Steuerungssicht 2/BPMN
Steuerungssicht 2/BPMN
Steuerungssicht 2/BPMN
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Jörg Krüger<br />
Christian Uhlig<br />
Geschäftsprozessmodellierung WS13/14<br />
4. <strong>Steuerungssicht</strong> 2 (<strong>BPMN</strong>)
Agenda<br />
• Einführung zu <strong>BPMN</strong><br />
• Modelltyp<br />
• <strong>BPMN</strong> Process Diagram<br />
• <strong>BPMN</strong> Collaboration Diagram<br />
• Beispiele<br />
• Bewertung EPK vs <strong>BPMN</strong><br />
• Daten- und Organisationsauszeichnung in <strong>BPMN</strong><br />
Übung Prozessmodellierung WS13/14<br />
Seite 2
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Die ARIS-Beschreibungssichten<br />
• Organisationssicht<br />
• Datensicht<br />
• <strong>Steuerungssicht</strong><br />
• Funktionssicht<br />
• Leistungssicht<br />
Übung Prozessmodellierung WS13/14<br />
Seite 3
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
<strong>BPMN</strong> Einführung (1)<br />
• <strong>BPMN</strong> = Business Process Model and Notation<br />
• Relativ junge Alternative insbesondere zu EPK-Modellen<br />
• Entwickelt 2002, seit 2005 Standard der Object Management Group (OMG),<br />
d.h. wird von einer offenen Standardisierungsinstitution gepflegt<br />
• Motivation<br />
• In der praktischen Anwendung von EPK deutlich gewordene Schwachstellen<br />
• Bessere Berücksichtigung einiger Anwendungsfelder, insbesondere des Software-<br />
Engineerings<br />
• EPK im Grunde ein informeller Standard, der durch einen einzigen Hersteller bzw.<br />
dessen Softwareimplementierung begründet wird<br />
• <strong>BPMN</strong> stattdessen unter Mitwirkung verschiedener Interessengruppen entwickelt<br />
und gepflegt<br />
• Im Ergebnis sind <strong>BPMN</strong> deutlich differenzierter und komplexer hinsichtlich der<br />
Notationselemente, aber auch ausdrucksstärker<br />
Übung Prozessmodellierung WS13/14<br />
Seite 4
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
<strong>BPMN</strong> Einführung (2)<br />
• Aktuell <strong>BPMN</strong> Version 2.0<br />
• ARIS bietet eine weitreichende Unterstützung für <strong>BPMN</strong> 1.x und 2.0<br />
• Integration entsprechender Modelltypen und der Notation mit Adaption an ARIS-<br />
Methode (Objekttypen und Kantentypen) und -Sichtenkonzept<br />
• Integration in fortgeschrittene ARIS-Mechanismen: Semantikchecks,<br />
Modellgenerierung, Simulation, …<br />
• Wie bei EPK Funktionen, Ereignissen und Regeln als zentrale Konzepte<br />
• Nachfolgend werden wir die zentralen Elemente der <strong>BPMN</strong>-Modellierung<br />
kennenlernen und in ihren Eigenschaften zu EPK-Modellelementen abgrenzen<br />
• Wichtig: Wir zeigen nur einen Ausschnitt aus dem <strong>BPMN</strong>-Standard, der auf<br />
die aus unserer Sicht wesentlichen Teile mit einigen Blicken links und rechts<br />
eingeschränkt ist<br />
Übung Prozessmodellierung WS13/14<br />
Seite 5
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Modelltyp: <strong>BPMN</strong> Process Diagram<br />
• Ein Process-Diagramm beschreibt genau einen Prozess analog zu einer EPK<br />
• Die Modellelemente werden in fünf Kategorien strukturiert<br />
• Flow Objects: Activities, Events, Gateways<br />
• Connecting Objects (Kanten): Sequence Flows, Associations, Data Associations<br />
• Swimlanes: Lanes<br />
• Artifacts: Groups, Annotations<br />
• Data: Data Objects, Data Inputs, Data Outputs, Data Stores<br />
Übung Prozessmodellierung WS13/14<br />
Seite 6
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Activity (1)<br />
• Activities entsprechen EPK-Funktionen und werden in ARIS über den Objekttyp<br />
Funktion abgebildet<br />
• Namenskonvention<br />
• Analog zu EPK Objekt + Verrichtung (z.B. "Lenkrad montieren")<br />
• Differenzierung von Activities in Tasks und Subprocesses<br />
• Tasks sind elementare Activities, d.h. solche Aktivitäten, für die keine<br />
weitere Zerlegung modelliert wird<br />
• Grafische Darstellung:<br />
• Subprocesses sind zusammengesetzte (komplexe) Activities, d.h. sie<br />
enthalten ihrerseits eine genauere Beschreibung in Form eines <strong>BPMN</strong>-<br />
Prozesses; sie werden hinsichtlich ihrer Darstellung wiederum differenziert in<br />
collapsed und expanded subprocesses<br />
Übung Prozessmodellierung WS13/14<br />
Seite 7
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Activity (2)<br />
• Collapsed Subprocess: Der modellierte Unterprozess ist nicht sichtbar; dies<br />
entspricht im wesentlichen EPK-Hinterlegungen in ARIS<br />
Grafische Darstellung:<br />
EPK-Modellierung<br />
• Expanded Subprocess: Der modellierte Unterprozess wird direkt im<br />
(entsprechend vergrößerten) Activity-Symbol dargestellt<br />
Grafische<br />
Darstellung:<br />
EPK-Modellierung<br />
Keine Analogie<br />
• Subprocesses werden in ARIS analog zu EPKs durch Hinterlegungen<br />
umgesetzt; die Unterprozesse werden nur in den hinterlegten Modellen<br />
bearbeitet, die direkt im Symbol dargestellten Elemente sind nicht editierbar<br />
Übung Prozessmodellierung WS13/14<br />
Seite 8
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Activity (3)<br />
• Ad-Hoc Process<br />
• Besondere Art Subprocess, die den Kontrollfluss ganz oder teilweise undefiniert lässt<br />
• Semantik: Abgesehen von definierten Kontrollflüssen wird die Reihenfolge und<br />
Häufigkeit der Aktivierung der enthaltenen Flow Objects dynamisch zur Laufzeit des<br />
Prozesses entschieden<br />
• Anwendungsbereich: z.B. kreative oder Management-Prozesse, bei denen<br />
bestimmte Schritte häufiger und in sehr dynamischer Reihenfolge ausgeführt<br />
werden, so dass eine ex ante Standardisierung nicht möglich oder unangemessen ist<br />
EPK-Modellierung<br />
Keine Analogie<br />
Übung Prozessmodellierung WS13/14<br />
Seite 9
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Activity (4)<br />
• Loop-Activity: Eine Activity (Task oder Subprocess)<br />
kann explizit als Schleife deklariert wird, die anhand<br />
einer Bedingung oder eines<br />
Zählers mehrfach ausgeführt<br />
wird<br />
EPK-Modellierung<br />
• Multi-Instance-Activity: Beim Ausführen wird eine<br />
Menge von Instanzen ("Threads") dieser Activity<br />
(Task oder Subprocess) erzeugt, die parallel (vertikale<br />
Markierungslinien) oder nacheinander (horizontale<br />
Markierungslinien) ausgeführt werden.<br />
Anwendungsfall: z.B. gleichartige Verarbeitung<br />
einer Menge von<br />
Datenobjekten<br />
EPK-Modellierung<br />
Keine Analogie;<br />
Nachbildung per<br />
Schleife notwendig,<br />
Parallelität kann<br />
nicht modelliert<br />
werden<br />
Übung Prozessmodellierung WS13/14<br />
Seite 10
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Activity (5)<br />
• Konventionen<br />
• Schleifen<br />
• Grundsätzlich kann eine Schleife entweder als Loop Activity oder analog zu EPKs<br />
(d.h. Entscheidungsfunktion zur Schleifensteuerung + Schleifenrumpf und<br />
Rücksprung) modelliert werden<br />
• Aber: Umfasst der Schleifenrumpf nur 1 bis 4 Funktionen, ist grundsätzlich eine<br />
Loop Activity (Task oder Subprocess, Loop-Type "Standard Loop") zu verwenden<br />
• Für einen Schleifenrumpf mit nur einer Funktion ist ein Loop Task zu modellieren<br />
• Für einen Schleifenrumpf mit 1 bis 4 Funktionen ist ein Subprocess zu modellieren, der<br />
expanded im Oberprozess dargestellt wird<br />
• Für einen Schleifenrumpf mit mehr als 4 Funktionen ist ein Subprocess zu modellieren,<br />
der nach eigenem Ermessen collapsed oder expanded im Oberprozess dargestellt wird<br />
• Bei Loop Activities ist über das Attribut "Loop Condition" (Gruppe "<strong>BPMN</strong> 2.0-<br />
Attribute" -> "Loop Characteristics" -> "Standard Loop Attributes") immer eine<br />
Schleifenbedingung anzugeben<br />
• Die Bedingung soll formulieren, wann die Schleife weiterläuft (z.B. "Weiterer Kunde<br />
zu verarbeiten?") oder im Falle einer Schleife über Datenobjekte die Menge der<br />
Datenobjekte charakterisieren (z.B. "für alle Kunden")<br />
Übung Prozessmodellierung WS13/14<br />
Seite 11
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Activity (5)<br />
• Konventionen (Fs.)<br />
• Schleifen (Fs.)<br />
• Über das Attribut "Test before" (Gruppe "<strong>BPMN</strong> 2.0-Attribute" -> "Loop<br />
Characteristics" -> "Standard Loop Attributes") kann eine kopf- (Test before<br />
aktiviert) oder fußgesteuerte Schleife (Test before deaktiviert) definiert werden. Wird<br />
dieses Attribut nicht gepflegt, wird implizit von einer kopfgesteuerten Schleife<br />
ausgegangen oder von einer Schleife, für die diese Frage keine Bedeutung hat.<br />
• Sowohl Tasks als auch Subprocesses können Loop Activities sein; Tasks kommen<br />
zum Einsatz, wenn der Schleifenrumpf nur eine (elementare) Funktion aufweist<br />
• Ad-Hoc-Prozesse und Multi-Instance-Activities sollen nicht verwendet werden<br />
Übung Prozessmodellierung WS13/14<br />
Seite 12
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Event (1)<br />
• Differenzierung nach Flow Dimension: Start, Intermediate und End Events<br />
• Grafische Darstellung:<br />
EPK-Modellierung<br />
einfacher Kreis = Start, doppelter Kreis = Intermediate, dicker Kreis = End<br />
Die Farben sind lediglich ein ARIS-Feature<br />
• Ereignisnamen sind optional und werden entsprechend häufig weggelassen<br />
• Weitere Differenzierung nach Gegenstand des Ereignisses (Type Dimension):<br />
None, Message, Timer, Error, Cancel, ...<br />
• None Event: Ereignis ohne Type (entsprechend leeres Symbol, z.B. )<br />
• Grafische Darstellung:<br />
EPK-Modellierung<br />
Keine Analogie bzw. informell<br />
über die Ereignisbezeichnung<br />
abbildbar<br />
Übung Prozessmodellierung WS13/14<br />
Seite 13
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Event (2)<br />
• Differenzierung nach Ursache / Wirkung: Catching und Throwing Events<br />
• Catching Events: Start Events müssen und Intermediate Events können einen<br />
Trigger haben, den sie "catchen". Das Typsymbol ist bei Catching Events nicht<br />
gefüllt.<br />
Grafische Darstellung:<br />
• Throwing Events: End Events können ein Result haben, das sie "throwen".<br />
Intermediate Events können einen Trigger haben, den sie "throwen". Das<br />
Typsymbol ist bei Throwing Events gefüllt.<br />
Grafische Darstellung:<br />
EPK-Modellierung<br />
Keine Analogie<br />
EPK-Modellierung<br />
Keine Analogie<br />
• Anders als in EPKs sind Zwischenereignisse nicht zwingend (Trivialereignisse<br />
werden vermieden). Außerdem dürfen Ereignisse auch auf Ereignisse folgen.<br />
• Start- & Endereignisse dürfen fehlen, in diesem Fall gelten bestimmte Regeln,<br />
wo der Prozess beginnt<br />
Übung Prozessmodellierung WS13/14<br />
Seite 14
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Event (3)<br />
Ereignisübersicht<br />
Beispiele<br />
• Start-Ereignis, das durch eine Nachricht<br />
ausgelöst wird<br />
(Start-Event, Catching Trigger, Message)<br />
• Zwischenereignis, das durch eine Zeit ausgelöst<br />
wird<br />
(Intermediate, Catching Trigger, Time)<br />
• Zwischenereignis, das eine Nachricht versendet<br />
(Intermediate, Throwing Trigger, Message)<br />
• Endereignis, das einen Fehler auslöst<br />
(End, Throwing Result, Error)<br />
Übung Prozessmodellierung WS13/14<br />
Seite 15
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Event (4)<br />
• Beispiel im Zusammenhang<br />
Ein Prozess, a) der durch eine Zeit ausgelöst wird, b) einen elementaren Schritt<br />
ausführt, c) anschließend auf eine Nachricht wartet, d) nach Eintreffen der<br />
Nachricht einen zweiten Schritt ausführt und e) schließlich ohne Erzeugen<br />
eines besonderen Results abschließt.<br />
• Ereignisse können in einigen Fällen mit Tasks konsolidiert werden; so "enthält"<br />
z.B. ein Send Task implizit ein Ereignis, das eine Nachricht auslöst, und ein<br />
Receive Task ein Ereignis, das eine Nachricht empfängt.<br />
Beispiel mit<br />
Receive Task<br />
Übung Prozessmodellierung WS13/14<br />
Seite 16
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Event (5)<br />
• Boundary Events: Bestimmte Ereignisse können auf Activity-Rändern platziert<br />
werden, um explizit Ausnahmen zu modellieren (z.B. Sonderfälle,<br />
Fehlersituationen usw.) und darauf zu reagieren<br />
• Beispiel: Fehlerereignis auf dem Rand eines Subprocess, fängt Fehler im<br />
Unterprozess ab<br />
Übung Prozessmodellierung WS13/14<br />
Seite 17
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Event (6)<br />
• Konventionen<br />
• An Ereignistypen sollen nur folgende verwendet werden (die Auswahl erfolgt beim<br />
Anlegen oder über das <strong>BPMN</strong>-Kontextmenü des Events):<br />
• Message: Das Ereignis entsteht durch Empfang einer Nachricht oder bildet selber den<br />
Versand einer Nachricht ab<br />
• Timer: Das Ereignis bildet das Eintreten eines Zeitpunktes oder das Ablaufen eines<br />
Zeitraums ab<br />
• Conditional: Das Ereignis ist durch das Eintreten einer bestimmten Bedingung<br />
gekennzeichnet (z.B. "Reklamationsrate > 5%"); dazu sollen keine Kriterien wie z.B.<br />
"Lieferung eingetroffen" gehören, die einen inhärent booleschen Zustand aufweisen, der<br />
sich nach dem Eintreten nicht mehr ändert<br />
• None: Alle übrigen Ereignisse…<br />
• Für Message Events soll Throwing und Catching unterschieden werden (die<br />
Auswahl erfolgt beim Anlegen oder über das <strong>BPMN</strong>-Kontextmenü des Events)<br />
• Ereignisse sollen nicht direkt auf Ereignisse folgen<br />
Übung Prozessmodellierung WS13/14<br />
Seite 18
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Event (7)<br />
• Konventionen (Forts.)<br />
• Trivialereignisse (d.h. Zwischenereignisse, die lediglich den Übergang zwischen zwei<br />
Funktionen modellieren) können weggelassen werden, in Sequenzen dürfen also<br />
Funktionen prinzipiell auf Funktionen folgen<br />
• Start- und Endereignisse sind zu modellieren; analog zu EPKs soll jeder<br />
Prozesspfad mit min. einem Ereignis anfangen und mit min. einem Ereignis enden<br />
• Die Ereignisbenennung erfolgt in Abhängigkeit vom Ereignistyp:<br />
• Message: Liegt ein eingehender Message Flow mit benannter Message vor (siehe später<br />
zu Collaboration), erfolgt keine Benennung; ansonsten gibt die Benennung analog zu EPK-<br />
Ereignissen Auskunft über die empfangene Nachricht (z.B. "Auftrag erhalten")<br />
• Timer: Die Benennung soll den Zeitpunkt bzw. Zeitraum des Ereigniseintritts<br />
charakterisieren (z.B. "8 Uhr" oder "24h verstrichen"). Die eigentlich vorgesehenen <strong>BPMN</strong>-<br />
Attribute "Timedate" und "Timecycle" sollen nicht gepflegt werden.<br />
• Conditional: Die Benennung soll die Eintrittsbedingung charakterisieren (z.B.<br />
"Reklamationsrate > 5%"). Das eigentlich vorgesehene <strong>BPMN</strong>-Attribut "Condition" soll<br />
nicht gepflegt werden.<br />
• None: Benennung analog zu EPK-Ereignissen (z.B. "Lieferung eingetroffen"); soweit<br />
Trivialereignisse modelliert werden, brauchen diese nicht benannt zu werden<br />
Übung Prozessmodellierung WS13/14<br />
Seite 19
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Gateways in <strong>BPMN</strong><br />
• Gateways in <strong>BPMN</strong> entsprechen prinzipiell EPK-Regeln (XOR, OR, AND)<br />
• Statt durch Ereignis(-Namen) wie in EPKs werden Bedingungen<br />
gegebenenfalls durch Kanten(-Attribute) repräsentiert<br />
• Gateways als Entscheidungsfunktionen<br />
• XOR/OR-Gateways können in manchen Fällen die Rolle von<br />
Entscheidungsfunktionen übernehmen und damit eine explizite<br />
Entscheidungsfunktion wie bei EPKs unnötig machen<br />
• Gateways sollen allerdings nur dann Entscheidungen im Sinne einer Funktion<br />
treffen, wenn diese deterministischer Natur und auf Basis von Daten möglich sind,<br />
die bei Ausführung des Gateways verfügbar sind (data-based decision) und nicht<br />
durch das Gateway erhoben werden müssten.<br />
• Damit könnte ein Gateway z.B. die Entscheidung "Kundenzahlungsziel = 0?" treffen,<br />
allerdings keine Entscheidung wie "Reklamationswunsch des Kunden<br />
entsprechen?". In letzterem Fall liegt die Entscheidung bei einer vorgeschalteten<br />
Activity und das Gateway dient nur der Abbildung der Entscheidungsergebnisse.<br />
Übung Prozessmodellierung WS13/14<br />
Seite 20
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Exclusive Gateway (1)<br />
• Data-Based Exclusive Decision and Merging (Exclusive Gateway)<br />
• Verzweigung in mehrere Pfade, wobei genau einer ausgewählt wird (entspricht<br />
einem EPK XOR-Split)<br />
• Grafische Darstellung:<br />
EPK-Modellierung<br />
• Zusammenführung mehrerer Pfade, wobei der Kontrollfluss zur Laufzeit von<br />
genau einem eintrifft (entspricht EPK XOR-Join)<br />
• Grafische Darstellung:<br />
EPK-Modellierung<br />
Übung Prozessmodellierung WS13/14<br />
Seite 21
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Exclusive Gateway (2)<br />
• Kanten der abgehenden Sequence Flows entsprechen Bedingungen<br />
(Conditional Sequence Flows), zu Wahr ausgewertete Bedingung markiert<br />
Zielpfad<br />
EPK-Modellierung<br />
• Beispiel:<br />
• Für den Fall, dass keine Kantenbedingung zutrifft, kann eine<br />
Defaultkante (Default Sequence Flow) festgelegt werden.<br />
• Ein XOR-Merge ist das Standardverhalten, wenn kein<br />
Gateway angegeben wird<br />
=<br />
Übung Prozessmodellierung WS13/14<br />
Seite 22
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Exclusive Gateway (3)<br />
• Beispiel: Gateway als (datenbasierte) Entscheidungsfunktion<br />
EPK-Modellierung<br />
• In diesem Fall weist das Gateway eine Bezeichnung auf, der dem Namen einer<br />
entsprechenden Entscheidungsfunktion entspricht<br />
Übung Prozessmodellierung WS13/14<br />
Seite 23
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Exclusive Gateway (4)<br />
• Konventionen<br />
• Gateways dürfen in den beschriebenen Fällen die Rolle von<br />
Entscheidungsfunktionen übernehmen; sie sind dann entsprechend zu benennen.<br />
Bildet ein Gateway das Entscheidungsergebnis einer vorgeschalteten Activity ab, so<br />
soll es nicht benannt werden.<br />
• Gateways in der Rolle von Entscheidungsfunktionen dürfen vermieden und<br />
grundsätzlich durch vorgeschaltete Activities gesteuert werden.<br />
• Eine Decision muss min. 2 ausgehende Sequence Flows aufweisen, analog ein<br />
Merge min. 2 eingehende Sequence Flows.<br />
• Die ausgehenden Sequence Flows einer Decision müssen Conditional oder Default<br />
Sequence Flows sein (Auswahlattribut "Sequence Flow Condition", Gruppe "<strong>BPMN</strong><br />
2.0-Attribute"). Für jeden Conditional Sequence Flow ist das Attribut "Condition<br />
Expression" (Gruppe "<strong>BPMN</strong> 2.0-Attribute") mit der entsprechenden<br />
Kantenbedingung zu pflegen.<br />
• Das leere Gateway-Symbol als Variante des XOR-Gateways soll nicht verwendet<br />
werden.<br />
Übung Prozessmodellierung WS13/14<br />
Seite 24
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Inclusive Gateway (1)<br />
• Data-Based Inclusive Decision and Merging (Inclusive Gateway)<br />
• Analog zu Exclusive Gateways, allerdings können mehrere Pfade, deren<br />
Bedingungen zu Wahr auswerten, ausgewählt werden<br />
• Entspricht EPK OR-Split/Join<br />
• Grafische Darstellung:<br />
EPK-Modellierung<br />
• Analog zum Exclusive Gateway kann für den Fall,<br />
dass keine Kantenbedingung passt, eine<br />
Defaultkante festgelegt werden<br />
Übung Prozessmodellierung WS13/14<br />
Seite 25
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Inclusive Gateway (2)<br />
• Auf das Verteiler-Gateway (Decision) kann verzichtet werden; stattdessen<br />
können die Conditional Sequence Flows direkt von einer vorgeschalteten<br />
Entscheidungsactivity ausgehen und werden in diesem Fall mit einer Raute<br />
dargestellt.<br />
EPK-Modellierung<br />
=<br />
Übung Prozessmodellierung WS13/14<br />
Seite 26
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Inclusive Gateway (3)<br />
• Konventionen<br />
• Soweit anwendbar gelten die gleichen Konventionen wie für Exclusive Gateways<br />
• Direkt von Activities ausgehende Conditional Sequence Flows zur Vermeidung eines<br />
Inclusive Gateways sollen nicht verwendet werden<br />
Übung Prozessmodellierung WS13/14<br />
Seite 27
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Parallel Gateway (1)<br />
• Parallel Forking and Joining (Parallel Gateway)<br />
• Alle ausgehenden Pfade werden aktiviert, analog zu EPK AND-Verteilern<br />
• Grafische Darstellung:<br />
EPK-Modellierung<br />
• Es werden normale und keine Conditional Sequence Flows verwendet<br />
• AND-Fork ist Standardverhalten, wenn kein Gateway angegeben wird<br />
=<br />
Übung Prozessmodellierung WS13/14<br />
Seite 28
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Parallel Gateway (2)<br />
• Konventionen<br />
• Parallel Gateways sollen nicht benannt werden<br />
• Ein Fork muss min. 2 ausgehende Sequence Flows aufweisen, analog ein Join min.<br />
2 eingehende Sequence Flows<br />
• Die ausgehenden Sequence Flows einer AND-Fork müssen normale Sequence<br />
Flows sein, weder ist ein anderer Typ (Conditional oder Default) auszuwählen noch<br />
eine Bedingung anzugeben<br />
• Die Darstellung von AND-Forks ohne Gateway soll nicht verwendet werden<br />
Übung Prozessmodellierung WS13/14<br />
Seite 29
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: (Exclusive) Event Gateway (1)<br />
• Event-Based Decision statt Data-Based Decision: Anstelle von Bedingungen an<br />
den Kanten werden an dieser Stelle im Prozess erwartete Ereignisse zur<br />
Auswahl des Pfades genutzt<br />
• Der Prozess wird mit dem ersten eintretenden Ereignis aus der<br />
Nachfolgermenge fortgesetzt<br />
• Nur Decision/Split, keine Join/Merge-Variante<br />
EPK-Modellierung<br />
• Grafische Darstellung:<br />
• Als Ziele sind ausschließlich Intermediate<br />
Events der Typen Message, Signal, Timer, Conditional<br />
und Multiple zulässig, außerdem Receive Tasks<br />
(entsprechend Message Events)<br />
Aber: Die EPK sagt aus, dass<br />
genau eines der Ereignisse<br />
ausgelöst wird; der Aspekt, dass<br />
mehrere Ereignisse ausgelöst<br />
werden können, von denen das<br />
erste zur Auswahl genutzt wird,<br />
kann nicht modelliert werden.<br />
Übung Prozessmodellierung WS13/14<br />
Seite 30
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: (Exclusive) Event Gateway (2)<br />
• Beispiel: Ein Angebot wird zugestellt, anschließend wird auf den Auftrag des<br />
Kunden gewartet. Trifft dieser nicht binnen einer Woche ein, wird das Angebot<br />
zurückgezogen.<br />
EPK-Modellierung<br />
Prinzipiell darstellbar, aber umständlicher,<br />
ungenauer und informeller<br />
Übung Prozessmodellierung WS13/14<br />
Seite 31
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: (Exclusive) Event Gateway (3)<br />
• Konventionen<br />
• Ein Event Gateway hat nie Entscheidungsfunktion (die Entscheidung fällt ja "von<br />
selbst" per Eintreten eines Ereignisses) und soll daher nicht benannt werden.<br />
• Ein Event Gateway muss min. 2 ausgehende Sequence Flows aufweisen, die jeweils<br />
in einem Intermediate Event des Typs Message, Timer oder Conditional münden;<br />
andere Ereignistypen oder Receive Tasks sollen nicht verwendet werden.<br />
• Die ausgehenden Sequence Flows eines Event Gateways müssen normale<br />
Sequence Flows sein, weder ist ein anderer Typ (Conditional oder Default)<br />
auszuwählen noch eine Bedingung anzugeben<br />
Übung Prozessmodellierung WS13/14<br />
Seite 32
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Modelltyp: <strong>BPMN</strong> Collaboration Diagram<br />
• Collaboration-Diagramme dienen der Darstellung mehrerer Prozesse (interne<br />
und/oder externe) im Zusammenspiel; dabei wird zusätzlich zum von EPK- und<br />
<strong>BPMN</strong>-Prozessen bereits bekannten Kontrollfluss der Nachrichtenfluss<br />
modelliert, d.h. welche Nachrichten in welcher Richtung ausgetauscht werden.<br />
Dabei kann über Nachrichten synchronisiert werden, d.h. ein Prozess kann<br />
explizit auf eine bestimmte Nachricht warten<br />
• Zusätzlich zu den vom Process-Diagramm bekannten Objekten sind Message<br />
Flows (Connection Objects) und Pools (Swimlanes) vorgesehen<br />
• Die Modellierung von Collaborations im Allgemeinen und des<br />
Nachrichtenflusses im Speziellen sind wesentliche und wichtige <strong>BPMN</strong>-<br />
Merkmale; es existieren keine vergleichbaren EPK-Analogien<br />
Übung Prozessmodellierung WS13/14<br />
Seite 33
Pool<br />
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Pool (1)<br />
• Pools werden verwendet, um unterschiedliche Prozesse abzugrenzen; ein Pool<br />
repräsentiert jeweils genau einen Teilnehmer an einer Collaboration bzw.<br />
typischerweise einen Prozess aus Flow Objects und Sequence Flows (der<br />
Inhalt des Pools stellt also prinzipiell ein Process-Diagramm dar)<br />
• Grafische Darstellung:<br />
• Ein Pool kann leer sein („black box“), wenn zwar ein Teilnehmer an einer<br />
Collaboration modelliert werden soll (z.B. der Kunde), seine internen Abläufe<br />
jedoch unbekannt oder für den Prozess unwichtig sind<br />
• Die Benennung ist flexibel und kann beispielsweise der Prozessbezeichnung<br />
oder einer organisatorischen Einheit folgen<br />
Übung Prozessmodellierung WS13/14<br />
Seite 34
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Pool (2)<br />
• Die Kommunikation und Synchronisierung zwischen Pools findet per Message<br />
Flows statt; Sequence Flows dürfen Poolgrenzen nicht überschreiten.<br />
• Beispiel-Collaboration:<br />
Übung Prozessmodellierung WS13/14<br />
Seite 35
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Pool (3)<br />
• Konventionen<br />
• Prozesse, an denen der Kunde oder eine andere externe Instanz per<br />
Nachrichtenaustausch beteiligt ist, sind immer als Collaborations zu modellieren<br />
Übung Prozessmodellierung WS13/14<br />
Seite 36
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Message / Message Flow (1)<br />
• Ein Message Flow repräsentiert den gerichteten Austausch einer Nachricht<br />
zwischen zwei Teilnehmern einer Collaboration bzw. zwei Prozessen<br />
• Grafische Darstellung:<br />
• ARIS modelliert einen Message Flow durch ein Message-Objekt, zu dem vom<br />
Sender eine Kante und von dem zum Empfänger eine Kante gezogen werden<br />
• Message Flows verbinden grundsätzlich zwei verschiedene Pools; dabei kann<br />
der Message Flow sowohl auf der Sende- als auch auf der Empfangsseite<br />
entweder direkt an ein Objekt des Pools (Event oder Activity) oder nur an den<br />
Rand des Pools angebunden werden (damit ohne Angabe des Events oder der<br />
Activity, die die Nachricht konkret sendet bzw. empfängt).<br />
Übung Prozessmodellierung WS13/14<br />
Seite 37
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Message / Message Flow (2)<br />
• Konventionen<br />
• Ist der Pool eine "black box", soll die Kante zur Message am Poolrand enden,<br />
ansonsten ist sie direkt zum sendenden/empfangenen Objekt (Event oder Activity)<br />
zu ziehen<br />
Übung Prozessmodellierung WS13/14<br />
Seite 38
Lane<br />
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Lane (1)<br />
• Ein Pool kann unterteilt werden in mehrere Lanes<br />
• Typischerweise werden mit Lanes organisatorische Strukturen abgebildet<br />
(Organisationseinheiten, Rollen, Systeme…); der Prozessablauf wechselt<br />
zwischen Lanes und drückt damit die Zuordnung von Prozessteilen zu<br />
Organisationseinheiten aus<br />
• Lanes sind als Elementtyp sowohl in Prozessen als auch in Collaborations<br />
zulässig; in Prozessen stehen sie allein, in Collaborations unterteilen sie Pools<br />
• Grafische Darstellung:<br />
• Darstellung informell auch für EPKs bekannt, ARIS etwa bietet EPK-Swimlane-<br />
Diagramme an<br />
Übung Prozessmodellierung WS13/14<br />
Seite 39
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Elementtyp: Lane (2)<br />
• Beispiel-Collaboration mit Lanes:<br />
Übung Prozessmodellierung WS13/14<br />
Seite 40
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Beispiele EPK vs. <strong>BPMN</strong> (1)<br />
• Keine Trivialereignisse<br />
• Explizite Schleife ohne "händische" Kontrollstruktur (Rücksprung und Austritt)<br />
• Attribut "Loop Condition" ersetzt Funktion zur Schleifensteuerung<br />
Übung Prozessmodellierung WS13/14<br />
Seite 41
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Beispiele EPK vs. <strong>BPMN</strong> (2)<br />
• Keine Trivialereignisse<br />
• Kunde als Prozess-<br />
Teilnehmer explizit<br />
modelliert<br />
• Nachrichten explizit<br />
modelliert<br />
• Synchronisation bzgl.<br />
externer Ereignisse<br />
(Vertrag trifft ein<br />
oder Zeit abgelaufen)<br />
explizit modelliert<br />
Übung Prozessmodellierung WS13/14<br />
Seite 42
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Beispiele EPK vs. <strong>BPMN</strong> (3)<br />
• Hierarchische EPK: Unterprozess "Antrag prüfen" steuert per Ereignis den<br />
anschließenden Prozesszweig an<br />
Übung Prozessmodellierung WS13/14<br />
Seite 43
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Beispiele EPK vs. <strong>BPMN</strong> (4)<br />
• In <strong>BPMN</strong> problematisch: Im Oberprozess ist nicht bekannt, mit welchem<br />
Endereignis ein Subprocess endete; ein Bezug ausgehender Kanten zu den<br />
Endereignissen des eingebetteten Unterprozesses kann nicht hergestellt<br />
werden<br />
• In der Folge wird ein zusätzliches Gateway benötigt<br />
Übung Prozessmodellierung WS13/14<br />
Seite 44
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Beispiele EPK vs. <strong>BPMN</strong> (5)<br />
• Aber: Das Problem entsteht häufig durch EPK-Modellierungsgewohnheiten<br />
• Der konkrete Fall kann in <strong>BPMN</strong> z.B. auch leicht ohne Subprocess und<br />
separate Prüffunktionen modelliert werden.<br />
• Hier wird ausgenutzt, dass Gateways in <strong>BPMN</strong> Entscheidungsfunktion haben<br />
können (außerdem, dass der XOR-Join nicht modelliert werden muss).<br />
• Ein Unterprozess macht aus <strong>BPMN</strong>-Sicht gar keinen Sinn, da die<br />
Entscheidungskaskade unmittelbar und ausschließlich der Auswahl des<br />
anschließenden Prozesspfades im Oberprozess dient<br />
Übung Prozessmodellierung WS13/14<br />
Seite 45
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Einfacher Beispielprozess in <strong>BPMN</strong> (1)<br />
• Angebote für Einkauf einholen (Quelle: <strong>BPMN</strong> 1.2 Specification)<br />
Übung Prozessmodellierung WS13/14<br />
Seite 46
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Einfacher Beispielprozess in <strong>BPMN</strong> (2)<br />
• Angebote für Einkauf einholen (Quelle: <strong>BPMN</strong> 1.2 Specification)<br />
Gateway als<br />
Entscheidungsfunktion<br />
(data-based decision)<br />
Übung Prozessmodellierung WS13/14<br />
Seite 47
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Einfacher Beispielprozess in <strong>BPMN</strong> (3)<br />
• Angebote für Einkauf einholen (Quelle: <strong>BPMN</strong> 1.2 Specification)<br />
Expanded Subprocess &<br />
Loop<br />
Übung Prozessmodellierung WS13/14<br />
Seite 48
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Einfacher Beispielprozess in <strong>BPMN</strong> (4)<br />
• Angebote für Einkauf einholen (Quelle: <strong>BPMN</strong> 1.2 Specification)<br />
Ausnahmebehandlung:<br />
Abbruch eines<br />
Subprocesses bzw. einer<br />
Schleife nach Ablauf<br />
einer Zeit<br />
Übung Prozessmodellierung WS13/14<br />
Seite 49
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Einfacher Beispielprozess in <strong>BPMN</strong> (5)<br />
• Angebote für Einkauf einholen (Quelle: <strong>BPMN</strong> 1.2 Specification)<br />
Verzicht auf Ereignisse<br />
bei einfachen Sequenzen<br />
Übung Prozessmodellierung WS13/14<br />
Seite 50
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
<strong>BPMN</strong> vs EPK (1)<br />
• Warum <strong>BPMN</strong>?<br />
• Zusätzliche Detailinformationen können modelliert werden: z.B. Differenzierung von<br />
Ereignisarten und Funktionsarten, präzise Definition der Input/Output-Daten von<br />
Activities (oben nicht angesprochen, von ARIS auch noch gar nicht unterstützt)<br />
• Interaktion zwischen Prozessteilnehmern bzw. mehreren Prozessen kann modelliert<br />
werden (Collaborations); Hand-Over-Vorgänge können durch Nachrichten sauber<br />
dargestellt und synchronisiert werden<br />
• Mächtige Schleifenkonstruktionen: z.B. Wiederholung von Funktionen aufgrund von<br />
Bedingungen, Parallelität kann explizit modelliert werden<br />
• Unterstützung für Ad-Hoc-Prozesse<br />
• Unterstützung für Exceptions: Ausstiege aus Funktionen aufgrund von Fehlern,<br />
Ablauf von Fristen (zeitliche Ereignisse) o.ä. können sauber modelliert werden<br />
• Unterstützung von transaktionalen Prozessen<br />
• <strong>BPMN</strong> wesentlich besser als EPK zur Unterstützung von Softwareentwicklung<br />
geeignet (Schnittstellensprache Business & IT)<br />
Übung Prozessmodellierung WS13/14<br />
Seite 51
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
<strong>BPMN</strong> vs EPK (2)<br />
• Warum nicht <strong>BPMN</strong>?<br />
• Komplexer als EPK-Modellierung<br />
• Deutlich mehr Modellelemente<br />
• Viele Syntaxregeln (insbesondere aufgrund der Elementvielfalt)<br />
• Viele Freiheitsgrade (z.B. bezüglich Start/Endereignissen, Weglassen von<br />
Ereignissen, usw.)<br />
• Einige Modellelemente mit weder trivialer noch intuitiver Semantik, die häufig<br />
technikgetrieben ist<br />
• Vieles kann auf mehrere Weisen modelliert werden, z.B. gibt es zwei Symbole für die<br />
Exclusive Decision, manche Gateways können entfallen (in einigen Situationen dann<br />
aber doch nicht), Schleifen können per Marker oder explizit (und hier mit oder ohne<br />
Ereignisse) dargestellt werden usw.<br />
• Für Modellierungsvorhaben, die keine Softwareentwicklung zum Ziel haben, ist die<br />
Komplexität von <strong>BPMN</strong> ein fragwürdiger Overhead; die zusätzlichen Möglichkeiten<br />
werden häufig nicht benötigt oder nicht bzw. falsch genutzt<br />
Übung Prozessmodellierung WS13/14<br />
Seite 52
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
<strong>BPMN</strong> vs EPK (3)<br />
• Fazit<br />
• <strong>BPMN</strong> wird die EPK ablösen<br />
• Unternehmen wollen mehrheitlich <strong>BPMN</strong> für zukünftige Projekte nutzen und sehen<br />
deutliche Vorteile bei der Unterstützung von IT-Projekten<br />
• Offener Standard: Bereits heute viele Tools<br />
• Inzwischen gute Unterstützung durch Taktgeber wie ARIS<br />
• <strong>BPMN</strong> flexibler und für einige Anwendungsfelder (Softwareentwicklung, ausführbare<br />
Prozesse, …) deutlich besser geeignet<br />
• Aber: Viele fortgeschrittene <strong>BPMN</strong>-Konstrukte werden nicht genutzt oder nicht<br />
verstanden – soweit diese Konstrukte nicht erforderlich sind, bieten sich EPK-<br />
Modellierung oder Einschränkungen von <strong>BPMN</strong> per Konvention an<br />
• Aber: EPK sind nach wie vor stark dominierend bei bestehenden Modellen<br />
• Aber: EPK scheinen zur Erlernung der GPM-Grundlagen besser geeignet, da sie auf<br />
wenige Elemente und Regeln beschränkt, einfach in der Anwendung und bei<br />
Bestandsmodellen am stärksten verbreitet sind<br />
• Auch denkbar: Kombination der Modelltypen (z.B. WSK/<strong>BPMN</strong> für Grobebene, EPK<br />
für mittlere Ebene und wieder <strong>BPMN</strong> für Detailebene)<br />
Übung Prozessmodellierung WS13/14<br />
Seite 53
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Daten & Organisationsauszeichnung in <strong>BPMN</strong> (1)<br />
• <strong>BPMN</strong> bietet umfassende Modellierungsmöglichkeiten hinsichtlich genutzter<br />
Daten oder beteiligter organisatorischer Einheiten<br />
• Allerdings andere Modellierungsstrategie: Statt mehrerer Modelltypen für<br />
Prozess, Daten und Organisation (die jeweils auf den Zweck zugeschnitten<br />
sind) sieht <strong>BPMN</strong> im Grunde die Verwendung eines einzigen mächtigen<br />
Modelltyps vor<br />
• Daher Schwierigkeiten und Schwächen bei der Integration in die ARIS-<br />
Modellierungslandschaft, die derzeit noch im Fluss ist<br />
• Insbesondere Berücksichtigung von Daten in <strong>BPMN</strong> 2.0 zu mächtig, um in der<br />
Veranstaltung behandelt zu werden; die Unterstützung in ARIS ist mithin bei<br />
weitem noch nicht vollständig<br />
• Kompromiss: Vernetzung mit bekannten Modellen (also ERD und<br />
Organigramm) über ARIS-Mechanismen<br />
Übung Prozessmodellierung WS13/14<br />
Seite 54
<strong>BPMN</strong> / Processes / Collaborations / Beispiele / Warum <strong>BPMN</strong>? / Daten & Organisation<br />
Daten & Organisationsauszeichnung in <strong>BPMN</strong> (2)<br />
• Konventionen<br />
• Daten<br />
• Datenbezüge an Activities sollen durch Hinterlegung mit einem<br />
Funktionszuordnungsdiagramm modelliert werden<br />
• Damit einziger Unterschied zur EPK-Modellierung: Die Datenobjekte und ihre<br />
Beziehungen zu Activities können nicht direkt in <strong>BPMN</strong>-Diagrammen dargestellt<br />
werden, d.h. die Funktionszuordnungsdiagramme werden hier zwingend notwendig<br />
• Ausnahme: Gateways können keine Funktionszuordnungsdiagramme hinterlegt<br />
werden. In Konsequenz sollen keine Gateways mit Entscheidungsfunktion eingesetzt<br />
werden, die Zugriff auf Objekte des Datenmodells erfordern.<br />
• Organisation<br />
• Analog zu Daten sollen Organisationsbezüge per Funktionszuordnungsdiagramm<br />
hergestellt werden<br />
• Häufig gar nicht erforderlich, da bereits die Oberfunktion z.B. auf WSK-Ebene mit<br />
einer Organisationseinheit verbunden wurde<br />
• Auf Lanes soll verzichtet werden, da kein Bezug zum Organigramm bzw. seinen<br />
Objekten hergestellt werden kann<br />
Übung Prozessmodellierung WS13/14<br />
Seite 55