Yannick H.,
TLDR;
49% der IT-Projektfehler werden auf schlechte Entscheidungsprozesse zurückgeführt - nicht auf die Technologie selbst. Die typischen Fallen: Demo-getriebene Entscheidungen, Fokus auf Kaufpreis statt Gesamtkosten, Technologie vor Menschen, und der Glaube "wir sind speziell". Organisationen mit strukturierter Evaluation haben 78% bessere Ergebnisse. Der Unterschied zwischen Erfolg und Katastrophe liegt nicht in der Wahl - sondern im Prozess.
Die Statistik, die Sie kennen sollten
49% der IT-Projektfehler werden auf schlechte Vendor-Selection-Prozesse zurückgeführt.
(Quelle: Enterprise Software Selection Study)
Nicht auf die falsche Technologie. Nicht auf unfähige Mitarbeiter. Nicht auf unvorhersehbare Marktveränderungen.
Auf den Entscheidungsprozess.
Fast die Hälfte aller gescheiterten IT-Projekte scheitern, weil die Entscheidung falsch getroffen wurde - nicht weil die falsche Option gewählt wurde.
Das ist eine unbequeme Erkenntnis. Denn es bedeutet: Die Katastrophe war vermeidbar. Nicht durch mehr Budget. Nicht durch bessere Technologie. Sondern durch einen besseren Prozess.
Warum gute Manager schlechte IT-Entscheidungen treffen
Die meisten IT-Entscheidungen werden nicht rational getroffen. Sie werden emotional getroffen und nachträglich rationalisiert.
Das klingt hart. Aber schauen Sie sich an, wie typische IT-Entscheidungen ablaufen:
Ein Vendor macht eine beeindruckende Demo
Die Entscheider sind begeistert
Die Entscheidung fällt - oft schon in diesem Moment
Danach werden Gründe zusammengetragen, warum diese Entscheidung richtig ist
Die eigentlichen Business-Requirements? Werden oft erst nach der emotionalen Entscheidung definiert - um die Wahl zu rechtfertigen.
67% der Software-Projekte scheitern wegen falscher Build-vs-Buy-Entscheidungen. Nicht weil die Frage schwer ist. Sondern weil sie emotional beantwortet wird.
Die 5 Entscheidungsfallen
Nach hunderten von IT-Projekten sehen wir immer wieder dieselben Muster. Hier sind die fünf Fallen, in die Unternehmen am häufigsten tappen:
Falle 1: Die Demo-Falle
Das Muster: Eine beeindruckende Präsentation bestimmt die Entscheidung mehr als die echten Business-Anforderungen.
Wie es passiert:
Der Vendor zeigt eine perfekt choreografierte Demo
Features, die Sie nie brauchen werden, sehen spektakulär aus
Die Komplexität der echten Implementation wird nicht sichtbar
Referenzen werden genannt, aber nicht verifiziert
Die Konsequenz: Projekte mit 300% Kostenüberschreitung - weil die Realität nicht zur Demo passt.
Der Ausweg: Definieren Sie Ihre Requirements, bevor Sie die erste Demo sehen. Nicht danach.
Falle 2: Die Preis-Blindheit
Das Muster: Der Fokus liegt auf dem Anschaffungspreis - nicht auf den tatsächlichen Kosten.
Hier ist eine Zahl, die Sie kennen sollten:
Der Kaufpreis repräsentiert nur 15-20% der Total Cost of Ownership über 5-10 Jahre.
(Quelle: Enterprise Software Selection Guide)
Das bedeutet: 80-85% der Kosten entstehen nach dem Kauf.
Was fehlt in der Kalkulation:
Implementierungskosten (oft höher als die Lizenz)
Schulungsaufwand (für Jahre, nicht Wochen)
Wartung und Support
Integration mit bestehenden Systemen
Anpassungen und Customization
Opportunity-Kosten während der Transition
Die Konsequenz: Die "günstigste" Lösung wird zur teuersten.
Der Ausweg: Kalkulieren Sie TCO über 5-10 Jahre. Nicht den Listenpreis.
Falle 3: Der Technologie-Tunnel
Das Muster: Die Entscheidung fokussiert auf Technologie - Menschen und Prozesse werden ignoriert.
McKinsey hat dazu eine eindrückliche Zahl:
Organisationen, die in kulturelle Veränderung investieren, haben 5.3x höhere Erfolgsraten als solche, die sich nur auf Technologie konzentrieren.
(Quelle: McKinsey Digital Transformation Study)
5.3-mal. Das ist kein marginaler Unterschied. Das ist der Unterschied zwischen Erfolg und Misserfolg.
Wie es passiert:
Change Management wird als "Phase 2" geplant - wenn überhaupt
User Buy-in wird als selbstverständlich angenommen
Prozessänderungen werden unterschätzt
Training kommt zu spät und zu kurz
Die Konsequenz: 70% der Unternehmen können nicht nachverfolgen, ob neue Anwendungen überhaupt wie vorgesehen genutzt werden. Die Software ist da - aber niemand nutzt sie richtig.
Der Ausweg: Menschen vor Technologie. Change Management von Tag 1.
Falle 4: Die "Wir sind speziell"-Falle
Das Muster: Die Überzeugung, dass Standard-Lösungen für die eigenen, angeblich einzigartigen Anforderungen nicht funktionieren können.
Eine der häufigsten Aussagen in IT-Projekten: "Das ist bei uns anders."
In den meisten Fällen ist es das nicht.
67% der Build-vs-Buy-Entscheidungen scheitern - oft weil Unternehmen ihre Einzigartigkeit überschätzen und Custom-Lösungen bauen, wo Standard gereicht hätte.
Die Konsequenzen von Custom:
Höhere Entwicklungskosten
Wartungsabhängigkeit von internen oder externen Entwicklern
Keine Updates und Verbesserungen aus der Produkt-Community
Lock-in in Eigenentwicklungen
Der Ausweg: Fragen Sie sich ehrlich: Sind unsere Anforderungen wirklich einzigartig - oder glauben wir das nur?
Falle 5: Der Prozess-Skip
Das Muster: Strukturierte Evaluation wird übersprungen - aus Zeitdruck, Overconfidence, oder beidem.
Die Zahlen sprechen für sich:
78% der Organisationen berichten von besseren Ergebnissen nach Einführung strukturierter Vendor-Evaluation.
(Quelle: Enterprise Software Selection Study)
Wie es passiert:
"Wir kennen den Markt, wir brauchen keine formale Evaluation"
Zeitdruck: "Wir müssen bis Q3 live sein"
Ein Stakeholder hat bereits einen Favoriten
"Das haben wir schon immer so gemacht"
Die Konsequenz: Bauchgefühl statt Fakten. Und 49% Fehlerrate.
Der Ausweg: Strukturierter Prozess. Gewichtete Kriterien. Dokumentierte Entscheidungen.
Die 6 Fragen vor jeder IT-Entscheidung
Bevor Sie die nächste IT-Entscheidung treffen, stellen Sie sich diese Fragen:
1. Was sind unsere Business-Requirements - bevor wir Demos anschauen?
Definieren Sie, was Sie brauchen, bevor Ihnen jemand zeigt, was er verkaufen will. Sonst bestimmt der Vendor die Agenda.
2. Wie hoch sind die wahren Kosten über 5-10 Jahre?
Nicht der Listenpreis. Die Total Cost of Ownership. Mit Implementation, Schulung, Wartung, Integration, Anpassungen.
3. Wer muss diese Lösung täglich nutzen - und was brauchen sie?
Nicht was die IT will. Nicht was beeindruckend aussieht. Was die täglichen Nutzer brauchen, um produktiv zu sein.
4. Sind unsere Anforderungen wirklich einzigartig - oder glauben wir das nur?
Hinterfragen Sie die "bei uns ist das anders"-Aussagen. In 80% der Fälle ist es nicht anders genug für Custom-Development.
5. Was passiert, wenn dieses Projekt scheitert?
McKinsey sagt: 17% der grossen IT-Projekte bedrohen die Existenz des Unternehmens. Kennen Sie Ihr Risiko?
6. Können wir drei echte Referenzkunden sprechen?
Nicht die, die der Vendor vorschlägt. Echte Kunden mit ähnlichen Anforderungen. Mit kritischen Fragen.
Was gute IT-Entscheidungen gemeinsam haben
Nach hunderten von Projekten sehen wir klare Muster bei erfolgreichen IT-Entscheidungen:
Requirements vor Demos. Die Business-Anforderungen sind definiert und priorisiert, bevor der erste Vendor präsentiert.
TCO statt Kaufpreis. Die Entscheidung basiert auf 5-10-Jahres-Kosten, nicht auf dem günstigsten Angebot.
Menschen vor Technologie. Change Management startet mit der Entscheidung - nicht nach dem Go-Live.
Strukturierte Evaluation. Gewichtete Kriterien, Scoring-Systematik, dokumentierte Entscheidungswege.
Verifizierte Referenzen. Echte Gespräche mit echten Kunden - nicht Hochglanz-Case-Studies.
Die Frage, die bleibt
Nicht: "Welche Technologie brauchen wir?"
Sondern: "Wie treffen wir diese Entscheidung?"
49% der Projektfehler entstehen nicht durch falsche Wahl - sondern durch falschen Prozess. Der Unterschied zwischen Erfolg und Katastrophe liegt nicht in der Option, die Sie wählen. Er liegt in der Art, wie Sie entscheiden.
Der Unterschied
Die meisten IT-Berater verkaufen Ihnen eine Lösung.
Wir helfen Ihnen, die richtige Entscheidung zu treffen.
Der Unterschied: Wir haben kein Interesse daran, welchen Vendor Sie wählen. Wir haben Interesse daran, dass Ihr Projekt erfolgreich ist.
Das bedeutet:
Neutrale Bewertung ohne Vendor-Interesse
Strukturierter Entscheidungsprozess
Pattern Recognition aus hunderten Projekten
TCO-Kalkulation statt Angebots-Vergleich
Change Management von Anfang an
Quellen:
