Eine 5-Minuten-Lektüre für CIOs, die keine Lust mehr auf 100-Millionen-Euro-Desaster haben
Kernaussagen auf einen Blick:
- 70% aller SAP-Großprojekte überschreiten Budget und Zeitplan dramatisch
- Validiertes Lernen reduziert das Projektrisiko um bis zu 50%
- Frühzeitige Hypothesentests mit echten Endnutzern verhindern kostspielige Kursänderungen
- KI-Agenten und Prompt Engineering erfordern eigene Validierungsstrategien
- Wissenstransfer in Krisenzeiten wird zum entscheidenden Erfolgsfaktor
Liebe Kolleginnen und Kollegen,
kennen Sie das? Da sitzt man als CIO in der Aufsichtsratssitzung, und der Vorstand fragt mal wieder: „Wie läuft denn unser SAP-Projekt?“ Und während man innerlich die Schweißperlen auf der Stirn spürt, antwortet man tapfer: „Wir sind noch im Plan.“ Plan? Welcher Plan? Der ursprüngliche ist längst Makulatur, der zweite wurde stillschweigend begraben, und der dritte… nun ja, der ist kreativ.
So geht es nicht nur Ihnen. Laut aktuellen Studien scheitern über 70% aller SAP-Großprojekte an ihren ursprünglichen Zielen. Die Gründe sind immer dieselben: unrealistische Annahmen, fehlender Realitätsbezug und – mein Lieblings-Klassiker – das „Big Bang“-Denken.
Was ist validiertes Lernen in IT-Großprojekten?
Validiertes Lernen in IT-Großprojekten ist ein empirischer Ansatz, der systematisch Hypothesen über Geschäftsprozesse, Nutzeranforderungen und technische Lösungen durch kontrollierte Experimente mit echten Anwendern überprüft. Anstatt monatelang im Elfenbeinturm zu planen, testen wir unsere Annahmen frühzeitig und kontinuierlich mit der Realität.
Der Unterschied zu traditionellen Methoden? Wir gehen nicht davon aus, dass wir von Anfang an alles richtig wissen. Wir akzeptieren Unwissen als Ausgangspunkt und machen es zu unserem Vorteil.
Der Irrsinn des traditionellen Vorgehens
Schauen wir uns mal an, wie IT-Großprojekte traditionell ablaufen:
Phase 1: Sechs Monate Requirements-Engineering. Das Fachteam erklärt den Consultants die Welt, die Consultants übersetzen das in SAP-Sprech, und heraus kommt ein 500-Seiten-Dokument, das niemand versteht.
Phase 2: Weitere sechs Monate Customizing. Wir bauen etwas, von dem wir glauben, dass es das ist, was die Fachabteilung will – basierend auf dem, was wir glauben verstanden zu haben.
Phase 3: Go-Live. Der große Tag. Die Nutzer sehen zum ersten Mal, was wir gebaut haben. Und dann der Schock: „Das haben wir nie so gewollt!“ „Das können wir so nicht arbeiten!“ „Wo ist denn die Funktion X geblieben?“
Phase 4: Krisenmodus. Change Requests hageln herein, das Budget explodiert, Termine werden verschoben, und plötzlich brauchen wir einen Krisenmanager.
Kommt Ihnen bekannt vor? Herzlich willkommen im Club der SAP-Großprojekt-Überlebenden.
Der Weg des validierten Lernens
Validiertes Lernen dreht diesen Wahnsinn um. Statt zu raten, testen wir. Statt zu hoffen, wissen wir. Hier die Kernprinzipien für SAP-Großprojekte:
1. Hypothesen statt Wahrheiten
Jede Anforderung ist zunächst nur eine Hypothese. „Die Buchhaltung braucht diese Funktion täglich“ ist keine Tatsache, sondern eine Annahme, die es zu validieren gilt.
2. Minimum Viable Processes (MVP)
Anstatt das perfekte SAP-System zu bauen, entwickeln wir zunächst die einfachste Version eines Geschäftsprozesses, die gerade noch funktioniert. Dann testen wir diese mit echten Nutzern.
3. Build-Measure-Learn in IT-Projekten
- Build: Wir implementieren eine Hypothese als Prototyp oder Teilfunktion
- Measure: Wir messen die Nutzung, Performance und Zufriedenheit
- Learn: Wir ziehen Schlüsse und passen unsere nächsten Schritte an
4. Geschwindigkeit vor Perfektion
Ein funktionierender Prototyp nach vier Wochen ist mehr wert als die perfekte Lösung nach vier Monaten – die sich dann als falsch herausstellt.
Praktische Umsetzung: Ein Beispiel aus der Realität
Lassen Sie mich ein konkretes Beispiel aus einem SAP S/4HANA-Projekt erzählen:
Ursprüngliche Annahme: Unsere Vertriebsmitarbeiter brauchen eine mobile App für Kundenbesuche mit 47 verschiedenen Datenfeldern.“
Validiertes Lernen Ansatz: Wir haben einen einfachen Prototyp mit nur fünf Kernfeldern entwickelt und diesen zwei Wochen lang von zehn Vertriebsmitarbeitern testen lassen.
Ergebnis: Die Mitarbeiter nutzten nur drei der fünf Felder regelmäßig. Dafür wünschten sie sich eine Funktion, an die niemand gedacht hatte: die Möglichkeit, Fotos von Produkten beim Kunden zu machen und diese direkt zu kommentieren.
Wären wir traditionell vorgegangen, hätten wir Monate damit verbracht, die 47-Felder-App zu entwickeln – die niemand genutzt hätte.
KI-Agenten im SAP-Umfeld: Wenn Algorithmen auf Geschäftsprozesse treffen
Und dann kam die KI-Revolution. Plötzlich wollen alle ChatGPT in SAP integrieren, KI-Agenten für die Rechnungsprüfung einsetzen und mit Prompt Engineering die Effizienz steigern. Wunderbar! Nur leider mit demselben „Big Bang“-Denken wie eh und je.
Die neue Illusion: „Wir trainieren einen KI-Agenten drei Monate lang, und dann automatisiert er 80% unserer Finanzbuchhaltung.“
Die Realität: KI-Systeme sind noch unberechenbarer als SAP-Customizing. Was heute perfekt funktioniert, kann morgen komplett daneben liegen – besonders bei neuen Datenkonstellationen oder veränderten Geschäftsprozessen.
Validiertes Lernen für KI-Agenten: Ein Praxisbeispiel
Lassen Sie mich von einem aktuellen Projekt erzählen, bei dem wir KI-Agenten für die automatische Kategorisierung von Eingangsrechnungen in SAP implementiert haben:
Ursprüngliche Annahme: „Unser KI-Agent erkennt nach dem Training alle Rechnungstypen mit 95% Genauigkeit und kategorisiert sie automatisch in die richtigen SAP-Konten.“
Was wir stattdessen gemacht haben:
Phase 1 – Minimum Viable AI (MVA): Wir haben den KI-Agenten zunächst nur mit 100 typischen Rechnungen eines einzigen Lieferanten trainiert und ihn nur für diesen Lieferanten scharf geschaltet.
Phase 2 – Measurement: Nach einer Woche: 78% korrekte Kategorisierung – nicht schlecht, aber die 22% Fehler kosteten mehr Zeit in der manuellen Nachbearbeitung als gedacht.
Phase 3 – Learning & Iteration (Timebox: 3 Tage): Wir analysierten die Fehlerpattern und entdeckten: Der Agent scheiterte nicht an komplexen Rechnungen, sondern an banalen Formatvariationen (PDF vs. gescanntes Dokument vs. E-Mail-Rechnung). Hätten wir uns hier in wochenlangen Analysen verloren, wäre das Projekt gestorben.
Phase 4 – Prompt Engineering Iteration (Timebox: 2 Wochen): Statt das gesamte KI-Modell neu zu trainieren, optimierten wir die Prompts für verschiedene Dokumenttypen. Die neue Erkennungsrate: 94%. Die Timebox zwang uns, pragmatische statt perfekte Lösungen zu finden.
Das Ergebnis nach drei Monaten: Ein KI-System, das tatsächlich funktioniert – aber ganz anders als ursprünglich geplant. Heute arbeitet es mit 15 verschiedenen Lieferanten und einer Genauigkeit von 91%. Hätten wir mit dem „Big Bang“-Ansatz alle Lieferanten gleichzeitig angegangen, wären wir heute noch am Debuggen.
Prompt Engineering als kontinuierlicher Lernprozess – mit Timeboxing
Besonders beim Prompt Engineering – der Kunst, KI-Systemen die richtigen Fragen zu stellen – ist validiertes Lernen unverzichtbar. Ein Prompt, der in der Testumgebung brilliert, kann in der Praxis völlig versagen.
Typische Prompt-Hypothese: „Wenn ich dem KI-Agenten sage ‚Analysiere diese SAP-Transaktion und erkläre Abweichungen‘, dann gibt er mir verwertbare Ergebnisse.“
Realität: Der Agent erklärt Ihnen ausführlich, warum 2+2=4 ist, ignoriert aber die kritische Budgetüberschreitung in Zeile 47.
Validiertes Vorgehen mit Timeboxing: Wir testen Prompts systematisch mit echten Daten (Timebox: 2 Stunden pro Prompt-Variante), messen die Relevanz der Antworten (Timebox: 30 Minuten Auswertung) und iterieren täglich (Timebox: maximal 3 Iterationen pro Tag). Manchmal reicht eine kleine Änderung wie „Fokussiere dich auf Abweichungen über 1000 Euro“ um die Nützlichkeit um 300% zu steigern.
Der Timeboxing-Trick: Ohne zeitliche Begrenzung würden wir ewig an dem „perfekten“ Prompt feilen. Mit der 2-Stunden-Regel finden wir schneller pragmatische Lösungen, die zu 90% funktionieren – statt nach Monaten eine theoretisch perfekte Lösung zu haben, die in der Praxis versagt.
Wissenstransfer in der Krise: Wenn das Kind schon in den Brunnen gefallen ist
Aber was, wenn das Projekt bereits in der Krise steckt? Hier kommt der Wissenstransfer ins Spiel. In kritischen Projektphasen müssen wir schnell verstehen:
- Was funktioniert wirklich?
- Wo sind die echten Schmerzpunkte?
- Was können wir schnell reparieren?
Validiertes Lernen hilft auch hier: Statt endlose Lessons-Learned-Workshops abzuhalten (die erfahrungsgemäß drei Tage dauern und nichts bringen), setzen wir Timeboxes. Jeder Workshop bekommt maximal 4 Stunden. In dieser Zeit testen wir konkrete Lösungsansätze mit den betroffenen Nutzern. Schnell, iterativ, evidenzbasiert.
Timeboxing in der Krise bedeutet: Lieber drei pragmatische Lösungen in einer Woche implementieren als eine theoretisch perfekte Lösung in einem Monat planen – während das Projekt weiter brennt.
Die häufigsten Einwände (und warum sie falsch sind)
„Das dauert zu lange“ – Falsch. Validiertes Lernen ist schneller, weil wir Irrwege früh erkennen.
„Unsere Nutzer haben keine Zeit für Tests“ – Sie haben auch keine Zeit für ein System, das nicht funktioniert.
„SAP ist zu komplex für Experimente“ – Gerade deshalb brauchen wir validiertes Lernen. Komplexität macht Annahmen gefährlicher, nicht sicherer.
„KI ist zu unberechenbar für iterative Ansätze“ – Im Gegenteil! Gerade weil KI-Systeme unberechenbar sind, müssen wir sie in kontrollierten Umgebungen testen, bevor wir sie auf unsere kritischen Geschäftsprozesse loslassen.
„Timeboxing führt zu schlechteren Ergebnissen“ – Falsch. By setting clear time limits, timeboxing helps individuals and teams maintain focus, increase efficiency, and prevent tasks from dragging on indefinitely. In der Praxis zeigt sich: 90% Qualität in festgelegter Zeit ist besser als theoretische 100% Qualität, die nie fertig wird.
Konkrete Schritte für Ihr nächstes Projekt
1. Identifizieren Sie Ihre riskantesten Annahmen – meist sind das die Prozesse, die „schon immer so gemacht wurden“
2. Entwickeln Sie testbare Hypothesen – „Wenn wir X implementieren, dann werden Y% der Nutzer…“
3. Bauen Sie schnelle Prototypen – Mockups, Klickdummys, minimale Konfigurationen und nutzen Sie structured Walkthroughs
4. Testen Sie mit echten Nutzern – nicht mit dem Projektteam
5. Messen Sie konkrete Ergebnisse – Nutzungsdauer, Fehlerrate, Zufriedenheit
6. Lernen Sie und iterieren Sie – schnell und ohne Ego
Speziell für KI-Projekte:
7. Starten Sie mit Minimum Viable AI – ein KI-Agent für einen Prozess, einen Lieferanten, eine Abteilung
8. Messen Sie KI-Performance kontinuierlich – Genauigkeit, Verarbeitungszeit, Nutzerakzeptanz
9. Iterieren Sie Ihre Prompts täglich – kleine Änderungen, große Wirkung
10. Bereiten Sie Fallback-Strategien vor – was passiert, wenn die KI versagt?
Timeboxing-Regeln für alle Aktivitäten:
11. Setzen Sie feste Zeitgrenzen für jede Phase – Requirements (max. 2 Wochen), Prototyping (max. 1 Woche), Testing (max. 3 Tage)
12. Beenden Sie Diskussionen nach der Timebox – auch wenn noch nicht alle Fragen geklärt sind
13. Dokumentieren Sie offene Punkte Dokumentieren Sie offene Punkte – aber blockieren Sie nicht den Fortschritt
14. Timeboxing macht tasks feel more manageable – große Probleme werden in kleine, zeitlich begrenzte Häppchen zerlegt
Fazit: Mut zur empirischen Wahrheit – auch bei künstlicher Intelligenz
Validiertes Lernen ist keine Garantie für den Projekterfolg. Aber es ist die beste Methode, die wir haben, um das Risiko zu minimieren und den Nutzen zu maximieren. Das gilt für SAP-Customizing genauso wie für KI-Agenten und Prompt Engineering. Es erfordert Mut – den Mut zu sagen: „Ich weiß es nicht, aber ich finde es heraus.“
Die Zukunft gehört den Unternehmen, die schnell lernen können. Nicht denen, die perfekte Pläne machen. In einer Welt, in der sich sowohl Geschäftsanforderungen als auch KI-Technologien im Wochentakt ändern, ist die Fähigkeit zur kontinuierlichen Validierung und Anpassung der einzige nachhaltige Wettbewerbsvorteil.
Als CIO haben Sie die Wahl: Weiter im Blindflug navigieren oder endlich das Licht anmachen. Ihre Stakeholder, Ihr Budget, Ihre Nachtruhe und Ihre KI-Agenten werden es Ihnen danken.
Und falls Ihr aktuelles SAP-Projekt bereits brennt: Validiertes Lernen funktioniert auch als Feuerlöscher. Sprechen Sie uns gerne an.
Christoph Lefkes und Daniel Goldberg und Matthias Berth
Wir sind Experten für Krisenmanagement und Wissenstransfer in IT-Großprojekten. Wir begleiteten Unternehmen bei der erfolgreichen Umsetzung komplexer SAP-Transformationen und helfen dabei, aus Projektkrisen Lernerfahrungen zu machen.
Schreibe einen Kommentar