Odoo-Apps: Standard, Drittanbieter und eigene Erweiterungen
Es gibt eine Frage, die ich in Projekten fast täglich höre: “Geht das mit Odoo?” Und nach über zehn Jahren mit Odoo-Projekten kann ich sagen: Die Antwort ist fast immer Ja. Die eigentliche Frage ist eine andere – und sie wird viel zu selten gestellt: Auf welchem Weg soll es gehen?
Denn Funktionalität kommt in Odoo aus drei Quellen: aus dem Standard, aus Drittanbieter-Modulen oder aus eigener Entwicklung. Alle drei haben ihre Berechtigung. Aber sie unterscheiden sich fundamental in dem, was nach dem Go-live passiert – bei jedem Update, jedem Versionssprung, jedem neuen Mitarbeiter, der das System verstehen muss. Die Wahl der Quelle ist keine technische Detailfrage. Sie ist eine Entscheidung über die Wartbarkeit Ihres Systems auf Jahre hinaus.
Quelle 1: Der Standard – unterschätzt und fast immer die richtige erste Wahl
Der Odoo-Standard deckt mehr ab, als die meisten glauben. Über 40 Apps, von CRM bis Fertigung, entwickelt und getestet für Millionen von Nutzern weltweit, dokumentiert, geschult, und – das ist der entscheidende Punkt – von Odoo selbst über jede Version weitergetragen. Was im Standard läuft, überlebt jedes Upgrade ohne Ihr Zutun.
Darum gilt bei uns die eiserne Regel: Standard zuerst. Bevor wir auch nur eine Zeile Code schreiben, prüfen wir, ob der Standard die Anforderung abdeckt – oder ob sie sich mit Konfiguration lösen lässt: Felder, Automatisierungen, Berichte, Zugriffsrechte. Das ist keine Bequemlichkeit, sondern Erfahrung: Jede Abweichung vom Standard ist ein Rucksack, den Ihr System ab sofort auf jedem Versionssprung trägt.
Und manchmal heisst die ehrlichste Empfehlung: Passen Sie den Prozess an, nicht die Software. Wenn ein Ablauf nur deshalb “speziell” ist, weil er historisch so gewachsen ist, kostet seine Nachprogrammierung mehr, als seine Vereinfachung je einsparen würde. Wann sich Anpassungen wirklich lohnen, haben wir separat aufgeschrieben.
Quelle 2: Drittanbieter – Zehntausende Module, sehr unterschiedliche Qualität
Für alles, was der Standard nicht abdeckt, gibt es einen riesigen Markt: Im Odoo App Store stehen Zehntausende Module von Anbietern aus aller Welt, dazu die kuratierten Open-Source-Module der OCA (Odoo Community Association) – für viele Spezialfälle existiert dort eine fertige, erprobte Lösung.
Das ist ein echter Vorteil des Odoo-Ökosystems. Aber hier ist der Punkt, den viele unterschätzen: Mit jeder installierten Drittanbieter-App gehen Sie eine langfristige Abhängigkeit ein. Bei jedem Odoo-Versionssprung muss dieses Modul mitziehen – und ob es das tut, entscheidet nicht Odoo, sondern der Anbieter. Ein verwaistes Modul kann ein Upgrade blockieren oder teuer machen.
Darum prüfen wir Drittanbieter-Module nach einer festen Checkliste, bevor sie in ein Kundensystem kommen:
- Versionspflege: Wurde das Modul über die letzten Odoo-Versionen zuverlässig nachgeführt?
- Verbreitung: Nutzen es viele – oder wären Sie der Grossversuch?
- Quellcode: Ist er offen und sauber, sodass wir im Notfall selbst eingreifen können?
- Anbieter: Reagiert er auf Anfragen? Gibt es ihn seit mehr als einer Saison?
- Test: Läuft das Modul in einer Testumgebung gegen Ihre echten Prozesse, bevor es produktiv geht?
Die OCA-Module haben hier strukturelle Vorteile: offener Code, Reviews durch die Community und eine gemeinsame Verantwortung für die Nachführung – deshalb sind sie oft unsere erste Anlaufstelle vor dem kommerziellen App Store.
Quelle 3: Eigene Erweiterungen – das schärfste Werkzeug, sparsam eingesetzt
Manchmal ist die Anforderung echt: ein Kernprozess, der Ihr Unternehmen von der Konkurrenz unterscheidet, eine Schnittstelle zu einem Branchensystem, eine Automatisierung, die es schlicht nirgends zu kaufen gibt. Dann – und erst dann – entwickeln wir selbst.
Eigenentwicklung ist nicht böse. Sie ist das schärfste Werkzeug im Kasten, und wie jedes scharfe Werkzeug verlangt sie Disziplin:
- Erweitern statt verändern. Eigene Module docken an den Standard an, statt ihn umzubauen. Der Odoo-Kern bleibt unangetastet – das hält den Upgrade-Pfad frei.
- Klein halten. Je weniger eigener Code, desto kleiner der Rucksack. Zehn saubere Erweiterungspunkte schlagen einen umgebauten Kernprozess um Längen.
- Upgrade von Anfang an mitdenken. Jede Erweiterung wird so gebaut und dokumentiert, dass sie beim Versionssprung nachgeführt werden kann – von uns oder von jedem anderen, der sauberen Code lesen kann. Keine Abhängigkeit von einer einzelnen Person.
Warum uns das wichtig ist, haben wir im Beitrag über Performance und Wartbarkeit vertieft: Wir wollen Systeme hinterlassen, die auch in fünf Jahren noch jemand versteht – nicht Monumente, die nur ihr Erbauer warten kann.
Die Reihenfolge ist das Prinzip
Zusammengefasst ist unsere Entscheidungslogik bewusst unspektakulär – und genau darum funktioniert sie:
- Standard? Konfigurieren statt programmieren.
- Prozess anpassbar? Manchmal ist der Ablauf das Problem, nicht die Software.
- Erprobtes Modul? OCA zuerst, dann App Store – geprüft nach Checkliste.
- Eigenentwicklung. Standardnah, klein, dokumentiert, upgradefähig.
Jede Stufe, die Sie früher aussteigen, spart nicht nur Projektkosten – sie spart über Jahre Wartung. Ob Standard oder Individualentwicklung ist am Ende keine Glaubensfrage, sondern eine Rechnung über die Lebensdauer des Systems.
Und falls Sie gerade vor so einer Entscheidung stehen: Bringen Sie uns die Anforderung. Wir sagen Ihnen ehrlich, auf welcher Stufe sie sich lösen lässt – auch wenn die Antwort lautet, dass es dafür keine einzige Zeile Code braucht.
Unsicher, welcher Weg der richtige ist?
Wir prüfen Ihre Anforderung ehrlich: Standard, bewährtes Modul oder Eigenentwicklung – und sagen auch, wenn die beste Lösung die einfachste ist.
