Akzeptanz im Odoo-Projekt: Change-Management

Nach dem Go-live zeigt sich, ob die Vorgänge in Odoo entstehen oder daneben. Ob das so ist, müssen Sie nicht aus Gesprächen schließen: Die Dokumentation 20.0 beschreibt in den Apps Berichte, mit denen sich Vorgänge nach Person, Zeitraum und Bereich gruppieren lassen. Dieser Artikel nennt diese Wege, dazu eine Checkliste und Beispielrechnungen. Die Zielwerte sind Annahmen der Redaktion, keine Vorgaben von Odoo.

Worauf es bei der Akzeptanz ankommt

Akzeptanz zeigt sich im Arbeitsalltag: Ein Vorgang landet nur dann in Odoo, wenn die Person, die ihn bearbeitet, einen Grund hat, ihn dort anzulegen.

Erfahrungswert der Redaktion aus der Begleitung von Einführungen, nicht gemessen: Vier Bedingungen tragen die Nutzung. Die Rolle muss den Vorgang anlegen dürfen; Zugriffsrechte ändert nur ein Administrator. Die Schulung muss den eigenen Fall zeigen, in den Formaten aus Odoo-Schulung planen. Eine Rückmeldung zu Fehlern und Wünschen muss ankommen. Und die Kennzahl gehört in das Gespräch mit dem Team, nicht in eine Kontrolle.

Eine Nachschulung nach dem Go-live gehört dazu: Die Fragen entstehen im Betrieb. Die Vorbereitung steht unter Key User schulen und in den ersten 90 Tagen.

Kennzahlen, die Nutzung belegen

Die Wege unten sind die englischen Menünamen der Dokumentation 20.0; in der deutschen Oberfläche können sie abweichen. Die Spalte Edition nennt die Edition, die den Bericht bereitstellt; die farbige Zeiterfassungs-Rasteransicht gibt es laut Editionsvergleich nur in Enterprise. Die Spalte Zielwert nennt je Zeile eine Annahme der Redaktion. Wer einen Vorgang nicht anlegen darf, kann ihn nicht liefern.

Kennzahl	Menüweg (Dokumentation 20.0)	Filter und Gruppierung	Edition	Zielwert (Annahme der Redaktion)
Vorgänge je verkaufende Person	Sales app ‣ Reporting ‣ Sales (Sales Analysis)	Group By Salesperson, Measure Count, Filter Order Date	Community und Enterprise	jede Person mit Verkaufsaufgabe erzeugt in der Woche mindestens einen Vorgang
Offene Chancen je Person	CRM app ‣ Reporting ‣ Pipeline (Pipeline Analysis)	Pivot view, Gruppierung nach Salesperson	Community und Enterprise	keine offene Chance ohne geplante Aktivität
Bestellungen je Person an der Kasse	POS-Karte ‣ ⋮ ‣ View ‣ Sessions ‣ Sitzung ‣ Orders (Spalte Employee)	Ansicht je Session, Filter Date	Community und Enterprise	jede Schicht ist einer Person zugeordnet; setzt die Einstellung Log in with Employees voraus
Erfasste Zeiten je Person	Timesheets, Ansicht My Timesheets (Rasteransicht)	Vergleich mit den Working Hours: Tages- und Periodensummen (grün genau, braun oder orange darüber, rot darunter)	nur Enterprise	zum Wochenende keine rote Zelle ohne Erklärung
Lagerbewegungen	Inventory app ‣ Reporting ‣ Moves Analysis oder Moves History	Filter Date, Group By Operation Type	Community und Enterprise	jede Ein- und Auslagerung im System, nicht auf Papier
Bestellungen je Einkäufer	Purchase app ‣ Reporting ‣ Purchase (Purchase Analysis)	Pivot view, Group By Buyer, Measure Count	Community und Enterprise	jede Bestellung im System statt per E-Mail
Fällige Aktivitäten je App	Aktivitätsansicht der App (Uhr-Symbol rechts oben in der Menüleiste)	Spalten je Aktivitätstyp, Fälligkeit als Farbe (grün künftig, orange heute, rot überfällig)	Community und Enterprise	zum Wochenende keine überfällige Aktivität in Verkauf und Einkauf

Zwei Zeilen haben Voraussetzungen. Erfasste Zeiten verlangen, dass die Person als Mitarbeitende geführt ist, das Projekt die Zeiterfassung zulässt und die Datenbank auf Enterprise läuft. Die Lagerberichte sind laut Dokumentation 20.0 nur mit Administratorzugriff erreichbar. Point of Sale ‣ Reporting ‣ Orders öffnet die statistische Auswertung in Graph- oder Pivot-Ansicht; die Spalte Employee steht erst im Sitzungsbericht. Die gebündelten Zähler einer App listet das Aktivitäten-Menü über das Uhr-Symbol in der Kopfzeile, gegliedert nach Late, Today und Future. Wer geändert hat, wann und auf welchen Wert, steht im Chatter des Datensatzes; für die Auswertung über mehrere Datensätze siehe Protokolle in Odoo.

So sieht das im Alltag aus

Beispielrechnung mit erfundenen Zahlen: Ein Betrieb mit zwölf Nutzenden, davon vier im Verkauf. In Woche 4 zeigt die Verkaufsanalyse (Sales app ‣ Reporting ‣ Sales) mit Filter Order Date, Group By Salesperson und Measure Count 46 Vorgänge, verteilt auf drei der vier Personen: 0, 12, 14 und 20. Der Zielwert von vier Personen ist nicht erreicht, obwohl 46 ÷ 4 = 11,5 je Kopf unauffällig wäre.

Die Null bei der vierten Person lässt sich aus dem Bericht nicht erklären: Möglich ist, dass sie in dieser Woche keinen Verkaufsvorgang hatte, dass sie keinen anlegen darf oder dass sie ihn woanders anlegt, etwa in einer Tabelle. In der Kennzahl sehen diese Fälle gleich aus, deshalb gehört die Frage in das Gespräch.

Ein zweites Beispiel aus dem Handel: 320 Bestellungen in fünf Kassenschichten ergeben 64 je Schicht. Stehen im Sitzungsbericht (POS-Karte ‣ ⋮ ‣ View ‣ Sessions ‣ Sitzung ‣ Orders) alle 320 ohne Zuordnung in der Spalte Employee, prüfen Sie die Einstellung Log in with Employees (Point of Sale ‣ Configuration ‣ Settings, Bereich PoS Interface); sie steuert die Anmeldung der Mitarbeitenden an der Kasse.

Typische Fehler

• Nach Anmeldungen zählen. Anmeldeinformationen und Geräte stehen laut Dokumentation 20.0 im Profil des Nutzers (My Preferences ‣ Security) und belegen Zugriff, nicht Arbeit.
• Kennzahl ohne Zielwert und Termin. Ohne Bezugswert sagen 46 Vorgänge nichts; ohne Termin fehlt der Anlass, die Zahl anzusehen.
• Kennzahl als Kontrolle verwenden. Wirkt die Zahl als Vorhaltung, entstehen Einträge für die Zahl statt für den Vorgang (redaktionelle Einschätzung).
• Parallel erfassen. Ein Vorgang, der ausschließlich außerhalb Odoos erfasst wird, fehlt in der Kennzahl: Count zählt laut Dokumentation 20.0 die gefilterten Datensätze. Eine Tabelle oder ein Formular neben einem Vorgang, der in Odoo steht, senkt die Zahl dagegen nicht.
• Rechte vergessen. Wer den Vorgang nicht anlegen darf, kann die Kennzahl nicht erfüllen; die Zugriffsrechte ändert nur ein Administrator.
• Nach dem Go-live nichts wiederholen. Die Fragen entstehen im Betrieb; ohne zweiten Termin bleiben sie unbeantwortet.

Die Akzeptanz-Checkliste

Jeder Schritt unten hat eine Kennzahl, an der Sie ihn prüfen; die Produktwege stehen in der Tabelle oben.

1. Bestimmen Sie je Bereich die Kennzahl aus der Tabelle und einen Zielwert, den das Team kennt.
2. Bauen Sie die Ansicht: Filter, Group By, dann im Suchfeld Save current search, bei Bedarf mit Default filter; die Pivot-Tabelle laden Sie bei Bedarf als xlsx herunter.
3. Benennen Sie je Bereich eine Person, die wöchentlich prüft; die Rollen stehen unter interne Verantwortung.
4. Prüfen Sie vor dem ersten Termin die Rechte: Anlegen darf nur, wer die passende Gruppe hat (Benutzer und Zugriffsgruppen).
5. Setzen Sie einen festen, kurzen Termin je Woche, beginnend in der ersten Woche nach dem Go-live.
6. Halten Sie die Zahl der ersten Woche fest und vergleichen Sie Wochen, nicht Tage.
7. Legen Sie Parallelwege still: Ein Vorgang, der ausschließlich außerhalb Odoos erfasst wird, erscheint in der Kennzahl nicht, weil Count die gefilterten Datensätze zählt (Dokumentation 20.0); eine Tabelle neben einem in Odoo erfassten Vorgang ändert die Zahl nicht.
8. Klären Sie jede Abweichung in dieser Reihenfolge: Recht, Schulung, Ablauf, zuletzt die Person; Ursachen und Gegenmittel ordnet Warum Odoo-Projekte scheitern den Projektphasen zu.
9. Prüfen Sie nach vier Wochen, ob die Kennzahl noch trägt; eigene Auswertungen auf Buchungszeilen bauen Sie nur in Enterprise im Entwicklermodus (Accounting ‣ Configuration ‣ Accounting Reports, Menüpunkt über Create Menu Item).

Kennzahlen für die Geschäftsführung bündelt Management-Berichte aus Odoo, eigene Tabellen Dashboards in Odoo.