Wer hat das nicht schon mal erlebt? (Gern und besonders schlimm in großen Projekten): Der Fachbereich formuliert Wünsche und weil die IT diese ja niemals verstehen würde, gibt es diverse Proxies, die das Geschwafel des Fachbereichs übersetzen. Dieses ist natürlich viel zu unkonkret und oberflächlich. Es gibt Business Analysten, die Fachkonzepte schreiben, Modellierer und Architekten, die alles genau durchdenken und in Modelle (häufig UML) gießen, so dass die Entwickler nur noch programmieren müssen. Im Gutfall gibt es dann noch Tester, die die Ergebnisse der Entwickler verifizieren und an den Fachbereich zurückmelden. Im Schlechtfall geht die Kommunikation die ganze Kette vom Entwickler über Architekten und Business Analysten zurück zum Fachbereich. Denn natürlich versteht dieser das Entwickler-Kauderwelsch ebensowenig.
Klingt irgendwie unagil und falsch? Ist es auch. Warum es gerade bei BPM-Projekten so nicht laufen muss, erkläre ich im Folgenden.
Stille Post in Projekten. Kann man machen, ist dann halt…
Doch vorher möchte ich nochmal vertiefen, warum das oben beschriebene Szenario so unglücklich ist. Es spiegelt nämlich das klassische Stille-Post-Prinzip wider. Fachbereich und IT sprechen nicht die gleiche Sprache – das ist erstmal nicht ungewöhnlich – und deswegen werden „Übersetzer“ installiert. Doch schon in der Mutter aller Kommunikationsmodelle, dem von Shannon und Weaver von 1948, wird deutlich: Kommunikation zwischen Sender und Empfänger (sprich: Fachbereich und Business Analyst, Business Analyst und Architekt, Architekt und Entwickler) unterliegt „Noise“, zu Deutsch „Störungen“. Diese Störungen können die Nachricht dahingehend beeinflussen, dass das, was der Empfänger erhält, nicht mehr das ist, was der Sender gesendet hat. Zudem findet beim Empfänger immer eine Interpretation statt und schnell hat der etwas anderes verstanden, als der Sender gemeint hat. Kurzum: Es ist ganz natürlich, dass bei Kommunikation Verluste auftreten. Das zu vermeiden, ist mit einigem Aufwand verbunden.
Nun kann man sich vorstellen, dass im oben beschriebenen Szenario die Wahrscheinlichkeit, dass die Entwickler genau das entwickeln, was der Fachbereich wollte, einigermaßen gering ist. Wenn die Tester zudem nicht mit dem Fachbereich kommunizieren, testen sie das, was die Entwickler ihnen sagen und was nicht unbedingt den tatsächlichen Anforderungen entspricht. So entstehen lange Feedbackschleifen, bis der Fachbereich den Fehler bemerkt und die Korrektur wiederum beim Entwickler ankommt. Lange Time-to-Market und hohe Kosten sind die Folge.
Agile Methoden versuchen deshalb, Feedbackzyklen zu minimieren und Fachbereich und IT näher zusammen zu bringen, idealerweise sitzen alle im gleichen Team.
BPMN als gemeinsame Sprache
Bei BPM-Projekten wird das durch ein wesentliches Merkmal begünstigt: Es geht um Prozesse! Und für Prozesse gibt es mit BPMN zum Glück eine Notation, die sowohl vom Fachbereich als auch der IT sehr gut zu verstehen und zu erlernen ist. Wird der Prozess von vornherein in BPMN modelliert, kann dies gut von beiden Parteien an einem Tisch passieren und das hat geradezu verblüffend große Vorteile. Zum einen designen Fachbereich und IT den Prozess gemeinsam – das heißt, der Fachbereich tauscht Anforderungen direkt mit den Entwicklern aus und erhält ebenso direkt Feedback bezüglich technischer Machbarkeit, Restriktionen oder ähnlichem. Beide können gemeinsam ein funktionierendes Modell erschaffen, das von allen verstanden und mitgetragen wird.
Zum anderen dient dieses Modell gleichzeitig als Dokumentation – eine aufwändige Prozessbeschreibung in Textform ist oftmals nicht mehr nötig. Und als ob das nicht schon toll genug wäre, kann das Modell – BPMN 2.0 sei Dank – auch noch direkt ausgeführt und sogar getestet werden. Der Fachbereich kann nun sicher sein, dass das, was im Prozess spezifiziert ist, auch das ist, was in der Anwendung passiert.
Und was haben wir dann? Neben kürzeren Zyklen, kürzerer Time-to-Market, weniger Verschwendung und besserer Qualität erreichen wir außerdem ein gutes Business-IT-Alignment. Bingo! Mein Kollege Roman hat das Thema schon vor einiger Zeit hier im Blog behandelt, wer es immer noch nicht glaubt, kann dort direkt weiterlesen ?
