ERP-Projekte scheitern selten an der Software. Sie scheitern daran, dass niemand vorher aufgeschrieben hat, was das System eigentlich können soll, und dass die Menschen, die später damit arbeiten, erst am Tag der Umstellung davon erfahren.
In diesem Beitrag zeigen wir dir, wie eine ERP-Einführung abläuft, die funktioniert: von der Aufnahme der Prozesse über die Anforderungsliste bis zum Start im laufenden Betrieb. Dazu die Fehler, die uns in Projekten immer wieder begegnen, und was sie kosten.
Phase 1: Verstehen, wie ihr heute arbeitet
Am Anfang steht nicht die Software, sondern eine unbequeme Bestandsaufnahme. Wir gehen mit den Beteiligten die zentralen Abläufe durch: Wie entsteht ein Angebot? Was passiert, wenn eine Bestellung eingeht? Wer pflegt Lagerbestände? Wie kommen die Daten zum Steuerberater?
Dabei kommt regelmäßig heraus, dass es für denselben Vorgang drei verschiedene Wege gibt, je nachdem wer gerade zuständig ist. Das ist normal und genau der Punkt: Ein ERP zwingt zu einer Entscheidung, welcher Weg der richtige ist. Wer diese Klärung ins System verschiebt, bezahlt sie später als Anpassungsaufwand.
Halte in dieser Phase auch fest, wo heute Doppelarbeit entsteht. Jede Stelle, an der jemand Daten von einem System ins andere überträgt, ist ein konkreter Gewinn, den du später gegen die Projektkosten rechnen kannst.
Phase 2: Anforderungen aufschreiben, nach Priorität
Jetzt entsteht die Liste dessen, was das System können muss. Wichtig ist die Einteilung in drei Kategorien, denn ohne sie wird jede Anforderung gleich wichtig und das Projekt unbezahlbar.
- Pflicht: Ohne das geht der Betrieb nicht. Rechnungen nach deutschem Recht, DATEV-Export, Chargenverfolgung, was auch immer bei euch gilt.
- Wichtig: Bringt spürbaren Nutzen, ist aber nicht existenziell. Kann in Stufe zwei kommen.
- Wunsch: Wäre schön. Wird zuerst gestrichen, wenn Budget oder Zeit knapp werden.
Formuliere Anforderungen als Aufgabe, nicht als Funktion. Also nicht „Dashboard mit Kennzahlen“, sondern „Der Vertrieb muss morgens sehen, welche Angebote seit zehn Tagen offen sind“. Der Unterschied klingt akademisch, verhindert aber, dass ihr Funktionen kauft, die niemand nutzt.
Und benenne ausdrücklich, was das System nicht leisten muss. Diese Liste spart im Auswahlprozess mehr Zeit als jede andere.
Phase 3: System und Partner auswählen
Erst jetzt kommt die Software ins Spiel. Lass dir keine Standardpräsentation zeigen, sondern gib zwei oder drei eurer echten Vorgänge vor und lass sie im System durchspielen. Der Unterschied zwischen Hochglanzdemo und eurem Alltag wird dabei sehr schnell sichtbar.
Mindestens genauso wichtig wie das System ist der Partner. Frag konkret: Wer betreut uns nach dem Start? Was passiert bei einem Versionswechsel? Wie werden Anpassungen umgesetzt, damit sie ein Update überstehen? Gerade bei Odoo entscheidet die Qualität der Umsetzung darüber, ob spätere Versionssprünge günstig oder schmerzhaft werden. Warum wir dabei auf saubere, updatefeste Module setzen, erklären wir auf der Seite zur Odoo Implementierung.
Phase 4: Daten vorbereiten
Der Teil, den alle unterschätzen. Stammdaten aus gewachsenen Systemen sind fast nie sauber: doppelte Kunden, veraltete Artikel, uneinheitliche Schreibweisen, Bestände, die nicht stimmen.
Wer diesen Zustand ins neue System überträgt, hat danach dasselbe Chaos in schöner Oberfläche. Nutz die Migration deshalb zum Aufräumen. Und entscheide bewusst, wie viel Historie du wirklich brauchst. In vielen Projekten reichen offene Vorgänge plus zwei Jahre Rückblick, alles Ältere bleibt im Altsystem archiviert. Das spart erheblichen Aufwand.
Phase 5: Testen mit echten Vorgängen
Testen heißt nicht, dass die Projektleitung einmal durchklickt. Testen heißt, dass die Menschen, die später täglich damit arbeiten, ihre echten Vorgänge im neuen System abwickeln, parallel zum Altsystem.
Hier kommen die Erkenntnisse, die keine Anforderungsliste liefert: dass ein Feld an der falschen Stelle steht, dass ein Ablauf drei Klicks zu lang ist, dass ein Sonderfall vergessen wurde. Plan dafür genug Zeit ein, mindestens zwei bis vier Wochen, und nimm die Rückmeldungen ernst. Widerstand aus dem Team ist in dieser Phase wertvoll, nicht lästig.
Phase 6: Start und die Wochen danach
Für den Umstieg gibt es zwei Wege. Der Stichtagswechsel schaltet alles auf einmal um, ist sauber und riskant. Der stufenweise Start beginnt mit einem Bereich, etwa Verkauf und CRM, und ergänzt später. Bei mittelständischen Betrieben empfehlen wir fast immer den zweiten Weg, weil das Team Erfolge sieht, bevor die Komplexität steigt.
Wähle einen ruhigen Zeitpunkt im Geschäftsjahr, nicht das Quartalsende. Rechne mit einem Produktivitätsknick von einigen Wochen, das ist normal und kein Zeichen für ein gescheitertes Projekt. Und sorge dafür, dass in den ersten Tagen jemand erreichbar ist, der Fragen sofort beantwortet.
Die fünf teuersten Fehler
- Alle Module gleichzeitig einführen. Die Organisation kann nur eine begrenzte Menge Veränderung auf einmal verarbeiten.
- Das Team erst am Ende einbeziehen. Wer nicht mitentschieden hat, arbeitet gegen das System oder daran vorbei.
- Schlechte Prozesse eins zu eins nachbauen. Wenn ein Ablauf nur historisch gewachsen ist, bau ihn nicht teuer nach, sondern ändere ihn.
- Anpassungen ohne Rücksicht auf Updates. Was tief in den Kern eingreift, macht jeden Versionswechsel zum Projekt.
- Nach dem Start niemanden mehr zuständig machen. Ein ERP braucht Pflege, sonst wandert die Arbeit binnen eines Jahres zurück in Excel.
Fazit
Eine ERP-Einführung ist zu achtzig Prozent Organisationsarbeit und zu zwanzig Prozent Software. Nimm dir Zeit für Prozesse und Anforderungen, priorisiere ehrlich, räum die Daten auf, lass die Anwender mit echten Vorgängen testen und starte lieber stufenweise. Welches System dabei passt und wo Odoo seine Stärken hat, haben wir im Beitrag Open Source ERP im Vergleich beschrieben. Wenn ihr vor der Entscheidung steht, sprecht uns an.