Odoo-Daten auswerten, ohne ein BI-Projekt zu starten

In jedem Odoo-System, das ein oder zwei Jahre in Betrieb ist, steckt mehr Wissen, als je jemand zu Gesicht bekommt. Die Zahlen liegen da — Deckungsbeiträge je Kunde, Lagerreichweiten, Zahlungsverhalten, Lieferantentreue, Auslastung. Nur eben verteilt über Dutzende Module und in Listenansichten, die für die tägliche Erfassung gebaut wurden, nicht für die Frage „warum eigentlich?".

Die Frage kommt in fast jedem Odoo-Projekt irgendwann: Schön, jetzt sind alle Daten drin — und wie schauen wir sie uns an?

Was Odoo von Haus aus kann

Mehr, als die meisten nutzen. Fast jede Listenansicht lässt sich per Klick in eine Pivot-Ansicht umschalten, nach beliebigen Feldern gruppieren, mit Messwerten versehen und als Favorit speichern. Die Graph-Ansicht daneben liefert Balken, Linien und Kreise auf denselben Daten. Wer das konsequent einsetzt, deckt einen großen Teil des Bedarfs ab, ohne ein einziges zusätzliches Werkzeug.

Dazu kommen die Dashboards der jeweiligen Module und, in der Enterprise-Edition, die Möglichkeit, gespeicherte Ansichten auf einer eigenen Übersicht zu sammeln.

Der erste Rat ist deshalb selten „kauf ein BI-Tool", sondern: Nutzt erst einmal, was da ist. Eine gespeicherte Pivot-Ansicht „Umsatz je Kunde und Quartal", die jeden Montag von den richtigen Leuten geöffnet wird, ist mehr wert als ein Dashboard-Projekt, das nie fertig wird.

Wo es aufhört

Die Grenze ist erreicht, sobald eine Frage mehrere Module verbindet. Beispiele aus der Praxis:

• Was ist der echte Deckungsbeitrag je Kunde — inklusive Lagerbewegungen, Nachlieferungen und dem Aufwand für Reklamationen?
• Welche Lieferanten liefern zuverlässig, gemessen an zugesagtem gegen tatsächliches Lieferdatum über zwei Jahre?
• Wie entwickelt sich die Lagerreichweite je Artikelgruppe im Verhältnis zur Absatzprognose?

Solche Auswertungen lassen sich in der Standardoberfläche kaum abbilden. Sie verbinden Verkauf, Einkauf, Lager und Buchhaltung — jedes Modul kennt nur seinen Ausschnitt.

Die zweite Grenze ist die Rolle. Ein Geschäftsführer will keine Pivot-Tabelle zusammenklicken, sondern eine Seite sehen, auf der die relevanten Zahlen bereits stehen. Werkzeuge, die Konfiguration verlangen, werden von Führungskräften nicht benutzt. Sie werden einmal gezeigt und dann nie wieder geöffnet.

Der klassische Ausweg — und warum er oft zu groß ist

Der Standardweg lautet: Data Warehouse aufsetzen, ETL-Strecke bauen, die Odoo-Daten regelmäßig dorthin spiegeln, ein BI-Werkzeug daraufsetzen, Datenmodell nachbauen, Dashboards entwickeln. Fachlich richtig — und für einen Mittelständler mit einer sauber laufenden Odoo-Instanz meist völlig überdimensioniert.

Was dabei realistisch anfällt: mehrere Monate bis zum ersten belastbaren Dashboard, Lizenzkosten für das BI-Werkzeug, Aufwand für den Betrieb der Spiegelung, und ein Datenmodell, das bei jeder Änderung in Odoo nachgezogen werden muss. Der Nutzen rechtfertigt das erst ab einer gewissen Größe — oder wenn tatsächlich mehrere Quellsysteme zusammenkommen.

Wann es sich lohnt: mehrere Quellsysteme, mehrjährige Historien unabhängig vom Quellsystem, oder Auswertungen auf Datenmengen, die das Produktivsystem spürbar bremsen.

Wann nicht: alles liegt in einer Odoo-Instanz, die Datenmenge ist überschaubar, und gebraucht wird vor allem eine gute Sicht auf das, was ohnehin schon da ist.

Der Mittelweg: lesender Zugriff über die API

Dazwischen liegt ein Weg, der in der Diskussion oft fehlt: ein Analyse-Werkzeug, das sich lesend an die Odoo-API hängt und direkt auf den Live-Daten arbeitet, statt sie vorher zu kopieren.

Die Vorteile liegen auf der Hand: kein zweiter Datenbestand, der auseinanderlaufen kann. Keine Spiegelungsstrecke, die nachts scheitern kann. Keine Verzögerung zwischen Buchung und Auswertung. Und vor allem: kein Eingriff ins ERP — was nicht installiert wird, muss beim nächsten Versionssprung auch nicht migriert werden.

Worauf du dabei achten solltest:

1. Wirklich lesend. Nicht „hat keine Schreibberechtigung", sondern „hat keinen Schreibpfad". Der Unterschied entscheidet, ob eine Fehlkonfiguration im Produktivsystem etwas anrichten kann.
2. Kein Odoo-Modul. Alles, was in die Instanz installiert wird, wird beim Upgrade zur Last.
3. Zugangsdaten serverseitig. Der API-Key gehört verschlüsselt auf den Server und nie in den Browser.
4. Standort und Betriebsmodell. EU-Hosting oder die Möglichkeit, dasselbe Image selbst zu betreiben — bei Finanz- und Personaldaten ist das keine Formalie.

Offenlegung

Genau diesen Weg gehe ich mit einem eigenen Produkt: Metrilens ist ein Analytics-Dashboard für Odoo, das ich selbst entwickle. Es hängt sich lesend an eine bestehende Instanz und liefert 41 Auswertungs-Tabs, die nach Rollen geschnitten sind — CEO, CFO, COO, HR, Einkauf, Bestand, Lieferanten-Scorecard, Bedarfsplanung — statt nach Odoo-Modulen. Dazu kommt ein KI-Analyst, der auf eine Frage wie „Warum ist die Marge letzten Monat gefallen?" selbstständig in den Daten nachsieht und die Ursache erklärt, statt nur eine Kurve zu zeigen.

Ich schreibe das offen dazu, damit du diesen Abschnitt einordnen kannst. Die Kriterienliste oben gilt unabhängig davon — und sie ist auch der Maßstab, an dem du mein Produkt messen solltest.

Der Punkt, an dem die meisten scheitern

Nicht am Werkzeug. An der Datenqualität.

Buchungen ohne Kostenstelle. Kunden, die dreimal angelegt sind, weil jemand „GmbH", „G.m.b.H." und „Gmbh" getippt hat. Produkte ohne Kategorie. Leere Analysekonten. Angebote, die nie geschlossen wurden und seit zwei Jahren die Pipeline aufblähen.

Jede dieser Lücken macht eine Auswertung entweder schlicht falsch oder so erklärungsbedürftig, dass ihr niemand mehr traut. Und eine Kennzahl, der niemand traut, wird nicht mehr angeschaut — womit der ganze Aufwand verloren ist.

Deshalb gehört vor die erste Kennzahl immer eine Bestandsaufnahme der Stammdaten. Das ist die unspektakulärste Phase eines jeden Auswertungsprojekts und die, die über Erfolg oder Misserfolg entscheidet.

Wie ich vorgehen würde

1. Fragen sammeln, nicht Kennzahlen. Nicht „welche KPIs brauchen wir", sondern „welche Entscheidung triffst du regelmäßig, und welche Zahl fehlt dir dafür?" Kennzahlen ohne dahinterliegende Entscheidung werden nicht benutzt.
2. Datenqualität prüfen. Für die Felder, die in diesen Fragen vorkommen. Nicht für alles.
3. Mit Bordmitteln anfangen. Was sich als gespeicherte Pivot-Ansicht lösen lässt, braucht kein Werkzeug.
4. Erst dann ergänzen. Wenn die verbleibenden Fragen Modulgrenzen überschreiten oder rollenspezifische Sichten gebraucht werden.
5. Ein Data Warehouse zuletzt. Wenn mehrere Quellsysteme oder echte Datenmengen ins Spiel kommen.

Die Reihenfolge ist wichtig. Wer bei Schritt fünf anfängt, baut sechs Monate an etwas, das nach dem Go-Live niemand öffnet — weil die Fragen aus Schritt eins nie gestellt wurden.