Droht uns eine neue Software-Krise?


Wohl noch nie hat sich einer der weltweit wichtigsten Software-Produzenten der­maß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 Program­mierer 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 über­fordert 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 Auftrag­geber 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.

 
Derzeitiger Projektstand 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 be­steht, nun schon zum dritten Mal einen geeigneten Auftragnehmer finden zu müssen).

 
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).

 
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.
 

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Gebhard Greiter  On March 5, 2013 at 10:11 am

     
    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 Kom­plexitä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 Steuerver­waltung 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 vor­liegenden 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.
     

  • Gebhard Greiter  On June 11, 2013 at 5:12 pm

     
    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.
     

    • Gebhard Greiter  On July 30, 2014 at 7:20 pm

       
      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 Unter­schä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?
       

      • Gebhard Greiter  On January 30, 2015 at 4:48 pm

         
        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.
         
        Typical IT Project Failure Rate
         

    • Gebhard Greiter  On October 8, 2014 at 11:10 am

       
      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
       

      • Gebhard Greiter  On October 30, 2014 at 5:56 pm

         
        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
         

    • Gebhard Greiter  On October 19, 2014 at 10:37 am

       
      Wie unkalkulierbar allein schon die Kosten für die Migration unternehmens­kritischer 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 employ­ees, including outside contractors, to deal with problems spawned by the new system.
       

  • Gebhard Greiter  On October 21, 2013 at 1:08 pm

     
    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.
     

  • Gebhard Greiter  On November 17, 2013 at 9:53 pm

     
    Siehe auch: IT-Projekte außer Kontrolle: Über zwei Jahre hinweg wurden rund 1500 IT-Projekte durch McKinsey und Forscher der Universität Oxford ausge­wertet. 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.
     

    • Gebhard Greiter  On May 22, 2015 at 8:57 pm

       
      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, gemein­sam 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.
       

  • ggreiter  On July 28, 2014 at 12:38 pm

     
    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”. «
     

  • ggreiter  On July 28, 2014 at 1:34 pm

     
    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 manage­ment 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)
     

  • Johann Dirry  On May 17, 2015 at 9:43 am

     
    „systematische, gut pflegbare, stets aktuelle Dokumentation von Anforderung und Lösung” ist doch die Voraussetzung für Agile und SCRUM ….
     

    • ggreiter  On May 18, 2015 at 8:09 pm

       
      Da haben Sie schon recht, Herr Dirry — aber dennoch stelle ich fest, dass Entwickler-Teams, die nach dem Agilen Manifest arbeiten, solche Dokumen­tation 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 anwendungs­technische Komplexität großer unternehmenskritischer Software­systeme beherrschbar zu halten, wird dennoch stets ein Problem sein, das keiner von uns unterschätzen sollte.
       

Trackbacks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: