Wann wird eine gewachsene Fachanwendung zum Geschäftsrisiko?

Der Ausfall ist das späteste Warnsignal, nicht das erste. Wenn eine gewachsene Fachanwendung stillsteht, war sie meist über Monate oder Jahre bereits ein Risiko — nur ohne sichtbares Ereignis, an dem sich das hätte festmachen lassen.

Die Signale kommen früher

Vier Muster tauchen in der Praxis regelmäßig auf, bevor etwas ausfällt:

Änderungen kosten unverhältnismäßig viel. Eine fachlich kleine Anpassung — ein zusätzliches Feld, eine geänderte Regel — löst Aufwände aus, die niemand mehr vorab abschätzen kann. Das ist kein Kapazitätsproblem, sondern ein Hinweis darauf, dass die innere Struktur der Anwendung die Fachlogik nicht mehr sauber abbildet.

Niemand kann die Auswirkung einer Änderung vorhersagen. Wenn vor jeder Anpassung die Frage steht, was dadurch sonst noch kaputtgeht, fehlt Übersicht. Tests, Dokumentation oder klare Modulgrenzen könnten diese Frage beantworten — wenn es sie gäbe.

Die Nutzer haben sich eingerichtet. Es gibt Wege, die man kennen muss. Reihenfolgen, die eingehalten werden müssen. Felder, in denen etwas anderes steht als ihr Name sagt. Diese Anpassung der Menschen an die Anwendung ist bequemer als eine Änderung — und verdeckt, wie weit Prozess und Werkzeug auseinandergelaufen sind.

Der Betrieb hängt an Verfügbarkeit statt an Prozessen. Die Frage „Wer kann das?” hat genau eine Antwort. Urlaub, Krankheit oder ein Wechsel werden damit zu betrieblichen Risiken.

Warum das ein Geschäftsrisiko ist und kein IT-Thema

Solange die Anwendung läuft, wirkt sie wie ein Kostenpunkt. Sobald sie nicht mehr läuft, ist sie ein Prozessproblem — und das trifft nicht die IT, sondern den Fachbereich, der seine Arbeit nicht mehr erledigen kann.

Entscheidend ist deshalb nicht, wie alt eine Anwendung ist oder auf welcher Technologie sie basiert. Entscheidend ist, wie viel geschäftsrelevante Arbeit von ihr abhängt und wie viele Personen nötig sind, damit sie weiterläuft.

Woran sich der Handlungsdruck bemessen lässt

Drei Fragen ordnen die Lage schneller ein als eine technische Bestandsaufnahme:

1. Welcher Fachprozess würde stehenbleiben, und wie lange wäre das tragbar?
2. Wie viele Personen könnten die Anwendung im Ernstfall ändern — nicht bedienen, sondern ändern?
3. Wie lange braucht heute eine fachlich kleine Anpassung, von der Anfrage bis zum Produktivbetrieb?

Fällt die Antwort auf Frage 2 auf eine oder zwei Personen, ist das Risiko unabhängig von der Technologie bereits erheblich. Fällt die Antwort auf Frage 3 in Wochen statt Tagen aus, ist die Anwendung faktisch nicht mehr weiterentwickelbar — auch wenn sie im Tagesbetrieb noch funktioniert.

Was daraus folgt

Nicht jede gewachsene Anwendung muss ersetzt werden. Manche brauchen nur eine gesicherte Wissensbasis, andere eine klare Modulgrenze, wieder andere tatsächlich eine Ablösung. Welcher Fall vorliegt, lässt sich nicht an der Technologie ablesen — sondern nur daran, wie Fachprozess und Anwendung heute zusammenspielen.