Was macht Software geschäftskritisch?

Ungeplante Ausfälle kosten große deutsche Unternehmen laut einer Untersuchung von Cisco und Splunk mit Oxford Economics im Schnitt 295 Millionen US-Dollar pro Jahr, davon 89 Millionen an direkten Umsatzverlusten. Wie viel Schutz ein einzelnes System vor einem Ausfall bekommt, hängt an der Einordnung, wie geschäftskritisch eine Anwendung ist. Wir benutzen den Begriff selbst auf unserer Website, weil wir Software für geschäftskritische Prozesse entwickeln. Ab wann ist eine Anwendung aber geschäftskritisch und lässt sich das messen?

Eine Anwendung ist geschäftskritisch, wenn ihr Ausfall den Betrieb des Kerngeschäfts verhindert, egal ob operativ, rechtlich oder finanziell. 

Beispiele:

Operativ: Bei Ausfall des Systems gibt es keinen anderen Weg, mit der Arbeit weiterzumachen und es kann höchstens für einige Stunden auf ein anderes System oder Papier ausgewichen werden.

Rechtlich: Wenn das System ausfällt, droht der Verlust von Kundendaten oder Belegen mit Aufbewahrungspflicht.

Finanziell: Während dem Ausfall eines Systems gehen keine Bestellungen mehr ein und kommen auch später nicht mehr nach.

Relevant ist der Prozess, den die Software verantwortet: Ein kleines Tool, das die Auftragsfreigabe steuert, kann kritischer sein als ein aufwendiges Data Warehouse.

Die Begriffe werden im deutschen Sprachgebrauch oft synonym verwendet, obwohl sie unterschiedliche Schadenshöhen beschreiben.

Systeme, die mission-critical sind, dürfen nicht ausfallen, weil der Ausfall selbst eine Katastrophe wäre. Hier sollte System-Redundanz, also eine mehrfache Absicherung, auf jeder Ebene gebaut werden und die Zeit, die ein Backup-System benötigt, um bei einem Ausfall des Hauptsystems die Arbeit ohne Datenverlust zu übernehmen, sollte so gering wie möglich gehalten werden. 

Geschäftskritische Anwendungen richten bei einem Ausfall erheblichen Schaden an, das Unternehmen übersteht ihn aber. Ein Vertriebsteam kann z.B. einen Tag ohne CRM arbeiten. Das kostet zwar vielleicht Umsatz und ein paar Überstunden, aber der wesentliche Betrieb kann weiterlaufen. Unternehmenskritisch wird meist gleichbedeutend mit geschäftskritisch gebraucht, gelegentlich mit dem Zusatz, dass die Wirkung über eine einzelne Abteilung hinausreicht. 

Erfolgskritische Software liegt eine Stufe darunter: Ihr Ausfall bremst das Geschäft nur aus, aber gefährdet die Kontinuität nicht.

Verbindliche Definitionen existieren für keinen dieser Begriffe, aber eine Einordnung kann mit zwei Zahlen vorgenommen werden: der maximal tolerierten Wiederherstellungszeit (RTO) und dem maximal tolerierten Datenverlust (RPO). Hat man diese Werte nicht, kann die Forderung nach zusätzlichem Budget oder mehr Testabdeckung nicht mit konkreten Zahlen untermauert werden. 

Dazu kommt, dass die Wichtigkeit der Systeme von der Branche abhängt. Ein Zeiterfassungssystem ist für eine Agentur, die nach Stunden abrechnet, eher geschäftskritisch als für den Einzelhandel, der sie für die Verwaltung nutzt.

Um noch schneller erkennen zu können, ob Software geschäftskritisch ist, sind hier fünf Fragen für eine erste Einordnung.

• Was kostet eine Stunde Stillstand? Gezählt werden die Löhne der Teams, die nicht weiterarbeiten können, der entgangene Umsatz und der Aufwand für die Nacharbeit im Anschluss.
• Welche Systeme hängen daran? Manche Anwendungen sind allein über ihre Abnehmer kritisch. Ein Stammdatendienst erzeugt selbst keinen Umsatz, blockiert im Ausfall aber acht weitere verbundene Systeme.
• Gibt es einen Notbetrieb und wie lange kann er sinnvoll laufen? Man kann mit Alternativsystemen eine halbe Stunde überbrücken, doch nach drei Tagen entsteht ein Datenbestand, dessen Rückführung vermutlich mehr Arbeit macht als der Ausfall selbst.
• Wie schnell muss das System zurück sein? Die Antwort auf diese Frage hilft Ihnen, RTO und RPO zu bestimmen. 
• Steckt in der Anwendung ein Wettbewerbsvorteil? Software, die einen individuellen Prozess abbildet, ist schwerer zu ersetzen als eine, die Standardaufgaben erledigt. Ein Ausfall trifft dann den Vorteil selbst.

Hat man Antworten auf diese Fragen, wird schon um einiges klarer, wie wichtig ein System für das Unternehmen ist.

Direkte Kosten entstehen aus entgangenem Umsatz und der blockierten Arbeitszeit. Die Cisco/Splunk-Untersuchung setzt die weltweiten Kosten ungeplanter Downtime bei rund 15.000 US-Dollar pro Minute an.

Folgekosten entstehen nach der Behebung: Datenabgleich, Nacharbeit, verschobene Termine. Wie stark dieser Posten der Folgekosten wiegt, hängt vom Wiederherstellungsweg ab, denn nur 38 % der befragten Technologieverantwortlichen geben an, die Ursache eines Ausfalls immer identifizieren zu können. Hybride Systemlandschaften und Abhängigkeiten von SaaS-Anbietern erschweren die Analyse.

Reputationskosten lassen sich schwer beziffern, sind aber messbar geworden: Nach einem größeren Ausfall verlieren Unternehmen laut derselben Studie im Schnitt 3,4 % ihres Marktwertes.

Compliance-Kosten sind seit Dezember 2025 für viele deutsche Unternehmen neu dazugekommen. Das NIS2-Umsetzungsgesetz (NIS2UmsuCG) gilt seit dem 06.12.2025 und betrifft rund 29.500 Unternehmen in 18 Sektoren. Erhebliche Sicherheitsvorfälle sind innerhalb von 24 Stunden als Frühwarnung beim Bundesamt für Sicherheit in der Informationstechnik zu melden, nach 72 Stunden folgt eine Bewertung und nach einem Monat der Abschlussbericht. Diese Fristen setzen verschiedene technische Voraussetzungen voraus, wie brauchbare Logs und ein entsprechendes Monitoring.

Ob Standard oder Individualentwicklung passt, entscheidet sich daran, wie eigen der Prozess ist und hängt nicht unbedingt mit der Kritikalität zusammen. Die Buchhaltung ist in vielen Unternehmen geschäftskritisch, weil Zahlungsläufe, Monatsabschluss und Umsatzsteuervoranmeldung an Fristen hängen, viele Unternehmen führen eine Buchhaltung aber gleich. Für solche Prozesse gibt es ausgereifte Produkte, die von tausenden Anwendern erprobt und laufend an neue Vorgaben angepasst werden. Eine Eigenentwicklung müsste denselben gesetzlichen Rahmen nachbauen und ihn anschließend selbst pflegen – hier passt also oft eine Standardsoftware schon sehr gut.

Die Grenzen der Standardsoftware zeigen sich an drei Stellen: 

• Hängt die Standardsoftware auch mit dem Wettbewerbsvorteil zusammen, kann jede Anpassung dieser auch ein Kompromiss beim Vorteil bedeuten. 
• Wenn mehrere Systeme zusammenspielen müssen, dann kann der Integrationsaufwand über die Kosten einer eigenen Anwendung hinauswachsen.
• Wenn Daten wie Betriebsgeheimnisse das Haus nicht verlassen dürfen, ist die Auswahl von Standardsoftware schon stark eingeschränkt.

Wenn einer dieser Punkte zutrifft, eignet sich eine Individualsoftware mehr. Um die Entscheidung voranzutreiben, hilft ein Kostencheck für ein Software-Abo vs. Individualsoftware.

Geschäftskritische Software wird über Jahre weiterentwickelt, und jede Änderung an einem laufenden System kann ein Risiko darstellen. Automatisierte Tests sind deshalb die Grundlage dafür, dass Änderungen überhaupt bezahlbar bleiben. Sie machen aus einer Anpassung, die vorher tagelanges manuelles Nachprüfen erforderte, einen Vorgang von Minuten. Bei makandra ist testgetriebene Entwicklung seit der Gründung Teil des Vorgehens, in inzwischen mehr als 200 Projekten.

Aber auch Tests fangen nur ab, was vorher jemand bedacht hat, alles andere zeigt sich erst im Betrieb. Deshalb laufen Änderungen zuerst auf Kopien der Produktionsumgebung, bevor sie live gehen. Dazu kommt ein schrittweiser Rollout, damit Fehler höchstens kleine Gruppen treffen und Ausfälle in der Größenordnung von CrowdStrike gar nicht erst entstehen.

Ein dritter Punkt sollte auch bereits in der Entwicklung berücksichtigt werden: die Langlebigkeit. Bei einem System, das zehn Jahre oder länger bestehen soll, fällt auch nach dem Livegang noch ein großer Teil der Arbeit an. Das Fundament altert nämlich: Framework und Bibliotheken bekommen einige Jahre lang Sicherheitsupdates, dann endet der offizielle Support. Ab da bleiben neu gefundene Lücken offen, und irgendwann steht ein Update auf eine neue Version an, meist unter Zeitdruck und im laufenden Betrieb. Modularität und automatisierte Tests halten solche Upgrades bezahlbar. 

Als letzten Punkt darf man auch den Betrieb an sich nicht vergessen. Wer eine Anwendung selbst entwickelt hat und betreibt, findet die Ursachen von Störungen schneller als ein Dienstleister, der nur die Anwendung oder die Infrastruktur kennt. Angesichts der Cisco/Splunk-Studie, die zeigt, dass nur 38% der Technologieverantwortlichen die Ursache eines Ausfalls identifizieren können, ist das ein handfestes Argument dafür, Entwicklung und Betrieb zusammenzuhalten. Bei Studyflix begleiten wir die Lernplattform seit 2018 durch eine Verhundertfachung des Traffics, von der Weiterentwicklung bis zum skalierbaren Betrieb.

Geschäftskritisch ist keine Eigenschaft der Technik, sondern eine Aussage über den Prozess, den eine Software abbildet. Wer sie trifft, sollte sie mit zwei Zahlen belegen können: wie lange ein Ausfall dauern darf und was er in dieser Zeit kostet. Aus diesen Werten ergibt sich der Rest, von der Testabdeckung über die Architektur bis zur Frage, wer das System betreibt.