Als erfahrene Software-Strategieberater wurden wir im Laufe der Jahre immer mit Lösungsansätzen konfrontiert, die selbst in großen und erfolgreichen Unternehmen überhaupt nicht zielführend sind. Ein besonders eindrückliches Beispiel dafür ist eine Ticket-App, die für ein Verkehrsunternehmen entwickelt werden sollte. Die Idee hinter diesem Prinzip war simpel: Die App sollte es ermöglichen, bequem und rasch mit dem Handy nach einer passenden Verbindung zu suchen und das Ticket mit einem Klick zu bezahlen. Das Ergebnis vorweg: Mehr als 100 Millionen Euro hat die App das Verkehrsunternehmen gekostet – während ein übliches Projekt zur Entwicklung einer solchen Anwendung bei gleicher Funktionalität mit rund 70.000 Euro dotiert ist. Wie kam es zu dieser gewaltigen Kostenexplosion?
Der Versuch, auf völlig veralteten Strukturen immer mehr Neues aufzubauen
Aufgrund der jahrzehntelang gewachsenen vorhandenen Systeme war dieses Projekt mit einer besonders hohen Softwarekomplexität konfrontiert. Das neue System musste über fünf große und unzähligen kleine alten Softwarelösungen aufgebaut werden. Das allein wäre noch mit einem überschaubaren Aufwand zu bewältigen: Es würde etwa das Fünffache der üblichen Kosten verursachen, also etwa 350.000 Euro. Selbst wenn die Anbindung der App an nur eine dieser großen alten Software-Systeme rund eine Million Euro gekostet hätte, wären es in Summe „nur“ fünf Millionen Euro – also immer noch weit von den 100 Millionen entfernt. Wohin sind also all die anderen Millionen geflossen? Wie kann ein im Grunde simples Softwareprojekt so extreme Kosten verursachen?
Der Komplexitätstreiber in diesem Projekt waren vor allem die alten Software-Anwendungen. Dazu kamen widerstrebende Bedürfnisse und Vorstellungen der einzelnen Abteilungsleiter des Unternehmens. In dem Transportunternehmen wurden mehrere Software-Anwendungen parallel eingesetzt, dabei handelte es sich um klassische, veraltete Backend-Systeme, die mittels jahrzehntealten Programmiersprachen entwickelt wurden. Zusätzlich erhöhte die Notwendigkeit für die App, bei der Routenplanung den grenzüberschreitenden Verkehr in die App einzubeziehen die Komplexität, da zudem alle Daten der internationalen Verkehrsverbindungen berücksichtigt werden mussten und somit zusätzliche Schnittstellen erforderlich wurden.
Jede dieser großen alten Software-Anwendungen wurde einem Bereich des Unternehmens zugeordnet und lag in der Verantwortung eines Abteilungsleiters. Diese Führungskräfte verfolgten jedoch unterschiedliche Ziele und zogen damit nicht an einem Strang. Anstatt konsequent ein komplettes System von Grund auf neu zu erstellen, musste die Ticket-App auf einem Durcheinander bestehender Alt-Software aufgebaut werden. Neben dem daraus resultierenden enormen Integrationsaufwand blockierte auch das politische Machtgefüge der einzelnen Abteilungen viele sinnvolle Entscheidungen im Projekt. Die Größe des Vorhabens, die Komplexität der technischen Lösung und die Vielzahl unterschiedlicher externer und interner Umsetzer sowie deren unterschiedliche Interessen verursachten schließlich diese extremen Kosten. Das Ergebnis des Projekts: eine hoffnungslos überteuerte und dazu noch fehleranfällige App, die intuitiv schlecht zu bedienen und noch dazu langsam ist.
Enormer Personalaufwand, um die Altsysteme am Laufen zu halten
Fast alle Banken haben ebenfalls bis heute das gleiche Problem wie das Transportunternehmen: Die Softwarestrukturen sind sehr veraltet, werden aber nicht grundlegend erneuert. Denn diese Unternehmen können es sich ebenfalls leisten, dass IT-Abteilungen mit mehreren hundert Mitarbeitern laufend neue Anwendungen um diese uralten Legacy-Systeme herum zu basteln. Um diese Hundertschaften von Mitarbeitern zu führen, werden zudem etwa 10 % des mittleren und oberen Managements benötigt, zu einer Softwareabteilung mit 700 Personen kommen also auch 65–75 Manager. Damit sich die einzelnen Fachabteilungen untereinander abstimmen, sind jährlich hunderte Meetings nötig. Für den Start eines grundlegend neuen Prozesses sind oft drei Jahre mühsamer Arbeit und damit extreme Kosten erforderlich.
Hinzu kommt oft erheblicher Widerstand der Nutzer: Denn Menschen halten eisern an ihren Gewohnheiten fest. Paradoxerweise sind sie verliebt in ihre hoffnungslos veraltete Software mit dem DOS-Eingabefenster und sperrigen Befehlen. Sie schaffen es nicht, loszulassen und sich gegenüber neuen Lösungen zu öffnen. In Summe sind diese Leute in vielen Unternehmen die überlegende Mehrheit und großangelegte Softwareprojekte werden abgelehnt.
Anhäufung gewaltiger Kosten für die Erneuerung
Der Weg zum Selbstfahrenden Unternehmen kann nur eingeschlagen werden, wenn diese veralteten Systeme radikal beseitigt werden. Die Beispiele haben gezeigt: Der Versuch, den alten Bestand zu überbauen verursacht auf Dauer weitaus höhere Kosten als eine Erneuerung der kompletten Software. Es werden zwar neue Firmengebäude errichtet und ganze Fuhrparks ersetzt – aber bei der Software, genau dort, wo die Innovation am raschesten voranschreitet soll gespart werden, das „bewährte Alte“ soll erhalten bleiben.
Hier trifft der Begriff „technische Schuld“ den Punkt. Ob Gebäudetechnik, Fahrzeuge oder Software: Jedes technische System, in das nicht regelmäßig investiert wird, vermehrt technische Schuld. Wenn unser Auto nicht regelmäßig serviciert wird, müssen wir bald mit weit höheren Reparaturkosten rechnen, weil wir damit z. B. einen Motorschaden verursacht haben. Generell kann davon ausgegangen werden, dass etwa 15–20 % des Ausgangswertes eines Software-Projektes in laufende Erneuerungen und Verbesserungen – im Fachjargon „Refactoring“ genannt – investiert werden müssen, damit sich keine technische Schuld anhäuft. Geschieht dies nicht, wird diese Schuld immer höher. Irgendwann muss sie jedoch bezahlt werden. Gerade in der Softwarebranche haben viele Unternehmen, auch Großunternehmen, in den letzten Jahrzehnten diese Tatsache ignoriert. Sie schleppen sich mit einer enormen technischen Schuld in ihrem „Bauch“ immer mühsamer vorwärts.
Ein weiteres Detail aus dem Bankensektor: Die wichtigsten Kernprozesse mehrerer systemrelevanter europäischer Banken werden seit den 1950er Jahren in der Programmiersprache COBOL oder verwandten Sprachen geschrieben. Die Technologie hinter COBOL basiert auf alten Lochkarten, einfachen Programmen, die historisch entwickelt wurden, um Webstühle zu steuern. Banken arbeiten in ihrem Innersten mit der Weiterentwicklung eines Systems, das letztlich auf alten mechanischen Webstühlen basiert – nach außen versuchen sie, weltoffen, modern und nach dem Omnichannel-Prinzip aufzutreten und ihre Leistungen nach Wunsch mit Datenbrille, WhatsApp, mobile Apps, Website, Telefon oder vor Ort anzubieten. Bis heute laufen in etwa 80 % aller Banken diese Altsysteme. So ist es nachvollziehbar, dass damit angesichts enorm steigender Datenmengen keine hohe Agilität erreicht werden kann.
Der Weg in die Zukunft kann daher nur erfolgreich beschritten werden, wenn dieses Fundament komplett erneuert wird. Alle Top-Führungskräfte wollen zwar dorthin gelangen – doch aktuell ist niemand bereit, die dafür erforderlichen radikalen Maßnahmen zu veranlassen.
Barrieren beseitigen und den Blick auf ungeahnten Nutzen richten
Abgesehen von den veralteten Kernprozessen sind auch viele weitere Funktionen, die heute längst Standard sein sollten, in vielen Unternehmen überhaupt nicht oder nur eingeschränkt möglich. So sollte es z. B. schon lange selbstverständlich sein, alle Kundeninteraktionen im gesamten Unternehmen zu kennen und rasch und zielgenau darauf reagieren zu können. Warum dies nicht funktioniert, beruht ebenfalls auf dem Festhalten an alter Software:
- Aufgrund der extremen technischen Schuld besteht enorme Angst, dass das Softwareprojekt scheitert. Die Vermeidung von Misserfolg verhindert damit einen großen und vor allem nachhaltigen Erfolg, den so ein Projekt versprechen kann.
- Während des Umbaues muss dennoch der laufende Betrieb des Unternehmens sichergestellt werden. Dies schürt ebenfalls Unsicherheit, ist aber bei professioneller Planung absolut möglich.
- Die Abteilungen verfolgen keine einheitliche Strategie, weisen unterschiedliche Interessen auf. Oft werden diese Interessen aus taktischen Gründen nicht offengelegt, damit liegt keine einheitliche Basis für die durchgängige Planung des Projekts vor. Von Beginn an ist damit klar zu kommunizieren, dass der Erfolg nur bei völliger Transparenz und Ausrichtung auf die übergeordneten Unternehmensziele gewährleistet werden kann.
- Der Projektaufwand wird zu niedrig eingeschätzt, das bringt die Projekte bereits zu Beginn ins Wanken und erhöht die Unsicherheit. Mit professionellen Methoden der Aufwandsschätzung kann dieses Problem beseitigt werden, z.B. mit den sogenannten „Story Points“, die von erfahrenen Experten auf Basis von Erfahrungswerten zur Bewertung komplexer, agiler Softwareprojekte eingesetzt werden.
- Bei den scheinbar hohen Kosten werden die langfristigen weitaus höheren langfristigen Einsparungen nicht mitkalkuliert. Diese resultieren vor allem aus der weitaus höheren Performance, wie auch aus der Tatsache, dass der gewaltige Wartungsaufwand für diese Systeme enorm reduziert wird.
- Die vielen weiteren Nutzeneffekte der neuen Software werden zu wenig erkannt: Bessere Marktbearbeitung, Neukundengewinnung, Kundenbindung, Mitarbeiterentlastung, Fehlerreduktion, Konkurrenzvorteile etc.
Zusammenfassend kann gesagt werden, dass es auf dem Weg zum Selbstfahrenden Unternehmen unerlässlich ist, sich radikal von der alten Software zu verabschieden und vor allem die Kernprozesse auf eine neue, den aktuellen technischen Standards entsprechende und zukunftsfähige Software aufzusetzen. Da das Top-Management dazu meist nicht das technische Know-how aufweist und die IT-Abteilungen oft eigene Ziele verfolgen, bedarf es hier in fast allen Fällen einer profunden Beratung durch erfahrene wie auch vorausschauende Profis, die eine klare Vision von den faszinierenden Möglichkeiten eines solchen intelligenten, selbstlernenden und reaktiven Gesamtorganismus mit nie dagewesener Performance haben.
