12 E-Commerce-Expert*innen zeigen, wie Wachstum gelingt. → Hol dir unser ERP-Playbook.
12 E-Commerce-Expert*innen zeigen, wie Wachstum gelingt. → Hol dir unser ERP-Playbook.
ERP-Systemwechsel von WeClapp, Xentral oder JTL zu Odoo: Wie Unternehmen sauber migrieren (Ablauf, Risiken und typische Fehler)
ERP-Systemwechsel von WeClapp, Xentral oder JTL zu Odoo: Wie Unternehmen sauber migrieren (Ablauf, Risiken und typische Fehler)
Ein ERP-Systemwechsel beginnt selten mit einer direkten Systementscheidung.
Meistens entsteht er schleichend: Das aktuelle Setup funktioniert noch, aber immer mehr Arbeit passiert darum herum. Die Logistik führt eigene Listen, Finance traut den Zahlen nur bedingt, der Vertrieb kennt Sonderwege, Reports brauchen manuelle Nacharbeit und neue Mitarbeitende fragen irgendwann, warum so viel händisch übertragen wird.
Dann steht die Frage im Raum: „Sollten wir von weclapp, Xentral oder JTL zu Odoo wechseln?“
Viele Unternehmen wachsen aus ihren bisherigen ERP-, Warenwirtschafts- oder Tool-Setups heraus. Erfolgreich wird der Wechsel aber erst, wenn danach Arbeit klarer läuft, Daten belastbarer sind und Verantwortung besser im System abgebildet wird.
Alte Daten in einem neuen ERP reichen dafür nicht aus, alte Workarounds in einer moderneren Oberfläche auch nicht.
Der eigentliche Job ist größer: Das Unternehmen muss entscheiden, welche Arbeitsweise es in die nächste Wachstumsphase mitnimmt.
TL;DR
Ein ERP-Systemwechsel zu Odoo sollte kein 1:1-Umzug sein.
Viele Unternehmen wechseln nicht wegen eines einzelnen fehlenden Features, sondern weil ihre Systemlogik nicht mehr zur operativen Realität passt. Excel, Google Sheets, manuelle Übergaben, Schattenprozesse und widersprüchliche Zahlen sind Warnsignale.
Vor der Migration braucht es Prozessklarheit. Welche Abläufe gehören wirklich ins neue ERP? Welche Sonderfälle sind geschäftskritisch? Welche Daten müssen sauber sein? Was gehört in Phase 1? Welche Themen wandern bewusst ins Backlog?
Odoo kann sehr viel abbilden. Genau deshalb ist Klarheit so wichtig. Wer alte Workarounds nach Odoo überträgt, bekommt am Ende kein besseres Betriebssystem. Nur ein teureres Abbild alter Unklarheit.
Warum Unternehmen überhaupt über einen Wechsel zu Odoo nachdenken
weclapp, Xentral oder JTL können für eine bestimmte Unternehmensphase sehr sinnvoll sein. Viele Unternehmen starten damit aus guten Gründen: Sie brauchen Struktur, eine Warenwirtschaft, eine bessere Auftragsabwicklung, vielleicht eine erste Verbindung zwischen Shop, Lager und Buchhaltung.
Für eine Zeit reicht das. Dann wächst das Geschäft. Es kommen mehr Produkte, mehr Bestellungen, mehr Mitarbeitende, mehr Lagerlogik, mehr B2B-Kunden, mehr Sonderfälle, mehr Abstimmung mit Finance, mehr Anforderungen an Reporting und Steuerung.
Das Setup wächst meistens irgendwie mit. Ein neues Sheet hier. Eine App dort. Eine manuelle Übergabe. Ein zusätzlicher Report. Ein Workaround für einen Sonderfall. Eine Sonderregel, die nur zwei Menschen im Unternehmen verstehen.
Irgendwann entsteht ein Zustand, der von außen noch wie ein System aussieht. Im Alltag hängt der Betrieb aber an vielen kleinen Brücken zwischen Systemen, Teams und Köpfen.
Ein typisches Muster aus Projekten: Artikelverfügbarkeiten, erwartete Wareneingänge, Statusinformationen und operative Abstimmungen liegen in Google Sheets. Das alte ERP liefert einen Teil der Wahrheit, aber viele wichtige Informationen werden täglich manuell ergänzt. Das Team hat dadurch eine Art Transparenz. Allerdings nur, weil Menschen ständig Daten von einem Ort zum anderen übertragen.
Ich nenne solche Setups gerne „menschliche APIs“.
Menschen halten die Systeme synchron, schließen Prozesslücken, wissen, welche Ausnahme wann gilt, retten die operative Realität, die das System nicht vollständig abbildet.
Das funktioniert erstaunlich lange, skaliert aber nicht.
Ein Wechsel zu Odoo wird dann relevant, wenn das aktuelle Setup das Unternehmen nicht mehr zuverlässig zusammenhält. Er ist das Ergebnis der Summe aus Reibung, Unsicherheit, Datenbrüchen und manueller Kompensation.
Typische Warnsignale sind:
wichtige Prozesse laufen außerhalb des Systems
Daten werden manuell zwischen Tools übertragen
Finance, Lager und Sales arbeiten mit unterschiedlichen Zahlen
Reports brauchen jedes Mal Bereinigung
Verfügbarkeiten stehen in Nebenlisten
Sonderfälle hängen an einzelnen Personen
Änderungen an Aufträgen erzeugen Folgeprobleme
neue Tools lösen nur Teilprobleme
Wachstum macht Abläufe schwerer statt leichter
Wenn mehrere dieser Punkte zutreffen, ist der Systemwechsel meist nur der sichtbare Teil. Darunter liegt eine größere Frage: Wie soll das Unternehmen künftig operativ funktionieren?
Das alte System ist meistens nicht der alleinige Schuldige
Ich halte wenig davon, bestehende Systeme oder Software pauschal schlechtzureden.
Oft war das alte Setup zu Beginn genau richtig. Es hat ein konkretes Problem gelöst und schnell Verbesserungen gebracht.
Aus der Praxis:
In einem unserer Kundenprojekte wurde das bestehende ERP ursprünglich vor allem für einen Fachbereich genutzt. Es half, Einkauf und Lieferantenbeziehungen besser zu strukturieren. Vertrieb, Logistik, Finance und Sonderprozesse liefen weiterhin über andere Tools, Sheets und Absprachen.
Das System war dadurch kein echtes unternehmensweites Betriebssystem. Es war eher ein stark genutztes Fachbereichstool in einem größeren Workaround-Netz.
Genau solche Setups sehe ich häufig, weil schnell wachsende Unternehmen im Alltag selten die Zeit haben, ihre Prozesse regelmäßig neu zu durchdenken. Teams lösen ihre eigenen Probleme. So entsteht über Zeit ein System aus Teillösungen. Doch irgendwann reicht das nicht mehr.
Gerade in Unternehmen unterhalb von 100 oder 150 Mitarbeitenden fehlt oft eine Rolle, die fachbereichsübergreifend auf Prozesse schaut. Jemand, der aus dem Tagesgeschäft herauszoomt und fragt:
Wie fließen Informationen eigentlich durch das Unternehmen?
Wo entstehen Übergaben?
Welche Daten braucht welches Team?
Welche Entscheidungen werden im System getroffen?
Welche nur im Kopf einzelner Menschen?
Welche Workarounds sind nützlich?
Welche sind nur historisch gewachsen?
Wenn niemand diese Fragen stellt, wächst Komplexität im Hintergrund weiter.
Der Wechsel zu Odoo kann dann ein guter Schritt sein. Aber nur, wenn er genutzt wird, um diese gewachsene Komplexität wirklich zu sortieren.
Der gefährlichste Fehler bei der Migration: alte Logik übernehmen
Viele Unternehmen denken bei Migration zuerst an Daten: Welche Artikel müssen rüber? Welche Kunden? Welche Lieferanten? Welche offenen Aufträge? Welche Rechnungen? Welche Lagerbestände?
Natürlich sind diese Fragen wichtig, sie kommen aber oft zu früh. Vorher muss klar sein, ob die alte Datenstruktur überhaupt die richtige Arbeitsweise beschreibt.
Ein Beispiel aus der Praxis: Lohnfertigung beziehungsweise Beistellung.
In einem gewachsenen Setup kann so ein Prozess über Krücken abgebildet sein. Zum Beispiel über Platzhalterprodukte, uneigentliche Produktionslogik, manuelle Ergänzungen oder Stücklisten, die eher aus der alten Systemgrenze heraus entstanden sind als aus der realen Prozesslogik.
Im Alltag kann das funktionieren. Bis Finance verstehen will, welcher Wareneinsatz entstanden ist, das Lager wissen muss, welche Komponenten wo liegen und Einkauf, Produktion und Buchhaltung auf dieselbe Wahrheit schauen sollen.
Wenn man diese Struktur einfach nach Odoo überträgt, zieht man das alte Problem mit um.
Eine saubere Migration stellt vorher andere Fragen:
Wie läuft der reale Prozess wirklich? Welche Komponenten werden beschafft? Was geht an den Lohnfertiger? Was kommt als fertiges Produkt zurück? Wann entsteht Bestand? Wann entsteht Wert? Welche Information braucht Finance? Welche Information braucht das Lager? Welche Information braucht der Einkauf?
Altdaten sind deshalb keine Blaupause. Sie sind ein Gesprächseinstieg und zeigen, wie bisher gearbeitet wurde. Sie weisen aber nicht automatisch den Weeg, wie künftig gearbeitet werden sollte.
Genau darin liegt der Unterschied zwischen einer technischen Migration und einer operativ sinnvollen Migration.
Technisch kann man viel übertragen. Fachlich sollte man deutlich weniger übernehmen, als viele zu Beginn glauben.
Ein ERP-Systemwechsel beginnt selten mit einer direkten Systementscheidung.
Meistens entsteht er schleichend: Das aktuelle Setup funktioniert noch, aber immer mehr Arbeit passiert darum herum. Die Logistik führt eigene Listen, Finance traut den Zahlen nur bedingt, der Vertrieb kennt Sonderwege, Reports brauchen manuelle Nacharbeit und neue Mitarbeitende fragen irgendwann, warum so viel händisch übertragen wird.
Dann steht die Frage im Raum: „Sollten wir von weclapp, Xentral oder JTL zu Odoo wechseln?“
Viele Unternehmen wachsen aus ihren bisherigen ERP-, Warenwirtschafts- oder Tool-Setups heraus. Erfolgreich wird der Wechsel aber erst, wenn danach Arbeit klarer läuft, Daten belastbarer sind und Verantwortung besser im System abgebildet wird.
Alte Daten in einem neuen ERP reichen dafür nicht aus, alte Workarounds in einer moderneren Oberfläche auch nicht.
Der eigentliche Job ist größer: Das Unternehmen muss entscheiden, welche Arbeitsweise es in die nächste Wachstumsphase mitnimmt.
TL;DR
Ein ERP-Systemwechsel zu Odoo sollte kein 1:1-Umzug sein.
Viele Unternehmen wechseln nicht wegen eines einzelnen fehlenden Features, sondern weil ihre Systemlogik nicht mehr zur operativen Realität passt. Excel, Google Sheets, manuelle Übergaben, Schattenprozesse und widersprüchliche Zahlen sind Warnsignale.
Vor der Migration braucht es Prozessklarheit. Welche Abläufe gehören wirklich ins neue ERP? Welche Sonderfälle sind geschäftskritisch? Welche Daten müssen sauber sein? Was gehört in Phase 1? Welche Themen wandern bewusst ins Backlog?
Odoo kann sehr viel abbilden. Genau deshalb ist Klarheit so wichtig. Wer alte Workarounds nach Odoo überträgt, bekommt am Ende kein besseres Betriebssystem. Nur ein teureres Abbild alter Unklarheit.
Warum Unternehmen überhaupt über einen Wechsel zu Odoo nachdenken
weclapp, Xentral oder JTL können für eine bestimmte Unternehmensphase sehr sinnvoll sein. Viele Unternehmen starten damit aus guten Gründen: Sie brauchen Struktur, eine Warenwirtschaft, eine bessere Auftragsabwicklung, vielleicht eine erste Verbindung zwischen Shop, Lager und Buchhaltung.
Für eine Zeit reicht das. Dann wächst das Geschäft. Es kommen mehr Produkte, mehr Bestellungen, mehr Mitarbeitende, mehr Lagerlogik, mehr B2B-Kunden, mehr Sonderfälle, mehr Abstimmung mit Finance, mehr Anforderungen an Reporting und Steuerung.
Das Setup wächst meistens irgendwie mit. Ein neues Sheet hier. Eine App dort. Eine manuelle Übergabe. Ein zusätzlicher Report. Ein Workaround für einen Sonderfall. Eine Sonderregel, die nur zwei Menschen im Unternehmen verstehen.
Irgendwann entsteht ein Zustand, der von außen noch wie ein System aussieht. Im Alltag hängt der Betrieb aber an vielen kleinen Brücken zwischen Systemen, Teams und Köpfen.
Ein typisches Muster aus Projekten: Artikelverfügbarkeiten, erwartete Wareneingänge, Statusinformationen und operative Abstimmungen liegen in Google Sheets. Das alte ERP liefert einen Teil der Wahrheit, aber viele wichtige Informationen werden täglich manuell ergänzt. Das Team hat dadurch eine Art Transparenz. Allerdings nur, weil Menschen ständig Daten von einem Ort zum anderen übertragen.
Ich nenne solche Setups gerne „menschliche APIs“.
Menschen halten die Systeme synchron, schließen Prozesslücken, wissen, welche Ausnahme wann gilt, retten die operative Realität, die das System nicht vollständig abbildet.
Das funktioniert erstaunlich lange, skaliert aber nicht.
Ein Wechsel zu Odoo wird dann relevant, wenn das aktuelle Setup das Unternehmen nicht mehr zuverlässig zusammenhält. Er ist das Ergebnis der Summe aus Reibung, Unsicherheit, Datenbrüchen und manueller Kompensation.
Typische Warnsignale sind:
wichtige Prozesse laufen außerhalb des Systems
Daten werden manuell zwischen Tools übertragen
Finance, Lager und Sales arbeiten mit unterschiedlichen Zahlen
Reports brauchen jedes Mal Bereinigung
Verfügbarkeiten stehen in Nebenlisten
Sonderfälle hängen an einzelnen Personen
Änderungen an Aufträgen erzeugen Folgeprobleme
neue Tools lösen nur Teilprobleme
Wachstum macht Abläufe schwerer statt leichter
Wenn mehrere dieser Punkte zutreffen, ist der Systemwechsel meist nur der sichtbare Teil. Darunter liegt eine größere Frage: Wie soll das Unternehmen künftig operativ funktionieren?
Das alte System ist meistens nicht der alleinige Schuldige
Ich halte wenig davon, bestehende Systeme oder Software pauschal schlechtzureden.
Oft war das alte Setup zu Beginn genau richtig. Es hat ein konkretes Problem gelöst und schnell Verbesserungen gebracht.
Aus der Praxis:
In einem unserer Kundenprojekte wurde das bestehende ERP ursprünglich vor allem für einen Fachbereich genutzt. Es half, Einkauf und Lieferantenbeziehungen besser zu strukturieren. Vertrieb, Logistik, Finance und Sonderprozesse liefen weiterhin über andere Tools, Sheets und Absprachen.
Das System war dadurch kein echtes unternehmensweites Betriebssystem. Es war eher ein stark genutztes Fachbereichstool in einem größeren Workaround-Netz.
Genau solche Setups sehe ich häufig, weil schnell wachsende Unternehmen im Alltag selten die Zeit haben, ihre Prozesse regelmäßig neu zu durchdenken. Teams lösen ihre eigenen Probleme. So entsteht über Zeit ein System aus Teillösungen. Doch irgendwann reicht das nicht mehr.
Gerade in Unternehmen unterhalb von 100 oder 150 Mitarbeitenden fehlt oft eine Rolle, die fachbereichsübergreifend auf Prozesse schaut. Jemand, der aus dem Tagesgeschäft herauszoomt und fragt:
Wie fließen Informationen eigentlich durch das Unternehmen?
Wo entstehen Übergaben?
Welche Daten braucht welches Team?
Welche Entscheidungen werden im System getroffen?
Welche nur im Kopf einzelner Menschen?
Welche Workarounds sind nützlich?
Welche sind nur historisch gewachsen?
Wenn niemand diese Fragen stellt, wächst Komplexität im Hintergrund weiter.
Der Wechsel zu Odoo kann dann ein guter Schritt sein. Aber nur, wenn er genutzt wird, um diese gewachsene Komplexität wirklich zu sortieren.
Der gefährlichste Fehler bei der Migration: alte Logik übernehmen
Viele Unternehmen denken bei Migration zuerst an Daten: Welche Artikel müssen rüber? Welche Kunden? Welche Lieferanten? Welche offenen Aufträge? Welche Rechnungen? Welche Lagerbestände?
Natürlich sind diese Fragen wichtig, sie kommen aber oft zu früh. Vorher muss klar sein, ob die alte Datenstruktur überhaupt die richtige Arbeitsweise beschreibt.
Ein Beispiel aus der Praxis: Lohnfertigung beziehungsweise Beistellung.
In einem gewachsenen Setup kann so ein Prozess über Krücken abgebildet sein. Zum Beispiel über Platzhalterprodukte, uneigentliche Produktionslogik, manuelle Ergänzungen oder Stücklisten, die eher aus der alten Systemgrenze heraus entstanden sind als aus der realen Prozesslogik.
Im Alltag kann das funktionieren. Bis Finance verstehen will, welcher Wareneinsatz entstanden ist, das Lager wissen muss, welche Komponenten wo liegen und Einkauf, Produktion und Buchhaltung auf dieselbe Wahrheit schauen sollen.
Wenn man diese Struktur einfach nach Odoo überträgt, zieht man das alte Problem mit um.
Eine saubere Migration stellt vorher andere Fragen:
Wie läuft der reale Prozess wirklich? Welche Komponenten werden beschafft? Was geht an den Lohnfertiger? Was kommt als fertiges Produkt zurück? Wann entsteht Bestand? Wann entsteht Wert? Welche Information braucht Finance? Welche Information braucht das Lager? Welche Information braucht der Einkauf?
Altdaten sind deshalb keine Blaupause. Sie sind ein Gesprächseinstieg und zeigen, wie bisher gearbeitet wurde. Sie weisen aber nicht automatisch den Weeg, wie künftig gearbeitet werden sollte.
Genau darin liegt der Unterschied zwischen einer technischen Migration und einer operativ sinnvollen Migration.
Technisch kann man viel übertragen. Fachlich sollte man deutlich weniger übernehmen, als viele zu Beginn glauben.
Ist dein ERP Projekt in Gefahr?
Ist dein ERP Projekt in Gefahr?
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
12 Fragen. Direktes Ergebnis. Für Teams, die vor dem Projektstart Klarheit schaffen wollen.
Ist dein ERP Projekt in Gefahr?
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
12 Fragen. Direktes Ergebnis. Für Teams, die vor dem Projektstart Klarheit schaffen wollen.
Eine saubere Odoo-Migration beginnt mit Verständnis
Wenn wir in ein Migrationsprojekt starten, interessiert uns zuerst nicht nur das alte System. Uns interessiert die echte Arbeit.
Wo beginnt ein Prozess? Wer macht welchen Schritt? Welche Informationen werden gebraucht? Wo entstehen manuelle Übergaben? Welche Entscheidungen trifft das System? Welche trifft das Team außerhalb des Systems? Welche Daten werden mehrfach gepflegt? Welche Ausnahmen kommen regelmäßig vor? Welche Sonderfälle werden größer gemacht, als sie wirtschaftlich sind?
In Workshops erzählen Unternehmen oft zuerst den Idealprozess. Der klingt dann relativ sauber. Nach ein paar Nachfragen kommt die operative Realität dazu.
„Normalerweise machen wir das so.“
„Außer bei diesem Kundentyp.“
„Außer im B2B.“
„Außer bei Export.“
„Außer wenn der Artikel noch nicht da ist.“
„Außer wenn die Rechnung schon bezahlt wurde.“
„Außer wenn der externe Logistiker es anders braucht.“
In diesen Ausnahmen sieht man, ob das Unternehmen einen stabilen Prozess hat oder ob der Betrieb über Erfahrungswissen zusammengehalten wird. Darum reicht es nicht, Anforderungen zu sammeln.
Viele Anforderungen sind Beschwerden in anderer Form. Jemand will ein Feld, einen Button, eine Automation, einen Report. Vielleicht ist das sinnvoll. Vielleicht steckt dahinter aber ein unklarer Prozess, eine falsche Datenstruktur oder eine Entscheidung, die bisher niemand treffen wollte.
Gute ERP-Arbeit bedeutet deshalb: erst verstehen, dann entscheiden, dann bauen.
Warum wir Odoo früh erklären
Viele ERP-Projekte behandeln Schulung wie den letzten Schritt vor Go-live. Ich halte das für gefährlich.
Natürlich braucht es am Ende Training für alle Nutzerinnen und Nutzer. Aber konzeptionelles Verständnis muss viel früher entstehen:
Am Anfang sprechen Kunde und Implementierungspartner oft unterschiedliche Sprachen. Der Kunde spricht die Sprache der alten Welt: Sheets, Sonderwege, Workarounds, gewachsene Fachbereichsbegriffe, alte Systemgrenzen. Wir sprechen die Sprache der neuen Welt: Odoo-Konzepte, Zielprozesse, Datenmodelle, Workflows, Systemlogik.
Wenn diese Lücke bestehen bleibt, diskutiert man monatelang über Anforderungen, ohne dass alle ein gemeinsames Bild vom Zielprozess haben.
Deshalb zeigen wir früh als Arbeitsgrundlage, wie Odoo einen relevanten Prozess grundsätzlich abbilden kann: Mit einem realen Kunden, Produkt, Auftrag, Lieferanten, Rechnung und möglichen Sonderfällen.
Wenn Beteiligte sehen, wie ein Prozess in Odoo laufen kann, verändert sich das Gespräch. Dann geht es nicht mehr nur um Wünsche aus der alten Welt. Dann kann man gemeinsam prüfen, welche Logik wirklich funktioniert, wo Standard ausreicht, wo eine Anpassung sinnvoll wäre und welche Daten dafür gebraucht werden.
Diese frühe gemeinsame Sprache spart später viele Umwege.
Der Ablauf einer sinnvollen Odoo-Migration
Jedes Projekt ist anders, totzdem folgt eine saubere Migration meistens einer ähnlichen Logik.
1. Status quo verstehen
Am Anfang geht es darum, die echte Arbeitsweise sichtbar zu machen: Abläufe, Übergaben, Daten, Rollen, Ausnahmen und Schattenprozesse.
Wichtig ist vor allem die Frage: Wo kompensieren Menschen jeden Tag, was das System nicht sauber abbildet?
2. Zielbild definieren
Danach wird geklärt, wie der Prozess künftig laufen soll. Hier fragen wir nicht zuerst „Kann Odoo das?“, sondern: „Wie sollte dieser Ablauf operativ funktionieren?“
Aus dieser Klärung entstehen Zielarchitektur, Prozesslogik, Datenhoheit, Integrationsbedarf, Verantwortlichkeiten und eine erste Vorstellung von Phase 1.
3. Workstreams schneiden
Statt nur in Modulen zu denken, hilft der Blick auf End-to-End-Prozesse. Besonders wichtig sind häufig Order-to-Cash und Procure-to-Pay.
Order-to-Cash beschreibt den Weg von Lead oder Nachfrage bis Zahlung: Opportunity, Angebot, Auftrag, Lieferung, Rechnung, Zahlung und Reporting.
Procure-to-Pay beschreibt den Weg von Bedarf bis Zahlung: Einkauf, Lieferant, Bestellung, Wareneingang, Lager, Eingangsrechnung, Zahlung und Bewertung.
Diese Sicht ist hilfreich, weil operative Probleme selten nur in einem Modul entstehen. Sie entstehen an Übergängen: zwischen Sales und Ops, Einkauf und Lager, Lager und Finance, Rechnung und Zahlung.
4. Prozessskelett bauen
Bevor massenhaft Daten migriert werden, braucht es ein schlankes Prozessskelett.
Dafür reichen am Anfang wenige echte Beispiele: einige reale Kunden, Produkte, Lieferanten, Preislisten, Lager, Stücklisten oder Aufträge. Mit diesen Beispielen wird der Zielprozess durchgespielt, um weitere Erkenntnisse zu gewinnen:
Wo funktioniert die Logik? Wo fehlen Daten? Wo entsteht ein Gap? Wo reicht Standard? Wo braucht es Konfiguration? Wo könnte eine Anpassung sinnvoll werden? Wo muss der Fachbereich eine Entscheidung treffen?
5. Datenstruktur ableiten
Erst wenn der Zielprozess greifbar ist, ergibt Datenmigration wirklich Sinn.
Stammdaten dienen dem Prozess. Artikel, Kunden, Preise, Bestände, Lieferanten, Stücklisten und Zahlungsbedingungen müssen so strukturiert sein, dass der künftige Ablauf funktioniert.
Alte Daten können helfen, aber sie sollten nicht ungeprüft die neue Struktur bestimmen.
6. Phase 1 schneiden
Eine gute erste Phase muss nicht alle Wünsche erfüllen. In Phase 1 gehören die Prozesse, Daten und Integrationen, die für einen stabilen Betriebszustand nötig sind. Alles andere braucht eine ehrliche Bewertung: Muss es vor Go-live gelöst werden? Kann es später kommen? Reicht vorübergehend ein manueller Schritt? Ist das Thema wirklich geschäftskritisch?
7. Implementieren, testen, trainieren
Jetzt wird konfiguriert, gebaut, getestet und geschult. Entscheidend ist die Nähe zur Realität. Tests mit erfundenen Standardfällen reichen selten.
Die wichtigen Fragen lauten: Können echte Nutzerinnen und Nutzer ihren Alltag abbilden? Funktionieren Sonderfälle, die geschäftskritisch sind? Stimmen Übergaben zwischen Teams? Können Daten von Finance genutzt werden? Versteht das Team, wo Verantwortung liegt?
8. Go-live kontrolliert gestalten
Nicht jeder Go-live muss ein großer Stichtag sein. Manche Bereiche können früher produktiv werden. B2B-Stammdaten, CRM, Pipeline, Preislisten oder Vertragsinformationen lassen sich oft vor der vollständigen Transaktionslogik in Odoo nutzen. So entsteht früher Nutzen, ohne direkt die gesamte Auftragsabwicklung umzustellen.
Andere Bereiche brauchen einen sauberen Cutover. Besonders, wenn Lager, Versand, Rechnung, Finance oder externe Logistik dranhängen.
9. Nach Go-live stabilisieren
Go-live ist der Moment, in dem echte Nutzung beginnt.
Danach zeigt sich, welche Annahmen stimmen, welche Schulungen fehlen, welche Anforderungen an Gewicht verlieren und welche Gaps wirklich wichtig sind. Eine gute Migration plant diese Phase bewusst ein.
Warum Workstreams besser funktionieren als Moduldenken
Viele Unternehmen beschreiben ihre Probleme entlang von Tools oder Abteilungen.
„Wir brauchen CRM.“
„Wir brauchen bessere Lagerprozesse.“
„Finance braucht bessere Zahlen.“
„Der Einkauf muss sauberer werden.“
„Wir brauchen bessere Reports.“
Das ist verständlich. Trotzdem reicht diese Sicht oft nicht aus.
Denn ein Unternehmen funktioniert nicht in Modulen. Arbeit fließt durch das gesamte Unternehmen.
Ein Lead wird zu einem Angebot. Ein Angebot wird zu einem Auftrag. Ein Auftrag löst Lieferung aus. Lieferung erzeugt Rechnung. Rechnung führt zu Zahlung. Zahlung fließt in Finance und Reporting.
Auf der anderen Seite entsteht Bedarf. Bedarf führt zu Einkauf. Einkauf zu Wareneingang. Wareneingang zu Bestand. Bestand zu Bewertung. Bewertung zu Finance.
Wenn man nur einzelne Module optimiert, verschiebt man Brüche leicht an die nächste Schnittstelle.
Deshalb sind Order-to-Cash und Procure-to-Pay so wertvoll. Sie zwingen alle Beteiligten, über Fachbereichsgrenzen hinweg zu denken.
Und genau diese fachbereichsübergreifende Perspektive fehlt in gewachsenen Setups häufig.
Datenmigration ist eine Qualitätsentscheidung
Welche Daten müssen wirklich ins neue System? Welche Historie ist relevant? Welche Daten können archiviert bleiben? Welche Daten widersprechen sich? Welche Informationen wurden zwar gepflegt, aber nie genutzt? Welche Felder fehlen, damit der neue Prozess funktioniert?
Besonders kritisch sind meist Artikelstammdaten, Kunden, Lieferanten, Preislisten, Lagerbestände, offene Aufträge, offene Rechnungen, Seriennummern, Chargen, Stücklisten, Zahlungsbedingungen, Steuersachverhalte, Verträge, Versandlogik und Retourenprozesse.
Ein Beispiel aus Finance zeigt, warum das wichtig ist:
Viele E-Commerce-Unternehmen sehen ihren Umsatz relativ gut. Sie wissen, was über Shopify, Marktplätze, B2B oder andere Kanäle verkauft wurde. Was sie deutlich schlechter sehen: welcher Warenwert diesem Umsatz gegenübersteht.
Dann wird der Monatsabschluss zur Datenjagd. Margen bleiben unscharf, Kanäle wirken profitabler oder unprofitabler, als sie wirklich sind, Entscheidungen basieren auf halber Wahrheit.
In so einem Fall reicht es nicht, Produktstammdaten zu importieren. Es muss geklärt werden, wie Produktwerte entstehen, wie Lagerbewegungen bewertet werden, wann Wareneinsatz entsteht und wie Umsatz und Kosten zusammenfinden.
Wer seinen Wareneinsatz nicht sauber sieht, kennt seine echte Marge nicht.
Deshalb gilt: Schlechte Daten werden durch Migration nicht besser. Sie werden nur sichtbarer.
Sonderfälle ernst nehmen, ohne das System zu verbiegen
Sonderfälle sind einer der schwierigsten Teile jeder ERP-Migration.
Ich verstehe, warum Fachbereiche daran hängen: Sonderfälle kommen aus echter Erfahrung. Da gab es einen Exportfall, der schiefging. Einen Großkunden mit spezieller Preislogik. Eine Retoure, die kompliziert war. Einen Produktionsfall, der vom Standard abweicht. Eine Abrechnung, die man nur mit viel Wissen sauber hinbekommt.
Für das Team sind solche Fälle nicht theoretisch. Sie sind erlebt.
Darum wäre es falsch, Sonderfälle einfach wegzuwischen.
Genauso problematisch wäre es, jeden Sonderfall sofort ins System zu bauen.
Ein Sonderfall sollte ins System, wenn er regelmäßig vorkommt, wirtschaftlich relevant ist, rechtlich oder buchhalterisch wichtig ist, operative Risiken erzeugt oder das Kundenerlebnis stark beeinflusst.
Wenn ein Sonderfall sehr selten vorkommt, nur historisch gewachsen ist, den Standardprozess massiv verkompliziert oder organisatorisch sauber gelöst werden kann, gehört er eher ins Backlog oder in einen bewusst manuellen Übergangsprozess.
In Projekten merkt man schnell: Die lautesten Themen sind nicht immer die wichtigsten.
Manchmal diskutiert ein Team sehr intensiv über einen Ausnahmefall, der zweimal im Jahr vorkommt. Gleichzeitig ist der tägliche Kernprozess noch nicht sauber genug. Dann braucht es Führung im Projekt.
Phase 1 braucht einen stabilen Betriebszustand
Viele Unternehmen wollen in Phase 1 alles lösen. Wenn man schon ein neues ERP einführt, soll es bitte gleich richtig werden. Alle Module. Alle Integrationen. Alle Reports. Alle Sonderfälle. Alle Automationen. Alle historischen Daten. Alle Wünsche aller Fachbereiche.
Ein überladener Go-live ist aber häufig ein Risiko.
Daher fragen wir uns: Was braucht das Unternehmen, um stabil im neuen System zu arbeiten?
In Phase 1 gehören Themen::
Prozesse, ohne die der Betrieb stockt
Daten, die für Lieferung, Rechnung, Bestand und Finance gebraucht werden
kritische Übergaben zwischen Teams
zentrale Verantwortlichkeiten
minimale Integrationen
Prozesse mit hohem Fehlerrisiko
Bereiche, die früh echten Nutzen bringen
Viele andere Themen dürfen später kommen: Komfortfunktionen, seltene Sonderfälle, zusätzliche Reports, Nice-to-have-Automationen, nachgelagerte Integrationen oder Customizations, deren Wert erst nach echter Nutzung klar wird.
Aus der Praxis:
In vielen Kundenprojekt ister der ursprüngliche Impuls, sehr viele Bereiche gleichzeitig live zu nehmen: Vertrieb, Einkauf, Versandlogistik, Produktion, Partnermanagement, Finance und weitere angrenzende Prozesse. In der Umsetzung wird das schnell schwer verdaulich: Zu viele Stakeholder, Abhängigkeiten, offene Gaps und zu viel Change und Schulungsaufwand auf einmal erzeugen unhandlebare Komplexität.
Manchmal ist die beste Projektentscheidung daher, den Scope bewusst zu schneiden.
Eine saubere Odoo-Migration beginnt mit Verständnis
Wenn wir in ein Migrationsprojekt starten, interessiert uns zuerst nicht nur das alte System. Uns interessiert die echte Arbeit.
Wo beginnt ein Prozess? Wer macht welchen Schritt? Welche Informationen werden gebraucht? Wo entstehen manuelle Übergaben? Welche Entscheidungen trifft das System? Welche trifft das Team außerhalb des Systems? Welche Daten werden mehrfach gepflegt? Welche Ausnahmen kommen regelmäßig vor? Welche Sonderfälle werden größer gemacht, als sie wirtschaftlich sind?
In Workshops erzählen Unternehmen oft zuerst den Idealprozess. Der klingt dann relativ sauber. Nach ein paar Nachfragen kommt die operative Realität dazu.
„Normalerweise machen wir das so.“
„Außer bei diesem Kundentyp.“
„Außer im B2B.“
„Außer bei Export.“
„Außer wenn der Artikel noch nicht da ist.“
„Außer wenn die Rechnung schon bezahlt wurde.“
„Außer wenn der externe Logistiker es anders braucht.“
In diesen Ausnahmen sieht man, ob das Unternehmen einen stabilen Prozess hat oder ob der Betrieb über Erfahrungswissen zusammengehalten wird. Darum reicht es nicht, Anforderungen zu sammeln.
Viele Anforderungen sind Beschwerden in anderer Form. Jemand will ein Feld, einen Button, eine Automation, einen Report. Vielleicht ist das sinnvoll. Vielleicht steckt dahinter aber ein unklarer Prozess, eine falsche Datenstruktur oder eine Entscheidung, die bisher niemand treffen wollte.
Gute ERP-Arbeit bedeutet deshalb: erst verstehen, dann entscheiden, dann bauen.
Warum wir Odoo früh erklären
Viele ERP-Projekte behandeln Schulung wie den letzten Schritt vor Go-live. Ich halte das für gefährlich.
Natürlich braucht es am Ende Training für alle Nutzerinnen und Nutzer. Aber konzeptionelles Verständnis muss viel früher entstehen:
Am Anfang sprechen Kunde und Implementierungspartner oft unterschiedliche Sprachen. Der Kunde spricht die Sprache der alten Welt: Sheets, Sonderwege, Workarounds, gewachsene Fachbereichsbegriffe, alte Systemgrenzen. Wir sprechen die Sprache der neuen Welt: Odoo-Konzepte, Zielprozesse, Datenmodelle, Workflows, Systemlogik.
Wenn diese Lücke bestehen bleibt, diskutiert man monatelang über Anforderungen, ohne dass alle ein gemeinsames Bild vom Zielprozess haben.
Deshalb zeigen wir früh als Arbeitsgrundlage, wie Odoo einen relevanten Prozess grundsätzlich abbilden kann: Mit einem realen Kunden, Produkt, Auftrag, Lieferanten, Rechnung und möglichen Sonderfällen.
Wenn Beteiligte sehen, wie ein Prozess in Odoo laufen kann, verändert sich das Gespräch. Dann geht es nicht mehr nur um Wünsche aus der alten Welt. Dann kann man gemeinsam prüfen, welche Logik wirklich funktioniert, wo Standard ausreicht, wo eine Anpassung sinnvoll wäre und welche Daten dafür gebraucht werden.
Diese frühe gemeinsame Sprache spart später viele Umwege.
Der Ablauf einer sinnvollen Odoo-Migration
Jedes Projekt ist anders, totzdem folgt eine saubere Migration meistens einer ähnlichen Logik.
1. Status quo verstehen
Am Anfang geht es darum, die echte Arbeitsweise sichtbar zu machen: Abläufe, Übergaben, Daten, Rollen, Ausnahmen und Schattenprozesse.
Wichtig ist vor allem die Frage: Wo kompensieren Menschen jeden Tag, was das System nicht sauber abbildet?
2. Zielbild definieren
Danach wird geklärt, wie der Prozess künftig laufen soll. Hier fragen wir nicht zuerst „Kann Odoo das?“, sondern: „Wie sollte dieser Ablauf operativ funktionieren?“
Aus dieser Klärung entstehen Zielarchitektur, Prozesslogik, Datenhoheit, Integrationsbedarf, Verantwortlichkeiten und eine erste Vorstellung von Phase 1.
3. Workstreams schneiden
Statt nur in Modulen zu denken, hilft der Blick auf End-to-End-Prozesse. Besonders wichtig sind häufig Order-to-Cash und Procure-to-Pay.
Order-to-Cash beschreibt den Weg von Lead oder Nachfrage bis Zahlung: Opportunity, Angebot, Auftrag, Lieferung, Rechnung, Zahlung und Reporting.
Procure-to-Pay beschreibt den Weg von Bedarf bis Zahlung: Einkauf, Lieferant, Bestellung, Wareneingang, Lager, Eingangsrechnung, Zahlung und Bewertung.
Diese Sicht ist hilfreich, weil operative Probleme selten nur in einem Modul entstehen. Sie entstehen an Übergängen: zwischen Sales und Ops, Einkauf und Lager, Lager und Finance, Rechnung und Zahlung.
4. Prozessskelett bauen
Bevor massenhaft Daten migriert werden, braucht es ein schlankes Prozessskelett.
Dafür reichen am Anfang wenige echte Beispiele: einige reale Kunden, Produkte, Lieferanten, Preislisten, Lager, Stücklisten oder Aufträge. Mit diesen Beispielen wird der Zielprozess durchgespielt, um weitere Erkenntnisse zu gewinnen:
Wo funktioniert die Logik? Wo fehlen Daten? Wo entsteht ein Gap? Wo reicht Standard? Wo braucht es Konfiguration? Wo könnte eine Anpassung sinnvoll werden? Wo muss der Fachbereich eine Entscheidung treffen?
5. Datenstruktur ableiten
Erst wenn der Zielprozess greifbar ist, ergibt Datenmigration wirklich Sinn.
Stammdaten dienen dem Prozess. Artikel, Kunden, Preise, Bestände, Lieferanten, Stücklisten und Zahlungsbedingungen müssen so strukturiert sein, dass der künftige Ablauf funktioniert.
Alte Daten können helfen, aber sie sollten nicht ungeprüft die neue Struktur bestimmen.
6. Phase 1 schneiden
Eine gute erste Phase muss nicht alle Wünsche erfüllen. In Phase 1 gehören die Prozesse, Daten und Integrationen, die für einen stabilen Betriebszustand nötig sind. Alles andere braucht eine ehrliche Bewertung: Muss es vor Go-live gelöst werden? Kann es später kommen? Reicht vorübergehend ein manueller Schritt? Ist das Thema wirklich geschäftskritisch?
7. Implementieren, testen, trainieren
Jetzt wird konfiguriert, gebaut, getestet und geschult. Entscheidend ist die Nähe zur Realität. Tests mit erfundenen Standardfällen reichen selten.
Die wichtigen Fragen lauten: Können echte Nutzerinnen und Nutzer ihren Alltag abbilden? Funktionieren Sonderfälle, die geschäftskritisch sind? Stimmen Übergaben zwischen Teams? Können Daten von Finance genutzt werden? Versteht das Team, wo Verantwortung liegt?
8. Go-live kontrolliert gestalten
Nicht jeder Go-live muss ein großer Stichtag sein. Manche Bereiche können früher produktiv werden. B2B-Stammdaten, CRM, Pipeline, Preislisten oder Vertragsinformationen lassen sich oft vor der vollständigen Transaktionslogik in Odoo nutzen. So entsteht früher Nutzen, ohne direkt die gesamte Auftragsabwicklung umzustellen.
Andere Bereiche brauchen einen sauberen Cutover. Besonders, wenn Lager, Versand, Rechnung, Finance oder externe Logistik dranhängen.
9. Nach Go-live stabilisieren
Go-live ist der Moment, in dem echte Nutzung beginnt.
Danach zeigt sich, welche Annahmen stimmen, welche Schulungen fehlen, welche Anforderungen an Gewicht verlieren und welche Gaps wirklich wichtig sind. Eine gute Migration plant diese Phase bewusst ein.
Warum Workstreams besser funktionieren als Moduldenken
Viele Unternehmen beschreiben ihre Probleme entlang von Tools oder Abteilungen.
„Wir brauchen CRM.“
„Wir brauchen bessere Lagerprozesse.“
„Finance braucht bessere Zahlen.“
„Der Einkauf muss sauberer werden.“
„Wir brauchen bessere Reports.“
Das ist verständlich. Trotzdem reicht diese Sicht oft nicht aus.
Denn ein Unternehmen funktioniert nicht in Modulen. Arbeit fließt durch das gesamte Unternehmen.
Ein Lead wird zu einem Angebot. Ein Angebot wird zu einem Auftrag. Ein Auftrag löst Lieferung aus. Lieferung erzeugt Rechnung. Rechnung führt zu Zahlung. Zahlung fließt in Finance und Reporting.
Auf der anderen Seite entsteht Bedarf. Bedarf führt zu Einkauf. Einkauf zu Wareneingang. Wareneingang zu Bestand. Bestand zu Bewertung. Bewertung zu Finance.
Wenn man nur einzelne Module optimiert, verschiebt man Brüche leicht an die nächste Schnittstelle.
Deshalb sind Order-to-Cash und Procure-to-Pay so wertvoll. Sie zwingen alle Beteiligten, über Fachbereichsgrenzen hinweg zu denken.
Und genau diese fachbereichsübergreifende Perspektive fehlt in gewachsenen Setups häufig.
Datenmigration ist eine Qualitätsentscheidung
Welche Daten müssen wirklich ins neue System? Welche Historie ist relevant? Welche Daten können archiviert bleiben? Welche Daten widersprechen sich? Welche Informationen wurden zwar gepflegt, aber nie genutzt? Welche Felder fehlen, damit der neue Prozess funktioniert?
Besonders kritisch sind meist Artikelstammdaten, Kunden, Lieferanten, Preislisten, Lagerbestände, offene Aufträge, offene Rechnungen, Seriennummern, Chargen, Stücklisten, Zahlungsbedingungen, Steuersachverhalte, Verträge, Versandlogik und Retourenprozesse.
Ein Beispiel aus Finance zeigt, warum das wichtig ist:
Viele E-Commerce-Unternehmen sehen ihren Umsatz relativ gut. Sie wissen, was über Shopify, Marktplätze, B2B oder andere Kanäle verkauft wurde. Was sie deutlich schlechter sehen: welcher Warenwert diesem Umsatz gegenübersteht.
Dann wird der Monatsabschluss zur Datenjagd. Margen bleiben unscharf, Kanäle wirken profitabler oder unprofitabler, als sie wirklich sind, Entscheidungen basieren auf halber Wahrheit.
In so einem Fall reicht es nicht, Produktstammdaten zu importieren. Es muss geklärt werden, wie Produktwerte entstehen, wie Lagerbewegungen bewertet werden, wann Wareneinsatz entsteht und wie Umsatz und Kosten zusammenfinden.
Wer seinen Wareneinsatz nicht sauber sieht, kennt seine echte Marge nicht.
Deshalb gilt: Schlechte Daten werden durch Migration nicht besser. Sie werden nur sichtbarer.
Sonderfälle ernst nehmen, ohne das System zu verbiegen
Sonderfälle sind einer der schwierigsten Teile jeder ERP-Migration.
Ich verstehe, warum Fachbereiche daran hängen: Sonderfälle kommen aus echter Erfahrung. Da gab es einen Exportfall, der schiefging. Einen Großkunden mit spezieller Preislogik. Eine Retoure, die kompliziert war. Einen Produktionsfall, der vom Standard abweicht. Eine Abrechnung, die man nur mit viel Wissen sauber hinbekommt.
Für das Team sind solche Fälle nicht theoretisch. Sie sind erlebt.
Darum wäre es falsch, Sonderfälle einfach wegzuwischen.
Genauso problematisch wäre es, jeden Sonderfall sofort ins System zu bauen.
Ein Sonderfall sollte ins System, wenn er regelmäßig vorkommt, wirtschaftlich relevant ist, rechtlich oder buchhalterisch wichtig ist, operative Risiken erzeugt oder das Kundenerlebnis stark beeinflusst.
Wenn ein Sonderfall sehr selten vorkommt, nur historisch gewachsen ist, den Standardprozess massiv verkompliziert oder organisatorisch sauber gelöst werden kann, gehört er eher ins Backlog oder in einen bewusst manuellen Übergangsprozess.
In Projekten merkt man schnell: Die lautesten Themen sind nicht immer die wichtigsten.
Manchmal diskutiert ein Team sehr intensiv über einen Ausnahmefall, der zweimal im Jahr vorkommt. Gleichzeitig ist der tägliche Kernprozess noch nicht sauber genug. Dann braucht es Führung im Projekt.
Phase 1 braucht einen stabilen Betriebszustand
Viele Unternehmen wollen in Phase 1 alles lösen. Wenn man schon ein neues ERP einführt, soll es bitte gleich richtig werden. Alle Module. Alle Integrationen. Alle Reports. Alle Sonderfälle. Alle Automationen. Alle historischen Daten. Alle Wünsche aller Fachbereiche.
Ein überladener Go-live ist aber häufig ein Risiko.
Daher fragen wir uns: Was braucht das Unternehmen, um stabil im neuen System zu arbeiten?
In Phase 1 gehören Themen::
Prozesse, ohne die der Betrieb stockt
Daten, die für Lieferung, Rechnung, Bestand und Finance gebraucht werden
kritische Übergaben zwischen Teams
zentrale Verantwortlichkeiten
minimale Integrationen
Prozesse mit hohem Fehlerrisiko
Bereiche, die früh echten Nutzen bringen
Viele andere Themen dürfen später kommen: Komfortfunktionen, seltene Sonderfälle, zusätzliche Reports, Nice-to-have-Automationen, nachgelagerte Integrationen oder Customizations, deren Wert erst nach echter Nutzung klar wird.
Aus der Praxis:
In vielen Kundenprojekt ister der ursprüngliche Impuls, sehr viele Bereiche gleichzeitig live zu nehmen: Vertrieb, Einkauf, Versandlogistik, Produktion, Partnermanagement, Finance und weitere angrenzende Prozesse. In der Umsetzung wird das schnell schwer verdaulich: Zu viele Stakeholder, Abhängigkeiten, offene Gaps und zu viel Change und Schulungsaufwand auf einmal erzeugen unhandlebare Komplexität.
Manchmal ist die beste Projektentscheidung daher, den Scope bewusst zu schneiden.
Ist dein ERP Projekt in Gefahr?
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
12 Fragen. Direktes Ergebnis. Für Teams, die vor dem Projektstart Klarheit schaffen wollen.
Teil-Go-lives können Risiko senken
Viele Menschen denken bei ERP-Migration an den großen Stichtag: Freitag altes System > Montag neues System.
Für manche Prozesse braucht es so einen klaren Cutover. Besonders bei Auftragsabwicklung, Lager, Rechnung, Finance oder externer Logistik. Dort können parallele Wahrheiten gefährlich werden.
Andere Bereiche lassen sich früher produktiv nutzen.
Ein Beispiel ist der B2B-Vertrieb.
Ein Unternehmen kann B2B-Stammdaten, CRM, Pipeline, Preislisten und Vertragsinformationen in Odoo pflegen, bevor Angebote, Lieferungen und Rechnungen vollständig über Odoo laufen.
Dadurch entsteht echter Nutzen: Die Geschäftsführung sieht Pipeline und Potenzial. Sales arbeitet zentraler. Das Supply-Team kann Nachfrage besser antizipieren. Kundendaten werden sauberer. Das Team gewöhnt sich an Odoo.
Der komplette Betrieb wurde damit noch nicht umgestellt. Aber ein konkreter Job wird besser gelöst.
So wird Migration greifbarer, risikoärmer und für Teams weniger abstrakt.
Customizing: Flexibilität mit Timing
Odoo Flexibilität ist einer der großen Vorteile derSoftware. Gleichzeitig verführt das dazu, zu früh zu viel zu bauen.
Gute Odoo-Setups brauchen oft Anpassungen. Besonders bei komplexen Produkten, E-Commerce-Integrationen, B2B-Prozessen, Lagerlogik oder Produktion.
Der entscheidende Punkt ist der Zeitpunkt. Vor echter Nutzung sind viele Anforderungen Annahmen. Nach ein paar Wochen im System sieht die Welt oft anders aus. Teams verstehen Odoo besser. Alte Wünsche verlieren an Bedeutung. Neue Engpässe werden sichtbar. Manche Komfortfunktion wirkt plötzlich unnötig.
Darum sollte jede Anpassung durch ein paar Fragen:
Was ist die Ursache?
Reicht der Standard?
Kann der Prozess anders laufen?
Löst Konfiguration das Problem?
Ist der Sonderfall wichtig genug?
Muss das vor Go-live passieren?
Oder lohnt es sich, echte Nutzung abzuwarten?
Manchmal ist ein manueller Klick vor Go-live besser als eine Customization, die drei Wochen später niemand mehr braucht.
Die häufigsten Fehler bei einer Odoo-Migration
Wenn Odoo-Migrationen teuer, langsam oder chaotisch werden, liegt die Ursache meistens früh im Projekt und bei Entscheidungen, die zu spät, zu weich oder auf der falschen Grundlage getroffen wurden.
1. Alte Prozesse 1:1 übernehmen
Viele Abläufe wirken vertraut, weil sie seit Jahren genutzt werden. Das heißt aber nicht, dass sie gut sind. Wenn ein Workaround im alten System entstanden ist, wird er durch Odoo nicht automatisch sauberer. Er bekommt nur eine neue Oberfläche.
2. Anforderungen sammeln, bevor der Prozess verstanden ist
Viele Anforderungen klingen im ersten Moment plausibel: ein zusätzliches Feld, ein Report, eine Automation, eine Sonderlogik. Manchmal lösen sie aber nicht die Ursache, sondern nur das sichtbare Symptom. Dann wird gebaut, bevor wirklich verstanden wurde, was im Betrieb passieren soll.
3. Zu viel Scope in Phase 1 packen
Wenn alles in die erste Launch-Welle soll, entsteht ein Tsunami: riesig und zerstörerisch.
Dann hängen zu viele Fachbereiche, Sonderfälle, Integrationen und offene Fragen am gleichen Go-live. Was auf dem Papier nach einem vollständigen Start aussieht, wird im Alltag schnell zu einem unübersichtlichen Kraftakt für Projektteam, Key User und operative Teams.
Eine gute erste Phase muss nicht alles lösen. Sie muss den Betrieb stabil ins neue System bringen. Alles, was dafür nicht zwingend gebraucht wird, gehört bewusst ins Backlog.
4. Einen Big Bang erzwingen
Manche Prozesse müssen gemeinsam umgestellt werden, weil Lager, Auftragsabwicklung, Rechnung und Finance eng zusammenhängen. Andere Bereiche lassen sich früher oder später entkoppeln. Wer alles auf einen einzigen Stichtag schiebt, erhöht Change-Aufwand und Fehlerrisiko unnötig.
5. Zu früh customizen
Odoo ist flexibel, und genau das verführt dazu, alte Sonderlogiken schnell nachzubauen. Vor echter Nutzung sind viele Anforderungen aber Annahmen. Wer zu früh baut, automatisiert oft eine Vorstellung vom Prozess, die drei Wochen nach Go-live schon anders bewertet wird.
6. Datenqualität zu spät ernst nehmen
Wenn Stammdaten, Bestände, Preise, offene Posten oder Stücklisten nicht stimmen, verliert das Team schnell Vertrauen ins neue System. Dann ist Odoo zwar live, aber die Menschen fangen wieder an, neben dem System zu prüfen, zu korrigieren und eigene Listen zu führen.
7. Interne Ownership unterschätzen
Ein ERP-Projekt lässt sich nicht vollständig an einen Partner auslagern. Der Partner kann führen, strukturieren, herausfordern und umsetzen. Das Unternehmen muss trotzdem mitentscheiden, mittragen und mitlernen. Ohne interne Verantwortung und gute Adaption wird jedes System irgendwann wieder zum Fremdkörper.
8. Go-live als Abschluss verstehen
Der Go-live ist kein Schlussstrich. Ab diesem Moment zeigt echte Nutzung, welche Prozesse funktionieren, welche Schulungen fehlen, welche Anforderungen an Gewicht verlieren und welche Verbesserungen wirklich relevant werden.
Wann Odoo stark ist
Odoo ist stark, wenn mehrere Teams auf einer gemeinsamen Plattform arbeiten sollen.
Also bei Unternehmen, die Sales, Einkauf, Lager, Finance, Produktion, Service oder Projekte enger verbinden wollen.
Typische gute Ausgangslagen sind:
E-Commerce mit mehreren Kanälen
B2B und B2C parallel
wachsende Handelsunternehmen
Produktion oder Lohnfertigung
komplexere Lagerlogik
Unternehmen mit zu vielen Tools
hoher manueller Abstimmungsaufwand
Finance mit Bedarf an besseren Daten
Organisationen, die skalieren wollen, ohne jeden Prozess über Menschen abzusichern
Odoo ist oft spannend für Unternehmen, denen einfache SaaS-Tools zu klein werden, während SAP, NetSuite oder Microsoft Business Central zu schwergewichtig wirken.
Der Sweet Spot liegt häufig dazwischen: genug Komplexität, damit Integration wirklich Wert schafft. Gleichzeitig genug Pragmatismus, um schnell und iterativ zu besseren Abläufen zu kommen.
Wann Odoo nicht automatisch hilft
Odoo löst keine ungeklärte Organisation: Wenn Prozesse unklar sind, werden sie sichtbarer, wenn Verantwortlichkeiten fehlen, verschwinden sie nicht durch neue Software. Wenn Daten widersprüchlich sind, werden sie durch Migration nicht plötzlich belastbar, wenn Fachbereiche keine Entscheidungen treffen, baut auch Odoo keine gemeinsame Arbeitsweise.
Odoo ist schwierig, wenn ein Unternehmen Plug-and-play erwartet, wenn niemand intern Verantwortung übernimmt, oder das Ziel lautet: „Bitte bildet alles so ab, wie es heute ist.“ Dann sollte man sehr ehrlich prüfen, ob ein Odoo-Projekt der richtige nächste Schritt ist.
Manchmal braucht es zuerst Prozessklärung, manchmal ein Recovery des bestehenden Systems oder eine kleinere Lösung, meist aber vor allem interne Ownership.
Ein gutes ERP-Projekt beginnt mit der Bereitschaft, die eigene Arbeitsweise zu hinterfragen.
Selbst-Diagnose: Ist euer aktuelles System noch euer Betriebssystem?
Wenn ihr über einen Wechsel zu Odoo nachdenkt, helfen ein paar ehrliche Fragen:
Laufen wichtige Prozesse außerhalb eures Systems?
Nutzt ihr Excel oder Google Sheets, um Daten zwischen Tools zu verbinden?
Müssen Mitarbeitende wissen, welche Sonderfälle wie behandelt werden?
Gibt es Informationen, die euer Team kennt, aber euer System nicht?
Stimmen Zahlen zwischen Finance, Lager und Sales nicht automatisch überein?
Dauern Reports länger, weil Daten erst bereinigt werden müssen?
Werden operative Entscheidungen auf Bauchgefühl statt Systemdaten getroffen?
Entstehen neue Tools, weil das aktuelle System Lücken lässt?
Funktioniert euer Prozess nur, solange alles nach Standard läuft?
Müssen Kunden-, Artikel- oder Auftragsdaten doppelt gepflegt werden?
Wird Wachstum eher schwerer als leichter?
Hängen Sonderfälle an einzelnen Personen?
Wird der Monatsabschluss zur Datenjagd?
Können neue Mitarbeitende Prozesse nur durch Zuruf lernen?
Wenn ihr drei oder mehr dieser Fragen mit Ja beantwortet, hat euer aktuelles Setup vermutlich strukturelle Risse.
Bei fünf oder mehr Ja-Antworten bildet euer System euer Business wahrscheinlich nicht mehr sauber ab.
Bei sieben oder mehr Ja-Antworten geht es nicht mehr nur um ein IT-Projekt. Dann geht es um Kontrolle, Verantwortung und Organisationsfähigkeit über die gesamte Wertschöpfungskette hinweg.
Fazit: Der Systemwechsel ist nur der sichtbare Teil
Der Wechsel von weclapp, Xentral oder JTL zu Odoo ist nur der sichtbare Teil.
Die eigentliche Arbeit liegt darunter: Prozesse verstehen, Workarounds hinterfragen, Datenqualität herstellen, Sonderfälle bewerten, die Systemumstellung sauber schneiden, Fachbereiche einbinden, den Go-live kontrolliert gestalten und nach Launch weiter verbessern.
Wenn ihr euer aktuelles System ablöst, entscheidet ihr über mehr als Software. Ihr entscheidet, welche Arbeitsweise ihr in die nächste Wachstumsphase mitnehmt und welche besser zurückbleibt.
Eine gute Odoo-Migration überträgt nicht euer altes System, sondern schafft die Grundlage dafür, dass euer Unternehmen klarer, stabiler und skalierbarer arbeiten kann.
Plant ihr den Wechsel zu Odoo?
Bevor ihr Daten und Prozesse migriert, lohnt sich ein strukturierter Blick auf Prozesse, Daten, Sonderfälle und Migrationsrisiken.
Wir prüfen mit euch, welche Prozesse wirklich ins neue System gehören, welche Daten kritisch sind, was in Phase 1 funktionieren muss und wo die größten Risiken liegen.
FAQ
Wann lohnt sich ein Wechsel von weclapp, Xentral oder JTL zu Odoo?
Ein Wechsel lohnt sich, wenn das aktuelle System zentrale Geschäftsprozesse nicht mehr sauber abbildet. Typische Warnsignale sind Excel-Workarounds, doppelte Datenpflege, manuelle Übergaben, unzuverlässige Reports oder Prozesse, die nur funktionieren, solange alles nach Standard läuft.
Wie läuft eine Odoo-Migration grundsätzlich ab?
Eine saubere Odoo-Migration beginnt mit Prozessverständnis. Zuerst werden Ist-Prozesse, Zielbild, Workstreams, kritische Daten, Sonderfälle und Phase-1-Scope geklärt. Danach folgen Prozessvalidierung, technische Umsetzung, Schulung, Go-live und kontinuierliche Weiterentwicklung.
Sollte man bestehende Prozesse 1:1 nach Odoo übernehmen?
Die 1:1-Übernahme alter Prozesse ist riskant. Bestehende Prozesse sind häufig durch alte Systemgrenzen, manuelle Workarounds oder historische Sonderfälle geprägt. Vor der Migration sollte entschieden werden, welche Prozesse sinnvoll sind, welche neu gedacht werden müssen und welche bewusst wegfallen dürfen.
Welche Prozesse sollte man zuerst migrieren?
Zuerst sollten Prozesse migriert werden, die für den laufenden Betrieb kritisch sind oder schnell isolierten Nutzen stiften. Dazu gehören je nach Unternehmen Angebot, Auftrag, Einkauf, Lager, Lieferung, Rechnung, Finance, CRM oder B2B-Stammdaten. Alles, was nicht go-live-kritisch ist, gehört bewusst ins Backlog.
Wie entscheidet man, welche Sonderfälle in Odoo abgebildet werden?
Ein Sonderfall sollte ins System, wenn er regelmäßig vorkommt, wirtschaftlich relevant ist, rechtlich notwendig ist oder operative Risiken erzeugt. Seltene, historisch gewachsene oder unverhältnismäßig komplexe Sonderfälle sollten geprüft, vereinfacht oder später umgesetzt werden.
Welche Daten müssen vor einer Odoo-Migration bereinigt werden?
Besonders kritisch sind Artikelstammdaten, Kunden, Lieferanten, Lagerbestände, Preislisten, offene Aufträge, offene Rechnungen, Seriennummern, Chargen, Stücklisten und Zahlungsbedingungen. Wenn diese Daten unsauber sind, entstehen im neuen System dieselben Unsicherheiten wie vorher.
Kann man Daten aus JTL, weclapp oder Xentral nach Odoo migrieren?
Grundsätzlich ja. Entscheidend ist aber nicht nur, ob Daten technisch migriert werden können. Wichtig ist, welche Daten wirklich gebraucht werden, wie sauber sie sind und ob historische Daten vollständig ins neue System gehören oder besser archiviert bleiben.
Wie vermeidet man Projektchaos bei einer Odoo-Migration?
Durch klare Priorisierung, saubere Discovery, realistische Phase-1-Definition, frühe Einbindung der Fachbereiche, klare interne Ownership, echte Testfälle, entzerrte Go-lives und bewusste Entscheidungen darüber, was nicht sofort umgesetzt wird.
Ist Odoo falsch, wenn eine Einführung nicht funktioniert?
Nicht zwingend. Häufig liegt das Problem nicht an Odoo selbst, sondern an ungeklärten Prozessen, unsauberen Daten, fehlenden Verantwortlichkeiten oder zu wenig Führung im Projekt. Odoo macht diese Unklarheit sichtbar.
Wie lange dauert eine Odoo-Migration?
Das hängt stark von Scope, Datenqualität, Prozesskomplexität und interner Verfügbarkeit ab. Sinnvoll ist meist ein Phasenmodell: zuerst ein stabiles Fundament, danach gezielte Erweiterungen und kontinuierliche Verbesserung.
Was ist der Unterschied zwischen Datenmigration und Prozessmigration?
Datenmigration überträgt Informationen von einem System ins andere. Prozessmigration entscheidet, wie Arbeit künftig laufen soll. Eine gute Odoo-Migration braucht beides. Die Prozesslogik sollte vor der Datenstruktur kommen.
Warum ist ein Big Bang bei ERP-Migrationen riskant?
Ein Big Bang verändert viele Prozesse, Teams und Abhängigkeiten gleichzeitig. Dadurch steigen Change-Aufwand, Testaufwand und operative Risiken. Wenn möglich, sollten Workstreams und Teil-Go-lives so geschnitten werden, dass der Übergang kontrollierbar bleibt.
Teil-Go-lives können Risiko senken
Viele Menschen denken bei ERP-Migration an den großen Stichtag: Freitag altes System > Montag neues System.
Für manche Prozesse braucht es so einen klaren Cutover. Besonders bei Auftragsabwicklung, Lager, Rechnung, Finance oder externer Logistik. Dort können parallele Wahrheiten gefährlich werden.
Andere Bereiche lassen sich früher produktiv nutzen.
Ein Beispiel ist der B2B-Vertrieb.
Ein Unternehmen kann B2B-Stammdaten, CRM, Pipeline, Preislisten und Vertragsinformationen in Odoo pflegen, bevor Angebote, Lieferungen und Rechnungen vollständig über Odoo laufen.
Dadurch entsteht echter Nutzen: Die Geschäftsführung sieht Pipeline und Potenzial. Sales arbeitet zentraler. Das Supply-Team kann Nachfrage besser antizipieren. Kundendaten werden sauberer. Das Team gewöhnt sich an Odoo.
Der komplette Betrieb wurde damit noch nicht umgestellt. Aber ein konkreter Job wird besser gelöst.
So wird Migration greifbarer, risikoärmer und für Teams weniger abstrakt.
Customizing: Flexibilität mit Timing
Odoo Flexibilität ist einer der großen Vorteile derSoftware. Gleichzeitig verführt das dazu, zu früh zu viel zu bauen.
Gute Odoo-Setups brauchen oft Anpassungen. Besonders bei komplexen Produkten, E-Commerce-Integrationen, B2B-Prozessen, Lagerlogik oder Produktion.
Der entscheidende Punkt ist der Zeitpunkt. Vor echter Nutzung sind viele Anforderungen Annahmen. Nach ein paar Wochen im System sieht die Welt oft anders aus. Teams verstehen Odoo besser. Alte Wünsche verlieren an Bedeutung. Neue Engpässe werden sichtbar. Manche Komfortfunktion wirkt plötzlich unnötig.
Darum sollte jede Anpassung durch ein paar Fragen:
Was ist die Ursache?
Reicht der Standard?
Kann der Prozess anders laufen?
Löst Konfiguration das Problem?
Ist der Sonderfall wichtig genug?
Muss das vor Go-live passieren?
Oder lohnt es sich, echte Nutzung abzuwarten?
Manchmal ist ein manueller Klick vor Go-live besser als eine Customization, die drei Wochen später niemand mehr braucht.
Die häufigsten Fehler bei einer Odoo-Migration
Wenn Odoo-Migrationen teuer, langsam oder chaotisch werden, liegt die Ursache meistens früh im Projekt und bei Entscheidungen, die zu spät, zu weich oder auf der falschen Grundlage getroffen wurden.
1. Alte Prozesse 1:1 übernehmen
Viele Abläufe wirken vertraut, weil sie seit Jahren genutzt werden. Das heißt aber nicht, dass sie gut sind. Wenn ein Workaround im alten System entstanden ist, wird er durch Odoo nicht automatisch sauberer. Er bekommt nur eine neue Oberfläche.
2. Anforderungen sammeln, bevor der Prozess verstanden ist
Viele Anforderungen klingen im ersten Moment plausibel: ein zusätzliches Feld, ein Report, eine Automation, eine Sonderlogik. Manchmal lösen sie aber nicht die Ursache, sondern nur das sichtbare Symptom. Dann wird gebaut, bevor wirklich verstanden wurde, was im Betrieb passieren soll.
3. Zu viel Scope in Phase 1 packen
Wenn alles in die erste Launch-Welle soll, entsteht ein Tsunami: riesig und zerstörerisch.
Dann hängen zu viele Fachbereiche, Sonderfälle, Integrationen und offene Fragen am gleichen Go-live. Was auf dem Papier nach einem vollständigen Start aussieht, wird im Alltag schnell zu einem unübersichtlichen Kraftakt für Projektteam, Key User und operative Teams.
Eine gute erste Phase muss nicht alles lösen. Sie muss den Betrieb stabil ins neue System bringen. Alles, was dafür nicht zwingend gebraucht wird, gehört bewusst ins Backlog.
4. Einen Big Bang erzwingen
Manche Prozesse müssen gemeinsam umgestellt werden, weil Lager, Auftragsabwicklung, Rechnung und Finance eng zusammenhängen. Andere Bereiche lassen sich früher oder später entkoppeln. Wer alles auf einen einzigen Stichtag schiebt, erhöht Change-Aufwand und Fehlerrisiko unnötig.
5. Zu früh customizen
Odoo ist flexibel, und genau das verführt dazu, alte Sonderlogiken schnell nachzubauen. Vor echter Nutzung sind viele Anforderungen aber Annahmen. Wer zu früh baut, automatisiert oft eine Vorstellung vom Prozess, die drei Wochen nach Go-live schon anders bewertet wird.
6. Datenqualität zu spät ernst nehmen
Wenn Stammdaten, Bestände, Preise, offene Posten oder Stücklisten nicht stimmen, verliert das Team schnell Vertrauen ins neue System. Dann ist Odoo zwar live, aber die Menschen fangen wieder an, neben dem System zu prüfen, zu korrigieren und eigene Listen zu führen.
7. Interne Ownership unterschätzen
Ein ERP-Projekt lässt sich nicht vollständig an einen Partner auslagern. Der Partner kann führen, strukturieren, herausfordern und umsetzen. Das Unternehmen muss trotzdem mitentscheiden, mittragen und mitlernen. Ohne interne Verantwortung und gute Adaption wird jedes System irgendwann wieder zum Fremdkörper.
8. Go-live als Abschluss verstehen
Der Go-live ist kein Schlussstrich. Ab diesem Moment zeigt echte Nutzung, welche Prozesse funktionieren, welche Schulungen fehlen, welche Anforderungen an Gewicht verlieren und welche Verbesserungen wirklich relevant werden.
Wann Odoo stark ist
Odoo ist stark, wenn mehrere Teams auf einer gemeinsamen Plattform arbeiten sollen.
Also bei Unternehmen, die Sales, Einkauf, Lager, Finance, Produktion, Service oder Projekte enger verbinden wollen.
Typische gute Ausgangslagen sind:
E-Commerce mit mehreren Kanälen
B2B und B2C parallel
wachsende Handelsunternehmen
Produktion oder Lohnfertigung
komplexere Lagerlogik
Unternehmen mit zu vielen Tools
hoher manueller Abstimmungsaufwand
Finance mit Bedarf an besseren Daten
Organisationen, die skalieren wollen, ohne jeden Prozess über Menschen abzusichern
Odoo ist oft spannend für Unternehmen, denen einfache SaaS-Tools zu klein werden, während SAP, NetSuite oder Microsoft Business Central zu schwergewichtig wirken.
Der Sweet Spot liegt häufig dazwischen: genug Komplexität, damit Integration wirklich Wert schafft. Gleichzeitig genug Pragmatismus, um schnell und iterativ zu besseren Abläufen zu kommen.
Wann Odoo nicht automatisch hilft
Odoo löst keine ungeklärte Organisation: Wenn Prozesse unklar sind, werden sie sichtbarer, wenn Verantwortlichkeiten fehlen, verschwinden sie nicht durch neue Software. Wenn Daten widersprüchlich sind, werden sie durch Migration nicht plötzlich belastbar, wenn Fachbereiche keine Entscheidungen treffen, baut auch Odoo keine gemeinsame Arbeitsweise.
Odoo ist schwierig, wenn ein Unternehmen Plug-and-play erwartet, wenn niemand intern Verantwortung übernimmt, oder das Ziel lautet: „Bitte bildet alles so ab, wie es heute ist.“ Dann sollte man sehr ehrlich prüfen, ob ein Odoo-Projekt der richtige nächste Schritt ist.
Manchmal braucht es zuerst Prozessklärung, manchmal ein Recovery des bestehenden Systems oder eine kleinere Lösung, meist aber vor allem interne Ownership.
Ein gutes ERP-Projekt beginnt mit der Bereitschaft, die eigene Arbeitsweise zu hinterfragen.
Selbst-Diagnose: Ist euer aktuelles System noch euer Betriebssystem?
Wenn ihr über einen Wechsel zu Odoo nachdenkt, helfen ein paar ehrliche Fragen:
Laufen wichtige Prozesse außerhalb eures Systems?
Nutzt ihr Excel oder Google Sheets, um Daten zwischen Tools zu verbinden?
Müssen Mitarbeitende wissen, welche Sonderfälle wie behandelt werden?
Gibt es Informationen, die euer Team kennt, aber euer System nicht?
Stimmen Zahlen zwischen Finance, Lager und Sales nicht automatisch überein?
Dauern Reports länger, weil Daten erst bereinigt werden müssen?
Werden operative Entscheidungen auf Bauchgefühl statt Systemdaten getroffen?
Entstehen neue Tools, weil das aktuelle System Lücken lässt?
Funktioniert euer Prozess nur, solange alles nach Standard läuft?
Müssen Kunden-, Artikel- oder Auftragsdaten doppelt gepflegt werden?
Wird Wachstum eher schwerer als leichter?
Hängen Sonderfälle an einzelnen Personen?
Wird der Monatsabschluss zur Datenjagd?
Können neue Mitarbeitende Prozesse nur durch Zuruf lernen?
Wenn ihr drei oder mehr dieser Fragen mit Ja beantwortet, hat euer aktuelles Setup vermutlich strukturelle Risse.
Bei fünf oder mehr Ja-Antworten bildet euer System euer Business wahrscheinlich nicht mehr sauber ab.
Bei sieben oder mehr Ja-Antworten geht es nicht mehr nur um ein IT-Projekt. Dann geht es um Kontrolle, Verantwortung und Organisationsfähigkeit über die gesamte Wertschöpfungskette hinweg.
Fazit: Der Systemwechsel ist nur der sichtbare Teil
Der Wechsel von weclapp, Xentral oder JTL zu Odoo ist nur der sichtbare Teil.
Die eigentliche Arbeit liegt darunter: Prozesse verstehen, Workarounds hinterfragen, Datenqualität herstellen, Sonderfälle bewerten, die Systemumstellung sauber schneiden, Fachbereiche einbinden, den Go-live kontrolliert gestalten und nach Launch weiter verbessern.
Wenn ihr euer aktuelles System ablöst, entscheidet ihr über mehr als Software. Ihr entscheidet, welche Arbeitsweise ihr in die nächste Wachstumsphase mitnehmt und welche besser zurückbleibt.
Eine gute Odoo-Migration überträgt nicht euer altes System, sondern schafft die Grundlage dafür, dass euer Unternehmen klarer, stabiler und skalierbarer arbeiten kann.
Plant ihr den Wechsel zu Odoo?
Bevor ihr Daten und Prozesse migriert, lohnt sich ein strukturierter Blick auf Prozesse, Daten, Sonderfälle und Migrationsrisiken.
Wir prüfen mit euch, welche Prozesse wirklich ins neue System gehören, welche Daten kritisch sind, was in Phase 1 funktionieren muss und wo die größten Risiken liegen.
FAQ
Wann lohnt sich ein Wechsel von weclapp, Xentral oder JTL zu Odoo?
Ein Wechsel lohnt sich, wenn das aktuelle System zentrale Geschäftsprozesse nicht mehr sauber abbildet. Typische Warnsignale sind Excel-Workarounds, doppelte Datenpflege, manuelle Übergaben, unzuverlässige Reports oder Prozesse, die nur funktionieren, solange alles nach Standard läuft.
Wie läuft eine Odoo-Migration grundsätzlich ab?
Eine saubere Odoo-Migration beginnt mit Prozessverständnis. Zuerst werden Ist-Prozesse, Zielbild, Workstreams, kritische Daten, Sonderfälle und Phase-1-Scope geklärt. Danach folgen Prozessvalidierung, technische Umsetzung, Schulung, Go-live und kontinuierliche Weiterentwicklung.
Sollte man bestehende Prozesse 1:1 nach Odoo übernehmen?
Die 1:1-Übernahme alter Prozesse ist riskant. Bestehende Prozesse sind häufig durch alte Systemgrenzen, manuelle Workarounds oder historische Sonderfälle geprägt. Vor der Migration sollte entschieden werden, welche Prozesse sinnvoll sind, welche neu gedacht werden müssen und welche bewusst wegfallen dürfen.
Welche Prozesse sollte man zuerst migrieren?
Zuerst sollten Prozesse migriert werden, die für den laufenden Betrieb kritisch sind oder schnell isolierten Nutzen stiften. Dazu gehören je nach Unternehmen Angebot, Auftrag, Einkauf, Lager, Lieferung, Rechnung, Finance, CRM oder B2B-Stammdaten. Alles, was nicht go-live-kritisch ist, gehört bewusst ins Backlog.
Wie entscheidet man, welche Sonderfälle in Odoo abgebildet werden?
Ein Sonderfall sollte ins System, wenn er regelmäßig vorkommt, wirtschaftlich relevant ist, rechtlich notwendig ist oder operative Risiken erzeugt. Seltene, historisch gewachsene oder unverhältnismäßig komplexe Sonderfälle sollten geprüft, vereinfacht oder später umgesetzt werden.
Welche Daten müssen vor einer Odoo-Migration bereinigt werden?
Besonders kritisch sind Artikelstammdaten, Kunden, Lieferanten, Lagerbestände, Preislisten, offene Aufträge, offene Rechnungen, Seriennummern, Chargen, Stücklisten und Zahlungsbedingungen. Wenn diese Daten unsauber sind, entstehen im neuen System dieselben Unsicherheiten wie vorher.
Kann man Daten aus JTL, weclapp oder Xentral nach Odoo migrieren?
Grundsätzlich ja. Entscheidend ist aber nicht nur, ob Daten technisch migriert werden können. Wichtig ist, welche Daten wirklich gebraucht werden, wie sauber sie sind und ob historische Daten vollständig ins neue System gehören oder besser archiviert bleiben.
Wie vermeidet man Projektchaos bei einer Odoo-Migration?
Durch klare Priorisierung, saubere Discovery, realistische Phase-1-Definition, frühe Einbindung der Fachbereiche, klare interne Ownership, echte Testfälle, entzerrte Go-lives und bewusste Entscheidungen darüber, was nicht sofort umgesetzt wird.
Ist Odoo falsch, wenn eine Einführung nicht funktioniert?
Nicht zwingend. Häufig liegt das Problem nicht an Odoo selbst, sondern an ungeklärten Prozessen, unsauberen Daten, fehlenden Verantwortlichkeiten oder zu wenig Führung im Projekt. Odoo macht diese Unklarheit sichtbar.
Wie lange dauert eine Odoo-Migration?
Das hängt stark von Scope, Datenqualität, Prozesskomplexität und interner Verfügbarkeit ab. Sinnvoll ist meist ein Phasenmodell: zuerst ein stabiles Fundament, danach gezielte Erweiterungen und kontinuierliche Verbesserung.
Was ist der Unterschied zwischen Datenmigration und Prozessmigration?
Datenmigration überträgt Informationen von einem System ins andere. Prozessmigration entscheidet, wie Arbeit künftig laufen soll. Eine gute Odoo-Migration braucht beides. Die Prozesslogik sollte vor der Datenstruktur kommen.
Warum ist ein Big Bang bei ERP-Migrationen riskant?
Ein Big Bang verändert viele Prozesse, Teams und Abhängigkeiten gleichzeitig. Dadurch steigen Change-Aufwand, Testaufwand und operative Risiken. Wenn möglich, sollten Workstreams und Teil-Go-lives so geschnitten werden, dass der Übergang kontrollierbar bleibt.
Weitere Artikel
ERP-Projekt erfolgreich starten: 9 Entscheidungen, die vor der Implementierung sitzen müssen
ERP-Implementierung: 7 Risiken, die Projekte scheitern lassen (und wie du sie früh erkennst)
Best-of-Breed vs. Best-of-Suite im Mittelstand: HubSpot vs. Odoo im Realitätscheck
Controlling ERP E-Commerce: So skaliert ihr mit belastbaren Finanzdaten
Customer Service ERP: So integrierst du Service, ERP und Logistik richtig
E-Commerce Buchhaltung im ERP: Wenn 60.000 Buchungen im Monat dein System sprengen
E-Commerce Logistik & ERP: Warum Fulfillment ab 5–10 Mio. Umsatz strukturell wird
Bestandsplanung im E-Commerce: Warum Spreadsheets ab 20 Mio. Umsatz scheitern
Made with🫀in Berlin © 2026 bobco GmbH
Made with🫀in Berlin © 2026 bobco GmbH
Made with🫀in Berlin © 2026 bobco GmbH