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.
Wo Einkäufer sich beharrlich weigern, das einzusehen, steigt das Risiko, am Ende eine wenig funktionsgerechte Lösung zu haben.
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 
