Agiles Business Process Management

Agiles Projektmanagement ist ja zur Zeit vor allem in IT-Projekten total angesagt. Immer mehr Unternehmen interessieren sich für Scrum, XP und Co. weil viele Projekte, die nach klassischen PM-Methoden, durchgeführt werden scheitern. Gründe hierfür sind häufig die Komplexität von Projekten und eine schlechte Kommunikation.

Die selben Probleme kenne ich auch aus BPM-Projekten. Man verliert sich bei der Prozessmodellierung, -analyse und -design im Detail. Diese Phasen dauern häufig mehrere Monate. Die Prozesse die nach der Analyse designed werden sind schon zu Beginn des Designs nicht mehr aktuell, werden aber im Anschluss noch in irgendeinem System realisiert. Im Endeffekt passen die Prozesse nicht mehr zu den schon längst geändertem realen Business.

Bietet sich in diesem Umfeld eine agile Vorgehensweise an?

Scrum ist nicht nur für Entwicklungsprojekte geeignet, sonder lässt sich auch als “normale” Projektmanagementmethode einsetzen und auch außerhalb der puren Entwicklung. Im Bereich des BPM befinden wir uns ja nur zu einem Teil in der IT. Große Teile werden nur mit IT-Unterstützung realisiert (z.B. Modellierung, Analyse, Design, Optimierung, etc.). Hier ist mir immer wieder aufgefallen, dass einige Unternehmen schon intensiv ihre Prozesse dokumentieren. Leider werden die Prozesse nach der initialen Erfassung nur noch selten aktualisiert. Darüberhinaus dauert es sehr lange bis die Prozesse bis auf das kleinste Detail modelliert, analysiert und designed ist. Wenn diese Schritte durchlaufen sind, traut sich häufig keiner einfach mal eben den Prozess anzupassen. Hier wäre ein agiles Vorgehen interessant.

Agile Vorgehensmodelle eignen sich besonders wenn komplex Themen zu bearbeiten sind oder der genaue Umfang am Anfang des Projektes nicht komplett detailliert werden kann. Dies trifft ja auf sehr viele Projekte zu. Häufig sind die Prozesse vor der Modellierung nicht bekannt oder veraltet, so das diese neu aufgesetzt oder aktualisiert werden müssen. Wenn ich Prozesse zum ersten Mal modellieren muss, dann kann ich zu Beginn der Modellierung nur grob den Umfang und den Inhalt des Prozesses abstecken. Wer behauptet mehr machen zu können lügt. Nach und nach werden bei der Modellierung und Analyse immer mehr Details und Informationen identifiziert die in den Prozess eingebaut werden müssen. Hier könnte man agil und iterativ vorgehen. Zuerst werden ein Prozess im groben abgesteckt und modelliert. Diese Modellierung kann analysiert und mit den bekannten Details im Design ausgearbeitet werden. Im nächsten Zyklus kann man das erstellte Prozessmodell validieren und mit den neuen Erkenntnissen anreichern. Genauso könnten die Prozesse mit Hilfe von BPM-Technologien umgesetzt werden. Dadurch würde man sehr schnell einen ersten lauffähigen Prozess erhalten, der zuerst den realen Geschäftsprotzess nur rudimentär wiedergibt und nach und nach ausgebaut werden kann.

Hierbei fällt mir aber sofort das erste Problem auf. Ein Prozess sollte einen spezifizierten Input und Output besitzen. Wenn in den verschiedenen Iterationen des Prozesses Input und Output angepasst werden müssen, sind ggf. andere abhängige Prozesse dadurch beeinflusst. Die Schnittstellen zwischen den einzelnen Prozessen sind nicht mehr konsistent. Also sollte man darauf achten, das in der ersten Iteration die Schnittstellen eines Prozesses möglichst sauber und vollständig beschrieben werden. In den nachfolgenden Zyklen kann dann der Prozess immer weiter mit Inhalt gefüllt werden. Hierbei ist zu beachten das der Prozess mit immer neuen Aktivitäten angereichert werden soll, die Aktivitäten an sich aber möglichst direkt vollständig umgesetzt werden sollten. Werden einzelne Aktivitäten an sich iterativ umgesetzt ergeben sich verschiedene Nachteile: Falls ein Benutzer in diese Aktivität eingebunden ist, muss sich dieser mit jeder Iteration auf eine neue Bearbeitungsweise der Aktivität einstellen. Darüberhinaus könnte das gewohnte Phänomen eintreten, das eine Zwischenlösung zur endgültigen Lösung wird und so nicht das volle Optimierungspotential ausgeschöpft wird.

Die Überlegung, wie man einen Prozess in einzelne Arbeitspakete für das Scrum-Team unterteile ist ebenfalls von großer Bedeutung. Welche Aktivitäten eines Prozesses müssen zwingend gemeinsam realisiert werden. Eine iterative Vorgehensweise ist meiner Meinung nach vor allem bei Prozessen sinnvoll, die ausgedehnte Verzweigungen mit mehreren parallelen Aktivitäten besitzen. Diese können nach und nach hinzugefügt und die parallelen Prozessabläufe erweitert werden.

In den nächsten Tagen möchte ich mich auch noch gerne mit der Möglichkeit der Agilität in den anderen Bereichen des BPM (Prozessumsetzung /-einführung, Prozessleistungsmessung, Unternehemensprozessmanagement) und vor allem mit dem Punkt Prozessdokumentation auseinander setzen. Denn die Dokumentation ist laut BPM CBOK® ein kritischer Erfolgsfaktor für das BPM.

Demnächst also mehr zum agilen Business Process Management.

Commentary

Leave a response »

  1. 1. Januar 31st, 2010

    Hallo Herr Wieschollek,
    das ist ein interessanter Zufall? Ich werde mich mit Herrn Jakob Freund von der camunda in 2 Wochen genau zu dem Thema SCRUM in BPM-Projekten in Berlin zusammensetzen.
    ich selbst wohne bei Köln, also nahe an Krefeld. Wenn Sie interesse haben, könnten wir uns anschließend auch gerne zusammen setzen.
    Und da Sie in BPM auch schon länger unterwegs sind, sagt Ihnen das Thema Customer Expectation Management etwas?
    Ich habe diese neue BPM-Disziplin in meinem Artikel im BPM-Netzwerk (http://www.bpm-netzwerk.de/content/articles/viewArticle.do?id=d915570e265ad62201266f515ff902d0&source=3)
    das erste Mal erwähnt und heute auf unserem SAPERION Blog weiter detailliert (http://www.saperionblog.com/business-process-management-bpm-mit-neuer-disziplin-customer-expectation-management-cem-bindet-kunden-besser/866/).
    Ich würde mich sehr freuen, wenn Sie hier kommentieren würden.
    Mir gefallen Ihre Beiträge auf Ihrem Blog ausgepsrochen gut. Weiter so!
    Viele Grüße, Martin Bartonitz

    Dr. Martin Bartonitz

Trackbacks

  1. [...] Meine ersten Gedanken zu dieser Kombination habe ich hier im Blog schon beschrieben (siehe Teil 1 und Teil 2). Die selben Gedanken haben sich auch Dr. Martin Bartonitz von Saperion und Jakob Freund [...]

    Agiles BPM mit Scrum « BPM+
  2. [...] by Martin at Dezember 22nd, 2009 Im ersten Teil zum Thema Agiles Business Process Management habe ich meine ersten Gedanken verfasst, wie man Prozesse mit Hilfe von Scrum analysieren und [...]

    Agiles Business Process Management – Teil 2 « BPM+

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