Wie du ein ERP-Projekt realistisch planst, was es wirklich kostet – und woran du erkennst, dass ein ERP allein dein Problem nicht löst.
TL;DR
- Eine ERP-Einführung ist ein Organisationsprojekt, kein IT-Projekt. Wer nur Software installiert, digitalisiert sein Chaos – und wundert sich über das Ergebnis.
- Die Lizenz ist der kleinste Posten. Die echten Kosten stecken in internen Aufwänden: Projektleitung, Key-User, Datenbereinigung, Schulung. Wer sie nicht einplant, plant am Projekt vorbei.
- Ein ERP ist ein Baustein, kein Betriebssystem. Die entscheidende Frage ist nicht „welches ERP", sondern: Welche Systemarchitektur trägt dein Unternehmen in fünf Jahren?
Was Dir dieser Beitrag bringt
Du bekommst den realistischen Ablauf einer ERP-Einführung und eine ehrliche Einordnung von Dauer und Kosten – inklusive der internen Aufwände, die auf keiner Anbieterseite stehen. Dazu die typischen Fehler und die eine Frage, die dir kein ERP-Anbieter stellen wird. Kein Anbietervergleich, sondern eine nüchterne Entscheidungsgrundlage für Entscheider.
Warum ERP-Projekte selten an der Software scheitern
Das neue ERP ist ausgewählt, das Budget freigegeben. Achtzehn Monate später: Die Disposition arbeitet weiter mit ihrer Excel-Liste, der Vertrieb pflegt Aufträge doppelt, und der Report am Freitag entsteht wie immer per Hand. Das System läuft. Benutzt wird es zur Hälfte.
Dieses Muster ist kein Einzelfall, und es liegt fast nie an der Software. ERP-Systeme sind ausgereifte Produkte. Was scheitert, ist der Weg dorthin: unklare Ziele, ungeklärte Prozesse, überlastete Schlüsselpersonen, schmutzige Daten. Die Einführung scheitert nicht am Werkzeug – sondern an der Struktur, in die das Werkzeug gestellt wird.
Software verstärkt, was da ist. Ordnung wird schneller. Chaos auch.
Eine ERP-Einführung ist kein IT-Projekt
Ein ERP bildet deine Kernprozesse ab: Auftrag, Einkauf, Lager, Rechnung. Wer diese Prozesse in ein neues System überführt, entscheidet zwangsläufig, wie das Unternehmen künftig arbeitet. Das ist Organisationsarbeit – die Technik ist nur ihr sichtbarer Teil. Deshalb gehört die Verantwortung für eine ERP-Einführung nicht in die IT-Abteilung, sondern in die Geschäftsführung. Nicht, weil die IT es nicht könnte – sondern weil nur die Geschäftsführung Prozessentscheidungen treffen darf, die Abteilungsgrenzen überschreiten. Ohne diese Rückendeckung wird das Projekt zum Verhandlungsmarathon, in dem jede Abteilung ihren Sonderfall verteidigt.
Wenn sich dein Unternehmen an diesem Punkt wiederfindet, ist das kein Versagen. Das ist der normale Verlauf von Wachstum ohne Systemarchitektur: Die operative Komplexität ist größer geworden als die Systeme, die sie steuern.
Erst die Organisation, dann das System.
Die Phasen einer ERP-Einführung
Der Ablauf folgt bei aller Anbietervielfalt demselben Grundmuster: Analyse → Auswahl → Implementierung → Go-live → Stabilisierung.
- Analyse: Ist-Prozesse erfassen, Ziele messbar machen, Schwachstellen benennen. Hier entsteht das Fundament, und hier wird am häufigsten gespart.
- Auswahl: Anforderungen ins Lastenheft, Longlist, Shortlist, Testszenarien mit echten Daten. Nicht die Demo entscheidet, sondern dein schwierigster Prozess.
- Implementierung: Konfiguration, Schnittstellen, Datenmigration, Tests. Die längste Phase, in der interne Kapazität zum Engpass wird.
- Go-live: Stichtag oder stufenweise. Beides ist legitim, beides braucht einen Plan für den Fall, dass etwas klemmt.
- Stabilisierung: Die ehrlichste Phase. Nach dem Start sinkt die Produktivität erst einmal, bevor sie steigt. Wer das einplant, bleibt ruhig.
Ein ERP-Projekt endet nicht am Go-live-Tag. Es endet, wenn niemand mehr zurück will.
Wie lange dauert eine ERP-Einführung?
Die Spannen in der Praxis sind groß: Ein kleines Unternehmen mit einfachen Prozessen kann in wenigen Monaten produktiv sein. Ein Mittelständler mit mehreren Standorten, Fertigung oder komplexer Logistik sollte eher in einem Jahr denken, manchmal länger. Versprechen wie „live in wenigen Wochen" gelten für den Standardfall ohne Anpassungen, ohne Altdaten, ohne Schnittstellen – also für ein Unternehmen, das es so kaum gibt.
Die Dauer hängt weniger von der Software ab als von drei Faktoren: Wie klar sind deine Prozesse dokumentiert? Wie sauber sind deine Daten? Und wie viel Zeit können deine besten Leute tatsächlich ins Projekt geben – neben dem Tagesgeschäft, das nicht wartet?
Nicht der Anbieter bestimmt das Tempo – sondern deine Struktur.
Was kostet eine ERP-Einführung wirklich?
Die Anbieterseiten nennen Lizenzpreise. Die Wahrheit ist unbequemer: Die Lizenz ist über die Laufzeit gerechnet meist der kleinste Posten. Dazu kommen Implementierung und Anpassungen, Schnittstellen, Datenübernahme, Schulung – und der Block, den fast niemand beziffert: deine internen Aufwände. Ein ERP-Projekt bindet einen Projektleiter über Monate zu einem erheblichen Teil seiner Arbeitszeit. Key-User aus jeder Abteilung fallen phasenweise spürbar aus dem Tagesgeschäft. Daten müssen bereinigt, Prozesse dokumentiert, Tests gefahren werden. Diese Stunden stehen auf keiner Rechnung, bezahlt werden sie trotzdem.
Rechne deshalb nie mit dem Angebotspreis, sondern mit den Gesamtkosten über fünf Jahre: Lizenzen, Betrieb, Wartung, Anpassungen, interne Zeit. Und rechne die zweite Spalte dagegen: Was kostet es, drei weitere Jahre mit dem heutigen Zustand zu arbeiten – mit Doppelerfassung, Suchzeiten, Fehlern und dem Report am Freitag?
Ein klassisches Muster aus unserem Beitrag: Excel ablösen: Wann sich eine eigene Lösung lohnt
Teuer ist nicht das Projekt. Teuer ist die Entscheidung, die auf falschen Zahlen beruht.
Das Lastenheft: Anforderungen, keine Lösungen
Das Lastenheft beschreibt, was dein Unternehmen braucht – nicht, wie der Anbieter es lösen soll. Der Unterschied klingt akademisch, entscheidet aber über die Qualität der Angebote. „Wir brauchen ein Feld für Sonderkonditionen" ist eine Lösung. „Unsere Preise hängen von Kunde, Menge und Saison ab, und der Vertrieb muss sie ohne Rückfrage auskunftsfähig haben" ist eine Anforderung.
Gute Lastenhefte entstehen aus Prozessen, nicht aus Wunschlisten. Sie priorisieren: Was ist Pflicht, was ist wertvoll, was ist nice-to-have? Und sie benennen die Sonderfälle ehrlich – denn genau dort entscheidet sich später, ob der Standard trägt oder verbogen werden muss.
Wer seine Anforderungen nicht kennt, bekommt die Anforderungen des Anbieters.
Sechs Kriterien für die Systemauswahl
Adjektive wie „flexibel" und „benutzerfreundlich" stehen in jeder Broschüre. Belastbar sind andere Fragen:
- Branchenlogik im Standard: Deckt das System deine Kernprozesse ab, ohne dass du sie verbiegen musst?
- Offene Schnittstellen: Gibt es eine dokumentierte API – oder nur das Versprechen, „alles anbinden" zu können? (Warum das entscheidend ist: API-Schnittstellen: Wo aus Anwendungen Systeme werden)
- Datenhoheit: Kommst du jederzeit vollständig an deine Daten – auch beim Ausstieg?
- Releasefähigkeit: Überleben deine Anpassungen das nächste Update, oder zementieren sie eine alte Version?
- Betriebsmodell: Cloud oder eigener Betrieb – passend zu deinen Anforderungen an Datenschutz und Verfügbarkeit, nicht zur Mode.
- Anbieterperspektive: Wird das Produkt aktiv weiterentwickelt, und wer implementiert es in fünf Jahren noch?
Wähle das System nach dem schwierigsten Prozess, nicht nach der schönsten Demo.
Datenmigration: die unterschätzte Baustelle
Altdaten sind das ehrlichste Abbild deiner heutigen Struktur: Dubletten im Kundenstamm, Artikel mit drei Schreibweisen, Preislisten, die nur eine Kollegin versteht. Wer diese Daten ungefiltert ins neue System kippt, nimmt das alte Chaos mit – nur teurer.
Deshalb gilt: erst bereinigen, dann migrieren. Das ist mühsame, unspektakuläre Arbeit, und sie braucht die Menschen, die die Daten kennen. Aber sie zahlt doppelt: Das neue System startet mit einer sauberen, zentralen Datenbasis – eine Wahrheit statt fünf Versionen. Und ganz nebenbei entsteht die Grundlage für alles, was später auf den Daten aufbauen soll, von Auswertungen bis KI.
Ein neues System mit alten Daten ist ein neues Etikett auf einem alten Problem.
Change Management heißt Arbeit, nicht Newsletter
Der häufigste Satz nach einem Go-live: „Früher ging das schneller." Er stimmt sogar – für die ersten Wochen. Wer zwanzig Jahre mit demselben System gearbeitet hat, ist darin schnell, Workarounds inklusive.
Widerstand gegen das neue System ist deshalb nicht böswillig – sondern menschlich. Konkret heißt das: Key-User früh einbinden, nicht erst zur Schulung. Die Menschen mit den Sonderfällen an den Tisch holen, denn ihre Fälle entscheiden über die Akzeptanz. Schulung am echten Prozess mit echten Daten, nicht am Klick-Handbuch. Und nach dem Start: Präsenz, schnelle Antworten, sichtbare Korrekturen. Frei von Schuldzuweisungen. Frei von Durchhalteparolen. Frei von der Illusion, ein Rundschreiben sei Kommunikation.
Systeme werden nicht eingeführt. Sie werden angenommen – oder umgangen.
Die typischen Fehler bei der ERP-Einführung
- Das Projekt der IT überlassen. Dann werden Technikfragen entschieden, wo Prozessfragen offen sind.
- Prozesse eins zu eins nachbauen. Wer den Ist-Zustand abbildet, digitalisiert seine Workarounds gleich mit.
- Interne Aufwände ignorieren. Das Tagesgeschäft frisst das Projekt auf – und das Projekt das Tagesgeschäft.
- Datenbereinigung aufschieben. Am Ende migriert der Zeitdruck die Fehler gleich mit.
- Jeden Sonderfall ins System customizen. Jede Anpassung will bei jedem Update gepflegt werden. Manche Sonderfälle gehören vereinfacht statt programmiert – und manche gehören gar nicht ins ERP.
- Nach dem Go-live abschalten. Die Stabilisierungsphase entscheidet, ob das System gelebt wird oder verwaist.
Fehler sind hier selten originell. Das ist die gute Nachricht: Sie sind bekannt – also vermeidbar.
Die Frage, die dir kein ERP-Anbieter stellt
Braucht dein Unternehmen wirklich (nur) ein neues ERP? Die Frage klingt ketzerisch, ist aber die wichtigste des ganzen Projekts. Ein ERP ist stark in dem, was bei vielen Unternehmen gleich ist: Auftrag, Einkauf, Lager, Buchhaltung. Deine Wertschöpfung – die Disposition, die Projektsteuerung, die Preislogik, die dich vom Wettbewerb unterscheidet – ist im ERP-Standard oft nur ein Kompromiss.
Standardsoftware bildet Durchschnitt ab. Ist Dein Unternehmen der Durchschnitt?
Viele Unternehmen versuchen dann, das ERP zu verbiegen, bis es alles kann. Das Ergebnis: teure Anpassungen, zähe Updates, und trotzdem Excel daneben. Der andere Weg ist architektonisch: Das ERP macht das, was es gut kann – und deine differenzierenden Prozesse laufen in Systemen, die dafür gebaut sind, verbunden über saubere Schnittstellen. Denn ein gutes ERP bleibt ein gutes ERP. Es muss nur nicht alles können.
Wann welcher Weg trägt: Standardsoftware vs. Individualsoftware
So wird aus der ERP-Frage eine Architekturfrage: nicht „welches System kaufen wir", sondern „welches Operating System braucht unser Unternehmen" – eine Struktur, in der Prozesse, Daten und Entscheidungen zusammenlaufen.
Wie dieses Zielbild aussieht: Operating System Die teuerste Antwort ist die richtige Antwort auf die falsche Frage.
Der erste Schritt: Klarheit statt Bauchgefühl
Ob ERP-Wechsel, ERP plus Individualsoftware oder ein anderer Schnitt: Diese Entscheidung braucht ein klares Bild vom Ist-Zustand – Prozesse, Systeme, Datenflüsse, Schmerzpunkte. Genau dafür gibt es das System-Audit: eine strukturierte Analyse mit Architekturentwurf und Umsetzungsfahrplan. Der Report gehört dir – auch wenn du danach nicht mit uns arbeitest. Technologie soll Menschen freier machen. Auch bei einer ERP-Einführung: frei von Doppelerfassung, frei von Systemen, gegen die dein Team arbeitet, frei für die Entscheidungen, die wirklich Erfahrung brauchen. Wir verwandeln operativ komplexe Mittelständler in Tech-Unternehmen.