Evidenzstatus · Stand 2026-08-31
Projektmuster · kein Kundennachweis
Projektmuster · Kennzahlen modelliertDieses Projektmuster verdichtet typische Anforderungen, Entscheidungen und Risiken aus der Beratungspraxis. Es beschreibt kein einzelnes Kundenmandat. Unternehmen, Verlauf und Kennzahlen sind illustrativ modelliert und dürfen nicht als gemessene Kundenergebnisse gelesen werden.
Interner Nachweis
Redaktionelles Szenario; im Repository liegt kein freigegebener Kundennachweis vor.
Datenschutz & Freigabe
Keine Kundendaten oder Original-Screenshots verwendet. Kundenfreigabe ist für dieses Projektmuster nicht anwendbar.
Kennzahlen-Nachweis
| Kennzahl | Klasse | Baseline | Zeitraum | Berechnung | Grenze |
|---|---|---|---|---|---|
| 16 Wochen von Rot zu Go-live | Modelliert | Zweimal verschobener Go-live-Termin im illustrativen Ausgangsszenario | Ab Mandatsstart der modellierten Umsetzungsbegleitung | Im Szenario beschriebene Dauer von Mandatsstart bis modelliertem Go-live | Keine reale Projektakte; Verzugsursachen und Aufholpotenzial variieren stark je Projekt. |
| ~70.000 € vermiedene Mehrkosten | Modelliert | Summe der im Szenario als strittig markierten Change-Request-Forderungen | Projektlaufzeit der modellierten Umsetzungsbegleitung | Modellierte Differenz zwischen geforderten und nach Scope-Prüfung anerkannten Change-Request-Beträgen | Keine echten Rechnungen oder Verhandlungsprotokolle; Beträge sind illustrativ. |
| 58 % → 100 % reale Fertigstellung | Modelliert | 58 % Fertigstellungsgrad laut Selbstauskunft des Integrators im Szenario | Bis zum modellierten Go-live | Modellierte Neubewertung gegen harte Abnahmekriterien statt Fortschritts-Selbstauskunft | Fertigstellungsgrade sind im Ausgangszustand naturgemäß subjektiv; die Zahl ist ein Szenario-Kontrast, kein Audit-Ergebnis. |
| 0 eigene Implementierung | Modelliert | Rollenverteilung im illustrativen Mandat | Gesamte modellierte Projektlaufzeit | Beschreibung der im Szenario definierten Steuerungsrolle ohne eigene Entwicklungs-/Konfigurationsleistung | Strukturmerkmal des Mandatstyps, keine gemessene Kennzahl. |
Auf einen Blick
Ausgangslage
Der Serienfertiger hatte sein ERP-System sorgfältig ausgewählt – die Auswahl war nicht das Problem. Das Projekt geriet in der Umsetzung aus dem Ruder: Der Implementierungspartner arbeitete, aber niemand auf Kundenseite steuerte ihn wirklich. Die Statusampel stand monatelang auf Grün, während Budget und Zeitplan längst gekippt waren.
Warum eine neutrale Steuerung – und nicht ein zweiter Integrator
- →Die Geschäftsführung wollte vor der nächsten Zahlung an den Integrator eine neutrale Einschätzung: Ist das Projekt zu retten – und wenn ja, wie?
- →Wichtig war, dass die Bewertung von jemandem kam, der weder am Integrator verdient noch selbst implementieren wollte – also keinen Anreiz hatte, das Projekt künstlich in die Länge zu ziehen.
- →Wir haben ausdrücklich nicht den Integrator ersetzt, sondern eine Steuerungsinstanz auf Kundenseite eingezogen, die vorher komplett fehlte.
Vorgehen: 5 Phasen in 22 Wochen
01Projekt-Check & Standortbestimmung (Woche 1–2)
- →Review von Projektvertrag, ursprünglichem Anforderungskatalog, Change-Request-Historie und offener Rechnungen
- →Interviews mit Fachbereichen, IT und dem Projektteam des Integrators – getrennt, für eine ehrliche Faktenlage
- →Echte Fertigstellungsgrad-Bewertung je Modul statt Selbstauskunft – Ergebnis: 58 % statt gemeldeter 85 %
- →Risiko-Ampel über 6 Dimensionen: Rot bei Scope-Kontrolle, Datenmigration und Abnahmeprozess
02Governance nachgezogen (Woche 3–5)
- →Lenkungsausschuss eingeführt: zweiwöchentlich, mit GF, IT, Fachbereich und Integrator an einem Tisch
- →Change Requests rückwirkend gegen den Anforderungskatalog geprüft – 40 % waren Bring-Schuld des Integrators, nicht zusätzlich zu bezahlen
- →Entscheidungs- und Risiko-Register eingeführt – erstmals eine gemeinsame, dokumentierte Faktenbasis
- →Neuer, realistischer Meilensteinplan mit harten Abnahmekriterien je Modul
03Partner-Steuerung & Nachverhandlung (Woche 4–10)
- →Wöchentliche Steuerung des Integrator-Teams gegen Backlog und Abnahmekriterien statt gegen Bauchgefühl
- →Strittige Change Requests neutral bewertet – Nachverhandlung führte zu Gutschrift und klarer Restleistungs-Definition
- →Test- und Migrationskonzept nachgeschärft: strukturierte Testfälle aus den Kernprozessen statt Ad-hoc-Klicktests
- →Scope eingefroren auf die Muss-Anforderungen bis Go-Live, Kann-Anforderungen in eine Phase 2 verschoben
04Cutover & Go-Live (Woche 11–16)
- →Cutover-Drehbuch mit Verantwortlichkeiten, Zeitfenstern und Rollback-Punkt erstellt und geprobt
- →Datenmigration in zwei Testläufen validiert, bevor die Produktivmigration freigegeben wurde
- →Go-Live über ein verlängertes Wochenende, mit klar definierten Abnahmekriterien für die Freigabe
- →Key-User vorab geschult, Hotline und Eskalationsweg für die erste Woche aufgesetzt
05Hypercare & Übergabe (Woche 16–22)
- →Vierwöchige Hypercare mit täglichem Stand-up, priorisierter Fehlerliste und klarer Zuordnung Integrator vs. Anwendung
- →Offene Punkte strukturiert abgearbeitet, Restleistungen gegen die Abnahmekriterien final abgenommen
- →Saubere Übergabe der Projektsteuerung an einen internen System-Owner inkl. Dokumentation
- →Phase-2-Backlog (Kann-Anforderungen) an das interne Team übergeben – ohne uns
Modellierte Ergebnisse
Qualitative Ergebnisse
- +Erstmals eine belastbare Statusübersicht – Geschäftsführung und Integrator arbeiteten auf einer gemeinsamen Faktenbasis statt gegeneinander
- +Change Requests wurden gegen den Anforderungskatalog geprüft, statt ungefiltert bezahlt zu werden
- +Die Muss-Anforderungen aus der ursprünglichen Auswahl landeten tatsächlich im Produktivsystem
- +Ein interner System-Owner übernahm nach Hypercare eine dokumentierte, stabile Anwendung
- +Der Integrator blieb im Boot – die Steuerung war unbequem, aber fair und faktenbasiert