Cloud-Migration – mal erfolgreich, mal wirtschaftliches Disaster Scheiternde IT-Projekte

Der Erfolg eines IT-Projektes ist keineswegs garantiert: bestes Beispiel aktuell die Postbank. Die Liste der aufgegebenen Vorhaben ist lang. Aber Scheitern ist nicht gleich Scheitern. Wir nennen die spektakulärsten Fälle und welche Lehren daraus gezogen werden können.

Die Einführung einer neuen Software in einer Firma ist ein Graus. Jeder, der das einmal mitgemacht hat, wird das bestätigen. Der „Faktor Mensch“ spielt dabei ganz offensichtlich eine große Rolle – es ist für Mitarbeiter einfach mühselig, neue Oberflächen und Abläufe zu lernen. Trotzdem muss alle paar Jahre ein neues Programm – für die Warenwirtschaft, die Produktion, das Personalmanagement, was auch immer – implementiert werden, mittlerweile kommt das ja alles in bzw. aus der Cloud. Andernfalls würden Anwender im Hinblick auf die allzeit wachen Wettbewerber ins Hintertreffen kommen – und die Anbieter und ihre Partner nichts verdienen.

Aber der Erfolg eines IT-Projektes ist nicht garantiert. Im Gegenteil: Die Liste der gescheiterten Vorhaben ist lang – aber nicht dramatisch. Laut einer neuen Untersuchung des Project Management Institutes wird es sogar immer besser: Immer mehr Projekte erfüllen die ursprünglichen Ziele und Geschäftsabsichten und werden innerhalb des Budgets abgeschlossen. Auch die Zahl der verlorenen Investitionen sei deutlich zurückgegangen: Für jede investierte Milliarde US-Dollar verschwenden Unternehmen durchschnittlich 97 Millionen US-Dollar aufgrund schlechter Projektleistung – das ist laut Berechnungen des Instituts von Ende 2023 ein Rückgang um 20 Prozent im Vergleich zum Vorjahr.

Durchaus erfreulich, festzuhalten gilt aber dennoch, dass jede Menge IT-Projekte scheitern, verlässliche (!) Zahlen sind dazu jedoch nicht erhältlich – kein IT-Manager profiliert sich mit einem Misserfolg, daher fällt die Kommunikation darüber leise aus. Aktuelle und wohlbegründete Schätzungen zu Totalausfällen bewegen sich zwischen 14 und 50 Prozent, in vielen Fällen geht es aber auch nur darum, dass Ziele nicht erreichen, Budget überzogen oder Deadlines nicht eingehalten wurden.

Wann gilt ein Projekt als gescheitert?

Scheitern ist relativ. Während die einen ein Projekt noch bejubeln, haben sich viele andere davon schon entnervt abgewandt, exemplarisch werden wir das weiter unten anhand der Postbank sehen. Abgesehen von finalen Indikatoren wie der Einsturz eines Gebäudes, gerne durch Naturkatastrophen, oder Pleiten inklusive Geschäftsaufgabe gibt es ein, zwei Handvoll eindeutiger Indikatoren, die das Scheitern eines IT-Projektes unzweideutig anzeigen:

• 1. Das Ziel des Projektes ist obsolet geworden.

• 2. Das Ziel des Projektes erfüllt die Anforderungen nicht mehr, ein Weiterverfolgen würde nur sinnlos Geld verbrennen.

• 3. Die Kosten sind so aus dem Ruder gelaufen, dass die weitere Finanzierung nicht mehr machbar ist oder das Projekt auch nicht mehr retten wird.

• 4. Äußere Umstände stoppen das Projekt – das sind nicht nur die genannten Naturkatastrophen, sondern könnten auch aus Politik oder Wirtschaft stammen.

• 5. Das Projekt ist rechtlich nicht weiter tragbar, z.B. wenn Klagen dagegen erfolgreich sind.

• 6. Unüberbrückbare Konflikte innerhalb des Projektteams oder mit dem Auftraggeber.

• 7. Das Personal ist weggelaufen – ITler aller Colour werden händeringend gesucht, allen voran Programmierer – die können sich also schnell einen neuen Arbeit- bzw. Auftraggeber suchen, sollte ein Projekt unzumutbar werden.

Nicht selten werden IT-Projekte als „gescheitert“ erklärt, weil die Kosten aus dem Ruder gelaufen sind. Das ist aber eigentlich eher die Regel – sofern neu entwickelte Systeme laufen, sollten sie auch als erfolgreich betrachtet werden. Gescheitert sind dann nur eben die Finanzpläne.

Liste mit Beispielen

All diese Gründe für Projektabbrüche finden sich in den vielen Beispielen dafür. Hier eine kleine Liste mit schweren IT-Havarien in Deutschland aus den vergangenen zehn Jahren:

Im Dezember funkte der Bundesrechnungshof SOS: der Deutschen Rentenversicherung stehe eine IT-Katastrophe ins Haus. Bis Ende 2023 hätten eigentlich sämtliche IT-Verfahren der DSRV auf eine neue Plattform gehoben werden müssen. Konkret geht es darum, im Dezernat „IT-Betrieb“ am Standort Würzburg die gesamte IT-Infrastruktur und sämtliche in der Regel in Cobol gefassten IT-Verfahren sowie zentrale Dienste für die 25 Millionen Rentenversicherte und deren Träger von Mainframes in die Cloud zu verlagern. Seit Jahren sucht die Behörde daher nach Cobol-Spezialisten, die auch firm in Ansible, Kubernetes und Podman sind. Eierlegende Wollmilchsäue sind häufiger anzutreffen. Deswegen ist man laut Bundesrechnungshof auch weit von einer Umsetzung entfernt, das Projekt habe sich an vielen Stellen verzettelt. Und das, obwohl bereits 2022 ein erstes, ursprüngliches Projekt gestoppt und als „Multiprojekt DSRV.move“ neu angegangen worden war.

Aber wir greifen vor: Gescheiterte IT-Projekte gibt es seit den Anfängen der Datenverarbeitung. 2017 teilte die Bundesagentur für Arbeit den Stopp ein 2010 gestartetes Software-Projekt mit Titel ROBASO (Rollenbasierte Oberfläche) mit, das 14 verschiedene eigene Anwendungen auf einer Plattform bündeln sollte. Verbraten wurden rund 60 Millionen Euro.

2018 startete die Allianz SE Versicherungsgruppe zusammen mit Microsoft den „Syncier Marketplace“ als Projekt. Ziel war eine quelloffene, cloudbasierte Versicherungsplattform inklusive eines Marktplatzes für entsprechende Softwarelösungen. Das Gesamtpaket sollte auch anderen Versicherungen angeboten werden. Diesen Plan gab die Allianz 2022 endgültig auf, es lagerte das mittlerweile Apinity genannte Projekt als GmbH aus und verkaufte es inklusive seiner 30 Mitarbeiter plus der „API Business Operations Plattform“ zu einem unbekannten Preis an die Munich Re.

Die Allianz hat viele Projekte am Laufen, was erklärt, warum Apinity nicht ihr einziger Software-Flopp war: Mit Heymoney sollte eine eigene Multibanking-App für Endanwender entwickelt werden. 2022 wurde ihr Ende verkündet, weil sich nicht genügend Nutzer fanden. Zumindest war das Projekt nicht gescheitert, nur das Umsatzmodell dafür.

Telefónica Deutschland gründete 2016 die Telefónica Germany Next GmbH, die Anwendungen für Big Data und das IoT erstellen sollte. Dafür kaufte man sogar den Analytics-Experten Minodes hinzu. 2019 wurde jede Arbeit eingestellt, eine IoT-Plattform namens Geeny komplett verworfen.

Auch die Deutschland Cloud ging an mangelndem Interesse der Anwender ein. Microsoft und T-Systems hatten sie 2015 gestartet, um Kunden mit besonders strengen Compliance-Richtlinien bedienen zu können. Mittlerweile gibt es wenigstens ein Dutzend vergleichbarer Modelle, das Original aber wurde 2022 abgeschaltet. Aber auch hier wurde das Projekt im Grunde voll durchgezogen, es hatte nur keinen wirtschaftlichen Erfolg.

Die Deutsche Post DHL stoppte ihr Transformationsprojekt New Forwarding Environment (NFE) 2016, in dem die SAP zusammen mit der IBM individualisierte SAP-Module einführen hätte sollen. Summa summarum dürfte sich die „Entwicklungshilfe“ dafür auf 500 Millionen Euro belaufen haben.

Spezialfall SAP

Naturgemäß geht es in Deutschland in Sachen ERP oft um den Wechsel eines oft jahrzehntealten SAP-Systems – gerne R/3 – auf SAP S/4HANA. Der muss erfolgen, weil die SAP ältere Versionen ab 2027 nicht mehr unterstützen will. Leider müssen SAP-Projekte auch mal abgebrochen werden. Das ist den Walldorfern nicht vorzuwerfen – bei 100.000en von Kunden findet sich schon mal das eine oder andere fehlgeschlagene Vorhaben, manche davon prominent:

Der Otto-Versand musste 2012 eine 2009 gestartete SAP-Einführung mit dem Namen „Passion for Performance“ wieder einstampfen. Da lief es bei Edeka besser: Ab 2007 versuchte er auf SAP umzusteigen. Das Projekt „Lunar“ sollte 200 Millionen Euro kosten, zum Schluss im Jahr 2012 waren es 350 Millionen Euro. Immerhin war es nicht gescheitert. 2018 stoppte Lidl nach sieben Jahren die Einführung des Warenwirtschaftssystems „Elwis“, ein auf den Discounter zugeschnittenes ERP-Gesamtsystem. Auch hier sollen 500 Millionen Euro verbrannt worden sein.

Jüngstes Beispiel: Postbank

Ein weiteres „schönes“ Beispiel dafür, wie holperig IT-Projekte geführt werden, ist die Integration der 2010 übernommenen Postbank in die Deutsche Bank. Diese beauftragte 2012 die SAP damit, beide IT-Systeme auf eine gemeinsame Plattform zu migrieren. Projekt „Magellan“ wurde aber schon 2015 wieder eingestellt, weil die Deutsche Bank ihre junge Tochter wieder verkaufen wollte. Projektkosten bis dahin: 1,6 Milliarden Euro. Drei Jahre später wurde der Verkauf abgeblasen und ein neuerliches Integrationsprojekt mit Namen „Unity“ ins Leben gerufen.

Das Projekt ist eines der „größten jemals durchgeführten IT-Projekte einer Bank in Deutschland“ – und treibt aktuell viele der etwa zwölf Millionen Postbank-Kunden in den Wahnsinn. Der Umzug von bislang etwa 15 der 19 Millionen Produktverträge auf die IT-Plattform der Deutschen Bank lief alles andere als reibungslos, viele Services fallen genauso wie Geldautomaten der Bank immer wieder aus. Die Verbraucherzentrale Bundesverband (Vzbv) verzeichnete seit Jahresbeginn bis zum 23. Oktober 2023 rund 1.700 Beschwerden. Bis Mitte des Jahres sollen die Anwender ihre Accounts wieder störungsfrei nutzen können, sagt die Postbank. Das hat sie allerdings vor einem Jahr auch schon behauptet.

„Was die Postbank angeht, bin ich wirklich erschlagen – wie so viele“, berichtet exemplarisch eine langjährige Postbank-Kundin, die selbst viele Jahre als IT-Expertin für einen internationalen IT-Konzern gearbeitet hat und die Herausforderungen der ITK aus dem „ff“ kennt, gegenüber CloudComputing-Insider. Gestörte Transaktionen haben sie bereits mehrmals in Nöte gebracht, viele davon sind ja überlebensnotwendig, etwa im Falle der Kommunikation mit der Krankenkasse. Genau diese Störungen lassen sie aber auch auf dem System der Postbank verharren – eine unvollständige oder gar gescheiterte Verlagerung des Hauptkontos zu einer neuen Bank würden viele neue Unannehmlichkeiten bedeuten. „Schuld ist aber meines Erachtens die Muttergesellschaft der Postbank, die auf Teufel komm raus zwei historisch unterschiedlich gewachsene IT-Systeme vereinen will“, so die Expertin. Unterschiedliche Hardware und Software und vor allem verschiedene organisatorische Begrifflichkeiten seien kaum zu vereinbaren, so werde z.B. das „Limit“ für ein Konto plötzlich als „Verfügungsrahmen“ bezeichnet.

Kein typisch deutsches Problem

Nun könnte man sagen: Typisch deutsch, nichts klappt mehr. Damit würden wir uns aber selbst Unrecht tun: Gescheiterte IT-Projekte gibt es in jedem Land, exemplarisch seien einige aus der Schweiz genannt, einem Land, dem ansonsten Erfolg und Präzision nachgesagt wird:

• 2005 stellt der Schweizer Bund nach vier Jahren Arbeiten und Investition in Höhe von 18 Millionen Franken die Arbeit an einem virtuellen Amtsschalter auf dem Behörden-Informationsportal www.ch.ch wieder ein.

• 2012 stoppte das Schweizer Bundesamt für Umwelt (BAFU) das Informatikprojekt Datenzugang für Umweltdaten (DaZu). 6,1 Millionen Franken waren bis dahin geflossen.

• 2013 wird ein neues System für die veraltete Telefon- und Internet-Überwachung wieder zurückgezogen und ein neuer Anbieter engagiert. Dem Alten werden noch 18 Millionen hinterher geworfen.

• 2015 muss das Staatssekretariat für Wirtschaft (SECO) das IT-Projekt ASALneu anhalten, ein Update des Auszahlungssystems der Arbeitslosenversicherung. Der Schaden belief sich jedoch nur auf ein paar hunderttausend Franken.

Ohne Zweifel ließe sich für jedes Land dieser Welt eine ähnliche Liste erstellen.

Gegenbeispiele

Aber seien wir ehrlich: Nicht alles ist schlecht. Tatsächlich finden sich auch in Deutschland durchaus Beispiele für erfolgreich umgesetzte IT-Projekte, und zwar nicht zu knapp. Hier zwei Beispiele, die einen schweren Start hatten:

2019 machte der Mineralölspezialist Liqui Moly lautstark seinem Ärger über eine angeblich gescheiterte Einführung der ERP-Software Microsoft Dynamics 365 for Finance and Operations (früher: Dynamics AX) Luft. Die schlechte Performance des neuen Systems habe sogar zu einer Gewinnwarnung geführt. Tatsache ist, dass das Projekt nicht wirklich gescheitert war, das System wurde seitdem verbessert und arbeitet weiter. Auch muss man wissen, dass das Altsystem von Liquid Molly stark individualisiert, in Cobol geschrieben und auf IBM AS400-Mainfames betrieben wurde.

Mit viel Häme und Geraune wurde das Projekt Herkules begleitet, es sollte ab 2006 die ITK der Bundeswehr auf den neusten Stand bringen. Trotz aller Unkenrufen speziell zu Beginn wurden tatsächlich in zehn Jahren insgesamt 140.000 Arbeitsplätze, 7.000 Server, 300.000 Festnetz- und 15.000 Mobil-Telefone an 1.500 Standorten auf ein gemeinsames System gehoben.

Bitkom-Hauptgeschäftsführer Bernhard Rohleder erklärte denn auch: „Die allermeisten IT-Projekte der öffentlichen Hand gelingen.“ Als weitere Beispiele nannte er dafür etwa die elektronische Steuererklärung Elster oder den elektronischen Personalausweis.

Gründe für das Scheitern

Im Nachhinein weiß man immer alles besser – das gilt auch bei den Gründen für gescheiterte IT-Projekte. Deren Liste ist lang: Mangelhafte Planung inklusive ungenauer Zielsetzung und ungenauen Rollen & Verantwortlichkeiten, Interessenkonflikte von maßgeblichen Beteiligten, Abhängigkeiten von Zulieferern, fehlende oder ineffiziente Ressourcen, zu optimistische Budget- und Zeitschätzungen, Ziel- und Richtungsänderungen während des laufenden Projektes, Kooperationsverweigerung der Mitarbeiter und das Ausschluss-Kriterium Nummer 1: schlechte Performance des entstandenen Systems.

Gelegentlich hört man hinter vorgehaltener Hand auch von überforderten Projektleitern, denen dann in der Regel die Erfahrung fehlt. So kommen dann unerprobte Verfahren oder prekäre Infrastrukturen zum Einsatz. Nicht selten sind auch große Kommunikationsprobleme, die dann letztlich ein Projekt scheitern lassen.

Das Ziel der allermeisten Neuprojekte liegt irgendwo in der Cloud. Die ist aber kein Allheilmittel, gibt Roman Seeberger, Berater und Partner bei B-4it, zu bedenken: „Zugegeben, die Heilserwartung, die in Unternehmen einer Cloud-Lösung entgegengebracht wird, ist zu einem großen Teil durch die überzogenen Versprechen der Hersteller geweckt worden“, so der Analyst. „Das Problem hierbei: Cloud-Lösungen – egal welche – garantieren nicht die automatische, reibungslose und harmonische Integration aller Prozesse, nachdem man die Software installiert hat. Um zu verstehen, warum das so ist, muss man wissen, dass Cloud-Lösungen konfigurierbar und adaptierbar an die Notwendigkeiten des Unternehmens sind und auch sein müssen.“

Doch wenn die meist hohen Investition die hohen Erwartungen an die Cloud nicht erfüllen, würde oft gleich der gesamte Digitalisierungsprozess in Frage gestellt und an und für sich nützliche Projekte „auf hold“ gesetzt. „Um diesem Fail entgegenzuwirken, muss im Projektvorgehen ein gezielter Wissensaufbau für Projektbeteiligte erfolgen und systemarchitektonische Fragestellungen wie die Integration des Cloud-Systems in unternehmenskritische Prozesse – z. B. Personalabrechnung – klar gesetzt und betrachtet werden“, so Seeberger.

Wie geht es besser?

Wenn das Kind nun aber in den Brunnen gefallen ist, die Abnahme eines Projektes nach §§ 631 ff. BGB also verweigert wurde – mit was müssen die Beteiligten dann rechnen? An allererster Stelle mit einer Klage auf Schadensersatz (§§ 281, 280 BGB). Für deren Erfolg muss der Auftraggeber beweisen können, dass eine Vertragspflicht verletzt wurde.

Abgesehen von dieser unangenehmen Begleiterscheinung drängt sich auch ein Realitätscheck auf, um künftige Projekte erfolgreicher zu gestalten. Der Bitkom hat dafür „Kriterien für gute Projekte“ erarbeitet:

• Wirkketten und Muster sind häufig nicht linear: Sensibel bleiben für Wechselwirkungen und

• systemisch denken.

• Kraftausdrücke und Chaka-Sätze sollten Alarmwirkung haben. Häufig kommen solche

• „Feuerwehrmodus“-Situationen dann, wenn die PM-Hausaufgaben nicht gemacht wurden.

• Silodenken aufbrechen, denn es braucht mehr als einen Fan und Mentor für ein erfolgreiches Projekt.

• Fokus auf die Wirkung des Projektes und nicht den Weg.

• Agile Methoden allein sind kein Heilsbringer, und Scrum ist „nur“ ein Framework.

• Herausforderungen müssen umgehend und klar angesprochen werden.

• Kommunikation zwischen den Beteiligten muss auch außerhalb des Projekts erfolgen.

„Wenn Fehler ignoriert werden, Kommunikation nicht stattfindet oder während des Projekts die Anforderungen geändert werden, ohne auf die Folgen zu schauen, dann ist das Scheitern vorprogrammiert“, fasst der Arbeitskreis Projektmanagement des Bitkom die Ergebnisse eines entsprechenden Mitgliedertreffens zusammen. Das Motto desselben lautete „Heiter Scheitern!“

(ID:49976603)