Das Problem: Warum ERP-Projekte scheitern
ERP-Migrationen scheitern meist nicht wegen schlechter Software. Sie scheitern wegen drei vermeidbarer Fehler:
- Prozesse wurden nicht verstanden — das System wird konfiguriert, bevor die echten Abläufe dokumentiert sind. Was in der Konfiguration "richtig" klingt, passt nicht zur Realität.
- Big-Bang-Go-Live — an einem Stichtag wird alles umgestellt. Wenn etwas schiefläuft, steht der Betrieb still.
- Change Management als Nachgedanke — das neue System ist live, aber die Mitarbeiter wissen nicht wie es funktioniert.
Die C-led Methodik adressiert alle drei Punkte systematisch.
Die Parallelbetrieb-Methode: Schritt für Schritt
Phase 1 — Business Process Diagnosis (Woche 1–2)
Bevor eine Zeile konfiguriert wird: Die echten Prozesse werden dokumentiert. Nicht die Soll-Prozesse aus dem Handbuch — die tatsächlichen Abläufe, mit allen Ausnahmen und Workarounds.
Das Ergebnis: ein Migrations-Blueprint mit klarem Scope, realistischer Timeline und identifizierten Risiken. Kein "das haben wir so nicht gewusst" nach Go-Live.
Phase 2 — Parallelsystem aufbauen (Woche 3–4)
Das alte System (z.B. SAP ECC) läuft unverändert weiter. Odoo wird daneben aufgebaut — mit den Daten-Mappings aus der Diagnose-Phase.
Wichtig: Kein Eingriff ins laufende System. Die Produktion merkt in dieser Phase gar nichts.
Phase 3 — Parallelbetrieb (Woche 5–10)
Beide Systeme laufen gleichzeitig. Echte Transaktionen werden im neuen System gespiegelt und geprüft. Mitarbeiter werden trainiert — im laufenden Betrieb, ohne Produktionsdruck.
Das ist die entscheidende Phase. Jeder Fehler wird hier gefunden — nicht nach Go-Live.
Phase 4 — Go-Live (Woche 11)
Die Umschaltung findet an einem Wochenende statt. Freitag Abend letzter Commit im alten System. Montag früh arbeitet alles in Odoo.
Das alte System bleibt 2–4 Wochen Read-Only. Falls etwas fehlt oder nachgeschaut werden muss: es ist da. In der Praxis ist diese Sicherheit nie gebraucht worden — aber sie schafft Vertrauen.
Warum das funktioniert: Keine Abkürzungen
Diagnose zuerst
2 Wochen Business Process Diagnosis eliminieren den häufigsten Scheitensgrund: Prozesse werden erst nach Go-Live verstanden. Mit Diagnose gibt es keine Überraschungen.
Parallelbetrieb als Standard
Big-Bang-Go-Lives sind vermeidbar. Parallelbetrieb kostet 2–3 Wochen mehr Zeit — spart aber potenzielle Wochen oder Monate Produktionsausfall.
Change Management parallel
Training findet während des Parallelbetriebs statt — im echten System, mit echten Daten, ohne Produktionsdruck. Mitarbeiter sind ab Tag 1 nach Go-Live produktiv.
Aus der Praxis: Maschinenbau 120 MA — Zero Produktionsausfälle
Ausgangssituation: SAP ECC läuft aus. S/4HANA-Angebot: 800k EUR + 14 Monate. Risiko einer langen Migrations-Phase inakzeptabel.
Prozess: Business Process Diagnosis (2 Wochen) → Odoo-Setup parallel (4 Wochen) → Parallelbetrieb und Mitarbeiter-Training (6 Wochen) → Go-Live an einem Wochenende.
Ergebnis: 12 Wochen total. Zero Produktionsausfälle. Mitarbeiter nach 3 Tagen vollständig produktiv.
"Das Team war nach 3 Tagen produktiv — das hätte ich so nicht für möglich gehalten."— Geschäftsführer, Fertigung (Maschinenbau), 120+ MA, NRW
FAQ
Mit Parallelbetrieb-Methode: 6–12 Wochen für Odoo-Implementierungen. Umschaltung: ein Wochenende. Altes System bleibt 2–4 Wochen Read-Only.
Das alte System ist noch aktiv (Read-Only). Rückkehr dauert Minuten. In der Praxis ist diese Notfall-Option noch nie genutzt worden — aber sie ist da.
Laut Gartner Research (2023): 55–75% aller ERP-Projekte scheitern oder überschreiten das Budget. Hauptgründe: Prozesse nicht verstanden, Big-Bang-Go-Live, fehlerhaftes Change Management. Die Business Process Diagnosis eliminiert den ersten und häufigsten Grund.
Nein. Die Parallelbetrieb-Methode funktioniert für jede ERP-Migration — SAP ECC, Shopware 5, Legacy-Systeme. Überall wo der Betrieb während der Migration weiterlaufen muss.