Nutzung agiler Methoden bei ERP-Projekten
In vielen IT-Beratungsgesellschaften und Systemhäusern wird bereits mit agilen Projektmethoden gearbeitet. Dagegen tun sich jedoch viele Anwenderunternehmen mit den modernen Methoden schwer. Sie nutzen bisher die klassische Form des Projektmanagements. Nur einzelne Unternehmen versuchen, ein agiles Projektmanagement bei ihren ERP-Projekten durchzuführen bzw. gemeinsam mit den ERP-Anbietern zu nutzen. Im Folgenden werden die Unterschiede zwischen der klassischen und agilen Methode dargelegt und anhand eines Beispiels aus der Praxis aufgezeigt, wie agiles Projektmanagement auch auf der Seite des Anwenderunternehmens genutzt werden kann.
Bei ERP-Projekten besprechen in der Regel der Implementierungspartner und das Anwenderunternehmen die geeignete Projektmethodik. Meistens schlägt der ERP-Partner eine Methode vor, die jedoch auch abhängig vom Anwenderunternehmen ist. In der Vergangenheit basierten diese Methoden häufig auf dem Wasserfallmodell. Seit einigen Jahren werden jedoch auch die agilen Methoden genutzt bzw. Mischformen im Projektmanagement angewandt.
Wasserfallmethode (klassisches Vorgehen)
Das Wasserfallmodell zeichnet sich durch seine hohe Bekanntheit und seine Einfachheit aus. Grundsätzlich wird erst die nächste Stufe begonnen, wenn die vorhergehende Stufe beendet ist. Jede Anforderung, die in der Software umgesetzt werden soll, beschreitet die vorgegebenen Schritte. Die Anforderung wird genau aufgenommen und es erfolgt die Erstellung einer Lösungsspezifikation. Auf Basis des Lösungsdesigns wird die Lösung entwickelt und in ein Testsystem implementiert. Es folgen der Komponenten- und Integrationstest, bevor die Umsetzung ins Echtsystem implementiert wird. Da diese Schritte aufeinander aufbauen, kann ein Umsetzungspunkt nur nach Abschluss der vorherigen Stufe in die nächste Stufe gelangen; die Phasen werden also nacheinander durchlaufen.
Diese Wasserfallmethode hat grundsätzlich folgende Vor- und Nachteile:
+ Einerseits hat dieses Vorgehen für viele Anwender den Vorteil, dass die Phasen klar abgegrenzt sind.
+ Grundsätzlich (theoretisch) ist auch eine gute Kosten- und Zeitplanung möglich.
+ Außerdem ist eine Kontrolle der Aufgaben und Zielerreichung gut möglich.
+ Gute Möglichkeit bei klar definierten und feststehenden Anforderungen.
– Andererseits können in der Praxis Phasen verschwimmen bzw. zusammenlaufende, parallellaufende Anforderungsumsetzungen befinden sich in unterschiedlichen Phasen.
– Es treten häufig Schwierigkeiten auf, wenn eine Umsetzung eine Stufe zurückgestuft wird bzw. zurückgestuft werden muss.
– Anforderungen müssen zu einem sehr frühen Stadium sehr exakt festgeschrieben werden.
– Der Anwender benötigt eine große Abstraktionsfähigkeit, um ggf. den Erläuterungen des Consultants folgen zu können.
– Unflexibel bei kurzfristigen Änderungen der Anforderungen.
– Insgesamt existiert ein sehr hoher Aufwand in der Aufnahme- und Konzeptionsphase. Viel Budget für nicht sichtbare Ausgaben.
Der Schwachpunkt des Wasserfallmodells besteht vor allem darin, dass ggf. eine lange Zeit entwickelt wird, bevor ein sichtbares Ergebnis vorliegt. Anwender beschreiben in der Regel (vor allem am Anfang eines ERP-Projektes) häufig nur den IST-Zustand und ggf. noch einzelne Wünsche. Da das ERP-System nicht bekannt ist, kommen auch keine Ideen auf, was in einer Software möglich ist. Die Anforderungen entwickeln sich während des Projektes aufgrund der Kenntnis der Anwendung und der internen Diskussionen. Der Stand der Anforderungen und damit auch die gestarteten Umsetzungen sind jedoch Stand der Anforderungsaufnahme bei Projektbeginn. Dadurch kann es passieren, dass lange Zeit an den gewünschten Ergebnissen vorbei entwickelt worden ist. Im schlimmsten Fall fallen diese Differenzen erst zu einem späteren Zeitpunkt des Projektes auf.
Bild 1: Wasserfallmodell. (Quelle: frigger-consult)
Agiles Vorgehen
Bei dem agilen Vorgehen handelt es sich um einen iterativen Ansatz. Das Anwenderunternehmen soll schnellstmöglich einen Mehrwert durch mögliche Anpassungen etc. erhalten. Eine Iteration ist hierbei das wiederholende Durchlaufen einzelner (Entwicklungs-)Schritte; d. h., innerhalb einer Phase können einzelne Entwicklungsschritte beliebig wiederholt werden.
Einzelne Umsetzungen werden nicht auf einen Schlag ausgeliefert, sondern es werden kleinere, nutzbare Teilobjekte ausgeliefert. Somit können die Anwender sehr schnell die umgesetzten Punkte testen und ggf. gegensteuern. Dadurch wird vermieden, dass lange Zeit an der Realität vorbei entwickelt wird.
In der agilen Entwicklung testet der User regelmäßig, da permanent neue Teile des Produktes geliefert werden. Die Erfahrungen des Users beim Ausprobieren helfen den Entwicklern wiederum, das schlussendlich „richtige“ Produkt zu liefern.
Damit ist der Anwender/Key-User aber auch viel schneller im Projekt und in der Software – „er denkt in der Software“.
Grundsätzlich hat die agile Vorgehensweise folgende Vor- und Nachteile:
+ Die Erfahrung zeigt, dass die Entwicklungszeiten für die Umsetzungen kürzer sind als bei dem Wasserfallmodell.
+ Schnellerer, praxisorientierter Einstieg für alle Beteiligten.
+ Anforderungsänderungen können laufend berücksichtigt werden.
+ Schnellere Lernkurve aller Beteiligten.
– Häufigere Kommunikation zwischen Entwickler, Consultant und Key User notwendig.
– Mehr Zeitaufwand für die Key User.
– Viele Personen sprechen von „zu viel Hin und Her“, bis es zu einer Lösung kommt.
Das Problem der Abstraktionsfähigkeit bleibt zumindest zum Teil bestehen; d. h., User sehen nur rudimentäre Anpassungen und können sich die finale Lösung nicht vorstellen, jedoch besser und schneller als bei dem Wasserfall-Ansatz.
Bild 2: Ablauf im agilen Vorgehen. (Quelle: frigger-consult)
Nutzung agiler Methoden bei Krisenprojekten
Insgesamt gibt es bei der Auswahl der Projektmethode kein „richtig“ oder „falsch“. Als gute und erfolgreiche Lösung hat sich jedoch die agile Methode bei kriselnden ERP-Projekten erwiesen. So konnte mithilfe der agilen Projektmethode eine ERP-Implementierung bei einem Produktionsunternehmen erfolgreich abgeschlossen werden. Vorher wurden die klassischen Schritte der Wasserfallmethode durchgeführt. Nach dem Lasten- bzw. Pflichtenheft wurde programmiert und nach einiger Zeit getestet. Dieses Vorhaben erstreckte sich insgesamt über mehrere Monate, verzeichnete allerdings wenig Erfolg. Durch die Änderung der Projektmethode hin zu mehr Agilität wurden die Fehler schneller gefunden, die Tests waren intensiver und näher an einzelnen Anforderungspunkten.
Die Key User waren ebenfalls näher an der Anwendung, auch wenn sie deutlich mehr Zeit in das Projekt investieren mussten. Insgesamt kam diese Intensität jedoch sehr gut bei den Anwendern an, zumal auch recht schnell positive Testergebnisse vorlagen.
Auch der ERP-Implementierungspartner konnte mit dem schnellen und iterativen Ansatz seine Performance verbessern. Die Kommunikation zwischen Dienstleister und Anwenderunternehmen wurde zunehmend fachlicher und besser. Insgesamt konnte damit das Projekt gerettet und in einer angemessenen Zeit doch noch ein Echtstart durchgeführt werden.
Fazit
Beide Methoden haben Vor- und Nachteile, sind aber auch stark abhängig von dem ERP-Partner und dem Anwendungsunternehmen. Die entscheidenden Fragen sind hierbei, inwieweit die Kapazitäten zur Umsetzung neuer, agiler Methoden vorhanden sind und wie viel Zeit die Key-User und Anwender für das ERP-Projekt aufwenden können.
Denkbar sind grundsätzlich auch Mischformen; die Art und Weise, wie diese Mischform umsetzbar ist, hängt von den handelnden Personen und vom Stand des Projektes ab. In der Praxis sind diesbezüglich folgende Punkte erkennbar:
- Das eigentliche ERP-Einführungsprojekt wird mit der klassischen Wasserfall-methode durchgeführt, bei einem Scheitern jedoch auf ein agiles Vorgehen umgestellt.
- Die Wasserfallmethode dient häufig als „Sündenbock“ für die Differenz zwischen Anforderungsbeschreibung und Umsetzungsprogrammierung.
- Die Komplexität der Anforderungsumsetzung soll durch die agilen Methoden verringert werden.
- Die Softwareentwickler leben eher in der agilen Welt.
- Andererseits ist ein ERP-Projekt kein Softwareentwicklungsprojekt im eigentlichen Sinne.
- Der Fokus liegt weniger auf der gesamten Unternehmensbetrachtung; es empfiehlt sich deshalb, gesondert auf End-to-end-Prozesse einzugehen.
Peter Frigger beschäftigt sich seit vielen Jahren mit der Einführung und Aktualisierung von Unternehmenssoftware (sog. Enterprise Resource Planning). Er unterstützt namhafte Unternehmen unterschiedlicher Branchen bei der Auswahl, Einführung und Aktualisierung von ERP-Lösungen. In seinem Buch „ERP-Projekte erfolgreich managen“ gibt Peter Frigger anhand von praxisrelevanten Beispielen wertvolle Tipps.
Peter Frigger
Frigger-consult
Rhynerberg 31
59069 Hamm
E-Mail: info@frigger-consult.de
Web: www.frigger-consult.de