Softwareeinführung im Betrieb: warum Projekte scheitern

Softwareprojekte im Betrieb scheitern selten an der Software. Sie scheitern an ungeklärten Zuständigkeiten, an Altdaten ohne Eigentümer und an Abnahmekriterien, die niemand vor dem Vertrag festgelegt hat. Diese vier Festlegungen entscheiden über den Verlauf, nicht der Funktionsumfang des Systems.

Warum scheitern Softwareprojekte im Betrieb?

Softwareprojekte scheitern an organisatorischen Ursachen: unklare Entscheidungswege, unvollständige Altdaten und fehlende Abnahmekriterien. Der Funktionsumfang der Software ist selten die Ursache. Betriebe erkennen den Fehler meist erst in der Testphase, wenn Anpassungen teuer und Termine bereits gesetzt sind.

Der Begriff Scheitern hat im Projektgeschäft drei Ausprägungen: Abbruch vor dem Go-live, Go-live mit deutlicher Terminüberschreitung und Go-live mit einem System, das die Fachabteilung anschließend umgeht. Die dritte Variante fällt in Statistiken selten auf, weil das Projekt formal abgeschlossen wurde.

Die Panorama Consulting Group berichtet im 2026 ERP Report, dass mehr als ein Viertel der befragten Organisationen das Projektbudget überschritten hat. Als führende Ursache nennt der Bericht zusätzlichen Technologiebedarf — Betriebe entdecken gravierende Passungsprobleme spät im Projekt und reagieren mit Zusatzmodulen, Scope-Erweiterung und Eigenentwicklung [Stand: 2026].

Ein ERP-System ist eine integrierte Software, die Auftrag, Lager, Einkauf, Fertigung und Buchhaltung auf einer gemeinsamen Datenbasis führt. Weil alle Bereiche dieselben Stammdaten nutzen, wirkt jede unsaubere Festlegung eines Bereichs auf alle anderen. Genau das unterscheidet die Einführung eines ERP-Systems von der Einführung eines Einzelwerkzeugs wie einer Zeiterfassung.

Welche organisatorischen Fehler treten am häufigsten auf?

Fünf organisatorische Fehler treten wiederkehrend auf: kein benannter Entscheider, Altdaten ohne Eigentümer, Prozesse ohne Hoheitsfrage, Schulung als letzter Projektschritt und ein Go-live-Termin, der aus dem Vertrieb stammt statt aus der Projektplanung.

Kein benannter Entscheider. Projekte mit einem Lenkungskreis aus fünf gleichberechtigten Abteilungsleitern produzieren Vertagungen. Es braucht eine Person mit Entscheidungsbefugnis über Prozessfragen und ein schriftliches Eskalationsverfahren mit Frist.

Altdaten ohne Eigentümer. Artikelstämme, Kundendaten, offene Posten und Dokumentenarchive liegen in unterschiedlichen Systemen und Qualitäten. Ohne benannten Verantwortlichen je Datenbereich verschiebt sich die Bereinigung bis in die Migrationswoche.

Prozesse ohne Hoheitsfrage. Wenn der Standardprozess der Software vom gewachsenen Ablauf abweicht, gibt es zwei Wege: Prozess anpassen oder Software anpassen. Betriebe, die diese Frage nicht vorab grundsätzlich beantworten, entscheiden sie im Projekt fünfzig Mal einzeln.

Schulung am Ende. Die Trovarit AG erhebt mit der Studie ERP in der Praxis — Anwenderzufriedenheit, Nutzen & Perspektiven seit 2004 zweijährlich Anwenderurteile im deutschsprachigen Raum; über 24.000 Teilnehmer haben bisher mitgewirkt. Im Zyklus 2024/25, veröffentlicht am 23. März 2026, liegt die Gesamtnote bei 1,80, während Support-Erreichbarkeit, Unterstützung bei Release-Wechseln, mobile Nutzbarkeit und Performance kritischer bewertet wurden als in früheren Runden [Stand: März 2026]. Das sind Themen der Betriebsphase, nicht der Auswahlphase.

Termin aus dem Vertrieb. Ein Go-live zum Jahreswechsel klingt sauber und trifft in vielen Betrieben auf Inventur, Jahresabschluss und Urlaubszeit gleichzeitig.

Was muss vor der Vertragsunterschrift festgelegt sein?

Vier Punkte gehören schriftlich in die Projektunterlagen, bevor ein Vertrag unterschrieben wird: Entscheidungsweg, Datenherkunft, Prozess-Hoheit und Abnahmekriterien. Dieser Vier-Festlegungen-Check kostet wenige Arbeitstage und verlagert Konflikte aus der Testphase in die Vorbereitung.

1. Entscheidungsweg. Eine Person entscheidet Prozessfragen. Ein Gremium entscheidet Budgetfragen. Eskalationen laufen über eine benannte Route mit einer Frist in Arbeitstagen.

2. Datenherkunft. Je Datenbereich — Artikel, Kunden, Lieferanten, offene Posten, Dokumente — steht fest: Welches System liefert, wer prüft, welcher Zeitraum wird übernommen, was bleibt im Altsystem.

3. Prozess-Hoheit. Es steht schriftlich fest, ob im Konfliktfall der Standardprozess der Software gilt oder der bestehende Ablauf. Abweichungen brauchen eine begründete Einzelfreigabe durch den Entscheider aus Punkt 1.

4. Abnahmekriterien. Der Go-live gilt als erreicht, wenn definierte Vorgänge im Echtsystem durchlaufen — etwa Auftrag bis Rechnung, Wareneingang bis Lagerbuchung, Monatsabschluss. Jedes Kriterium hat ein Datum und einen Prüfer.

Der Vier-Festlegungen-Check ersetzt kein Lastenheft. Er beantwortet die Fragen, die ein Lastenheft offen lässt: nicht was das System können muss, sondern wer im Projekt entscheidet. Wie das dazugehörige Anforderungsdokument aufgebaut wird, steht im Leitfaden Branchensoftware auswählen: ein Leitfaden in sieben Schritten.

Wie erkennt man ein Projekt, das gerade kippt?

Vier Frühwarnzeichen zeigen ein kippendes Projekt an: Testfälle werden verschoben statt durchgeführt, offene Punkte wandern ohne Entscheidung von Sitzung zu Sitzung, Anpassungswünsche steigen nach Projektstart, und die Fachabteilung pflegt parallel eine eigene Tabelle weiter.

Die Parallel-Tabelle ist das deutlichste Signal. Sie bedeutet, dass Beschäftigte dem neuen System für ihre Kernaufgabe nicht vertrauen. Nach dem Go-live verschwindet diese Tabelle nicht von selbst — sie wird zur zweiten Datenquelle und erzeugt genau die Abweichungen, für deren Beseitigung das Projekt begonnen wurde.

Das zweite belastbare Signal ist die Zahl der Änderungsanträge nach Projektstart. Steigt sie über die ersten Projektwochen hinweg an, statt zu fallen, war die Anforderungsaufnahme unvollständig. Zusätzliche Entwicklungsleistung behebt die Ursache nicht; sie verlängert die Kette der Abhängigkeiten. Welche Kostenblöcke dabei entstehen, ist in Was kostet die Einführung eines ERP-Systems? aufgeschlüsselt.

Wie viel Zeit und Personal braucht eine Einführung?

Eine Softwareeinführung bindet interne Arbeitszeit in drei Rollen: Projektleitung, Key-User je Fachbereich und Datenverantwortliche. Diese Zeit fällt zusätzlich zum Tagesgeschäft an. Betriebe, die dafür keine Freistellung einplanen, verschieben Projektaufgaben in Abendstunden und verlängern die Laufzeit.

Key-User sind Beschäftigte aus der Fachabteilung, die das System im Projekt testen, Prozesse abnehmen und später als erste Anlaufstelle im Betrieb dienen. Ihre Auswahl entscheidet über die Akzeptanz: Wer die tägliche Arbeit kennt, erkennt einen unpassenden Ablauf im Test, nicht erst im Echtbetrieb.

Die Bandbreite der Projektdauer ist groß und hängt von Datenmenge, Zahl der Standorte, Schnittstellen und Fertigungstiefe ab. Belastbare Zahlen liefert nur die Projektplanung des konkreten Betriebs zusammen mit dem Anbieter. Pauschale Dauerangaben aus Anbieterunterlagen beziehen sich meist auf Referenzfälle ohne Altdatenmigration.

Für die Einordnung des eigenen Bedarfs hilft eine Auswertung dieses Verzeichnisses: Für die fünf erfassten Branchen sind 30 Funktionskategorien hinterlegt — von Warenwirtschaft über DMS bis Zeiterfassung [Stand: September 2026]. Ein Betrieb entscheidet in der Regel nicht über ein System, sondern über ein Zusammenspiel mehrerer Kategorien. Welche Kategorien für den eigenen Betrieb infrage kommen, grenzt der Software-Finder ein.

Was passiert nach dem Go-live?

Nach dem Go-live folgt die Stabilisierungsphase: Fehlerbehebung, Nacharbeit an Stammdaten, Nachschulung und die Umstellung auf Regelbetrieb mit festem Ansprechpartner. Diese Phase gehört in den Projektplan und in das Budget, weil in ihr die Akzeptanz des Systems entschieden wird.

Drei Aufgaben stehen in dieser Phase regelmäßig an: die Übergabe vom Projektteam an eine dauerhafte Betreuung, die Festlegung eines Verfahrens für Änderungswünsche aus dem Betrieb, und die Planung des ersten Release-Wechsels. Gerade der Release-Wechsel gehörte in der Trovarit-Erhebung 2024/25 zu den kritisch bewerteten Punkten [Stand: März 2026] — ein Argument dafür, den Ablauf vertraglich zu klären, solange die Verhandlungsposition besteht.

Auch die Auswertung der Nutzung gehört dazu. Module, die drei Monate nach dem Go-live niemand öffnet, sind entweder überflüssig oder ungeschult. Beide Befunde führen zu einer Handlung, das Weglassen der Messung nicht.

💬 Meine Einschätzung

Die verbreitete Annahme lautet, die Auswahl entscheide über den Projekterfolg. Die Datenlage spricht dagegen: Der 2026 ERP Report führt Budgetüberschreitungen auf zusätzlichen Technologiebedarf im laufenden Projekt zurück, und die Trovarit-Kritikpunkte 2024/25 betreffen mit Support, Release-Wechseln und Performance durchweg die Betriebsphase. Beides entsteht nach der Unterschrift. Für die Redaktion folgt daraus eine unbequeme Reihenfolge: erst die vier Festlegungen zu Entscheidungsweg, Daten, Prozess-Hoheit und Abnahme treffen, dann Anbieter vergleichen. Ein Betrieb, der diese vier Punkte schriftlich hat, führt auch mit dem zweitbesten System ein funktionierendes Projekt. Umgekehrt gilt das nicht.

Häufige Fragen zur Softwareeinführung

Wann ist eine Softwareeinführung gescheitert?

Eine Softwareeinführung gilt als gescheitert, wenn das Projekt abgebrochen wird, der Go-live-Termin deutlich überschritten wird oder die Fachabteilung das System nach der Einführung umgeht. Die dritte Variante erscheint in Projektberichten als Erfolg und zeigt sich erst an parallel gepflegten Tabellen.

Wer sollte die Projektleitung im Betrieb übernehmen?

Die Projektleitung übernimmt eine Person mit Entscheidungsbefugnis über Prozessfragen und mit freigestellter Arbeitszeit. Fachliche Nähe zum Kerngeschäft wiegt schwerer als IT-Kenntnis, weil die meisten Projektentscheidungen Abläufe betreffen und nicht Technik.

Wie viele Altdaten sollten übernommen werden?

Übernommen werden die Daten, die im Tagesbetrieb gebraucht werden: aktive Artikel, aktive Kunden und Lieferanten, offene Posten. Historische Daten bleiben nach Möglichkeit revisionssicher im Altsystem oder in einem Archiv. Jeder zusätzlich migrierte Datenbereich verlängert Test und Bereinigung.

Braucht der Betriebsrat ein Mitspracherecht bei der Software?

In Betrieben mit Betriebsrat besteht ein Mitbestimmungsrecht nach § 87 Absatz 1 Nummer 6 Betriebsverfassungsgesetz, sobald eine technische Einrichtung geeignet ist, Verhalten oder Leistung von Beschäftigten zu überwachen. Das trifft auf Zeiterfassung, Telematik und viele Auswertungsfunktionen zu.

Lohnt sich externe Projektbegleitung?

Externe Begleitung liefert Projekterfahrung und Neutralität zwischen Betrieb und Anbieter. Sie ersetzt keine interne Entscheidungsinstanz. Betriebe, die den Entscheidungsweg nicht selbst festlegen, verschieben mit externer Begleitung die Verantwortung, nicht das Problem.

Quellen und weiterführende Literatur

• Panorama Consulting Group — The 2026 ERP Report (panorama-consulting.com): Jährliche Auswertung weltweiter ERP-Implementierungen mit Angaben zu Budget- und Terminüberschreitungen.
• Trovarit AG — ERP in der Praxis: Anwenderzufriedenheit, Nutzen & Perspektiven (trovarit.com): Seit 2004 zweijährliche Anwenderbefragung im deutschsprachigen Raum, Zyklus 2024/25 veröffentlicht im März 2026.
• Betriebsverfassungsgesetz § 87 (gesetze-im-internet.de): Rechtsgrundlage der Mitbestimmung bei technischen Einrichtungen zur Verhaltens- und Leistungskontrolle.
• Bitkom e. V. (bitkom.org): Studien und Presseinformationen zu Digitalisierung und Weiterbildung in deutschen Unternehmen.
• GoBD — Bundesministerium der Finanzen (bundesfinanzministerium.de): Anforderungen an die Aufbewahrung und Unveränderbarkeit digitaler Aufzeichnungen, relevant bei Altdatenmigration.