Freitag, 16. Januar 2015

Geschäftsprozesse kann man in Worten beschreiben, man kann es aber auch sein lassen.

These: Systemkontextanalyse öffnet die Augen für optimale Software

Praktischer Modellentwurf für Prozesse.

Artikelübersicht
1. Teil Geschäftsprozesse kann man in Worten beschreiben, man kann es aber auch sein lassen.
2. Teil Geschäftsprozesse mit den eigenen Augen sehen.


In meiner Reihe zur Systemkontextanalyse habe ich Modelle für die Stakeholderanalyse und für das Erfassen von Dokumenten erläutert. Damit können zwei wesentliche Kontextaspekte in geeigneter Weise beschrieben werden. Ein weiterer Kontextaspekt ist der Prozess. Im Artikel Welche Arten von Kontextobjekten gibt es? habe ich den Prozess wie folgt definiert: "Ein Prozess ist eine Aktivität zur Verarbeitung von Eingangsdaten. Die Beschreibung des Algorithmus dieser Verarbeitung bildet die Abbildung des Prozesses." Daraus können wir schlussfolgern, dass wir ein Modell benötigen, welches Algorithmen abbilden kann. Die Business Process Modeling Notation (BPMN) ist genau so eine Möglichkeit. BPMN ist ein Standard der OMG (Object Management Group). Im Jahre 2011 wurde die BPMN 2.0 als Standard verabschiedet.

Tim Weilkiens, Christian Weiss und Andrea Grass haben das Buch "Basiswissen Geschäftsprozessmanagement" geschrieben, mit dem man sehr effektiv für den Zertifizierungsprozess zum OMG Certified Expert lernen kann. Es ist jedoch auch möglich das Buch einfach so zu lesen, sich seine eigenen Gedanken zu machen und die Modellnotation in seinem eigenen Alltag anzuwenden. [WEIL10] beschreibt die Ziele der BPMN wie folgt: "
  • Es existiert eine standardisierte grafische Notation zur Modellierung von Geschäftsprozessen.
  • Die Notation ist für alle Stakeholder – angefangen vom Business Analyst bis zum Prozessimplementierer – verständlich.
  • Die Notation lässt sich auf eine ausführbare XML-basierte Prozesssprache (wie z.B. Business Process Execution Language for Web Services (BPEL4WS) abbilden.)“ [S.94, WEIL10]



In Berlin sitzt die Firma Camunda Services GmbH. Die Gründer der Firma, Jakob Freund und Bernd Rücker, haben in ihrem Buch "Praxishandbuch BPMN 2.0" ein Methoden-Framework für BPMN entwickelt, das camunda BPMN-Framework (caBPMN). Dieses Modell erläutert, wie man über vier Ebenen eine Prozesslandschaft mithilfe der BPMN analysieren kann. Auf der untersten Ebene, der Ebene 1, wird ein strategisches Prozessmodell gebildet. "Es geht darum, eine grundsätzliche, ereignisorientierte Darstellung von Prozessen zu liefern. Der Hauptanspruch liegt auf einem schnellstmöglichen Verständnis des groben Ablaufes, ohne dass spezielle BPMN-Kenntnisse nötig wären." [S.16, FREUND10] Wir beschreiben Prozesse also aus einer groben fachlichen Sicht. In der Ebene 2 bleiben wir in der fachlichen Perspektive. Hier wird ein operatives Prozessmodell erstellt. "Hier betrachten wir die operativen Details der tatsächlichen Abwicklung." [S.16, FREUND10] Zur Beschreibung von Kontextobjekten aus fachlicher Sicht ist diese Ebene ausreichend. Ebene 1 und 2 bilden eine sinnvolle Hierarchie von Kontextobjekten. Ebene-1-Kontextobjekte beschreiben Prozesse in einer Überblicksstruktur, Ebene-2-Kontextobjekte leiten sich aus diesen ab und beschreiben die konkreten Arbeitsschritte.

Ebene 3 und 4 des Modells sind technische Ebenen und gehen schon weit in die Implementierung der Prozesse hinein. Ich möchte sie trotzdem kurz beschreiben, um deutlich zu machen, wie man die BPMN über das Requirements Engineering hinaus bis in die Architektur und Implementierung benutzen kann. Hier wird deutlich, wie eine Modellsprache über die einzelnen Entwicklungsschritte verbindend wirken kann. Auf der Ebene 3 kann man entweder ein technisches Prozessmodell oder eine IT-Spezifikation erstellen. Das technische Prozessmodell ist eine Verfeinerung des operativen Prozessmodells. Es muss so genau abgefasst werden, dass es möglich ist, es in einer Process Engine ablaufen zu lassen. Hat man nicht die Möglichkeit eine Process Engine zu benutzen, entwickelt man eine IT-Spezifikation. Diese bildet dann auf der Ebene 4, wo sonst die Process Engine wäre, die Grundlage für eine eigene Implementierung.

Dieses Methoden-Framework zeigt sehr schön ein zusammenhängendes Denken in der Entwicklung von Software auf, welches Requirements Engineering, Softwarearchitektur und Implementierung im Zusammenhang denkt. Eine Umsetzung ohne Bestimmung was umzusetzen ist, wäre kaum möglich. Man wird gezwungen bestimmte Schritte nicht auszulassen. Die Modellsprache bietet außerdem ein gemeinsames Denkmodell, welches man mehr oder weniger leicht erlernen kann. Sicherlich ist die Anwendung auf technischer Ebene wesentlich schwieriger als auf fachlicher Ebene. Aber gerade das bietet die Voraussetzung, sie auf fachlicher Ebene zu benutzen. Man wählt eine geeignete Menge von Elementen der Sprache aus, gleicht deren Bedeutung in der Arbeitsgruppe ab und entwickelt gemeinsam Prozessabläufe.

In einem Prozessmodell, welches mithilfe der BPMN erstellt wurde, muss man auf Universalquantoren, wie alle, jeder, sämtlich oder nirgends, verzichten. Auch sinnlose Füllinformationen, die in so manchen Pflichtenheften die eigentliche Information verdecken, entfallen einfach ersatzlos. Das Ebenenmodell und die grafische Visualisierung erleichtern in ungemeiner Weise den Zugang zur Information. Anstatt langweilige Texte mit ungenauen Formulierungen zu lesen, sieht man bildliche Information, erfasst Zusammenhänge viel schneller und kann Falschinformationen schneller auffinden und bereinigen. Einem kurzen strategischen Modell für die Zubereitung von ungarischen Gulasch entnehmen wir vier Schritte, die wir in jedem Fall durchführen müssen. Sie springen uns geradewegs ins Auge. Es ist eine konzentrierte Information. Später haben wir die Möglichkeit ein operatives Modell anzufertigen, welches genau beschreibt, was wir in den einzelnen Arbeitsschritten tun müssen.



Im nächsten Post dieser Reihe werden wir die Modellelemente kurz besprechen, die sich für die strategische und operative Ebene lohnen. Ein genau definierter Vorrat an Elementen und deren besprochene Bedeutung ist die Grundlage gemeinsamer Arbeit. Die zunehmende Akzeptanz der BPMN ermöglicht damit eine gemeinsame Sprache zwischen den verschiedenen Fachbereichen. Mithilfe dieser Absprachen werden wir das operative Modell zum Zubereiten des ungarischen Gulaschs entwickeln. Die OOSE hat mit der BizMod eine ganzheitliche Geschäftsprozessmodellierung entworfen. Dabei wird das BPMN-Modell durch UML-Diagramme ergänzt. Mit der UML steht eine weitere anerkannte Modellierungsmethode zur Verfügung. Beispielsweise werden Datenzusammenhänge mit Klassendiagrammen sichtbar gemacht. Klassendiagramm und das Prozessdiagramm werden dann miteinander verbunden und machen so Prozess- und Datenabbildung visuell sichtbar. Tiefer möchte ich an dieser Stelle nicht auf diese Idee eingehen. Bleibt jedoch festzuhalten, dass verschiedene Modellarten verschiedene Zusammenhänge sichtbar machen (z.B. Daten, Status, Prozesse, …) und das diese Informationen in einem größeren Kontext sinnvoll miteinander verbunden werden müssen.

Bleibt die Überschrift: Geschäftsprozesse kann man in Worten beschreiben, man kann es aber auch sein lassen. Damit möchte ich Sie auffordern soviel an Information wie möglich zu visualisieren und so wenig Freitext wie möglich zu schreiben. Freitexte schreiben ist viel schwieriger als man glaubt. Er ist wesentlich schwerer qualitativ abzusichern. Ganze Stapel schwer verständlicher Spezifikationen beweisen diesen Umstand. Das Einfache ist das Schwere und ein Zeichen kollegialer Freundlichkeit ist es, einem Kollegen eine Spezifikation zu überreichen, die er verstehen kann. Der Sinn von Zusammenarbeit muss ein möglichst einfacher Informationsfluss und das Erhalten von Information sein.

  1. [FREUND10] Jakob Freund, Bernd Rücker: "Praxishandbuch BPMN 2.0", 2. aktualisierte Auflage, Carl Hanser Verlag, München, 2010
  2. WEIL10] Tim Weilkiens, Christian Weiss, Andrea Grass: "Basiswissen Geschäftsprozessmanagement", 1. Auflage, dpunkt.verlag GmbH, Heidelberg, 2010


folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Kommentare:

  1. Schöne Artikel! Kenne die Bücher und Werke auch, sind durchaus für Einsteiger oder neutrale Leser geeignet. Eine Visualisierung der Prozesse über Prozessmodelle, sei es nun in BPMN oder z.B. EPK oder WKD, bietet immer eine Menge Vorteile!
    Aus BPM-Sicht sage ich aber auch immer: Besser schriftlich als gar nicht dokumentiert. Das Motto dazu: "Ein Prozess, der nicht dokumentiert ist, ist auch kein Prozess".
    VG BeRu

    AntwortenLöschen
  2. Wer kennt das Visualisierungs-Tool ViFlow? Ist das für Prozess-Visualisierungen brauchbar?

    AntwortenLöschen
    Antworten
    1. ja, absolut! Ist eigentlich ein reines Modellierungstool.

      Löschen
    2. Was bedeutet "ein reines Modellierungstool"? Was gibt es denn sonst noch?

      Löschen
    3. z.B., BPM-Engines, die einen Workflow automatisieren...BPM-Suites, die enthalten so alles was es rund um das Thema Prozessmanagement abzubilden gibt...etc.

      Löschen
  3. Danke für diesen Artikel. Ich denke auch ... ganz ohne natürlicher Sprache gehts dann doch nicht. Zumal oft (zumindest meiner Erfahrung nach) der Fachbereich der Leser einer Anforderungen ist. Wir haben uns bei der Modellierung mit dem Kunden auf eine ausreichendes und schnell verständliches Set an Artefakten verständigt und ergänzen in der Regel an notwendigen Stellen mit natürlicher Sprache. @BeRu .. tolles Motto !!
    Grüße

    AntwortenLöschen
    Antworten
    1. Danke! Stimme ich auch voll zu....der Mix macht es...und da kommt es auf den "Endkunden" an, also den "Leser".

      VG BeRu

      Löschen