Systemeinführung

ERP-Mythen vom Pflichtenheft bis zum Go-Live

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.

Empfehlungen

• Jede zusätzliche Stunde, welche die Fachseite in das Soll-Konzept investiert, zahlt sich in der Implementierungsphase doppelt aus. Danach gilt es zu handeln.
• 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).
• 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

• Vor einem ERP-Projekt sollten die Geschäftsprozesse klassifiziert werden. Mindestens 80 Prozent der Prozesse sollten in die Kategorie Brot & Butter fallen.
• 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.

Empfehlungen

• Bei einer ERP-Einführung sollte es eine Phase geben, in der Anwender durch die vertraute Projektorganisation besonders intensiv unterstützt werden.
• Sinnvoll sind Lessons-Learned-Workshops mit den Fachabteilungen nach dem Go-Live. Die Ergebnisse sollten folgerichtig auch in Release 1.1 der ERP-Software einfließen.