Elf IT-Projekte im Sturzflug

Gefährliche Bindung an einen Anbieter

Wenig Gutes kam auch dabei heraus, als der US-Staat Kalifornien Ende der 1980er seine Führerschein- und Kraftfahrzeugbehörden neu mit Rechnern ausstatten wollte. Die Regierung entschied sich bei der Software für den Hersteller Tandem Computers und band sich damit auch bei der Hardware an dieses Unternehmen. Für 11,9 Millionen mussten sechs Computer beschafft werden.

Schließlich stellte sich heraus, dass das neue System langsamer war als das alte. Das Projekt wurde beendet - 44 Millionen Dollar waren damit in den Sand gesetzt worden. Für Jake Widman ist das gescheiterte Vorhaben ein Lehrstück, das zeigt, wie gefährlich die Bindung an einen einzigen Anbieter ist.

Den rechtzeitigen Ausstieg verpasst

Auch der Staat Washington verschwendete hohe Summen für ein ähnliches Unterfangen. Das 1990 angelaufene Projekt zur Automatisierung der Fahrzeugzulassung war ursprünglich auf 16 Millionen über fünf Jahre angesetzt. Schon 1992 waren die Ausgaben auf 41,8 Millionen gewachsen. Erst 1997 zog die Verwaltung die Notbremse. 67,5 Millionen waren bis dahin in das Projekt geflossen. Ein Paradebeispiel dafür, aus einem ganz offensichtlich zum Scheitern verurteilten Projekt besser früher als später auszusteigen.

Unrealistische Zeitvorgaben für ERP-System von SAP

Der amerikanische Pharma-Großhändler Fox-Meyer strauchelte 1993 über ein ERP-Projekt. SAPSAP und das Beratungshaus Andersen sollten ein System zur Automatisierung der Warenlager einführen. Auf der einen Seite machte Fox-Meyer unrealistische Zeitvorgaben: In nur 18 Monaten sollte das System zum Laufen gebracht sein. Zu schaffen machten dem Unternehmen auch die Lagerarbeiter, die ihre Stellen gefährdet sahen und der neuen Lösung daher widerwillig gegenüber standen. Alles zu SAP auf CIO.de

Das System selbst verfehlte zudem vollkommen die Erwartungen. 1994 konnte es nur 10.000 Bestellungen pro Nach abarbeiten, während die frühere Mainframe-Lösung 420.000 schaffte. 1996 musste der Großhändler Insolvenz anmelden. Dieses Beispiel soll Widman zufolge zeigen, dass IT-Projekte so angelegt sein sollten, dass ihr Scheitern nicht das Überleben des ganzen Unternehmens gefährden dürfen.