Monthly Archives: October 2015

Fehlende Software-Qualität kann auch große Unternehmen gefährlich stolpern lassen!


Dass fehlende Qualität von Software ein Unternehmen in Krisen führen kann, bestätigt sich auf jeden Fall dann, wenn anhaltende Probleme mit einen unter­nehmenskritischen neuen System den CFO zu einer Gewinnwarnung zwingen und so auch die Aktionäre beunruhigen.

Sie glauben nicht, dass so was passiert? Nun, hier ist ein Beispiel:

Wie die Computerwoche berichtet, droht das misslungene neue Computersystem “New Forwarding Environment” (NFE) die Deutsche Post im Frachtgeschäft um Jahre zurückzuwerfen.

Deteils finden sich auf FinanzNachrichten.de in einer Meldung vom 29.10.2015:
 

    Larry Rosen, der Finanzchef der deutschen Post, erklärt, NFE sei zu fehleranfällig und müsse wohl ersetzt werden, was Jahre dauern könne, denn eine neue, weniger komplexe Lösung stehe kurzfristig nicht zur Verfügung.

    Man überlege nun, schrittweise neue Komponenten zu integrieren und habe Rückstellungen in Höhe von 37 Millionen Euro gebildet für Ausgaben zur erwarteten Rückabwicklung des Systems in den bereits umgestellten Pilotländern.

    Der Bonner Konzern schätze die Wahrscheinlichkeit, aus dem derzeitigen System positive Effekte erzielen zu können, als sehr gering ein und habe deshalb auch Abschreibungen in Höhe von 309 Mio. Euro vorgenommen.

    Die bereits nach dem zweiten Quartal 2015 schon einmal korrigierte Prognose sei nun nicht mehr zu halten.

 

Nachdenklich macht: NFE basiert auf Software von SAP und wurde mit IBM Global Business Services als Implementierungspartner umgesetzt.

Da sollte man sich schon fragen, wie es zu einem solchem Unglück kommen konnte.

Eines dürfte klar sein:

Obgleich zu akzeptabler Software-Qualität weit mehr gehört als nur die Abwesen­heit von Programmierfehlern, wird sie doch (vom Software-Lieferanten) gerne auf genau solche reduziert gesehen. Dem Auftraggeber fällt das zunächst gar nicht auf.

Doch können denn wirklich nur Programmierfehler so ein Desaster verursachen, wenn das System auf Code beruht, den SAP und IBM entwickelt haben (Firmen also, von denen man erwartet, dass sie kompetentes Personal einsetzen)?

Meine etwa 30-jährige Erfahrung mit Software-Entwicklung sagt mir, dass ein System, dessen Anforderungen vor Beginn der Programmierung genau und vollständig schriftlich spezifiziert und entsprechend gründlich durchdacht worden sind, von erfahrenen Programmierern auf keinen Fall derart verkorkst werden kann, dass es nicht gelingt, alles wesentliche Fehlverhalten innerhalb weniger Monate, wenn nicht Wochen, beseitigen zu können.

An was aber mag es denn dann liegen, dass selbst weltweit bekannte Software-Lieferanten wie IBM — solche, denen man größtmögliche Erfahrung unterstellt — ein System abliefern, welches seine Anwender und Betreiber als kaum nutzbar, auf jeden Fall aber als nicht länger tragbar einstufen?

Mein Verdacht: Man wird wohl versucht haben, nach dem Agilen Manifest zu arbeiten — nach dem Vorgehensmodell also, das seit der Jahrtausendwende unter dem Label “Agile” hochgelobt wird, weil junge Entwickler sich nicht mehr die Mühe machen wollen, die klassischen Verfahren des Software-Engineerings wirklich zu verstehen und der inzwischen neu hinzugekommenen Notwendigkeit, maximal flexibel zu sein, erfolgreich anzupassen — auch und gerade unter der Neben­bedingung, dass heute fast alle Entwicklungsaufträge zum Festpreis vergeben werden.

Wenn die Deutsche Post jetzt plant — und sich sogar gezwungen sieht — “eher evolu­tionär” vorzugehen (wie Rosen sich ausdrückt), klingt mir das schon fast nach einer Wiederholung des von mir vermuteten Fehlers.

Will man wirklich riskieren, dass ich recht habe? Will man nicht zuerst über die Ursachen des Mißerfolgs nachzudenken?

Oder will man einfach nicht einsehen, dass der klassische Weg, Software zu ent­wickeln, eher Erfolg garantiert als SCRUM-artig gestaltete Prozesse in Kombination mit dem blinden Glauben an die Effektivität der allzu naiven Prinzipien des Agilen Manifests?

Ist uns denn nicht bewusst, dass Agile, SCRUM und dieser ganze verhängnisvolle, viel zu wenig durchdachte Trend auf eine kleine Gruppe von Wartungsprogram­mieren zurückgehen, die dachten zu wissen, wie man wirklich große Software-Entwicklungsprojekte so durchführt, dass (fast) nichts mehr schief gehen kann?

Wer glaubt, man könne die Wahl des Prozessmodells zur Entwicklung einer umfangreichen IT-Lösung einfach der Mode oder nur an ihren Code denkenden Programmierern überlassen, der irrt gewaltig.

Dem CIO der Deutschen Post jedenfalls kann man nur raten, die Ursachen seines Desasters genau zu identifizieren.

Versäumt er das, könnte die Deutsche Post in einer eher noch folgenreicheren IT-Sackgasse landen. Ob es dann noch reichen würde, einfach nur eine Gewinn­warnung herauszugeben, kann bezweifelt werden.
 

Advertisements