Keep informed?
Subscribe for our newsletter now!

Kick-off: BPM + Scrum

BPM + Scrum?

BPM + Scrum?

BPM umfasst eine Reihe von Paradigmen, Methoden und Technologien, um Geschäftsprozesse zu verbessern bzw. generell zu managen. Scrum ist ein agiles Vorgehensmodell für die Softwareentwicklung, das aber auch generell als Vorgehensmodell, also unabhängig von IT-Themen, genutzt werden kann.

Sowohl BPM als auch Scrum werden immer beliebter. Lassen sich die beiden Disziplinen sinnvoll kombinieren? Wir glauben schon, und haben auch schon erste Versuche in diese Richtung unternommen, da wir nicht nur BPM-Experten sind, sondern auch Scrum-Expertise besitzen und das Thema entsprechend coachen. Ganz ähnlich geht es Dr. Martin Bartonitz von Saperion, und Martin Wieschollek von Seven Principles, und deshalb haben wir drei uns gestern mal bei camunda in Berlin zusammen gesetzt.

Wie man sich denken kann, ist das ein ziemlich großes Fass, das wir da aufgemacht haben. Und der gestrige Vormittag hat bei Weitem nicht gereicht, um das wieder schließen zu können. Deshalb haben wir zwei Dinge getan: Einfach mal gesammelt, welche Themen bzw. Fragen uns bei “BPM + Scrum” durch den Kopf gehen, und uns dann einfach mal welche herausgepickt und darüber diskutiert. Es wurde eine lebhafte und produktive Diskussion, und die ersten Ergebnisse kommen weiter unten.

Das Ganze ist 100% “work in progress”, aber ganz im Sinne von Scrum wollen wir nicht ewig tüfteln für die perfekte Lösung, sondern zeitnah unsere Ideen herausbringen, damit sie diskutiert und vielleicht sogar schon angewandt werden können. Für die Diskussion habe ich ein Forenbrett auf BPM-Netzwerk.de eingerichtet. Aber natürlich sind auch Diskussionen dazu im Rahmen von Events etc. denkbar, z.B. bei der Berliner BPM-Offensive. Ich werde das dort mal anregen.

Wir drei werden uns jedenfalls im März wieder treffen, um weiter zu diskutieren und die nächste Iteration unserer Ideen zu entwickeln. Die Ergebnisse werden wieder geblogged, entweder im Blog von Martin Bartonitz oder im Blog von Martin Wieschollek, je nachdem wer das nächste Mal Gastgeber und somit Moderator ist. Ich werde dann aber natürlich auch auf BPM-Guide.de darauf hinweisen.

BPM + Scrum: Ergebnisse des 1. Workshops (18.02.2010, camunda, Berlin)

Spontane Überlegung am Anfang: Prozessmodellierung ist kein Overhead

Wir sehen grundsätzlich keinen Widerspruch zwischen der Modellierung von Prozessen und dem agilen Manifest. Die zentrale Frage ist einfach, in welchem Umfang man Prozessmodellierung betreibt. Aber ganz unabhängig von User Stories etc. erspart uns ein kleines Prozessdiagramm eine umfangreiche textuelle Prozessbeschreibung, und das ist ist kein Bremser, sondern eine Hilfe für mehr Agilität.

Scope: Was betrachen wir?

Wir konzentrieren uns im ersten Schritt auf BPM-Projekte (Scrum ist ein Vorgehensmodell für Projekte), also weniger den kontinuierlichen Prozessbetrieb o.ä.. Diese Projekte können drei Ausprägungen haben:

  • “Reine” IT-Projekte
  • IT-Projekte mit Orga-Anteil (=> Change Management etc.)
  • “Reine” Orga-Projekte

Auch wenn es die beiden Reinformen wohl kaum gibt, geht es darum, die unterschiedlichen “Ausmaße”, die der Orga- bzw. IT-Teil in einem BPM-Projekt haben kann, zu berücksichtigen.

Themen rund um BPM + Scrum

Das sind die Fragen, die wir uns spontan gestellt haben:

  • Sprint und BPM-Kreislauf bzw. BPM-Projekt: Wie geht das zusammen?
  • Scrum-Rollen im BPM-Projekt?
  • Scrum-Artefakte im BPM-Projekt?
  • Scrum-Zeremonien im BPM-Projekt?
  • User Stories im BPM-Projekt?

Als estes haben wir uns der Sprint-Frage gewidmet.

Sprint und BPM-Kreislauf bzw. BPM-Projekt: Wie geht das zusammen?

camunda BPM-Kreislauf

camunda BPM-Kreislauf


Als Ausgangspunkt haben wir den BPM-Kreislauf von camunda genommen, der ja in ähnlicher Form von verschiedensten Firmen, Hochschulen etc. vertreten wird und noch relativ überschaubar, aber nicht marketing-mäßig trivialisiert ist.

Hier kommt schon das erste Problem: Im Kreislauf ist explizit von einer Phase der Prozesskonzeption die Rede, und danach kommt die Umsetzung. Das riecht verdächtig nach Wasserfall, und tatsächlich ist das ja auch die Denkweise, die dem allgemeinen Paradigma von Konzeption und Umsetzung zugrundeliegt: Erst entwerfe ich ein Haus, dann baue ich es. Spätere Änderungen unerwünscht. Das widerspricht Scrum. Wir sind trotzdem der Ansicht, dass die Prozesskonzeption als Phase erhalten bleiben muss. Hier subsummieren sich viele Tätigkeiten, die einer Prozessverbesserung richtigerweise vorausgehen, z.B. eine ROI-Abschätzung. In der Prozesskonzeption werden unter Umständen überhaupt erst die User Stories ermittelt, die ins Product Backlog eingehen.

Der Soll-Prozess ist nicht in Stein gemeißelt

Der Soll-Prozess ist nicht in Stein gemeißelt

Die Prozesskonzeption muss also erhalten bleiben, aber: Wir flexibilisieren die Umsetzung.
Das heißt, wir gehen generell nicht mehr davon aus, dass die Soll-Konzeption und somit auch das Soll-Prozessmodell nach Abschluss der Konzeptionsphase fixiert ist, sondern dass es sich hierbei nur um eine Version 1.0 handelt. Diese Version 1.0 kann aber im Rahmen der Prozessumsetzung auch überarbeitet werden, dass Soll-Konzept bzw. der Soll-Prozess wird also auch während der Prozessumsetzung noch verändert (siehe Abbildung).

Das klingt jetzt irgendwie banal, aber tatsächlich schafft diese neue Prämisse einen großen Spielraum, aber auch große Herausforderungen. Allerdings genau die Herausforderungen, denen sich Scrum widmet, und für die Scrum ja auch Lösungsansätze bietet.

Nach dieser Grundsatzüberlegung kamen wir zur Gretchenfrage: Wie schneide ich meine Sprints? Ist eine Iteration im Kreislauf ein Sprint? Oder finden mehrere Kreislaufiterationen innerhalb eines Sprints statt? Oder anders herum sogar mehrere Sprints innerhalb einer jeden Phase im Kreislauf?

Die vorläufige Antwort lautet wie so oft: Es kommt drauf an :-(, sprich das Ganze hängt maßgeblich von der Komplexität des Prozesses / der Prozesse bzw. des Verbesserungsvorhabens ab. Aber gehen wir mal von einem typischen “mittelschweren” Vorhaben aus, das sich locker über 6 Monate hinziehen kann. Nach einigen Versuchen, die Sprint=>Kreislauf-Frage “top-down”, also vom Groben zum Feinen, zu diskutieren, mussten wir erstmal aufgeben: Wir kamen nicht so recht weiter, auch wenn unser schönes BPMN-Framework dabei recht schnell eine zentrale Rolle spielte ;-). Nein, wir entschieden uns, “bottom-up” vorzugehen, was die Diskussion sehr schnell konkret werden ließ und sich am Ende als zielführender herausstellte (wie so oft).

Sprich: Wenn wir jetzt mal nur die Phase der Prozessumsetzung anschauen, wie verhält sich diese zu einem Sprint? In einem mittelschweren Vorhaben (3-6 Monate), ist die Konsequenz ganz klar: Die Prozessumsetzung kann sich über mehrere Sprints hinweg ziehen, denn ein Sprint sollte idealerweise 3 oder 4 Wochen dauern, jedenfalls nicht 6 Monate. Diesen Grundgedanken übertrugen wir auf andere Phasen im Kreislauf:

Das Verhältnis von Kreislaufphasen zu Sprints ist häufig 1:N.

OK, spinnen wir den Gedanken für die Prozessumsetzung mal weiter, was müssen wir tun, damit das klappt? Schließlich sind Sprints eine ziemlich abgegrenzte Sache, mit jeweils eigenem Planning etc. Die erste Challenge (neben vielen weiteren) besteht also darin, die Prozessumsetzung in Sprint-fähige Phasen einzuteilen, wir müssen das Ganze “schneiden”. Das wiederum brachte uns zu einer Diskussion, die vorerst ohne Konsens beendet werden musste:

Ist es für die Akzeptanz der betroffenen Prozessbeteiligten (“Process Participants”) besser, wenn mehrere kleine Prozessänderungen erfolgen, oder ist es besser, wenn nur eine große Prozessänderung erfolgt?

Eine interessante Frage, die man vielleicht im Forum diskutieren könnte. Ja klar, es kommt mal wieder drauf an, aber ich selbst tendiere eher zu vielen kleinen Änderungen, als zu einer großen, solange es nicht die Änderungen selbst sind, die wieder geändert werden (denn das führt ja dann zum “heute hü, morgen hott”-Gefühl).

Obwohl wir hier keinen Konsens hatten, konnten wir trotzdem über mögliche “Schnittmuster” für die Prozessumsetzung diskutieren, um diese in Sprints aufzuteilen. Spontan eingefallen sind uns drei Muster:

Parallele Prozess-Stränge: Mitunter findet ein Prozess durch mehrere gleichzeitig ablaufende “Stränge” statt, sodass man die einzelnen Stränge in jeweils eigenen Sprints umsetzen könnte. Ein Beispiel, das Martin Wieschollek hierführ nennen konnte, war die Einschleusung neuer Mitarbeiter, also aus dem HR-Bereich.

Vertikal schneiden: Prozesse lassen sich oft in Phasen aufteilen, also sequentielle Teilprozesse, wenn man so möchte. Beispielsweise Bestellprozesse. Je nach Zeit und “Erlaubnis” kann ich hoffentlich bald ein Projektbeispiel hierzu bringen. Jedenfalls lassen sich diese Phasen bzw. Teilprozesse auf Sprints verteilen, wobei natürlich sicher gestellt werden muss, dass die “neuen” Teilprozesse mit den “alten” Teilprozessen gekoppelt werden können, z.B. über technische Schnittstellen.

Horizontal schneiden: Ein anderer Ansatz wäre, den Prozess end-to-end im ersten Sprint umzusetzen, aber nur für einen bestimmten organisatorischen Bereich, z.B. eine Niederlassung, oder für ganz bestimmte interne oder externe Prozessbeteiligte.

Wir haben uns vorgenommen, in den kommenden Wochen für jede dieser drei Ideen ein Beispiel zu formulieren und das Ganze auf dieser Grundlage weiter zu diskutieren. Martin Bartonitz hat heute direkt mal vorgelegt:

Prozessumsetzung horizontal schneiden: Beispiel von Martin Bartonitz

eBilling / elektronische Rechnung:

Die Implementierung des Signierens von Ausgangsrechnung ist sehr schnell durchgeführt. In der Regel können die Ausgangsdokumente in ein Verzeichnis gespeichert werden. Hier holt sich der Signier-Service die Dokumente ab, verarbeitet sie und legt sie anschließend in ein anderes Verzeichnis ab, ggf. verschickt er die Rechnungen auch schon. Aus diesem Verzeichnis holt sich dann der Import-Service des Archivs die Dokumente ab und speichert diese zusammen mit den ebenfalls zur Verfügung gestellten Indexdaten. Wurden die Dokumente noch nicht verschickt, könnte dies nun auch das Archiv noch durchführen. Alternativ aber auch das ERP, das die Rechnungen erstellt hat.

Schwieriger ist es, die Empfänger dazu zu bewegen, den Empfang auch zu akzeptieren. Denn dieser darf sich auch verweigern. Mann kann nun in mehreren Iterationen nach und nach die Empfänger einzufangen. Eine weitere Möglichkeit ist, eine kleines Unternehmen zu gründen, das die Verifikation der signierten Rechnugnen im Namen des Empfängers durchzuführen. So könnten die Empfänger für das Verfahren gewonnen werden, die aufgrund der geringen Anzahl von Rechnungen aus Kostengründen keinen Inhaus-Service einrichten wollen.

Damit könnte das Schnittmuster wie folgt aussehen:

Iteration #1 Implementierung Verfahren zum Signieren elektronischer Rechnungen (falls kein Archiv vorhanden: Iteration #0)
Iteration #2 Versand der signierten Rechnung an die ersten Geschäftspartner, die schon ihr OK gegeben haben
Iteration #3 Einrichtung Unternehmen zum Verifizieren
Iteration #4 Versand der signierten Rechnung mit Verifikationsbericht an die Geschäftspartner, die den Verifikationsservice nutzen wollen

papierbasierte Rechnungsverarbeitung

Da der papierbasierte Prozess extrem langsam und fehleranfällig ist (verlorene Eingangsrechnugen -> Skonti verpasst), sollen sie gescannt, manuell indiziert, archiviert und über einen Workflow zur Freigabe inkl. gebracht werden.

Damit könnte das Schnittmuster wie folgt aussehen:

Iteration #1 bis #x Implementierung Dokumentenerfassung, Archivierung und Freigabeprozess
Iteration #x+1 Pilot mit erster Niederlassung

Iteration #x+n Ausrollen auf n-te Niederlassung

Viele Grüße
Martin

Scrum-Rollen im BPM-Projekt?

Danach haben wir noch kurz die Rollenfrage andiskutiert, sind aber aufgrund des Zeitlimits nicht sehr weit gekommen. Hier trotzdem mal der aktuelle Stand:

Product Board: Hier werden in Scrum die strategischen Produktentscheidungen getroffen, die der Product Owner in User Stories ausformulieren muss. Der Horizont der Entscheidungen dieses Boards liegt oft bei ca. 6 Monaten. Wenn wir ein ähnliches Gremium für einen oder mehrere Prozesse überlegen, wäre das ein Process Board, dem die Führungskräfte angehören, die den Prozess ganz oder teilweise verantworten, was mit dem Problem der Prozess-Matrixorganisation zusammenhängt. In unserem BPMN-Buch heißen diese Rollen Process Manager. Falls der Prozess nur von einem Process Manager verantwortet wird, bestünde das Board eben nur aus einer Person. Wichtig: Hier wird unter einem Process Manager also wirklich ein Entscheider verstanden, nicht bloß ein Inhouse-Consultant oder Methodenspezialist, das ist viel mehr der Process Analyst (siehe unten).

Product Owner: Die Analogie, die am ehesten zum Product Owner passt, wäre der Process Analyst, zumal dieser als Einziger in der Lage wäre, aus den Soll-Prozessmodellen die notwendigen User Stories abzuleiten.

An dieser Stelle mussten wir aus Zeitgründen einen Cut machen, obwohl sich natürlich gerade bei den Rollen zigtausend weitere Fragen auftun (z.B. Aus welchen Mitgliedern besteht das Scrum-Team, wenn die Verbesserungsmaßnahme ganz oder teilweise aus Change Management, also nicht IT-Umsetzung, besteht? Wie verändert sich die Zusammensetzung des Teams über mehrere Sprints hinweg, z.B. zuerst mehr Entwickler, später mehr Change Manager?).

Aber wie schon gesagt: Unser Anspruch ist es nicht, unangreifbare Weisheiten zu postulieren. Wir wollen einfach nur unsere Überlegungen, Ideen etc. mitteilen, evtl. Hilfestellung und Anregungen dadurch liefern, und natürlich Feedback sammeln und Diskussionen führen. Jedes Workshop-Ergebnis soll, so gut es halt geht, ein Working Increment sein, aber mit Sicherheit nicht der Weisheit letzter Schluss ;-)

Jakob Freund

About Jakob Freund, CEO

Jakob Freund has profound experience in BPM projects, especially in the area of strategic BPM, process modeling and business IT alignment. He is author of the successful book "Real-Life BPMN", founder of BPM-Netzwerk.de and gives lectures at the university of applied science in Zürich and Bern.

Already read?

Why BPMN is not enough

Decision Model and Notation (DMN) – the new Business Rules Standard. An introduction by example.

Free: Camunda BPM Online Training

CMMN – The BPMN for Case Management?

New Whitepaper: The Zero-Code BPM Myth

13 Responses

Leave a reply