Wohl noch nie hat sich einer der weltweit wichtigsten Software-Produzenten dermaßen gründlich blamiert wie eben jetzt die SAP. Was geschah?
Mitte 2006 vergab der Staat Kalifornien ein Projekt, dessen Inhalt es sein sollte,
das damals schon 30 Jahre alte staatliche Payroll System auf SAP-Basis neu zu implementieren.
Solche Neuentwicklung sollte das Problem beseitigen, dass kaum noch Programmierer zu finden waren, die die alte Technologie gut genug verstanden, volle Funktionsfähigkeit der Anwendung auf Jahre hinaus zu garantieren.
Nachdem der ursprüngliche Auftragnehmer, damals BaringPoint, nach 3 Jahren – pikanterweise erst zum geplanten Projektende-Termin (!) — eingestehen musste, dass man mit einer Neuimplementierung dieser Anwendungs hoffnungslos überfordert war, wurde das Projekt ein zweites Mal begonnen: jetzt aber, um wirklich sicher zu sein,
- mit SAP als Auftragnehmer
- und unter der Nebenbedingung dass zunächst mal in einer Pilotphase nur ein ganz kleiner Teil der Anwendung – weniger als 5 Prozent der gesamten Funktionalität – entwickelt und in Betrieb genommen werden sollte.
Schon diese Pilotphase aber ging so gründlich daneben, dass auch SAP – d.h. der für Systeme dieser Art wohl kompetenteste Entwickler weltweit (!) – im Januar 2013 gefeuert werden musste.
Wie gründlich die SAP versagt hat geht hervor aus einer eben erst (Feb 13, 2013) herausgegebenen Pressemitteilung des State Controller Office (SCO), das als Auftraggeber fungiert. Man liest dort u.A.:
One fact is particularly troubling with respect to SAP’s lack of progress:
The pilot phase only covers 1,300 SCO employees and two bargaining agreements with fairly simple payroll requirements. After eight months and little progress, the SCO cannot responsibly proceed to the second phase and expose thousands more State employees to payroll errors.
Nor can the SCO have any confidence that SAP can scale the failed system to cover the State’s 240,000 employees, operating out of 160 different departments, under 21 different bargaining units.
The errors in the SAP system affect everyday lives: Not only have SCO employees been paid too much, or too little, they and their family members also have been denied medical services despite paying for the insurance coverage. Payments to the State’s dental, vision and deferred compensation partners have been incorrect and delivered late. Improper deductions have been taken, payments have been made to the wrong payee, payroll and pensionable wages have been incorrectly calculated, and union deductions incorrectly determined.
To stabilize payroll for its employees, the SCO is rolling back its 1,300 employees to the legacy system that is currently and reliably paying all other 240,000 State employees.
Projektstand 2013 also:
Fast 7 Jahre nach der ersten Auftragsvergabe
- Ist das ursprüngliche Budget von 70 Mio. USD schon um etwa das 4-fache überschritten,
- und man ist zurückgeworfen auf den allerersten Schritt (der jetzt darin besteht, nun schon zum dritten Mal einen geeigneten Auftragnehmer finden zu müssen).
Nachtrag (June 2016): Das Projekt endete vor Gericht mit einem Vergleich, worin SAP sich bereit erklärt hat 59 Mio USD an SCO als Auftraggeber zurückzuzahlen und zudem auf die eigene Forderung von 23 Mio USD zu verzichten.
Unterm Strich hatte der Staat bis dahin, ohne irgend ein brauchbares Ergebnis, schon 250 Mio USD ausgegeben.
Sogar noch 2019 – genau 20 Jahre, nachdem man zum ersten Mal Geld bereit gestellt hatte, das Altsystem zu ersetzen (damals 1 Mio USD) – ist nicht klar, wie und wann das denn nun endlich gelingen könnte. Nach Tarifverhandlungen den Bediensteten die Gehaltserhöhungen ohne mehrere Monate Verzug auszuzahlen, wird immer schwieriger (May 2017). Im Oct 2018 sprach man von “over 425 identified issues and opportunities”, die es durch Abänderung der Software zu adressieren gelte.
Wer jetzt denkt, dieses Beispiel sei ein einmaliger Ausrutscher, also eher nicht typisch, wird durch andere Beispiele schnell eines Besseren belehrt:
- Beispiel 1: Noch glimpflich abgegangen ist das New York CityTime Projekt, wo es ebenfalls um die Modernisierung eines Payroll Systems ging: The New York CityTime project was planned in 1998 to cost around $63 million and take five years to complete.Tatsächlich fertiggestellt wurde es – einer ganz offensichtlich viel zu wenig kompetenten Entwicklungsmannschaft wegen – erst im Sommer 2011 mit einer Überschreitung des ursprünglich geplanten Projektbudgets von sage und schreibe um gut das 12-fache.
- Beispiel 2: In Australien endete 2010 ein Payroll System Projekt in einer absoluten Katastrophe: “Thousands of nurses were overpaid, underpaid or not paid at all when IBM rolled out its faulty system in March 2010.” Mit dafür verantwortlich war absolut unprofessionelles Projektmanagement auf Seiten des Auftraggebers.Auch dieses Beispiel ist Beweis dafür, dass Arbeiten für den Entwurf von Software — und ganz besonders auch die für den Test von Software — heute kaum professioneller erledigt werden als noch zu Zeiten der Softwarekrise Ende der 60-iger Jahre.
- Beispiel 3: Im November Ende 2012 kommt es zum Eklat über ein von IBM völlig unprofessionell angegangenes Projekt, in dem der Auftraggeber dem Auftragnehmer (IBM) vor Gericht zerrt mit der expliziten Anschuldigung, er habe zur Entwicklung des unternehmenskritischen Systems inkompetente Entwickler eingesetzt und sich lange Zeit geweigert, das zuzugeben.Schließlich hätten sogar IBM-Mitarbeiter das, was dort entstand und in Betrieb genommen wurde, die schlechteste SAP-Implementierung genannt, die sie je gesehen hätten.
Zum endgültigen Bruch mit dem Auftraggeber (Avantor) kam es, nachdem IBM ihm einer Problembehebung wegen zumuten wollte » to cancel every pending order and reset the entire System in light of pervasive warehouse problems. IBM said this was necessary to discover the root cause of the problem. Ultimately, IBM acknowledged that it had to engage in extensive remedial efforts to redesign and rebuild the System that Avantor hired it to deliver. « (Quelle: Avantors Aussage).
- Beispiel 4: 2015 liefern SAP und IBM der Deutschen Post ein System, welches sich als nicht gebrauchsfähig herausgestellt. Entstandener Schaden: 345 Mio Euro.
- Beispiel 5: How a Screwed-Up SAP Implementation Almost Brought Down National Grid
Fragen wir uns deswegen:
- Wie kommt es, dass es so extrem schwierig erscheint, mit der heute zur Verfügung stehenden (sehr ausgereiften) Technologie zu erreichen, was man mit längst überholter doch schon mal erreicht hatte: z.B. funktionstüchtige Payroll oder Order Management Systeme zu bauen?
- Muss man da nicht glauben, dass moderne Projektteams einfach nicht mehr systematisch genug arbeiten?
Dieser schlimme Verdacht liegt wirklich nahe, und Ursache solcher Mängel könnte gut sein, dass junge Software-Entwickler heute glauben, UML, SCRUM und Agiles Vorgehen (missverstanden im Sinne des Agile Manifesto) seien der Weisheit letzter Schluss.
Nur ältere Kollegen — solche mit Erfahrung aus den 80-er Jahren — scheinen zu wissen, dass vor allem systematische, gut pflegbare, stets aktuelle Dokumentation von Anforderung und Lösung das Rückrat erfolgreicher Projekttechnik ist.
Auch sollte man einsehen, dass der berechtigte Wunsch nach agilem Vorgehen (im richtig verstandenen Sinne) sich kaum mit dem heute allgegenwärtigen Wunsch nach Festpreisen verträgt.
Dass — bei hinreichend professionellem Vorgehen — hochkomplexe ERP-Systeme auch durchaus erfolgreich migriert werden können, hat Vissmanns Projekt bewiesen:
Nach nur 18 Monaten Projektlaufzeit konnte man an einem einzigen Wochenende die alte ERP-Installation durch eine von Anfang an fehlerfrei arbeitende neue Lösung auf Basis S/4HANA ersetzen. Die in diesem Projekt zu 80% migrierte und zu 20% neu entworfene Anwendung ist die zentrale Komponente der internationalen System-Landschaft bei Viessmann: 190 Buchungskreise, ein Mandant, auf den insgesamt 6000 User in 34 Ländern zugreifen. Es galt dabei 26 Sprachen zu berücksichtigen.
ggreiter 
Comments
Interessant ist, dass App-Entwickler ebenfalls eine neue Softwarekrise fürchten — sie sehen Anzeichen dafür, dass zunehmend schnell entstehender Bedarf mit heute angewandter Programmiertechnik demnächst nicht mehr zu decken sein wird.
Zudem werden heute Systeme benötigt, die allein schon ihrer Größe und Komplexität wegen Software-Entwickler vor Aufgaben stellen, denen sie nicht mehr gewachsen erscheinen:
So ist etwa in der Schweiz das IT-Großprojekt INSIEME, mit dem die Steuerverwaltung ihre alten Informatiksysteme zusammenführen und erneuern wollte, als technisch nicht durchführbar aufgegeben worden. Nachdem Ende September 2012 nämlich — nach sieben Jahren — lediglich zehn Prozent der notwendigen Programmierarbeiten abgeschlossen waren, dafür aber sowohl der Zeit- als auch der Budgetrahmen gesprengt war, zog das Eidgenössische Finanzdepartement die Notbremse: Eine Weiterführung des Projekts wurde “aufgrund der heute vorliegenden Erkenntnisse und Fakten als zu risikobehaftet” beurteilt.
Nebenbei: Bis dahin waren für den Versuch immerhin schon 124 Millionen Euro Steuergelder ausgegeben worden.
Ähnliches widerfuhr dem Versandhaus Otto: 2009 hatte der Konzern aus Hamburg ein Vorhaben mit dem Ziel gestartet, seine vielschichtige Anwendungslandschaft mit Hilfe von SAP-Standardsoftware zu zentralisieren. Doch “Passion for Performance” — so hieß das Projekt — wurde vor allem zur Leidensgeschichte und sorgte bereits im Frühjahr 2011 für den Abschied von CIO Thomas Tribius.
Die Komplexität wuchs den Beteiligten einfach über den Kopf, und so hat man das Projekt 2012 aufgeben müssen.
[Quelle: Computerwoche].
Siehe auch Walmüllers Präsentation.
Insbesondere dort, wo die Migration unternehmenskritischer Anwendungen auf moderne Technolgie misslingt stellt sich die drängende Frage, was genau denn eigentlich heutige Software-Entwickler hin und wieder so dramatisch zu überfordern scheint.
Eines scheint sicher: Wenn Software Engineering heute Teams überfordert, dann ist das sicher nicht mehr — wie damals in den 60-er Jahren — die Schwierigkeit, Code zu beherrschen, sondern vor allem ein Unterschätzen der Schwierigkeit, die stetig zunehmende Komplexität von Anwendungslogik überschaubar zu halten, hinreichend schnell zu verstehen und auf ein gesundes Normalmaß begrenzen zu können.
Dass man vor der Komplexität großer Softwareprojekte — sei es Entwicklung oder Migration — recht oft immer noch nicht genügend Respekt hat, zeigen jedes Jahr neu Zahlen, die die Standish Group veröffentlicht. So sind 2012 etwa in den USA zwar nur 4% aller kleineren Software-Entwicklungsvorhaben gescheitert, aber ganze 38% aller wirklich großen.
Für die Jahre vorher gesammelte Zahlen waren nicht wesentlich anders.
Und dass das Problem in naher Zukunft nicht kleiner werden wird, lässt sich ablesen aus Beobachtungen darüber WIE heute in IT-Projekten gearbeitet wird. Kann das noch lange gut gehen?
Die Zahlen der Standish Group über den Prozentsatz fehlgeschlagener Software-Entwicklungsprojekte (absolut ebenso wie in Abhängigkeit zu ihrer Größe) bestätigt eine 2012 von Gartner publizierte Studie.
Gartner hatte dazu — im Herbst 2011 — 150 Unternehmen aus USA, England, Frankreich und Deutschland befragt.
Welch gewaltiger Bedarf an notwendiger Neugestaltung alter IT-Anwendungen weltweit besteht, kann sich gut vorstellen, wer erfährt, dass die deutsche Bundesagentur für Arbeit im Herbst 2014 T-Systems damit beauftragt hat, federführend mehr als 100 IT-Verfahren und Systeme zu überarbeiten sowie 40 Neuentwicklungen mitzugestalten.
Quelle: Computerwoche, Okt. 2014
Schwerwiegende Konsequenzen der veralteten IT:
Wie gravierend die Auswirkungen veralteter IT-Systeme auf die Leistungsfähigkeit deutscher Unternehmen sind, zeigt eine Umfrage des Centre for Economics and Business Research. Demnach verwenden IT-Abteilungen durchschnittlich etwa 14 Mannstunden pro Woche nur um die Auswirkungen veralteter IT zu beheben.
Den deutschen Unternehmen kostet allein dieser Zeitaufwand 738 Millionen Euro. Eine Ursache für dieses Problem ist die zunehmende Diskrepanz zwischen den Geschäftsanforderungen einerseits und den Fähigkeiten der Unternehmens-IT andererseits.
57 Prozent der deutschen IT-Entscheider glauben, dass die Anforderungen an die IT und deren tatsächliche Leistungsfähigkeit deutlich auseinander klaffen.
Quelle: Computerwoche, Okt 2014
Wie unkalkulierbar allein schon die Kosten für die Migration unternehmenskritischer Anwendungen auf moderne Technologie geworden sind, zeigt z.B.
ein Migrationsprojekt des New Yorker Strom- und Gaslieferanten National Grid:
Statt der geplanten 384 Mio US Dollar erwartet man nun Gesamtkosten von etwa 945 Mio Dollar.
Interessant ist, dass die Lösung, die im November 2012 in Betrieb genommen wurde, zunächst massive Probleme — wegen fehlerhafter Implementierung — verursacht hat. Erst ganze 2 Jahre später denkt man, fast alle davon behoben zu haben.
Aber schon ein Jahr vorher (2013) haben zwei Gewerkschaften National Grid erfolgreich auf Schadenersatz von 270.000 Dollar verklagt als Ausgleich dafür, dass viele Arbeiter der fehlerhaften neuen Software wegen 9 Wochen lang nicht bezahlt werden konnten.
Darüber hinaus wurden 17.000 Angestellte nach Einführung des neuen Systems teilweise ganz gravierend falsch bezahlt. Die Unternehmensprecherin soll damals gesagt haben: National Grid has assigned “hundreds” of employees, including outside contractors, to deal with problems spawned by the new system.
Dass sogar SAP bei eigenen Großprojekten an der Komplexität der Lösung zu scheitern beginnt, zeigen die extrem hohen Entwicklungskosten — etwa 3 Mrd. Euro — für SAP Business by Design.
Noch bestreitet SAP, dass Business By Design aufgegeben werden soll. Man wolle das Produkt, bevor man seine Funktionalität fortentwickle, erst mal auf die neue Plattform HANA migrieren. Das aber — so wird den Kunden auch gesagt — sei aufwendig, so dass SAP nicht sagen könne, wann die Migration erfolgt sein wird.
Originalton Rainer Zinow, Senior Vice President der Cloud Unit von SAP: “Wir können nicht gleichzeitig Funktionen und Plattform entwickeln.”
Siehe auch: IT-Projekte außer Kontrolle: Über zwei Jahre hinweg wurden rund 1500 IT-Projekte durch McKinsey und Forscher der Universität Oxford ausgewertet. Hierbei ergab sich:
Jedes sechste Projekt sprengte das Budget um wenigstens 200 Prozent,
der geplante Zeitrahmen wurde im Mittel um 70 Prozent überschritten.
IT-Projekte, obgleich oft schöngerechnet, geraten 2 bis 3 Mal öfter außer Kontrolle als Bauprojekte.
Siehe auch: Schwarze Schwäne – woran große IT-Projekte scheitern (McKinsey, 2013, Ergebnisse einer Langzeituntersuchung).
Etwa 60 Prozent aller “Schwarzen Schwäne“, so McKinsey, werden schon während der Design-Phase verursacht.
Zudem muss heute ernsthaft damit gerechnet werden, dass die geplante Entwicklung einer großen Software-Applikation sich als einfach nicht mehr durchführbar herausstellt:
Ein solches Beispiel war Fiscus – der Versuch von Bund und Ländern, gemeinsam eine einheitliche Software für die Steuerverwaltung zu entwickeln. Über ein Jahrzehnt werkelten die Behörden an diesem Projekt, bis es 2005 endgültig scheiterte.
Budget-Überschreitung bis dahin: 4,6 Milliarden Euro. Heute basteln die Bundesländer am Nachfolger, Resultate sind bis dato nicht in Sicht.
Dass ein ganz analoges Vorhaben in der Schweiz — Projekt INSIEME — sich ebenfalls als undurchführbar erwies, wurde oben (im ersten Kommentar) schon erwähnt.
Wie unerwartet risikoreich die Migration alter Legacy Systeme auf moderne Standard-Software sein kann, zeigt z.B. auch ein Projekt aus 2008, über das der Harvard Business Review Folgendes berichtet:
» To top managers at Levi Strauss, revamping the information technology system seemed like a good idea. The company had come a long way since its founding in the 19th century by a German-born dry-goods salesman: In 2003 it was a global corporation, with operations in more than 110 countries. But its IT network was antiquated, a balkanized mix of incompatible country-specific computer systems. So executives decided to migrate to a single SAP system and hired a team of Deloitte consultants to lead the effort. The risks seemed small: The proposed budget was less than $5 million.
But very quickly all hell broke loose. One major customer, Walmart, required that the system interface with its supply chain management system, creating additional hurdles. Insufficient procedures for financial reporting and internal controls nearly forced Levi Strauss to restate quarterly and annual results. During the switchover, it was unable to fill orders and had to close its three U.S. distribution centers for a week. In the second quarter of 2008, the company took a $192.5 million charge against earnings to compensate for the botched project—and its chief information officer, David Bergen, was forced to resign.
A $5 million project that leads to an almost $200 million loss is a classic “black swan”. «
In 2010 ging ein größeres mittelständisches Unternehmen daran zugrunde, dass ein vier Jahre vorher begonnenes Projekt, sein Order Management System auf Standard-Software zu migrieren, ein nahezu unbrauchbares Ergebnis lieferte. Genauer:
» In 2006 Auto Windscreens was the second-largest automobile glass company in the UK, with 1,100 employees and £63 million in revenue.
Unsatisfied with its financial IT system, the company migrated its order management from Oracle to Metrix and started to implement a Microsoft ERP system. In the fourth quarter of 2010, a combination of falling sales, inventory management problems, and spending on the IT project forced it into bankruptcy. «
Quelle: Harvard Business Review (2011)
„systematische, gut pflegbare, stets aktuelle Dokumentation von Anforderung und Lösung” ist doch die Voraussetzung für Agile und SCRUM ….
Da haben Sie schon recht, Herr Dirry — aber dennoch stelle ich fest, dass Entwickler-Teams, die nach dem Agilen Manifest arbeiten, solche Dokumentation noch viel weniger erzeugen als Teams, mit denen ich früher gearbeitet habe.
Nebenbei noch: Ich bin kein Gegner von Agilität, denn ich weiß, dass man den heutigen Anforderungen nicht mehr gerecht werden kann, ohne zu berücksichtigen, dass sie sich ständig im Fluss befinden.
Wichtig aber ist, Agilität ihrem Ziel nach richtig zu verstehen (und nicht einfach so naiv zu arbeiten, wie ein Team von Wartungsprogrammieren das in ihrem sog. Agilen Manifest beschrieben hat — ein Manifest, das leider allzu viele allzu wörtlich nehmen).
Und geradezu lächerlich finde ich Kent Becks Extreme Programming.
Kents Ansatz und den von mir empfohlenen finden Sie gegenüber gestellt auf Seite Comparing two Process Models for Software Development.
Wie ich Agilität verstanden sehen möchte, lässt sich nachlesen in What Agile Software Development Really Means.
Aber vielleicht sind Sie, Herr Dirry, ja wirklich einer der wenigen, die nicht bei SCRUM und dem Agilen Manifest stehen bleiben möchten. Die anwendungstechnische Komplexität großer unternehmenskritischer Softwaresysteme beherrschbar zu halten, wird dennoch stets ein Problem sein, das keiner von uns unterschätzen sollte.
Dass insbesondere die Implementierung oder Erneuerung von ERP Systemen selbst modernste Software-Engineering-Methodk zunehmend öfters an die Grenzen ihrer Leistungsfähigkeit führt, bestätigen auch 12 von UpperEdge zusammengetragene Beispiele.
Über die in Queensland (Australien) zwischen 2006 und 2013 so dramatisch misslungene Neuimplementierung des staatlichen Payroll Systems für den Gesundheitsbereich wird am aussagekräftigsten berichtet auf folgenden Seiten:
(1) https://blog.beyondsoftware.com/the-queensland-health-payroll-fiasco
(2) http://ddkonline.blogspot.com/2010/07/anatomy-of-it-disaster-how.html
(3) https://drive.google.com/file/d/1p997XIJ_4bmDJ_BTty7wg5ptgyDto58S/view
Es scheinen hier Auftraggeber und Auftragnehmer gleichermaßen unprofessionell gehandelt zu haben.
Einserseits soll IBM sich nur 2 Wochen Zeit genommen haben, die hochkomplizierte Sollfunktionalität der Anwendung zu dokumentieren, andererseits aber hat man den dümmsten und folgenreichsten aller Fehler ganz klar auf Seite des Auftraggebers (einer staatliche Behörde) aus wohl rein politischen Beweggründen heraus gemacht: Man hat die ganz unglaublich vielen, äußerst schwerwiegenden, noch während des – zudem nur teilweise durchgeführten – Abnahmetests entdeckten Fehler der Software verharmlost und das System dennoch produktiv gesetzt.
“… perhaps the project’s worst failure was caused by the inability of team leadership to adequately plan and test the system during the development process:
Back in 2010, because of time constraints and cost overruns, it was determined to let the system go live without testing, which resulted almost immediately in over 35,000 payroll anomalies. Thousands of workers were underpaid or didn’t receive payment at all, while the system inadvertently overpaid thousands of other employees by a total of AU $400 M. Queensland has consequently spent millions more collecting those unearned funds from their employees; as of July 2017, almost 32,000 QH workers still owed $38 M in payroll overpayment attributable to the failure of the QHS Payroll Project.”
“Instead of slowing the process, the project board agreed to revise the definition of Severity 1 and 2 defects – effectively shifting the goalposts so the project passed exit criteria.”
Man lese auch, wie die Notwendigkeit für Migration unternehmenskritischer Anwendungen auf modernere Plattformen so manchen Unternehmensführer zur Weißglut bringt: Hier über einen, der feststellt: “Das ist schlimmer als Brexit, Trump und Handelskrieg“.
Trackbacks
Selbst weltweit anerkannte IT-Dienstleister (siehe Beispiele) liefern hin und wieder absolut unbrauchbare Software und bescheren so ihren Kunden Verluste in 2- bis 3-stelliger Millionenhöhe.
Hasso Plattner (SAP Mitbegründer) scheint einer der wenigen, die das ganz klar erkennen und auch auszusprechen wagen.