ERP-Prozessanalyse: Was Unternehmen vor der Einführung wirklich wissen müssen
Warum die wichtigste Phase eines ERP-Projekts vor der Softwareauswahl liegt – nicht danach.
Das Projekt, das nie hätte scheitern dürfen
Ein Fachhändler mit rund 120 Mitarbeitenden startet eine ERP-Einführung. Der Anbieter ist sorgfältig ausgewählt, das Budget genehmigt, der Projektplan steht. Neun Monate später steht das System – und passt nicht. Der Einkaufsprozess läuft anders als konfiguriert, weil er im Lastenheft falsch beschrieben war. Die Lagerverwaltung bildet eine Sonderlogik nicht ab, die im Tagesgeschäft aber täglich gebraucht wird. Das Systemhaus berechnet Nachkonfiguration. Das Unternehmen zahlt ein zweites Mal für Leistungen, die beim ersten Mal hätten sauber definiert sein müssen.
Das Problem war nicht der Anbieter. Das Problem war, dass niemand die Prozesse vor der Ausschreibung wirklich verstanden hatte.
Diese Konstellation ist keine Ausnahme. Sie ist der Normalfall. Unternehmen investieren erhebliche Zeit in die Softwareauswahl – und zu wenig Zeit in die Frage, die diese Auswahl erst sinnvoll macht: Wie arbeiten wir wirklich, und wie wollen wir künftig arbeiten?
Was ERP-Prozessanalyse bedeutet – und was sie nicht ist
Bevor wir zu den typischen Fehlern kommen, eine Einordnung.
ERP-Prozessanalyse im Kontext einer Einführung bedeutet:
- Bestehende Abläufe strukturiert aufnehmen – nicht wie sie im Handbuch stehen, sondern wie sie tatsächlich gelebt werden
- Medienbrüche, Workarounds und informelle Prozesse sichtbar machen
- Anforderungen an das neue System aus dem Prozessverständnis ableiten, nicht aus Produktkatalogen
- Prozesslücken identifizieren, die im neuen System geschlossen werden sollen – und solche, die bewusst bleiben dürfen
ERP-Prozessanalyse ist nicht:
- Das Abzeichnen von Standard-Prozesslandkarten, die der Anbieter mitbringt
- Eine einmalige Workshop-Runde mit der Geschäftsführung
- Deckungsgleich mit dem Lastenheft – das Lastenheft ist das Ergebnis, nicht der Prozess
Vier Muster, die ich in der Praxis immer wieder sehe
1. Die Prozesse werden beschrieben wie sie sein sollten – nicht wie sie sind
Das klingt selbstverständlich, ist es aber nicht. Wenn Abteilungsleiter gebeten werden, ihre Prozesse zu beschreiben, schildern sie meistens die Soll-Version: geordnet, logisch, so wie es im letzten Qualitätssicherungsaudit dokumentiert wurde. Was sie nicht schildern: die fünfzehn Excel-Tabellen, die parallel laufen. Das inoffizielle Vier-Augen-Prinzip bei Bestellungen über einem bestimmten Betrag, das nirgendwo steht. Den Workaround in der Lagerverwaltung, den die Kollegen vor drei Jahren eingeführt haben, als das Altsystem das nicht mehr konnte.
Genau diese informellen Prozesse sind es, die bei einer ERP-Einführung zu Problemen führen – weil sie weder im Lastenheft stehen noch in der Konfiguration berücksichtigt werden. Das neue System bildet sie nicht ab. Die Mitarbeitenden bauen die nächste Generation von Workarounds.
Eine belastbare Prozessanalyse arbeitet deshalb mit zwei Ebenen: der dokumentierten Prozessbeschreibung und der gelebten Realität. Beide unterscheiden sich fast immer. Der Abstand zwischen ihnen ist einer der wichtigsten Indikatoren für das Projektrisiko.
Wie die strukturierte Prozess- und Projektreifeanalyse methodisch aufgesetzt wird, ist zentraler Bestandteil von ERPulse360 – dem Assessment, das Klarheit schafft, bevor die Konfiguration beginnt.
2. Anforderungen werden aus dem Produktkatalog des Anbieters abgeleitet
Es ist ein naheliegender Fehler: Der Anbieter präsentiert sein System in einer Demo. Die Fachabteilungen sehen Funktionen, die sie beeindrucken. Aus dem Beeindrucktsein werden Anforderungen. Das Lastenheft entsteht im Dialog mit dem Anbieter – nicht aus einem eigenständig erarbeiteten Prozessverständnis.
Das Ergebnis ist ein System, das die Standardprozesse des Anbieters gut abbildet. Ob es die tatsächlichen Prozesse des Unternehmens abbildet, ist eine andere Frage.
Wer seine Anforderungen kennt, bevor er in eine Anbieterpräsentation geht, verhandelt aus einer fundamental anderen Position. Er kann bewerten, was das System wirklich leistet – und was nicht. Er erkennt, wo Standardprozesse passen und wo Anpassungsbedarf entsteht. Und er kann die Anpassungskosten realistisch einschätzen, bevor der Vertrag unterschrieben ist.
In einem Projekt im Großhandel haben wir im Rahmen einer vorgelagerten Prozessanalyse festgestellt, dass ein wesentlicher Teil der Anforderungen im Bereich Lieferantenmanagement durch Standardfunktionalität abbildbar war – was zuvor als zwingendes Customizing bewertet worden war. Die Einsparung allein in diesem Bereich überstieg das Honorar für die Analyse um ein Vielfaches.
3. Die Prozessanalyse wird zu spät gestartet oder zu früh abgebrochen
Viele Unternehmen starten die Prozessaufnahme parallel zur Anbieterauswahl oder sogar erst danach. Das ist die falsche Reihenfolge. Die Prozessanalyse ist die Grundlage für die Auswahl – nicht ihr Begleiter.
Häufig wird sie auch zu früh abgebrochen: Die ersten Prozesse sind aufgenommen, das Gefühl entsteht, man habe einen guten Überblick. Was fehlt: die zweite Ebene, also die Schnittstellen zwischen Abteilungen, die Ausnahmefälle, die Saisonlogiken. Genau diese Details entscheiden darüber, ob das System im Tagesgeschäft funktioniert.
Eine vollständige Prozessanalyse für einen mittelständischen Händler mit fünf bis acht Kernprozessen dauert in der Regel vier bis sechs Wochen – wenn sie methodisch sauber durchgeführt wird. Wer diese Zeit nicht investiert, investiert sie später – unter deutlich ungünstigeren Bedingungen.
4. Die Prozessanalyse endet mit der Dokumentation
Prozessaufnahme allein reicht nicht. Der entscheidende Schritt ist die Bewertung: Welche Prozesse sollen im neuen System unverändert abgebildet werden? Welche sollen optimiert werden – und nach welchen Kriterien? Welche Prozesse sind so unternehmensspezifisch, dass Customizing unvermeidbar ist, und wo ist Standardisierung die bessere Wahl?
Diese Bewertung ist keine technische Frage. Sie ist eine strategische. Sie betrifft Prioritäten, Ressourcen und manchmal auch Machtfragen zwischen Abteilungen. Wer sie nicht explizit stellt, beantwortet sie implizit – durch die Entscheidungen, die das Systemhaus später in der Konfiguration trifft.
Was eine belastbare ERP-Prozessanalyse liefern sollte
Am Ende einer soliden Prozessanalyse sollte ein Unternehmen folgendes in der Hand haben:
Ein realistisches Bild der Ist-Prozesse – nicht bereinigt, nicht geschönt. Mit den Workarounds, den informellen Abläufen und den bekannten Schwachstellen.
Eine priorisierte Anforderungsliste – abgeleitet aus den Prozessen, nicht aus dem Produktkatalog. Mit klarer Unterscheidung zwischen Must-have, Should-have und Nice-to-have.
Eine Bewertung der Projektkomplexität – wie viel Customizing ist realistisch notwendig? Welche Prozesse passen gut auf Standardfunktionalität? Wo sind die größten Risiken?
Eine Go/No-go-Grundlage für die Anbieterwahl – die es ermöglicht, Angebote miteinander zu vergleichen, ohne Äpfel mit Birnen zu vergleichen.
Genau diese Artefakte entstehen im Rahmen von ERPulse360: strukturierte Prozess- und Projektreifeanalyse mit dokumentierten Ergebnissen als Entscheidungsgrundlage – in vier bis sechs Wochen.
Die Frage, die fast niemand stellt
Neben der Frage, wie Prozesse heute ablaufen, gibt es eine zweite, die in vielen ERP-Projekten gar nicht gestellt wird: Wie sollen sie künftig ablaufen?
Eine ERP-Einführung ist kein Digitalisierungsprojekt im technischen Sinne. Sie ist eine Gelegenheit, Abläufe neu zu denken – Prozesse zu vereinfachen, Schnittstellen zu reduzieren, Verantwortlichkeiten zu klären. Unternehmen, die diese Gelegenheit nutzen, haben nach der Einführung ein System, das ihre Prozesse trägt. Unternehmen, die sie nicht nutzen, haben ein neues System mit denselben alten Problemen – nur teurer.
Diese Frage ist auch eine Führungsfrage. Sie kann nicht an das Projektteam oder den Berater delegiert werden. Sie muss von der Geschäftsführung und den verantwortlichen Führungskräften beantwortet werden – am besten bevor die erste Anbieterdemonstration stattfindet. Wie das organisatorisch und methodisch gelingt, begleiten wir im Rahmen unserer strategischen ERP-Advisory.
Die Veränderungsbereitschaft der Organisation, diese neuen Prozesse tatsächlich zu leben, ist dann die nächste kritische Frage – und der Anknüpfungspunkt für strukturiertes Change Management mit ChangeReady360.
Fazit: Prozessklarheit ist kein Luxus
Eine ERP-Einführung ohne belastbare Prozessanalyse ist keine Sparmaßnahme. Sie ist ein kalkuliertes Risiko – das regelmäßig teurer wird als die Analyse selbst.
Unternehmen, die vier bis sechs Wochen in eine saubere Prozessaufnahme und Anforderungsbewertung investieren, gehen mit einer fundamental anderen Ausgangslage in Ausschreibung, Verhandlung und Implementierung. Sie wissen, was sie brauchen. Sie wissen, wo Standardfunktionalität reicht. Und sie wissen, wo Risiken liegen – bevor sie vertraglich gebunden sind.
Das ist keine Theorie. Das ist der Unterschied zwischen einem ERP-Projekt, das im Budget bleibt, und einem, das nachfinanziert werden muss.
Wo steht Ihre ERP-Vorbereitung wirklich?
In einem kostenlosen 30-minütigen Erstgespräch besprechen wir gemeinsam, ob Ihre Prozessdokumentation als Grundlage für eine ERP-Auswahl tragfähig ist – und welche Lücken vor dem nächsten Schritt geschlossen werden sollten.
Häufig gestellte Fragen
Wie lange dauert eine ERP-Prozessanalyse im Mittelstand?
Für einen mittelständischen Händler oder Großhändler mit fünf bis acht Kernprozessen sind vier bis sechs Wochen realistisch – vorausgesetzt, die relevanten Fachbereiche sind verfügbar und die Dokumentation ist zumindest in Grundzügen vorhanden. Kürzere Zeiträume sind möglich, wenn der Fokus auf definierten Kernprozessen liegt und Ausnahmefälle bewusst ausgeklammert werden.
Wann ist der richtige Zeitpunkt für die Prozessanalyse?
Vor der Anbieterauswahl – nicht parallel dazu und nicht danach. Die Prozessanalyse ist die Grundlage, auf der eine Ausschreibung und ein belastbarer Vergleich von Angeboten erst möglich wird. Wer erst nach der Systemwahl in die Prozessaufnahme geht, kauft die Katze im Sack.
Was kostet es, die Prozessanalyse zu überspringen?
Die häufigsten Konsequenzen: Nachkonfigurationskosten, weil Anforderungen im Vertrag nicht oder falsch beschrieben waren. Verlängerung der Projektlaufzeit, weil Prozesslücken erst in der Implementierungsphase sichtbar werden. Und im schlechtesten Fall ein System, das technisch funktioniert, aber die tatsächlichen Arbeitsprozesse nicht trägt. Erfahrungswerte aus der Praxis zeigen, dass die Kosten einer nachträglichen Prozessklärung im Schnitt drei- bis fünfmal höher liegen als die einer vorgelagerten Analyse.
Quellen: Panorama Consulting ERP Report 2023; Gartner, Why ERP Implementations Fail, 2022; eigene Projekterfahrung aus ERP-Begleitungen im Handel und Großhandel
Wenn Sie dieses Thema in Ihrem Projekt vertiefen möchten, sprechen Sie mit uns.