WAS UNS AUSMACHT

Projekt Methodik

Project Support

Management für Ihre Projekte

EQEEP Hybride Implementierungsmethodik

Bevor wir die praktische Umsetzung betrachten, müssen wir erst einmal die Begrifflichkeiten klären. Was wir als agile ERP-Einführung bezeichnen, ist nämlich nicht vollständig agil. Im ERP-Kontext kommen rein agile Ansätze so gut wie nie vor.

Die übliche Vorgehensweise bei der ERP-Auswahl– Lastenhefterstellung, Longlist, Shortlist, etc. widerspricht dem bereits. Bei einer vollständig agilen ERP-Einführung würde sich ein Unternehmen einen vertrauenswürdigen ERP-Anbieter suchen, so schnell wie möglich eine Basisversion des ERP-Systems implementieren und erst im Rahmen weiterer Optimierungszyklen die realen Anforderungen herausarbeiten. Dieser Ansatz des Rapid Prototypings verträgt sich jedoch nicht mit der Tatsache, dass die ERP-Einführung kein reines IT-Projekt ist, sondern ein komplexer Change-Management-Prozess.

Wenn wir in der Praxis von agiler ERP-Einführung reden, sind damit fast immer hybride Modelle gemeint. Einführungsmethoden, die Elemente agiler und linearer Ansätze miteinander kombinieren.

Hybride Ansätze teilen den Projektverlauf - wie beim Wasserfallmodell auch – in drei Phasen auf:

  1. Projektvorbereitung
  2. Realisierung
  3. Inbetriebnahme/Produktivstart

Hierbei handelt es sich aber um kein starres Konzept. Die drei Phasen gehen oft fließend ineinander über oder werden zum Teil auch kombiniert. Die genaue Ausarbeitung hängt zum Teil vom jeweiligen ERP-Anbieter ab. In unserem hybridem Einführungsmodell läuft beispielsweise die Realisierungsphase agil ab, die anderen beiden Phasen jedoch vorwiegend linear.

TOOLS UND VORGEHEN

Am Anfang stehen die Anforderungen des Kunden. Diese sind oft noch unvollständig oder vage. DerKunde bzw. der Teilprojektleiter (TPL) formuliert seine Anforderungen daher erst mal grob so weit sie bekannt sind und fasst sie als Ansammlung von User Stories in Arbeitspakete (Product Backlog) zusammen. Die wichtigsten Funktionen werden entsprechend priorisiert und müssen nun noch hinreichend genau spezifiziert werden. Am Anfang eines Zyklus, dem sog. Sprint, schätzt das Team im Sprint Planning Meeting die User Stories mit der höchsten Priorität und zerlegt sie in kleinere Teilaufgaben. Es werden dann vom Team nach absteigender Priorität so viele Aufgaben für den aktuellen Sprint Backlog zur Implementierung ausgewählt, wie mit den gegebenen Ressourcen bearbeitet werden können. Das Team verpflichtet sich, diese Aufgaben bis zum Ende des Sprints umzusetzen (commitment). Teilweise wird anstatt Verpflichtung auch der Begriff Prognose verwendet, da die Erfahrung zeigt, dass die Qualität des Produkte leidet, wenn das Team verpflichtet ist, gegen Ende des Sprints noch unbedingt alle Aufgaben fertigstellen zu müssen. Im Anschluss an das Sprint Planning werden die Aufgaben aus dem Sprint Backlog auf dem Kanban Board in der Spalte ToDo plaziert (siehe auch Tools). Innerhalb eines Sprints organisiert das Team seine Arbeit selbst, der PL (Projektleiter) und der SA (Solution Architect) dürfen keine Anweisungen geben. Jeden Tag trifft sich das Entwicklungsteam in einem kurzen Daily Meeting (auch virtuell) in dem jedes Teammitglied über seine Arbeit (aktuelle, erledigte und nächste Aufgaben, Probleme) berichtet. Am Ende des Sprints wird im Sprint Review Meeting das Ergebnis (systemisch) dem PL und SA freigegeben und die Implementierungen werden abgenommen (oder zurückgewiesen und wieder in das Product-Backlog aufgenommen). In der den Sprint abschliessenden Sprint-Retrospektive wird der Verlauf des Sprints kritisch im Rückblick überprüft. Es nehmen nur das Team und der SA teil und untersuchen, was für Probleme es gab und was besser gemacht werden kann.

Srumban Methode

1 

Es gibt auch in der ERP Implementierung gewisse ”Fertigungsstufen”, wie man z.B. am Wasserfallmodell oder ähnlich auch beim V-Model gut erkennen kann: Anforderungsanalyse, Entwurf, Implementierung, Tests, Auslieferung und Inbetriebnahme. Wie bei anderen agilen Methoden auch wird bei Srumban aber die Arbeit in viele Teilpakete zerlegt und für jeden Teil werden die ”Fertigungsstufen” einzeln durchlaufen. Es entsteht so ein iterativer Prozess bei dem in kurzen Abständen (lauffähige) Zwischenstufen der Software ausgeliefert werden können bzw. tatsächlich auch ausgeliefert werden. Kanban ist ein sehr leichtgewichtiger Prozess und macht nur sehr wenige Vorgaben. Die beiden wichtigsten Regeln sind:

  • Visualisiere den Arbeitsfluss (auf der Srumban-Tafel)
  • Begrenze die Arbeit in jeder Phase des Prozesses mit WIP-Limits

2

Der Begriff Scrumban ist nicht fest definiert, es wird in der Regel verwendet als ein Vorgehensmodell, dass zwischen Scrum und Kanban liegt. Teilweise wird auch der gleichzeitige Einsatz von Scrum und Kanban in einer Organisation (z.B. auf verschiedenen Ebenen) als Scrumban bezeichnet.

  • Srumban ist agil und schlank (lean) und verwenden das Pull-Prinzip, hat eine gewisse Beschränkung der WIP und unterstützt einen kontinuierlichen Verbesserungsprozess durch Schaffung von Transparenz.
  • Srumban setzt beide auf sich selbst organisierende Teams und auf die eigenverantwortliche Mitarbeit und teilen die Arbeiten in kleinere Arbeitspakete auf.
  • Scrumban ist leichtgewichtiger und anpassbar, nicht das Vorgehensmodell steht im Mittelpunkt sondern die zu erledigenden Aufgaben in ihrer angestammten Umgebung.

Bei einer Implementierung stehen dem Projektteam die Werkzeuge Jira & Confluence zur Verfügung.

Mit Einsatz dieser Werkzeuge wird sowohl die Scrumban Methodik unterstützt als auch die Transparenz aus dem Projekt in Richtung Projektleitung und Stakeholder aufrechterhalten.

Hier ein paar graphische Beispiele:

JIRA (Board)

 3

4

Confluence

5

6

Und vieles mehr …

Copyright 2020 eqeep GmbH.