Weg mit der alten Software

Gebäude werden saniert, Fuhrparks ausgetauscht, Maschinen ersetzt. Nur die Software, auf der die Kernprozesse laufen, bleibt in vielen Unternehmen seit Jahrzehnten dieselbe. Dieser Beitrag zeigt an zwei Beispielen aus unserer Beratungspraxis, warum das Überbauen alter Systeme auf Dauer teurer ist als ihre Erneuerung, was technische Schuld tatsächlich kostet und welche Barrieren fallen müssen, bevor ein Unternehmen zum selbstfahrenden Unternehmen werden kann.

Ein Ticket, hundert Millionen: was Überbauen kostet

Ein Verkehrsunternehmen wollte eine App, mit der Fahrgäste am Handy eine Verbindung suchen und das Ticket mit einem Klick bezahlen. Die Aufgabe klingt überschaubar, und sie ist es auch: Eine App mit dieser Funktionalität wird üblicherweise mit rund 70.000 Euro kalkuliert. Am Ende hat sie das Unternehmen mehr als 100 Millionen Euro gekostet. Ich habe das Beispiel im Buch „Das selbstfahrende Unternehmen“ (Springer Gabler 2021) beschrieben, weil es den Mechanismus so deutlich zeigt.

Die App musste auf fünf großen und unzähligen kleinen Bestandsanwendungen aufsetzen, klassisch gewachsenen Backend-Systemen in jahrzehntealten Programmiersprachen. Das allein hätte den Aufwand vielleicht verfünffacht, also rund 350.000 Euro. Selbst wenn die Anbindung jedes einzelnen der fünf großen Systeme eine Million Euro gekostet hätte, wären wir bei fünf Millionen gewesen. Wohin sind die restlichen 95 Millionen geflossen?

Die Antwort liegt nicht in der Technik allein. Jede der großen Bestandsanwendungen gehörte einem Unternehmensbereich und wurde von einer eigenen Abteilungsleitung verantwortet. Diese Führungskräfte verfolgten unterschiedliche Ziele und zogen nicht an einem Strang. Statt das Gesamtsystem von Grund auf neu zu bauen, wurde die App auf das Durcheinander der Altsysteme gesetzt. Der grenzüberschreitende Verkehr brachte weitere Schnittstellen zu internationalen Verbindungsdaten. Die Zahl der externen und internen Umsetzungsteams wuchs, mit ihr die Zahl der Interessen, und das machtpolitische Gefüge blockierte Entscheidungen, die technisch längst klar waren. Das Ergebnis ist eine überteuerte, fehleranfällige Anwendung, die nicht intuitiv zu bedienen und obendrein langsam ist.

Die Lehre daraus ist nicht, dass Apps teuer sind. Die Lehre ist, dass die Kosten eines Vorhabens nicht vom Neuen bestimmt werden, sondern vom Alten, auf dem es aufsetzen muss.

Hundertschaften, die das Alte am Laufen halten

Fast alle Banken stehen vor demselben Problem, nur in größerem Maßstab. Ihre softwaretechnischen Grundstrukturen sind veraltet, und statt sie zu erneuern, leisten sich die Institute IT- und Softwareabteilungen mit mehreren hundert Mitarbeiterinnen und Mitarbeitern, die um die alten Kerne herum neue Anwendungen bauen. Zur Führung dieser Abteilungen sind erfahrungsgemäß rund zehn Prozent mittlere und höhere Führungskräfte nötig; bei einer Softwareabteilung mit 700 Personen sind das 65 bis 75 Managerinnen und Manager. Für die Abstimmung mit den Fachabteilungen fallen jährlich hunderte Meetings an. Um einen grundlegend neuen Prozess zu starten, sind oft drei Jahre aufwendigster Arbeit erforderlich.

Dazu kommt der Widerstand der Anwenderinnen und Anwender. Menschen sind Gewohnheitstiere. Paradoxerweise haben viele ihre alte Software mit dem schwarzen Eingabefenster und den sperrigen Befehlen liebgewonnen und denken nicht daran, sich neuen Lösungen zu öffnen. In Summe ist das eine breite Masse, die großen Softwarevorhaben erheblichen Widerstand entgegensetzt, und in vielen Unternehmen ist sie in der Mehrheit.

Ein Detail macht die Dimension des Problems greifbar: Die wichtigsten Kernbankanwendungen eines Großteils der systemrelevanten Banken in Europa sind in COBOL oder verwandten Programmiersprachen aus den 1950er Jahren geschrieben. Die Technologie hinter COBOL beruht auf Lochkarten, und Lochkarten wurden historisch zur Steuerung mechanischer Webstühle entwickelt. Banken arbeiten in ihrem Innersten also mit einer mehrfach weitergeführten Technik, die auf Webstühlen beruht, und versuchen nach außen, über Datenbrille, WhatsApp, App, Website, Telefon und Schalter denselben modernen Omnichannel-Service zu bieten. Nach meiner Einschätzung im Buch verfügen bis heute etwa 80 Prozent aller Banken über diesen Altbestand. Dass damit keine hohe Agilität entsteht, ist leicht nachvollziehbar.

Technische Schuld: die Rechnung kommt immer

Für diesen Zustand gibt es einen präzisen Begriff: technische Schuld. Ob Gebäudetechnik, Fahrzeug oder Software: Jedes technische System, in das nicht laufend investiert wird, häuft technische Schuld an. Wer beim Auto die Services auslässt, spart kurzfristig und zahlt später den Motorschaden, weil die Schmierung gefehlt hat. Bei Software ist es nicht anders, nur unsichtbarer.

Als Faustregel gilt: Etwa 15 bis 20 Prozent des ursprünglichen Errichtungswerts einer Software müssen laufend in Verbesserungen und Erneuerungen fließen, in der Fachsprache Refactoring genannt, damit sich keine technische Schuld anhäuft. Diese Quote stammt aus unserer Erfahrung in Softwarestrategieprojekten und ist auch im Buch so beschrieben. Wird sie über Jahre auf null gesetzt, verschwindet die Schuld nicht. Sie wächst mit Zinsen und wird irgendwann fällig, entweder als Großprojekt zur Ablöse oder als Vorhaben wie die Ticket-App, dessen Kosten niemand mehr erklären kann. Vor allem im Softwarebereich haben viele Unternehmen bis hin zu großen Konzernen diese Regel über Jahrzehnte ignoriert. In ihrem „Bauch“ schleppen sie enorme technische Schuld in Form inhomogener Systeme mit sich.

Drei Beobachtungen aus unserer Praxis erklären, warum die Schuld so lange unbemerkt bleibt:

• Geschäftskritische Software lebt lange. Backend-Systeme haben in der Regel einen Lebenszyklus von 15 bis 20 Jahren; auch die großen ERP-Anbieter bringen etwa in diesem Rhythmus einen Generationswechsel heraus. Wer die Entscheidung zur Erneuerung aufschiebt, bindet sich damit leicht für weitere Jahre an den Altbestand, weil das nächste Zeitfenster erst mit dem nächsten Generationswechsel kommt.
• Projekte werden systematisch unterschätzt. Nach unserer Erfahrung werden über 80 Prozent der industriell gefertigten Softwareprojekte falsch geschätzt, meist liegen die Schätzungen 40 bis 50 Prozent unter dem tatsächlichen Aufwand. Werden Entscheidungsträgerinnen und Entscheidungsträgern vorab die richtigen Kosten kommuniziert, werden viele Projekte gar nicht erst begonnen, und der Altbestand bleibt.
• Software hat keine Plakette. Für nahezu jedes technische Gerät gibt es eine Prüfung nach Art des TÜV, für Software nicht, obwohl von ihr das Funktionieren ganzer Branchen abhängt. Während die Fahrzeuge im Fuhrpark die aktuelle Plakette tragen, laufen im Unternehmen Prozesse auf Software, die längst hoffnungslos veraltet ist. Weil das schon so lange so ist, fehlen in vielen Unternehmen Bewusstsein und Expertise dafür.

Sechs Barrieren und was ihnen entgegensteht

Alle Führungskräfte, mit denen ich spreche, wollen zu einem modernen Fundament. Kaum jemand ist bereit, den entscheidenden Schritt zu setzen. Die Gründe wiederholen sich von Unternehmen zu Unternehmen, und für jeden gibt es ein Gegenmittel.

Der vierte Punkt verdient einen Zusatz. Ein Business Case, der nur die Errichtung rechnet, ist unvollständig. Er muss Betrieb, Refactoring und die spätere Ablöse über den gesamten Lebenszyklus abbilden. Erst dann wird sichtbar, dass die vermeintlich günstige Variante, das Alte weiter zu überbauen, in Summe die teurere ist.

Erneuern statt überbauen

Im Buch habe ich die Konsequenz in einem Satz formuliert:

Der Weg zu den echten selbstfahrenden Unternehmen ist nur möglich, wenn diese veralteten Systeme radikal modernisiert werden.

Radikal heißt nicht unbedacht. Es heißt, die Kernprozesse auf eine Software zu setzen, die dem aktuellen Stand der Technik entspricht und in den nächsten 15 bis 20 Jahren Refactoring verträgt, statt weitere Schichten auf ein Fundament zu bauen, das niemand mehr durchschaut. Softwareroboter, die ich im Buch als Brückentechnologie eingeordnet habe, überbrücken die Übergangszeit, ersetzen den Neubau aber nicht.

Die Reihenfolge ist entscheidend. Im vorigen Beitrag dieser Serie habe ich gezeigt, wie automatisierte Softwaredokumentation Transparenz über ein Bestandssystem schafft. Diese Transparenz ist die Voraussetzung für die Entscheidung, was aus dem Altbestand in die Zukunft mitgenommen wird und was nicht. Erst wer sein Altsystem vollständig kennt, kann den Umfang der Erneuerung seriös schätzen, die Etappen planen und den laufenden Betrieb während des Umbaus absichern.

Warum passiert das trotzdem so selten? Weil das Top-Management in der Regel nicht über das technische Wissen verfügt, um die Lage zu beurteilen, und weil IT-Abteilungen, die über Jahre um ein Altsystem herum gewachsen sind, häufig eigene Ziele verfolgen. Nach meiner Erfahrung braucht es in fast allen Fällen eine unabhängige Beratung, die keine Lizenzen verkauft, keine Umsetzungsressourcen platzieren muss und eine klare Vorstellung davon hat, was ein Unternehmen mit einem modernen Fundament erreichen kann: ein intelligenter, lernender und reaktionsfähiger Gesamtorganismus, dessen Leistungsfähigkeit mit dem Altbestand schlicht nicht erreichbar ist.

Ich bin überzeugt, dass die Unternehmen, die in den kommenden Jahren ihre Kernsysteme erneuern, den anderen davonziehen werden. Nicht weil neue Software an sich ein Wettbewerbsvorteil wäre, sondern weil sich intelligente Software nur auf einem Fundament entfalten kann, das nicht selbst zum Komplexitätstreiber geworden ist.

Der nächste Schritt

Wie technische Schuld, Enterprise Architecture und kognitive Software im selbstfahrenden Unternehmen zusammenhängen, beschreibt das Buch „Das selbstfahrende Unternehmen“: Zum Buch. Wenn Sie vor der Frage stehen, ob Ihr Kernsystem weiter überbaut oder erneuert werden soll, klären wir in einem Gespräch, wie groß die angehäufte technische Schuld tatsächlich ist und in welchen Etappen sie sich abtragen lässt: Expertengespräch buchen.