Wer verantwortet Odoo im Unternehmen? Rollen im Projekt
Kurz gesagt
Für ein Odoo-Projekt brauchen Sie in Deutschland, Österreich und der Schweiz dieselben drei internen Funktionen: eine Projektleitung mit Entscheidungsbefugnis, je Fachbereich einen Key User und mindestens eine Person für die Odoo-Administration. In Odoo 20.0 ändert nur ein Administrator Rollen und Zugriffsrechte. Die Zeitbudgets in diesem Artikel sind redaktionelle Richtwerte, keine Messwerte.
Das Wichtigste
- Drei Funktionen tragen das Projekt: Projektleitung, Key User je Fachbereich und Odoo-Administration.
- Odoo 20.0 kennt intern die Rollen Benutzer, Administrator und Light, dazu Portal für Kunden und Lieferanten.
- Zugriffsrechte ändert nur ein Administrator; Gruppen und technische Rechte verlangen den Entwicklermodus.
- Die Zeitbudgets hier sind redaktionelle Richtwerte mit offengelegten Annahmen, keine Messwerte.
- Bei Odoo Online betreibt Odoo den Server; on-premise kommt die Betreuung von Server und Versionwechseln hinzu.
Ein Odoo-Projekt bringt keine Projektorganisation mit. Die Dokumentation zu Odoo 20.0 beschreibt, welche Rollen und Zugriffsrechte es in der Datenbank gibt, nicht aber, wer im Unternehmen entscheidet, schult und die Rechte pflegt. Diese Lücke besetzen Sie vor dem Start mit Namen, Befugnissen und Stunden. Der Projektplan von Analyse bis Go-live nennt je Phase einen Verantwortlichen; dieser Artikel füllt die Rollen dahinter.
Worauf es ankommt
Halten Sie die Aufgabe im Projekt und die Rolle in Odoo auseinander. Die Aufgabe beschreibt, was eine Person tut: entscheiden, Prozesse beschreiben, testen, Rechte vergeben. Die Rolle in der Datenbank legt fest, was sie darf.
Odoo 20.0 kennt intern drei Rollen: Benutzer, Administrator und Light; für Kunden und Lieferanten kommt die Rolle Portal hinzu, deren Rechte vorgegeben sind. Vergeben werden Zugriffsrechte allein aus der Rolle Administrator heraus: Ein zweiter Administrator entsteht, indem ein bestehender Administrator im Reiter Zugriffsrechte das Feld Administration auf „Access Rights“ setzt. Einzelne Gruppen und technische Rechte setzen den Entwicklermodus voraus; die Wege stehen im Artikel Benutzer und Zugriffsgruppen.
Light ist enger zugeschnitten als die Rolle Benutzer: Sie umfasst persönliche Mitarbeiterdaten, Urlaubs- und Spesenanträge, die App Planung, Kassensitzungen und Barcode-Scans im Lager. Verkauf, Einkauf, Projekte und Buchhaltung bleiben ausgeschlossen. Planung, Knowledge und Barcode führt der Editionsvergleich als Enterprise-Funktionen, in Community fehlen sie. Erhält ein Light-Benutzer darüber hinaus Rechte, stuft Odoo ihn automatisch auf die Rolle Benutzer hoch.
Für das Projekt heißt das: Administratorrechte brauchen wenige Personen, jede Funktion aber eine klare Zuordnung von Aufgabe, Rolle und Rechtestufe je App.
Die Funktionen und ihr Zeitbudget
Die Zeitbudgets dieser Tabelle sind redaktionelle Richtwerte mit frei gewählten Annahmen, keine Angaben von Odoo. Angegeben ist die Mindestrolle, die die Aufgabe verlangt.
| Funktion | Kernaufgaben | Rolle in Odoo 20.0 | Zeitbudget im Projekt (pro Woche) | Zeitbudget im Betrieb |
|---|---|---|---|---|
| Auftraggeber aus der Geschäftsführung | Umfang, Budget, Freigaben, Eskalation | Benutzer | 1 bis 2 Stunden | 1 Stunde pro Monat |
| Projektleitung | Plan, Entscheidungen, Partnersteuerung, Abnahme der Tests | Benutzer | 4 bis 8 Stunden | 1 bis 2 Stunden pro Woche in den ersten 90 Tagen |
| Key User je Fachbereich | Prozesse beschreiben, testen, Kolleginnen und Kollegen schulen, erste Anlaufstelle | Benutzer | 2 bis 4 Stunden | 1 bis 2 Stunden pro Woche |
| Odoo-Administration | Benutzer, Rollen, Gruppen, Datensatzregeln, Anmeldung, Export | Administrator | 2 bis 4 Stunden | 1 bis 3 Stunden pro Woche |
| Technische Betreuung | Testdatenbanken, Module, Server, Versionwechsel | Administrator, bei On-Premise zusätzlich Serverzugang | bei On-Premise 4 bis 8 Stunden | 1 bis 4 Stunden pro Monat, mehr vor einem Versionwechsel |
Zu jeder Funktion gehört eine Vertretung. Für die Administration bedeutet das ein zweites Konto mit der Rolle Administrator, weil eine Rechteänderung sonst die Rechteverwaltung lahmlegen kann. Die technische Betreuung können Sie intern besetzen oder mit dem Partner vereinbaren; festlegen sollten Sie, wer welche Schritte ausführt.
Ein Rechenbeispiel mit 12 Benutzern
Beispielrechnung mit erfundenen Zahlen: 12 interne Benutzer, drei Fachbereiche, 20 Projektwochen, acht Stunden je Personentag.
| Funktion | Besetzung | Stunden pro Woche | Stunden über 20 Wochen | Personentage |
|---|---|---|---|---|
| Projektleitung | 1 Person | 6 | 120 | 15,0 |
| Key User | 3 Personen zu je 3 Stunden | 9 | 180 | 22,5 |
| Odoo-Administration | 1 Person | 3 | 60 | 7,5 |
| Auftraggeber | 1 Person | 1,5 | 30 | 3,8 |
| Summe | 19,5 | 390 | 48,8 |
Über die 20 Wochen bindet das Projekt damit rund 49 Personentage im Unternehmen. Nach dem Go-live bleibt ein Rest: Projektleitung 1,5, Key User 4,5, Administration 2 und Auftraggeber 0,25 Stunden pro Woche ergeben etwa 8 Stunden pro Woche, also rund vier Personentage pro Monat. Setzen Sie Ihre eigenen Werte ein.
Was das Hostingmodell an der Rolle ändert
Bei Odoo Online hostet und verwaltet Odoo die Datenbanken, und eigene Module sowie Module aus dem Apps-Store sind dort nicht unterstützt. Die technische Betreuung beschränkt sich deshalb auf Konfiguration, Benutzer, Tests und das Herunterladen von Sicherungen.
Bei Odoo.sh kommen Web-Shell, SSH-Zugang und Continuous Integration hinzu. Wer diese Werkzeuge nutzt, sollte sie beherrschen, weil Änderungen an Branches und Modulen die Produktivdatenbank betreffen können.
Bei On-Premise gehört der Server Ihnen, bis hin zum Datenbankmanager des Servers (<odoo-server>/web/database/manager) und zu Duplikaten für Tests. Versionwechsel plant die Dokumentation mit einem Vorlauf: Eigene Module brauchen vor einem Upgrade eine Fassung für die Zielversion, und jede Hauptversion wird drei Jahre unterstützt. Ist diese Aufgabe intern nicht besetzt, gehört sie in die Vereinbarung mit dem Partner.
Typische Fehler
- Projektleitung ohne Befugnis. Wer Umfang und Termine nicht ändern darf, braucht für jede Entscheidung einen Umweg; die Wartezeit fehlt anschließend im Plan.
- Key User ohne Stundenfreigabe. Die Aufgabe bleibt liegen, und die Tests vor dem Go-live fallen aus.
- Nur ein Administrator, keine Vertretung. Die Dokumentation warnt, dass fehlerhafte Rechteänderungen die Rechteverwaltung blockieren können; dann kann der Odoo-Support den Zugang wiederherstellen.
- Administratorrechte aus Bequemlichkeit. Die Rolle reicht bis zu technischen Funktionen und Export; die Dokumentation rät vor Änderungen an Zugriffsrechten zu fachlicher Begleitung und nennt bei Mehrfirmen-Datenbanken erfahrene Benutzer.
- Light als Sparvariante geplant. Wächst die Aufgabe über den Light-Umfang hinaus, stuft Odoo 20.0 automatisch auf Benutzer hoch; weil interne Benutzer im Abonnement mitzählen, ändert sich damit die abgerechnete Benutzerzahl.
- Externe Zugänge ohne Abschluss. Ein Administratorkonto des Partners, das nach dem Go-live weiterbesteht, bleibt offen; legen Sie fest, wer es wann deaktiviert.
So gehen Sie vor
- Schreiben Sie vor der Analyse fest, wer Auftraggeber, Projektleitung, Key User und Administration ist — mit Namen und Vertretung.
- Lassen Sie je Rolle ein Wochenbudget von der Geschäftsführung freigeben; die Tabelle oben ist der Ausgangspunkt.
- Übersetzen Sie jede Funktion in Rolle und Rechtestufe je App und planen Sie die Schulung der Key User.
- Bestimmen Sie zwei Personen mit Administratorrolle und prüfen Sie mit einem Testbenutzer, welche Menüs und Datensätze sichtbar sind.
- Sichern Sie die Administratorkonten mit Zwei-Faktor-Anmeldung (Zwei-Faktor und SSO) und begrenzen Sie die Sichtbarkeit mit Datensatzregeln, wo Bereiche getrennt bleiben sollen.
- Prüfen Sie nach dem Go-live monatlich, ob die Budgets reichen, und passen Sie sie an.