Ein Odoo-Projekt, das nicht wie geplant verläuft, ist eine häufigere Situation, als es scheint, und sie hat nichts Aussergewöhnliches bei der Einführung einer Verwaltungssoftware. Sie haben Zeit und Ressourcen investiert, und das Ergebnis entspricht nicht dem Erwarteten. Bevor irgendetwas vorgeschlagen wird, muss diese Situation für das anerkannt werden, was sie ist: Ein Projekt scheitert selten wegen einer einzigen Partei, und wir kennen nicht den vollständigen Kontext — Fristen, Budget, Kommunikation, Zwänge auf beiden Seiten —, in dem die Entscheidungen getroffen wurden. Dieses Dokument beschreibt, wie ein Odoo-Projekt in Schwierigkeiten besonnen übernommen werden kann, ohne Opportunismus.
Es besteht kein Anlass, vor dem Handeln nach einem Schuldigen zu suchen. Eine Odoo-Einführung beteiligt mehrere Parteien — den Anbieter, das Kundenunternehmen, manchmal Dritte wie einen Hoster oder einen anderen verbundenen Softwarehersteller — und jede beeinflusst das Endergebnis. Was an diesem Punkt zählt, ist nicht, den Entscheidungsverlauf zu rekonstruieren, sondern den tatsächlichen Zustand des Systems heute zu verstehen und in Kenntnis der Sachlage über die weitere Vorgehensweise zu entscheiden.
Die typischen Situationen
Mehrere Szenarien wiederholen sich regelmässig bei Unternehmen, die ein bestehendes Odoo-Projekt übernehmen möchten.
- Der frühere Anbieter ist nicht erreichbar oder hat seine Tätigkeit eingestellt. Keine Antwort mehr auf Anfragen, keine Betreuung mehr, manchmal auch kein Unternehmen mehr.
- Das Projekt ist unterwegs stehen geblieben. Ein Teil der Konfiguration besteht, aber die Einführung wurde nie abgeschlossen.
- Das Budget wurde ohne Inbetriebnahme überschritten. Ressourcen wurden investiert, aber das Werkzeug ist im Alltag immer noch nicht nutzbar.
- Die Instanz ist produktiv, aber unbenutzbar. Die Teams umgehen das Werkzeug, kehren zu Excel oder alten Systemen zurück, mangels an ihre tatsächlichen Prozesse angepasster Konfiguration.
- Die erzeugte Buchhaltung ist falsch. Abweichungen, inkohärente MwSt-Abrechnungen, Bankabstimmungen, die nie erfolgen.
- Nicht dokumentierte Entwicklungen. Spezifischer Code läuft produktiv, ohne dass jemand genau weiss, was er tut oder warum er so geschrieben wurde.
- Niemand intern weiss, wie die Instanz funktioniert. Die Abhängigkeit von einer einzigen Person — oft dem Anbieter selbst — hat sich eingeschlichen, ohne dass das Unternehmen es bemerkt hat.
Der erste Schritt: die Kontrolle über Ihre Zugänge, Ihren Code und Ihre Daten zurückerlangen
Vor jeder Diagnose oder Entscheidung über die Fortsetzung muss sichergestellt werden, dass das Unternehmen tatsächlich die Kontrolle über seine eigenen Vermögenswerte hat. Das ist ein Schritt, der vorrangig behandelt werden muss, oft noch bevor überhaupt ein neuer Anbieter gesucht wird, weil ein verlorener Zugang sehr schwer zurückzugewinnen sein kann, sobald die Verbindung zum früheren Anbieter endgültig abgebrochen ist.
- Der Administratorzugang zur Odoo-Instanz, nicht nur ein Nutzerkonto.
- Der Zugang zum Hosting, auf dem die Instanz läuft, oder zumindest das Wissen, wer es hostet und unter welchem Vertrag.
- Das Eigentum am damit verbundenen Domainnamen, sofern vorhanden, und dessen DNS-Verwaltung.
- Der Code der spezifischen Entwicklungen, in einem vom Unternehmen kontrollierten Repository, nicht nur auf der Maschine des Anbieters.
- Die bestehenden Sicherungen und ein aktueller Datenexport, unabhängig davon, was danach geschieht.
Solange diese Elemente nicht auf Unternehmensseite gesichert sind, bleibt jede Diskussion über die Fortsetzung des Projekts fragil: Man entscheidet nicht gelassen über die Zukunft eines Systems, über das man keine Kontrolle hat. In den angespanntesten Fällen, in denen der Kontakt zum früheren Anbieter abgebrochen ist, kann dieser Schritt erfordern, den Hoster direkt anzusprechen, die vertraglichen Bedingungen zum Dateneigentum zu prüfen oder ein im ursprünglichen Vertrag vorgesehenes Rückgaberecht geltend zu machen. Das ist ein manchmal unangenehmes Vorgehen, das aber alles Weitere bedingt.
Der technische und buchhalterische Zustandsbericht
Sobald die Zugänge gesichert sind, folgt eine vollständige Diagnose, die in ihrer Methode einem klassischen Odoo-Instanz-Audit nahekommt, aber auf eine Übernahmeentscheidung statt auf eine blosse Aufnahme ausgerichtet ist. Sie betrifft die Buchhaltungs- und MwSt-Konfiguration, die Lohnparametrierung, sofern vorhanden, die aktiven Module, die spezifischen Entwicklungen und ihren Dokumentationsgrad, die Datenqualität, die Zugriffsrechte und den Zustand der Sicherungen. Die buchhalterische Dimension wird mit derselben Sorgfalt wie die technische geprüft: Eine ohne sichtbaren Fehler laufende Instanz kann dennoch falsche Zahlen erzeugen, und oft ist genau dieser Punkt der Auslöser für die Suche nach einer neuen Begleitung.
Diese Diagnose beantwortet sehr konkrete Fragen. Sind die bisher erzeugten Buchungen nutzbar, oder muss eine Periode zurückgenommen und korrigiert werden? Entspricht die an die Behörden übermittelte MwSt-Abrechnung tatsächlich der Tätigkeit des Unternehmens? Stellen die produktiven spezifischen Entwicklungen ein unmittelbares Risiko dar, oder können sie einen nächsten Schritt abwarten? Die Antworten auf diese Fragen bestimmen die Dringlichkeit jeder Massnahme und vermeiden, einen Nebenpunkt als vorrangig zu behandeln, während ein gravierenderes Problem ignoriert bleibt.
Entscheiden: reparieren, neu aufbauen oder auf den Standard zurücksetzen
Der Zustandsbericht mündet in eine Wahl zwischen drei Optionen, und diese Wahl muss auf konkreten Kriterien beruhen, statt auf einem allgemeinen Eindruck der Situation.
- Das Bestehende reparieren ist sinnvoll, wenn die Basis insgesamt gesund ist: Die Konfiguration entspricht den tatsächlichen Bedürfnissen, die spezifischen Entwicklungen sind von korrekter Qualität, und die festgestellten Probleme sind lokalisiert und identifizierbar.
- Von einer sauberen Basis neu beginnen rechtfertigt sich, wenn sich die Konfiguration zu weit von den tatsächlichen Prozessen des Unternehmens entfernt, wenn die Entwicklungen zu anfällig oder zu zahlreich sind, um sie einzeln zu stabilisieren, oder wenn die Datenqualität zu stark beeinträchtigt ist, um zuverlässig korrigiert zu werden.
- Die Instanz auf den Odoo-Standard zurücksetzen besteht darin, die riskantesten Individualisierungen zu entfernen und so weit wie möglich zu den nativen Funktionen zurückzukehren, insbesondere wenn die spezifischen Entwicklungen nicht dokumentiert sind und jedes Versionsupgrade erschweren. Das ist oft der mittelfristig tragfähigste Weg.
Das entscheidende Kriterium ist nicht das scheinbare Ausmass des Schadens, sondern die Tragfähigkeit jeder Option über die Zeit: Eine schnelle Reparatur, die dieselben Ursachen bestehen lässt, hat das Problem nur aufgeschoben. Eine technisch instabile Instanz, deren fachliche Konfiguration jedoch stimmig ist, muss nicht neu aufgebaut werden; umgekehrt bleibt eine stabile Instanz, die aber auf Prozessen beruht, die der tatsächlichen Tätigkeit des Unternehmens nicht mehr entsprechen, unabhängig von den technischen Korrekturen ein Klotz am Bein.
Die Instandsetzung
Sobald die Option gewählt ist, folgt die Instandsetzung den im Zustandsbericht ermittelten Prioritäten: zuerst die Korrektur der Buchhaltungs- und MwSt-Konfiguration, da sie direkte und unmittelbare Auswirkungen auf die gesetzlichen Pflichten des Unternehmens hat, dann die Bereinigung der Daten, dann die Übernahme oder Ersetzung der anfälligsten Entwicklungen. Je nach Bedarf kann dies unsere dedizierten Seiten zu Odoo Buchhaltung, zur Lohnbuchhaltung oder zur spezifischen Entwicklung einbeziehen. Ähnelt die Situation eher einer neuen Einführung als einer Korrektur, gehört sie zu unserer Seite Odoo-Implementierung.
Dokumentation und Wissenstransfer
Eine Projektübernahme, die sich auf die Korrektur der Symptome beschränkt, reproduziert die Abhängigkeit, die zur ursprünglichen Situation geführt hat. Die Dokumentation ist daher kein Nebenschritt: Jede Konfigurationsentscheidung, jede spezifische Entwicklung, jede in Odoo parametrierte Geschäftsregel muss irgendwo so festgehalten werden, dass sie für eine Person verständlich ist, die nicht am Projekt beteiligt war. Diese Dokumentation muss nicht im Sinne eines vollständigen technischen Handbuchs erschöpfend sein: Sie muss vor allem die Fragen beantworten, die sich eine aussenstehende Person beim Entdecken der Instanz stellen würde — warum dieses Feld existiert, wozu diese Automatisierung dient, welche Geschäftsregel diese Parametrierung statt einer anderen rechtfertigt.
Diese Arbeit geht mit einem Wissenstransfer an Ihre Teams einher, damit die tägliche Nutzung des Werkzeugs nicht mehr auf einer einzigen Person beruht, intern oder extern. Siehe unsere Seite Odoo-Schulung für diese Begleitung, und Odoo-Support für die weitere Betreuung, sobald die Instanz instand gesetzt ist.
Vermeiden, mit dem nächsten Anbieter erneut in diese Situation zu geraten
Bestimmte, von Beginn einer neuen Zusammenarbeit an getroffene Vorkehrungen verringern deutlich das Risiko, eine ähnliche Situation erneut zu erleben:
- Die Reversibilität: die konkrete Möglichkeit, den Anbieter zu wechseln, ohne von Grund auf neu zu beginnen, von Anfang an vorgesehen statt in Eile ausgehandelt.
- Die Zugänge: Das Unternehmen behält jederzeit die Administratorzugänge zu seiner Instanz, seinem Hosting und seinem Domainnamen.
- Die Dokumentation: als Projektlieferobjekt verlangt, nicht als dem Ermessen des Anbieters überlassene Option.
- Das Eigentum am Code: die für das Unternehmen realisierten spezifischen Entwicklungen gehören ihm, in einem von ihm kontrollierten Repository.
Diese vier Punkte garantieren nicht, dass ein Projekt reibungslos verläuft, aber sie garantieren, dass ein Zwischenfall reparierbar bleibt. Um diesen Ansatz in unsere Gesamtleistungen einzuordnen, siehe Odoo ERP in Genf und Odoo in Genf. Betrifft der Zweifel eher den allgemeinen Zustand einer Instanz als ein klar gestopptes Projekt, kann unsere Seite Odoo-Instanz-Audit der passendere Ausgangspunkt sein.