Wie man diese Risiken vermeidet

Die meisten Risiken lassen sich vermeiden, wenn die Reihenfolge stimmt.

Discovery zuerst: echtes Verständnis dafür, wie das Unternehmen heute läuft, wo Engpässe entstehen, welche Ziele relevant sind und welche operativen Abhängigkeiten wirklich kritisch sind.

Dazu gehört auch Datenklarheit: Welche Kundendaten, Produktdaten, Preise, Bestände, offenen Aufträge und kaufmännischen Informationen müssen wirklich sauber sein, bevor sie ins neue System wandern? Eine ERP-Migration sollte keine alten Datenunsicherheiten in ein neues System übertragen.

Dann Solutioning: Welche Rollen braucht es? Welche Übergaben müssen sauber definiert werden? Wo reicht Standard? Wo ist Anpassung sinnvoll?

Erst dann entscheiden, was in Phase 1 gehört und was bewusst draußen bleibt.

Die Umsetzung sollte als belastbares Grundgerüst verstanden werden und nicht als vollständige Migration der Vergangenheit: echte Strukturdaten, echte Beispiele, echte Key User, echte Validierung.

Diese Validierung sollte nicht nur in abstrakten Demos passieren. Entscheidend sind Dry Runs mit echten Fällen: echte Aufträge, echte Sonderfälle, echte Daten und die Menschen, die später damit arbeiten. Erst wenn ein Prozess mit realistischen Beispielen stabil durchläuft, sieht man, ob die Systemlogik wirklich funktioniert.

Nach dem Go-Live beginnt die Stabilisierung. In den ersten Wochen entstehen Fragen, Frust, Routinen und neue Erkenntnisse. Genau dort entscheidet sich, ob ein System wirklich angenommen wird oder die Organisation in alte Muster zurückfällt.

Diese Phase sollte bewusst geplant werden und nicht als Restarbeit nebenbei laufen. In den ersten Wochen nach Go-live braucht es klare Ansprechpartner, schnelle Fehlerklärung, aktive Nachschulung und einen sauberen Prozess, um echte Verbesserungen von hektischen Sonderwünschen zu unterscheiden. Sonst wird Hypercare schnell zu dauerhaftem Ausnahmezustand.

Was tun, wenn die Implementierung bereits schief läuft?

Nicht jedes problematische Projekt ist verloren. Viele Unternehmen treffen hier aber die falsche Entscheidung: Sie wechseln vorschnell die Software. Oder den Partner, ohne die Ursache zu verstehen. Oder sie arrangieren sich mit einem Setup, das dauerhaft Misstrauen und Ineffizienz erzeugt.

Der bessere erste Schritt ist Diagnose: Was ist ein Prozessproblem? Was ist ein Setup-Problem? Was ist ein Nutzungsproblem? Welche Komplexität wurde künstlich erzeugt? Was lässt sich stabilisieren, was muss neu gedacht werden?

Erst danach ergibt es Sinn, über Weiterentwicklung, Re-Implementierung oder Partnerwechsel zu sprechen.

Oft zeigt sich: Odoo ist nicht das eigentliche Problem. Das Problem ist die Art, wie Entscheidungen getroffen, Prozesse verstanden und Anpassungen gebaut wurden.

Fazit

Die meisten ERP-Projekte scheitern, weil die Einführung die falschen Dinge in der falschen Reihenfolge getan hat: Customizing vor Prozessverständnis, Scope vor Zielbild, Go-Live vor echter Verankerung.

Gerade bei flexiblen Systemen wie Odoo hat das seinen Preis. Was im Setup unklar ist, wird im Betrieb zum Problem. Das System selbst ist dabei selten das Thema. Die Frage ist immer, mit welcher Klarheit man in das Projekt gegangen ist und ob diese Klarheit wirklich vorhanden war oder nur so aussah.

FAQs

Woran erkennen wir, ob unser ERP-Projekt überhaupt startklar ist?

Startklar ist ein ERP-Projekt erst, wenn vier Dinge klar sind: Was soll konkret besser werden, welche Prozesse gehören in den ersten Scope, wer entscheidet intern verbindlich und woran wird Erfolg gemessen.

Es muss vor der Umsetzung nicht jedes Detail gelöst sein. Das wäre unrealistisch. Aber es braucht genug Klarheit, damit das Projekt nicht zu einer langen Reihe reaktiver Einzelentscheidungen wird.

Ein gutes Zeichen ist, wenn das Team diese Fragen in einfachen Worten beantworten kann: Welches Geschäftsproblem lösen wir? Welche Abläufe sind in Phase 1 wirklich kritisch? Welche Themen bleiben bewusst draußen? Wer entscheidet, wenn Fachbereiche unterschiedliche Anforderungen haben? Woran merken wir sechs Monate nach Go-live, dass das Projekt erfolgreich war?

Wenn diese Antworten noch unscharf sind, sollte das Projekt nicht direkt in die Implementierung gehen. Dann braucht es zuerst eine bessere Discovery.

Sollten wir eine laufende ERP-Implementierung pausieren, wenn es schon chaotisch wirkt?

Manchmal ja. Pausieren heißt nicht, das Projekt zu beenden. Es heißt, blinde Umsetzung kurz zu stoppen, um zu verstehen, was gerade wirklich schiefläuft.

Wenn das Team ständig über neue Features diskutiert, Workarounds baut, bevor der Standard sauber getestet wurde, oder jede Woche den Scope verändert, wird mehr Geschwindigkeit das Projekt meistens schlechter machen. Dann ist der bessere Schritt: einmal sauber diagnostizieren.

Liegt das Problem an unklaren Prozessen? An fehlender Ownership? An einem schlechten Setup? An schwacher interner Entscheidungslogik? Oder an einem Partner, der zu wenig führt und zu wenig hinterfragt?

Eine kurze Pause für Klarheit ist fast immer günstiger als Monate an Implementierungsschulden.

Wie viel Prozessdokumentation brauchen wir vor einem ERP-Projekt?

Ihr braucht keine 200-seitige Prozessdokumentation. Ihr braucht genug Prozessklarheit, um gute Systementscheidungen zu treffen.

Das heißt: Ihr müsst verstehen, wodurch ein Prozess ausgelöst wird, wer beteiligt ist, welche Daten gebraucht werden, wo Übergaben passieren, welche Sonderfälle regelmäßig auftreten und wo der heutige Ablauf bricht.

Entscheidend ist nicht, ob die Dokumentation schön aussieht. Entscheidend ist, ob alle Beteiligten dasselbe Verständnis vom operativen Ablauf haben.

Wenn ein Prozess nur im Kopf einzelner Personen existiert, ist er nicht bereit für ERP. Und wenn niemand erklären kann, warum ein Schritt überhaupt existiert, sollte er hinterfragt werden, bevor er zur Systemlogik wird.

Welche Daten sollten vor einer ERP-Implementierung bereinigt werden?

Nicht alle alten Daten müssen perfekt sein. Aber alle Daten, die künftig operative Entscheidungen steuern, müssen sauber genug sein.

Dazu gehören vor allem Kundendaten, Produktdaten, Preise, Bestände, Lieferanten, offene Aufträge, offene Rechnungen, Buchhaltungslogik und relevante historische Bewegungen. Entscheidend ist nicht, möglichst viel Vergangenheit zu migrieren. Entscheidend ist, dass das neue System mit belastbaren Informationen startet.

Wenn Dubletten, alte Artikel, unklare Preislogiken oder widersprüchliche Bestände ungeprüft übernommen werden, verschiebt sich das Problem nur. Dann sieht das neue System moderner aus, aber die Unsicherheit bleibt.

Die bessere Frage lautet daher: „Welche Daten müssen stimmen, damit Teams im Alltag bessere Entscheidungen treffen können?“

Wer sollte ein ERP-Projekt intern verantworten?

Ein ERP-Projekt braucht einen Business Owner (nicht nur einen IT-Ansprechpartner).

Diese Person muss das operative Ziel verstehen, Entscheidungen treffen oder eskalieren können und die Perspektiven aus Operations, Finance, Sales, Service, Lager oder Einkauf zusammenbringen.

Sie muss die Richtung halten: Prioritäten, Scope, Zielbild, Trade-offs, Entscheidungsqualität und interne Verankerung.

Wenn niemand das ERP-Projekt intern wirklich besitzt, passieren meist zwei Dinge: Entweder trifft der Implementierungspartner faktisch Business-Entscheidungen, die das Unternehmen selbst treffen müsste. Oder das Projekt driftet, weil niemand Konflikte sauber auflöst.

Ist unser Implementierungspartner verantwortlich dafür, diese Risiken zu verhindern?

Teilweise, aber nicht allein. Ein guter Implementierungspartner sollte unklare Anforderungen hinterfragen, verstehen wollen, warum ein Prozess heute so läuft, Trade-offs erklären, unnötiges Customizing bremsen und messy Business Reality in ein funktionierendes Systemdesign übersetzen.

Aber ein Partner ersetzt keine interne Verantwortung. Er kann führen, strukturieren und bessere Optionen vorschlagen. Er kann aber nicht vollständig entscheiden, wie euer Unternehmen künftig arbeiten soll.

Gefährlich wird es, wenn beide Seiten auf die jeweils andere warten: Das Unternehmen erwartet, dass der Partner „das schon richtig umsetzt“, während der Partner erwartet, dass das Unternehmen genau weiß, was es will. Genau dort beginnen viele ERP-Projekte leise zu kippen.

Woran erkennen wir, ob unser Partner das Problem ist oder unsere interne Klarheit?

Schaut auf das Muster: Wenn euer Team Prozesse, Prioritäten, Ownership, Erfolgskriterien oder den Scope der ersten Phase nicht klar erklären kann, liegt das Problem wahrscheinlich zuerst in der internen Klarheit.

Wenn euer Team aber valide Business-Fragen stellt und der Partner hauptsächlich mit Konfigurationsoptionen, Feature-Erklärungen oder „ja, das können wir bauen“ antwortet, kann der Partner Teil des Problems sein.

Ein starker Partner fragt nicht nur: „Was sollen wir bauen?“ Er fragt: „Was wollt ihr erreichen, und ergibt dieser Weg wirklich Sinn?“

In vielen schwierigen Projekten ist es beides: Das Unternehmen hat zu wenig Klarheit, und der Partner schafft nicht genug Struktur, um diese Unklarheit produktiv aufzulösen.

Wann ist Customizing wirklich sinnvoll?

Customizing ist sinnvoll, wenn der Standard einen geschäftskritischen Prozess nicht ausreichend abbildet und klar verstanden wurde, warum diese Anforderung operativ relevant ist.

Customizing ist nicht sinnvoll, nur weil „wir das heute so machen“.

Vor jeder Anpassung sollten diese Fragen beantwortet sein: Haben wir den Standard wirklich getestet? Verstehen wir den Business Impact der Lücke? Ist die Anforderung kritisch oder nur Gewohnheit? Reduziert die Anpassung Komplexität oder erzeugt sie langfristig neue Wartungslast? Wer besitzt diese Anpassung nach Go-live?

Gutes Customizing macht einen kritischen Ablauf besser. Schlechtes Customizing konserviert alte Komplexität in neuer Software.

Wie viel Odoo-Standard sollten wir nutzen, bevor wir anpassen?

Mehr, als viele Teams am Anfang glauben. Odoo-Standard sollte meistens der Ausgangspunkt sein, weil er gute Fragen erzwingt: Welche Teile unseres heutigen Prozesses sind wirklich notwendig? Wo ist Komplexität nur entstanden, weil alte Tools uns dazu gezwungen haben? Wo hängt das Team an einem Workaround, der die Migration eigentlich nicht überleben sollte?

Das heißt nicht, Standard blind zu akzeptieren. Es heißt, Standard erst zu verstehen, bevor man ihn ersetzt.

Eine gute Regel: Erst customizen, wenn ihr sauber erklären könnt, warum der Standard nicht reicht, welches Geschäftsergebnis die Anpassung verbessert und welche langfristige Komplexität sie erzeugt.

Was ist der größte Fehler in Phase 1?

Zu viel in Phase 1 zu packen. Sie sollte keine vollständige Migration aller historischen Prozesse, Sonderfälle, Wunschlisten und fachbereichsspezifischen Vorlieben sein. Phase 1 sollte ein belastbares operatives Grundgerüst schaffen.

Das Ziel ist nicht, sofort alles zu lösen. Das Ziel ist, einen funktionierenden Kern live zu bringen, den die Organisation wirklich nutzen kann.

Eine gute Phase 1 hat klare Grenzen: welche Prozesse enthalten sind, welche bewusst später kommen, welche Daten sauber sein müssen, welche Nutzer geschult werden und welche KPIs zeigen, ob das neue Setup funktioniert.

Wenn Phase 1 zu „alles, was wir irgendwann brauchen könnten“ wird, wird das Projekt langsamer, riskanter und schwerer zu adoptieren.

Wie verhindern wir Scope Creep in Phase 1?

Indem ihr nicht jede plausible Anforderung automatisch als Phase-1-Thema behandelt.

Scope Creep entsteht oft schleichend. Ein Fachbereich braucht noch eine Sonderlogik, ein anderer möchte ein zusätzliches Reporting, jemand erinnert sich an einen Ausnahmefall, der „unbedingt“ mitgedacht werden muss. Jede einzelne Anforderung klingt nachvollziehbar. Zusammen machen sie das Projekt schwerfällig.

Die sauberste Regel ist: Phase 1 enthält nur, was für den stabilen End-to-End-Kernprozess notwendig ist. Alles andere kommt in ein bewusst geführtes Backlog.

Wie entscheiden wir, was in Phase 1 gehört?

Startet bei operativen Abhängigkeiten und nicht bei Wunschlisten einzelner Fachbereiche.

Ein Prozess gehört in Phase 1, wenn er notwendig ist, damit der Kernprozess end-to-end funktioniert. Zum Beispiel: Lead zu Angebot, Angebot zu Auftrag, Auftrag zu Lieferung, Lieferung zu Rechnung, Rechnung zu kaufmännischer Sicht.

Nice-to-have-Verbesserungen, lokale Optimierungen, fortgeschrittene Automationen und Randfälle können oft warten.

Die bessere Entscheidungsfrage lautet: Bricht unser Operating Model, wenn wir dieses Thema nicht in Phase 1 aufnehmen oder wird es nur weniger elegant?

Dieser Unterschied ist wichtig. ERP-Projekte scheitern, wenn alles kritisch wird.

Woran sollten wir den Erfolg eines ERP-Projekts messen?

Nicht daran, ob das System live gegangen ist. Das ist zu niedrig gegriffen.

Bessere Erfolgskriterien sind operativ: weniger manuelle Übergaben, kürzere Durchlaufzeiten von Angebot zu Auftrag, weniger Abrechnungskorrekturen, verlässlichere Lager- oder Projektdaten, schnellere Sicht auf Monatszahlen, weniger Excel-Workarounds, bessere Margentransparenz und höhere Nutzung durch Key User.

Die konkreten KPIs hängen vom Unternehmen ab. Aber jedes ERP-Projekt sollte Erfolg daran messen, ob echte Arbeit einfacher, schneller, zuverlässiger oder besser steuerbar wird.

Wenn Erfolg nur heißt „Odoo ist live“, ist die Messlatte falsch gesetzt.

Was bedeutet es, wenn das Team nach Go-live weiter Excel nutzt?

Dann vertraut das Team dem System noch nicht vollständig.

Das heißt nicht automatisch, dass das ERP schlecht ist. Meistens bedeutet es eines von drei Dingen: Der Prozess im System passt nicht zur Arbeitsrealität, die Nutzer wurden nicht sauber eingebunden oder die Daten im System sind nicht zuverlässig genug.

Excel ist ein Symptom. Die eigentliche Frage lautet: Welche Aufgabe übernimmt Excel noch, die das ERP nicht gut genug löst?

Wenn Excel gelegentlich für Analyse genutzt wird, ist das unproblematisch. Wenn Excel aber als operative Brücke zwischen Teams dient, hat das ERP-Setup das eigentliche Problem nicht gelöst.

Was sollte in den ersten Wochen nach Go-live passieren?

Die ersten Wochen nach Go-live sollten als bewusste Stabilisierung verstanden werden.

In dieser Phase zeigt sich, wo Nutzer unsicher sind, welche Daten nicht sauber genug sind, welche Prozesse noch haken und welche Workarounds wieder auftauchen. Genau deshalb braucht es klare Ansprechpartner, regelmäßige kurze Feedbackschleifen, schnelle Priorisierung und gezielte Nachschulung.

Nicht jede Rückmeldung ist sofort ein Customizing-Auftrag. Manche Probleme sind Schulungsthemen. Manche sind Datenprobleme. Manche sind echte Prozesslücken.

Die wichtigste Aufgabe ist, sauber zu unterscheiden: Was muss stabilisiert werden, was muss verbessert werden und was ist nur Anfangsirritation?

Wie früh sollten Key User eingebunden werden?

Früh genug, um das System mitzugestalten und nicht nur, um es später erklärt zu bekommen.

Key User sollten nicht erst kurz vor Go-live in Trainings involviert werden. Sie sollten reale Beispiele validieren, Sonderfälle testen, fehlenden Kontext sichtbar machen und erklären, wie Arbeit in ihrem Bereich wirklich passiert.

Die besten Key User sind die Menschen, die die tägliche Arbeit verstehen, im Team glaubwürdig sind und zwischen operativer Realität und Systemlogik übersetzen können.

Wenn Key User erst kurz vor Go-live eingebunden werden, betreiben sie meist Schadensbegrenzung. Dann ist es zu spät.

Wie sollten ERP-Prozesse vor dem Go-live getestet werden?

Gute Tests nutzen echte Beispiele aus dem Alltag: echte Kunden, echte Artikel, echte Preise, echte Sonderfälle, echte Rollen und echte Übergaben zwischen Teams. Der Test sollte zeigen, ob ein Prozess wirklich von Anfang bis Ende funktioniert — nicht nur, ob ein einzelnes Modul korrekt eingerichtet ist.

Besonders wichtig sind Fälle, die heute schon Reibung erzeugen: Teilstornos, Sonderpreise, abweichende Lieferadressen, Rückfragen aus der Buchhaltung, fehlende Bestände, Projektänderungen oder manuelle Workarounds.

Wenn ein Prozess nur im Demo-Szenario funktioniert, ist er noch nicht bereit für den Go-live.

Ist ERP-Implementierung eher ein Technologieprojekt oder ein Organisationsprojekt?

Ein Organisationsprojekt mit Technologieanteil.

Die Software ist wichtig. Aber die größeren Fragen sind organisatorisch: Wie soll Arbeit künftig über Teams hinweg laufen? Wer besitzt welche Entscheidungen? Welche Daten gelten? Welche Sonderfälle sind relevant? Was soll standardisiert werden? Wo braucht das Unternehmen Flexibilität? Wie wird das System im Alltag genutzt?

Wenn ERP als reines Technologieprojekt behandelt wird, optimieren Teams Konfigurationen und übersehen das Operating Model.

Deshalb sind viele ERP-Probleme in Wahrheit keine Systemprobleme. Es sind unklare Business-Entscheidungen, die durch das System sichtbar werden.

Was sollten wir zuerst tun, wenn wir glauben, dass unser ERP-Projekt im Risiko ist?

Macht zuerst eine kurze Projektdiagnose, bevor ihr Software, Partner oder Scope wechselt.

Prüft das Projekt entlang von fünf Bereichen: Zielbild, Prozessklarheit, Scope, Ownership und Adoption. Danach lässt sich besser erkennen, wo das Risiko wirklich entsteht.

Springt nicht sofort zu „wir brauchen ein anderes System“ oder „wir brauchen einen anderen Partner“. Manchmal stimmt das. Aber oft liegt das eigentliche Problem darin, dass das Projekt nie genug Klarheit hatte.

Der erste sinnvolle Schritt ist bessere Diagnose.