Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03113.jsonl.gz/3121

Auch wenn es vielleicht manchmal nicht offensichtlich ist, aber bei all meinen Beiträgen geht es mir um den Praxisbezug. Es gibt zwar nichts Praktischeres, als eine gute Theorie, aber wenn daraus nicht hervor geht, was ein Manager machen muss, um bessere Ergebnisse zu erzielen, dann ist die Theorie noch unausgereift.
Obwohl ich hier schon einmal auf den Artikel When Bad Things Happen to Good Projects1 aufmerksam gemacht habe (Was ist billiger? Ein Mitarbeiter oder eine Zertifizierung? in diesem Blog, 29. September 2009), möchte ich nochmals mit Nachdruck darauf hinweisen. Die Lessons Learned, die man aus diesem Artikel ziehen kann, weisen eindeutig in die richtige Richtung.
Ein typisches Migrationsprojekt
Es handelt sich um eine Fallstudie eines typischen Migrationsprojekts. Nachdem HP einige Unternehmen inklusive ihren Prozessen und IT-Systemen akquiriert hat – z.B. Compaq – sah sie sich vor das Problem gestellt, die verschiedenen IT-Systeme, die dieselbe Funktionen haben, zusammen zu führen. Beispielsweise hat jede Unternehmung ein sog. Order Entry System, also eine IT-Einrichtung, die Bestellungen entgegen nimmt und in Produktions- und Speditionsanweisungen umwandelt. Die Bestellungen geben die Kunden über das Internet (bzw. das Web) direkt in das Order Entry System ein. Kleinere Kunden können ev. auch einen Support Mitarbeiter anrufen und die Bestellung mündlich durchgeben.
Bei HP ist das Order Entry System ein Teilsystem ihres SAP. Einige Unternehmen, die HP akquiriert hat, haben allerdings kein SAP eingesetzt. HP wollte nun alle Order Entry Systeme in ihrem Unternehmen auf SAP konsolidieren.
Umleiten des Outputs des einen Systems in das andere System
Das machte sie in mehreren Etappen und stets auf dieselbe Weise: Der Output eines Order Entry Systems R wurde in das SAP-System umgeleitet. Für das SAP-System waren dann die Bestellungen, die via R herein gekommen sind, gleichbedeutend, wie Bestellungen, die von einem externen Kunden kamen. Haben die Kunden, die via R bestellten, einmal begriffen, dass sie jetzt via das SAP-System bei HP bestellen müssen, kann R abgeschaltet werden.
Dazu müssen die Produktions- und Speditionsanweisungen, die das System R verlassen, in Bestellungen für das SAP-System übersetzt werden. Es braucht also zwischen dem R-System und dem SAP-System ein kleines Stück Software, das diese Übersetzung macht. HP hat diese Übersetzungssoftware für das Order Entry System einer jedem akquirierten Unternehmung geschrieben. Jedes Mal ging das gut und jedes Mal erhöhte sich die Erfahrung von HP für dieses Vorgehen bei der Übernahme einer neuen Unternehmung….bis sie die fremden Order Entry Systeme für das Servergeschäft migrieren wollten. Das Servergeschäft ist der grösste Geschäftszweig von HP.
Der Krug geht zum Brunnen bis er bricht
Die letzte und umfangreichste Migration ging schief! Die Übersetzungssoftware enthielt kleine Fehler, die dazu führten, dass viele Bestellungen im SAP-System stecken blieben und gar nie in die Produktion kamen, bzw. die bestellte Ware gar nie spediert wurde. Kunden beschwerten sich oder – noch schlimmer – wanderten ohne Kommentar ab. Der Schaden betrug 160 Millionen US-Dollar!
HP hat die Übersetzungssoftware auf Herz und Nieren getestet. Dennoch enthielt sie Fehler, denn man konnte nicht alle möglichen Bestellformate voraussehen, die die Kunden anliefern. Es gab Bestellungen, die enthielten unvorhergesehene Elemente oder Zeichen, die die Übersetzungssoftware nicht richtig interpretieren konnte. Das kann man mit den umfangreichsten und sorgfältigsten Tests nicht verhindern.
Lehren
Es gibt viele Lehren, die wir daraus ziehen können, und ich möchte in einem oder zwei Folgebeiträgen auf ein paar Lehren hinweisen, die der Autor des Artikels nicht erwähnt hat. Er betont vor allem, dass das Risikomanagement vom Business wahrgenommen werden muss und nicht auf die IT abgeschoben werden darf. Oft wird nämlich die IT „geschlagen“, obwohl man das Business meint.
Die IT versucht, durch Zertifizierung die Projektmanagement-Fähigkeiten zu erhöhen, was zwar machbar ist, aber offensichtlichs nichts taugt. Gegen die Unvorhersehbarkeit der Bestellformate hilft eben z.B. ein Gantt-Diagramm oder eine Earned Value Analysis nichts. Risikomanagement auf der Businessebene ist hingegen viel schwieriger und unangenehmer, weshalb es gerne auf die IT abgewälzt wird. Das ist der Systemarchetypus der Problemverschiebung, auf den ich im nächsten Beitrag zu sprechen komme.
Schliesslich forderte der Autor bereits 2004, dass man im Projektmanagement endlich vom Kost-Termin-Denken wegkommen sollte. Was nützt einem ein Projekt, dass kosten- und terminmässig erfolgreich abgeschlossen wurde, nachträglich dem Business aber 160 Mio Dollar Verlust bringt? Sagen Sie nicht, dass das Projekt in dem Fall nicht erfolgreich war! Es wurde vom Auftraggeber zufriedenstellend abgenommen, nachdem er sogenannte Akzeptanztests gemacht hatte, denn auch er hatte sich nicht abschliessend vorstellen können, was für Bestellungen eintreffen werden.
1Koch, Christopher. When Bad Things Happen to Good Projects, in CIO.com, 2. April 2007