Der Satz, der uns in ERP-Projekten am meisten Sorgen macht, lautet nicht: Die Software hat einen Fehler. Er lautet: Die Kollegen machen es einfach in Excel weiter. Wenn das ein halbes Jahr nach dem Start passiert, ist das Projekt gescheitert, egal wie gut das System konfiguriert wurde. Und es passiert erstaunlich oft, weil Change Management in den meisten ERP-Projekten als Punkt auf einer Folie vorkommt, aber nicht als Arbeit im Kalender.
In diesem Beitrag zeigen wir dir, was Change Management bei einer ERP-Einführung konkret bedeutet, warum Widerstand aus dem Team eine wertvolle Information ist und welche Schritte in unseren Odoo-Projekten den Unterschied zwischen einem System machen, das genutzt wird, und einem, das nur Lizenzen kostet.
Warum Menschen ein neues System ablehnen
Die naheliegende Erklärung lautet Gewohnheit. Sie stimmt, aber sie greift zu kurz. In unserer Erfahrung haben Mitarbeitende, die ein neues ERP ablehnen, fast immer einen konkreten Grund, den niemand gefragt hat.
Die Sachbearbeiterin, die seit zwölf Jahren die Angebote schreibt, hat in ihrer Excel-Tabelle Sonderfälle abgebildet, von denen die Projektleitung nichts weiß. Der Lagerleiter befürchtet, dass ein System, das jede Bewegung dokumentiert, seine Fehler sichtbar macht. Der Vertriebler hat schon zwei Softwareeinführungen erlebt, die nach einem Jahr wieder eingestampft wurden, und spart sich die Energie. Keiner davon ist ein Blockierer. Jeder davon hat eine Information, die das Projekt braucht.
Widerstand ist Information
Deshalb der wichtigste Grundsatz: Wer bremst, wird nicht überredet, sondern befragt. In den Prozess-Workshops, mit denen wir jede Odoo-Einführung beginnen, sitzen deshalb nicht nur Geschäftsführung und Abteilungsleitung, sondern die Menschen, die die Vorgänge täglich bearbeiten. Und die erste Frage an sie lautet nicht, was das neue System können soll, sondern was am heutigen Ablauf gut funktioniert und was nervt.
Aus diesen Antworten entstehen zwei Listen. Die eine enthält Sonderfälle und Abläufe, die das neue System abbilden muss, sonst arbeiten die Betroffenen daran vorbei. Die andere enthält alte Umwege, die mit dem neuen System verschwinden können. Beide Listen sind wertvoller als jedes Pflichtenheft, das ohne die Anwender geschrieben wurde. Wie die Phasen einer Einführung insgesamt aussehen, haben wir im Beitrag ERP einführen ohne Chaos beschrieben.
Die sechs Schritte, die in unseren Projekten den Unterschied machen
1. Das Warum erklären, bevor das Was kommt
Bevor irgendjemand eine Oberfläche sieht, muss klar sein, welches Problem das Projekt löst. Nicht abstrakt, sondern konkret: Heute werden Kundenadressen an drei Stellen gepflegt, und niemand weiß, welche stimmt. Heute dauert die Monatsauswertung zwei Tage. Wer das Problem sieht, versteht die Lösung. Wer nur die Lösung sieht, sieht zusätzliche Arbeit.
2. Schlüsselpersonen früh einbinden
In jeder Abteilung gibt es eine Person, auf die andere hören. Nicht unbedingt die Führungskraft, oft die erfahrenste Sachbearbeiterin oder der Kollege, der bei Fragen immer weiterhilft. Diese Menschen gehören von Anfang an ins Projekt, als Testende, als Ansprechpartner, als Stimme ihrer Abteilung. Wenn sie das System tragen, trägt es die Abteilung. Wenn sie es ablehnen, hilft keine Schulung.
3. Mit dem Bereich beginnen, in dem der Schmerz am größten ist
Ein modularer Start, wie ihn Odoo ermöglicht, ist nicht nur technisch sinnvoll, sondern auch psychologisch. Wenn der erste Schritt den Bereich verbessert, unter dem alle am meisten gelitten haben, entsteht ein Erfolg, den das Team spürt. Das ist die beste Werbung für den zweiten Schritt. Wer dagegen mit dem Bereich beginnt, der schon gut lief, erzeugt nur Aufwand ohne sichtbaren Nutzen.
4. Schulung an echten Vorgängen, nicht an Beispieldaten
Eine Schulung mit Musterfirma und Beispielkunden bleibt abstrakt. Wir schulen an den echten Angeboten, echten Artikeln und echten Kunden der Teilnehmenden, weil dann sofort die Frage aufkommt, wie der konkrete Sonderfall von letzter Woche abgebildet wird. Genau diese Fragen müssen vor dem Start beantwortet werden, nicht danach.
5. Den Produktivitätsknick ankündigen
Nach dem Start wird es erst langsamer. Routineaufgaben dauern das Doppelte, weil Wege neu gelernt werden. Das ist normal und dauert je nach Umfang einige Wochen. Wer das vorher sagt, nimmt der Phase den Schrecken. Wer es verschweigt, erlebt nach zwei Wochen den Satz vom Excel. Was in dieser Phase noch schiefgehen kann, steht in unserem Beitrag Die Nachteile von ERP-Systemen.
6. Jemanden zuständig machen, dauerhaft
Change Management endet nicht mit dem Start. Ein ERP braucht eine Person im Unternehmen, die Fragen beantwortet, Rückmeldungen sammelt, kleine Anpassungen anstößt und neue Kolleginnen einarbeitet. Nicht als Vollzeitstelle, aber mit echter Zeit im Kalender. Ohne diese Rolle wandert die Arbeit binnen eines Jahres zurück in Tabellen und E-Mails.
Was die Geschäftsführung tun muss
Change Management lässt sich nicht delegieren. Wenn die Geschäftsführung das Projekt startet und dann verschwindet, lesen Mitarbeitende das als Signal, dass es nicht wichtig ist. Was hilft: sichtbar selbst mit dem System arbeiten, in den ersten Wochen regelmäßig nachfragen, was hakt, und bei Konflikten zwischen alten und neuen Abläufen eine Entscheidung treffen statt beide parallel laufen zu lassen. Der Parallelbetrieb ist der sicherste Weg, ein ERP-Projekt scheitern zu lassen, weil er den Weg zurück offenhält.
Was das mit Odoo zu tun hat
Wir setzen Odoo ein, weil es modular ist, weil die Oberfläche für ein ERP ungewöhnlich zugänglich ist und weil sich Sonderfälle ohne Eingriff in den Kern abbilden lassen. Alle drei Punkte sind für die Akzeptanz im Team direkt relevant: Ein modularer Start erzeugt frühe Erfolge, eine verständliche Oberfläche senkt die Hürde, und abbildbare Sonderfälle nehmen den Betroffenen die Angst, dass ihre Arbeit nicht mehr passt. Mehr zu unserem Vorgehen findest du auf der Seite zur Odoo Implementierung.
Fazit
Ein ERP scheitert selten an der Software und häufig an den Menschen, die damit arbeiten sollen und nicht gefragt wurden. Change Management heißt: das Warum erklären, Widerstand als Information nehmen, Schlüsselpersonen einbinden, mit dem größten Schmerz beginnen, an echten Vorgängen schulen, den Knick ankündigen und jemanden dauerhaft zuständig machen. Nichts davon ist Software, alles davon entscheidet über den Erfolg. Wenn ihr vor einer Einführung steht und das Team mitnehmen wollt, sprecht uns an.