BPM-Projekte verleiten leicht zu einem „Big Design Upfront“. So naheliegend es scheint, Geschäftsprozesse erst umfassend zu analysieren und bis ins Detail auszumodellieren, ehe man auf Basis dieser (vorgedachten) Modelle dann eine Software-Lösung implementiert: der Komplexität und der Dynamik im Umfeld von Geschäftsprozessen lässt sich in der Regel nur unzureichend durch ein solches Wasserfall-Vorgehen begegnen. Zu viele Annahmen müssen in Vorfeld getroffen werden. Fehler und Missverständnisse sind vorprogrammiert und es besteht ein hohes Risiko, dass erst sehr spät gemerkt wird, dass das Modell nicht (oder nicht mehr) den Anforderungen entspricht oder die Implementierung fehlerhaft ist. Auf geänderte Anforderungen und Erkenntnisse, seien sie intern oder extern, kann dann nicht oder nur schwer reagiert werden. Da hilft es dann auch nicht, sich darauf zu berufen „das hatten wir aber so definiert!“.
Ursachen und Wirkung
Im Kontext von BPM gibt es vor allem zwei Aspekte, warum man leicht einem „Big Design Upfront“ Ansatz verfallen kann. Zum einen haben BPM-Projekte naturgemäß einen hohen Anteil von Analyse-, Design- und Modellierungsaufgaben. Die Prozessmodelle stehen im Fokus des Projektvorhabens und so liegt es nahe, sich gleich zu Projektbeginn sehr intensiv damit auseinander zu setzen. Insbesondere in der Zusammenarbeit mit stark spezialisierten Fachexperten besteht dann auch immer die Gefahr, dass man sich viel zu früh viel zu sehr in einzelnen Details verstrickt.
Zum anderen sind in BPM-Projekten meist viele Stakeholder beteiligt. Prozesse erstrecken sich über verschiedene Fachabteilungen, die die unterschiedlichsten Anforderungen haben und alle Beteiligten wollen ihre Anforderungen vollumfänglich umgesetzt wissen. Deshalb fordern sie vorab möglichst genaue Modelle und Spezifikationen. Wiederholt haben wir in diesem Zusammenhang schon Aussagen wie „Wir müssen ja mindestens 120% fordern, um nachher 80% zu bekommen!“ gehört.
Dies führt dazu, dass bereits vor der Realisierung viel Zeit in die Erstellung eines umfassenden Entwurfs investiert wird, der sich hinterher womöglich als unzureichend heraus stellt. Es ist ein trügerisches Gefühl der Sicherheit, dass umfangreiche Modelle, Spezifikationen und Dokumentation auch zur besten Lösung führen. Vielmehr wird durch ein „Big Design Upfront“ der kreative Lösungsraum sowie die Bereitschaft, sich auf sich ändernde Anforderungen einzulassen, frühzeitig eingeschränkt. Entwicklungsmannschaft und Fachbereiche können dabei leicht zu Gegenspielern werden, anstatt gemeinsam die bestmögliche Lösung zu erarbeiten.
Gerade in komplexen Systemen lassen sich kaum alle wichtigen Entwurfsentscheidungen im Vorfeld sicher bestimmen. Egal welchen Aufwand wir betreiben, viele Erkenntnisse ergeben sich erst in der praktischen Auseinandersetzung mit dem Problemgegenstand und eine objektive Aussage über die Brauchbarkeit von Entwurfsentscheidungen ist oft erst nach der Überprüfung der Realisierung möglich.
Abhilfe: Agiles BPM
Es ist schon kurios: Projekte im Kontext von BPM sind meist groß, langlaufend, interdisziplinär und komplex. Eigentlich alles gute Gründe für agile Methoden und dennoch tun wir so, als müsse alles vorab komplett ausdefiniert sein. Dabei versprechen wir uns mit BPM ja eigentlich flexible, schnell zu ändernde Prozesse. Was bedeutet es denn, wenn z.B. vom Fachbereich keine klare Aussage kommt, wie etwas umzusetzen ist? Das muss nicht immer eine Schwäche sein. Vielleicht verbirgt sich dahinter eine Stellschraube für Flexibilität, die wir im Prozessdesign berücksichtigen müssen?
Aus unserer Sicht ist es unerlässlich, auch (oder vielmehr insbesondere) in BPM-Projekten ein agiles Vorgehen zu etablieren. Natürlich durchläuft auch ein agiles Projekt verschiedenen Phasen und wir benötigen erste Prozessmodelle, bevor wir mit der Realisierung loslegen können. Eine initiale Grundlagenphase sollte sich aber auf ein „Big Picture“ beschränken, d.h. die ersten Entwürfe strategischer Prozessmodelle auf abstrakter Ebene und die Abstimmung der fachlichen wie technischen Leitplanken für die Umsetzung.
In der anschließenden Realisierung besteht die Herausforderung darin, auch die weitere Prozessanalyse und -modellierung iterativ-inkrementell zu gestalten und parallel zur Implementierung durchzuführen. Dies lässt sich am besten dadurch erreichen, dass man in der Wachstumsphase des Projekts mit zwei agilen Teilteams arbeitet: der eine Teil des Teams kümmert sich um die Entwicklung und schrittweise Detaillieren der Prozessmodelle während das andere Team die Implementierung der Software-Lösung übernimmt. Die beiden Teams arbeiten dabei in versetzten Sprints, d.h. die Arbeitsergebnisse des Modellierungsteams aus dem vorangegangenen Sprint liefern den Input für den aktuellen Implementierungs-Sprint. Dabei sollte aber immer darauf geachtet werden, dass beide Teams in räumlicher Nähe eng und interdisziplinär zusammen arbeiten und ein kontinuierliches, wechselseitiges Feedback stattfindet.
Durch die regelmäßige Auslieferung und Überprüfung von Teilergebnissen beider Teams kann sichergestellt werden, dass Overengineering sowohl auf der Ebene der Prozessmodelle als auch bei der Implementierung der Software vermieden wird und dass die umgesetzte Lösung am Geschäftsziel ausgerichtet bleibt. Gleichzeitig empfiehlt es sich, die iterativ-inkrementell umgesetzten, ausführbaren Prozessemodelle stets auch durch automatisierte Unit-Tests abzusichern.
Ist das Projekt schließlich so weit fortgeschritten, dass der Vorlauf in der Modellierung nicht mehr in dieser Form benötigt wird, ist es meist sinnvoll, die beiden Teilteams wieder zusammen zu führen, um in interdisziplinären Feature-Teams die BPM-Lösung zur Produktionsreife fertig zu entwickeln.
Dieses Vorgehensmodell hat sich in unseren BPM-Projekten in der Praxis so gut bewährt, dass es mittlerweile auch zu einem integralen Bestandteil des BPM-Frameworks der Enterprise BPM Alliance geworden ist. Mehr Informationen dazu gibt es unter http://bpm-alliance.org oder auch in unserem Whitepaper „BPM/SOAgil“.
