Odoo-Implementierung: vom Erstaudit bis zum Go-live

Die Implementierung von Odoo besteht nicht darin, Module zu installieren und ein paar Einstellungen vorzunehmen. Es ist ein Projekt, das berührt, wie das Unternehmen fakturiert, Zahlungen einzieht, die MwSt deklariert und häufig auch die Löhne zahlt. In der Schweiz sind diese drei Themen — Buchhaltung, MwSt, Lohnbuchhaltung — durch präzise Regeln geregelt, und eine Konfiguration, die sie beim Scoping ignoriert, rächt sich beim ersten Abschluss, nicht davor. Das ist der Unterschied zwischen einem Integrator, der eine Software installiert, und einer Treuhandgesellschaft, die die Implementierung von dem her denkt, was die Buchhaltung letztlich produzieren muss.

Diese Seite beschreibt die Methode, der wir Phase für Phase folgen, vom Vorabaudit bis zum Support nach der Inbetriebnahme. Sie behandelt auch unverblümt, was ein ERP-Projekt scheitern oder entgleisen lässt: Das sind bekannte, wiederkehrende und vermeidbare Ursachen, sofern sie rechtzeitig antizipiert werden.

Wann ein Unternehmen für Odoo bereit ist — und wann noch nicht

Odoo ist sinnvoll, sobald ein Unternehmen mehrere Prozesse betreibt, die heute nicht miteinander kommunizieren: Fakturierung in einem Werkzeug, Lager auf einer Tabelle, Löhne bei einem Dritten, ohne Gesamtüberblick. Das klarste Signal ist die manuelle Doppelerfassung — dieselbe Information zwei- oder dreimal in unterschiedlichen Werkzeugen eingegeben — und das Fehlen einer Echtzeit-Sicht auf Liquidität oder Margen.

Umgekehrt zeigen bestimmte Signale, dass es besser ist zu warten oder zunächst ein vorgelagertes Problem zu lösen:

• Die aktuellen Prozesse sind nicht stabilisiert. Ändert das Unternehmen noch regelmässig seine Art zu fakturieren oder Einkäufe zu verwalten, bedeutet die Digitalisierung eines instabilen Prozesses, die Unordnung festzuschreiben.
• Es kann niemand für die fachliche Projektleitung freigestellt werden. Ohne verfügbare interne Ansprechperson werden Konfigurationsentscheidungen standardmässig getroffen, oft schlecht, und später mit höherem Aufwand korrigiert.
• Die Quelldaten befinden sich in sehr schlechtem Zustand (massive Duplikate, inkohärenter Kontenplan, keine verlässliche Historie), und niemand ist bereit, sie vor dem Projekt zu bereinigen.
• Das Unternehmen durchläuft eine grössere Reorganisation (Fusion, Rechtsformänderung, Restrukturierung), die die Prozesse in den kommenden Monaten ohnehin verändern wird.

In diesen Fällen ist es manchmal die bessere Entscheidung, das Projekt um einige Monate zu verschieben, statt es auf instabilem Terrain zu starten. Ein Vorabaudit erlaubt eine objektive Entscheidung.

Das Vorabaudit

Vor jeder Konfiguration dokumentieren wir die bestehende Situation:

• Bestehende Prozesse: wie Offerten, Bestellungen, Rechnungen, Zahlungen und Löhne heute zirkulieren, und wer bei jedem Schritt eingreift.
• Aktuelle Werkzeuge: Buchhaltungs-, Fakturierungs-, Lohnsoftware, Tabellen, und wie sie sich untereinander verzahnen — oder auch nicht.
• Daten: wo sie liegen, in welchem Format, ihr Sauberkeitsgrad (Duplikate, unvollständige Felder, Inkohärenzen im Kontenplan).
• Volumen: Anzahl Kunden, Lieferanten, Produktreferenzen, jährlicher Buchungen, Mitarbeitenden — diese Zahlen bestimmen die Komplexität der Datenübernahme und der Tests.
• Für die Tätigkeit spezifische regulatorische Vorgaben: MwSt-Pflicht (anwendbare Sätze, Abrechnungsmethode), branchenspezifische Pflichten, Gesamtarbeitsverträge, die die Lohnbuchhaltung beeinflussen.

Dieses Audit liefert ein klares Bild dessen, was besteht und was sich ändern muss — es ist die Grundlage für das folgende Scoping, keine Formalität.

Das Scoping: Umfang, Module, was verschoben wird

Das Scoping übersetzt das Audit in einen konkreten Projektumfang. In diesem Schritt entscheidet sich ein grosser Teil des späteren Erfolgs oder Misserfolgs des Projekts, da er festlegt, was beim Start funktionieren muss und was warten kann.

Den Umfang der ersten Phase festlegen

Die nützlichste Regel ist einfach zu formulieren und schwer einzuhalten: mit dem kleinstmöglichen Umfang starten, der den tatsächlichen Betriebsbedarf des Unternehmens abdeckt, nicht mit dem vollständigsten möglichen Umfang. Ein Projekt, das vom ersten Tag an Buchhaltung, MwSt, Lohnbuchhaltung, CRM, Lagerhaltung und individuelle Entwicklungen abdecken will, vervielfacht die Entscheidungspunkte, die Tests und die gleichzeitig einzubindenden Personen — und verzögert genau den Moment, in dem die finanzielle Basis verlässlich ist.

Die Module wählen

Die Modulwahl ergibt sich direkt aus dem festgelegten Umfang. Für die meisten KMU umfasst die erste Basis die Buchhaltung, die Fakturierung und den Basiseinkauf. Je nach Tätigkeit ergänzt man von Beginn an das CRM und den Vertrieb, die Lager- und Einkaufsverwaltung oder die Lohnbuchhaltung und Personalwesen — aber nur, wenn diese Bausteine für den täglichen Betrieb unverzichtbar sind, nicht weil sie im Odoo-Katalog existieren.

Was bewusst verschoben wird

Explizit zu dokumentieren, was verschoben wird, und warum, vermeidet zwei Fallstricke: den Eindruck, etwas sei vergessen worden, und die Versuchung, es dringend während des Projekts hinzuzufügen. Typischerweise auf eine spätere Phase verschoben werden: Integrationen mit unkritischen Drittsystemen, fortgeschrittene individuelle Berichte, E-Commerce- oder Projektmanagement-Module, sofern sie den Basisbetrieb nicht bedingen, sowie jede Individualisierung, die ihre Notwendigkeit noch nicht unter Beweis gestellt hat, sobald das Standardwerkzeug im Einsatz ist.

Die Konfiguration

Sobald der Umfang validiert ist, legt die Konfiguration die technischen und organisatorischen Grundlagen des Systems fest:

• Gesellschaft: Firmenname, Rechtsform, Kontaktdaten, Basiswährung, Geschäftsjahr.
• Kontenplan: Kontenstruktur, Gruppierungen, Bilanz- und Erfolgsrechnungskonten, angepasst an die tatsächliche Tätigkeit — nicht nur der Standard-Kontenplan.
• Steuerpositionen und MwSt: Zuordnung der Konten und Produkte zu den richtigen Sätzen, Verwaltung befreiter oder ausländischer Geschäfte, Abrechnungsmethode (effektiv oder Saldosteuersatz je nach Berechtigung).
• Journale: Verkauf, Einkauf, Bank, Diverses, mit korrekten Nummerierungssequenzen und Gegenkonten.
• Bankkonten: Zuordnung der realen Konten, Importformate der Kontoauszüge, Konfiguration der QR-Rechnung für den Zahlungsversand und -empfang.
• Zugriffsrechte: wer welche Art von Dokument je nach Nutzerprofil sehen, erfassen, ändern oder validieren darf.
• Freigabeprozesse: Genehmigungskreise für Lieferantenrechnungen, Spesenabrechnungen, Bestellungen, gemäss internen Schwellenwerten und Verantwortlichkeiten.

Diese Konfigurationsarbeit ist der am wenigsten sichtbare, aber entscheidendste Teil des Projekts für die Verlässlichkeit der anschliessend erzeugten Zahlen.

Die Schweizer Lokalisierung: kontrollieren und vervollständigen, nicht nur installieren

Odoo installiert automatisch das Modul für die Schweizer Lokalisierung (l10n_ch), sobald die Gesellschaft mit der Schweiz als Land konfiguriert ist. Dieses Modul legt eine nützliche Basis: eine an Schweizer Gepflogenheiten angepasste Kontenplanstruktur, gängige MwSt-Sätze (8,1 %, 2,6 % und 3,8 %, gültig seit dem 1. Januar 2024) sowie die Unterstützung der QR-Rechnung, dem Schweizer Zahlungsstandard.

Die Implementierungsarbeit endet nicht dort — sie beginnt genau an diesem Punkt. Diese generische Basis muss:

• kontrolliert werden, konto für konto, um zu prüfen, dass sie der tatsächlichen Struktur der Tätigkeit entspricht und nicht einem generischen Modell.
• angepasst werden an die effektiven Steuerpositionen: anwendbare Sätze je nach Leistung, MwSt-Abrechnungsmethode, einschliesslich der Prüfung der Berechtigung zu den Schwellenwerten der Saldosteuersatzmethode (maximaler Umsatz von CHF 5'024'000 und maximal geschuldete Steuer von CHF 108'000 pro Jahr, gültig seit dem 1. Januar 2025 gemäss ESTV).
• vervollständigt werden gemäss den Journalen, Bankkonten und tatsächlichen Flüssen des Unternehmens — die Basislokalisierung kennt weder Ihre Bankkonten noch Ihre interne Organisation.

Genau in diesem Schritt zeigt sich der Unterschied zwischen einem generalistischen Integrator und einer Treuhandgesellschaft: eine technisch installierte, aber inhaltlich nicht kontrollierte Lokalisierung liefert Zahlen, die bis zum ersten MwSt-Abschluss korrekt erscheinen, wo dann die Abweichungen sichtbar werden. Für alles rund um die laufende Buchführung nach der Systemeinführung siehe unsere Seite Odoo Buchhaltung.

Die Datenübernahme

Die Datenübernahme beantwortet drei getrennte Fragen, die separat entschieden werden müssen.

Was übernommen wird

In der Regel: die aktiven Kunden- und Lieferantenstammdaten, der Produktkatalog, die offenen Rechnungen (noch nicht eingezogen oder bezahlt), die Eröffnungssaldi zum Umstellungsdatum sowie die für die unmittelbare operative Kontinuität notwendigen Daten (aktueller Lagerbestand, laufende Verträge).

Was nicht systematisch übernommen wird

Die detaillierte Buchhaltungshistorie abgeschlossener Geschäftsjahre muss in der Regel nicht Buchung für Buchung in Odoo nachvollzogen werden. Sie bleibt im alten System zugänglich oder wird im PDF-Format archiviert, was den gesetzlichen Aufbewahrungspflichten genügt, ohne die Migration zu belasten. Ebenso werden seit langem inaktive Kunden- oder Lieferantenstammdaten oder Daten mit zweifelhafter Verlässlichkeit oft bewusst weggelassen statt «vorsorglich» migriert.

Das Umstellungsdatum

Es wird gemäss dem Buchhaltungskalender des Unternehmens gewählt — meist zu Beginn eines Geschäftsjahres oder einer MwSt-Periode, um zu vermeiden, dass eine Periode auf zwei verschiedene Systeme aufgeteilt wird. Die Eröffnungssaldi zu diesem Datum werden mit Sorgfalt erstellt: Sie gewährleisten die buchhalterische Kontinuität zwischen dem alten System und Odoo. Für ein Projekt, bei dem das Quellsystem bereits identifiziert und dokumentiert ist, siehe unsere Seite zur Datenmigration.

Entwicklungen und Integrationen, falls nötig

Odoo Standard deckt den Grossteil des Bedarfs eines KMU ab. Eine individuelle Entwicklung oder eine Integration mit einem Drittsystem (E-Commerce-Shop, Kasse, branchenspezifische Fachsoftware) rechtfertigt sich nur, wenn der Standard den Bedarf wirklich nicht erfüllt — nicht aus Prinzip. Jede Entwicklung fügt eine Abhängigkeit hinzu, die bei künftigen Versionsupgrades gewartet werden muss; wir dokumentieren systematisch, was massgeschneidert entwickelt wurde und warum, damit diese Entscheidung über die Zeit nachvollziehbar bleibt.

Aus methodischer Vorsicht wird jede Entwicklung, die für den Betrieb der ersten Phase nicht streng unverzichtbar ist, verschoben: eine vorschnelle Individualisierung, die entschieden wird, bevor die Teams das Standardsystem genutzt haben, stützt sich oft auf eine Gewohnheit des alten Werkzeugs statt auf einen tatsächlichen Bedarf in Odoo.

Die Tests und die Abnahme

Die Abnahme validiert, dass das konfigurierte System korrekte Ergebnisse liefert, bevor das Unternehmen seine realen Vorgänge darauf umstellt.

• Testdaten: repräsentative Daten, auf Basis realer Fälle des Unternehmens erstellt, keine generischen Daten.
• Geschäftsszenarien: vollständige Abläufe — von der Bestellung bis zum Zahlungseingang, vom Eingang einer Lieferantenrechnung bis zu ihrer Zahlung, von der Lohnberechnung bis zur Lohnabrechnung — von Anfang bis Ende getestet, nicht isoliert Funktion für Funktion.
• Buchhalterische Validierung: Kontrolle der Bilanzen, der Bankabstimmungen und einer simulierten MwSt-Abrechnung vor der endgültigen Umstellung. Das ist die wertvollste Kontrolle, denn sie deckt eine falsch eingestellte Steuer- oder Buchhaltungskonfiguration auf, bevor sie eine offizielle Zahl erzeugt.

Die Abnahme wird mit den Nutzern durchgeführt, die das System tatsächlich täglich verwenden werden, nicht nur mit der Projektansprechperson — sie sind es, die Abweichungen zwischen der theoretischen Konfiguration und der tatsächlichen Nutzung erkennen.

Die Schulung der Nutzer, nach Profil

Eine für alle identische, generische Schulung lässt jeden mit den ihn nicht betreffenden Funktionen allein und vernachlässigt jene, die er tatsächlich braucht. Die Schulung wird daher nach Profil aufgebaut:

• Buchhaltung und Finanzen: Erfassung, Zuordnung, Bankabstimmung, periodischer Abschluss, MwSt-Abrechnung.
• Verkauf und Fakturierung: Offerten, Bestellungen, Fakturierung, Zahlungsverfolgung.
• Einkauf und Lager, sofern dieser Umfang gewählt wurde: Lieferantenbestellungen, Wareneingänge, Inventur.
• Personalwesen, sofern die Lohnbuchhaltung im Umfang enthalten ist: Verwaltung der Personalakten, Lohnzyklus, Sozialabrechnungen.
• Geschäftsleitung: Lesen von Dashboards und Kennzahlen, nicht zwingend die operative Erfassung.

Die Schulung zu vernachlässigen ist eine ebenso häufige Ursache für ein Scheitern wie eine schlechte technische Konfiguration: ein gut konfiguriertes, aber schlecht verstandenes System erzeugt Erfassungsfehler, die ihrerseits falsche Zahlen liefern. Details zu unserem Schulungsansatz finden Sie auf der Seite Odoo-Schulung.

Der Go-live und die Stabilisierungsphase

Der Go-live ist der Moment, in dem das Unternehmen seinen Betrieb endgültig auf Odoo umstellt. Ihm geht eine Erfassungssperre im alten System voraus, um die Datenübernahme abzuschliessen, gefolgt von einer Stabilisierungsphase, in der die ersten realen Zyklen — erste Fakturierung, erste Bankabstimmung, erster MwSt-Abschluss — Abweichungen zutage bringen, die keine noch so sorgfältige Abnahme vollständig im Voraus erkennt. Diese Phase wird als Projektphase geplant, mit verstärkter Begleitung, und nicht als Abfolge unvorhergesehener Störfälle behandelt.

Der Support und die kontinuierliche Verbesserung

Nach der Stabilisierungsphase wechselt das Unternehmen in den laufenden Support: Nutzungsfragen, kleinere Konfigurationskorrekturen, Begleitung der periodischen Abschlüsse, punktuelle Weiterentwicklungen je nach festgestelltem Bedarf. Das ist auch der Moment, in dem die beim ersten Scoping bewusst verschobenen Module und Funktionen neu bewertet und auf einer nun stabilen Basis hinzugefügt werden können. Siehe unser Odoo-Supportangebot für die Details dieser kontinuierlichen Begleitung.

Was die Dauer und das Budget eines Projekts beeinflusst

Wir nennen keine generische Dauer- oder Kostenspanne: Sie würde auf Annahmen beruhen, die wir zum Zeitpunkt des Verfassens dieser Seite noch nicht kennen. Die Faktoren jedoch, die ein Odoo-Implementierungsprojekt nach oben oder unten beeinflussen, sind identifizierbar:

• Der gewählte Umfang: Anzahl der in der ersten Phase aktivierten Module, Anzahl der zu konfigurierenden Gesellschaften oder Rechtseinheiten.
• Der Zustand der Quelldaten: saubere und strukturierte Daten werden schnell übernommen; verstreute, inkohärente oder duplizierte Daten erfordern eine vorgelagerte Bereinigungsarbeit, die schwerer wiegen kann als die Konfiguration selbst.
• Die Verfügbarkeit der internen Ansprechperson: Ein Projekt, in dem Entscheidungen schnell getroffen werden, schreitet regelmässig voran; ein Projekt, in dem jede Validierung mehrere Wochen wartet, zieht sich entsprechend in die Länge.
• Der Umfang individueller Entwicklungen: Jede Individualisierung fügt einen Spezifikations-, Entwicklungs- und Testzyklus hinzu, der zur Standardkonfiguration hinzukommt.
• Die regulatorische Komplexität der Tätigkeit: mehrere MwSt-Sätze, internationale Tätigkeit, spezifische Gesamtarbeitsverträge für die Lohnbuchhaltung, mehrere Gesellschaften — jeder dieser Punkte fügt zu konfigurierende und zu testende Fälle hinzu.
• Die gewählte Edition, Community oder Enterprise: Diese Wahl beeinflusst sowohl die von Anfang an verfügbaren Funktionen als auch das wiederkehrende Kostenmodell pro Nutzer.
• Die installierte Odoo-Version: Odoo 19 ist die aktuelle stabile Version; eine aktuelle Version profitiert von einem längeren Herstellersupport, was erzwungene Versionsupgrades kurzfristig einschränkt.

Genau um diese Faktoren für Ihre reale Situation abzuwägen, und nicht für einen generischen Fall, beginnt das Projekt mit einem dokumentierten Audit und Scoping — nicht mit einer Offerte, die erstellt wird, bevor Ihre Prozesse gesehen wurden. Wenn Ihr Unternehmen in Genf oder der Region ansässig ist, siehe auch unsere Odoo-Begleitung in Genf.