Agiles Business Process Management – Teil 2

Im ersten Teil zum Thema Agiles Business Process Management habe ich meine ersten Gedanken verfasst, wie man Prozesse mit Hilfe von Scrum analysieren und modellieren kann. Im zweiten Teil möchte ich mich etwas genauer mit dem Thema beschäftigen.

Der Einsatz von Scrum in BPM Projekten hängt von mehreren Faktoren ab. Zum einen von der Komplexität der Prozesse und vom Ziel des Projektes.

Diese verschiedenen Szenarien möchte ich nachfolgend erläutern:

bpm_scrum

Für alle Komplexitätsstufen sind einige Vorraussetzungen zu beachten bevor man beginnt Prozesse ausführbar in IT-Systemen zu implementieren:

  • Strategie zur Prozessimplementierung ist vorhanden
  • Ein lauffähiges BPMS System ist vorhanden
  • Erfahrene Experten zur Prozess Analyse sind vorhanden

Sofern diese Punkte nicht erfüllt sind, sollte man in vorgelagerten Projektphasen diese Grundlagen schaffen. Es ist ratsam eine Strategie zur Prozessimplementierung zu definieren. Diese beschreibt wie Prozesse in die IT-Landschaft integriert werden, wie die Verantwortlichkeiten für Prozesse geregelt sein müssen (Process Owner) und welche Methoden, Konventionen und Techniken verwendet werden sollen. Durch eine gute Strategie könne spätere Prozesse schnell und flexibel implementiert werden. Die Strategie erst nach und nach mit den einzelnen zu implementierenden Prozesses wachsen zu lassen führt häufig dazu, dass die Prozesse nicht einheitlich, schwer zu warten und unflexibel werden. Eine einheitliche Strategie reduziert auch den notwendigen Dokumentationsaufwand und reduziert somit auch die Einarbeitungszeit neuer Mitarbeiter. Da die wesentlichen Elemente der verschiedenen Prozesse identisch sind und den gleichen Regeln folgen.

Scrum bei Prozessen mit niedriger Komplexität:

Hier kann Scrum in seiner reinform vollständig ausgelebt werden. Vor allem, wenn viele Prozesse mit niedriger Komplexität bis zur Prozessausführung mit IT-Systemen implementiert werden sollen lässt sich dies sehr gut mit Scrum realisieren. Prozess Analysten nehmen die Prozesse beim Kunden auf und modellieren diese am besten mit einer standardisierten Modellierungsnotation (z.B. BPMN). Einfache Prozesse können schon während der Modellierung durch erfahrene Prozess Analysten analysiert werden, um zum einen den Prozessablauf zu optimieren, aber auch die benötigten Ressourcen, KPIs und Daten zu definieren. Die so modellierten Modelle können in einem BPMS implementiert werden. Einige der auf dem Markt vorhandenen BPM Suiten bieten die Möglichkeit auf den modellierten Prozessen aufzubauen und das Prozessdesign durchzuführen (Implementierung der technischen Details, die für die Prozessausführung notwendig sind). Im Anschluss können die Prozesse sofort vom Kunden im BPMS getestet werden. Prozesse von niedriger Komplexität ermögliche es all diese Schritte in einem Sprint (z.B. 4 Wochen) durchzuführen.

Scum bei Projekten mit mittlerer Komplexität:

Hier wird es schon schwerer die kurzen Iterationszyklen des Scrum einzuhalten. Scrum definiert, dass nach jedem Sprint ein lauffähiges Produkt ausgeliefert werden kann. Werden die Prozesse zu groß, um diese während eines Sprints zu modellieren, analysieren, designen und zu implementieren hat man im Prinzip drei Möglichkeiten:

  1. Die Prozesse zerlegen/reduzieren
  2. Die Sprints verlängern
  3. Die Ergebnisse eines Sprints anders definieren

Zu 1) Die Prozesse zerlegen ist nicht bei allen Prozesse möglich. Zum einen unterstützen dieses Vorgehen nicht alle BPM Suiten und Systeme. Zum anderen liefern Prozesse ein bestimmtes Ergebnis. Mit den Zwischenprodukten, die während eines Prozesses anfallen kann der Product Owner nichts anfangen. Daher eignet sich das zerlegen der Prozesse nur dann, wenn der Prozess dies überhaupt ermöglicht. Dies ist häufig der Fall, wenn Prozesse viele parallele Zweige aufzeigen. Dann können diese parallelen Zweige nach und nach implementiert werden. Eine Reduzierung der Prozesse könnte bedeuten, dass Schritte die automatisiert werden sollen, oder Schnittstellen in einem Prozess in die erste Prozess-Version durch einen manuellen Task abgebildet werden. Dies ist natürlich nicht bei der Verarbeitung von Massendaten möglich, bei Prozessen mit hoher menschlicher Interaktivität aber schon. So müssen Anwender ggf. in der ersten Version Daten noch manuell in Drittsysteme übertragen und im nächsten Sprint werden die Schnittstellen entwickelt und automatisiert. Ein großer Nachteil der Prozesszerlegung/-reduzierung ist, dass die Anwender sich während der Prozessimplementierung nach jedem Schritt an einen etwas anderen Prozess gewöhnen müssen. Dies kann zu Verwirrung und Frustration führen.

Zu 2) Eine allgemeine Verlängerung der Sprints in einem Scrum Projekt ist möglich. So kann man von den üblichen 4 Wochen abweichen und ggf. 6 oder sogar 8 Wochen als Sprintdauer definieren. Allgemein ist dies aber nicht im Sinne von Scrum. Durch längere Sprints würde ein großer Teil der Agilität von Scrum verloren gehen. Der Product Owner muss in bestimmten Situationen zu lange warten bis neue Anforderungen realisiert werden können. Daher ist die Verlängerung der Sprints mit Vorsicht zu genießen und sollte die 8 Wochen nicht überschreiten.

Zu 3) Die dritte Möglichkeit ist eine Kombination von Kanban und Scrum. Es wird nicht am Ende eines Sprints der fertige Prozess implementiert, sondern es werden beispielsweise insgesamt 3 Sprints benötigt. Im ersten Sprint werden die Prozesse modelliert, im 2. Sprint werden die Prozesse analysiert und im 3 Sprint erfolgt das Design und die Implementierung. Dies Reduziert zwar wieder die Agilität (der Prozess an sich ist erst nach 3 Sprints fertig), hat aber gegenüber der Sprintverlängerung den Vorteil, das alle 4 Wochen ein Ergebnis sichtbar ist. Der Product Owner kann alle 4 Wochen eingreifen und ggf. neue Produkte in das Sprint Backlog mit aufnehmen lassen und kann so das Projekt besser mit gestalten. Des Weiteren ermöglicht diese Variante, dass man in jedem Sprint unterschiedliche Teams mit den Aufgaben beauftrage. So kann die Modellierung durch ein Team von Analysten durchgeführt werden, die evtl. fachliches Know-how der zu modellierenden Prozesse besitzen und sehr gut dabei sind mit den späteren Anwendern Prozesse in Workshops oder Interviews zu erfassen. Das nächste Team analysiert und optimiert die Prozesse und ist darauf spezialisiert. Das dritte Team ist spezialisiert auf die Implementierung der Prozesse und ggf. Entwicklung von Schnittstellen. Dadurch kann man die Auslastung der Teams deutlich erhöhen und Leerlaufzeiten einzelner Spezialisten vermeiden. Man sieht hier aber schon, dass man ggf. vom „klassischen“ Scrum abweichen muss um Prozesse mittlerer Komplexität zu realisieren.

Scrum bei Prozessen mit hoher Komplexität

Prozesse mit hoher Komplexität lassen ggf. nur noch mit der oben beschriebenen „Kanban und Scrum“ Kombination bewältigen. Sollten hierbei langwierige Workshops und Analysen zur Prozessmodellierung notwendig sein und bei der Einführung große organisatorische Änderungen benötigt werden müssen schon wahre Scrum-Experten ans Werk. Hierbei ist wahrscheinlich ein Scrum of Scrums zu verwenden um einzelne Aktivitäten runterzubrechen und an verschiedene Teams zu verteilen. Hierbei ist wieder darauf zu achten, dass die User Stories in sinnvolle Teilpakete aufgeteilt werden, die in einem Sprint realisiert werden können. Nichts desto trotz kann das agile Manifest auch hierbei beachtet werden. Und man sollte möglichst schnell versuchen modellierte Prozesse lauffähig zu machen. Denn eine Modellierungs- und Analysephase, die mehrere Monate dauert gefolgt von einer langwierigen Implementierung führt häufig zum Scheitern von Projekten. Hier sollte auch versucht werden den „start small grow big“ Ansatz zu verfolgen. Mit der ersten Prozess-Version sollte man also nicht unbedingt versuchen denn Prozess zu 100% mit allem drum und dran (Schnittstellen, Automatisierung, etc.) zu realisieren, sondern eine sinnvolle Reduktion. Denn die letzten 10 % sind eh immer die teuersten.

Commentary

Leave a response »

  1. 1. Januar 31st, 2010

    Hallo Herr Wieschollek,
    der Link auf den ersten Artikel scheint nicht zu funktionieren …
    MfG Martin Bartonitz

    Dr. Martin Bartonitz
  2. 2. Januar 31st, 2010

    Hallo Herr Wieschollek,
    ich hätte da noch ein paar mehr Ideen, wie die Stories für die Iterationen geschnitten werden könnten.
    Übrigens heißt es bei Scrum, dass das Ergebnis “poteniell auslieferbar” sein soll. D.h. also, dass Anwender nicht nach jeder Interation was Neues bekommen müssen.
    Das Schneiden der Stories könnte im Grobe nach a) der im von Ihnen kommentierten Praxishandbuch BPMN beschriebenen Methode erfolgen: Strategische Modelle -> Operative Modelle -> Technische Modelle, und b) ein Prozess nach dem anderen und c) ein Stück eines Prozess nach dem anderen, was allerdings voraussetzt, dass der Prozess die auch zulässt.
    Was noch offen bleibt: wenn der Prozess dann umgesetzt ist, wie geht es dann mit dem Process Improvement Cycle weiter. Auch hier kann ich mir vorstellen, dass Scrum funktioniert. Nur dann in längeren Cyclen und wiederkehrenden Gesamtaufgaben: Erst die Analyse, dann das Ideen zur Verbesserung entwickelt, anschließend die Verbesserungen in die technischen Prozesse umsetzen, und natürlich wieder die Anwender schulen.
    Wie sieht es mit den Scrum Rollen und BPM-Rollen aus:
    Der Geschäftsführer als der Process Owner?
    Der Process Manager als Scrum Master?
    Wer sitzt im Product Board?
    Lassen Sie uns unbedingt hier dran weiterarbeiten!

    Dr. Martin Bartonitz
  3. 3. Januar 31st, 2010

    Hallo Martin.

    Ich sehe es sehr ähnlich wie Martin (Bartonitz): Nicht jedes Release am Sprint-Ende wird ausgeliefert. Es muss “nur” lauffähig und theoretisch auslieferbar sein.

    Dieser kleine Unterschied liefert einem aber denke ich genügend Möglichkeiten, Aufgaben sowie Inhalte entsprechend zu schneiden und in verschiedene Sprints zu packen. Das würde ja so oder so im Projekt passieren, da man seine eigene Arbeit auch innerhalb der Sprints strukturieren muss (spätestens das Team oder der Mitarbeiter).

    Oder meinst du nicht? Ach ja: Und wenn das Tool dieses Vorgehen nicht zulassen sollte, hat man vermutlich das falsche Tool ;-) ) Aber ernsthaft: Das wird dann ja auch an anderen Stellen vermutlich zu starr sein…

    Schöne Grüße
    Bernd

  4. 4. Februar 2nd, 2010

    Hallo Herr Dr. Bartonitz,

    zu c) fällt mir im Zusammenhang mit dem camunda BPMN Framework ein, dass man die Prozess nicht nur “der Länge nach” teilen kann (also in diverse Teil-Prozesse), sondern man könnte in einzelnen Sprints auch die jeweils einzelnen Prozessbeteiligten betrachten, da nach dem Framework ja versucht werden soll jedem beteiligten einen eigenen Pool zu widmen. Das würde auch die Komplexität reduzieren, da nach der Erfassung des strategischen Modells, das operative Modell mit jedem Prozessbeteiligtem separat besprochen werden kann (zumindest in großen Teilen).

    Beim Improvment Cycle würde ich nicht unbedingt auf längere Sprints setzen. Ich würde evtl. in Regel mäßigen Abständen Mini-Projekte mit Scrum durchführen. Der erste Sprint würde sich dann mit der Analyse und Auswertung der gesammelten Informationen befassen, im Anschluss danach kann überlegt werden, ob in weiteren Sprints der Prozess optimiert werden kann/soll oder nicht. Ein anderer Punkt wäre das “Daily Business”, also z.B. das Monitoren der Prozesse. Hier weiß ich nicht genau, wie man hier gezielt Scum einsetzen könnte. Ich finde Scrum macht mehr Sinn im Projekt-Umfeld.

    Noch ganz kurz zwei Sätze zur Rollenverteilung :-) Ich würde eher den Process Owner als Scrum Product Owner einsetzen. Als Scrum Master einen x-beliebigen Mitarbeiter, da dieser “nur” die Scrum Formalia überwacht. Welche Scrum Rolle besetzt dann der Prozess-Analyst? Braucht man weitere Scrum-Rollen? Quasi ein BPM-Add-on?

    Schöne Grüße
    Martin Wieschollek

    PS: Danke für den Hinweis mit dem Link. Ist jetzt korrigiert. Aber ich sehe grade, dass ich das Template auch noch anpassen muss, damit meine Antwort direkt unter Ihrem Kommentar steht.

    Martin
  5. 5. Februar 2nd, 2010

    Hallo Bernd,
    das mit dem “lauffähig” sollte man wirklich nicht zu ernst nehmen. Ich habe auch schon von großen Konzernen gehört, in denen das Management nach Scrum arbeitet. Und auf der Ebene werden auch keine “lauffähigen” Produkte entwickelt, sondern Strategien, Konzepte und Visionen. Und das wahrscheinlich auch in mehreren Iterationen. Den eine Konzernstrategie steht meiner Meinung nach nicht in 4 Wochen ;-)
    Schöne Grüße
    Martin

    Martin
  6. 6. Februar 2nd, 2010

    Ist repariert. Danke!

    Martin

Trackbacks

  1. [...] könnte man sagen, und genau wie wir ein BPMN-Fan. In seinem Blog greift Martin u.a. das Thema BPM und Agile Projekte auf, dem wir uns ebenfalls verschrieben haben. Und er gewährt einen guten Einblick in den intalio [...]

    BPM-Guide.de It’s Business Process Management » Gute BPM-Blogs
  2. quick ways To make money…

    Agiles Business Process Management…

    online tutoring uses
  3. corporate proxy solicitation Companies House…

    Agiles Business Process Management…

    proxy solicitation jobs
  4. TopTenSeo.de…

    Agiles Business Process Management – Teil 2 « BPM+…

    TopTenSeo.de
  5. Superfoods…

    Agiles Business Process Management – Teil 2 « BPM+…

    Superfoods
  6. áo cờ vn…

    Agiles Business Process Management – Teil 2 « BPM+…

    áo cờ vn

Leave a comment, a trackback from your own site or subscribe to an RSS feed for this entry. Trackback URL for this entry Comments feed for this entry

Leave a response

Leave a URL

Preview