Freitag, 30. Januar 2015

Geschäftsprozesse mit den eigenen Augen sehen.

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.


Wenn wir die BPMN zur Modellierung von Geschäftsprozessen im Requirements Engineering benutzen, dann kommen wir mit einer beschränkten Menge von Modellelementen aus. Welche wir verwenden, bleibt uns überlassen. Auch bei der Syntax können wir manchmal ein Auge zudrücken. Am Ende soll das Bild allgemeinverständlich sein, zumindest unter denen, die damit arbeiten wollen. Zwischen dem Fachbereich und dem Entwicklungsbereich sollte es unbedingt ein klärendes Gespräch über die zu verwendenden Symbole und deren Bedeutung geben. Unterschiedliche Auslegungen des Gesehenen führen nur zu Verwirrungen die wesentlich mehr Zeit kosten.




Eines der wichtigsten Elemente der BPMN ist die Aufgabe, von denen mehrere im Teilprozess zusammengefasst werden können. Ein Mitarbeiter hat die wichtige Aufgabe jeden Tag mehrere Briefe zu schreiben, danach beschriftet er die Umschläge und steckt die Post am Ende in den Briefkasten. Natürlich steckt er das Geschriebene auch in die Umschläge und klebt die Umschläge zu. Da der Briefkasten wahrscheinlich auch nicht in seinem Büro steht, muss er einen Weg zurücklegen. Das grobe Modell kann also mehr und mehr verfeinert werden. Mit jeder Überlegung wird die Wirklichkeit besser abgebildet. Die Diskussion im Team deckt Schritte auf, wo wir vorher keine gesehen haben. Doch das Schönste ist, dass wir mit einem Blick auf das Modell den Zusammenhang erfassen. Über verschiedene Hierarchiestufen können wir in das Modell einsteigen. Zuerst erkennen wir Teilprozesse. Interessieren wir uns für den Teilprozess Post erledigen, dann können wir eine Stufe tiefer gehen und uns die Aufgaben des Teilprozesses ansehen.

Mithilfe von Teilprozessen und Aufgaben stoßen wir jedoch schnell an unsere Grenzen. Auch im oberen Bild sind wir nicht mit diesen zwei Elementen ausgekommen. Wir haben außerdem einen Sequenzfluss verwendet, ein Start- und ein Endereignis. Am Anfang eines Prozesses steht das Startereignis. Hier wird eine Marke geboren, die Schritt für Schritt vorwärts kommt. Der Sequenzfluss, in Form der Pfeile, zeigt die Richtung in die die Marke wandert. Am Ende wird sie im rot umrandeten Endereignis wieder geschluckt und die Arbeit ist getan. Während des Prozesses können auch andere Ereignisse auftreten. Da gäbe es zum Beispiel das Zeitereignis. Ein auslösendes Startereignis kann auch ein Zeitereignis sein, genau wie ein weiteres Zwischenereignis inmitten des Prozesses. Im unteren Bild wird der Prozess um 7 Uhr ausgelöst, danach trinkt die betreffende Person einen Kaffee und isst danach ein Brötchen. Da er jedoch genau um 9 Uhr mit der Arbeit beginnt, sorgt ein weiteres Ereignis für einen pünktlichen Arbeitsbeginn.



Eine weitere wichtige Sache ist die Möglichkeit Teilprozesse parallel abzuarbeiten. Dazu benötigen wir Gateways. An einem Gateway muss sich unsere Marke entscheiden welchen Weg sie nehmen will oder sie vermehrt sich und arbeitet Teilprozesse parallel ab. In dem kleinen Beispiel muss sich die Marke entscheiden, ob sie den Weg des geringsten Widerstandes geht oder den schweren Weg. Im Prozess darunter werden aus einer Marke zwei und sie arbeiten zur gleichen Zeit die Gulaschzubereitung und die Kloßzubereitung ab. Auf der anderen Seite stoppt der Prozess solange bis beide Marken fertig sind und sich im zweiten Gateway wieder vereint haben. Dann kann es im Gesamtprozess wieder weiter gehen und das Essen wird aufgetragen.



Ein weiteres wichtiges Element ist der Pool. Ein gut organisierter Pool hat mehrere Lanes, in denen die unterschiedlichen Schwimmer ihre Bahnen ziehen können. Ein Pool repräsentiert eine Organisationseinheit, beispielsweise einen Betrieb. Die Lanes können verschiedene Personen im Betrieb sein, die gemeinsam einen Geschäftsprozess abwickeln. Natürlich können während dieses Prozesse auch Informationen zu anderen Organisationseinheiten gelangen. Diese können jedoch nur über Nachrichtenflüsse erreicht werden. In unserem kleinen Beispiel schreibt die erste Person einen Brief, die zweite steckt ihn ein, löst damit eine Nachricht an die Post aus. Die macht dann irgendetwas damit und nach einiger Zeit sendet sie uns eine Rückantwort. Die zweite Person empfängt den Rückantwortbrief, vermerkt ihn in einem Register und übergibt den Brief an die erste Person zum lesen.



Nachdem wir uns ein wenig die Möglichkeiten von BPMN angesehen haben, kommen wir zum operativen Prozessmodell für unseren Gulasch. Darin werden wir viele der besprochenen Modellelemente wiederverwenden. Doch für ein vernünftiges Rezept gehört es sich die Zutaten aufzuzählen:

Zutaten für 4 Personen
  • 500g Zwiebel
  • 3 Knoblauchzehen
  • 3 Eßl. Öl
  • 750g Rindfleisch
  • 3 Eßl. Paprikapulver
  • Salz
  • Pfeffer
  • 0,5 l Fleischbrühe
  • 400g rote Paprikaschoten
  • 4 Eßl. Tomatenmark




Es geht mir in diesem Artikel nicht darum die BPMN zu erklären. Dazu gibt es vielfältige Fachliteratur. Ich möchte jedoch dafür plädieren, sie im Requirements Engineering, speziell in der Systemkontextanalyse, einzusetzen. Außerdem wollte ich zeigen, dass sie ein geeignetes Mittel zur visuellen Darstellung von Geschäftsprozessen ist. Und zum Schluss empfehle ich noch einmal die beiden Bücher, die sich für einen schnellen und guten Einstieg bestens eignen.

  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


vorheriger Post dieses Themas


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

1 Kommentar:

  1. BPMN im Requirements Engineering macht durchaus Sinn. Und ich will es auch gleich einschränken: macht Sinn im Kontext der Konzeption eines Prozess-unterstützenden IT-Systems.
    Das Problem für die Diskussion mit den fachlich verantwortlichen ist ja immer, dass Sie eine solche Modellierungssprache nicht in allen Details kennen und in kurzer Zeit erlernen können.

    BPMN ist sicher nicht kompliziert. Aber kein "normaler" Mensch kann sich die 7 verschiedenen Gateways merken und sie in einem Workshop fachlich sicher anwenden. Oder die 4 verschiedenen Aktivitäts-Formen. Mit "normalen" Menschen meine ich wie immer den Kollegen aus der Fachabteilung, der seit 15 oder 20 Jahren im Unternehmen arbeitet.

    Daher arbeite ich in Workshops mit der Fachabteilung zunächst mit einfachen Swimlanes für die Prozessabläufe.
    Die systemrelevanten Details, für die man eine detailliertere Notation braucht, kläre ich dann meistens "bilateral" mit Fach- und Systemverantwortlichen.
    Oder ich bereite eine Version vor, die dann durch die Workshop-Teilnehmer nur noch angepasst werden muss.

    Ich habe mal in einem Internet-Startup gearbeitet - da hätte ich das nicht so machen müssen, weil die Mitarbeiter irgendwie alle sehr "IT-affin" waren. Aber in klassischen Unternehmen kann man da nicht drauf setzen.

    AntwortenLöschen