Nicht-Qualität kostet zweimal – im Budget und im Einsatz.

Die Automobilindustrie hat für Fehler einen nüchternen Namen: Kosten der Nicht-Qualität. Nacharbeit, Ausschuss, Rückrufe, Gewährleistungsfälle. Jede Zahl lässt sich einer Ursache zuordnen, jede Ursache einem Prozessschritt, an dem etwas übersehen wurde. Diese Nüchternheit macht das Konzept wertvoll: Es macht Qualität zu einer Rechengröße, über die sich mit dem Management sprechen lässt, nicht nur mit dem Prüflabor.

Für Software-Defined Defence braucht es dieselbe Rechnung, nur mit einem zweiten Posten. Der Begriff ist kein Kunstwort dieser Serie: Software Defined Defence (SDD) ist im sicherheitspolitischen Diskurs bereits länger gebräuchlich und wurde 2023 in einem gemeinsamen Positionspapier von Bundesministerium der Verteidigung, BDSV, BDLI und Bitkom als Leitprinzip für die Streitkräfteentwicklung der Bundeswehr konkretisiert. Ein Fehler, der bei einem Fahrzeug einen Rückruf auslöst, ist ärgerlich und teuer. Ein Fehler, der bei einem vernetzten System erst im Einsatz auffällt, kostet nicht nur Geld, sondern Wirkung. Damit ist die Frage nach Nicht-Qualität im Umfeld von Software-Defined Defence keine rein finanzielle mehr, sondern eine nach Einsatzfähigkeit. Das ändert die Dringlichkeit, nicht die Logik.

Diese Verbindung von Nicht-Qualität und Einsatzfähigkeit ist eine eigene Zuspitzung dieses Artikels, kein Zitat aus dem SDD-Positionspapier selbst. Das Papier konzentriert sich auf Architektur, Entwicklungsgeschwindigkeit und Vertragsfragen, nicht auf Fehlerkosten. Diese Lücke zwischen Architekturprinzip und Qualitätskonsequenz ist der Ansatzpunkt für den Rest dieses Artikels.

Software-Defined Vehicle und Software-Defined Defence stehen für dieselbe Verlagerung, die im vorigen Einblick dieser Serie bereits beschrieben wurde. Der eingangs erwähnte Bundeswehr-Begriff bringt dabei eigene Untersuchungsfelder mit, von IT-Architektur über Entwicklungsgeschwindigkeit bis zu Vertrags- und Wirtschaftsfragen. Erste Kooperationen zwischen deutschen Rüstungs-Start-ups und etablierten Industriepartnern laufen bereits ausdrücklich unter diesem Prinzip, ein Hinweis darauf, dass der Transfer keine theoretische Übung bleibt, sondern operativ schon begonnen hat. Damit teilen sich beide Begriffe auch die zentrale Schwachstelle, nur mit unterschiedlichem Gewicht auf den Folgen.

Der Unterschied liegt also nicht im Prinzip, sondern in der Härte der Konsequenz und im Reifegrad der Werkzeuge, mit denen Nicht-Qualität sichtbar gemacht wird. Automotive hat diese Werkzeuge über Jahrzehnte gebaut. SDD hat bislang vor allem die Architekturfrage beantwortet, nicht die Qualitätskostenfrage. Das macht den Transfer wertvoll: Die Werkzeuge existieren bereits, sie müssen nur auf ein Umfeld mit weniger Fehlertoleranz übertragen werden.

Der entscheidende Unterschied liegt im Zeitpunkt der Entdeckung. In der Automobilindustrie gibt es für nahezu jeden Fehlerfall eine nachträgliche Reparatur: Software-Update, Werkstatttermin, im Extremfall Rückruf. Teuer, aber selten existenziell.

Bei vernetzten Systemen im Einsatz fehlt dieser Puffer oft. Eine Schwäche in der Architektur, die im Labor unauffällig blieb, kann sich unter Einsatzbedingungen anders zeigen, in einem Moment, in dem kein Software-Update mehr hilft. Genau deshalb wiegt jeder Fehler, der zu spät entdeckt wird, in diesem Umfeld schwerer als sein reiner Reparaturaufwand.

Die Automobilindustrie hat aus genau diesem Grund gelernt, Fehlerkosten so früh wie möglich zu verursachen, nicht so spät wie möglich zu entdecken. Ein Fehler in der Entwicklung ist billig. Derselbe Fehler im Feld ist um ein Vielfaches teurer, das zeigt sich in jedem Reifegrad- und Gewährleistungsprogramm, das diesen Zusammenhang systematisch nachverfolgt

Damit schließt sich der Kreis zu den beiden vorangegangenen Einblicken dieser Serie. Wer Prozessreife und Lieferkette beherrscht, wie im ersten Einblick beschrieben, und wer Architektur, Test und Freigabe softwaregerecht organisiert, wie im zweiten Einblick, hat die Voraussetzung geschaffen, um Nicht-Qualität überhaupt früh zu sehen. Ohne diese Voraussetzung bleibt sie unsichtbar, bis sie im Feld auftaucht. Und im Feld ist sie am teuersten, in jeder Hinsicht.

Das ist der Punkt, an dem viele Programme scheitern, nicht an fehlendem Willen zur Qualität, sondern an fehlender Transparenz darüber, wo ein Risiko eigentlich liegt. Entwicklungsteams bewerten ihre eigenen Themen erfahrungsgemäß zu optimistisch, das gilt branchenübergreifend. Eine neutrale, vergleichbare Bewertung über Teamgrenzen hinweg ist deshalb kein bürokratischer Zusatzschritt, sondern die Voraussetzung dafür, dass Risiken überhaupt sichtbar werden, bevor sie sich in Fehlerkosten oder Einsatzrisiken übersetzen.

Auch hier gilt, was diese Serie von Anfang an offen benennt: Der Transfer ist keine Einbahnstraße. Automotive denkt in Millionen Stück, Defence in Kleinserien mit wenigen hundert oder tausend Einheiten. Dieser Größenunterschied verändert die Rechnung selbst: Wo Automotive einen Fehler über die Stückzahl amortisieren kann, trifft derselbe Fehler in Defence eine viel kleinere Basis voller Kosten. Automotive hat trotzdem einen Vorsprung beim Instrumentarium, mit dem sich Nicht-Qualität überhaupt messbar machen lässt, nicht weil das Problem im Defense-Umfeld kleiner wäre, sondern weil die Branche aus eben dieser Kleinserien-Logik kommt, in der Einzelfälle bislang noch individuell aufgefangen werden konnten.

Nicht-Qualität lässt sich nicht vermeiden, in keiner Branche, die komplexe Systeme entwickelt. Was sich vermeiden lässt, ist der Zeitpunkt, an dem sie sichtbar wird. Je später ein Fehler entdeckt wird, desto teurer wird er, und im software-definierten Gefechtsfeld bedeutet spät nicht selten: zu spät.
Die eigentliche Frage lautet deshalb nicht, ob Fehler passieren. Sie lautet, ob eine Organisation die Struktur besitzt, sie früh zu finden, sauber zuzuordnen und mit einer Entscheidung zu beantworten, statt mit einer Hoffnung.