Prozessmanagement in ERP-Projekten

In vielen Unternehmen existieren Prozesshandbücher, Verfahrensanweisungen oder ISO-konforme Dokumentationen. Sie erfüllen Audit-Anforderungen und beschreiben Abläufe formal korrekt. Doch im ERP-Projekt zeigt sich häufig eine unbequeme Wahrheit: Diese Dokumente bilden die gelebte Realität nur unzureichend ab.

Zwischen dokumentiertem Prozess und operativer Praxis liegen oft Welten. Informelle Abstimmungen, gewachsene Varianten, Excel-Zwischenlösungen und implizite Sonderregelungen prägen den Alltag, stehen aber in keinem QM-Handbuch. Wird diese Diskrepanz im ERP-Prozessmanagement nicht systematisch aufgearbeitet, entsteht eine strukturelle Fehleinschätzung mit weitreichenden Folgen.

Die Konsequenz: ERP-Projekte scheitern in der Regel nicht an fehlenden Funktionen, sondern an fehlender Prozessklarheit. Prozessmanagement ist im ERP-Kontext keine Dokumentationsübung und kein QM-Nebenprodukt, sondern die Führungsdisziplin, die bestimmt, ob ein System lediglich technisch eingeführt oder organisatorisch wirksam implementiert wird.

Wer Funktionen bewertet, ohne Prozesse zu verstehen, optimiert Symptome

In der Auswahlphase ist eine funktionale Betrachtung legitim und notwendig. Für Marktrecherche und Shortlist stehen Aufwand-Nutzen-Aspekte im Vordergrund: Unternehmen müssen klären, ob branchenspezifische Kernanforderungen grundsätzlich im Standard abbildbar sind. Dabei können sie jedoch nicht jeden Anbieter, sein Produkt und seine Methodik frühzeitig im Detail bewerten.

Funktionen sind dabei ein Filterinstrument – aber kein Selbstzweck. Jede funktionale Anforderung sollte aus einem konkreten Prozess heraus begründet sein. Nur so wird die Vorauswahl der TOP-3 Anbieter mit einer überschaubaren Zahl entscheidungsrelevanter Anforderungen fundiert unterlegt.

Spätestens mit der Projektvergabe verschiebt sich der Fokus grundlegend: Die Prozessarchitektur rückt in den Mittelpunkt. Funktionale Anforderungen konkretisieren den Leistungsumfang, werden zu Akzeptanzkriterien im prozessorientierten Pflichtenheft und bilden die Leitplanken der Soll-Prozesse. Prozessmanagement wird damit zur Brücke zwischen Markteingrenzung und inhaltlicher Strukturierung des Einführungsprojekts.

Kontext entscheidet: Es gibt kein universelles Prozessmanagement

Ein häufiger Denkfehler besteht darin, Prozessmanagement als standardisierbares Schema zu betrachten. Tatsächlich muss es immer im jeweiligen Unternehmens- und Projektkontext ausgeprägt werden.

Eine ERP-Einführung in einem Unternehmen mit geringer Prozessreife erfordert einen anderen Ansatz als in einer Organisation mit ausgeprägter Prozesskultur und klaren Prozess-Owner-Strukturen. Im ersten Fall sollte vor dem eigentlichen Einführungsprojekt zunächst Transparenz geschaffen werden, um ein gemeinsames Prozessverständnis zu etablieren. Der Fokus liegt auf Analyse und Beschreibung der Ist-Prozesse als Grundlagenarbeit.

Wo Prozessorientierung, Rollen und Verantwortlichkeiten entlang der Wertschöpfungskette bereits gelebte Praxis sind, ist dieses Fundament etabliert. Hier sollte der Schwerpunkt stärker auf Harmonisierung, Governance und weiterer Optimierung liegen.

Im validierten Umfeld – etwa in der Medizintechnik oder Pharmaindustrie – ist Prozessmanagement untrennbar mit regulatorischen Vorgaben, Normen und Validierungsanforderungen verbunden. Prozesse sind hier nicht nur Effizienzträger, sondern Nachweisobjekte; Risikoanalysen, Validierungsdokumentationen und formale Change-Control-Verfahren sind integraler Bestandteil der Prozessarchitektur.

Je geringer das Systemverständnis, je teurer fallen die Prozessentscheidungen aus

Ein neuralgischer Punkt vieler ERP-Projekte liegt in der Konzeptphase: Zielprozesse werden definiert, Varianten bewertet und organisatorische Weichen gestellt – häufig bevor Key-User die Systemlogik ausreichend durchdrungen haben.

Klassisch sequenzielle Vorgehensmodelle (Wasserfall) verstärken dieses Risiko. Prozesse werden abstrakt entworfen und freigegeben; die konkrete Abbildung in der ERP-Software erfolgt deutlich später. Das Informationsgefälle zwischen Einführungsberatern und den Usern bleibt bestehen. – mit teuren Folgen.

Ein hybrider oder agiler Ansatz verändert diese Dynamik: Werden Zielprozesse bereits in der Konzeptionsphase systemnah über Prototypen abgebildet und durch die Key-User validiert, entsteht früh eine reale Auseinandersetzung mit der Standardlogik. Prozessverantwortliche erkennen unmittelbar, wo Anpassungen notwendig sind – und welche organisatorischen Konsequenzen daraus entstehen.

Anforderungs- und Testmanagement sollten dabei eng mit dem Prozessmanagement verzahnt werden: Spezifikationen werden so engmaschig entlang von Prozessen strukturiert, und die Umsetzbarkeit der End-to-End-Szenarien wird innerhalb des Systems validiert und freigegeben. Methodiken wie das Aachener Implementierungsmodell für Business Software verankern diese Verzahnung als Querschnittsaufgabe und schließen damit die klassische Lücke zwischen Konzept und Realisierung.

Neu gestalten oder historisch fortschreiben?

Die Ausprägung des Prozessmanagements unterscheidet sich fundamental zwischen Greenfield- und Brownfield-Szenarien:

Greenfield-Projekte zielen auf eine kritische Auseinandersetzung mit etablierten Ist-Prozessen. Prozessoptimierung und -harmonisierung stehen im Fokus: Prozessvarianten werden reduziert, Rollen und Verantwortlichkeiten neu strukturiert und organisatorische Potenziale erschlossen. Zentrales Paradigma ist die Nutzung der Standard-Abläufe der neuen ERP-Lösung.

Brownfield-Projekte hingegen sind eher als technisches Upgrade einzuordnen. Bestehende Abläufe und Strukturen werden in der Regel weitgehend übernommen; Systemeinstellungen und Individualentwicklungen werden mit möglichst wenig Aufwand technisch migriert. Der organisatorische Veränderungsbedarf bleibt entsprechend begrenzt.

Aus Perspektive der Prozessoptimierung ist eine Brownfield-Migration – beispielsweise von SAP ERP (ECC 6.0) auf SAP S/4HANA – nur ein Zwischenschritt. Wer Prozessentscheidungen vertagt, übernimmt organisatorische Altlasten und verschenkt Verbesserungspotenziale.

Prozessmanagement-Methodik der Dienstleister: Tools, Templates und Governance

Einführungsdienstleister verstehen Prozessmanagement zunehmend horizontal, übergreifend auf Konzeption, Realisierung, Testing und Betrieb. BPM-Tools werden dabei zur gemeinsamen Informationsbasis von Fachbereich und IT und können – je nach Toolchain – mit zentralen Systemkomponenten verknüpft werden. Voraussetzung dafür sind jedoch, dass schlanke Modellierungsrichtlinien (Ebenen, Notation, Pflichtattribute, Qualitätskriterien und Freigaben) sowie klare Governance (Single Source of Truth, Änderungs- und Freigaberechte) nicht an Dokumentation, Test und Training vorbeilaufen.

Template- und Fit-to-Standard-Ansätze beschleunigen die Implementierung und schaffen Orientierung, insbesondere in Greenfield- oder stark standardisierten Organisationen. Sie bergen jedoch Risiken, wenn Templates als implizite Prozessvorgabe übernommen werden: Dann werden notwendige organisatorische Änderungen zu wenig qualifiziert und Key-User setzen sich zu spät mit den Standardprozessen auseinander – mit der Folge, dass Prozessentscheidungen faktisch an den Dienstleister delegiert und Passungsprobleme erst spät sichtbar werden.

Von der Prozesskonzeption zur gelebten Praxis: Die Rolle des Change Managements

In Konzeption und Realisierung werden fast immer organisatorische Veränderungen identifiziert – etwa neue Rollen und Verantwortlichkeiten, angepasste Freigaben und Kontrollen, veränderte Schnittstellen oder Anpassungen in der Aufbau- und Ablauforganisation. Erst wenn diese Änderungen geplant und umgesetzt werden, kann die ERP-Lösung nach dem Go-live die gewünschten Verbesserungen liefern.

Genau hier liegt ein häufiger Bruch: Prozesse werden konzipiert und technisch umgesetzt, aber die Organisation „zieht nicht nach“. Diese Lücke schließt ein kontinuierliches Change Management – parallel zur Prozess- und Systemumsetzung. Sonst drohen Rückfälle in alte Gewohnheiten, Umgehungslösungen und Schattenprozesse kurz nach dem Go-live.

Noch reibungsloser wird der Übergang, wenn Prozessmanagement und Change Management von Beginn an verzahnt werden: Prozessmodelle liefern die Grundlage für Kommunikation, Trainings und organisatorische Maßnahmen; Change Management stellt sicher, dass Prozessentscheidungen in der Linie ankommen und tatsächlich gelebt werden – bis hin zu Führungskommunikation, Readiness und messbarer Adoption.

Nach dem Go-live: Prozessmanagement nachhaltig implementieren

In vielen ERP-Projekten entsteht ein Spannungsfeld: Das System ist produktiv, während die formale Prozessdokumentation der neuen Realität zeitlich hinterherläuft. In den Monaten vor dem Go-live dominieren Stabilisierung, Tests, Cutover und Training – Fachleute und Key-User sind gebunden, die Dokumentation wird verschoben.

Im nicht regulierten Umfeld ist das durch eine fokussierte Dokumentations- und Optimierungswelle nach der Hypercare-Phase pragmatisch lösbar. Priorität sollten dabei kritische End-to-End-Ketten, Kontrollen und Schnittstellen haben: Sie müssen revisionsfest und onboarding-tauglich vorliegen.

Fazit: ERP-Erfolg ist Prozesskompetenz

ERP-Auswahl und -Einführung werden oft als IT-Projekte verstanden, sind aber in erster Linie Organisationsprojekte. Prozessmanagement schafft Transparenz über den Ist-Zustand, definiert Zielbilder und bildet den Orientierungsrahmen für Soll-Prozesse – als Leitplanke für Standardisierung und gezielte Differenzierung.

Entscheidend ist der Übergang ins Change Management und seine Kultivierung: Nur wenn Änderungen an Arbeitsweisen, Rollen, Verantwortlichkeiten und Steuerungsmechanismen in der Organisation ankommen, kann die Lösung stabil wirken. Und weil Prozessdokumentation im Projektalltag häufig zu kurz kommt, sollte nach dem Go-live eine bewusst geplante Konsolidierungsphase mit klarer Priorisierung und Governance folgen.

Damit ist ERP-Erfolg weniger eine Frage der Software als der Prozesskompetenz – als durchgängige Disziplin entlang der Projektphasen und als Grundlage für nachhaltige Weiterentwicklung.

5 Kernaussagen des Beitrags „Prozessmanagement in ERP-Projekten“

1. ERP-Projekte scheitern meist an Prozessen – nicht an der Software.
   Fehlende Transparenz über tatsächlich gelebte Abläufe führt dazu, dass Anforderungen falsch formuliert und Systeme an falschen Annahmen ausgerichtet werden.
2. Dokumentierte Prozesse entsprechen oft nicht der operativen Realität.
   QM-Handbücher oder ISO-Dokumentationen bilden informelle Abstimmungen, Sonderwege und Excel-Zwischenlösungen häufig nicht ab – genau diese prägen jedoch den Arbeitsalltag.
3. Prozessmanagement wird im Projektverlauf zur zentralen Steuerungsdisziplin.
   Während Funktionen in der Auswahlphase als Filter dienen, bilden später Zielprozesse die Grundlage für Pflichtenheft, Systemkonfiguration, Tests und organisatorische Entscheidungen.
4. Prozessdesign muss früh mit Systemverständnis verknüpft werden.
   Prototyping, iterative Vorgehensmodelle und die Einbindung von Key-Usern reduzieren Fehlentscheidungen, die sonst in frühen Konzeptphasen getroffen werden.
5. Nachhaltiger ERP-Erfolg entsteht erst durch die organisatorische Umsetzung.
   Prozessdesign allein reicht nicht aus. Erst die Verzahnung mit Change Management, klarer Governance und einer konsolidierten Prozessdokumentation sorgt dafür, dass neue Abläufe tatsächlich gelebt werden.

Das könnte Sie auch interessieren

Hauptsache ERP Warum nicht die Software, sondern die Führungsfähigkeit über den Projekterfolg entscheidet

Cloud, KI und neue regulatorische Anforderungen verändern die Anforderungen an ERP-Systeme grundlegend. Doch der Erfolg entscheidet sich nicht bei der Softwareauswahl, sondern bei Prozessen, Daten und klaren Verantwortlichkeiten. Warum Unternehmen ihr ERP neu denken müssen und welche Fehler viele Mittelständler dabei noch immer machen, zeigt dieser Beitrag.

Adaptive Service Level Agreements Wie flexible Verträge Innovation ermöglichen und welche Risiken sie bergen

Klassische SLAs sichern Stabilität –doch genau das macht sie oft zur Innovationsbremse. Anpassungen werden aufgeschoben, Chancen bleiben ungenutzt. Wie lassen sich Verträge so gestalten, dass Veränderung nicht stört, sondern systematisch ermöglicht wird? Der Beitrag zeigt, wie adaptive SLAs als „Living Contract“funktionieren und Innovation schon während der Laufzeit fördern –praxisnah und direkt umsetzbar für IT- und ERP-Verantwortliche.

Requirements-Engineering bei „lebenden“ ERP-Systemen Ein Framework zur Unterstützung des Requirements-Engineerings durch Fachabteilungen

Das grundlegende Problem: mehr Pflege als Neuentwicklung Wertet man Pressemitteilungen als Indikator, so kann man den Eindruck bekommen, dass Start-Ups, technische Innovationen und große Projekte mit wegweisenden Weichenstellungen den Alltag beherrschen, begleitet von neuen IT-Systemen und innovativen Cloud-Anwendungen, die man einfach nur herunterladen müsse, um eine neue Stufe der „Digitalisierung“ zu erreichen. Auch in der Informatikausbildung ist die Ausrichtung auf neue Systeme vorherrschend: Das „Requirements Engineering“ (RE), also die Erhebung, die Analyse und das Management von Anforderungen, wird oft anhand von kleinen Projekten in der Neuentwicklung geschult.  Dieser Fokus auf neue Systeme ist aus Sicht der Medien und Technikanbieter zwar nachvollziehbar,  verstellt allerdings den Blick darauf, dass die meisten Unternehmen eben doch schon einige Jahre oder Jahrzehnte auf dem Markt sind und die grundlegenden betriebswirtschaftlichen Prozesse mit vorhandener ...

Zehn ERP-Praktiker über Projekterfolg Was in Auswahl, Implementierung und Betrieb wirklich zählt

ERP-Projekte scheitern selten an der Software selbst, sondern an unklaren Prozessen, fehlender Vorbereitung und mangelnder organisatorischer Einbindung. Zehn erfahrene ERP-Praktiker aus Deutschland und der Schweiz berichten aus ihrer Projektpraxis und zeigen, welche Faktoren bei Auswahl, Einführung und Betrieb von ERP-Systemen wirklich entscheidend sind – von der oft unterschätzten Phase Null bis zur realistischen Einordnung von KI.

Gefährliche Stille: Wenn S/4HANA-Projekte aus dem Ruder laufen  Warum viele Unternehmen strategisch falsch entscheiden – und es erst Jahre später merken

Die S/4HANA-Transformation gilt für viele Vorstände und IT-Leitungen als eines der wichtigsten strategischen Projekte der letzten Jahre. Sie steht für Zukunftsfähigkeit, Innovationsfähigkeit und nicht zuletzt für die technologische Grundlage kommender Geschäftsmodelle. Umso erstaunlicher ist eine Beobachtung, die sich in zahlreichen Transformationsprojekten wiederholt: Die Transformation scheitert –ohne dass es jemand zur Kenntnis nimmt.