Vor dem Go-Live kommt der Gesprächsraum: Warum Softwareprojekte an Akzeptanz scheitern, nicht an Technik

Die Projektlage ist im deutschen Mittelstand häufig dieselbe: Ein ERP- oder DMS-System wurde nach sorgfältiger Auswahl beschafft, der Hersteller liefert solide Technologie, das Budget stimmt – und doch bleibt die Einführung in der Praxis hängen. Mitarbeiterinnen und Mitarbeiter umgehen das neue System, pflegen Altdaten parallel weiter oder drucken Dokumente aus, die digital vorliegen sollten. Die Ursache liegt selten im Produkt. Sie liegt in der Frage, die zu spät gestellt wird: Wollen die Menschen, die damit arbeiten sollen, das überhaupt?

Die Anatomie eines stillen Scheiterns

Ein typisches Beispiel aus dem Mittelstand: Ein produzierender Betrieb mit 180 Mitarbeitenden führt ein neues Warenwirtschaftssystem ein. Sechs Monate nach dem Go-Live erfährt die Geschäftsleitung, dass die Disposition weiterhin in der alten Excel-Liste arbeitet, während das neue System nur befüllt wird, um den Monatsabschluss zu speisen. Doppelarbeit als Dauerzustand. Die Projektleitung hatte Schulungen eingeplant – jeweils zwei Stunden, sechs Wochen vor dem Start, ohne Einbindung der Betriebsrats.

Solche Verläufe sind keine Ausnahme. Studien zur Projektarbeit zeigen seit Jahren, dass ein erheblicher Teil der Softwareeinführungen Zeit- und Budgetpläne reißt oder die angestrebten Ziele verfehlt – und dass die Hauptursachen menschlicher Natur sind: mangelnde Akzeptanz, unklare Verantwortlichkeiten, verlorene Vertrautheit mit gewohnten Abläufen. Das Kürzel auf der Rechnung, ob ERP, DMS oder MES, spielt dabei keine Rolle.

Was der Betriebsrat mit Systemarchitektur zu tun hat

In vielen Projekten gilt der Betriebsrat als Hindernis, das man möglichst spät informiert. Diese Lesart verkehrt die Realität. Nach § 87 BetrVG unterliegen unter anderem die technischen Überwachungseinrichtungen und im weiteren Sinne Fragen des Datenschutzes der Mitbestimmung; bei Einführung neuer Software, die Arbeitsabläufe verändert, ist der Betriebsrat ohnehin ein zentraler Gesprächspartner. Wer ihn erst zwei Wochen vor dem Go-Live einlädt, erzeugt genau die Verzögerungen, die man fürchten.

Umgekehrt kann die Mitbestimmung zum Qualitätshebel werden. Betriebsräte kennen die tatsächlichen Abläufe am Arbeitsplatz – etwa jene informellen Workarounds, die in keiner Prozessdokumentation stehen. Wer sie früh einbindet, entdeckt Lücken im Konzept, bevor sie teuer werden. Ein mittelständisches Handelsunternehmen aus Baden-Württemberg verlegte seine komplette Projekt-Kommunikation in einen gemeinsamen Ausschuss aus IT, Fachbereich und Betriebsrat; die Durchführungsquote im neuen CRM lag nach sechs Monaten bei über neunzig Prozent, während vergleichbare Einführungen im Umfeld häufig unter fünfzig Prozent bleiben.

Schulung ist kein Termin, sondern ein Zeitraum

Die zweite wiederkehrende Schwachstelle ist die Schulungsplanung. Zwei Stunden Gruppenunterweisung vor dem Launch sind keine Qualifizierung, sondern eine Formalie. Menschen verändern Arbeitsgewohnheiten nicht, weil eine Folie ihnen sagt, dass sie es sollen. Wirksam sind stattdessen:

• Rollenbezogene Schulungen kurz vor dem jeweiligen Go-Live des Moduls, nicht Monate im Vorfeld
• Multiplikatoren im Fachbereich, die als interne Ansprechpartner fungieren und aus eigener Praxis berichten
• Verlässliche Übergangsphasen, in denen Altsystem und Neusystem parallel gepflegt werden dürfen – mit klarem Enddatum
• Sichtbare Unterstützung der Führungsebene, die das neue System selbst nutzt und nicht per Delegation ausweicht

Diese Maßnahmen kosten Geld und Zeit. Sie kosten ein Bruchteil dessen, was ein gescheitertes Projekt oder ein Dauerzustand der Doppelarbeit verursacht.

Change-Management als Teil der Beschaffung

Der eigentliche Denkfehler liegt früher: Software wird beschafft, als wäre sie eine Maschine. Geliefert, angeschlossen, fertig. Systeme, die Arbeitsweisen verändern, sind jedoch soziale Artefakte. Ihre Beschaffung sollte deshalb von Beginn an zwei Spalten führen: eine für die Technik, eine für die Organisation. Die zweite Spalte enthält Kommunikationsplan, Mitbestimmungsfahrplan, Schulungskonzept und eine ehrliche Antwort auf die Frage, welche Stellenprofile sich verändern.

Projektleitungen, die diese Akzeptanzfrage vor dem Go-Live klären, gewinnen etwas Unbezahlbares: Vorlauf. Widerstände werden sichtbar, solange man sie noch adressieren kann, statt sie nach dem Launch als Sabotage zu deuten. Und die Geschäftsleitung kann sich früh positionieren – nicht als Auftraggeber, der durchdrückt, sondern als Beteiligter, der selbst ins neue System wechselt.

Fazit: Die Kürzel stehen auf dem Papier, der Erfolg steht im Betrieb

ERP, DMS, CRM – die Abkürzungen der Digitalisierung beschreiben, was ein System ist. Ob es funktioniert, entscheidet sich in der Belegschaft. Wer Mitbestimmung als Pflichtübel behandelt, Schulungen als Restposten des Budgets plant und Change-Management für ein Beratungsprodukt hält, wird auch mit der besten Technologie scheitern. Wer dagegen die Akzeptanzfrage zur ersten Projektfrage macht, holt aus mittelmäßiger Software oft mehr heraus, als ein Spitzenprodukt unter Ablehnung je leisten kann. Der Unterschied liegt nicht im Kürzel. Er liegt im Gesprächsraum, der vor dem Go-Live stattfindet.