Archiv der Kategorie: Projektmanagement

Projektmanagement der ERP-Einführung

Typisches Vorgehen zur ERP-Einführung im Mittelstand

Schreibe eine Antwort

Für die ERP Einführung im Mittelstand werden zwei grundsätzliche Strategien vorgeschlagen, eine klassische und eine agile. Sie haben beide ihre Vorzüge, die klassische Vorgehensweise ist erprobt, die agile trägt den unterschiedlichen Lösungsansätzen auf dem ERP Markt Rechnung. Daher muss der Mittelstand über das Vorgehen bei der ERP Einführung nach Art der verwendeten Software entscheiden.

Klassische ERP Einführung im Mittelstand

Die Softwareanbieter haben eigene Strategien parat, Microsoft zum Beispiel On-Target, SAP das ASAP-Modell. Beide zählen zu den klassischen Modellen. Grundsätzlich wird hierbei ein linearer Projektablauf vorausgesetzt, obgleich es in der Praxis häufig Überschneidungen gibt. Der Rücksprung in eine vorhergehende Phase ist ohnehin erlaubt. Die Phasen gliedern sich grob wie folgt:

  • Vorbereitung und Organisation
  • Analyse der Ist-Soll-Situation
  • Customizing, das heißt Anpassung der ERP-Software an individuelle Bedürfnisse
  • Vollständige Umstellung des Unternehmens auf die neue Software
  • Sicherstellung des Betriebes der neuen ERP-Software

Es ist denkbar, bei der klassischen ERP Einführung im Mittelstand fließend vorzugehen, etwa im Verlauf von vier Wochen. Die Unternehmen streben allerdings die Simultan-Umstellung an (Big Bang), was rein datentechnisch Vorteile hat, um nicht in parallelen Datenbanken zu arbeiten. Hierbei können schnell Verluste auftreten. Wesentlich an der klassischen Umstellung ist der zeitlich nacheinander folgende Ablauf einzelner Schritte, also ein kaskadierender Verlauf, wie er aus der Softwaremodellierung bekannt ist. Die Projektstruktur bleibt dabei übersichtlich, das ist ein klarer Vorteil. Es muss allerdings schon bei der Vorbereitung des Projektes sehr klar definiert sein, welche Projektschritte zu welchem Zeitpunkt – unter welchen betrieblichen Umständen – abgeschlossen sein müssen.

Agile Vorgehensmodelle

Bei diesem Vorgehen innerhalb der ERP Einführung im Mittelstand wird ein hoch flexibles, wenn auch strukturiertes Modell angewandt. Agil heißt flink oder gewandt, in der Softwareentwicklung haben sich einige Verfahren als Standard etabliert wie SCRUM (Scrum Alliance) oder RUP (Rational Unified Process) von IBM. Die wesentlichen Elemente sind hierbei:

  • Analyse und Anpassung in Iterationen (mehrere kleine Phasen)
  • Zerlegen des Einführungsprozesses in Iterationen zu Reduzierung von Komplexität
  • Jeweils zum Ende einer Iteration ein unmittelbarer Test mit Feedback zum ERP-System
  • Anschließende Verbesserung der ERP-Software oder Anpassung der Geschäftsprozesse

Auch die agile ERP-Einführung läuft in Phasen ab, die mit denen der klassischen Einführung nahezu identisch sind. Der Unterschied besteht in den Iterationen, die einem Versuch-und-Irrtum-Vorgehen ähneln. Jedes Mal, wenn ein Teilschritt abgeschlossen ist, wird dessen Ergebnis erprobt. Dabei werden, im Gegensatz zur klassischen Einführung, kaum Rückschritte nötig, es wird jeweils nur die einzelne Phase verifiziert.
Wofür sich ein Unternehmen aus dem Mittelstand bei der ERP Einführung entscheidet, hängt neben der Software auch vom Personal ab. Es gibt Firmen, in denen die klassische Step-by-step-Methode eindeutig besser geeignet ist.

Details zu diesem Thema, sowie weitere Grundlagen und Literatur 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).

Wie steuere ich meinen (ERP) Software-Implementierer?

1 Antwort

Dieser Artikel möchte Ihnen eine kurze Einführung in verhaltensbasierte Denk- und Lösungsansätze bieten, um nachzuforschen warum es möglicherweise in einem (ERP-) Implementierungsprojekt hakt (und dass, obwohl Sie ein perfektes Projektmanagement aufgesetzt haben und eine dezidiertes Qualitätsmanagement betreiben), als auch einige Lösungsansätze bieten, um genau diese Herausforderungen kollaborativ zu lösen.

Im Fokus dieses Artikels steht also die Frage, wie ich (als Kunde) meinen ERP-Software-Implementierer (den Dienstleister) einvernehmlich steuere. Dem voran werden die Fragen diskutiert, warum und wann ein Dienstleister überhaupt gesteuert werden kann und muss.

Warum steuere ich meinen ERP-Implementierer?

Die platte Antwort lautet: „Damit er das liefert, was er soll und zwar in der Qualität die ich mir wünsche.“ Stellt sich also die Frage, ob der Dienstleister das nicht sowie macht, schließlich wurde ja alles vertraglich vereinbart… oder nicht?

Klar ist, dass nicht jedes Detail vertraglich geregelt werden kann. Das ergibt sich allein schon aus der schlichten Tatsache, dass das aufgrund des ernorm hohen Aufwands nicht möglich ist (und oft auch nicht sinnvoll). Daraus ergibt sich also eine gewisse „Unschärfe“ in der Lieferung. Diese „Unschärfe“ ist die Diskrepanz zwischen der Erwartung eines Kunden und der tatsächlichen Lieferung eines Dienstleisters. Das bezieht sich auf alle Lieferdimensionen: Inhalt, Qualität, Zeit und Budget. Wobei die letzteren beiden Punkte (vor allem der letzte) meist vertraglich recht klar geregelt sind. In der Praxis zeigt sich, dass auf Grund dessen tendenziell die ersten beiden Punkte (Inhalt und Qualität) leiden.

Ziel einer einvernehmlichen Steuerung ist in den Bereichen Inhalt und Qualität diese „Unschärfe“ rechtzeitig erkennen und die daraus entstehenden Konflikte gemeinsam zu lösen.

Wann steuere ich meinen ERP-Implementierer?

Ganz einfach: Vom ersten bis zum letzten Tag, an dem der Dienstleister tätig ist. Das beginnt bei der Anforderungsdefinition oder den Antworten auf die Ausschreibung über die Implementierungsphase bis hin zum Go-Live und auch in die spätere Support-Zeit. Konflikte auf Grund o.g. „Unschärfe“ zwischen Erwartung und Erfüllung werden Sie immer finden.

Wie steuere ich meinen ERP-Implementierer?

Diese Frage ist jetzt nicht mehr so klar zu beantworten. Der typische Berater würde wohl sagen: „Das kommt ganz darauf an…“

… denn Sie sollten zunächst klären, wo die Ursache des Problems (sprich: des Konfliktes) liegt. Diese ist nicht immer eindeutig: Von den Symptomen (verspätete Lieferung, mangelnde Qualität, etc.) kann man nicht immer auf die Ursachen und somit auch nicht auf die angemessene Lösung schließen.

Die folgenden zwei Schritte werden Ihnen hier ein paar Ideen und Lösungsansätze an die Hand geben:

Schritt 1: Finden Sie die Ursache

Abgesehen von den anfangs genannten Praxiserfahrungen, sollten Sie sich zunächst vor Augen halten, dass der Dienstleister normalerweise Ihre Erwartungen erfüllen will. Er möchte natürlich, dass Sie mit seinen Leistungen und Lieferungen hochzufrieden sind. Schließlich möchte er weiterhin mit Ihnen Geschäfte machen und ist besonders im mittelständischen ERP-Bereich auf Ihre Empfehlungen und Referenz angewiesen. In einer optimistisch-positiven Grundhaltung sollte man also immer davon ausgehen, dass kein Dienstleister „schlecht“ liefern will.

Wenn die Erwartungen dennoch nicht erfüllt werden, kann dies verschiedene Gründe haben, die Sie erforschen sollten. Ansonsten ziehen Sie u.U. falsche Schlüsse und die angewendete Steuermethodik greift nicht.

Hier ein paar typische Gründe, warum Ihre Erwartungen (also die des Kunden) nicht (voll) erfüllt werden:

  • Die Kundenerwartungen wurden nicht klar genug, nicht detailliert genug oder unvollständig kommuniziert.
  • Die Kundenerwartungen wurden falsch oder anders verstanden, als sie gemeint waren.
  • Der Kunde hat implizite Annahmen, die in seinem Tagesgeschäft selbstverständlich sind – für den Lieferanten jedoch abwegig (oder umgekehrt).
  • Beim Dienstleister mangelt es an fachlichem Know-how zum Verständnis der Anforderungen (oder dem Kunden das zur klaren Formulierung).
  • Beim Dienstleister mangelt es an technischem Know-how oder der Kreativität zur zufriedenstellenden Umsetzung der Anforderungen.
  • Dem Dienstleister mangelt die Methodik und/oder des Wissen zum Know-how Transfer (z.B. vom eigenen fachlichen Experten zum technischen Entwickler).
  • Dem Dienstleister mangelt es an Methodik und/oder Wissen zum Prüfen seiner Lieferqualität und/oder seiner Entwicklungsprozesse.
  • Dem Dienstleister fehlt es an Mitarbeitern zur Umsetzung in gewünschter Qualität oder Zeit.
  • Dem Dienstleister fehlt ein gutes Projektmanagement und/oder Methodik, um sein (ausreichenden) Ressourcen sinnvoll einzusetzen und zu verteilen
  • Kunde und Dienstleister finden keine gemeinsame Kommunikationsbasis (reden aneinander vorbei) oder keinen klaren Arbeitsmodus (arbeiten aneinander vorbei) etc.

Sie finden in Ihrer eigenen Praxiserfahrung oder einschlägiger Projektmanagement- und Softwareentwicklungsliteratur sicherlich noch viele andere Gründe, die allesamt keine „Böswilligkeit“ oder „Unfähigkeit“ der einen oder anderen Seite darstellen.

Wichtig ist nur, dass Sie versuchen, sich klar darüber zu werden, woran es hakt bzw. was die Ursachen sind. Im Folgenden finden Sie ebenso einige Lösungsansätze in Form von Steuerungsmethodiken, die Sie dementsprechend auf Ihre Situation übertragen können.

Schritt 2: Finden Sie eine Steuerungsmethodik

Eines Vorweg: Wie Sie an o.g. Gründen sehen, sind die Ursachen für die „Unschärfe“ nicht immer beim Dienstleister zu suchen. Prüfen Sie also, auch ob es nicht in Ihrem eigenen Unternehmen (oder bei sich selbst) Steuerungsbedarf gibt.

Im Folgenden wird nicht auf allgemeine Grundlagen und Werkzeuge des klassischen oder agilen Projektmanagements oder die notwendige fachlichen Qualitätssicherung eingegangen. Im Fokus stehen verhaltensbasierte Lösungsansätze zur Lösung und/oder Vermeidung (also Steuerung) von Konflikten, welche sich typischer Weise in einem ERP-Implementierungsprojekt ergeben können.

Kollaboration vs. Eskalation

In einem ERP-Implementierungsprojekt ziehen alle an dem gleichen Strang (wie oben beschrieben). Daher sollten Sie grundsätzlich versuchen Konflikte kollaborativ zu lösen. Das bedeutet…

  1. Konflikte zu erkennen (nicht nur persönliche, sondern auch Zielkonflikte z.B. zwischen hoher Qualität und zu engem Zeitplan),
  2. Konflikte offen und pro-aktiv anzusprechen und
  3. Konflikte vernehmlich auf Arbeitsebene bzw. im angemessenen Rahmen zu lösen. Teilweise wird dies am besten in einem persönlichen 1:1 Gespräch möglich sein, teilweise eher kreativ in der gemeinsamen Projektgruppe.

Dieses Vorgehen hat ganz klar seine Grenzen. Insbesondere Budget-getriebene Zielkonflikte lassen sich trotz aller Kreativität nicht immer auf Arbeitsebene lösen. Es könnte z.B. notwendig werden, weitere Mitarbeiter einzusetzen, die auf der einen oder anderen Seite den Budget-Rahmen sprengen. Auch kann es passieren, dass trotz aller gemeinsamen Bemühungen die Lieferqualität nicht ausreichend ist. In diesen und anderen Fällen kann eine Eskalation eine sinnvolle Alternative sein, z.B. zur Gesamtprojektleitung, einem Projektsteuerungsgremium oder auch der Geschäftsführung.

Eine zu häufige (und unnötige) Eskalation kann leicht zu einem Überdruss der Beteiligten oder auch zu einem Gewohnheitseffekt führen. Wenn während der Projektlaufzeit ein oder zweimal zur Geschäftsführung eskaliert wird, kann das eine starke Wirkung entfalten. Telefonieren die Geschäftsführer von Kunde und Dienstleister aber täglich wegen irgendwelcher Probleme, ist hier kaum noch eine Wirkung zu erwarten.

Wichtig ist, dass Konflikte (auch unangenehme) nicht ignoriert oder stillschweigend toleriert werden. In der Regel wird der Konflikt dann doch von sich aus eskalieren – und das meist zum ungünstigsten Zeitpunkt…

Bezogen auf die o.g. Ursachen bewegen wir uns hier im Bereich der „Kommunikation“ aber auch von „Ressourcenengpässen“, „Verständnisproblemen“ oder nicht erfüllten Erwartungen.

Positive vs. negative Motivation

Hier geht es um die Frage, ob ein Kunde zum Erreichen bestimmter Ziele (sprich: zur Erfüllung bestimmter Erwartungen) versucht, den Dienstleister positiv oder negativ zu beeinflussen. Bei einer positiv-optimistischen Grundhaltung ist sicherlich die positive Motivation vorzuziehen.

Im Falle der positiven Motivation werden Dienstleister oder auch den Projektmitgliedern eine positive Konsequenz (sprich: eine Belohnung) in Aussicht gestellt, falls bestimmte Ziele oder Erwartungen erreicht werden. Z.B. ein Bonus für die zeitgerechte Auslieferung oder eine sehr niedrige Fehlerrate.

Jedoch hat auch die positive Methodik Grenzen, z.B. wenn trotz aller Versuche, positiver Motivation und klarer Kommunikation, keine Qualitative Steigerung bei den Lieferungen zu sehen ist. Der Grund könnte z.B. sein, dass die Geschäftsführung des Dienstleisters schlicht zu wenige (teuere) Tester einsetzt. Bevor hier jedoch zur negativen Motivation gegriffen wird (z.B. mit einem Verweis auf die festgelegte Liefqualität und möglichen Schadenersatz), müssen erst die Ursachen klar sein: Beiden Varianten, positive und negative Motivation, funktionieren nur, wenn der Dienstleister überhaupt in der Lage ist, die Erwartung zu erfüllen. Z.B. müsste ein Dienstleister in der Kürze der Zeit überhaupt in der Lage sein, benötigtes Know-how aufzubauen oder einzukaufen.

Bezogen auf die o.g. Ursachen bewegen wir uns in den Bereichen „Termin- oder Qualitätserfüllung durch Ressourceneinsatz“ oder anderen budgetlastigen Themen, die sich nicht auf Know-how oder Fähigkeiten des Dienstleisters beziehen. Z.B. der weg brechenden Marge eines Dienstleisters durch Qualitätsprobleme.

Coaching des Dienstleisters

Hier geht es um das Coaching (oder Training) des Dienstleisters durch den Kunden. Hier handelt es sich ganz klar um ein kollaboratives Konzept: Im Fokus steht der Projekterfolg mit allen Mitteln. Dazu zählt auch, dass der Kunde bereit ist, den Dienstleister in Bereichen zu coachen, in denen dieser Schwächen in Know-how oder Methodik hat – und das auch, wenn das zu Projektbeginn nicht abzusehen war.

Das Coaching des Dienstleisters erfüllt hier mehrere Aufgaben:

  • Es löst einen möglichen Konflikt einvernehmlich und ohne großen Aufwand. Also einen Konflikt, der weder durch Eskalation noch Motivation ohne Weiteres lösbar wäre.
  • Mit der Vermittlung von Methodik und/oder Know-how wird es unmittelbar für den Dienstleister leichter, die Kundenerwartungen zu verstehen und zu erfüllen. Somit wird die „Unschärfe“ verringert.
  • Es handelt sich um eine präventive Maßnahme. Ohne Coaching würde spätestens die Lieferung die inhaltlichen oder qualitativen Mängel zeigen oder aber die Lieferung käme verspätet.

Beispiele für Coaching-Bereiche sind hier:

  1. Vermittlung von fachlichem Know-how
  2. Vermittlung von Projektmanagement- und/oder Qualitätsmanagementmethodik
  3. Vermittlung von Kommunikations- und/oder Workshop-Methodik

Voraussetzung zur Anwendung von erfolgreichem Coaching ist u.a. das Erkennen der Know-how- oder Methodik-Lücken, das Vorhandensein von dem Know-how beim Kunden und nicht zuletzt die Bereitschaft des Dienstleisters sich coachen zu lassen. Coaching und Know-how kann in den meisten Fällen auch extern eingekauft werden, hier stellt sich jedoch die Frage, wer die Kosten übernimmt.

Bezogen auf die o.g. Ursachen bewegen wir uns in den Bereichen von „Methodik- oder Know-how-Mängeln“ des Dienstleisters. Umgekehrt könnte hier aber auch ein (externes) Coaching des Kunden notwendig sein.

… und was gibt es sonst noch zu beachten?

Ungefähr tausend andere Dinge, ganz klar. Sie sollten mit dieser kurzen Einführung jedoch in der Lage sein, selber ein wenig Ursachenforschung bei Problemen bzw. Konflikten im Projekt zu betreiben und selber verhaltensbasierte Lösungsansätze zu entwickeln und auszuprobieren.

Viel Erfolg mit Ihrem Projekt!

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).

Agile versus klassische Vorgehensmodelle bei der ERP-Softwareeinführung

2 Antworten

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:

  1. Vorbereitung und Organisation der Einführungsprojektes
  2. Detaillierte Analyse der Ist-Situation und Feinkonzept der Soll-Umsetzung
  3. Vollständige Anpassung der ERP-Software und Umsetzung von allen individuellen Erweiterungen (Customizing)
  4. Vollständige Umstellung auf die neue ERP-Software
  5. 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:

  1. Vorbereitung und Organisation der Einführungsprojektes
  2. Grobe Analyse der Ist-Situation und Konzeption einer groben Soll-Umsetzung
  3. Planung der folgenden Iterationen und deren grobe Inhalte, vor allem der umzusetzenden Teile des
  4. Ziel-ERP-Systems je Iteration
  5. 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
  6. Iteration 2 bis n
    • wie Iteration 1, bis der geplante Soll-Zustand erreicht ist und/oder keine weitere Optimierung geplant/gewünscht ist
  7. Finale Umstellung auf die neue ERP-Software
  8. 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).