ERP-Mythen vom Pflichtenheft bis zum Go-Live
Rund um die ERP-Einführung haben sich eine Reihe hartnäckiger Mythen gebildet. Zum Beispiel werden diese Systemintegrationen noch immer von vielen als reine IT-Projekte angegangen - der Mythos 1. Mit diesem und anderen Missverständnissen räumt dieser Artikel auf.
Bild: Pikon Deutschland AGDa ERP-Projekte teuer sind, benötigen Unternehmen einen Sponsor für das Projekt, möglichst aus dem Top-Management. Häufig gibt dieser dem IT-Leiter den Auftrag, einen Business Case für das Projekt zu rechnen.
Bild: Pikon Deutschland AG
Um diese Ziele zu erreichen, braucht man Expertise der Fachabteilungen im Projekt, und zwar nicht erst für das Schreiben des Pflichtenhefts. Sinnvollerweise wird die IT schon vor dem eigentlichen ERP-Projekt zusammen mit der Fachseite die 'Schmerzpunkte' des Unternehmens ermitteln und daraus die Ziele für das ERP-Projekt ableiten. Daraus ergibt sich dann mit dem Warum? des Projekts, ein sehr wichtiger Punkt bei der späteren Projektkommunikation.
Bild: ©Pixel-Shot / stock.adobe.comSpielregeln definieren
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 von Spielregeln, die unbedingt vom Top-Management mitgetragen werden müssen. Eine solche Spielregel kann 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 sogenannten Process Ownern in der Unternehmensorganisation nicht genug hervorgehoben werden. Ein ERP-Projekt braucht fachseitige Ansprechpartner und vor allem Entscheider, die Prozesse end-to-end weltweit definieren.
Empfehlungen @WK Einrückung:Ein fachseitiger Projektsponsor und ein fachseitiger Projektleiter sind unverzichtbar. @WK Einrückung:Die Projektziele sollten anhand der 'Pain Points' des Unternehmens in einem Vorprojekt definiert werden. @WK Einrückung:Eine gute Projektkommunikation erklärt nicht nur das Was und Wie, sondern vor allem das Warum. @WK Einrückung:Process-Owner sollten fest in die Unternehmensorganisation eingebunden sein. Mythos 2 - Detailplanung
als Garant für den Projekterfolg
Detaillierte Projektpläne überleben in der Regel den ersten Realitätskontakt nicht, und der Projektleiter bzw. das Project Management Office sind permanent mit Umplanungen beschäftigt. Ähnliches gilt für sehr langfristige Pläne. In dieser schnelllebigen Welt ist nicht einfach davon auszugehen, dass ein ERP-Projekt über einen Zeitraum von drei oder mehr Jahren die höchste Priorität im Unternehmen darstellt. In der Realität kommen immer wieder Krisen, Strategieprojekte, Mergers & Acquisitions und so weiter dazwischen, die mit dem ERP-Projekt um Aufmerksamkeit und Ressourcen konkurrieren.
Bild: Pikon Deutschland AGEmpfehlungen @WK Einrückung:Definition einer System- und Prozesslandschaft, die langfristig mit dem ERP-Projekt erreicht werden soll. @WK Einrückung:Entwurf einer groben Roadmap mit Meilensteinen. @WK Einrückung:Ein detaillierter Projektplan ergibt für konkrete Teilprojekte und einen Zeitraum von maximal 12 bis 18 Monaten Sinn. @WK Einrückung:Mit der Fachseite sollten Projektkontingente und feste Projekttage für die wichtigsten Ressourcen (etwa 50 Prozent für einen Process Owner) vereinbart werden. Mythos 3 - Niemals vom
Pflichtenheft anweichen
In der idealen Wasserfallmethoden-Welt ist das Projektleben ganz einfach: Nach einer Ist-Analyse und einem Soll-Konzept 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, die in der Praxis nur dann einigermaßen gut funktioniert, wenn das neue ERP-System die Prozesse des Altsystems weitgehend unverändert übernimmt. Tatsächlich sind bei ERP-Projekten Prozessoptimierungen sinnvollerweise eher Regel als Ausnahme. Dann aber fällt es der Fachseite zunehmend schwer, ein wasserdichtes Pflichtenheft zu schreiben. Das liegt u.a. 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, in der sich Anforderungen so beschreiben lassen, dass einerseits die Fachseite einen Bezug zum Tagesgeschäft herstellen kann und die andererseits so formal klar ist, dass sie sich in einer ERP-Software umsetzen lässt. Unklarheiten und Missverständnisse machen das Pflichtenheft zu einer Art beweglichem Ziel für die IT, mit entsprechenden Auswirkungen auf den Projektzeitplan und das Budget. Dabei gilt: Je später Änderungsbedarfe erkannt wird (ungünstigerweise etwa erst in der Anwenderschulung), desto gravierender sind die Auswirkungen. Die Empfehlungen sind daher darauf gerichtet, die Qualität der Anforderungen zu verbessern und Änderungsbedarfe möglichst früh zu erkennen.
Bild: ©Elnur/ stock.adobe.comEmpfehlungen @WK Einrückung:Jede zusätzliche Stunde, welche die Fachseite in das Soll-Konzept investiert, zahlt sich in der Implementierungsphase doppelt aus. Danach gilt es zu handeln. @WK Einrückung:Prozessvisualisierungen schaffen eine gemeinsame Sprache zwischen Fachseite und IT. In der Praxis bewährt haben sich Swimlane-Diagramme aus der Business Process Modelling Notation (BPMN). @WK Einrückung:Mit regelmäßigen Präsentationen von Prototypen und Mock-Ups während der Implementierungsphase erhält das Projekt frühzeitig Feedback von der Fachseite und erkennt Änderungsbedarfe schneller. Mythos 4 - Best Practice und
Cloud als Universallösung
Ist es überhaupt erforderlich, im Rahmen einer ERP-Einführung alle Prozesse mühsam zu analysieren und gegebenenfalls neu zu definieren? Wäre es nicht viel einfacher, Branchenreferenzprozesse eines Beratungsunternehmens oder des Softwareherstellers zu nutzen, oder die Standardprozesse einer Cloudlösung zu nutzen? Immerhin fiele dadurch eine Soll-Konzeptphase weitgehend weg, eine kurze Fit-Gap-Analyse würde reichen. Bei Nutzung von vorkonfigurierten Systemen oder Cloudlösungen versprechen zumindest deren Hersteller wesentlich kürzere Projektlaufzeiten im Vergleich zu klassischen ERP-Projekten. Bevor sich diese Frage beantworten lässt, sollten die Unternehmensprozesse hinsichtlich ihrer Best-Practice-Eignung klassifiziert werden. 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 oder administrativen Erfordernissen. Für solche Prozesse ergibt es in der Tat Sinn, innerhalb eines ERP-Systems Referenzprozesse oder die standardisierten Funktionen einer Cloudlösung zu nutzen. Man passt also die Arbeitsanweise an das System an. Für wettbewerbskritische Prozesse (etwa Angebots- oder Serviceprozesse) ergibt Best Practice dagegen meist wenig Sinn, denn bei Nutzung solcher Prozesse ist man per Definition genauso gut (oder schlecht) wie der Wettbewerb. Hier lohnt es sich, das System an die individuellen Prozesse anzupassen - sei es durch Konfiguration des Systems, durch die Nutzung von Add-Ons oder die Anbindung von Speziallösungen. Natürlich sind bei jedem Unternehmen andere Prozesse wettbewerbskritisch, je nach Branche, Know-how und individuellen Stärken. Sogenannte Game-Changer-Prozesse haben das Potenzial, die Spielregeln in der Branche zu verändern oder neue Geschäftsmodelle zu kreieren (etwa im Umfeld von Internet of Things oder Machine Learning). Hierfür kommen keine Prozesse von der Stange in Frage. Zudem werden solche Prozesse in der Regel zunächst einmal prototypenhaft außerhalb der naturgemäß etwas trägeren ERP-Systeme implementiert, um schnell aus Versuch und Irrtum zu lernen.
Empfehlungen @WK Einrückung:Vor einem ERP-Projekt sollten die Geschäftsprozesse klassifiziert werden. Mindestens 80 Prozent der Prozesse sollten in die Kategorie Brot & Butter fallen. @WK Einrückung:Best Practices sollten konsequent nur dort eingesetzt werden, wo ein unternehmensindividueller Prozess keinen Wettbewerbsvorteil bringt. Mythos 5 - Projekte enden
mit dem Go-Live
Wenn eine ERP-Integration nur bis zum Go-Live geplant wird und sich die Projektorganisation unmittelbar danach auflöst, hat das Konsequenzen: Zum einen könnte die Akzeptanz des ERP-Systems bei den Anwendern sinken, weil es für die anfangs auftretenden Probleme nur den regulären IT-Support gibt. Wenn Anwender davon ausgehen, dass das Projekt nach dem Go-Live nicht mehr existiert, könnten sie zudem versuchen, alle denkbaren Anforderungen und Sonderprozesse in die Konzeptionsphase zu drücken.
Rund um die ERP-Einführung haben sich eine Reihe hartnäckiger Mythen gebildet. Zum Beispiel werden diese Systemintegrationen noch immer von vielen als reine IT-Projekte angegangen - der Mythos 1. Mit diesem und anderen Missverständnissen räumt dieser Artikel auf.
Bild: Pikon Deutschland AGDa ERP-Projekte teuer sind, benötigen Unternehmen einen Sponsor für das Projekt, möglichst aus dem Top-Management. Häufig gibt dieser dem IT-Leiter den Auftrag, einen Business Case für das Projekt zu rechnen.Bild: Pikon Deutschland AG
Um diese Ziele zu erreichen, braucht man Expertise der Fachabteilungen im Projekt, und zwar nicht erst für das Schreiben des Pflichtenhefts. Sinnvollerweise wird die IT schon vor dem eigentlichen ERP-Projekt zusammen mit der Fachseite die 'Schmerzpunkte' des Unternehmens ermitteln und daraus die Ziele für das ERP-Projekt ableiten. Daraus ergibt sich dann mit dem Warum? des Projekts, ein sehr wichtiger Punkt bei der späteren Projektkommunikation.
PIKON Deutschland AG
Dieser Artikel erschien in IT&Production ERP CRM Wissen 2019 - 13.12.19.Für weitere Artikel besuchen Sie www.it-production.com
