Was wir aus zehn Jahren Odoo gelernt haben
Zehn Jahre, zahlreiche Projekte, Migrationen über mehrere Odoo-Versionen. Sechs Lehren daraus - und drei Dinge, die wir heute anders machen als am Anfang.
Die Binadoo AG gibt es seit dem 1. Juni 2026. Das Odoo-Geschäft dahinter ist deutlich älter: Es ist über zehn Jahre bei der Bytebrand Outsourcing AG gewachsen - zahlreiche Projekte, Migrationen über mehrere Odoo-Versionen, eigene Module und Schnittstellen zu Dutzenden von Drittsystemen. Die Ausgliederung war die Konsequenz daraus, nicht der Anfang.
Zehn Jahre in einem System sind lang genug, um dieselben Fehler mehrfach zu sehen - eigene wie fremde. Sechs davon haben unsere heutige Arbeitsweise geprägt.
Lehre 1: Der Umfang entscheidet, nicht die Software
Am Anfang jedes gescheiterten Projekts steht fast nie eine falsche Softwareentscheidung. Es steht ein Umfang, den niemand begrenzt hat: eine Anforderungsliste, die im Verlauf wächst, weil jede Abteilung noch etwas beisteuert und niemand die Autorität hat, Nein zu sagen.
Die Konsequenz daraus ist unser heutiges Vorgehen: Wir machen kein Angebot ohne vorherigen Workshop, in dem der Umfang priorisiert und abgegrenzt wird. Das kostet uns Anfragen - manche springen genau an dieser Stelle ab. Es kostet uns weniger als die Alternative.
Lehre 2: Jede Anpassung kostet zweimal
Der teuerste Satz in einem ERP-Projekt lautet “das haben wir bei uns immer schon so gemacht”. Er führt zu einer Anpassung, die beim Bau bezahlt wird - und danach bei jedem Versionswechsel erneut, weil sie geprüft und oft nachgezogen werden muss.
Über zehn Jahre und mehrere Migrationen wird daraus eine Rechnung, die sich nachlesen lässt. Systeme mit wenigen, bewusst gewählten Anpassungen sind über die Jahre nicht nur billiger, sondern auch beweglicher: Neue Standardfunktionen lassen sich übernehmen, statt an der eigenen Sonderlogik zu scheitern.
Daraus wurde einer unserer vier Grundsätze: Standard vor Anpassung. Individualentwicklung setzen wir dort ein, wo sie echten Mehrwert schafft - nicht als Ersatz für sauberes Prozessdesign.
Kurz gesagt: Die drei häufigsten Ursachen für teure Projekte sind immer dieselben: ein Umfang ohne Grenze, Anpassungen ohne Not und eine Führung, die das Vorhaben an die IT delegiert hat. Die Software steht nie auf der Liste.
Lehre 3: Manchmal ist die richtige Antwort ein eigenes Modul
Der Gegenpunkt zur zweiten Lehre - und der Grund, warum “Standard vor Anpassung” nicht “Standard um jeden Preis” heisst.
Bei der Hosberg AG, einem Bio-Lebensmittelbetrieb, den wir seit über zehn Jahren begleiten, stand eine gesetzeskonforme Schweizer Zeiterfassung an. Odoo bietet die von Haus aus nicht. Die Lösung war ein eigens entwickeltes Modul, heute im Einsatz mit über zehn stationären Stempeluhren an verschiedenen Standorten - und als Open Source veröffentlicht.
Der Unterschied zur überflüssigen Anpassung liegt in der Frage, die man vorher stellt: Ist das eine Anforderung, die aus dem Gesetz oder aus dem Geschäftsmodell kommt - oder eine, die aus Gewohnheit kommt? Bei der ersten Sorte bauen wir. Bei der zweiten fragen wir nach.
Aus derselben Haltung sind unsere Module im offiziellen Odoo App Store entstanden, die heute weltweit von über 5’000 Nutzenden eingesetzt werden. Der Nebeneffekt ist wertvoller als das Produkt: Wer selbst entwickelt und den offiziellen Review-Prozess durchläuft, beurteilt fremden Code anders.
Lehre 4: Systeme müssen mitwachsen können
Hosberg ist in der Zeit unserer Zusammenarbeit von 35 auf 150 Mitarbeitende gewachsen - ohne Systemwechsel. Als 2024 die Bieri Food AG übernommen wurde, war die Umstellung auf eine Mehrfirmenstruktur nötig; die Integration gelang innerhalb weniger Wochen.
Das ist die Erfahrung, die uns bei der Plattformfrage geprägt hat. Der Wert eines Systems zeigt sich nicht beim Go-live, sondern beim dritten unerwarteten Ereignis danach: Zukauf, neuer Standort, neues Geschäftsfeld, doppelte Mitarbeiterzahl.
Deshalb fragen wir in jedem Workshop nach dem Wachstumspfad - nicht aus Höflichkeit, sondern weil er die Architektur bestimmt.
Lehre 5: Nach dem Go-live beginnt die Arbeit
Die unangenehmste Lehre, weil sie dem klassischen Projektdenken widerspricht. Projekte scheitern selten beim Start. Sie scheitern in den zwölf Monaten danach - wenn niemand zuständig ist, Rückmeldungen nirgends ankommen und das System auf dem Stand des Einführungsjahres stehen bleibt, während sich der Betrieb weiterentwickelt.
Wir haben daraus zwei Konsequenzen gezogen. Erstens gehört die Frage nach der internen Verantwortung heute in den Workshop, nicht in ein Gespräch nach dem Go-live. Zweitens endet unsere Zusammenarbeit nicht mit der Abnahme.
Die Muster dahinter sind allgemein genug, dass sie in eigenen Beiträgen stehen: Warum Odoo kein einmaliges Projekt ist und Wenn Odoo zu wenig Nutzen bringt.
Lehre 6: Der Prozess entscheidet, nicht die Branche
Über zehn Jahre haben wir Betriebe aus dem Automobilhandel, der Lebensmittelverarbeitung, der Logistik, dem Agenturgeschäft und der Softwareentwicklung begleitet. Die Erwartung wäre, dass jede Branche eigene Antworten braucht.
Die Erfahrung sagt etwas anderes. Ein Lebensmittelbetrieb mit 57 Mitarbeitenden, 18 Lieferwagen, 5’000 Palettenplätzen in drei Temperaturzonen und über 2’500 Artikeln hat andere Details als ein Onlinemarktplatz, bei dem täglich hunderte Anfragen automatisch verteilt werden müssen. Die Struktur der Fragen ist dieselbe: Wo entstehen Daten, wo werden sie gebraucht, wer entscheidet was, und wo bricht die Kette.
Nicht die Branche entscheidet über die Lösung. Der Prozess entscheidet über die Lösung.
Das ist übrigens keine neue Erkenntnis. Sie stammt aus einer Zeit lange vor Odoo - 1992 und 1993, als ich mit Microsoft Access ein komplettes ERP für einen Büromaterial-Grosshandel entwickelt habe. Die Werkzeuge haben sich vollständig verändert. Die Frage nicht.
Drei Dinge, die wir heute anders machen
Wir beraten vor dem Verkauf. Am Anfang stand, wie üblich, das Angebot vorne. Heute steht der kostenlose Projekt-Check und danach der Workshop davor - und der Festpreis kommt erst, wenn er belastbar ist.
Wir raten öfter ab. Ein Projektstopp nach dem Workshop ist bei uns als reguläres Ergebnis hinterlegt, nicht als verlorener Verkauf. Das war früher anders, und es hat uns Projekte gebracht, die für beide Seiten mühsam wurden.
Wir haben uns festgelegt. Ein Dutzend Systeme oberflächlich zu betreuen ist bequemer, weil man auf jede Anfrage antworten kann. Es hilft dem Kunden nicht. Die Entscheidung fiel auf Odoo, weil es das Grundproblem unserer Kunden adressiert: getrennte Systeme statt einer gemeinsamen Steuerungsgrundlage.
Fazit
Zehn Jahre in einem System lehren vor allem eines: Die teuren Fehler sind selten technisch. Sie entstehen bei der Abgrenzung des Umfangs, bei Anpassungen ohne Not und in der Zeit nach dem Go-live, in der niemand mehr zuständig ist.
Was daraus für Sie folgt, ist unspektakulär: Klären Sie den Umfang, bevor Sie eine Zahl verlangen. Fragen Sie bei jeder Sonderlogik, woher sie kommt. Und benennen Sie jemanden, der das System nach dem Go-live verantwortet - bevor der Go-live stattfindet.
Weiterführend: Themenwelt Binadoo Insights · Lösung ERP. Den nächsten Schritt machen Sie mit dem kostenlosen Projekt-Check.
Profitieren Sie von diesen Erfahrungen
Im kostenlosen Projekt-Check ordnen wir Ihre Ausgangslage ein - auf Basis dessen, was in vergleichbaren Projekten funktioniert hat.
