Rund um die ERP-Einführung ranken viele Mythen, ganz unabhängig davon, um welches ERP-System es sich handelt. Die Mythen und Vorurteile, denen ich bei der Einführung von SAP S/4HANA begegne, knüpfen nahtlos an die aus ECC-Zeiten an.
So gehen z.B. viele Unternehmen davon aus, dass es sich dabei um ein reines IT-Projekt handelt, das die Fachabteilung nur am Rande betrifft. Oder dass eine exakte Detailplanung automatisch der Garant für den Erfolg des Projektes ist. Genauso hartnäckig hält sich der Glaube, dass die Nutzung von Best Practices generell ein Heilsbringer ist. Was ist Wahrheit, was Mythos, was ist tatsächlich wichtig für den Erfolg des Projekts?
Wer ist verantwortlich für die Umstellung auf S/4HANA?
Die Einführung von SAP S/4HANA ist immer ein großer finanzieller Aufwand. Ganz egal ob es sich um eine Neueinführung per Greenfield-Approach, die Migration per Conversion oder einen hybriden Ansatz handelt. Daher benötigt man einen Sponsor für das Projekt, möglichst aus dem Top-Management. Häufig gibt dieser dem bedauernswerten IT-Leiter den Auftrag, einen Business Case für das Projekt zu rechnen.
ABER: Ich habe in über 30 Jahren SAP Beratung noch nie einen seriösen Business Case für eine ERP-Einführung gesehen, der sich allein aus IT-Einsparungen (z. B. Systemkonsolidierung, Standardisierung) ergeben hat!
Gründe für die Einführung eines modernen ERP-Systems
Vielmehr ergibt sich ein effektiver Hebel erfahrungsgemäß in erster Linie durch Maßnahmen, welche die Fachbereiche betreffen.
- Vereinfachung von Prozessen („brauchen wir das wirklich?“)
- Harmonisierung von Prozessen („ein betriebswirtschaftliches Problem -> ein Prozess -> eine ERP-Funktion“)
- Optimierung von Prozessen (Prozessinnovationen, Automatisierung)
- Qualitätsverbesserungen bei den Stammdaten (verbesserte Pflegeprozesse, Vermeidung von Redundanzen)
Beteiligte Personengruppen an der S/4HANA-Einführung: Fachseite, IT und Top Management
Die Fachseite wird im Projekt daher nicht erst für das Schreiben des Pflichtenhefts benötigt. Sinnvollerweise wird die IT schon vor dem eigentlichen S/4HANA-Projekt zusammen mit der Fachseite die „Schmerzpunkte“ des Unternehmens ermitteln und daraus die Ziele für das Projekt ableiten. Daraus ergibt sich dann auch das „Warum?“ des Projekts, ein sehr wichtiger Input für die spätere Projektkommunikation.
Damit die Ziele nicht zu reinen Lippenbekenntnissen werden, an die sich in den späteren Konzeptionsworkshops niemand mehr erinnern kann oder will, empfiehlt sich die Vereinbarung klarer Spielregeln, für die man unbedingt ein Commitment des Top Managements benötigt. Eine solche Spielregel kann zum Beispiel heißen: „Eine lokale Abweichung von global definierten Prozessen ist nur im Falle zwingender lokaler gesetzlicher Vorschriften zulässig.“
In diesem Zusammenhang kann die Bedeutung von Process Ownern und Key Usern in der Unternehmensorganisation nicht genug hervorgehoben werden. Ein ERP-Projekt braucht klare fachseitige Ansprechpartner und vor allem Entscheider, welche einen Prozess end-to-end weltweit definieren.
Wie detailliert sollte die Projektplanung sein?
Wer kennt sie nicht: Projektpläne in Excel oder MS Project, die Tausende von Vorgängen enthalten und in denen Ressourcen auf Mitarbeiterebene wochen- oder gar tagesgenau geplant werden? Schließlich muss die Fachseite wissen, dass Herr/Frau X am Mittwochnachmittag in drei Monaten für zwei Stunden und 15 Minuten benötigt wird (eine detaillierte Agenda sollte acht Wochen vorher versendet werden).
Derart detaillierte Projektpläne überleben den ersten Realitätskontakt nicht, und der Projektleiter beziehungsweise das Project Management Office sind permanent mit Umplanungen beschäftigt.
Ähnliches gilt für sehr langfristige Pläne: In unserer schnelllebigen Welt kann man nicht einfach davon ausgehen, dass ein S/4HANA Einführungsprojekt über einen Zeitraum von drei oder mehr Jahren die Top-Priorität im Unternehmen darstellt. In der Realität kommen immer wieder Krisen, Strategieprojekte, Mergers & Acquisitions und so weiter dazwischen, die mit Ihrem ERP-Projekt um Aufmerksamkeit und knappe Ressourcen konkurrieren.
Verabschieden Sie sich daher von der Idee, sehr detaillierte und langfristige Projektpläne zu erstellen. Wichtiger ist
- Die Definition eines Zielbilds (System- und Prozesslandschaft), das Sie mit dem ERP-Projekt erreichen wollen.
- Eine grobe Roadmap mit wichtigen Meilensteinen. Richten Sie sich aber auch darauf ein, dass diese Roadmap Veränderungen unterworfen sein wird.
- Ein detaillierter Projektplan für konkrete Teilprojekte und einen Zeitraum von maximal 12-18 Monaten.
- Die Vereinbarung mit der Fachseite
- von Projektkontingenten für die wichtigsten Ressourcen (z. B. 50% für einen Process Owner)
- von festen Projekttagen. Die inhaltliche Feinplanung der Workshops erstellen Sie für 1-2 Wochen im Voraus.
Wie erstellt man das Pflichtenheft für das S/4HANA-Projekt?
Alle Anforderungen an die umzusetzenden Prozesse und Abläufe werden im Pflichtenheft gesammelt. Die Erstellung ist jedoch selten so einfach, wie gedacht.
Die „Wasserfallmethode“ von Istanlayse über Sollkonzept bis zum Pflichtenheft
In der idealen „Wasserfallmethoden“-Welt ist das Projektleben ganz einfach: Nach einer Istanalyse und einem Sollkonzept wird ein Pflichtenheft erstellt und abgenommen. Dessen Anforderungen werden nie mehr verändert und die IT kann diese in Software umsetzen, die dann anhand des Pflichtenhefts getestet werden kann. Sollte es ausnahmsweise doch mal eine Änderung geben, dann ist das ein Change Request, der akribisch zu begründen und im Genehmigungsfall einzuplanen ist.
Soweit die Theorie. In der Praxis funktioniert das nur dann einigermaßen gut, wenn das neue ERP-System die Prozesse des Altsystems weitgehend unverändert übernimmt.
Da bei der S/4HANA-Einführung aber sinnvollerweise auch Prozessoptimierungen durchgeführt werden, fällt es der Fachseite zunehmend schwer, ein „wasserdichtes“ Pflichtenheft zu schreiben. Das liegt unter anderem an der zunehmenden Arbeitsverdichtung in den Fachabteilungen, welche die Projektarbeit zusätzlich zum Tagesgeschäft stemmen müssen. Dieser chronische Zeitmangel wirkt sich negativ auf die Detaillierung und Qualität der Anforderungen aus und ist die Wurzel vieler Änderungswünsche.
Häufig gibt es auch Kommunikationsprobleme zwischen Fachseite und IT, die schlicht keine gemeinsame „Sprache“ finden. Einerseits sollen sich Anforderungen so beschreiben lassen, dass die Fachseite einen Bezug zum Tagesgeschäft herstellen kann. Andererseits müssen die Anforderungen so formal klar sein, dass sie sich im ERP-System umsetzen lassen. Unklarheiten und Missverständnisse machen das Pflichtenheft zu einem „moving target“ für die IT mit entsprechenden Auswirkungen auf den Projektzeitplan und das Budget. Dabei gilt: Je später Änderungsbedarfe erkannt werden (im schlimmsten Fall erst in der Anwenderschulung), desto gravierender sind die Auswirkungen.
„Agile“ Vorgehensweise als Alternative?
Kann man angesichts dieser Problematik den Wasserfall-Ansatz nicht einfach beerdigen und stattdessen „agil“ vorgehen? Leider werden agile Projektmethoden wie zum Beispiel Scrum von der Fachseite häufig dahingehend missverstanden, dass man dabei überhaupt keine Anforderungen formulieren muss oder diese jederzeit ändern kann. Dem ist leider nicht so, außerdem müssen Sie bei agilen Projektmethoden akzeptieren, dass einer der folgenden Projektdimensionen variabel sein muss:
- Der Scope („wir arbeiten mit einer fixen Timeline und einem festen Budget und schauen mal, was dabei herauskommt“)
- oder die Timeline/das Budget („die Funktionalität ist vorgegeben, aber wir können nicht vorab sagen, wie lange es dauert und was es kostet“).
Das wird bei so gewichtigen Projekten wie einer S/4HANA-Implementierung in der Regel nicht akzeptabel sein.
Meine Empfehlungen richten sich daher darauf, die Qualität der Anforderungen zu verbessern und Änderungsbedarfe frühestmöglich zu erkennen:
- Jede zusätzliche Stunde, welche die Fachseite in das Sollkonzept investiert, zahlt sich in der Implementierungsphase doppelt aus.
- Verwenden Sie Prozessvisualisierungen, um eine gemeinsame Sprache zwischen Fachseite und IT zu finden. In der Praxis bewährt haben sich beispielsweise Swimlane Diagramme aus der der Business Process Modelling Notation (BPMN). Machen Sie keine Wissenschaft aus der Prozessmodellierung, sondern wählen Sie einen praxistauglichen Detaillierungsgrad (maximal 10-12 Funktionen pro Prozess, maximal 3 Prozesshierarchieebenen).
- Warten Sie keinesfalls die gesamte Implementierungsphase ab, bis Sie erstmals im Rahmen eines Anwendertests die Fachseite mit der Umsetzung ihrer Anforderungen in der ERP-Software konfrontieren. Planen Sie regelmäßige Präsentationen von Prototypen und Mock-Ups ein (Rapid Prototyping), holen Sie sich frühzeitig Feedback von der Fachseite ein und sehen Sie im Projektplan von vorneherein Puffer für Änderungen vor.
Nutzen und Grenzen von Best Practice und Cloud
Zu S/4HANA gibt es sowohl von SAP als auch von einigen Beratungsunternehmen Best Practices (Branchenreferenzprozesse). Auch die S/4HANA Public Cloud arbeitet mit Standardprozessen. Best Practices und Cloud-Lösungen werden damit beworben, dass mit der Nutzung die Projektlaufzeiten zur Einführung wesentlich verkürzt werden. Insbesondere eine Sollkonzeptphase fällt weitgehend weg, eine kurze Fit-Gap Analyse scheint ausreichend.
Aber eignen sich vordefinierte Standardprozesse für Ihr Unternehmen? Zur Beantwortung sollte man zunächst einmal die Unternehmensprozesse hinsichtlich ihrer Best Practice Eignung klassifizieren. Bewährt hat sich dabei die an Gartner angelehnte Methode:
Die als „Brot-und-Butter“ bezeichneten Prozesse bringen dem Unternehmen keinen Wettbewerbsvorteil. Häufig ergeben sie sich aus regulatorischen (Beispiel: Umsatzsteuervoranmeldung) oder administrativen (Beispiel Büromaterialbestellung) Erfordernissen. Für solche Prozesse ergibt es in der Tat Sinn, innerhalb eines ERP Systems Best Practice Prozesse oder die standardisierten Funktionen einer Cloud-Lösung zu nutzen (zum Beispiel für die Reisekostenabrechnung). Sie passen also Ihre Arbeitsanweise an das System an.
Für wettbewerbskritische Prozesse (z. B. Angebots- oder Serviceprozesse) ergibt Best Practice dagegen wenig Sinn, denn bei Nutzung von Best Practice Prozessen sind Sie per Definition genauso gut (oder schlecht) wie Ihr Wettbewerb. Hier lohnt es sich, das System an Ihre individuellen Prozesse anzupassen (sei es durch Konfiguration des ERP-Systems, durch die Nutzung von Add-On‘s/Programmerweiterungen oder durch die Anbindung von spezialisierten Fremdsystemen). Beachten Sie, dass bei jedem Unternehmen jeweils andere Prozesse wettbewerbskritisch sind (je nach Branche und unternehmensindividuellem Know-How und Stärken).
So genannte „Game-Changer“ Prozesse haben das Potenzial, die „Spielregeln“ in der Branche zu verändern oder neue Geschäftsmodelle zu kreieren (zum Beispiel im Umfeld „Internet of Things“ oder „Machine Learning“). Hierfür kommen keine Prozesse „von der Stange“ in Frage. Zudem wird man solche Prozesse zunächst einmal prototypenhaft außerhalb der naturgemäß etwas „trägeren“ ERP-Systeme implementieren, um schnell aus Versuch und Irrtum zu lernen.
Ist das S/4HANA-Implementierungsprojekt mit dem Go-Live beendet?
Wenn Sie Ihr Projekt nur bis zum Go-Live planen und sich die Projektorganisation unmittelbar danach auflöst, hat das Konsequenzen:
- Die Akzeptanz des neuen Systems bei den Anwendern wird schlecht sein, weil es für die naturgemäß anfangs auftretenden Probleme nur den regulären IT-Support gibt. Bedenken Sie, dass insbesondere die „Generation Smartphone“ mit Anwenderhandbüchern wenig anzufangen weiß.
- Wenn Anwender davon ausgehen, dass das Projekt nach dem Go-Live nicht mehr existiert, werden sie versuchen, alle denkbaren Anforderungen und Sonderprozesse in die Konzeptionsphase zu drücken, gemäß dem Motto „Jetzt oder nie!“.
Planen Sie daher bei der S/4HANA-Einführung von vorneherein eine Hypercare Phase mit einer verstärkten Unterstützung der Anwender durch die vertraute Projektorganisation ein. Sparen Sie lieber an Anwenderschulungen und Anwenderhandbüchern und investieren Sie besser in die Ausbildung von Key-Usern und Training on the Job.
Nach dem Go-Live sollte Sie Lessons Learned Workshops mit der Fachseite durchführen, deren Ergebnisse in ein Release 1.1 der ERP-Software einfließen. Planen Sie diese von vorneherein mit ein. Dadurch nehmen Sie den Druck aus dem Projekt, jeden exotischen Prozess zum Go-Live im S/4HANA-System abgebildet haben zu müssen.
2 Gedanken zu „Mythen bei ERP-Projekten: Vom Pflichtenheft bis zum Go-Live“
Da machen sich 30 Jahre Erfahrung bemerkbar.
Toller Beitrag!
Vielen Dank!