Der Prozess-Steckbrief

Nicht nur beim Aufbau einer Prozesslandkarte, sondern immer dann wenn man über Prozesse redet, ist es sehr hilfreich zu beschreiben was eigentlich “der Prozess” ist. Hierfür findet man zum Beispiel das SIPOC-Diagramm aus dem Six Sigma. Im SIPOC-Diagramm werden alle wesentlichen Bestandteile eines Prozesses beschrieben:

S – Supplier (Lieferant
I – Inputs (Einsatzfaktoren)
P – Process (Prozess)
O – Output (Ergebnisse)
C – Customer (Kunde)

Bei Bedarf lässt sich ein solches Diagramm natürlich um den jeweiligen Informationsbedarf erweitern. Einige weitere Informationen könnten sein: Ziele, Applikationen, Rollen, Standorte, KPI, Prüf- & Messverfahren, Stellschrauben für Verbesserungen und vieles mehr. Bei der Erweiterung des SIPOC sollte man darauf achten, dass der komplette Prozess-Steckbrief immer noch lesbar auf eine DIN A4 Seite passt, bzw. sich in eine Präsentation (z.B. mit MS PowerPoint) einbinden lässt.

the_process

Elemente eines Prozesses

Wenn man mehrere Prozesse beschreibt können als Lieferant und Kunde auch die vor- und nach-gelagerten Prozesse erfasst werden. Somit ergibt sich nach und nach über die Steckbriefe ein Netzwerk von Prozessen.

BPMN 2012 und BPMN-Anwendertag an der WU Wien

Zwei spannende Tage in Wien sind vorüber und ich konnte einige interessante Informationen mitnehmen. Herausragend waren die drei  Key-Notes von Jan Recker, Steven A. White und Jakob Freund. Im Blog von Prof. Dr. Allweyer findet man eine gute Zusammenfassung der Vorträge.

Welche Aspekte habe ich von der BPMN 2012 mitgenommen?

Aus den Vorstellungen der wissenschaftlichen Forschung rund um BPMN habe ich gelernt, dass ein allgemeines Bedürfnis an Erweiterungen zur BPMN besteht. Sei es um Datenqualitäts- oder Sicherheitsaspekte mit in den Prozessen darzustellen oder um erweiterte Problemstellungen im Prozessmodell darzustellen (z.B. wenn mit 3 verschiedenen Aktivitäten gemeinsam versuchen ein optimales Ergebnis zu erzielen). Hierbei kommt es aber schnell zum Überfrachten der Prozessmodelle mit zusätzlichen Artefakten.

Eine spannende und kontrovers diskutierbare Aussage von Jan Recker zum Thema „Stand der BPMN Forschung“ ist, dass die Forschung zur BPMN einen hohen Reifegrad erreicht hat und die meisten offenen Fragen und Probleme rund um die BPMN bereits geklärt sind. Soweit die Theorie. In der Praxis sehe ich noch genügend offene Punkte wie und ob überhaupt die theoretischen Konstrukte abgebildet werden können. Reicht es wenn die wissenschaftliche Betrachtung „abgeschlossen“ ist? Welchen Nutzen ziehen die BPMN Anwender hieraus? Die wissenschaftlichen Ergebnisse den Anwendern und Toolherstellern „über den Zaun zu werfen“ ist doch nur die halbe Miete. Es sind noch genügend offene Fragen zu klären. Ja, wir benötigen Visionäre, die weiter denken, die größer denken und zu neuen Ufern aufbrechen um die „Unkown Unkowns“ zu erforschen. Aber auch viele der „Known Knows“ müssen noch zur „Serienreife“ gebracht werden.

Der Bericht von Stephen A. White gibt mir Zuversicht, da aktuell keine BPMN 3.0 Version in Planung ist. Warum ist das gut? Zum einen haben die Toolhersteller so mehr Sicherheit in Hinblick auf ihre Investitionen in die BPMN 2.0, da in den nächsten Jahren keine wesentlichen Änderungen zu erwarten ist. Zum anderen profitieren auch die Anwender, das Business, welche einen hohen Aufwand in die Erstellung von Prozessmodellen mit BPMN 2.0 stecken und diese nicht kurzfristig mit einem Migrationsaufwand zu einer neuen BPMN-Version konfrontiert werden. Außerdem kann man noch genügend Erfahrung sammeln. Die BPMN 2.0 ist erst 1,5 Jahre alt und die ersten Tools mit BPMN 2.0 Unterstützung sind noch jünger. Die Erfahrung der Anwender in Hinblick auf die BPMN 2.0 als DIE Standardnotation für die Prozessmodellierung beschränkt sich daher auf diesen kleinen Zeitraum. Darüber hinaus wurden einige Ideen für mögliche Weiterentwicklungen präsentiert. Die BPMN könnte durch die CMMN (Case Management Model and Notation) beeinflusst werden. Hier wurde konkret der Bereich der Ad-hoc Prozesse angesprochen. Darüber hinaus hat Steve Ideen zum „Service Level Behaviour“ vorgestellt. Wenn ich das richtig verstanden habe ist damit die Beschreibung des Screenflow zu einem BPMN Task gemeint. Offen hingegen bleiben die Punkte Process Architecture, bzw. Prozess Mapping, also wie Prozesse untereinander besser verknüpft werden können. Die ist u.a nützlich um in komplexe Prozess Kollektionen einzelne Prozesse miteinander in Beziehung zu setzten. Dieses Thema geht in die Richtung der Prozesslandkarten und ist aktuell nicht im Fokus der BPMN. Man sollte überlegen ob ein Erstellung eines „Prozess Architektur Framework“ nicht eine interessante Ergänzung für die BPMN Anwender wäre.

Im Vortrag von Jakob Freund zum Thema „BPMN Guidelines“ wurden einige Ideen und Erfahrung angesprochen, die er mit seinen Kollegen rund um das Thema BPMN gemacht haben. Im Wesentlichen keine „Raketenwissenschaft“ aber dennoch viele kleine wichtige Schritte die sich in den Projekten als Erfolgsfaktoren herausgestellt haben.  Eine interessante Ergänzung zum Camunda BPMN Framework ist, dass die Ebenen 2 und 3 eher als eine Ebene betrachtet werden soll – der Ebene „Zweidrei“ – um Business und IT näher zusammenzubringen. Hier sollte es nur EIN Modell geben, welches von beiden Seiten genutzt werden kann. Zum einen um die Kommunikation zwischen den Bereichen zu stärken aber auch um eine agilere Prozessimplementierung zu gewährleisten.

Insgesamt war es eine sehr gut organisierte Veranstaltung, daher auch meinen Dank an die Organisatoren und Moderatoren für die gelungene Durchführung. Alle wissenschaftlichen Vorträge findet man im Buch Business Process Model and Notation: 4th International Workshop, BPMN 2012, Vienna, Austria, September 12-13, 2012, Proceedings (Lecture Notes in Business Information Processing).

Im Team einheitlich modellieren – geht das?

Wer im Team arbeitet kennt das vermeintliche Problem: Jedes Teammitglied denkt, redet und speichert Informationen anders. Die Sichtweisen auf ein Problem oder eine Lösung können variieren. Dies ist auch gut und nützlich: Eine schöne Übung, die zeigt dass Teamergebnisse besser sind als Einzelergebnisse, ist das Gruppen-Experiment „NASA-Game“. In der Regel ist die Entscheidung der Gruppe um einiges besser als die Entscheidung des Einzelnen. Doch wenn es darum geht gemeinsam ein Ergebnis zu erzeugen (z.B. ein Dokument oder ein Modell) und dieses Ergebnis aus Teilergebnissen der einzelnen Teammitglieder besteht, erkennt man häufig, dass das Gesamtergebnis irgendwie nicht aus „einem Guss“ ist. Angefangen bei einfachen Sachen die z.B. die Zeitform, aktive oder passive Formulierungen, direkte Ansprache (Sie) oder indirekte Formulierungen (z.B. man), Aufbau der Abschnitte, Formatierung etc. bis hin zu komplexen Sachen wie Satzbau, Wortschatz für Formulierungen, Visualisierung von Sachverhalten können signifikante Unterschiede in den erstellten Inhalten der einzelnen Teammitglieder auftreten. Bei einer nicht sauberen Abgrenzung der Aufgaben kann es zusätzlich zu Redundanzen kommen oder gar inkonsistente Inhalte produziert werden. Für den Empfänger eines solchen Ergebnisses ist es in der Regel aber vorteilhaft wenn alles zusammenpasst. Dies wirkt qualitativ hochwertiger, lässt sich leichter verstehen, weiterverarbeiten und pflegen.

Wie kann man mit solchen Unterschieden im Team umgehen. Ich möchte mich hier konkret auf die Prozessmodellierung mit BPMN beziehen und ein paar Lösungsansätze vorstellen. (weiterlesen …)