Komplexität ist die größte Falle!

16.05.2007

Gescheiterte oder kurz vor dem Scheitern stehende Softwareprojekte wie die Umstellung von SAP auf Oracle bei Hochtief (siehe Seite 1) sind vielen Beobachtern und natürlich Wettbewerbern willkommener Anlass zur Häme. Je nach persönlicher Einstellung und Perspektive kommentieren sie das Hochtief-Desaster als Versagen Oracles, als Scheitern des Dienstleisters Capgemini oder als das Unvermögen des Anwenders, ein Projekt dieser Größe entsprechend gut zu managen. Wahrscheinlich haben alle Recht zumindest ein bisschen.

Aber bei Hochtief geht es nicht nur um eine normale Migration, bei der von einer Applikation auf eine andere umgestellt werden soll. Einige, bisher nicht integrierte Systeme neuer Konzernteile sollten in Oracles E-Business-Suite ebenfalls eingebunden werden. Außerdem musste das Ganze weniger kosten als bisher, und der Verkauf der Hochtief-eigenen IT-Tochter an einen Dienstleister (Capgemini) veränderte die Ausgangslage zusätzlich. Das hätte man vorher alles berücksichtigen können, führen die Berufskritiker jetzt ins Feld. Stimmt! Aber mit wie vielen Aufgaben und Funktionen kann man ein Projekt belasten, wie viel Komplexität und Variabeln hält es aus, bevor es scheitert? Garantiert weniger, als gemeinhin angenommen wird.

Der Verdacht liegt nahe, dass bei Hochtief die Menge der angestrebten Ziele alle Beteiligten überfordert hat. Beispielsweise die Integration der Teilsysteme: Höchstwahrscheinlich wird Oracle vor der Zusage geprüft haben, was jeweils getan werden muss, um die Teilsysteme einzubinden. Aber weder die vorherigen Betreiber dieser Applikationen werden lückenlos alle kritischen Punkte offengelegt haben, noch die Prüfer von Oracle die prinzipielle Machbarkeit in Frage gestellt haben - schließlich wollte der SAP-Rivale den Deal auf Biegen und Brechen. Doch Politik ist selten ein guter Ratgeber, um das Realisierungsrisiko bestimmter Teile oder des Gesamtprojekts einzuschätzen.

An dieser Stelle hilft eine alte Fußballweisheit als Faustregel weiter: "Immer den einfachen Pass spielen." Natürlich müssen auch bei Software-projekten Risiken eingegangen werden. Sie sollten aber auf Teilaspekte begrenzt sein, die nicht das Potenzial haben, das Gesamtprojekt zu gefährden.