Zum Hauptinhalt springen
    SystemSelect · Beratung für Software-Auswahl

    30 Min · kostenlos

    Beratung anfragen

    Anfragen →

    Steckengebliebenes ERP-Projekt kundenseitig zurück auf Kurs

    Projektmuster für die kundenseitige Stabilisierung eines verzögerten ERP-Projekts; Verlauf und Kennzahlen sind illustrativ modelliert.

    Zuletzt fachlich geprüft:

    Evidenzstatus · Stand 2026-08-31

    Projektmuster · kein Kundennachweis

    Projektmuster · Kennzahlen modelliert

    Dieses 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

    KennzahlKlasseBaselineZeitraumBerechnungGrenze
    16 Wochen von Rot zu Go-liveModelliertZweimal verschobener Go-live-Termin im illustrativen AusgangsszenarioAb Mandatsstart der modellierten UmsetzungsbegleitungIm Szenario beschriebene Dauer von Mandatsstart bis modelliertem Go-liveKeine reale Projektakte; Verzugsursachen und Aufholpotenzial variieren stark je Projekt.
    ~70.000 € vermiedene MehrkostenModelliertSumme der im Szenario als strittig markierten Change-Request-ForderungenProjektlaufzeit der modellierten UmsetzungsbegleitungModellierte Differenz zwischen geforderten und nach Scope-Prüfung anerkannten Change-Request-BeträgenKeine echten Rechnungen oder Verhandlungsprotokolle; Beträge sind illustrativ.
    58 % → 100 % reale FertigstellungModelliert58 % Fertigstellungsgrad laut Selbstauskunft des Integrators im SzenarioBis zum modellierten Go-liveModellierte Neubewertung gegen harte Abnahmekriterien statt Fortschritts-SelbstauskunftFertigstellungsgrade sind im Ausgangszustand naturgemäß subjektiv; die Zahl ist ein Szenario-Kontrast, kein Audit-Ergebnis.
    0 eigene ImplementierungModelliertRollenverteilung im illustrativen MandatGesamte modellierte ProjektlaufzeitBeschreibung der im Szenario definierten Steuerungsrolle ohne eigene Entwicklungs-/KonfigurationsleistungStrukturmerkmal des Mandatstyps, keine gemessene Kennzahl.

    Auf einen Blick

    Branche
    Serienfertigung / Maschinenbau
    Unternehmensgröße
    210 Mitarbeitende
    Unsere Rolle
    Kundenseitiges PMO
    Dauer bis Go-Live
    16 Wochen

    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.

    Verzug
    Go-Live bereits zweimal verschoben, das Projekt lief im 14. statt geplanten 9. Monat
    Budget
    Implementierungsbudget zu 90 % verbraucht, Fertigstellung aber bei geschätzt 60 %
    Scope
    Change Requests des Integrators summierten sich unkontrolliert – niemand prüfte sie gegen den ursprünglichen Anforderungskatalog
    Steuerung
    Projektleitung lag beim IT-Leiter nebenbei zum Tagesgeschäft – keine belastbare Statusübersicht, Ampel stand grün
    Vertrauen
    Geschäftsführung und Integrator im Konflikt, wechselseitige Schuldzuweisungen, keine gemeinsame Faktenbasis

    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

    16 Wo.
    von Rot zu Go-Live
    das zuvor zweimal verschobene Projekt kam in 16 Wochen produktiv
    ~70.000 €
    vermiedene Mehrkosten
    durch Prüfung strittiger Change Requests und Nachverhandlung
    58 → 100 %
    reale Fertigstellung
    gegen harte Abnahmekriterien statt Selbstauskunft
    0
    eigene Implementierung
    wir haben gesteuert, nicht gebaut – Neutralität blieb intakt

    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