Ein ERP-System ist die größte Einzelinvestition in die eigene Organisation, die viele Mittelständler je tätigen — und eines der riskantesten Projekte zugleich. Branchenerhebungen und Projektberichte zeichnen seit Jahren dasselbe Bild: Ein erheblicher Teil der Einführungen sprengt Budget und Zeitplan, manche scheitern ganz und enden vor Gericht. Das Bemerkenswerte daran: Die Ursachen sind fast nie technischer Natur. ERP-Projekte scheitern an unklaren Anforderungen, überschätzter Standardnähe, vernachlässigter Datenqualität und daran, dass die eigentliche Arbeit — die Veränderung von Abläufen und Gewohnheiten — als Nebensache behandelt wird. Wer die typischen Bruchstellen kennt, kann sie vertraglich und organisatorisch absichern, bevor sie teuer werden.
Warum ERP-Projekte scheitern
Das Grundmuster gescheiterter Projekte ähnelt sich. Am Anfang steht häufig eine Auswahl nach Hochglanzdemo statt nach den eigenen kritischen Prozessen. Dann wird der Aufwand systematisch unterschätzt — nicht der des Anbieters, sondern der eigene: Ein ERP-Projekt bindet Schlüsselleute aus Fachabteilungen über Monate zu erheblichen Teilen ihrer Arbeitszeit, und genau diese Leute fehlen dann im Tagesgeschäft. Drittens wächst der Anpassungsumfang schleichend: Jede Abteilung möchte ihre gewohnten Sonderlocken im neuen System wiederfinden, aus dem Standardsystem wird eine teure Individualentwicklung mit allen Folgekosten bei Updates. Viertens wird die Datenmigration als technisches Anhängsel behandelt, obwohl sie ein eigenes Teilprojekt ist. Und fünftens fehlt oft eine Instanz mit Entscheidungsmacht: Ohne einen Lenkungsausschuss, der Zielkonflikte schnell entscheidet, eskaliert jede Detailfrage zur Geschäftsführung — oder bleibt liegen.
Die Gegenmittel sind bekannt und unspektakulär: realistische Kapazitätsplanung mit Freistellung der Schlüsselpersonen, ein klares Zielbild, was das System leisten muss (und was bewusst nicht), eiserne Disziplin beim Standard und eine Projektorganisation mit kurzen Entscheidungswegen. Für Unternehmen, die intern keine Projektleitungserfahrung haben, kann externe Verstärkung auf Zeit sinnvoll sein — die Fachbereichskenntnis muss aber im Haus bleiben.
Anforderungen: Vom Prozess zum Lastenheft
Vor jeder Anbieterrecherche steht die Innenschau: Wie laufen die Kernprozesse heute tatsächlich — nicht wie im Organigramm, sondern in der Realität mit ihren Excel-Nebenbuchhaltungen und Zurufen über den Flur? Eine Prozessaufnahme mit den Menschen, die die Arbeit machen, fördert dabei regelmäßig Erstaunliches zutage und ist zugleich die erste Gelegenheit zu entscheiden, welche Abläufe das neue System abbilden soll und welche man besser vorher bereinigt. Die alte Regel gilt: Wer einen schlechten Prozess digitalisiert, hat einen schlechten digitalen Prozess.
Das Ergebnis fließt ins Lastenheft — die Beschreibung dessen, was das System aus Anwendersicht können muss. Gute Lastenhefte sind priorisiert (Muss, Soll, Kann), beschreiben Prozesse und erwartete Ergebnisse statt Bildschirmmasken und konzentrieren sich auf das Unterscheidende: Die Debitorenbuchhaltung kann jedes System; die Frage ist, ob es die eigene Chargenrückverfolgung, das Rahmenauftragsgeschäft oder die Intercompany-Abwicklung beherrscht. Nicht vergessen: nichtfunktionale Anforderungen wie Benutzerzahlen, Schnittstellen zu Bestandssystemen, Berechtigungskonzept, Anforderungen an Datenschutz und — je nach Branche — Compliance-Vorgaben, wie sie unser Beitrag zu Compliance-Pflichten im Mittelstand beschreibt. Auch Berichtspflichten der nächsten Jahre gehören auf den Radar: Wer etwa künftig Nachhaltigkeitsdaten liefern muss, sollte die Datenverfügbarkeit gleich mitdenken — Stichwort CSRD-Berichterstattung.
Systemauswahl und Vertragsgestaltung
Aus Lastenheft und Marktrecherche entsteht eine Longlist von vielleicht acht bis zehn Systemen, die über strukturierte Anfragen auf drei bis vier Finalisten schrumpft. Für die Endauswahl haben sich Testszenarien bewährt: Die Anbieter führen nicht ihre Standarddemo vor, sondern spielen vorbereitete Geschäftsvorfälle des Unternehmens mit dessen (anonymisierten) Beispieldaten durch — vom Auftragseingang über Fertigung und Lieferung bis zur Rechnung. Das kostet beide Seiten Aufwand und trennt zuverlässig Marketing von Substanz. Neben der Funktionalität zählen Implementierungspartner (oft wichtiger als der Softwarehersteller selbst), Branchenerfahrung mit Referenzbesuchen, Roadmap und Zukunftssicherheit des Produkts sowie die Gesamtkosten über fünf bis zehn Jahre: Lizenzen oder Subscription, Implementierung, Anpassungen, Wartung, interne Kosten.
Der ERP-Vertrag wird in guten Zeiten verhandelt und in schlechten gelesen — wer beim Abschluss auf klare Meilensteine und Exit-Regeln verzichtet, verhandelt später aus der Schwäche.
Dem Vertrag gebührt mehr Aufmerksamkeit, als er meist bekommt. Die wichtigsten Schutzklauseln für den Auftraggeber: ein Phasenmodell mit definierten Meilensteinen, Teilabnahmen und daran gekoppelten Zahlungen statt hoher Vorauszahlungen; das priorisierte Lastenheft beziehungsweise Pflichtenheft als Vertragsbestandteil mit geregeltem Change-Request-Verfahren samt Preisfindung; präzise gefasste Mitwirkungspflichten des Kunden — denn zu vage Mitwirkungsklauseln sind das Standardargument von Anbietern, wenn Projekte kippen; benannte Schlüsselpersonen des Dienstleisters mit Zustimmungsvorbehalt bei Austausch; Eskalationsstufen und ein Ausstiegsrecht mit fairer Abrechnungsregel, wenn definierte Meilensteine endgültig verfehlt werden. Dazu gehören Regelungen zur Datenherausgabe in offenen Formaten beim Vertragsende und — bei kleineren Herstellern oder kritischen Individualanteilen — eine Quellcode-Hinterlegung beim neutralen Dritten. Bei Cloud-ERP treten Verfügbarkeits-SLAs, Datenstandort und Exit-Management an die Stelle des klassischen Lizenzkaufs.
Datenmigration und Altsystem
Kein Teilprojekt wird so regelmäßig unterschätzt wie die Datenmigration. Stammdaten aus zwanzig Jahren Altsystem sind fast immer in schlechterem Zustand als vermutet: Dubletten, verwaiste Artikel, inkonsistente Einheiten, Kundenadressen in drei Schreibweisen. Die Bereinigung ist keine IT-Aufgabe, sondern Facharbeit — nur der Vertrieb weiß, welcher der drei „Müller GmbH"-Einträge der richtige ist. Deshalb: früh beginnen, Verantwortliche je Datenobjekt benennen, Qualitätsregeln definieren und die Migration mehrfach als Generalprobe durchspielen, inklusive Abstimmung der Eröffnungssalden mit der Buchhaltung. Wer erst vier Wochen vor Go-live merkt, dass die Artikelstämme nicht laden, verschiebt nicht die Migration, sondern das ganze Projekt.
Zum Altsystem gehört eine bewusste Entscheidung: Welche historischen Daten werden übernommen, welche bleiben in einem Lesezugriff oder Archiv? Vollmigration aller Historie ist teuer und selten nötig; gesetzliche Aufbewahrungspflichten für steuerrelevante Daten lassen sich auch über ein stillgelegtes, lesbar gehaltenes Altsystem oder einen Archivexport erfüllen. Wichtig ist, dass Zugriff und Auswertbarkeit über die gesamten Aufbewahrungsfristen gesichert bleiben.
Change, Schulung und der Go-live
Die beste Software scheitert an Menschen, die sie nicht nutzen wollen oder können. Change beginnt nicht mit der Schulungswoche vor dem Start, sondern mit der Prozessaufnahme: Wer früh einbezogen wird, Testläufe mitgestaltet und seine Einwände ernst genommen sieht, trägt das neue System später mit. Key User aus den Abteilungen sind dafür die wichtigste Institution — sie werden intensiv geschult, gestalten Tests und Anpassungen mit und sind nach dem Start die erste Anlaufstelle für Kollegen. Schulungen selbst sollten rollenbezogen und nah am Echtbetrieb stattfinden, mit den Prozessen und Daten des Hauses statt mit Schulungsbeispielen des Herstellers. Auch neue Arbeitsformen wollen bedacht sein: Wenn Teile des Teams remote arbeiten, müssen Schulungskonzept und Support das abbilden — wie Unternehmen verteiltes Arbeiten organisieren, zeigt das Beispiel der Eilers GmbH aus Kiel.
Für den Go-live selbst gibt es zwei Grundmuster: Big Bang — alles an einem Stichtag — oder stufenweise Einführung nach Standorten oder Modulen. Der Big Bang ist riskanter, vermeidet aber teure Parallelphasen mit doppelter Datenpflege; die Stufenlösung ist schonender, verlangt aber Übergangsschnittstellen. In beiden Fällen gilt: Der Stichtag gehört an ein Wochenende oder in eine schwache Geschäftsphase, es braucht eine Hypercare-Phase von mehreren Wochen mit erhöhter Supportpräsenz von Anbieter und Key Usern — und vorab definierte Kriterien, wann der Start abgebrochen und zurückgerollt wird. Ein Go-live, der nüchtern verschoben wird, ist ein Erfolg des Projektcontrollings, kein Scheitern. Mehr zu Projektsteuerung und Organisation finden Sie im Ressort Unternehmensführung.
Häufige Fragen
Wie lange dauert eine ERP-Einführung im Mittelstand?
Je nach Unternehmensgröße und Komplexität typischerweise 9 bis 24 Monate von der Anforderungsaufnahme bis zum stabilen Betrieb. Auswahlphase und Datenbereinigung werden dabei am häufigsten unterschätzt. Ein sportlicher, aber unrealistischer Zeitplan ist eine der sichersten Methoden, das Budget zu sprengen.
Standard nutzen oder System anpassen?
So viel Standard wie möglich. Jede Individualanpassung kostet dreifach: bei der Entwicklung, bei jedem Update und bei jedem Personalwechsel. Anpassungen sollten auf Prozesse beschränkt bleiben, die echte Wettbewerbsvorteile darstellen — für alles andere ist es meist günstiger, den eigenen Prozess dem Standard anzunähern.
Welche Vertragsklauseln sind die wichtigsten?
Meilensteine mit Teilabnahmen und daran gekoppelten Zahlungen, ein geregeltes Change-Request-Verfahren, präzise Mitwirkungspflichten, benannte Schlüsselpersonen, Eskalations- und Ausstiegsregeln sowie Datenherausgabe in offenen Formaten am Vertragsende. Bei kritischen Individualanteilen zusätzlich eine Quellcode-Hinterlegung.
Big Bang oder stufenweise Einführung?
Beides ist legitim. Der Big Bang eignet sich für kleinere Organisationen mit überschaubarer Systemlandschaft und vermeidet doppelte Datenpflege. Die stufenweise Einführung reduziert das Risiko bei mehreren Standorten oder komplexen Prozessen, erfordert aber Übergangsschnittstellen und mehr Geduld. Entscheidend sind in beiden Fällen Generalproben, Hypercare und klare Rückfallkriterien.
