Warum Odoo-Projekte scheitern: Ursachen und Gegenmittel
Kurz gesagt
Ein Odoo-Projekt scheitert an Entscheidungen, die zu spät fallen: Edition und Hostingart, Firmenstruktur, Datenqualität und Verantwortlichkeiten. Legen Sie diese Punkte je Projektphase mit einem festen Prüftermin fest und prüfen Sie jeden Schritt in einer Testdatenbank. In Deutschland, Österreich und der Schweiz gilt dieselbe Vorgehensweise; sie ist eine redaktionelle Empfehlung, keine Messung.
Das Wichtigste
- Die Phasenfolge entspricht dem Projektplan von Analyse bis Go-live.
- Odoo Online ist laut Dokumentation 20.0 mit eigenen Modulen und Apps-Store-Modulen nicht kompatibel.
- Ein Lokalisierungspaket lässt sich laut Dokumentation 20.0 nur wechseln, solange keine Buchung gebucht ist.
- Eine als Mutterunternehmen angelegte Firma lässt sich laut Dokumentation 20.0 nicht nachträglich in einen Zweig umwandeln.
- Ein Datenimport ist laut Dokumentation 20.0 dauerhaft und nicht rückgängig zu machen.
- Eine Datenbank mit eigenen Modulen lässt sich erst auf eine neue Version heben, wenn die Module für die Zielversion vorliegen.
Wer ein Odoo-Projekt plant, will wissen, an welchen Stellen es hängen bleibt. Eine belegte Abbruchquote, die dieser Artikel zitieren könnte, liegt uns nicht vor, deshalb arbeitet er mit Bedingungen statt mit Quoten: Er nennt je Projektphase die Ursache, die ein Projekt ausbremst, und die Prüfung, die sie früh sichtbar macht.
Worauf es ankommt
Ein Odoo-Projekt hat zwei Sorten von Entscheidungen: solche, die man später noch korrigieren kann, und solche, die eine Datenbank oder ein Upgrade dauerhaft binden. Die zweite Sorte verursacht die teuren Verzögerungen. Die Odoo-Dokumentation 20.0 nennt mehrere solcher Bindungen ausdrücklich: ein Import lässt sich nicht rückgängig machen, ein Lokalisierungspaket nur ohne gebuchte Buchung wechseln, ein Mutterunternehmen nicht in einen Zweig umwandeln, und eine Datenbank mit eigenen Modulen erst dann aufrüsten, wenn die Module für die Zielversion vorliegen.
Die Phasenfolge unten folgt dem Projektplan von Analyse bis Go-live. Der Nutzen der Tabelle liegt nicht in der Reihenfolge, sondern in der Spalte „Prüfung“: Jede Zeile endet mit einem Nachweis, den Sie vor der nächsten Phase sehen können.
Ursachen und Gegenmittel je Projektphase
Die Spalte „Ursache“ nennt eine Bedingung, keine Häufigkeit; die Spalte „Prüfung“ nennt den Nachweis, der die Ursache ausschließt. Die Phasen entsprechen dem verlinkten Projektplan. Die Zuordnung ist eine redaktionelle Einschätzung.
| Phase | Ursache (Bedingung) | Gegenmittel und Prüfung |
|---|---|---|
| 1 Entscheidung | Edition und Hostingart stehen fest, bevor geklärt ist, ob eigene Module nötig sind; Odoo Online nimmt laut Dokumentation 20.0 keine eigenen Module und keine Apps-Store-Module an | Fit-Gap zuerst, Hostingart danach; Prüfung: Liste der Prozesse, die ohne eigenen Code nicht abbildbar sind |
| 2 Analyse | Umfang und Abweichungen vom Standard bleiben offen, spätere Wünsche gelten als Nacharbeit | Je Prozess entscheiden: Standard, Konfiguration oder Anpassung; Prüfung: Freigabe des Umfangs vor der Konfiguration (Fit-Gap-Analyse für Odoo) |
| 3 Konfiguration | Firmenstruktur oder Lokalisierungspaket werden nach den ersten Buchungen korrigiert; laut Dokumentation 20.0 lässt sich das Paket dann nicht mehr wechseln und ein Mutterunternehmen nicht mehr in einen Zweig umwandeln | Rechtsträger und Lokalisierung vor der ersten Buchung festlegen; Prüfung: Firmenbaum und Paket schriftlich abnehmen |
| 4 Datenübernahme | Stammdaten sind unbereinigt; ein Import ist dauerhaft, und fehlende oder geänderte External IDs erzeugen Duplikate | Erstimport in einer Testdatenbank, External IDs vergeben und unverändert lassen, vor dem Import „Test“ nutzen; Prüfung: Prüfbericht je Datenart (Stammdaten vorbereiten) |
| 5 Test und Schulung | Es wird in der Testdatenbank geprüft, aber ihre Grenzen sind nicht bekannt; Testdatenbanken sind laut Dokumentation 20.0 neutralisiert und versenden keine E-Mails | Erwartetes Verhalten der Testumgebung festhalten und Key User die Prozesse üben lassen; Prüfung: Abnahmeprotokoll je Prozess (Abnahmetest für Odoo) |
| 6 Go-live | Kein Stichtag und kein Rückfallweg; Altdaten und neue Buchungen überschneiden sich | Stichtag und Parallelbetrieb festlegen, vorher ein Backup ziehen; Prüfung: Go-live-Checkliste für Odoo abgehakt |
| 7 Stabilisierung | Eigene Module haben keinen Eigentümer; laut Dokumentation 20.0 lässt sich eine Datenbank erst aufrüsten, wenn die Module für die Zielversion vorliegen, und das Entfernen einer App löscht ihre Datensätze | Eine verantwortliche Person je eigenem Modul benennen und App-Änderungen in einer Kopie testen; Prüfung: Betriebs- und Upgrade-Plan (Ablauf des Upgrades) |
Ein Beispiel: eine verschobene Entscheidung
Das folgende Beispiel ist eine Beispielrechnung mit erfundenen Annahmen; es zeigt einen Ablauf, keine Messung. Ein Handelsbetrieb mit 15 Nutzern und acht Apps will in zwölf Wochen live gehen.
- Woche 2: Im Fit-Gap zeigt sich, dass die Lagerbewertung einen eigenen Bericht braucht. Statt sofort zu entscheiden, bleibt der Punkt offen. Wäre Odoo Online bereits gewählt und der Bericht nur über ein eigenes Modul darstellbar, wäre er dort laut Dokumentation nicht möglich; der Betrieb muss die Hostingfrage nachholen.
- Woche 6: Die ausländische Tochter ist noch nicht als eigene Firma angelegt. Weil ein Mutterunternehmen nicht nachträglich zum Zweig wird, kostet die späte Klärung einen Umbau der Struktur.
- Woche 8: Die Buchhaltung hat bereits gebucht, aber das Lokalisierungspaket ist noch nicht geprüft. Der Wechsel ist jetzt nicht mehr möglich.
Aus den drei Punkten werden am Ende nach dieser Rechnung drei Wochen Verzug statt einer Fehlerkorrektur am letzten Tag. Keine dieser Ursachen ist eine Softwarefrage; alle drei sitzen an einem Entscheidungstor.
Welche Fehler den Zeitplan kosten
Die folgende Liste ist eine redaktionelle Einschätzung.
- Ein Entscheidungstor ohne Ergebnis. Wird ein Tor passiert, ohne die Freigabe der Vorstufe einzuholen, wandert der offene Punkt mit und taucht später als vermeintlich neuer Aufwand auf.
- Wachsender Umfang nach der Freigabe. Neue Wünsche nach der Umfangsfreigabe sind Nacharbeit, solange sie nicht als eigener Nachauftrag mit eigener Freigabe behandelt werden.
- Altdaten erst in der Produktivdatenbank bereinigen. Ein Import ist dauerhaft; was in einer Kopie testbar ist, gehört nicht in die produktive Datenbank.
- Eigene Anpassungen ohne Eigentümer. Ohne benannte Person für eigene Module blockiert eine ungepflegte Modulversion später das Upgrade.
- Grenzen der Testumgebung nicht dokumentiert. Wer erwartet, dass eine Testdatenbank E-Mails versendet oder Zahlungen auslöst, deutet das Verhalten falsch.
So gehen Sie vor
- Legen Sie die Phasen aus dem Projektplan mit Ergebnis und Entscheidungstor an und hängen Sie an jedes Tor einen Termin.
- Beantworten Sie die Edition- und Hostingfrage erst nach dem Fit-Gap: Die Frage lautet, ob eigene Module nötig sind (Community oder Enterprise, Hosting-Optionen für Odoo).
- Entscheiden Sie Firmenstruktur und Lokalisierungspaket, bevor die erste Buchung gebucht wird; legen Sie ein Mutterunternehmen zuerst an.
- Führen Sie den ersten Import in einer Testdatenbank aus, vergeben Sie External IDs und dokumentieren Sie, was die Testumgebung nicht kann.
- Benennen Sie für jedes eigene Modul eine verantwortliche Person und halten Sie fest, wer den künftigen Versionswechsel plant.
Offene Punkte, die Sie nicht selbst entscheiden können, gehören an den Partner; die internen Entscheidungen ersetzt das nicht.