Eine Analyse der systematischen Versagensmuster externer IT-Expertise zeigt: Nicht selten dominiert Innovationstheater – glänzende Präsentationen ohne belastbare Umsetzung. Das Problem ist nicht der Einsatz externer Berater an sich, sondern wie sie ausgewählt, eingesetzt und kontrolliert werden. Wenn alle sagen „geht nicht“ und McKinsey aufgibt – dann braucht es einen anderen Ansatz.
Die ernüchternde Realität: Zahlen ohne Rhetorik
Die Standish Group erhebt seit 1994 Daten zu IT-Projekterfolgen mit ernüchternden Ergebnissen:
- Nur 9% der IT-Projekte in Großunternehmen sind erfolgreich (pünktlich, im Budget, volle Funktionalität)
- 52,7% der Projekte überschreiten das Budget oder reduzieren den Umfang
- 31,1% werden komplett abgebrochen
- Durchschnittliche Kostenüberschreitung: 189% des ursprünglichen Budgets
Diese Zahlen bedeuten: In neun von zehn IT-Projekten bei Großunternehmen stimmt am Ende entweder das Budget nicht, der Zeitplan nicht, der Funktionsumfang nicht – oder das Projekt wird komplett abgebrochen.
Die Pegasystems-Studie 2025 quantifiziert die jährlichen Verluste durch technische Schulden: 370 Millionen USD Gesamtverlust pro Unternehmen und Jahr.
Dokumentierte Katastrophen: Was wirklich schiefging
National Grid vs. Wipro: Über 1 Milliarde USD Schaden
National Grid USA wollte ihre Back-Office-Systeme auf SAP migrieren. Budget: 290 Millionen USD. Sie wechselten von Deloitte zu Wipro – Hauptgrund: Kostensenkung.
Wipros Behauptung: „Well-established SAP practice“ für Utilities.
Die Realität: Wipro hatte faktisch keinerlei Erfahrung mit SAP-Implementierungen für US-regulierte Versorgungsunternehmen.
Die Folgen nach Go-Live:
- Mitarbeiter wurden falsch bezahlt oder gar nicht
- 8 Millionen USD Überzahlungen nie zurückgeholt
- 15.000+ Lieferantenrechnungen nicht verarbeitet
- Buchungsabschluss: von 4 Tagen auf 43 Tage
- Stabilisierungskosten: 30 Millionen USD pro Monat
Gesamtschaden: Über 1 Milliarde USD
Weitere dokumentierte Millionenschäden
| Unternehmen | Jahr | Schaden | Kernproblem |
|---|---|---|---|
| Revlon | 2018 | 64 Mio. USD | Keine SAP-Erfahrung, falscher Systemwechsel |
| MillerCoors vs. HCL | 2014-2017 | 100 Mio. USD | 80 Defekte beim ersten Rollout |
| Lidl | 2011-2018 | 500 Mio. EUR | SAP-Standard passte nicht zu Geschäftslogik |
| US Air Force ECSS | 2005-2012 | 1+ Mrd. USD | Kein klares Ziel, kein Wille zur Umsetzung |
Die vier Typen externer Expertise, die regelmäßig scheitern
Typ 1: Der Offshore-Volumenanbieter
Charakteristik: Behauptet Expertise, optimiert aber für Volumen und Marge. Setzt Junior-Personal ein.
Versagensmechanismus: „Wir haben SAP-Erfahrung“ ist technisch korrekt, aber irreführend. SAP für einen Einzelhändler ist etwas anderes als SAP für ein reguliertes Versorgungsunternehmen.
Typ 2: Der Systemintegrator ohne Domain-Wissen
Charakteristik: Kennt die Technologie, nicht die Branche.
Versagensmechanismus: Technische Korrektheit ist nicht gleich Geschäftstauglichkeit.
Typ 3: Die Big-4-Firma mit Interessenkonflikt
Charakteristik: Berät, implementiert und prüft – manchmal beim selben Kunden.
Das strukturelle Problem: Wer vom Folgegeschäft abhängt, hat keinen Anreiz, Probleme zu benennen.
Typ 4: Der Berater als „Partner des Managements“
Charakteristik: Sagt, was der Kunde hören will. Keine unabhängige Prüfung.
Versagensmechanismus: Berater, die Probleme benennen, gefährden den nächsten Auftrag.
Wann externe Expertise tatsächlich wirkt
Die Analyse zeigt fünf kritische Erfolgsbedingungen:
1. Nachweisbare Referenzen im identischen Kontext
Nicht „ähnlich“, sondern identisch. SAP für ein US-Versorgungsunternehmen erfordert andere Expertise als SAP für einen europäischen Einzelhändler.
2. Trennung von Implementierung und Prüfung
Wer implementiert, kann nicht gleichzeitig unabhängig prüfen. Investieren Sie in unabhängige Qualitätssicherung als Versicherungspolice.
3. Geschäftsmodell, das Problemfindung belohnt
Ein Berater, dessen Auftrag es ist, Probleme zu finden, hat einen anderen Anreiz als ein Berater, dessen Folgeauftrag von zufriedenen Stakeholdern abhängt.
4. Seniorität ohne Team-Overhead
Das Problem großer Beratungshäuser: Seniors machen die Akquise, Juniors die Arbeit.
5. Kontinuierliche Gap-Analyse statt Einmal-Assessment
Gaps entstehen jeden Tag. Jede Schnittstelle, die nicht passt. Jeder Mitarbeiter, der geht. Jede Anforderung, die erst bei der Implementierung sichtbar wird.
Der Unterschied: Wenn unmögliche IT-Projekte doch gelingen
Referenzbeispiele aus der Praxis:
- 120 SAP-Systeme bei CIBER stabilisiert mit nur 4-Personen-Kernteam – als alle anderen aufgaben
- Migration des Telekom-Kernnetzes (160 Millionen Verbindungen) – obwohl die Telekom sagte „unmöglich“
- M/OMS Output Management System – 1988 entwickelt, nach 39 Jahren noch in Betrieb
Der Schlüssel: Unabhängige Senior-Expertise mit nachweisbarer Domain-Kontinuität, deren Geschäftsmodell die Identifikation von Problemen belohnt statt bestraft.
Fragen vor der Beauftragung
Bevor Sie externe IT-Expertise beauftragen, sollten Sie folgende Fragen beantworten:
- Referenzen: Hat der Anbieter nachweisbare Erfahrung in exakt diesem Kontext?
- Personal: Wer arbeitet tatsächlich am Projekt? Die Seniors aus dem Pitch oder ein Junior-Team?
- Interessenkonflikt: Hängt der Anbieter vom Folgegeschäft ab?
- Kontrolle: Wer behält die Projekthoheit? Gibt es eine unabhängige Prüfinstanz?
- Accountability: Was passiert bei Versagen? Wie ist die Haftung geregelt?
Schlussfolgerung
IT-Projekte scheitern nicht, weil externe Expertise grundsätzlich versagt. Sie scheitern, weil:
- Kostensenkung wichtiger ist als Qualifikation
- Behauptungen nicht verifiziert werden
- Kontrolle abgegeben wird
- Interessenkonflikte ignoriert werden
- Verträge keine Accountability erzwingen
Die dokumentierten Schäden – von 64 Millionen USD bei Revlon bis über 1 Milliarde USD bei National Grid – sind keine Naturkatastrophen. Sie sind das vorhersagbare Ergebnis vorhersagbarer Entscheidungen.
Die Frage ist nicht: Externe Expertise ja oder nein?
Die Frage ist: Welche externe Expertise, unter welchen Bedingungen, mit welcher Accountability?
Wenn niemand traut sich ran und alle sagen „geht nicht“ – dann braucht es einen IT Troubleshooter Stuttgart, der gescheiterte Projekte retten, die unmögliche IT Migration möglich machen, Ihre IT-Krise lösen und unmögliche IT-Projekte realisieren kann – auch wenn McKinsey aufgibt.
Über den Autor
Michael Schmid ist Principal Consultant und Inhaber der it-dialog e.K. (gegründet 2000). Als Physiker mit über 40 Jahren IT-Erfahrung positioniert er sich als unabhängiger Experte für kontinuierliche Gap-Analyse in kritischen IT-Projekten.
Sein Ansatz unterscheidet sich von klassischer Beratung: Keine Implementierung, keine Teams, kein Folgegeschäft-Interesse. Stattdessen: Identifikation dessen, was nicht funktionieren wird – bevor die Millionen verbrannt sind.
Nehmen Sie Kontakt auf, wenn Sie vor unmöglichen IT-Projekten stehen: Kontakt | LinkedIn
Diese Studie basiert auf öffentlichen Gerichtsakten, Branchenstudien und dokumentierten Projektkatastrophen. Vollständige Quellenangaben auf Anfrage verfügbar.