Der Business Case für eine Modernisierung: wie man ein Gremium überzeugt, das keine IT-Argumente hört

Warum eine Vorlage, die das System kritisiert, verliert

Ein Investitionsgremium entscheidet zwischen Alternativen, und die bequemste Alternative ist immer das Nichtstun. Eine Vorlage, die erklärt, wie schlecht das Altsystem ist, liefert dem Gremium kein Argument gegen diese Alternative, denn das System läuft ja heute. Was das Gremium braucht, ist die Antwort auf zwei Fragen: Was gilt in drei Jahren, wenn wir nicht entscheiden, und was kostet der Weg, der das verhindert? Aus diesen zwei Fragen ergeben sich vier Bausteine, die in unserer Praxis jede tragfähige Vorlage enthält, und die Reihenfolge ist Teil des Arguments.

Baustein 1: Das Szenario ohne Investition

Die stärkste Vorlage beginnt mit der Fortschreibung des Ist-Zustands statt mit dem Vorhaben: Änderungsvorlaufzeit heute und in drei Jahren, Zahl der Kenner heute und nach den bekannten Abgängen, laufende Kosten für Wartung und Support. Diese Fortschreibung braucht keine Annahme über die Zukunft, nur die Fortsetzung dessen, was bereits messbar ist. Wenn eine fachliche Änderung heute sechs Wochen braucht und die Vorlaufzeit in den letzten drei Jahren jedes Jahr gestiegen ist, ist die Zahl für 2029 keine Prognose, sie ist eine Linie durch bekannte Punkte. Wenn zwei Personen das System kennen und eine davon 2028 in Rente geht, ist die Kennerzahl danach ohne Maßnahme eins. Wie sich diese Kosten vollständig erfassen lassen, auch die versteckten in Umgehungslösungen und Excel-Listen, zeigt Legacy-Betriebskosten transparent machen.

Welche Zahlen brauchen Sie für das Szenario ohne Investition?

Fünf Zahlen reichen, und alle fünf lassen sich in zwei Wochen aus dem eigenen Betrieb erheben, ohne externe Hilfe. Sie sind zugleich die Zahlen, die das Gremium später als Erfolgsmaßstab verwenden wird.

• Änderungsvorlaufzeit: Tage von der Anforderung bis zur produktiven Änderung, gemessen an den letzten zehn Änderungen, mit Trend über drei Jahre.
• Kennerzahl: Personen, die eine Änderung am System ohne Anleitung durchführen können, heute und nach den bekannten Abgängen mit Datum. Was passiert, wenn der einzige Kenner ausfällt, beschreibt IT-Notfallplan: wenn der einzige Kenner ausfällt.
• Laufende Kosten: Wartungsvertrag, Support, Lizenzen, Betrieb, plus die Stunden, die intern für Umgehungslösungen anfallen, je Jahr.
• Vorfälle: Ausfälle und Fehlbuchungen je Jahr mit Dauer und betroffenen Prozessen, aus dem Ticketsystem oder dem Schichtbuch.
• Abhängige Prozesse: Welche Geschäftsprozesse stehen still, wenn das System steht, und mit welchem Umsatz je Tag.

Wer diese fünf Zahlen nicht hat, hat einen Grund für den ersten Baustein der Vorlage: eine abgegrenzte Systemanalyse. Eine Legacy Discovery über zehn Arbeitstage liefert in unserer Praxis die Systemkarte, die Abhängigkeiten und die Kennerzahl, und sie ist klein genug, um ohne große Debatte beschlossen zu werden. Wie eine solche Kartierung mit KI-Unterstützung abläuft, steht in Softwarearchäologie: das Altsystem kartieren.

Baustein 2: Die entgangenen Geschäftsmöglichkeiten

Die Liste der als zu riskant vertagten Anforderungen, mit den dahinterliegenden fachlichen Zielen. Diese Liste kommt aus den Fachbereichen statt aus der IT, und das ist ihr eigentlicher Wert: Sie macht aus einem IT-Antrag einen Geschäftsantrag mit mehreren Fürsprechern. Typische Einträge sind der Kundenzugang zum Auftragsstatus, den der Vertrieb seit zwei Jahren wünscht, die Schnittstelle zum Lieferanten, die der Einkauf nicht bekommt, oder die Auswertung, die das Controlling monatlich von Hand baut. Zu jedem Eintrag gehören der Fachbereich, das Ziel, der Grund der Vertagung und eine Größenordnung des Nutzens, wo sie belegbar ist. Wo sie nicht belegbar ist, steht das Ziel ohne Zahl, und das ist besser als eine geschätzte Zahl, die im Gremium zerlegt wird.

Baustein 3: Die Reihenfolge statt der Gesamtsumme

Gremien lehnen große Zahlen ohne Zwischenschritte ab, und zwar zu Recht. Ein Vorhaben in Modulen mit eigenem Nutzen, eigener Aufwandsspanne und eigenem Abbruchpunkt ist entscheidbar. Der erste Baustein sollte klein, festpreisfähig und in Wochen abgeschlossen sein; er beweist die Methode, bevor über den großen Betrag gesprochen wird.

Die Reihenfolge der Module folgt dem Risiko, nicht der technischen Eleganz: Zuerst das Modul, dessen Ausfall den größten Umsatz je Tag blockiert, oder das, dessen einziger Kenner am frühesten geht. Jedes Modul bekommt einen Abbruchpunkt, also eine Bedingung, unter der das Gremium das Vorhaben ohne Gesichtsverlust beendet, etwa: Modul 1 liefert bis Tag zehn keine belastbare Systemkarte, oder die Aufwandsschätzung für Modul 2 liegt mehr als die Hälfte über der Spanne. Das nimmt dem Gremium die Angst vor dem Fass ohne Boden. Wie eine Modernisierung Modul für Modul neben dem laufenden System entsteht, beschreibt Das Strangler-Fig-Muster in der Praxis; wie eine realistische Aufwandsspanne je Modul zustande kommt, Modernisierungskosten realistisch schätzen.

Baustein 4: Das Risiko der Alternative

Jede Vorlage sollte die Gegenposition sauber darstellen: Was spricht dafür, nichts zu tun, und unter welchen Bedingungen wäre das richtig? Wer diese Bedingungen benennt, wird glaubwürdig, und in dem Moment, in dem sie nicht zutreffen, hat er das Argument schon selbst geführt. Drei Bedingungen kommen in der Praxis vor: Das System wird in absehbarer Zeit ohnehin abgelöst, etwa durch einen Konzernstandard nach einer Übernahme. Die Kennerzahl bleibt über fünf Jahre stabil, weil ein Nachfolger eingearbeitet ist. Oder die abhängigen Prozesse verlieren an Bedeutung, weil das Geschäft sich verlagert. Trifft keine der drei zu, steht das in der Vorlage, mit Datum und Beleg.

Die drei Formulierungen, die zuverlässig scheitern

„Technologisch veraltet“ beschreibt einen Zustand, kein Risiko. „Wartungsaufwand steigt“ ist ohne Zahl eine Behauptung. „Wir brauchen eine moderne Architektur“ beantwortet die Frage nach dem Nutzen mit einer Anforderung an die Lösung. Jede dieser Formulierungen lässt sich durch eine belegte Zahl aus dem eigenen Betrieb ersetzen, und jede Ersetzung erhöht die Chance auf eine Entscheidung. Aus „technologisch veraltet“ wird: „Der Hersteller liefert seit 2023 keine Sicherheitsupdates, die letzte bekannte Lücke ist seit 14 Monaten offen.“ Aus „Wartungsaufwand steigt“ wird: „Die Änderungsvorlaufzeit ist von drei auf sechs Wochen gestiegen, bei gleicher Zahl der Änderungen.“ Aus „moderne Architektur“ wird: „Die zwölf vertagten Anforderungen lassen sich mit Modul 2 in vier Monaten umsetzen.“ Wie sich technische Schulden so beziffern lassen, dass ein Controller sie nachrechnen kann, zeigt Technische Schulden messen und belegen.

Wie sieht die Vorlage auf einer Seite aus?

Ein Gremium liest die erste Seite. Deshalb steht auf der ersten Seite alles, was für die Entscheidung nötig ist, und der Rest ist Anhang. Oben das Szenario ohne Investition mit den fünf Zahlen heute und in drei Jahren. Darunter die vertagten Anforderungen mit Fachbereich und Ziel, höchstens zwölf Zeilen. Dann die Modulreihenfolge mit Nutzen, Aufwandsspanne und Abbruchpunkt je Modul, wobei nur Modul 1 zur Entscheidung steht. Dann die Bedingungen, unter denen Nichtstun richtig wäre, mit dem Befund, ob sie zutreffen. Unten der Beschlussvorschlag: Modul 1 beauftragen, Festpreis, Termin für die Vorlage von Modul 2. Diese Struktur können Sie als druckbares Arbeitsblatt (PDF) herunterladen und mit den Zahlen aus Ihrem Betrieb füllen.

Wer die Vorlage einbringt, entscheidet über ihre Wirkung mit. Sobald ein Fachbereich die entgangenen Möglichkeiten mitträgt und mit unterschreibt, ändert sich die Wahrnehmung von „die IT will Geld“ zu „das Geschäft wird gebremst“. In unserer Praxis ist die Vorlage mit zwei Unterschriften aus Fachbereichen die, die im ersten Anlauf beschlossen wird. Wer im Betrieb überhaupt für das Altsystem verantwortlich ist und deshalb unterschreiben sollte, klärt Wer verantwortet das Altsystem?.

Was der Business Case nicht löst

Die Vorlage ersetzt keine Analyse. Wenn die fünf Zahlen fehlen, ist die ehrliche Vorlage der Antrag auf die zehntägige Analyse, nicht der Antrag auf die Modernisierung. Sie erzeugt keine Kenner: Ein beschlossenes Modul 1 macht aus zwei Wissensträgern keine vier, dafür braucht es Dokumentation und Einarbeitung, die im Modul eingeplant sind. Sie verspricht keinen ROI: Eine Modernisierung erwirtschaftet selten direkt Umsatz, sie senkt Risiko und Änderungskosten, und beides lässt sich beziffern, ohne eine Rendite zu behaupten, die in der Nachbetrachtung nicht hält. Und sie ersetzt keine Entscheidung über das Zielbild: Ob das Altsystem abgelöst, modernisiert oder in Teilen weiterbetrieben wird, ist eine eigene Frage, die Ablösen oder modernisieren? behandelt. Die Vorlage bringt das Gremium dazu, den ersten Schritt zu beschließen. Die weiteren Schritte verdient sich das Vorhaben mit jedem Modul neu.