Kurze Antwort: Odoo Studio ist Odoos Low-Code-Schicht, mit der Sie Felder, Bildschirme und Automatisierungen ohne Programmierung anpassen. Verlockend, aber wir sind bewusst vorsichtig damit. Bei Versions-Upgrades brechen Studio-Anpassungen regelmäßig - Felder verschwinden aus Views, vererbte Views werden zurückgesetzt - und in Kombination mit Eigenentwicklung führt es fast unweigerlich zu schwer lokalisierbaren Störungen. Für alles, was wirklich zählt, bevorzugen wir Anpassungen, die man isolieren und abschalten kann.
Was Odoo Studio verspricht
Studio ist attraktiv, und das verstehen wir. Sie müssen nicht auf einen Entwickler warten, fügen selbst schnell ein Feld hinzu, passen einen Bildschirm an oder bauen eine kleine Automatisierung. Für kleine, isolierte Dinge ist das auch in Ordnung. Wir sind nicht gegen Studio; wir sind gegen Studio als Standardantwort auf jeden Wunsch.
Denn die Geschichte hört nicht bei “es funktioniert heute” auf. Ein ERP-System muss jahrelang halten, und genau da hakt es.
Wo es schiefgeht: das Upgrade
Odoo bringt jedes Jahr eine neue Version. Anpassungen, die Sie in der Oberfläche über den Standard-Views machen, überleben so ein Upgrade nicht immer. In der Praxis sehen wir es als Felder, die plötzlich aus einer View verschwunden sind, oder vererbte Views, die beim Upgrade auf Standard zurückgesetzt wurden.
Die Folge: Nach dem Upgrade sieht Ihr frisch eingerichteter Bildschirm anders aus, und Sie müssen ihn von Hand wiederherstellen. Genau in dem Moment, in dem Sie ohnehin mit dem Upgrade beschäftigt sind, und ohne dass sauber festgehalten ist, was vorher da war. Das ist kein Einzelfall, sondern ein wiederkehrendes Muster.
Noch riskanter: Studio plus Eigenentwicklung
Richtig gefährlich wird es, wenn Studio und Eigenentwicklung nebeneinander leben. Studio ändert die View in der Datenbank, Eigenentwicklung ändert Dinge im Code, und die beiden Schichten wissen nichts voneinander.
Bei einer Störung können Sie dann nicht sagen, ob es an Studio liegt, am Code oder am Konflikt zwischen beiden. Das sind genau die Störungen, die Stunden zum Finden kosten, weil es keinen einzigen Ort zum Nachschauen gibt. Je mehr Studio-Anpassungen auf einer Eigenentwicklung liegen, desto undurchsichtiger wird das Ganze.
Warum wir Eigenentwicklung bevorzugen: man kann sie abschalten
Der größte Vorteil eines sauberen Custom-Moduls ist einfach: Sie können es isolieren. Geht etwas kaputt, schalten Sie das Modul ab. Funktioniert es danach wieder? Dann wissen Sie, wo der Fehler sitzt. Immer noch kaputt? Dann liegt es woanders.
Dieser Aus/Ein-Test ist beim Lokalisieren von Störungen unbezahlbar, und genau das lässt sich mit in der Datenbank verwobenen Studio-Anpassungen nicht sauber machen. Hinzu kommt, dass Eigenentwicklung in der Versionsverwaltung liegt, vor dem Upgrade gegen eine neue Odoo-Version getestet werden kann und Ihnen genau zeigt, was sich ändert. Das ist kein Luxus; es ist der Unterschied zwischen einem beherrschbaren System und einem System, das niemand mehr upzugraden wagt.
| Odoo Studio | Eigenentwicklung (Modul) | |
|---|---|---|
| Etwas Kleines schnell ändern | Stark | Langsamer |
| Verhalten bei Upgrades | Bricht regelmäßig (Felder weg, Views zurückgesetzt) | Getestet, in Versionsverwaltung |
| Bei Störungen isolierbar | Nein, in der Datenbank verwoben | Ja: abschalten, Fehler lokalisiert |
| Mit Eigenentwicklung kombinieren | Riskant, schwer zu debuggen | Eine konsistente Codebasis |
| Langfristige Wartung | Unvorhersehbar | Beherrschbar |
Wann Studio in Ordnung ist
Ehrlich: Studio ist nicht der Teufel. Ein zusätzliches Feld auf einem unkritischen Modell, ein schneller Prototyp, um eine Idee zu zeigen, eine kleine eigenständige Automatisierung. Für solche kleinen, isolierten Dinge kann Studio gut funktionieren, sofern Sie akzeptieren, dass Sie es nach einem Upgrade vielleicht kurz prüfen müssen.
Die Grenze liegt bei zwei Dingen: geschäftskritisch und das Vorhandensein von Eigenentwicklung. Sobald eines davon ins Spiel kommt, wiegt die Geschwindigkeit von Studio das Risiko nicht mehr auf.
Unsere Faustregel
Nutzen Sie Studio so wenig wie möglich, und nie für etwas Geschäftskritisches oder in Kombination mit Eigenentwicklung. Sobald es zählt, oder sobald bereits Eigenentwicklung in der Nähe ist, wählen Sie Anpassungen, die Sie isolieren, testen und abschalten können.
Das ist kein Dogma gegen Low-Code; es ist hart gelernt aus Upgrades und Störungen. Odoo Studio ist selten die Lösung. Oft ist es der Anfang des Problems.
Häufige Fragen
Ist Odoo Studio schlecht? Nein, nicht schlecht, aber wir sind bewusst vorsichtig damit. Für kleine, isolierte Anpassungen kann Studio gut funktionieren. Das Risiko liegt im Muster: bei Upgrades brechen Studio-Anpassungen regelmäßig, und in Kombination mit Eigenentwicklung führt es zu schwer lokalisierbaren Störungen.
Brechen Studio-Anpassungen bei einem Odoo-Upgrade? Ja, regelmäßig. Wir sehen Felder, die aus einer View verschwinden, und vererbte Views, die beim Upgrade auf Standard zurückgesetzt werden. Ihr frisch eingerichteter Bildschirm sieht dann anders aus und muss von Hand wiederhergestellt werden, genau während des Upgrades.
Odoo Studio oder Eigenentwicklung? Klein und isoliert, auf einem unkritischen Modell: Studio geht. Geschäftskritisch oder neben bestehender Eigenentwicklung: wählen Sie Eigenentwicklung. Ein Custom-Modul lässt sich isolieren, gegen eine neue Odoo-Version testen und liegt in der Versionsverwaltung, Sie wissen also genau, was sich ändert.
Kann man Odoo Studio und Eigenentwicklung kombinieren? Technisch ja, aber riskant. Studio ändert die View in der Datenbank, Eigenentwicklung im Code, und die beiden Schichten wissen nichts voneinander. Bei einer Störung können Sie dann nicht sagen, ob es an Studio, am Code oder am Konflikt dazwischen liegt. Das sind die Störungen, die Stunden kosten.
Was tun Sie bei einer Störung? Bei Eigenentwicklung schalten wir das betreffende Modul einfach ab, um zu sehen, ob das Problem verschwindet. Tut es das, wissen Sie, wo der Fehler sitzt. Dieser Aus/Ein-Test ist beim Lokalisieren unbezahlbar, und mit in der Datenbank verwobenen Studio-Anpassungen lässt er sich nicht sauber durchführen.
Lieber ein System, das in drei Jahren noch upgradebar ist?
Genau darauf steuern wir hin: Änderungen, die Sie isolieren, testen und zurückrollen können, statt unsichtbarer Eingriffe, die bei jedem Upgrade Überraschungen liefern. Mehr zu dieser Abwägung in Odoo selbst einführen oder über einen Partner und unserer Implementierungsmethode. Möchten Sie es für Ihre Situation besprechen? Kostenloses Kennenlerngespräch buchen.