Total Cost of Ownership für Verteidigungssoftware: ein Beschaffungsleitfaden

Ein Verteidigungssoftware-Programm plant €2,4 Millionen für eine Lagebildplattform ein. Zwei Jahre nach der Inbetriebnahme belaufen sich die Gesamtausgaben auf €6,1 Millionen. Die Differenz – €3,7 Millionen – stand in keiner Budgetposition. Sie akkumulierte sich über Integrationsaufwand, Schulungsrotationen, drei Sicherheits-Neuzertifizierungszyklen, eine größere Versionsmigration und eine proprietäre Middleware-Schicht, die der Anbieter zwar voraussetzte, aber im ursprünglichen Angebot nie offenlegte.

Dieses Muster ist so verbreitet, dass es strukturell und nicht zufällig ist. Der Total Cost of Ownership (TCO) für Verteidigungssoftware wird bei der Beschaffung konsequent und manchmal dramatisch unterschätzt – nicht weil Beschaffungsbeauftragte nachlässig sind, sondern weil das zum Zeitpunkt der Anschaffung verwendete Kostenmodell by design unvollständig ist. Dieser Leitfaden bietet ein Framework für die Erstellung einer belastbaren TCO-Schätzung vor der Vertragsvergabe.

Warum der TCO für Verteidigungssoftware systematisch unterschätzt wird

Bei der kommerziellen Software-Beschaffung liegen Anschaffungskosten und TCO so nah beieinander, dass es vertretbar ist, einen als Näherungswert für den anderen zu verwenden. Die Integrationsumgebung ist relativ standardisiert, die Schulungsbasis ist die allgemeine Belegschaft, und der Wartungsrhythmus folgt vorhersehbaren kommerziellen Normen.

Die Verteidigungsbeschaffung operiert in einer anderen Umgebung bei jeder dieser Dimensionen. Die Integrationsschicht verbindet sich mit klassifizierten Netzwerken, proprietären militärischen Datenformaten und jahrzehntealten Legacy-Systemen, die modernen API-Konventionen vorausgehen. Die Schulungsbasis besteht aus Militärbedienern mit definierten Rollenprofilen und hoher jährlicher Fluktuation. Der Wartungsprozess umfasst Sicherheits-Neuzertifizierungen, bevor ein Patch auf einem klassifizierten System bereitgestellt werden kann – ein Prozess, der jedem Update-Zyklus Wochen oder Monate hinzufügt.

Strukturell wird das Problem durch die Organisation von Verteidigungsbudgets verstärkt. Die Anschaffungskosten erscheinen im Beschaffungsbudget. Integrationsaufwand erscheint im Engineering-Budget des Programmbüros. Schulungen erscheinen in der Schulungszuweisung der Einheit. Sustainment erscheint in einer mehrjährigen Wartungslinie, die separat vom Erstvertrag verhandelt wird. Kein einzelner Budgetverantwortlicher hat Einblick in alle vier. Das Ergebnis ist, dass Anbieter konsequent mit niedrigen Anschaffungskosten gewinnen und dann ihre Marge über die Kosten zurückgewinnen, für die niemand budgetiert hat.

Die fünf TCO-Komponenten und ihre Gewichtung

Ein vollständiges TCO-Modell für Verteidigungssoftware umfasst fünf Kostenkategorien. Ihre relative Gewichtung variiert je nach Programm, aber die nachfolgende Verteilung spiegelt typische 10-Jahres-Programme wider, die in der europäischen Verteidigungsbeschaffung beobachtet wurden:

Anschaffungskosten (15–25 % des 10-Jahres-TCO)

Das ist die Zahl im Angebot des Anbieters: Lizenzgebühren, Abonnementgebühren, Pro-Seat-Gebühren und einmalige Einrichtungsgebühren. Bei unbefristeten Lizenzen handelt es sich hauptsächlich um Kosten im ersten Jahr. Bei Abonnementmodellen projizieren Sie die Jahresgebühr nach vorne unter Verwendung der vertraglich vereinbarten Preiseskalationsgrenze des Anbieters – typischerweise 3–8 % pro Jahr für Verteidigungssoftware – und diskontieren Sie auf den Gegenwartswert über die Programmlaufzeit.

Achten Sie auf Pro-Seat-Preise, die unerwartet skalieren. Eine Plattform, die mit €40.000 pro Jahr für 50 Nutzer bepreist ist, kann €320.000 pro Jahr erreichen, wenn das Programm auf 400 Nutzer einer Koalition ausgeweitet wird. Modellieren Sie die realistische Nutzer-Obergrenze, nicht den Piloteinsatz-Kopfstand.

Integrationskosten (25–35 % des 10-Jahres-TCO)

Integration ist die größte Einzelquelle für TCO-Unterschätzungen bei Verteidigungsprogrammen. Sie umfasst den Arbeits- und Infrastrukturaufwand, um die neue Software mit der bestehenden Betriebsumgebung zu verbinden: C2-Systeme, Sensorfeeds, Geheimdienstdatenbanken, Logistikplattformen, Identitätsmanagement und Netzwerkinfrastruktur.

Verteidigungsintegration ist keine Standardarbeit. Jeder Verbindungspunkt erfordert benutzerdefinierte Datentransformation (militärische Datenformate sind nicht REST-freundlich), Sicherheitsschicht-Mediation (jede Verbindung über Klassifizierungsgrenzen hinweg erfordert kryptografische Trennung) und Tests mit Live- oder repräsentativen Betriebsdaten. Die Integrationsdokumentation des Anbieters ist für kommerzielle Umgebungen geschrieben. Die Anpassung für eine klassifizierte Verteidigungsumgebung multipliziert den dokumentierten Aufwand typischerweise um 1,5 bis 2.

Schulungskosten (20–30 % des TCO im ersten Jahr; danach 10–15 % jährlich)

Die Erstschulung umfasst Bediener, Systemadministratoren und Sicherheitsbeauftragte. Bei einem mittelgroßen Einsatz über drei Einheiten belaufen sich die Kosten typischerweise auf 400–800 Personenstunden Unterricht zuzüglich Instrukteur- und Raumkosten. Die Zahl, die konsequent in Beschaffungsschätzungen fehlt, sind die wiederkehrenden Schulungskosten, die durch Personalfluktuation entstehen.

Operative Militäreinheiten erneuern 20–35 % ihres Personals pro Jahr. Bei einem System mit 200 aktiven Nutzern bedeutet das, dass 40–70 neue Bediener jährlich geschult werden müssen – unbegrenzt, für die Lebensdauer des Programms. Schulungsmaterialien erfordern ebenfalls Pflege: Jede größere Softwareveränderung macht bestehende Materialien ungültig und erfordert einen Dokumentationsrevisionszyklus, den Anbieter nicht finanzieren und selten unterstützen.

Wartungs- und Supportkosten (20–30 % des 10-Jahres-TCO)

Jährliche Wartungsgebühren für Verteidigungssoftware belaufen sich typischerweise auf 15–22 % der ursprünglichen Lizenzkosten pro Jahr. Diese Gebühren decken die anbieterseitige Patch-Entwicklung und den Supportzugang ab. Sie decken nicht den internen Aufwand ab, der erforderlich ist, um diese Patches in einer klassifizierten Umgebung zu validieren, zu testen und bereitzustellen – ein Prozess, der aufgrund von Neuzertifizierungsanforderungen wesentlich teurer ist als das kommerzielle Äquivalent.

SLA-Stufen sind im Verteidigungsbereich wichtiger als im kommerziellen Kontext, weil die Folge von Ausfallzeiten operativ ist. Bewerten Sie die Reaktionszeitverpflichtungen für P1-Vorfälle, die dokumentierte Support-Kapazität des Anbieters (Mitarbeiterzahl und Eskalationsweg) und die Länge des Langzeit-Support-Fensters im Verhältnis zur Betriebslebensdauer des Programms. Ein Anbieter, der 5-Jahres-Support für ein 15-Jahres-Programm anbietet, schafft eine strukturelle Lücke, die Beschaffungsverträge selten adressieren.

Weiterentwicklungskosten (10–20 % des 10-Jahres-TCO)

Verteidigungssoftwareprogramme durchlaufen mindestens zwei größere Versionsübergänge über eine 10-jährige Laufzeit. Jeder Übergang in einer klassifizierten Umgebung umfasst: Migrationsaufwand, Neuzertifizierung (Sicherheitsüberprüfung und formale Betriebsgenehmigung für die neue Version), Nachschulung und Integrations-Retests. Professional Services des Anbieters für Migrationen werden in Erstschätzungen routinemäßig zu niedrig angesetzt, da die Migrationskomplexität zum Zeitpunkt der Vertragsvergabe noch nicht vollständig bekannt ist.

Planen Sie eine Neuzertifizierungs-Kontingenz von 40–80 % des ursprünglichen Integrationsaufwands für jeden größeren Versionsübergang ein. Das ist die Zahl, die in Programmbüro-Schätzungen am häufigsten fehlt.

Integrationskosten-Modell: Aufwandsschätzung vor Vertragsvergabe

Eine Vorab-Integrationskosten-Schätzung ist zwangsläufig ungenau, aber eine Größenordnungsschätzung ist weit besser als gar keine Schätzung. Das folgende Modell bietet einen strukturierten Ausgangspunkt.

Vergeben Sie für jeden Integrationspunkt einen API-Komplexitäts-Score von 1 bis 5 basierend auf vier Faktoren: Protokollkomplexität (REST/JSON ergibt 1; benutzerdefinierte Binärprotokolle ergeben 5), Authentifizierungsanforderungen (API-Schlüssel ergibt 1; gegenseitiges TLS mit PKI-Infrastruktur ergibt 4–5), Datentransformationskomplexität (direkte Feldzuordnung ergibt 1; semantische Übersetzung über Datenmodelle hinweg ergibt 4–5) und SDK-Verfügbarkeit (Anbieter-SDK ergibt 1; keine Dokumentation ergibt 5).

Die Basis-Aufwandsschätzung lautet: (Komplexitäts-Score × 20 Stunden) pro Endpunkt, zuzüglich einer festen Ergänzung von 80 Stunden für die Sicherheitsüberprüfung pro Integrationspunkt in einer klassifizierten Umgebung, zuzüglich 40 Stunden für Abnahmetests pro Endpunkt. Für ein System mit 8 Integrationspunkten mit durchschnittlichem Komplexitäts-Score 3 lautet die Basisschätzung: (3 × 20 × 8) + (80 × 8) + (40 × 8) = 480 + 640 + 320 = 1.440 Stunden vor Kontingenz.

Wenden Sie einen Kontingenz-Multiplikator von 1,3–1,5 für klassifizierte Infrastrukturen an, wo Tool-Zugang, Netzwerksegmentierung und Genehmigungsprozesse die Produktivität einschränken. Die angepasste Schätzung von 1.872–2.160 Stunden (ungefähr 12–14 Personenmonate) ist eine realistische Planungsgröße für eine mittelkomplexe Verteidigungssystemintegration.

Schulungskosten: das wiederkehrende Belastungsmodell

Die Schulungskostenmodellierung beginnt mit der Rollendifferenzierung. Nicht alle Nutzer haben dieselben Schulungsanforderungen. Bediener benötigen funktionale Schulungen zu ihren spezifischen Arbeitsabläufen. Systemadministratoren benötigen vollständige Plattformschulungen einschließlich Sicherheitskonfiguration. Sicherheitsbeauftragte benötigen akkreditierungsspezifische Schulungen zu Systemsicherheitsfunktionen und Auditverfahren.

Für einen Einsatz mit 200 Bedienern, 10 Administratoren und 3 Sicherheitsbeauftragten könnte ein Basis-Erstjahres-Schulungsbudget wie folgt aussehen: 200 Bediener à 16 Stunden (3.200 Stunden), 10 Administratoren à 40 Stunden (400 Stunden), 3 Sicherheitsbeauftragte à 24 Stunden (72 Stunden) zuzüglich Instrukteur- und Materialkosten – insgesamt rund 3.700 Personenstunden Direktunterricht plus Overhead.

Die wiederkehrenden Jahreskosten bei 25 % Fluktuation betragen 50 Bediener à 16 Stunden (800 Stunden) zuzüglich anteilige Administratoren- und Sicherheitsbeauftragten-Fluktuation – ungefähr 900 Stunden pro Jahr. Über eine 10-jährige Programmlaufzeit übersteigen die wiederkehrenden Schulungsaufwände die anfängliche Schulungsinvestition bis zum 4. Jahr. Programme, die nur für Erstschulungen budgetieren, entdecken diese Diskrepanz im dritten oder vierten Betriebsjahr.

Die Pflege von Schulungsmaterialien ist ein separater Posten. Jede größere Softwareversion – typischerweise alle 18–24 Monate – erfordert Materialrevision. Budgetieren Sie 200–400 Stunden technisches Schreiben und Instructional Design pro größerem Release-Zyklus.

Wartung und Support: SLA-Stufen und Anbieter-Ausfallrisiko

Die SLA-Bewertung für Verteidigungssoftware erfordert die Prüfung von drei Dimensionen, die Standard-Checklisten für kommerzielle Beschaffungen auslassen.

Die erste ist Patch-Rhythmus versus Neuzertifizierungs-Overhead. Ein Anbieter, der monatlich Sicherheitspatches veröffentlicht, erzeugt für klassifizierte Einsätze eine monatliche Neuzertifizierungsbelastung. Ein vierteljährlicher Patch-Rhythmus – mit Notfall-Patches für kritische CVEs – ist operativ kompatibler mit den Einschränkungen klassifizierter Einsätze. Bewerten Sie die historische Patch-Release-Frequenz des Anbieters gegen die Akkreditierungskapazität Ihrer Organisation.

Die zweite ist das Anbieter-Ausfallrisiko. Verteidigungssoftware-Anbieter auf dem europäischen Markt umfassen einen erheblichen Anteil kleiner und mittelständischer Unternehmen mit begrenzter finanzieller Tiefe. Ein Anbieter mit 40 Mitarbeitern, der eine missionskritische Plattform bereitstellt, stellt ein Konzentrationsrisiko dar: Schlüsselpersonen-Abhängigkeit, Übernahmerisiko und potenzielle Produktaufgabe. Bewerten Sie die finanzielle Gesundheit, Eigentümerstruktur und langfristige Support-Verpflichtungen des Anbieters im Vertrag. Source-Code-Escrow ist die Standardmitigation – der Anbieter hinterlegt Quellcode und Build-Anweisungen bei einem neutralen Escrow-Agenten, mit Freigabe bei definierten Kontinuitätsereignissen.

Die dritte Dimension ist die Exposition gegenüber Open-Source-Komponenten. Die meisten Verteidigungssoftware-Produkte enthalten Open-Source-Bibliotheken, deren Pflege durch die Community finanziert wird. Bedeutende Open-Source-Komponenten, deren Community-Support nachlässt, schaffen zukünftige Kosten: Entweder absorbiert der Anbieter interne Wartungskosten (die schließlich auf die Support-Gebühren umgelegt werden) oder die Komponente wird zu einem Sicherheitsrisiko. Fordern Sie eine Software Bill of Materials (SBOM) an und überprüfen Sie den Gesundheitszustand der wichtigsten Open-Source-Abhängigkeiten als Teil der Anbieter-Due-Diligence.

Für ein detailliertes Framework zur Bewertung von Anbieterfähigkeiten vor der Vertragsvergabe, siehe Bewertung von Verteidigungssoftware-Anbietern: ein technischer Due-Diligence-Leitfaden für Beschaffungsbeauftragte.

Eigenentwicklung vs. Kauf vs. COTS: wann Eigenentwicklung beim TCO gewinnt

Die Standard-Beschaffungsannahme ist, dass COTS-Software (Commercial Off-The-Shelf) günstiger ist als Eigenentwicklung, weil sie F&E-Kosten auf viele Kunden verteilt. Diese Annahme gilt in kommerziellen Umgebungen und bricht in spezifischen Verteidigungskontexten zusammen.

Eigenentwicklung wird TCO-konkurrenzfähig gegenüber COTS, wenn drei Bedingungen zusammentreffen. Erstens ist das Datenmodell des COTS-Produkts architektonisch inkompatibel mit dem System of Record und erfordert eine Middleware-Schicht, die selbst ein bedeutendes Softwareprojekt ist. Eine Middleware-Schicht erhöht Integrationskosten, Wartungskosten und stellt einen Single Point of Failure dar – und sie ist in der Preisgestaltung des COTS-Anbieters unsichtbar. Zweitens schafft die proprietäre Integrationsschicht des COTS-Produkts Vendor-Lock-in, der sich über die Zeit verschärft: Zukünftige Versionsmigrationen werden zur Geisel des Migrations-Toolings des Anbieters, und alternative Anbieter stehen vor dem gleichen Middleware-Problem von Grund auf. Drittens ist der Funktionsumfang eng und stabil. Ein maßgeschneidertes Tool, das eine Sache gut macht – beispielsweise Track-Fusion für einen bestimmten Sensortyp –, kann von einem kleinen Team zu niedrigeren 10-Jahres-Kosten gebaut, getestet und gewartet werden als eine breite COTS-Plattform mit 80 % ungenutzter Funktionalität.

Die Crossover-Berechnung: Wenn der COTS-Integrationsaufwand im ersten Jahr 150 % der Lizenzkosten übersteigt und die jährliche Wartungsgebühr über 20 % der Lizenz liegt und die Programmlaufzeit 8 Jahre übersteigt, modellieren Sie Eigenentwicklung als konkurrierende Option vor der Vergabe. Der Vergleich muss die vollständigen Eigenentwicklungskosten umfassen (nicht nur den initialen Build – laufende Wartung, Sicherheits-Patching und Weiterentwicklung), projiziert über denselben Zeitraum.

Für Programme, bei denen COTS die richtige Wahl ist, aber Beschaffungskonditionen sorgfältig strukturiert werden müssen, behandelt der Verteidigungsbeschaffungsleitfaden von RFP bis Vertrag die Vertragsstrukturen, die gegen Kostensteigerungen nach Vergabe schützen.

Das Modell zusammenführen: ein Praxisbeispiel

Betrachten Sie eine taktische Geheimdienstfusionsplattform, die für ein Hauptquartier auf Brigade-Ebene beschafft wird. Das Angebot des Anbieters beläuft sich auf €1,8 Millionen für eine 5-Jahres-Lizenz für 150 Nutzer. Ein vollständiges TCO-Modell für eine 10-jährige Programmlaufzeit:

Anschaffung (10 Jahre): Lizenz Jahr 1–5: €1,8 Mio., Verlängerungsjahre 6–10 geschätzt auf €2,2 Mio. (3 % jährliche Eskalation angewendet). Gesamt: €4,0 Mio.

Integration: 10 Integrationspunkte bei durchschnittlichem Komplexitäts-Score 3,5 mit klassifiziertem Infrastruktur-Kontingenz von 1,4. Geschätzte 2.100 Arbeitsstunden bei €120/Stunde belasteter Rate. Zuzüglich Infrastruktur (Middleware-Server, Sicherheitsappliances): €180.000. Gesamt: €432.000.

Schulung (10 Jahre): Erstschulung 3.700 Personenstunden à €85/Stunde = €315.000. Jährliche Wiederholungsschulung à €80.000/Jahr × 9 Jahre = €720.000. Materialpflege 3 größere Release-Zyklen à €35.000 = €105.000. Gesamt: €1,14 Mio.

Wartung und Support (10 Jahre): Jährliche Support-Gebühren bei 18 % der ursprünglichen Lizenz (€324.000/Jahr) × 10 = €3,24 Mio. Internes Patch-Management-Aufwand à €60.000/Jahr = €600.000. Gesamt: €3,84 Mio.

Weiterentwicklung (2 größere Upgrades): Migrationsaufwand 2 × 1.000 Stunden à €120/Stunde = €240.000. Neuzertifizierung 2 × 600 Stunden à €120/Stunde = €144.000. Gesamt: €384.000.

10-Jahres-TCO: ungefähr €9,8 Millionen gegenüber einem Headline-Anschaffungsangebot von €1,8 Millionen. Die Anschaffungskosten entsprechen 18 % der gesamten Programmkosten. Die restlichen 82 % standen nie im Angebot des Anbieters.

Beschaffung strukturieren, um den TCO zu kontrollieren

Ein TCO-Modell ist vor der Vergabe nützlich. Nach der Vergabe hängt die Kostenkontrolle von der Vertragsstruktur ab. Mehrere Mechanismen reduzieren das Risiko von Kostensteigerungen nach der Vergabe erheblich.

Preisobergrenzen für Abonnement-Eskalation verhindern den Zinseszinseffekt jährlicher Gebührenerhöhungen über lange Programmlaufzeiten. Professional-Services-Sätze für Integration sollten bei der Vertragsvergabe fixiert werden, nicht späteren Verhandlungen überlassen werden, wenn der Anbieter Hebelwirkung hat. Das Eigentum an Schulungsmaterialien sollte beim beschaffenden Unternehmen liegen – anbietereigene Schulungsmaterialien sind ein wiederkehrendes Kostenzentrum. Migrationssupport-Verpflichtungen sollten spezifiziert werden: Was der Anbieter liefert, zu welchem Satz, für jeden größeren Versionsübergang. Und Langzeit-Support-Fenster-Verpflichtungen sollten explizit sein – ein Anbieter, der sich bei Vertragsvergabe zu 10 Jahren Support verpflichtet, unterscheidet sich wesentlich von einem, der sich zu 5 Jahren mit Verlängerung nach Ermessen des Anbieters verpflichtet.

TCO-Modellierung ist keine Garantie gegen Kostenüberschreitungen. Programme ändern sich, Anforderungen entwickeln sich, und Anbieter werden übernommen. Aber eine Beschaffungsentscheidung, die mit einem vollständigen Kostenbild getroffen wird – anstatt mit einem Anschaffungskosten-Näherungswert –, beginnt aus einer Position strukturellen Bewusstseins statt struktureller Blindheit.