Praktisches & Grundsätzliches zur Informatik


Was passieren kann, wenn Software-Tester versagen oder man ihre Aussagen zu wenig ernst nimmt:

Drei Projekt-Desaster, die uns nachdenklich machen sollten

Die drei weltweit schlimmster Software-Entwicklungs-Desaster, von denen ich bisher gehört habe, sind:


Im Folgenden sei wenigstens ansatzweise diskutiert, was es für Entwickler, Tester und Projekt­manager aus diesen 3 schlimmen Fällen lernen zu lernen gilt.

In Summe hatten sie finanzielle Schäden von mehr als 1 Milliarde US-Dollar zur Folge, ganz zu schweigen davon, dass im dritten Fall sogar mehr als 2000 Personen aus dem mittleren Management der britischen Post schwer geschädigt wurden: Erst 72 von ihnen sind inzwischen rehabilitiert, alle erst nach jahrelanger Haft. Viele andere kämpfen noch um ihren vor Jahren zerstörten guten Ruf. Die zuständige Justiz nennt diesen Fall inzwischen "the most widespread miscarriage of justice in the UK ever".


zu (1): Zwischen 2002 und 2010 haben sich gleich zwei ausgesprochen renommierte Hersteller von Software — erst Baring Point, dann SAP — die Zähne ausgebissen.

  • Baring Point hat 1 Woche vor dem geplanten Liefertermin eingestanden, dass sie sich mit dem Projekt überfordert fühlen.
  • Danach ist das Projekt — zum etwa 7-fachen Preis — von SAP angenommen worden, Vorsichtshalber hatte man jetzt geplant, zunächst einen Prototyp auszuliefern, der dazu gut sein sollte, die monatliche Gehaltsabrechnung für nur etwa 1100 Bediensteten einer einzigen Behörde zu erledigen: das Office des State Controllers, der als Auftraggeber auftrat. Zum Vergleich: Das Altsystem erledigt die Gehaltsabrechnung für sämtliche, damals etwa 240.000 Bedienstete des Staates Kalifirnien. Während das Altsystem etwa 45 unterschiedliche Vertragstypen unterstützt, brauchte der Prototyp nur zwei davon zu unterstützen.
  • Dass das neue System auf SAP-eigener Plattform zu implementiert werden sollte, sollte SAP die Realisierung eher einfach gemacht haben (was damal wohl alle dachten). Da auch der Preis, zu dem SAP angeboten hatte, den zuvor mit Baring Point vereinbarten um hahezu eine Größenordnung überstieg, sollte — so dachte man wohl — alles gut gehen.
  • Leider war dem nicht so: SAP hat den Prototyp ausgeliefert und als für Produktion geeignet empfoh­len. Nachdem man ihn in Betrieb nahm, hat er derart viel falsch gemacht, dass sich der State Controller schon ein halbes Jahr später gezwungen sah, wieder zurück auf das Altsystem zu migrieren. Auch SAP selbst war nicht in der Lage, zu sagen, was bei der Implementierung des Prototyps schief gelaufen war. Die entsprechende gerichtliche Auseinandersetzung endete mit einem Vergleich, demzufolge SAP auf eigene Forderungen zu verzichten hatte und zudem noch gut 40 Mio US-Dollar Scheadenersatz zu leisten hatte.
  • Nach diesem Vergleich hat man begonnen, die Funktionalität des Altsystems — nun schon über etwa 8 Jahre hinweg — detailliert zu dokumentieren.
  • Damit scheint klar zu sein, dass zunächst Baring Point und danach SAP den fatalen Fehler gemacht haben, eine detaillierte Problemanalyse zu unterlassen.
  • SAP muss man zudem noch vorwerfen, dass der Systemtest, für den die Entwickler verantwortlich waren, absolut unzureichend ausgefallen war. Und das obgleich man sich in der besonders schönen Lage fand, Ergebnisse der neuen Software ein oder 2 Monate lang mit entsprechenden Ergebnissen des Altsystems vergleichen zu können: Man hat das ganz offensichtlich unterlassen, bevor man dem Auftraggeber empfahl, den Prototyp produktiv zu setzen. Was sagt uns das über die Kompetenz der Tester auf SAP-Seite?
    |
  • Stand 2021: Man denkt, demnächst hinreichend gute Dokumentation des Altsystems, seiner Funktionalität und auch gewünschter SOLL-Funktionalität zu haben, um das Migrationsprojekt, nun CSPS genannt, eine drittes Mal ausschreiben zu können: Es soll nun zu einer cloud-basierten Lösung werden. Die Vorarbeiten hierfür begannen 2016.



zu (2): Ganz äühnlich, wie SAP in Kalifornien scheterte, ist IBM Australia in Queenslandgescheitert:

IBM hatt eden Auftrag bekommen, die diversen ERP-Systeme, die im Staat Quennslang im öffentlichen Gesundheitsbereich genutzt wurden, durch ein einzigen, neues zu ersetzen.

  • Dieses Projekt stand von Anfang an unter hohem Zeitdruck, insbesondere von Politikernerzeugt, und hatte mit der Problematik zu kämpfen, dass es auf Seite des Vertretung der Auftraggeber allzu viel Uneinigkeit und offenbar auch völlig unrealistische Vorstellungen über den benötigten Zeitrahmen gab.
  • Wie ein Insider später berichet haben soll, hat IBM sich nur ganze 2 Wochen Zeit für eine Problemanalyse und SOLL-Spezifikation genommem.
  • Als der geplante Auslieferungstermin dann aber nahe war und IBM erste Ergebnisse von Systemtest vorlagen, hat IBM sich als ehrlich und durchaus kompetent erwiesen: Man hat den Auftraggebern empfohlen diese Version des neuen Systems noch auf keinen Fall produktiv zu setzen.
  • Leider hat man — politischem Druck folgende — IMBs Ratschlag nicht gut geheißen und die Altsysteme dennoch sofort durch das neue System ersetzt.
  • Diese Entscheidung hat sich schon wenige Wochen später als fatal erwiesen, denn sie hat Queenslands Gesundheitssektor nahe an den Punkt gebracht, nicht mehr funktionsfähig zu sein. Der Grund hierfür: eine ganz erheblicher Prozentsatz aller Bediensteten und Subunternehmer wurde vom neuen System falsch, gar nicht oder viel zu hoch bezahlt. Wie sich später zeigen sollte, hat man über Jahre hinweb bis zu 3000 Beamte damit beschäftigen müssen, zu viel ausgezahlte Gelder zurückzufordern. Umgekehr hat bei denen, die jetzt plötzlch falsche Gehaltsabrechnungen oder zunächst mal gar keine mehr bekamen, die Wut so groß, dass einige Politiker sich starkem Druck ausgesetzt sahen, doch besser zurückzutreten.
  • Auch dieses Projekt hatte einen gerichtliche Auseinandersetzung zwischen Auftraggeber und Auftragnehmer zur Folge, wobei IBM aber freigesprochen wurde, da sie klug genug gewesen waren, ihren Auftraggeber wahrheitsgemäß zu unterrichten und ihn davor gewarnt hatten, das neue ERP-System trotz der zahlreichen durch IBMs Systemtest schon bekannt gewordenen Mängel produktiv zu setzen.
    |
  • Dieses Projekt gilt derzeit (2021) als das größte IT-Desaster, zu dem auf der südlichen Halbkugel der Erde je kam.


zu (3): Noch schlimmer als in den Projekten (1) und (2) kam es in Projekt (3): dem etwa 2000 produktiv gesetzten derzeitigen ERP-System Horizon der britischen Post:

  • Während sich in (1) die Auftragnehmer, in (2) aber die Auftraggeber als durch ihr Projekt weit überfordert erwiesen, kann man dem Projekt (3) nur bescheinigen, das dort Entscheider auf beiden Seiten nicht nur absolut inkompetent, sondern auch absolut unverantwortlich gehandelt haben:
  • Das Unglück begann damit, dass dort auf Seite des Auftragnehmers (Fujitsu) ganz offensichtlich nur völlig unzureichender Systemtest passiert ist: Korrektheit aus anwendungslogischer Sicht, scheint man nicht ernsthaft getestet zu haben.
  • Zudem ist auf Seites des Auftraggebers (der Post) — wie man aus heutiger Sicht wohl annehmen muss — scheinbar gar kein ernsthafter Abnahmetest erfolgt: ganz sicher nicht hinsichtlich korrekter Anwendungslogik, denn obgleich dieses ERP-System nun schon 21 Jahre alternativlos produktiv genutzt wird, waren erst kürzlich einige seiner Anwender tapfer genug, auszusagen, dass es immer noch nicht fehlerfrei funktioniere.
  • Das unprofessionelle, offenbar auch zuweilen unehrliche Handeln, beider Seiten besteht darin, dass niemand der verantwortlichen Manager Fehler einzuräumen bereit ist — obgleich das doch zur Folge hat, dass mit großer Wahrscheinlichkeit immer noch etwa 2000 ehemaligen Mitarbeiter der Post unschuldig des Betrugs bezichtigt werden: Bisher von der Justiz nach jahrelangem juristischen Hickhack rehabilitiert sind erst 72 der vor meist schon vor 2014 beschuldigten und verurteilten Postmaster. Man geht davon aus, dass weitere fregesprochen werden, will aber offenbar doch jeden einzelnen der Fälle neu untersuchen. Die Post-Manager sind (noch?) nicht bereit, von der Unschuld aller auszugehen. Dass man in dem Fall wohl niemand Fehlverhalten wird nachweisen können, da ja alle das nun als fehlerhafte System nutzten, scheint für sie keine Rolle zu spielen.

    Note: In den Jahren 2000-2014 wurde im Durchschnitt jede Woche ein Postsmaster des Betruges bezichtigt. 2020 rehabilitiert wurde auch einer, den man damals so hart bedrängt hatte, dass von ihm sogar ein falsches Gestandnis vorliegt: er habe 72.000 britische Pfund unterschlagen. Einge der damals mit hoher Wahrscheinlichkeit Unschuldigen waren schon verstorben, als das Fehlverhalten des Systems nachweisbar wurde. In einigen Fällen, so wir berichtet, haben Post-Manager Unterlagen geschreddert, nachdem ehemalige Mitarbeiter um Einsicht baten mit dem Ziel, ihre Unschuld beweisen zu können.


In Summe gesehen:

  • Auffalled ist, dass bei allen drei Projekten Test als Sicherheitsnetz versagt hat: In (1) der Tester wegen, in (2) der Auftraggeber wegen und in (3) wohl der Unehrlichkeit aller Manager wegen.
     
  • In allen drei Projekten wird eine entscheidende Ursache für das Versagen der neuen Software und ihrer Tester ganz sicher auch gewesen sein, dass es viel zu wenig genaue Spezifikationen der SOLL-Funktionalität des neuen, ebenso wie der IST-Funktionalität des alten Systems gab.

    Könnte das daran liegen, dass alle 3 Projekte realisiert wurden zu einer Zeit, als man — der Ende der 90-er Jahre populär gewordenen "agilen" Bewegung wegen — das klassische Wasserfallmodell schlecht zu reden begann, um stattdessen SCRUM als Allheilmittel anzupreisen?




stw4778SAPPASAP . Projekt . AuftraggeberNews?

Mehr + B G E + S H A + More