Ist geplant, eine ERP-Software in einem mittelständischen Unternehmen einzuführen, bieten sich zwei grundlegende Strategien als Alternativen an: Ein agiles Vorgehen auf der einen Seite gegenüber einem klassischem Vorgehen auf der anderen Seite. Ist das Vorgehen für die gewählte Strategie formal beschrieben (und damit reproduzierbar), spricht man von einem „Vorgehensmodell“.
Klassische Vorgehensmodelle
Die bekannteren Einführungsstrategien, z.B. das „On-Target“ Vorgehensmodell für „Microsoft Dynamics NAV“ (vormals „Navision“) oder auch das für „SAP R/3“ entwickelte „ASAP“ (= „AcceleratedSAP“) Vorgehensmodell zählen zu den „klassischen“ Vorgehensmodellen.
Diesen und den anderen klassischen Vorgehensmodellen ist gemein, dass ein zeitlich linearer Projektablauf zu Grunde gelegt wird. Alle Phasen der Einführung laufen nacheinander ab, wobei je nach Modell ein Rücksprung in die unmittelbar vorhergehende Phase erlaubt ist. Ein klassisches Vorgehensmodell könnte sich grob in die folgenden Phasen gliedern, welche im Einführungsprojekt zeitlich nacheinander abgearbeitet werden.
Phasen eines „klassischen“ ERP-Einführungsprojektes:
- Vorbereitung und Organisation der Einführungsprojektes
- Detaillierte Analyse der Ist-Situation und Feinkonzept der Soll-Umsetzung
- Vollständige Anpassung der ERP-Software und Umsetzung von allen individuellen Erweiterungen (Customizing)
- Vollständige Umstellung auf die neue ERP-Software
- Betrieb der neuen ERP-Software sicherstellen
Jede dieser Phasen birgt je nach Projektumfang eine Vielzahl von Tätigkeiten und Risiken. Dabei ist nicht gesagt, dass die Umstellung simultan (als „Big-Bang“) umgesetzt werden muss; auch eine simultane (fließende) Umstellung ist hier dankbar.
Der wesentliche Punkt ist jedoch, dass jede dieser Phasen mit Ihren wesentlichen Ergebnissen zeitlich nacheinander erfolgt und sich gegenseitig bedingt. Damit ähnelt dieses Vorgehensmodell dem klassischen „Wasserfallmodell“ in der Softwareentwicklung und beinhaltet ähnliche Vor- und Nachteile.
Bewertung klassischer Vorgehensmodelle
Als wesentliche Vorteile können hier die klare, leicht verständliche Projektstruktur und (scheinbar) einfache Planbarkeit genannt werden. Insbesondere letzter Punkt ist jedoch gleichzeitig der wesentliche Nachteil dieses Vorgehens: Man muss bereits zu Beginn der Projektes (spätestens bei der Konzeption der Soll-Umsetzung) genau wissen, welche Anpassungen und individuellen Erweiterungen für die Umstellung gefordert sind.
Insbesondere in mittelständischen Unternehmen wird erfahrungsgemäß das Optimum erst während der Umsetzungsphase oder ersten Tests mit der neuen ERP-Software erkannt. Dieser Effekt wird oft durch eine gewisse „Unerfahrenheit“ mittelständischer Unternehmen in IT-Optimierung bzw. Softwareentwicklung verstärkt: Oft ist den fachlichen Beteiligten des Unternehmens zu Beginn des Projektes noch nicht klar, welches Optimierungspotenzial die ERP-Software bietet (oder eben nicht bietet) und wie das fertige Zielsystem aussehen könnte. (Stichwort: „Der Appetit kommt beim Essen.“)
Auf Grund dessen hat sich insbesondere bei kleinen und mittelständischen ERP-Anbietern in der Praxis ein flexibleres Vorgehen etabliert, welches keinen starren Projektplan zu Grunde legt. Ohne dabei ein durchdachtes, flexibles Vorgehensmodell anzuwenden, verbirgt sich hier jedoch das Risiko das Projekt unstrukturiert oder chaotisch (= ohne Plan) durchzuführen. Der Projekterfolg hängt in diesem Fall stark von den Persönlichkeiten der Projektbeteiligten ab und lässt sich schwer reproduzieren bzw. voraussagen.
Agile Vorgehensmodelle
In der Softwareentwicklung und bei der Produktentwicklung anderer Branchen gibt es ähnliche Probleme. Um diese zu lösen wurden in den Vergangen rund 20 Jahren verschiedene, sog. „agile“ Vorgehensmodelle entwickelt, um diese Risiken zu minimieren und den Projekterfolg reproduzierbar zu machen. Eben dieses strukturierte und doch flexible Vorgehen lässt sich auch in ERP-Einführungsprojekte einsetzen. Man spricht dann von einem „agilen“ Vorgehen, welches im Folgenden detaillierter beschrieben wird.
Der Begriff „agil“ kommt aus dem lateinischen und kann auch den englischen Begriff „agile“ abgeleitet werden. Er steht für „flink, gewandt“. In der Softwareentwicklung werden agile Vorgehensmodelle bereits seit Jahren erfolgreich eingesetzt. Zu den bekanntesten zählen hier sicherlich „SCRUM“ von der Scrum Alliance oder der „Rational Unified Process“ (RUP) von IBM. SCRUM und RUP beschreiben Projektmanagementmodelle, welche sich nicht nur für die Softwareentwicklung eignen und die ursprünglich auch eine andere Zielstellung verfolgt haben (z.B. wird SCRUM für die Produktentwicklung beliebiger Produkte eingesetzt).
Diese agilen Vorgehensmodelle beschreiben somit strukturierte (also ganz und gar nicht chaotische) Ansätze zum flexiblen Erreichen eines Endergebnisses (z.B. einer fertig ausgelieferten ERP-Software).
Diese Flexibilität wird durch die folgenden wesentlichen Elemente erreicht:
- Analyse, Anpassung und Umstellung in mehreren kleinen Phasen (sog. „Iterationen“)
- Zerlegen des Einführungsprozesses in kleine Phase (Iterationen) zur Reduzierung der Komplexität
- Unmittelbarer Test und Feedback zum neuen ERP-System am Ende jeder Iteration
- Verbesserung der neuen ERP-Software bzw. der Geschäftsprozesse mit jeder Iteration
Phasen eines „agilen“ ERP-Einführungsprojektes:
- Vorbereitung und Organisation der Einführungsprojektes
- Grobe Analyse der Ist-Situation und Konzeption einer groben Soll-Umsetzung
- Planung der folgenden Iterationen und deren grobe Inhalte, vor allem der umzusetzenden Teile des
- Ziel-ERP-Systems je Iteration
- Iteration 1 – (es wird immer nur ein Teil des ERP-Systems betrachtet)
- Analyse der Ist-Situation und des Benutzer-Feedbacks [ab Iteration 2]
- Soll-Konzeption des Ziel-ERP-Systemteils
- Anpassung der ERP-Software und Umsetzung von individuellen Erweiterungen (Customizing) für den betrachteten Teil
- Test-Umstellungen auf die neue ERP-Software
- Benutzer-Feedback sammeln und analysieren
- Iteration 2 bis n
- wie Iteration 1, bis der geplante Soll-Zustand erreicht ist und/oder keine weitere Optimierung geplant/gewünscht ist
- Finale Umstellung auf die neue ERP-Software
- Betrieb der neuen ERP-Software sicherstellen
Bewertung agiler Vorgehensmodelle
Wie bereits erwähnt, wird dieser Prozess in dieser oder einer ähnlichen Form in der Praxis gerade in kleineren ERP-Einführungsprojekten oft implizit von den ERP-Anbietern angewendet. Die implizite, also relativ ungeplante, Anwendung birgt jedoch oben beschriebene Risiken, u.a. ein chaotische Vorgehen und schwere Planbarkeit des Ergebnisses. Ein ungeplantes Vorgehen ist nicht agil, sondern chaotisch!
Ziel der agilen Vorgehensmodelle ist somit dieses Vorgehen als expliziten Prozess zu definieren. In diesen Modellen wird u.a. der iterative Prozess, die Rollen der Beteiligten, der Fokus einzelner Iterationen, die Einflussnahmemöglichkeiten des Kunden, sowie die Messbarkeit der Ergebnisse beschrieben.
Insgesamt ist der Prozess strukturiert, die Ergebnisse für den Kunden planbar und es wird Transparenz im Einführungsprozess geschaffen sowie ein optimales Ergebnis erreicht (und darum geht es letztendlich).
Vergleich der Vorgehensmodelle
In einer Gegenüberstellung der beiden Vorgehensmodelle, zeigt sich, dass das klassische Vorgehen umso besser geeignet ist, je klarer allen Beteiligten die konkrete Ausgestaltung des Ziel-ERP-Systems ist und je weniger Komplex das Einführungsprojekt ist. Je mehr sich die optimale Lösung erst im Umsetzungsprozess herauskristallisiert und je komplexer der Einführungsprojekt ist, desto mehr Stärken finden sich beim agilen Vorgehen zu ERP-Einführung.
Insbesondere wenn keine simultane Big-Bang Umstellung geplant ist (wenn z.B. Abteilungsweise umgestellt wird oder einzelne Programmteile nach und nach in Betrieb genommen werden), sollte tendenziell ein agiles Vorgehensmodell gewählt werden.
Beiden Vorgehensmodellen ist gemein, dass es sich um „Modelle“ handelt, also die idealtypische Beschreibungen eines Vorgehens, sowie die Bereitstellung von Werkzeugen und Hilfsmitteln, welche in Einführungsprojekten angewendet werden können. Auch die Zielstellung ist sehr ähnlich.
Die Vorgehensmodelle unterscheiden sich jedoch in ihrer praktischen Umsetzung im Projektablauf gravierend. Es wird mit einer grundlegend unterschiedlichen Methodik versucht ein ähnliches Ergebnis zu erreichen (klassische, ingenieurmäßige Feinplanung vorab versus agile, flexible Optimierung der Ergebnisse im Projektablauf).
Welches Vorgehensmodell gewählt wird, sollte in der Praxis von dem Projektkontext, dem Kunden, dem ERP-Anbieter und der Zielstellung abhängig gemacht werden.
Die Anwendung irgendeines Vorgehensmodells zur ERP-Einführung ist in jedem Fall zu empfehlen!
Diesen Artikel und mehr zum Thema ERP-Einführung finden Sie auch auf erpmanager.de.
Details zu diesem Thema, sowie weitere Grundlagen und Literatur zur ERP-Einführung finden Sie natürlich auch in dem Buch “Vorgehensmodell zur ERP-Einführung in kleinen und mittelständischen Unternehmen (KMU). Ein Modell aus der Perspektive eines Softwarehauses” (ISBN 978-3-638-94778-7).