Business Process Modeling mit BPMN 2.0 und eEPK

Eine Methode zur Identifikation geeigneter Modellierungsklassen in spezifischen Einsatzszenarien

Tesis de Máster , 2014 , 80 Páginas , Calificación: 2,0

Economía de las empresas - Gestión de la información

Das Ziel der Arbeit ist eine systematische Erstellung von Geschäftsprozessmodellen mit den genannten Notationen in Abhängigkeit der Anforderungen spezifischer Szenarien.

In Anlehnung an Becker et al. wird mit dieser Zielsetzung ein methodischer Auftrag mit einem Erkenntnis- sowie einem Gestaltungsziel verfolgt. Das Erkenntnisziel ist jedoch eher nachrangig zu sehen, da kein vollständiges Verständnis der Modellierung mit BPMN 2.0 und eEPK, sondern nur ein grober Überblick vermittelt werden soll. Im Vordergrund steht hingegen das Gestaltungsziel, eine Methode zur systematischen Erstellung von Prozessmodellen in Abhängigkeit der Anforderungen spezifischer Einsatzszenarien zu entwickeln.

Die zentralen Forschungsfragen, die sich aus den beschriebenen Zielen ergeben, können wie folgt formuliert werden: Welche Modellierungsmöglichkeiten bieten BPMN 2.0 und eEPK und wie können diese unter Nutzung bestehender Ansätze systematisch differenziert werden? Welche Anforderungen an Geschäftsprozessmodelle können in spezifischen Einsatzszenarien bestehen und anhand welcher Kriterien können diese bewertet werden? Wie muss eine Methode zur systematischen Erstellung von Geschäftsprozessmodellen, in Abhängigkeit der Anforderungen spezifischer Einsatzszenarien, ausgestaltet sein?

Mit dem Forschungsziel geht die Grundhypothese dieser Arbeit einher, die wie folgt formuliert werden kann: Es ist möglich, in Abhängigkeit von bestimmten Kriterien Geschäftsprozessmodelle mit BPMN 2.0 und eEPK zu erstellen, die Anforderungen spezifischer Einsatzszenarien erfüllen.

Inhalt

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Einführung
1.1 Motivation
1.2 Problemstellung und Zielsetzung
1.3 Forschungsmethode und –verfahren
1.4 Aufbau der Arbeit
1.5 Unterstützung durch die CSC Deutschland Solutions GmbH

2. Grundlagen Business Process Modeling
2.1 Definitionen/Begriffsabgrenzungen
2.1.1 Prozess und Geschäftsprozess
2.1.2 Teilprozess
2.1.3 Vorgang, Aufgabe und Elementaraufgabe
2.1.4 Abgrenzung Geschäftsprozess und Workflow.
2.1.5 Geschäftsprozessmodell
2.1.6 Business Process Modeling
2.1.7 Modellierungssprache und Notation
2.2 Klassifikation von Modellierungssprachen
2.2.1 Klassifikation nach Formalisierungsgrad
2.2.2 Klassifikation nach Art der Methode

3. BPMN 2.0 und eEPK im Detail
3.1 Anmerkung zum Kapitel
3.2 eEPK
3.2.1 Historie und Versionen von EPK
3.2.2 Symbole
3.2.3 Modellierung mit eEPK
3.3 BPMN 2.0
3.3.1 Historie und Versionen von BPMN
3.3.2 Symbole
3.3.3 Modellierung mit BPMN 2.0
3.4 BPMN 2.0 und eEPK im Vergleich
3.4.1 Anforderungen an Modellierungssprachen
3.4.2 Ableitung von Bewertungskriterien für Modellierungssprachen
3.4.3 Vergleich von BPMN 2.0 und eEPK anhand Bewertungskriterien
3.4.4 Zusammenfassung des Vergleichs

4. Differenzierung der Modellierungsmöglichkeiten von eEPK und BPMN 2.0: Konzeption von Modellierungsklassen
4.1 Bestehende Ansätze zur Differenzierung von Prozessmodellen und Modellierungsmöglichkeiten
4.1.1 Sichtenkonzepte zur Differenzierung von Prozessmodellen
4.1.2 Konzepte zur Differenzierung der Modellierungsmöglichkeiten von BPMN 2.0
4.1.3 Vergleich der Konzepte von Silver und Shapiro
4.2 Konzeption von Modellierungsklassen für BPMN 2.0 und eEPK.
4.2.1 Anmerkung zum Kapitel
4.2.2 Definition „Modellierungsklasse“
4.2.3 Modellierungsklassen im Vergleich zu bestehenden Ansätzen
4.3 Modellierungsklasse eins im Detail: Prozessmodelle
4.3.1 Symbole
4.3.2 Modellierungsregeln
4.3.3 Nutzen von Modellierungsklasse eins
4.4 Modellierungsklasse zwei im Detail: Workflowmodelle I
4.4.1 Symbole
4.4.2 Modellierungsregeln
4.4.3 Nutzen von Modellierungsklasse zwei
4.5 Modellierungsklasse drei im Detail: Workflowmodelle II
4.5.1 Symbole
4.5.2 Modellierungsregeln
4.5.3 Nutzen von Modellierungsklasse drei
4.6 Abschließender Vergleich der Modellierungsklassen

5. Identifikation geeigneter Modellierungsklassen: Definition von Entscheidungskriterien
5.1 Anforderungen an Prozessmodelle: Grundsätze ordnungsmäßiger Modellierung
5.2 Ableitung von Entscheidungskriterien
5.3 Konzeption einer „Entscheidungsmatrix“
5.4 Anwendung der Entscheidungsmatrix

6. Evaluierung definierter Entscheidungskriterien anhand beispielhafter Einsatzszenarien aus Praxisprojekten
6.1 Definition „Einsatzszenario“
6.2 Ablauf der Evaluierung
6.3 Einsatzszenario eins: Modellierung eines Prozesses zur automatisierten Rechnungseingangsverarbeitung
6.3.1 Beschreibung des Einsatzszenarios
6.3.2 Identifikation einer geeigneten Modellierungsklasse
6.3.3 Modellierung des Geschäftsprozesses in Modellierungsklasse eins
6.3.4 Bewertung der Erfüllung spezifischer Anforderungen
6.4 Einsatzszenario zwei: Modellierung eines Prozesses zur Dauerauftragsbearbeitung
6.4.1 Beschreibung des Einsatzszenarios
6.4.2 Identifikation einer geeigneten Modellierungsklasse
6.4.3 Modellierung des Geschäftsprozesses in Modellierungsklasse zwei
6.4.4 Bewertung der Erfüllung spezifischer Anforderungen

7. Schlussbetrachtung
7.1 Zusammenfassung
7.2 Kritische Würdigung der Ergebnisse
7.3 Ausblick

Literaturverzeichnis

Anhang

Internetquellen

Abkürzungsverzeichnis

ARIS Architektur integrierter Informationssysteme

BPEL Business Process Execution Language

BPM Business Process Modeling

BPMI Business Process Management Initiative

BPML Business Process Modeling Language

BPMN Business Process Model and Notation

BPMN 2.0 Business Process Model and Notation 2.0

CSC Computer Sciences Corporation

EPK ereignisgesteuerte Prozesskette

eEPK erweiterte ereignisgesteuerte Prozesskette

GoB Grundsätze ordnungsmäßiger Buchführung

GoM Grundsätze ordnungsmäßiger Modellierung

GPM Geschäftsprozessmanagement

IDEF Integration Definition for Function Modeling

MS-Visio Microsoft Visio

oEPK objektorientierte ereignisgesteuerte Prozesskette

OMG Object Management Group

SADT Structured Analysis Design Technic

SOM semantisches Objektmodell

SSA Structured Systems Analysis

UML Unified Modeling Language

Abbildungsverzeichnis

Abbildung 1: Hierarchie von Prozessen, Teilprozessen, Vorgängen und Aufgaben

Abbildung 2: Grafische Darstellung einer Funktion in eEPK

Abbildung 3: Grafische Darstellung eines Ereignisses in eEPK

Abbildung 4: Grafische Darstellung einer Organisationseinheit in eEPK

Abbildung 5: Grafische Darstellung eines Informationsobjekts in eEPK

Abbildung 6: Grafische Darstellung des Kontrollflusses in eEPK

Abbildung 7: Operatoren in eEPK

Abbildung 8: Beispielhaftes eEPK-Modell aus dem Bereich der Vertriebslogistik

Abbildung 9: Grafische Darstellung von Aktivitäten und Unterprozessen in BPMN 2.0

Abbildung 10: Grafische Darstellung von Start- und Endereignissen in BPMN 2.0

Abbildung 11: Grafische Darstellung von Pools und Lanes in BPMN 2.0

Abbildung 12: Grafische Darstellung eines Sequenzflusses in BPMN 2.0

Abbildung 13: Grafische Darstellung von Gateways in BPMN 2.0

Abbildung 14: Beispielhaftes BPMN 2.0-Modell aus dem Logistikbereich

Abbildung 15: Modellierungsklassen und Merkmale erzeugter Prozessmodelle

Abbildung 16: eEPK-Prozessmodell in Modellierungsklasse eins

Abbildung 17: BPMN 2.0-Prozessmodell in Modellierungsklasse zwei (Teil I)

Abbildung 18: BPMN 2.0-Prozessmodell in Modellierungsklasse zwei (Teil II)

Abbildung 19: BPMN 2.0-Prozessmodell in Modellierungsklasse zwei (Teil III)

Tabellenverzeichnis

Tabelle 1: Übersicht über ausgewählte grafische Modellierungssprachen

Tabelle 2: Anforderungen an Modellierungssprachen und zugehörige Bewertungskriterien

Tabelle 3: Vor-/Nachteile der Ansätze von Silver und Shapiro

Tabelle 4: BPMN 2.0- und eEPK-Symbole in Modellierungsklasse eins

Tabelle 5: Zusätzliche BPMN 2.0-/eEPK-Symbole in Modellierungsklasse zwei (semantisch vergleichbar)

Tabelle 6: Symbole in Modellierungsklasse zwei speziell für BPMN 2.0

Tabelle 7: Zusätzliche BPMN 2.0- und eEPK-Symbole in Modellierungsklasse drei

Tabelle 8: Anforderung "Richtigkeit" und korrespondierendes Entscheidungskriterium sowie Einflussfaktoren

Tabelle 9: Anforderung "Relevanz" und korrespondierendes Entscheidungskriterium sowie Einflussfaktoren

Tabelle 10: Anforderung "Wirtschaftlichkeit" und korrespondierende Entscheidungskriterien sowie Einflussfaktoren

Tabelle 11: Anforderung "Klarheit" und korrespondierendes Entscheidungskriterium sowie Einflussfaktoren

Tabelle 12: „Entscheidungsmatrix“: Zuordnung der Ausprägungen von Einflussfaktoren zu geeigneten Modellierungsklassen

Tabelle 13: Schema zur Festlegung der Ausprägungen von Einflussfaktoren

Tabelle 14: Beispielhafte ausgefüllte Entscheidungsmatrix

Tabelle 15: Ablauf des Evaluierungsprozesses

Tabelle 16: Ausgefüllte Entscheidungsmatrix für Einsatzszenario eins

Tabelle 17: Ausgefüllte Entscheidungsmatrix für Einsatzszenario zwei

1. Einführung

1.1 Motivation

Innerhalb des Geschäftsprozessmanagements (GPM) nimmt Business Process Modeling (BPM) heute einen sehr hohen Stellenwert in Unternehmen ein. Die Erstellung von Prozessmodellen beansprucht ca. 40% der gesamten Zeit von Projekten im Bereich GPM.¹ Die Einsatzzwecke von BPM sind vielfältig. Darunter fallen u. a. die Dokumentation von Geschäftsprozessen, Prozessoptimierungsmaßnahmen oder auch die Anforderungsanalyse im Rahmen der Softwareentwicklung.²

Um BPM umzusetzen, werden in der Praxis verschiedene Modellierungssprachen genutzt. Unter den am weitesten verbreiteten Sprachen befinden sich die erweiterte ereignisgesteuerte Prozesskette (eEPK) und Business Process Model and Notation 2.0 (BPMN 2.0). Diese sind sich sehr ähnlich und bieten im Vergleich zu Alternativen, wie z. B. der Unified Modeling Language (UML), sehr umfangreiche Modellierungsmöglichkeiten.³ Aus diesen Gründen sollen eEPK und BPMN 2.0 im Rahmen dieser Arbeit näher betrachtet werden.

Die erwähnten umfangreichen Modellierungsmöglichkeiten der beiden Sprachen führen dazu, dass diese oftmals ausgeschöpft und im Ergebnis sehr detaillierte Prozessmodelle erstellt werden, obwohl dies nicht in jedem Szenario angemessen ist. Prozessdetails können einen Betrachter unnötig verunsichern.⁴

Es stellt sich daher die Frage, wie genau dieser Problematik entgegengewirkt und eine Erstellung angemessener Prozessmodelle sichergestellt werden kann.

1.2 Problemstellung und Zielsetzung

Im Zusammenhang mit BPMN 2.0 gibt es verschiedene Ansätze, die darauf ausgerichtet sind, die Modellierungsmöglichkeiten dieser Sprache in verschiedenen Stufen bzw. Ebenen einzuschränken, um auf diese Weise Prozessmodelle mit unterschiedlichen Detaillierungsebenen zu erzeugen.⁵ In welchem Kontext bzw. für welche genaue Zielsetzung diese unterschiedlichen Prozessmodelle geeignet sind, wird hingegen nicht beschrieben. Darüber hinaus gibt es für eEPK keinen vergleichbaren Ansatz.

Das übergeordnete Forschungsziel dieser Arbeit kann daher wie folgt beschrieben werden:

Forschungsziel: Das Ziel der Arbeit ist eine systematische Erstellung von Geschäftsprozessmodellen mit BPMN 2.0 und eEPK in Abhängigkeit der Anforderungen spezifischer Szenarien.

In Anlehnung an Becker et al. wird mit dieser Zielsetzung ein methodischer Auftrag⁶ mit einem Erkenntnis- sowie einem Gestaltungsziel⁷ verfolgt.⁸ Das Erkenntnisziel ist jedoch eher nachrangig zu sehen, da kein vollständiges Verständnis der Modellierung mit BPMN 2.0 und eEPK, sondern nur ein grober Überblick vermittelt werden soll. Im Vordergrund steht hingegen das Gestaltungsziel, eine Methode⁹ zur systematischen Erstellung von Prozessmodellen, in Abhängigkeit der Anforderungen spezifischer Einsatzszenarien, zu entwickeln.

Die zentralen Forschungsfragen, die sich aus den beschriebenen Zielen ergeben, können wie folgt formuliert werden:

Forschungsfrage eins: Welche Modellierungsmöglichkeiten bieten BPMN 2.0 und eEPK und wie können diese unter Nutzung bestehender Ansätze systematisch differenziert werden?

Forschungsfrage zwei: Welche Anforderungen an Geschäftsprozessmodelle können in spezifischen Einsatzszenarien bestehen und anhand welcher Kriterien können diese bewertet werden?

Forschungsfrage drei: Wie muss eine Methode zur systematischen Erstellung von Geschäftsprozessmodellen, in Abhängigkeit der Anforderungen spezifischer Einsatzszenarien, ausgestaltet sein?

Mit dem Forschungsziel geht die Grundhypothese dieser Arbeit einher, die wie folgt formuliert werden kann:

Grundhypothese: Es ist möglich, in Abhängigkeit von bestimmten Kriterien Geschäftsprozessmodelle mit BPMN 2.0 und eEPK zu erstellen, die Anforderungen spezifischer Einsatzszenarien erfüllen.

1.3 Forschungsmethode und –verfahren

Um die beschriebenen Ziele dieser Arbeit zu erreichen, soll eine geeignete Forschungsmethode definiert werden.

Nach Hevner et al. stellt die in Forschungsfrage drei erwähnte Methode, die im Rahmen dieser Arbeit entwickelt werden soll, ein Entwurfsartefakt¹⁰ dar. Die Erstellung eines Entwurfsartefakts ist charakteristisch für das konstruktionswissenschaftliche Paradigma¹¹. Um festzustellen, ob ein solches Entwurfsartefakt die Anforderungen erfüllt, die sich aus der ursprünglichen Problemstellung ergeben haben, muss im Anschluss eine Evaluierung erfolgen.¹² Dieser Empfehlung soll in dieser Arbeit gefolgt werden.

Die zu entwickelnde Methode soll in spezifischen Einsatzszenarien anwendbar sein und zur Erstellung semi-formaler Prozessmodelle dienen. Die zugrunde liegende Forschungsmethode kann daher als konzeptionell-deduktive Analyse bezeichnet werden. Die Evaluation der entwickelten Methode erfolgt rein qualitativ-argumentativ im Rahmen einer argumentativ-deduktiven Analyse.¹³

Um in die Entwicklung der Methode fachliches Know-how aus der Praxis einfließen zu lassen, wurden darüber hinaus Interviews mit Experten der CSC Deutschland Solutions GmbH durchgeführt. Der konstruktionswissenschaftliche Forschungsansatz wird an dieser Stelle um eine empirische Komponente ergänzt.¹⁴

1.4 Aufbau der Arbeit

In Kapitel 2 werden grundlegende Begrifflichkeiten erläutert, die für das Verständnis der nachfolgenden Ausführungen von Bedeutung sind. Daneben wird ein Überblick über verschiedene Modellierungssprachen gegeben.

Kapitel 3 beschreibt die grundlegenden Modellierungsmöglichkeiten von BPMN 2.0 und eEPK im Detail und schließt mit einem Vergleich der beiden Modellierungssprachen ab.

In Kapitel 4 werden bestehende Ansätze zur Differenzierung der Modellierungsmöglichkeiten von BPMN 2.0 untersucht und ein eigener Ansatz zur Definition unterschiedlicher „Modellierungsklassen“ herausgearbeitet, der für BPMN 2.0 und eEPK übergreifend gültig ist.

In Kapitel 5 werden allgemeine Anforderungen an Prozessmodelle definiert, um daraus Entscheidungskriterien abzuleiten. Anschließend wird eine Methode zur Identifikation geeigneter Modellierungsklassen anhand der abgeleiteten Entscheidungskriterien erläutert.

Um die in Kapitel 5 beschriebene Methode zu evaluieren, wird diese im Rahmen von Kapitel 6 in fiktiven Einsatzszenarien angewandt, um Prozessmodelle zu erstellen.

Kapitel 7 bildet mit einer kritischen Würdigung sowie einem Fazit und Ausblick den Abschluss dieser Arbeit.

1.5 Unterstützung durch die CSC Deutschland Solutions GmbH

In Kapitel 1.3 wurde bereits angeführt, dass die Erstellung dieser Arbeit an verschiedenen Stellen durch Fachexperten der CSC Deutschland Solutions GmbH¹⁵ unterstützt wurde. Erfahrungen und Know-how aus der Praxis wurden maßgeblich von Martina Mustermann (Name geändert) beigetragen. Frau Mustermann ist Business-Architect im Bankenbereich und besitzt jahrelange Expertise im Bereich Business Process Modeling.

2. Grundlagen Business Process Modeling

2.1 Definitionen/Begriffsabgrenzungen

2.1.1 Prozess und Geschäftsprozess

Für den Begriff „Prozess“ gibt es in der Literatur eine Vielzahl unterschiedlicher Definitionen.¹⁶ Häufig liegen Unterschiede im Kontext der wissenschaftlichen Disziplin begründet (z. B. Wirtschaftsinformatik oder Managementlehre).¹⁷ Um eine geeignete Definition für den Rahmen dieser Arbeit zu finden, sollen im Folgenden zunächst drei beispielhafte Ansätze vorgestellt werden.

Hammer und Champy definieren einen Prozess im Rahmen des Business Reengineerings durch eine Menge von Aktivitäten, die ein oder mehrere verschiedene Inputs benötigt, um Ergebnisse mit einem Wert für den Kunden zu erzeugen.¹⁸

Nach Becker, Schütte und Rosemann ist ein Prozess durch die inhaltlich abgeschlossene, zeitliche und sachlogische Folge von Aktivitäten definiert, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objektes notwendig sind.¹⁹

Gehring bezeichnet einen Geschäftsprozess als eine zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die durch verschiedene Organisationseinheiten bzw. Organisationen ausgeführt werden können und die Nutzung von Informations- und Kommunikationstechnologien beinhalten.²⁰

Gemeinsam ist diesen Definitionen, dass ein Prozess eine Folge von Aktivitäten bzw. Aufgaben darstellt. Der Ansatz von Gehring erscheint insbesondere durch die Berücksichtigung beteiligter Organisationseinheiten sowie Informations- und Kommunikationstechnologien im Kontext der Modellierung von Geschäftsprozessen am besten geeignet und soll dieser Arbeit daher zugrunde gelegt werden.

Anhand der drei beispielhaften Definitionen wurde bereits deutlich, dass in der Literatur häufig nicht zwischen den Begriffen „Prozess“ und „Geschäftsprozess“ unterschieden wird.²¹ Es kann jedoch dahingehend eine Unterscheidung getroffen werden, dass Geschäftsprozesse sich dadurch auszeichnen, stets auf die Stiftung eines Kundennutzens und auf die Sicherung der Wettbewerbsfähigkeit eines Unternehmens ausgerichtet zu sein.²²

Da es für die Modellierung jedoch unerheblich erscheint, ob ein Prozess diese Anforderungen erfüllt oder nicht, sollen die beiden Begriffe im Rahmen dieser Arbeit synonym verwendet werden. Für dritte Begrifflichkeiten, die die Bezeichnungen „Prozess“ oder „Geschäftsprozess“ beinhalten, gilt dies ebenso (z. B. ist Prozessmodellierung als Synonym für Geschäftsprozessmodellierung zu sehen).

2.1.2 Teilprozess

Die in 2.1.1 beschriebenen Geschäftsprozesse können nach Ott hierarchisch in Teilprozesse untergliedert werden.²³

Es gibt jedoch keine theoretischen Grundlagen dazu bzw. eine einheitliche Festlegung, wie diese Untergliederung vorgenommen wird.²⁴ So kann die Anzahl von Geschäftsprozessen und Teilprozessen in einem Unternehmen sich in Abhängigkeit des Betrachters unterscheiden.²⁵

Um in dieser Arbeit einen Rahmen zur Orientierung zu haben, soll ein Teilprozess stets die erste Untergliederungsebene eines zuvor definierten Geschäftsprozesses darstellen (vgl. Abbildung 1).

2.1.3 Vorgang, Aufgabe und Elementaraufgabe

In Geschäftsprozessen durchgeführte Tätigkeiten können nach Staud als Aufgaben definiert und auf unterschiedlichen Ebenen betrachtet werden.²⁶

Darüber hinaus werden Aufgaben auf der untersten Ebene nach Bullinger & Fähnrich als Elementaraufgaben bezeichnet.²⁷ Diese Ebene ist erreicht, wenn Aufgaben nicht weiter zerlegt werden können, d. h. wenn für deren Bearbeitung kein Wechsel des Bearbeiters mehr erforderlich ist.²⁸ Mehrere Elementaraufgaben können zu Aufgaben zusammengefasst werden,²⁹ sodass sie betriebliche Funktionen darstellen, die von Menschen und/oder Maschinen durchgeführt werden.³⁰ Zur Vereinfachung wird im Rahmen dieser Arbeit festgelegt, dass die Bezeichnung „Aufgabe“ als Synonym für „Elementaraufgabe“ gilt.

Ein Vorgang stellt wiederum eine Zusammenfassung mehrerer Aufgaben dar.³¹

Es ist noch anzumerken, dass die Abgrenzung eines Vorgangs gegenüber Aufgaben oder einem Teilprozess der gleichen Unschärfe unterworfen ist, wie die Untergliederung von Geschäftsprozessen in Teilprozesse, d.h. auch in diesem Fall kann nicht klar definiert werden, wann es sich um Aufgaben handelt und wann um Vorgänge oder Teilprozesse. (vgl. 2.1.2).

Abbildung 1 soll die Zusammenhänge zwischen Prozessen, Teilprozessen, Vorgängen und (Elementar)-Aufgaben abschließend verdeutlichen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Hierarchie von Prozessen, Teilprozessen, Vorgängen und Aufgaben³²

2.1.4 Abgrenzung Geschäftsprozess und Workflow

Workflows stellen, wie Geschäftsprozesse, Abfolgen von Aufgaben dar. Der Unterschied liegt in dem Detaillierungsgrad. Nach Gadatsch sind Workflows so detailliert, dass ihre Beschreibung als Arbeitsanweisung für ausführende Mitarbeiter dienen kann.³³ Diese Definition erinnert an die Definition von Elementaraufgaben bzw. Aufgaben aus Kapitel 2.1.3. Im Rahmen dieser Arbeit soll daher immer dann von einem Workflow gesprochen werden, wenn dessen Beschreibung den Detaillierungsgrad von Aufgaben aufweist. Ist die Beschreibung hingegen auf den Detaillierungsgrad von Teilprozessen und Vorgängen beschränkt, soll von Geschäftsprozessen gesprochen werden.

2.1.5 Geschäftsprozessmodell

Modelle werden allgemein als abstrakte Abbilder der Realwelt verstanden und als Hilfsmittel zur Erklärung und Gestaltung realer Systeme eingesetzt.³⁴ Sie sind Ergebnis einer problembezogenen Strukturierungsleistung und werden durch einen Modellierer mithilfe einer Modellierungssprache erstellt.³⁵ Geschäftsprozessmodelle im Besonderen dienen einer formalen Beschreibung von Geschäftsprozessen der Realwelt und werden zu Analyse sowie Dokumentations- und Gestaltungszwecken im Zusammenhang mit ebendiesen eingesetzt.³⁶

2.1.6 Business Process Modeling

Sämtliche Aktivitäten, mit Bezug auf die Konstruktion von Geschäftsprozessmodellen, werden unter dem Begriff „Business Process Modeling (BPM)“ subsumiert.³⁷ BPM beschäftigt sich mit der Darstellung von Geschäftsprozessen und Sachverhalten, die für eine Gestaltung von Geschäftsprozessen relevant sind (z. B. Datenstrukturen). Zur Darstellung werden meist Modellierungssprachen - wie z. B. EPK - eingesetzt.³⁸ Als alternative Bezeichnungen sollen in dieser Arbeit „Geschäftsprozessmodellierung“ und „Prozessmodellierung“ verwendet werden.

2.1.7 Modellierungssprache und Notation

Eine Modellierungssprache stellt im Gegensatz zu natürlichen Sprachen³⁹ eine Kunstsprache dar, die für einen bestimmten Zweck konstruiert wurde. Sie definiert notwendige Sprachelemente, deren Repräsentationsform sowie deren erlaubte Verknüpfungen. Die systematische Definition der Sprachelemente wird als Orthosprache bezeichnet, die Festlegung der Repräsentationsformen als Notation.⁴⁰

Die durch die Orthosprache festgelegten erlaubten Verknüpfungsmöglichkeiten bzw. Beziehungen von Sprachelementen werden als Syntax bezeichnet.⁴¹ Die Definition der Bedeutung von Sprachelementen stellt die Semantik einer Modellierungssprache dar.⁴²

Notationen können in textuelle und grafische Notationen differenziert werden. In textuellen Notationen stellen Zeichen (z. B. Buchstaben, Zahlen), die aneinandergereiht werden können, die Sprachelemente dar. In einer grafischen Notation sind es Objekte, wie z. B. geometrische Figuren.⁴³

Zur Vereinfachung soll im Rahmen dieser Arbeit der Begriff „Sprache“ als Synonym für „Modellierungssprache“ genutzt werden.

2.2 Klassifikation von Modellierungssprachen

2.2.1 Klassifikation nach Formalisierungsgrad

Modellierungssprachen können entsprechend ihres Formalisierungsgrades in formale, semi-formale und nicht formale Sprachen unterteilt werden.⁴⁴

In formalen Sprachen sind Syntax und Semantik formal definiert, d. h. alle Sprachelemente sind hinsichtlich möglicher Beziehungen und ihrer Bedeutungen vollständig und eindeutig bestimmt. In semi-formalen Sprachen ist i. d. R. die Syntax formal definiert und die Semantik nicht-formal. In nicht-formalen Sprachen ist weder Syntax noch Semantik formal definiert.⁴⁵

Sowohl eEPK als auch BPMN 2.0 zählen zu den semi-formalen Modellierungssprachen.⁴⁶

2.2.2 Klassifikation nach Art der Methode

Neben der Unterscheidung nach dem Formalisierungsgrad können Modellierungssprachen nach Art der Methode unterteilt werden. In diesem Kontext ist zwischen skriptbasierten und grafischen Methoden zu unterscheiden.⁴⁷

Skriptbasierte Methoden bzw. Skriptsprachen (z. B. BPEL⁴⁸ ) erlauben durch eine an Programmiersprachen angelehnte formale textuelle Notation eine sehr hohe Präzision der Modelle, zeichnen sich jedoch auch durch eine geringe Anschaulichkeit aus.⁴⁹

Grafische Methoden bzw. Diagrammsprachen führen im Ergebnis zu grafischen Prozessmodellen bzw. Prozessdiagrammen. Sie lassen sich weiter in kontrollflussorientierte, objektorientierte und datenflussorientierte Sprachen klassifizieren.⁵⁰

Tabelle 1 zeigt eine Übersicht der verschiedenen Klassen und zugehörige beispielhafte Modellierungssprachen. BPMN 2.0 und eEPK sind der kontrollflussorientierten Klasse zuzuordnen.⁵¹ Da den übrigen Sprachen im Rahmen dieser Arbeit keine tiefere Bedeutung zugemessen wird, soll auf diese nicht näher eingegangen werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Übersicht über ausgewählte grafische Modellierungssprachen⁵²

3. BPMN 2.0 und eEPK im Detail

3.1 Anmerkung zum Kapitel

Ein Ziel dieser Arbeit ist, Modellierungsmöglichkeiten von BPMN 2.0 und eEPK zu differenzieren und an die Anforderungen spezifischer Einsatzszenarien anzupassen. Um ein grundlegendes Verständnis darüber zu erhalten, welche Möglichkeiten zur Prozessmodellierung die beiden Sprachen bieten, sollen diese in den folgenden Unterkapiteln grob dargestellt werden.

Detaillierte und vollumfängliche Beschreibungen der Modellierungsmöglichkeiten von BPMN 2.0 und eEPK sind im Rahmen dieser Arbeit explizit nicht Zielsetzung. Da bereits verschiedene Grundlagenwerke bzw. Praxishandbücher auf diese Thematik ausgerichtet sind, sei an dieser Stelle auf ebendiese verwiesen.⁵³

3.2 eEPK

3.2.1 Historie und Versionen von EPK

In 2.2.2 wurde bereits erwähnt, dass eEPK zu den kontrollflussorientierten Modellierungssprachen gehört. Sie wurde im Rahmen des ARIS-Konzeptes⁵⁴ von Keller, Nüttgens und Scheer entwickelt.⁵⁵ Aufgrund der Tatsache, dass sie ein zentraler Bestandteil des SAP-Systems ist, hat sie eine schnelle Verbreitung erfahren und ist heute für die Praxis von hoher Relevanz.⁵⁶

Es existieren neben der ursprünglichen „einfachen“ EPK weitere Versionen, darunter die erweiterte Ereignisgesteuerte Prozesskette (eEPK) und die objektorientierte Ereignisgesteuerte Prozesskette (oEPK).⁵⁷

Im Vergleich zur einfachen EPK sind in eEPK zusätzliche Symbole, wie z. B. Organisationseinheiten verfügbar.⁵⁸ Alle folgenden Kapitel dieser Arbeit beziehen sich stets auf diese Variante.

Daneben stellt oEPK eine Weiterentwicklung von EPK dar, mit den Zielsetzungen, das Konzept ereignisgesteuerter Interaktion von Objekten in objektorientierten komponentenbasierten IT-Systemen auf die Erstellung von Fachkonzepten zu übertragen und Prozesse und zugehörige Objekte integriert zu beschreiben.⁵⁹ Aufgrund ihrer geringen Verbreitung in der Praxis wird diese Variante jedoch nicht weiter betrachtet.⁶⁰

3.2.2 Symbole

Zur grafischen Modellierung von Geschäftsprozessen bietet eEPK eine definierte Menge verschiedener Symbole. Die im Folgenden vorgestellten Symbole stammen aus dem ursprünglichen ARIS-Konzept von Scheer.⁶¹ Es sei jedoch angemerkt, dass in der Praxis weitere Symbole für die eEPK-Modellierung genutzt werden. Dies liegt u. a. darin begründet, dass in der häufig genutzten Software „ARIS Platform⁶² “ weitaus mehr Symbole zur Verfügung stehen.⁶³ In Kapitel 4 werden diese zusätzlichen Symbole im Rahmen der Definition von Modellierungsklassen herangezogen.

Funktionen

Funktionen stellen Tätigkeiten dar, die innerhalb eines Geschäftsprozesses erbracht werden müssen. Analog zu den Definitionen in 2.1 können diese auf verschiedenen Ebenen betrachtet werden, sodass Funktionen zur Repräsentation von Teilprozessen, Vorgängen oder Aufgaben dienen können. Grafisch wird eine Funktion als Rechteck mit abgerundeten Ecken dargestellt (siehe Abbildung 2).⁶⁴

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Grafische Darstellung einer Funktion in eEPK

Ereignisse

Ereignisse werden in eEPK stets als betriebswirtschaftlich relevante Ereignisse verstanden, die für den jeweils betrachteten Geschäftsprozess eine Bedeutung haben. Sie stehen außerdem immer in enger Beziehung zu den zuvor beschriebenen Funktionen: Sie beschreiben entweder den Auslöser oder das Ergebnis von Funktionen. Ereignisse werden als Sechseck dargestellt (siehe Abbildung 3).⁶⁵

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Grafische Darstellung eines Ereignisses in eEPK

Organisationseinheiten

Organisationseinheite n werden Funktionen zugeordnet, um zu dokumentieren, wo in einem Unternehmen eine jeweilige Funktion ausgeführt wird. Prinzipiell können auch mehrere Organisationseinheiten an einer Funktion beteiligt sein. Das Symbol für Organisationseinheiten ist in Abbildung 4 dargestellt.⁶⁶

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Grafische Darstellung einer Organisationseinheit in eEPK

Informationsobjekte

Informationsobjekte werden eingesetzt, um in eEPKs darzustellen, welche Datenbestände und Informationen bei der Durchführung von Funktionen benötigt werden. Grafisch werden sie als Rechtecke oder auch Zylinder dargestellt (siehe Abbildung 5).⁶⁷

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Grafische Darstellung eines Informationsobjekts in eEPK

Kontrollfluss

Der Kontrollfluss stellt den Fluss abwechselnder Funktionen und Ereignisse dar (siehe 3.2.3) und wird durch eine Pfeil-Linie dargestellt (siehe Abbildung 6).⁶⁸

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Grafische Darstellung des Kontrollflusses in eEPK

Operatoren

Über die reine Darstellung einer Abfolge verschiedener Ereignisse und Funktionen hinausgehend, werden in eEPK Modellierungsmöglichkeiten für die Darstellung der Parallelisierung von Funktionen bzw. für alternative Abläufe bereitgestellt. Grafisch werden diese Beziehungen über sogenannte Operatoren abgebildet. Die grafischen Symbole der verschiedenen Operatoren finden sich in Abbildung 7.⁶⁹

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Operatoren in eEPK⁷⁰

3.2.3 Modellierung mit eEPK

Zur Erstellung von aussagekräftigen Prozessmodellen werden die im vorangegangenen Kapitel vorgestellten Symbole nach definierten syntaktischen Regeln miteinander verknüpft. In diesem Kontext ist z. B. zu beachten, dass sich Funktionen und Ereignisse stets gegenseitig ablösen. Der Fluss von Ereignissen und Funktionen (Kontrollfluss) erfolgt i. d. R. von oben nach unten.⁷¹

Abbildung 8 soll an einem einfachen Beispiel aus der Vertriebslogistik verdeutlichen, wie ein Kontrollfluss in eEPK konkret modelliert sein kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Beispielhaftes eEPK-Modell aus dem Bereich der Vertriebslogistik⁷²

3.3 BPMN 2.0

3.3.1 Historie und Versionen von BPMN

BPMN gehört wie eEPK ebenfalls zu den kontrollflussorientierten Modellierungssprachen (vgl. 2.2.2). Sie wurde ursprünglich von der Business Process Management Initiative (BPMI) unter der Federführung von Stephen A. White entwickelt und 2004 in der Version 1.0 veröffentlicht. Zielsetzung war, eine grafische Notation zur Darstellung von BPML⁷³ -Prozessbeschreibungen bereitzustellen. Seit 2006 wird sie von der Object Management Group (OMG)⁷⁴ verantwortet. Vor der in 2011 veröffentlichten heute gültigen Version 2.0 wurden 2008 noch zwei weitere Versionen 1.1 und 1.2 mit geringfügen Änderungen in der Darstellung veröffentlicht.⁷⁵ Alle folgenden Ausführungen in dieser Arbeit beziehen sich stets auf BPMN 2.0.

3.3.2 Symbole

Analog zu eEPK sollen zunächst nur grundlegende Symbole von BPMN 2.0 vorgestellt werden. Im Rahmen von Kapitel 4 werden zusätzlich alle übrigen Symbole dargestellt.

Aktivitäten

Ähnlich wie in eEPK können auch in BPMN 2.0 Aufgaben bzw. Tätigkeiten auf unterschiedlichen Ebenen dargestellt werden. Sie werden hier jedoch nicht Funktionen, sondern Aktivitäten genannt. Mit Aktivitäten können jedoch maximal Vorgänge abgebildet werden, da es für Teilprozesse ein eigenes Symbol gibt (in BPMN 2.0 „Unterprozess“ genannt). Die grafische Darstellung für Aktivitäten und Unterprozesse findet sich in Abbildung 9.⁷⁶

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Grafische Darstellung von Aktivitäten und Unterprozessen in BPMN 2.0

Ereignisse

Auch Ereignisse, die Relevanz für einen Geschäftsprozess aufweisen, können in BPMN 2.0 dargestellt werden. Die grundlegende grafische Darstellung erfolgt durch einen Kreis. Es gibt allerdings eine Vielzahl von Ereignistypen mit jeweils individuellen Kreissymbolen. In diesem Kapitel sollen nur Start- und Endereignisse angeführt werden (siehe Abbildung 10).⁷⁷ Weitere Ereignistypen finden sich in Kapitel 4.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Grafische Darstellung von Start- und Endereignissen in BPMN 2.0

Pools und Lanes

Um Zuständigkeiten innerhalb eines Geschäftsprozesses abzubilden, gibt es in BPMN 2.0 sogenannte Pools und Lanes. Diese können beliebig bezeichnet werden und z. B. für Organisationseinheiten oder aber auch IT-Systeme stehen (siehe Abbildung 11).⁷⁸

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Grafische Darstellung von Pools und Lanes in BPMN 2.0

Sequenzfluss

Das Pendant zum Kontrollfluss aus eEPK wird in BPMN 2.0 „Sequenzfluss“ genannt und zeigt auf, in welcher Reihenfolge Aktivitäten durchgeführt werden. Der Sequenzfluss wird ebenfalls durch eine durchgezogene Pfeil-Linie dargestellt (siehe Abbildung 12).⁷⁹

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Grafische Darstellung eines Sequenzflusses in BPMN 2.0

Gateways

Ähnlich wie die Operatoren in eEPK (vgl. 3.2.2) bietet BPMN 2.0 über Gateways die Möglichkeit, alternative Prozesspfade und Parallelisierungen abzubilden (siehe Abbildung 13). Die drei grundlegenden Gateways AND, OR und XOR decken sich von ihrer Semantik her mit den UND-, ODER- und exklusives ODER-Operatoren aus eEPK.⁸⁰

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Grafische Darstellung von Gateways in BPMN 2.0

3.3.3 Modellierung mit BPMN 2.0

Der Sequenzfluss verläuft bei BPMN 2.0 i. d. R. von links nach rechts, statt von oben nach unten.⁸¹ Wie in eEPK werden Flussobjekte wie Aktivitäten, Ereignisse und Gateways in einer zeitlich logischen Reihenfolge über eine durchgezogene Pfeillinie miteinander verbunden.⁸²

In Abbildung 14 findet sich zur Veranschaulichung ein beispielhaftes BPMN 2.0-Modell für einen einfachen Logistikprozess.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Beispielhaftes BPMN 2.0-Modell aus dem Logistikbereich⁸³

3.4 BPMN 2.0 und eEPK im Vergleich

Nachdem Grundlagen zu BPMN 2.0 und eEPK erläutert wurden, sollen in einem Vergleich Unterschiede und Gemeinsamkeiten zwischen beiden Notationen identifiziert werden. Dazu werden zunächst Anforderungen an Modellierungssprachen untersucht, um daraus entsprechende Kriterien für einen Vergleich ableiten zu können.

3.4.1 Anforderungen an Modellierungssprachen

In Anlehnung an Frank und van Laak können für alle Modellierungssprachen drei verschiedene Arten genereller Anforderungen formuliert werden: formale Anforderungen, anwenderbezogene Anforderungen und anwendungsbezogene Anforderungen.⁸⁴

Formale Anforderungen gliedern sich in „Korrektheit und Vollständigkeit“, „Einheitlichkeit und Redundanzfreiheit“ sowie „Wiederverwendbarkeit und Wartbarkeit“.⁸⁵

Anwenderbezogene Anforderungen werden weiter in „Einfachheit“ und „Verständlichkeit und Anschaulichkeit“ unterteilt.⁸⁶

Zu den anwendungsbezogene Anforderungen zählen „Mächtigkeit und Angemessenheit“ sowie „Operationalisierbarkeit“.⁸⁷

3.4.2 Ableitung von Bewertungskriterien für Modellierungssprachen

Um die in 3.4.1 dargestellten Anforderungen bewerten zu können, wurden verschiedene Kriterien abgeleitet und der jeweiligen Anforderung zugeordnet (siehe Tabelle 2).⁸⁸

Die anwendungsbezogene Anforderung „Angemessenheit“ wurde aus der Betrachtung herausgenommen, da diese von einer subjektiven Einschätzung abhängig ist und sich nicht durch präzise Kriterien beschreiben lässt.⁸⁹

[...]

---

¹ Vgl. (Mendling, 2008, S. 1)

² Vgl. (Becker, Kugeler, & Rosemann, 2012, S. 53 ff.)

³ Vgl. (Gadatsch, 2012, S. 100)

⁴ Vgl. z. B. (Bobrik, 2008, S. 8)

⁵ Vgl. z. B. (Silver, 2012); (Shapiro, et al., 2012)

⁶ Ein methodischer Auftrag zeichnet sich dadurch aus, dass er „das Verstehen und Entwickeln von Methoden und Techniken zur Beschreibung, Entwicklung, Einführung und Nutzung von Informationssystemen“ umfasst. [Vgl. (Becker et al., 2001, S. 11)]

⁷ Im Gegensatz zu „Erkenntniszielen“, die das Verstehen gegebener Sachverhalte anstreben, ist ein „Gestaltungsziel“ auf die Gestaltung bzw. Veränderung bestehender Sachverhalte ausgerichtet. [Vgl. (Becker et al., 2001, S. 11)]

⁸ Vgl. (Becker et al., 2001, S. 11)

⁹ Der allgemeine Begriff der Methode steht nach Chmielewicz für ein Vorgehen, das sich durch eine bestimmte Auswahl von Instrumenten als Mittel der Zielerreichung auszeichnet. Im Kontext der Wirtschaftsinformatik stehen daneben stets die Merkmale „Zielorientierung“, „Systematik“, „Prinzipienorientierung“ und „Nachvollziehbarkeit“ im Vordergrund. [Vgl. (Chmielewicz, 1994, S. 36 f.); (Braun, Hafner, & Wortmann, 2004, S. 10 ff.)]

¹⁰ Ein Entwurfsartefakt kann durch Konstrukte, Modelle, Methoden oder Instanziierungen gegeben sein. [Vgl. (Hevner et al., 2004, S. 82 f.)]

¹¹ Das konstruktionswissenschaftliche Paradigma verfolgt die Entwicklung neuer und innovativer Artefakte, um die Fähigkeiten von Menschen und Organisation zu erweitern. [Vgl. (Hevner et al., 2004, S. 75)]

¹² Vgl. (Hevner et al., 2004, S. 82 ff.)

¹³ Vgl. (Wilde & Hess, 2006, S. 7)

¹⁴ Vgl. (König et al., 1996a, S. 46)

¹⁵ Die CSC Deutschland Solutions GmbH ist eine Tochtergesellschaft der Computer Sciences Corporation (CSC), einem weltweit führenden Anbieter für IT-gestützte Businesslösungen und Dienstleistungen. Die deutsche Zentrale befindet sich in Wiesbaden [Vgl. (CSC, 2013, S. 1)]

¹⁶ Vgl. z. B. (Davenport, 1993, S. 5); (Hammer & Champy, 1994, S. 52); (Österle, 1995, S. 62 f.); (Rosemann, 1996a, S. 9); (Becker & Schütte, 2004, S. 107 f.)

¹⁷ Vgl. (Koch, 2011, S. 1)

¹⁸ Vgl. (Hammer & Champy, 1994, S. 52)

¹⁹ Vgl. (Becker & Schütte, 2004, S. 107 f.); (Rosemann, 1996a, S. 9)

²⁰ Vgl. (Gehring, 1998) zitiert nach: (Gadatsch, 2012, S. 36 f.)

²¹ Vgl. (Saatkamp, 2002, S. 63)

²² Vgl. (Koch, 2011, S. 1 f.)

²³ Vgl. (Ott, 1995, S. 82)

²⁴ Vgl. (Hess & Brecht, 1996, S. 127)

²⁵ Vgl. (Staud, 2006, S. 23)

²⁶ Vgl. (Staud, 2006, S. 4)

²⁷ Vgl. (Bullinger & Fähnrich, 1997, S. 41)

²⁸ Vgl. (Gadatsch, 2012, S. 37)

²⁹ Vgl. (Staud, 2006, S. 6)

³⁰ Vgl. (Österle, 1995, S. 50)

³¹ Vgl. (Bullinger & Fähnrich, 1997, S. 19)

³² Selbsterstellte Grafik

³³ Vgl. (Gadatsch, 2012, S. 46 f.)

³⁴ Vgl. (Stachowiak, 1979, S. 131); (Becker, Rosemann, & Schütte, 1995, S. 435)

³⁵ Vgl. (Schütte, 1998, S. 51 u. 59)

³⁶ Vgl. (Gadatsch, 2012, S. 63)

³⁷ Vgl. (Funk et al., 2010, S. 13)

³⁸ Vgl. (Allweyer, Geschäftsprozessmanagement - Strategie, Entwurf, Implementierung, Controlling, 2005, S. 94)

³⁹ Natürliche Sprachen stellen historisch entwickelte sowie regional und sozial geschichtete Sprachen dar. [Vgl. (Bußmann, 2002, S. 516)]

⁴⁰ Vgl. (Seel, 2010, S. 37)

⁴¹ Vgl. (Seel, 2010, S. 39)

⁴² Vgl. (Fromkin, Rodman, & Hyams, 2003, S. 592)

⁴³ Vgl. (Larkin & Simon, 1987, S. 68)

⁴⁴ Vgl. (Remme, 1997, S. 44); (Balzert, 2001, S. 110 f.)

⁴⁵ Vgl. (Dietzsch, 2002, S. 58)

⁴⁶ Vgl. (Bartsch, 2010, S. 86)

⁴⁷ Vgl. (Gadatsch, 2012, S. 63)

⁴⁸ BPEL ist eine Skriptsprache, die typischerweise eingesetzt wird, um ausführbare Geschäftsprozessmodelle zu erstellen. [Vgl. (Lessen, Lübke, & Nitzsche, 2011, S. 53 f.)]

⁴⁹ Vgl. (Gadatsch, 2012, S. 64)

⁵⁰ Vgl. (Gadatsch, 2012, S. 64)

⁵¹ Vgl. (Gadatsch, 2012, S. 66 ff.)

⁵² Vgl. (Gadatsch, 2012, S. 64)

⁵³ Für eEPK siehe z.B. (Staud, 2006); für BPMN 2.0 siehe z.B. (Freund & Rücker, 2012), (Göpfert & Lindenbach, 2013)

⁵⁴ ARIS (Ar chitektur integrierter I nformations s ysteme) steht für ein Konzept mit einer prozessorientierten Sichtweise, d.h. die Betrachtung von Abläufen in einem Unternehmen als zielgerichtetes Zusammenwirken von Geschäftsprozessen. Neben der Integration von Informationssystemen werden hier verschiedene andere Aspekte betrachtet, die als Sichten bezeichnet werden: Datensicht, Funktionssicht, Organisationssicht, Ressourcensicht und Steuerungssicht. Vgl. (Scheer, 1997, S. 4 ff.)

⁵⁵ Vgl. (Scheer, 1997, S. 4 ff.)

⁵⁶ Vgl. (Gadatsch, 2012, S. 170)

⁵⁷ Vgl. (Gadatsch, 2012, S. 64)

⁵⁸ Vgl. (Staud, 2006, S. 80)

⁵⁹ Vgl. (Scheer, Nüttgens, & Zimmermann, 1997, S. 16)

⁶⁰ Vgl. (Gadatsch, 2012, S. 97)

⁶¹ Vgl. (Scheer, 1997, S. 11)

⁶² „ARIS Platform“ stellt eine Weiterentwicklung der Geschäftsprozessanalyse-Software „ARIS Toolset“ dar, die ursprünglich von der IDS Scheer AG entwickelt worden ist. Im Zuge einer Unternehmensverschmelzung in 2010 wurde sie geistiges Eigentum der Software AG. [Vgl. (Software AG, 2013, S. 1)]

⁶³ Vgl. (Mustermann, 2013, S. I Anhang)

⁶⁴ Vgl. (Staud, 2006, S. 60 ff.)

⁶⁵ Vgl. (Staud, 2006, S. 62f.)

⁶⁶ Vgl. (Staud, 2006, S. 63f.)

⁶⁷ Vgl. (Staud, 2006, S. 64); (Software AG, 2012, S. 126)

⁶⁸ Vgl. (Staud, 2006, S. 68)

⁶⁹ Vgl. (Staud, 2006, S. 66)

⁷⁰ Vgl. (Gadatsch, 2012, S. 174)

⁷¹ Vgl. (Staud, 2006, S. 67 f.)

⁷² Vgl. (Gadatsch, 2012, S. 80)

⁷³ BPML (Business Process Modeling Language) dient, ähnlich wie die Business Process Execution Language (BPEL), zur Spezifikation von ausführbaren Prozessbeschreibungen. [Vgl. (Allweyer, 2009, S. 10)]

⁷⁴ Die OMG ist eine Non-Profit-Organisation und stellt ein Konsortium dar, welches sich mit der Entwicklung von Standards für die Computer-Industrie, wie z.B. der Unified Modeling Language (UML), beschäftigt. [Vgl. (OMG, 2013)]

⁷⁵ Vgl. (Allweyer, 2009, S. 10); (White, 2004)

⁷⁶ Vgl. (Object Management Group, 2011, S. 29 u. 33)

⁷⁷ Vgl. (Object Management Group, 2011, S. 31 f.)

⁷⁸ Vgl. (Object Management Group, 2011, S. 30)

⁷⁹ Vgl. (Object Management Group, 2011, S. 29)

⁸⁰ Vgl. (Object Management Group, 2011, S. 34)

⁸¹ Vgl. (Allweyer, 2009, S. 21)

⁸² Vgl. (Object Management Group, 2011, S. 315 ff.)

⁸³ Selbsterstellte Grafik

⁸⁴ Vgl. (Frank & Laak, 2003, S. 25)

⁸⁵ Vgl. (Frank & Laak, 2003, S. 26 ff.)

⁸⁶ Vgl. (Frank & Laak, 2003, S. 28 ff.)

⁸⁷ Vgl. (Frank & Laak, 2003, S. 31 ff.)

⁸⁸ Vgl. (Frank & Laak, 2003, S. 26 ff.)

⁸⁹ Vgl. (Frank & Laak, 2003, S. 33)

• Universidad: University of Applied Sciences Mainz
• Calificación: 2,0
• Autor: Carlos Sinaga (Autor)
• Año de publicación: 2014
• Páginas: 80
• No. de catálogo: V583479
• ISBN (Ebook): 9783346181091
• ISBN (Libro): 9783346181107
• Idioma: Alemán
• Etiqueta: Prozessmodellierung, BPMN, eEPK, EPK, Business Process Modeling, Geschäftsprozesse, Business Process Management, Prozessmodelle, Modellierungssprachen