Geschäftsprozesskomponenten
Im folgenden betrachten wir die Bauteile, aus den die Geschäftsprozesse zusammengestellt und organisiert werden - die Geschäftsprozesskomponenten.
Geschäftsprozessbündel
Ähnlich der Strukturierung in Kontinente und Länder, können auch Geschäftsprozesse in fachlicher Hinsicht gruppiert werden. Dabei ist analog ein sogenanntes GP-Bündel die fachlichen Gruppierung mehrerer Geschäftsprozesse.
Konvention: Zur besseren Unterscheidung werden Namenskürzel für Kontinente und Länder groß, die für GP-Bündel und Geschäftsprozesse klein geschrieben.
Ggf. methodisch interessant zum Auffinden von Geschäftsprozessbündeln:
https://der-prozessmanager.de/aktuell/wissensdatenbank/prozesslandkarte
Szenarien
Wie Länder, sollen auch Geschäftsprozesse in verschiedenen Szenarien eingesetzt werden können (z.T. mit leichten Abwandlungen). In diesem Sinne kann die Software-Lösung für ein Szenario als abgestimmte Zusammenstellung der benötigten Geschäftsprozesse mit den von diesen verwendeten Ländern verstanden werden.
Geschäftsprozesse
Geschäftsprozesse sind Arbeitsabläufe, die über Ländergrenzen hinweg operieren.
In Schleupen.CS werden Geschäftsprozesse durch Workflows und Dialogabläufe abgebildet. Dabei stellen die Subdomänen (Länder) Services und Business Events bereit, die von den Geschäftsprozessen genutzt werden.
Transkontinentale Geschäftsprozesse
Im Sinne der fachlich / organisatorischen Zuordnung ist es in einigen Fällen sinnvoll, die Geschäftsprozesse einer Anwendungsdomäne (einem Kontinent) zuzuordnen. Demnach gehören zu einer Anwendungsdomäne die Länder eines Kontinents und die zugeordneten Geschäftsprozesse.
In vielen Fällen, typischerweise bei den wichtigen Haupt-Geschäftsprozessen des Kunden, gehen diese aber über Domänengrenzen hinaus - d.h. sie sind im CS-Sprachgebrauch transkontinental. Diese Prozesse verbinden verschiedene Anwendungsdomänen.
Geschäftsprozessabschnitte
Geschäftsprozesse können in mehreren GP-Abschnitte unterteilt werden. Es gibt zwei wesentliche Gründe dies zu tun:
- Um GP-Abschnitte eindeutig einer Domäne oder Subdomäne zuordnen zu können und eine klare Regelung für die Verantwortlichkeit zu finden.
- Um GP-Abschnitte in mehreren Geschäftsprozessen nutzen zu können (DRY-Prinzip).
Geschäftsprozesskomponenten
Die für einen Geschäftsprozess oder GP-Abschnitt notwendigen Artefakte (Workflows und Dialogabläufe) werden von Geschäftsprozesskomponenten (GP-Komponenten) zusammengehalten. Um die Wiederverwendung zu unterstützen, Demzufolge kommt es vor, dass GP-Komponenten nicht alle Teile des gesamten Geschäftsprozesses enthalten, sondern "nur" alle eines GP-Abschnitts.
Eine oder mehrere Geschäftsprozesskomponenten setzen zusammen einen Geschäftsprozess um.
Modellierung von Geschäftsprozessen
Prozesse in Schleupen.CS werden in BPMN 2.0 modelliert. Sie nutzen Services und Business Events der Länder. Dieses bezeichnet man als Orchestrierung.
Die durch Schleupen.CS 3.0 umgesetzten Geschäftsprozesse werden mit Hilfe der Business Process Model Notation Version 2.0, kurz BPMN beschrieben. BPMN ist eine Spezifikationssprache zur Modellierung und Dokumentation von Geschäftsprozessen. Schleupen.CS verwendet BPMN sowhl zur Modellierung von Workflows, als auch für Dialogabläufe.
Die Verwendung von Workflows zur Orchestrierung ist getrieben durch die Anforderungen, alle Bausteine und Abläufe von Schleupen.CS anpassen zu können. Der Ablauf der Prozesse ist bei Choreographie einfacher nachvollziehbar. Weitere gehende Informationen hierzu: Orchestration vs choreography.
Siehe: Exkurs BPMN
Blaue Diagramme / fachlicher Kontext
Spricht man mit unterschiedlichen Stakeholdern und Personen die am Prozess beteiligt sind, stellt man fest, dass diese einen Geschäftsprozess aus unterschiedlichen Perspektiven und insbesondere in unterschiedlicher Granularität beschreiben.
Der im Bild dargestellte Beschwerdeprozess ist auf einer "sehr hohen Flughöhe". Die Darstellung ist geeignet, um ein erstes Verständnis des Geschäftsprozesses zu erhalten, nicht jedoch, um daraus Software zu generieren.
Wir bezeichnen solche BPMN-Diagramme als Blaue Diagramme. Sie liefern den fachlichen Kontext, d.h. einen Überblick über die zu erstellende Software zur Umsetzung des Geschäftsprozesses und dessen Umgebung.
Der Name Blaues Diagramm ist eine Schleupen Wortschöpfung und kein allgemein in der IT verwendeter Begriff. Er entstand dadurch, dass das für die Erstellung der ersten Prozesse genutzte Tool, diese im Standard blau einfärbte. Da durch die blaue Farbe die Assoziation zu einer Blaupause oder einem Blueprint nahe lag, hat sich der Begriff bei uns für BPMN-Modelle von Geschäftsprozessen mit "hoher Flughöhe" gehalten.
Schrittweise Verfeinerung
Um aus einem Blauen Diagramm ein ausführbares BPMN Modell zu entwickeln, wird dieses im Verlauf der Entwicklung verfeinert und ggf. in Geschäftsprozessabschnitte (Workflows und Dialogabläufe) zerlegt. Für jeden dieser GP-Abschnitte existiert dann ein eigenes, detailliertes BPMN Modell, aus dem Software generiert werden kann.
Die BPMN-Modelle von Workflows und Dialogabläufen in Schleupen.CS können als Quelltext für die Generierung von Workflows und Dialogabläufen verstanden werden. Dabei achten wir darauf, keine technischen Details über die Ausführungsebene (WF-Engine, UI-Engine) in die Modellierung aufzunehmen. Diese Abstraktion sorgt für die Entkopplung der fachlichen von technischen Ebene und ermöglicht es uns im Sinne des Investitionsschutzes Änderungen an der technischen Ausführungsebene vorzunehmen, ohne die fachliche Modellierung zu invalidieren.
Da Schleupen.CS eine geschäftsprozessorientierte Plattform ist, machte es methodisch Sinn, mit der Modellierung der Geschäftsprozesse zu beginnen (Blaue Diagramme). Durch die Schrittweise Verfeinerung bis zu einem ausführbaren Modell aus GP-Abschnitten, findet man die über die Aktivitäten für die Ausführung nötige Services, Business Events, Aufaben, Jobs , ...
Siehe:
- Workflows
- Aufgaben
- Services
- Jobs
Direkt-Start und Start per Event
Für die Modellierung ist es ebenfalls wichtig, ob der Workflow direkt, d.h. unmittelbar gestartet werden soll oder als Seiteneffekts eines Business Events. Der Direkt-Start wird als sogenannter ProcessService modelliert und implementiert. Soll der Workflow als Resultat eines Ereignisse gestartet werden, so muss dieser eine EventService-Schnittstelle implementieren.