Agilität und Prozessmanagement – wie passt das zusammen?

„Brauchen wir noch Prozesse oder arbeiten wir jetzt alle agil?“ lautet die etwas provozierende Frage im Titel eines kürzlich erschienen Whitepapers aus dem Hause BPM&O. Es dürfte nicht verwundern, dass die Autoren als erfahrene Prozessmanagement-Experten darlegen, dass agile Methoden und Vorgehensweisen keine Alternativen zum durchgängigen Management der Geschäftsprozesse darstellen. Agile Ansätze können aber in vielen Bereichen des Prozessmanagements nutzbringend eingesetzt werden und zur Ergänzung und Weiterentwicklung herkömmlich genutzter Methoden dienen.

Interessant an dem Whitepaper ist vor allem, dass die verschiedenen Bereiche des Prozessmanagements systematisch daraufhin untersucht wurden, wie und an welchen Stellen agile Prinzipien angewandt werden können. Zudem wird beschrieben, wo man konkrete Elemente aus bestimmten agilen Methoden einsetzen kann, insbesondere aus Scrum. Es wird dafür plädiert, Prozessmanagement als integrierenden Rahmen für den agilen Methodeneinsatz zu nutzen und hierdurch eine nachhaltige Wirkung sicherzustellen.

Auf strategischer Ebene können Methoden wie Design Thinking angewandt werden. Die Umsetzung der Strategie kann dann agil über die Prozesse erfolgen. Wie agil die Prozessdurchführung durch selbstverantwortliche Prozessteams erfolgen sollte, hängt von der Art des jeweiligen Prozesses ab. Tendenziell eignen sich dynamische Prozesse, die sich häufiger ändern, mehr individuelle Variationsmöglichkeiten und weniger strenge regulatorische Anforderungen haben, besser für den Einsatz agiler Methoden. Prädestiniert sind Prozesse, in denen neue Produkte, Konzepte o. ä. entwickelt werden, wo man Scrum und ähnliche Ansätze in ihrer Ursprungsform direkt nutzen kann. Aber auch auf andere, eher kurz laufende Prozesse können agile Prinzipien angewandt werden, z. B. indem man den Prozessausführenden größere Freiheitsgrade einräumt.

Das Gesamtprozessmodell stellt eine Komplettsicht auf die Prozesse und insbesondere auf ihre Abhängigkeiten dar. Innerhalb dieser Gesamtstruktur können agile und nicht-agile Prozesse nebeneinander existieren. Die Autoren machen Vorschläge, wie die in Scrum definierten Rollen, die eher auf projektbezogene Vorhaben ausgerichtet sind, an auftragsbezogene Prozesse angepasst werden können.

Die Entwicklung und Einführung neuer Prozesse kann ebenfalls agil erfolgen – wobei darauf geachtet werden soll, dass die in den einzelnen Iterationen umgesetzten inkrementellen Veränderungen das Funktionieren des Gesamtprozessmodells nicht gefährden. Die agile Sollprozessentwicklung eignet sich vor allem für Prozesse, die komplexen und dynamischen Anforderungen gerecht werden müssen – weniger hingegen für Prozesse mit hohen Anforderungen an Korrektheit und Regelkonformität.

Als entscheidend wird ein konsequenter Prozessbezug angesehen. Dieser lässt sich zwar sehr gut mit agilen Prinzipien vereinbaren, doch findet er sich in den Beschreibungen agiler Methoden meist nicht explizit, sondern höchstens zwischen den Zeilen.

An dieser Stelle noch einige Gedanken zu den Ausführungen in dem sehr lesenswerten Whitepaper:

• Es wird die Frage angerissen, wie in einer agilen Prozessentwicklung die Ergebnisse der einzelnen, recht kurzen Iterationen aussehen. In der agilen Software-Entwicklung soll am Ende jeder Iteration ein potenziell auslieferbares Produkt entstanden sein. Das Pendant hierzu wäre ein funktionierender, potentiell produktiv einsetzbarer Prozess. Im Whitepaper wird darauf verwiesen, dass durch die inkrementellen Ergebnisse das Gesamtprozessmodell nicht gefährdet werden darf. Andererseits muss der am Ende einer Iteration vorliegender Prozess nicht unbedingt sofort produktiv eingesetzt werden. Denkbar ist auch, dass die Prozessbeteiligten den geänderten Prozess in einer Laborumgebung testen, oder dass sie ihn erst einmal nur in einem Pilotbereich oder mit ausgewählten Kunden durchführen.
• In dem Paper ist öfter die Rede von Anforderungen an die Prozesse, insbesondere Kundenanforderungen. Ebenso wie in der Softwareentwicklung erlebt man es auch bei der Gestaltung von Prozessen, dass die Kunden ihre Anforderungen häufig gar nicht genau kennen und daher auch nicht formulieren können. Entsprechend sollte auch bei der Umgestaltung von Prozessen nicht vorrangig mit Anforderungsdokumenten gearbeitet werden. Vielmehr sollten konsequent echte Kunden einbezogen werden.
• Es wird mehrfach auf Scrum als agile Methode Bezug genommen, wobei Adaptionen an auftragsbezogene Prozesse vorgenommen werden. Hier wäre auch ein Blick auf weitere Ansätze aus dem Umfeld der agilen Methoden und des Lean Management hilfreich, insbesondere Kanban.
• Die Rolle der IT wird im Whitepaper ebenfalls behandelt. Zum einen zur Unterstützung der Zusammenarbeit von Teams, zum anderen zur Automatisierung von Prozessen. Im Zuge der Digitalen Transformation stellt sich die Frage, ob der herkömmliche Zweischritt noch aufrecht erhalten werden sollte, wo Prozesse zunächst aus fachlicher Sicht beschrieben und anschließend softwaretechnisch umgesetzt werden.
  Im Zuge eines agilen Vorgehens müssten der jeweilige Prozess und seine Software-Implementierung von Anfang an integriert betrachtet und in jeder Iteration gemeinsam weiterentwickelt und von den Prozessbeteiligten und Kunden getestet werden. Hierbei entsteht in einer modellbasierten BPM-Plattform auch das detaillierte Prozessmodell, das direkt zur Ausführung kommt. Eine sehr detaillierte fachliche Modellierung ist dann gar nicht mehr erforderlich.
• Das Gesamtmodell der Prozesse mit ihren Schnittstellen wird als Rahmen betrachtet, innerhalb dessen Prozesse agil entwickelt und durchgeführt werden können. Dabei sollte man sich aber auch überlegen, ob das Ziel einer agilen Entwicklung flexibler und schnell anpassungsfähiger Prozesse nicht auch dazu führen sollte, dass die Prozesse unter Umständen ganz anders geschnitten werden. Eventuell könnte man das Software-Architekturkonzept der Microservices als Anregung verwenden. Microservices sind weitgehend unabhängig voneinander und können daher schnell entwickelt und geändert werden. Hierfür nimmt man unter anderem auch redundanten Code in Kauf und verzichtet auf die Vorteile der Wiederverwendung.
  In vergleichbarer Weise könnte man entscheiden, dass in einem Kundenauftragsbearbeitungsprozess das verantwortliche Prozessteam nicht den unternehmensweit standardisierten Beschaffungsprozess nutzen muss, sondern diese Einkäufe komplett selbst abwickelt. Das widerspricht der Idee einheitlicher und standardisierter Prozesse im gesamten Unternehmen, ermöglicht es aber, den fraglichen kundenbezogenen Prozess schneller weiterzuentwickeln, da es weniger Abhängigkeiten von anderen Prozessen gibt. Die Anforderungen einer komplexen und dynamischen Umwelt können es an manchen Stellen erforderlich machen, hergebrachte Prozessmanagement-Prinzipien über Bord zu werfen.

Download des Whitepapers bei BPM&O (Registrierung erforderlich).