Commit 080754e7 authored by Claudia Kaar's avatar Claudia Kaar
Browse files

Merge branch 'master' into 'master'

Subjektorientierte Prozessmodellierung

See merge request !43
parents 5436e797 b8629e55
# Subjektorientierte Prozessmodellierung
## 1. Zusammenfassung
**Subjektorientierte Prozessmodellierung** (Subject-oriented Business Process Modeling) ist ein Modellierungsansatz, sowie ein konstruktives und nachhaltiges Managementskonzept. Im Zentrum des Modelles stehen die im Geschäftsprozess involvierten Akteure und deren Interaktionsverhalten. Diese Modellierungssprache, zur Abbildung der Geschäftsprozesse, verfügt über einen geringen Umfang von Sprachelementen mit großer Ausdrucksstärke. Sie bietet eine Alternative zur BPMN, die über sehr umfangreiche Modellierungselemente verfügt.
## 2. Einleitung
Die subjektorientierte Prozessmodellierung beschreibt Geschäftsvorgänge aus Sicht von mit einander kommunizierenden Akteuren (Handelnde oder Systeme). Hierbei werden Arbeitsschritte des Prozesses abgebildet, inklusive der handelnden Personen oder Systeme und der verwendeten Hilfsmittel. Weiter wird abgebildet welches Ergebnis durch die Arbeitsschritte erreicht wird und für wen die Ergebnisse bestimmt sind. [1]
Damit wird diese Sprache aus Sicht der Mitarbeiter modelliert und besticht durch ihre einfache Notation, die über lediglich fünf Symbole verfügt. Dadurch können Prozesse rasch und einfach modelliert werden und ebenso einfach wieder gelesen und verstanden werden. [1], [2]
## 3. Erstellung eines S-BPMN-Modell
In diesem Kapitel werden zuerst die Notationselemente vorgestellt. Anschließend wird darauf eingegangen, wie das Modell selbst erstellt werden kann.
### 3.1. Notationselemente
Die Modellierung von S-BPM erfolgt auf zwei unterschiedlichen Ebenen: Der Interaktionsebene und der Verhaltensebene. Die Notationselemente sind Subjekte, Nachrichten (Abbildung 1) und drei Funktionszustände (Abbildung 2). [1], [2], [3]
Zuerst werden die beteiligten Subjekte erstellt – in der Abbildung 3 sind es Subjekt1 und Subjekt2. Anschließend folgen die Nachrichtenflüsse zwischen den Subjekten, die die Kommunikationsbeziehungen der beteiligten Subjekte definieren.
Sobald die Modellierung auf Interaktionsebene abgeschlossen ist, werden sämtliche der Subjekte detailliert mit Informationen ausgefüllt, indem der interne Nachrichtenfluss dargestellt wird, der durchlaufen werden muss um den gewünschten Output zu erreichen. Dazu dienen die drei Funktionszustände „Empfangen“, „Bearbeiten“ und „Senden“. [2]
![Abbildung1]( img/Bild1.PNG )
*Abbildung 1 - Kommunikationsebene: Subjekte und Nachrichten [2]*
![Abbildung1]( img/Bild2.PNG )
*Abbildung 2 - Subjektinterne Sicht mit den Funktionszuständen [2]*
### 3.2. Interaktionsdiagramm
Für das Interaktionsdiagramm werden, wie bei den Notationselementen bereits angesprochen, zuerst die Subjekte festgelegt und benannt. Ein Subjekt kann hierbei ein Mensch sein, oder ein System, solange sie aktiv am Prozess beteiligt sind. Allerdings werden die Subjekte abstrakt beschrieben, sodass sie keine Personen oder Maschinen, sondern Rollen beschreiben: beispielsweise „Geschäftsführung“ anstatt „Herr Huber“.
Nachdem die Subjekte erstellt wurden, werden die Nachrichten, die zwischen den Subjekten ausgetauscht werden eingefügt. Dabei wird festgelegt wer der Sender und wer der Empfänger ist, wie in Abbildung 3 genauer abgebildet ist. Allerdings wird die Reihenfolge der Nachrichten hier NICHT festgelegt. In Abbildung 5 wird das Beispiel Dienstreise-Antrages gezeigt. Hierbei gibt es drei Subjekte: Mitarbeiter, Vorgesetzter und Reisestelle. Diese drei Subjekte hängen mittels der übermittelten Nachrichten zusammen. [1], [4]
![Abbildung1]( img/Bild3.PNG )
*Abbildung 3 - Drei Subjekte und Nachrichtenflüsse [4]*
### 3.3. Verhaltensdiagramm
Die Subjekte werden im Verhaltensdiagramm ausgefüllt mit der Reihenfolge in welcher es die Nachrichten empfängt, bearbeitet und sendet. Die Zustände werden mit Verbindungen in Beziehung gesetzt, die den Übergang zwischen verschiedenen Zuständen zeigen. Hier in Abbildung 4 beispielsweise ein einfacher Prozess der Prüfung eines Antrages und den Abschluss der Prüfung. [3]
![Abbildung1]( img/Bild4.PNG )
*Abbildung 4 - Prozess als S-BPM Verhaltensdiagramm [3]*
Neben direkten Beziehungen gibt es auch Möglichkeiten mehrere Optionen (beispielsweise bei Entscheidungen) abzubilden. So beispielsweise in der nächsten Abbildung 5 in der ein Antrag unbekannten Inhaltes geprüft wird. Dabei werden je nach Ergebnis der Prüfung auf die Höhe einer Investitionssumme unterschiedliche Zweige angeboten. So wird beispielsweise beim Zweig „Investition <1000 EUR das Verhalten weiter geleitet auf den Zustand Antrag bestätigen“. Damit gibt es auch keine Verbindung zu einem anderen Kommunkiationspartner also Subjekt. Anders bei dem Zweig Investition >9999“. Hier ist vorgesehen, dass der Antrag an ein weiteres (hier nicht angeführtes) Subjekt weitergeleitet werden muss (zu erkennen an dem Sendezustand „Antrag weiterleiten“), das über einen Empfangszustand verfügt. [1], [3]
![Abbildung1]( img/Bild5.PNG )
*Abbildung 5 - Prozess mit unterschiedlichen Zweigen [3]*
Nach direkten Beziehungen und Verzweigungen gibt es noch die Möglichkeit Schleifen zu modellieren. Dazu das Beispiel in Abbildung 6. Hier wird wieder der nicht näher spezifizierte Antrag als Beispiel gewählt. Das Subjekt, das mit der Antragsbearbeitung beauftragt ist, wird so lange weiterhin Anträge prüfen, solange noch weitere Anträge vorhanden sind. [1],[3]
![Abbildung1]( img/Bild6.PNG )
*Abbildung 6 - Schleifen in Verhaltensdiagramm [3]*
## S-BPM Interaktions- und Verhaltensdiagramm
Im nachfolgenden Beispiel wird ein Prozess mit zwei Subjekten gezeigt. Einerseits wird es als Interaktionsdiagramm (Abbildung 7) dargestellt und nachfolgend werden die Verhaltensdiagramme von SachbearbeiterIn und AbteilungsleiterIn (Abbildung 8) dargestellt. Die Begründung zur Beurteilung wird nur im Falle einer negativen Beurteilung als Datenobjekt zur Aufgabe „Antrag ablehnen“ übergeben. Im Fall der Bestätigung des Antrags wird das Datenobjekt „Beurteilung“ nicht mehr benötigt - wir können also annehmen, dass in diesem Fall keine weitere Begründung erfolgt. [1], [3]
![Abbildung1]( img/Bild7.PNG )
*Abbildung 7 - Interaktionsdiagramm [3]*
![Abbildung1]( img/Bild8.PNG )
*Abbildung 8 - Verhaltensdiagramm [3]*
Durch den Fokus von S-BPM auf die Abbildung von Kommunikationsvorgängen, wird eine umfassendere und flexiblere Beschreibung ermöglicht, als es alle zuvor betrachteten Modellierungssprachen erlauben. Durch Inputpools werden komplexere Kommunikationsszenarien leichter abbildbar. Außerdem erlauben Geschäftsobjekte, detailliertere Beschreibungen der in Nachrichten ausgetauschten Daten. [3]
### 4.1. Inputpool
Bis die Nachrichten im Verhaltensdiagramm benötigt werden, können sie in einem Inputpool wie in einem Postkasten zwischengespeichert werden. Anders als ein Postkasten, ist ein Inputpool aber konfigurierbar. Es kann festgelegt werden, wie viele Nachrichten von welchem Typ gespeichert werden können. Sollte der Inputpool entsprechend seiner Konfiguration nicht in der Lage sein, eine Nachricht entgegenzunehmen, dann muss der Sender im Sendezustand warten, bis die Nachricht zugestellt werden kann. Wenn also der Platz im Inputpool für einen bestimmten Nachrichtentyp auf 0 reduziert wir, muss der Sender immer auf den Empfänger warten. Man spricht dann von einer asynchronen Kommunikation. Außerdem erlauben Inputpools das Entgegennehmen von Nachrichten in beliebiger Reihenfolge. Es muss also nicht die Nachricht als erstes abgearbeitet werden, welche zu erst eingetroffen sind, sondern können auf die Bedürfnisse des Empfängers abgestimmt verarbeitet werden.
Inputpools haben keine eigene graphische Entsprechung in der S-BPM, sondern sind eher ein Konzept der Ausführungssemantik. Für jedes Subjekt werden sie extra beschrieben, entweder textuell oder in einem Konfigurationswerkzeug. Wenn keine Inputpools definiert sind, hat die Standardkonfiguration unbegrenzt viele Speicherstellen für beliebige Nachrichten. Somit entspricht das Kommunikationsverhalten den Nachrichtenflüssen des BPMN und somit der asynchronen Kommunikation. [3]
### 4.2. Geschäftsobjekte
Der Sinn von Geschäftsobjekten ist es, Dinge, die zur Leistungserbringung in einem Geschäftsprozess benötigt werden zu spezifizieren. Es sind also all jene Dinge, die in einem Prozess verwendet werden können wie Daten und physische Ressourcen. Geschäftsobjekte initiieren keine Interaktionen oder Aktionen und sind somit passiv. Sie werden von Subjekten bearbeitet und können Inhalte von Nachrichten näher spezifizieren indem sie ihnen zugeordnet werden.
Wie auch für Inputpools gibt es auch für Geschäftsobjekte keine graphischen Entsprechungen in der Notation der Modellierungssprache. Sie sind Konzepte der Ausführungssemantik und somit von der technischen Ausführungsumgebung abhängig. Angegeben werden sie meist in tabellarischer Form. Die Grundstruktur von Geschäftsobjekten besteht aus einem Bezeichner, Datenstrukturen und Datenelementen. Der Bezeichner ergibt sich aus dem Geschäftsumfeld, in dem mit dem Geschäftsobjekt gearbeitet wird, also zum Beispiel Bestellung, Rechnung, Urlaubsantrag, etc. Die Datenstrukturen aus denen sich das Geschäftsobjekt zusammensetzt können entweder einfache Datenelemente eines bestimmten Typs sein so wie Zeichenketten oder Zahlen, oder selbst wieder Datenstrukturen die wiederum wieder aus Datenelementen oder Datenstrukturen bestehen. Um Missverständnissen vorzubeugen ist es sinnvoll, die Bedeutung der Datenelemente näher zu beschreiben. Vor allem dann, wenn es sich nicht klar aus dem Bezeichner ableiten lässt.
Anhand eines Dienstreiseantrages wie dem folgenden, lässt sich das gut erklären. [3]
![Abbildung1]( img/Bild9.PNG )
*Abbildung 9 - Geschäftsobjekt Dienstreiseantrag [3]*
In dem Dienstreiseantrag (Abbildung 9) wird die Datenstruktur gut sichtbar. Er besteht unter anderem aus der Datenstruktur „Daten zum Antragsteller“ mit den Datenelementen für Name, Vorname und Personalnummer und der Datenstruktur „Daten zur Dienstreise“ bestehend aus den Datenelementen für Beginn, Ende und Zweck der Reise.
In vielen Fällen kann sich die Semantik eines Geschäftsobjektes während dem Prozessablauf verändern, so werden zum Beispiel aus Lieferscheinen Rechnungen. Es können daher für ein Geschäftsobjekt mehrere Zustände definiert werden. Bei einem Wechsel des Status werden nur die Datenstrukturen und Datenelemente des vorherigen übernommen, die für den neuen Status benötigt werden. Bei Bedarf werden neue Komponenten hinzugefügt oder die nicht mehr relevanten entfernt. Durch die Sicherstellung, dass so ein Subjekt nur die Datenelemente zur Verfügung gestellt bekommt, die es für seine Arbeit braucht, wird die Einhaltung von Datenschutzbestimmungen erleichtert.
Im Beispiel des Dienstreiseantrags kann aus dem ursprünglichen Status „Reiseantrag“ des Geschäftsobjekts der Status „Dienstreisebuchung“ abgeleitet werden. Dabei werden insbesondere Datenelemente mit internen Angaben wie Personalnummer, Vergütungsgruppe, Reisegrund und die komplette Datenstruktur zur Genehmigung entfernt, welche beispielsweise bei der Einschaltung eines Reiseagenten für die Buchung das Unternehmen nicht verlassen sollen und auch nicht relevant sind. Dafür wird, wie in der folgenden Abbildung gezeigt, eine neue Datenstruktur „Daten zur Buchung“ eingefügt. Sie enthält Datenelemente, mit denen die Reisestelle gegenüber dem Reiseagenten eine Frist für den spätesten Eingang der Buchungsbestätigung setzen und bestimmte Hotelketten vorgeben kann, mit denen beispielsweise Rahmenverträge bestehen. [3]
![Abbildung1]( img/Bild10.PNG )
*Abbildung 10 - Geschäftsobjekt 'Dienstreiseantrag' im Status 'Dienstreisebuchung' [3]*
### 4.3. Einordnung
Im Gegensatz zu den anderen bislang besprochenen Modellierungssprachen gibt es in der S-BPM kein einzelnes Diagramm, das einen Geschäftsprozess vollständig beschreibt. Vielmehr wird für jedes Subjekt ein separates Verhaltensdiagramm erstellt, welche durch ein Interaktionsdiagramm miteinander verknüpft werden, in dem der Nachrichtenaustausch beschrieben ist. Dadurch ermöglicht die S-BPM eine lose Kopplung von Prozessteilen und eine einfachere Veränderbarkeit des Verhaltens eines Subjektes, solange dessen Kommunikationsschnittstelle, also der Satz an empfangenen und gesendeten Nachrichten und deren Reihenfolge, unverändert bleibt.
Die Verwendung von Zustandsdiagrammen zur Beschreibung des Verhaltens eines Subjekts stellt ebenfalls einen grundlegenden Unterschied zu den anderen bislang behandelten Sprachen dar. Ein Zustandsdiagramm beschreibt — im Namen bereits enthalten — den Zustand eines Systems und die Ereignisse, die zu einem Zustandsübergang führen. Ein Subjekt kann sich immer nur in genau einem Zustand befinden — es ist deshalb per Definition nicht in der Lage, Vorgänge parallel auszuführen. Vielmehr arbeiten alle Subjekte parallel und unabhängig voneinander. Dies bedingt ein Umdenken bei der Modellierung, da Konstrukte wie UND-Konnektoren, Split/Joins oder parallele Gateways nicht zur Verfügung stehen. Gleichzeitig führt dieser Modellierungsansatz zu einfacheren, kompakteren Modellen und einem vor allem im Gegensatz zur BPMN deutlich reduzierten Sprachumfang, was der Verständlichkeit der Modelle zuträglich ist. [3]
## 5. Fragen zur Selbstkontrolle
* Erläutern Sie in eigenen Worten, was S-BPM ist und warum es entwickelt wurde.
* Beschreiben Sie die Notationselemente in S-BPM und erläutern Sie die Vorteile von S-BPM im Vergleich zu anderen Modellierungssprachen.
* Beschreiben Sie das Vorgehen bei der Erstellung eines Modelles in S-BPM.
* Erstellen Sie ein beliebiges Interaktionsdiagramm mit mind. 3 Subjekten und erweitern Sie es um Verhaltensdiagramme.
* Warum ist es nicht notwendig, ein Modellierungselement zu haben, mit dem ein paralleles Splitten im Verhalten eines Subjektes abgebildet werden kann?
* Erläutern Sie den Unterschied zwischen Datenelementen und Datenstrukturen eines Geschäftsobjektes. Aus welchem Bestandteil ist neben diesen noch in einem Geschäftsobjekt enthalten?
* Beschreiben Sie in eigenen Worten die Aufgaben bzw. Möglichkeiten eines Inputpools.
## 6. Literaturverzeichnis
[1] A. Fleischmann, S. Oppl, W. Schmidt, und C. Stary, Ganzheitliche Digitalisierung von Prozessen: Perspektivenwechsel – Design Thinking – Wertegeleitete Interaktion. Wiesbaden: Springer Vieweg, 2018.
[2] A. Wiechmann und N. Graef, „Subjektorientiertes Geschäftsprozessmanagement - Ein Paradigmenwechsel in der Welt der Geschäftsprozesse“. Braincourt Gmbh.
[3] S. Oppl, „Skriptum PKM“.
[4] P. Gluchowski, „Agilität in der IT Chancen und Nutzen agiler IT ; Evolution in der Softwareentwicklung ; Wireframes zur Oberflächenkonzeption ; Anwendungsbereiche agiler Methoden ; Agile Prozesse und Architekturen ; Business Intelligence und Agilität ; Semantische Netze“. dpunkt-Verl., 2013.
## Review
## Zusammenfassung
Everything was fine and dandy:
Markdown: OK
Inhalt: OK
Sprachgebrauch: OK
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment