kurz gesagt
- ERP-Einführungen scheitern selten an der Technologie. Sie scheitern, wenn die Menschen, die das System täglich nutzen sollen, nie gefragt wurden.
- Stille Sabotage ist kein Widerstand, sondern ein Signal. Sie zeigt an, dass ein Prozess die Betroffenen als Objekte behandelt hat, nicht als Beteiligte.
- Zuhören ist ein strategisches Werkzeug. Zwanzig narrative Interviews ohne Agenda fördern zutage, was kein Fragebogen je liefern würde.
Das ERP-System war gut. Die Beratung war renommiert. Der Zeitplan war eingehalten worden. Und trotzdem: Am Launch-Day wusste jeder, der hinschaute, dass das Projekt nicht gelandet war. Die Mitarbeitenden nutzten das neue System formal, fanden aber bei jeder Gelegenheit einen Weg drumherum. Was auf den ersten Blick wie technischer Widerstand aussah, war in Wahrheit ein Muster, das ich seitdem in vielen Unternehmen wiedererkenne.
Wenn Change-Müdigkeit kein Zufall ist
Change-Müdigkeit ist kein Persönlichkeitsmerkmal. Sie ist eine direkte Reaktion auf einen Prozess, der die Betroffenen nicht als Akteure behandelt hat, sondern als Empfänger von Entscheidungen. Wer ein System einführt, ohne vorher zu fragen, wie der betroffene Ablauf heute wirklich läuft und was die Menschen darin täglich beschäftigt, bekommt Compliance, aber kein Commitment.
Im beschriebenen Fall hatten 400 Mitarbeitende monatelang zugesehen, wie das Projekt von oben geplant wurde. Niemand hatte sie gefragt. Die Folge war keine Revolte, sondern etwas Schwierigeres: kollektive Gleichgültigkeit gegenüber einem System, das ihre Arbeit eigentlich erleichtern sollte.
Zuhören als erste Maßnahme
Der erste Schritt zur Wende war ungewohnt simpel: aufhören, Lösungen zu präsentieren. Stattdessen wurden zwanzig narrative Interviews geführt, quer durch alle Hierarchieebenen, ohne Agenda, ohne Beamer, ohne vorbereitete Antwortoptionen. Eine einzige Frage stand im Mittelpunkt: Was ist passiert, und wie hat sich das für dich angefühlt?
Was dabei zum Vorschein kam, war keine Liste von Beschwerden. Es war ein Bild: Wo der Prozess tatsächlich läuft, wo er stockt, was die Menschen täglich frustriert, und was sie sich wünschen würden, wenn jemand fragt. Dieses Bild hätte kein Fragebogen geliefert. Skalen messen, was man zu erfragen weiß. Narrative fördern zutage, was man noch nicht zu fragen wusste.
Was die Interviews zeigten
Drei Themen kamen in fast allen Gesprächen vor. Erstens: Die Mitarbeitenden hatten vor dem Go-live gewusst, dass bestimmte Schnittstellen nicht funktionieren würden. Niemand hatte sie gefragt. Zweitens: Die Schulungen hatten das neue System erklärt, aber nicht erklärt, warum bestimmte alte Abläufe aufgehört hatten zu gelten. Drittens: Es gab nach dem Launch keine Anlaufstelle für Probleme, die jemand ernsthaft aufnahm.
Keines dieser drei Themen war in der offiziellen Projektkommunikation aufgetaucht. Alle drei hatten das Team dazu gebracht, das System zu umgehen. Die Lösung war in keinem Fall technisch. Sie war organisatorisch.
Wie sich das auf andere Mittelstands-Projekte übertragen lässt
- Narratives Gespräch vor dem Rollout. Einige Gespräche, quer durch Hierarchieebenen und Abteilungen, ohne strukturierten Fragebogen. Die Frage ist offen: Wie läuft es heute, und was beschäftigt dich dabei?
- Die Ergebnisse gemeinsam lesen, nicht als Problembericht, sondern als Systembild. Was zeigt sich als Muster? Was hätte das Projekt verändern können?
- Einwände in die Lösung einbauen, bevor der Rollout beginnt. Was sich jetzt noch verändern lässt, kostet wenig. Was sich nach dem Go-live verändert, kostet viel.
- Nach dem Launch eine klare Anlaufstelle benennen, nicht für Beschwerden, sondern für Beobachtungen. Was jetzt noch schiefläuft, ist wertvolles Feedback.
Einordnung in core+
Das Feld enable & support in core+ fragt nicht nur nach Werkzeugen und Kompetenzaufbau. Es fragt nach den Bedingungen, unter denen Menschen sich trauen, Probleme zu benennen. Zuhören, wie ich es hier beschreibe, ist eine direkte Maßnahme in diesem Feld. Es schafft die Voraussetzung dafür, dass Wandel aus dem System selbst kommt.
Wer parallel verstehen will, warum Change-Projekte im Mittelstand systematisch eine bestimmte Dynamik entwickeln, findet das unter Change Management: Warum Wandel oft scheitert. Konkrete Methodik für die Ursachenanalyse bietet 5-mal Warum: Ursachen finden statt Symptome lösen. Wenn ein Rollout bereits in Schieflage geraten ist, hilft ERP-Rollout retten: Change Management von unten.
Drei Entscheidungsfragen
- Weißt du, was die Menschen, die das neue System täglich nutzen sollen, bereits über die geplante Veränderung denken?
- Gibt es einen Einwand, den du in den letzten Monaten mehrfach gehört hast, aber noch nicht wirklich verarbeitet hast?
- Wer in deinem Unternehmen kennt den betroffenen Ablauf am besten, und war diese Person an der Lösung beteiligt?
Mehr Methodik unter Change Management und Transformation.
