Universität Ulm | 89069 Ulm | Germany Fakultät für
Ingenieurwissenschaften
und Informatik
Institut für Datenbanken
und Informationssysteme
Referenzprozessmodellierung:
Methoden, Konzepte und
Transformationen
Masterarbeit an der Universität Ulm
Vorgelegt von:
Mutlu Oytun
Karlstraße 11
89150 Laichingen
mutlu.o[email protected]
Gutachter:
Prof. Dr. Manfred Reichert
Prof. Dr. Franz Schweiggert
2015
Fassung 31. Mai 2015
c
2015 Mutlu Oytun
Karlstraße 11
89150 Laichingen
Abstract
Nowadays, companies are faced with historically grown structures and processes. Addi-
tionally, within this environment the increased competition, declining product lifecycles
and new working methods force companies to constantly improve their existing business
processes and adapt to those new requirements. To shorten the adaptation process or
develop new business units reference models offer approved business processes and
structures. Reference models offer a general framework for companies. They can derive
their company specific process variants on the basis of reference models.
This thesis tries to give an overview on existing methods and concepts within the
refence model environment and reference process modeling. Existing reference models
will be presented and their application areas explained. This work also includes the
transformation of existing reference models, which were modeled in event-driven process
chains (EPC), to business process model and notation (BPMN).
The intention is to show the feasability of transformation on existing reference models in
EPC to BPMN 2.0. At the end a critical evaluation and a summary of gained experienced
will be presented.
Kurzfassung
Historisch gewachsene Strukturen und Abläufe stellen Unternehmen vor neuen Her-
ausforderungen. Diese bestehen im erhöhten Wettbewerbsdruck, kürzer werdenden
Produktlebenszyklen und neuen Arbeitsmethoden. Innerhalb dieses Umfelds ist es
notwendig, die vorhandenen Geschäftsprozesse stets zu verbessern und den neuen
Anforderungen anzupassen. Um die Anpassungsvorgänge zu beschleunigen haben
sich Referenzmodelle bewährt. Referenzmodelle oder Referenzinformationsmodelle
stellen durch ihre Allgemeingültigkeit vordefinierte und bewährte Abläufe dar, an der sich
Unternehmen ihre spezifischen Modelle ableiten können.
iii
Die vorliegende Arbeit versucht zuerst ein Überblick über die vorhandenen Methoden
und Konzepte innerhalb der Referenzprozessmodellierung zu geben. Dabei werden
auch vorhandene Referenzmodelle aufgelistet und ihre Einsatzgebiete aufgezeigt. Ein
weiterer Bereich, welches diese Arbeit umfasst, ist die Transformation von vorhandenen
Referenzmodellen. Die Transformation erfolgt von ereignisgesteuerten Prozessketten
nach Business Process Model and Notation (BPMN) 2.0.
Diese Arbeit wird die Durchführbarkeit der Transformation nach BPMN 2.0 aufzeigen
und die gesammelten Erkenntnisse wiedergeben.
iv
Abkürzungsverzeichnis
ARIS Architektur integrierter Informationssysteme
BPMN Business Process Model and Notation
CIM Computer Integrated Manufacturing
EPK Ereignisgesteuerte Prozesskette
ER Entity Relationship
ERM Entity Relationship Model
GP Geschäftsprozess
GoM Grundsätze ordnungsmäßiger Modellierung
GoR Grundsätze ordnungsmäßger Referenzmodellierung
OMG Object Management Group
RM Referenzmodell
RIM Referenzinformationsmodell
SAP Systeme, Anwendungen, Produkte
UML Unified Modeling Language
VKD Vorgangskettendiagramm
WfMC Workflow Management Coalition
Architektur integrierter Informationssysteme (
ARIS
) Business Process Model and Notati-
on (
BPMN
) Computer Integrated Manufacturing (
CIM
) Ereignisgesteuerte Prozessket-
te (
EPK
) Entity Relationship (
ER
) Entity Relationship Model (
ERM
) Geschäftsprozess
(
GP
) Grundsätze ordnungsmäßiger Modellierung (
GoM
) Grundsätze ordnungsmäßger
Referenzmodellierung (
GoR
) Object Management Group (
OMG
) Referenzmodell (
RM
)
v
Inhaltsverzeichnis
1. Einleitung 1
1.1.Ausgangssituation ............................... 1
1.2.Problemstellung ................................ 3
1.3.BeitragderArbeit................................ 5
1.4.Forschungsmethodik.............................. 6
1.5.AufbauderArbeit................................ 7
2. Grundlagen 11
2.1.Geschäftsprozesse............................... 12
2.2.Prozessmodellierung.............................. 16
2.3. Beschreibungssprachen zur Modellierung . . . . . . . . . . . . . . . . . . 21
2.3.1. Meta-Modell der Beschreibungssprachen . . . . . . . . . . . . . . 22
2.3.2. Ereignisgesteuerte Prozessketten . . . . . . . . . . . . . . . . . . 24
2.3.3. Business Process Model and Notation 2.0 . . . . . . . . . . . . . . 27
2.4. Segmentierung und Kaskadierung von Geschäftsprozessen . . . . . . . . 30
2.5. Grundsätze ordnungsmäßiger Modellierung . . . . . . . . . . . . . . . . . 33
2.6. Ziele der Prozessmodellierung . . . . . . . . . . . . . . . . . . . . . . . . 35
3. Referenzprozessmodellierung 37
3.1. Definition Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2. Klassifikation von Referenzmodellen . . . . . . . . . . . . . . . . . . . . . 42
vii
Inhaltsverzeichnis
3.3. Sprachen und Gestaltungsmöglichkeiten der Referenzmodelle . . . . . . 44
3.4. Vorgehensmodell zur Referenzmodellierung . . . . . . . . . . . . . . . . . 48
3.5. Grundsätze ordnungsmäßiger Referenzprozessmodellierung . . . . . . . 50
3.6. Ziele der Referenzprozessmodellierung . . . . . . . . . . . . . . . . . . . 53
3.7. Literaturrecherche und vorhandene Referenzmodelle . . . . . . . . . . . . 55
4. Referenzmodelle in EPK und ihre Einsatzgebiete 59
4.1. Referenzmodell für industrielle Geschäftsprozesse . . . . . . . . . . . . . 60
4.2. Referenzmodell für den Handel . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3. Referenzmodell für vertriebslogistische Systeme . . . . . . . . . . . . . . 67
4.4. Referenzmodell für die Handelslogistik . . . . . . . . . . . . . . . . . . . . 69
4.5. Weitere Referenzmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5. Modellierung und Transformation von EPK-Referenzprozessen nach BPMN
2.0 73
5.1. Signavio das BPMN-Modellierungstool . . . . . . . . . . . . . . . . . . . . 74
5.2. Vorgehensweise für Transformation . . . . . . . . . . . . . . . . . . . . . . 76
5.3. Auswahl und Überblick der Prozesse . . . . . . . . . . . . . . . . . . . . . 77
5.4. Transformationsregeln der Referenzprozesse nach BPMN . . . . . . . . . 79
5.5. Analyse der Transformationsregeln und der Beschreibungssprachen . . . 83
5.6. Validierung der transformierten Prozesse . . . . . . . . . . . . . . . . . . 85
5.7. Erkenntnisse und Lessons Learned . . . . . . . . . . . . . . . . . . . . . 87
6. Diskussion 91
7. Zusammenfassung und Ausblick 97
7.1.Zusammenfassung............................... 97
7.2.Ausblick..................................... 99
A. Übersicht vorhandener Referenzmodelle 101
B. Transformierte Modelle in BPMN 2.0 107
viii
1
Einleitung
Dieses Kapitel stellt die Zielsetzung und den Aufbau der Arbeit dar. Daher wird zuerst
die Ausgangssituation erläutert, anhand dessen die Problemstellung abgeleitet wird.
Desweiteren wird auf den Beitrag der Arbeit und die Forschungsmethodik eingegangen.
Der letzte Abschnitt gibt einen Überblick über die Zusammensetzung und Aufbau der
Arbeit.
1.1. Ausgangssituation
Um im globalen Wettbewerb bestehen zu können stehen Unternehmen vor der Her-
ausforderung ihre historisch gewachsenen Abläufe und Strukturen auf die neuen Gege-
1
1. Einleitung
benheiten auszurichten. Dabei spielt innerhalb des dynamischen Umfelds flexible und
effiziente Strukturen eine essenzielle Rolle. Unternehmen sind heute mehr denn je auf
effiziente und effektive Informations- und Kommunikationsmittel angewiesen. Dabei spielt
die Informationstechnik eine entscheidende Rolle. Kürzer werdenden Produktlebenszy-
klen und die stärkere Ausrichtung auf die Kundenbedürfnisse benötigen durchgängig
dokumentierte und strukturierte Arbeitsabläufe. Dadurch können Unternehmen eine
optimale Allokation der Ressourcen und Kostenminimierung erreichen, welches auf
die Profitabilität positiv auswirkt [
SAJK02
, S.47]. Die Anpassungen innerhalb dieses
dynamischen Umfelds sind nur durch eine gezielte Ausrichtung der Leistungserstellung
an die Markt- und Kundenbedürfnisse möglich. Dies zu erreichen erfordert von Unter-
nehmen ihre Flexibilität, Produktivität, Innovation, Schnelligkeit und Unternehmenskultur
anzupassen und weiterzuentwickeln [Sch04, S.1].
Geschäftsprozessmanagement spielt in diesem Umfeld eine wichtige Rolle. Sie ermög-
licht die Dokumentation und Verbesserung der Arbeitsabläufe. Eine Neugestaltung bzw.
Ausrichtung des Unternehmens auf die Leistungserstellung erfordert eine tiefgreifende
Analyse der vorhandenen Strukturen. Insbesondere stehen größere Unternehmen vor
undokumentierten, komplexen und historisch gewachsenen Abläufen und Strukturen
[
Gad04
, S.60]. Außerdem führen die Entwicklungen der letzten Jahre innerhalb der
Informationstechnologie zu steigenden und komplexen Informationssystemen, auf die
die Unternehmen angewiesen sind. Daher versuchen Unternehmen ein Unternehmens-
modell zu erstellen, welches ihre Abläufe und Strukturen dokumentiert und darstellt. Für
die Unternehmensmodellierung stehen zwei Herangehensweisen zu Verfügung, welche
im Folgenden vorgestellt werden [SRS96, S.266]:
•
Der klassische Ansatz besteht darin, die Ist-Abläufe zu dokumentieren und einer
detaillierten Analyse unterzuziehen. Aus den gewonnen Erkenntnissen wird die
Verbesserung abgeleitet und ein Soll-Modell definiert. Dabei kann das Soll-Modell
auch ohne ein Ist-Modell definiert werden. Der Nachteil des klassischen Ansatzes
besteht in der hohen Zeit- und Arbeitsaufwand, die für die Ist-Modellierung und
Analyse aufgewendet wird. Für das Endresultat spielt die Erfahrung der Modellierer
2
1.2. Problemstellung
eine erhebliche Rolle. Meistens scheitern diese Vorhaben aufgrund des Aufwands
und knappen Ressourcen.
•
Der alternative Ansatz basiert auf die Referenzmodelle. Diese Vorgehensweise
sieht den Einsatz von vordefinierten und allgemeinen Prozessmodellen für die
Analyse und das Soll-Modell vor, die bewährte Prozess-Know-Hows beinhalten.
Dabei versuchen die Referenzmodelle den hohen Aufwand und Fehler bei der Ist-
und Soll-Modellierung zu minimieren und den Modellierer zu unterstützen.
Referenzinformationsmodelle haben eine weite Verbreitung in der Theorie und Pra-
xis erfahren. Dabei spielen Standardsoftwaresysteme eine erhebliche Rolle, welche
betriebswirtschaftlich bewährtes Wissen in der Informationstechnik abbilden. Dabei ab-
strahieren Referenzinformationsmodelle vom Einzelfall und bieten Transparenz über das
betriebswirtschaftliche Unternehmenswissen. Sie soll die Basis für die Schwachstellen-
analyse, Ableiten von spezifischen Prozessmodellen und Auswahl von Standardsoftware
bieten. Die vorliegende Arbeit beschäftigt sich mit Referenzinformationsmodellen und
wird die vorhanden Konzepte, Methoden und Transformationen vorstellen.
1.2. Problemstellung
Unternehmen haben sehr vielen Geschäftsprozesse, die einzeln dokumentiert und ana-
lysiert werden müssen. Für die Dokumentation wird dabei auf die Prozessmodellierung
und vorhandene Modellierungssprachen zurückgegriffen. Dabei ist die Prozessmodellie-
rung keine einfache Aufgabe, welches Rosemann durch seine Veröffentlichung „Potential
pitfalls of process modeling“ [
Ros06a
] darstellt. Dabei geht er auf einzelne kritische Be-
reiche innerhalb der Prozessmodellierung ein und erläutert mögliche Fehlerquellen. Eine
mögliche Fehlerquelle bei der Prozessmodellierung ist der Modellierer selbst [
Ros06a
,
S.252]. Werden die Modelle durch unerfahrenes Personal erstellt steigt die Fehlerrate
erheblich und die Modellqualität sinkt.
3
1. Einleitung
Bei der Modellierung und Gestaltung von Prozessmodellen bzw. Unternehmensmodellen
können Referenzmodelle eine fehlerminimierende und komplexitätreduzierende Funk-
tion übernehmen. Dabei sind Referenzmodelle aufgrund Ihrer Allgemeingültigkeit und
Empfehlungscharakter sehr allgemein gefasst. Die methodischen Aspekte innerhalb der
Referenzmodellierung werden in der Literatur ausgiebig diskutiert [
Fet06
] und klassifi-
ziert [
FL03a
]. Auch über die Konstruktion hin zu eigentlichen Nutzung und Management
der Referenzmodelle gibt es Ansätze, die auch die Evaluationsmethodik betrachten
[Tho06].
In der Literatur und Praxis sind sehr viele Referenzmodelle vorhanden. Diese werden
anhand von verschiedenen Sprachen, wie ereignisgesteuerte Prozessketten, Unified
Modeling Language oder Petri Netzen vorgestellt. Nichtsdestotrotz gibt es für die Pro-
zessmodellierung von Fachprozessen und Workflows nicht sehr viele alternativen. Zu
den genannten Sprachen kam im Jahr 2004 die Modellierungssprache BPMN hinzu,
welche im Januar 2011 mit der Version 2.0 eine Aktualisierung erhalten hat [
Gro13
].
BPMN steht für Business Process Model and Notation und wurde unter Berücksich-
tigung früherer Erfahrungen entwickelt. Diese Modellierungssprache bietet aufgrund
ihrer Aktualität und Standardisierung, durch die Objekt Management Group, eine weite
Verbreitung in der Praxis.
Durch die weite Verbreitung und Akzeptanz von BPMN ist es ratsam Referenzmodelle
in dieser Sprache den Nutzern zu Verfügung zu stellen. Aktuell gibt es keine Referenz-
modelle in BPMN, daher ist es empfehlenswert vorhandene Referenzmodelle nach
BPMN zu transformieren. Da die ereignisgesteuerten Prozessketten sich durch das
ARIS-Konzept und die weite Verbreitung von SAP in der Praxis etabliert haben, eignen
sich Referenzmodelle dieser Sprache für die Transformation. Die Referenzmodelle, die
mit ereignisgesteuerten Prozessketten modelliert wurden und frei zugänglich sind ba-
sieren auf die Veröffentlichungen von Autoren wie Scheer, Becker & Schütte, Kruse,
Remmert oder Stadler. Somit könnte die Lücke bis zu konkreten Referenzmodellen, die
in BPMN modelliert werden, geschlossen werden.
4
1.3. Beitrag der Arbeit
1.3. Beitrag der Arbeit
Wie auch im vorherigen Abschnitt erwähnt gibt es keine praktischen Referenzmodelle
in BPMN 2.0. Daher ist es notwendig vorhandene Referenzmodelle auf die mögliche
Darstellung durch BPMN zu untersuchen. Dabei könnte die Lücke der fehlenden Re-
ferenzmodelle in BPMN überbrückt werden. Die vorliegende Arbeit stellt einen Beitrag
bezüglich der Durchführbarkeit der Transformation an vorhandenen Referenzmodellen
nach BPMN 2.0 dar. Außerdem wird ein Überblick über die vorhandenen Veröffentlichun-
gen gegeben und die Theorie der Referenzmodelle analysiert. Daher gibt die Arbeit
einen guten Überblick über die vorhandenen Referenzmodelle und gibt die Erfahrungen
der Transformation wieder. Es werden vorhandene Gestaltungselemente untersucht und
mögliche Informationsverluste dargestellt.
Es sei vorab zu erwähnen, dass die vorliegende Arbeit nicht den Anspruch erhebt, die
Thematik der Transformation und der Referenzmodelle vollständig darzustellen. Die
Theorie der Referenzmodelle ist sehr vielfältig und betrachtet je nach Gesichtspunkten
des Betrachters bestimmte Aspekte als relevant oder vernachlässigbar. Daher wird ein
bestimmter Weg ausgewählt und bestimmte Ziele verfolgt.
Die vorliegende Arbeit verfolgt folgende Ziele:
•Untersuchung vorhandener Referenzmodelle und Durchführung einer Literaturre-
cherche.
•
Untersuchung vorhandener Modellierungssprachen und ihrer Elemente. Dabei ist
der Fokus auf EPK und BPMN 2.0
•
Durchführung von Transformationen und Erstellung von konkreten Referenzmodel-
len in BPMN 2.0
Somit beinhaltet die Arbeit sowohl eine theoretische Basis als auch praktische Gestal-
tungselemente, um die theoretische Basis zu ergänzen.
5
1. Einleitung
1.4. Forschungsmethodik
Dieser Abschnitt stellt die Vorgehensweise und die Forschungsmethodik dar. Die Ziele
der Arbeit wurden bereits im vorherigen Abschnitt erläutert. Einer der Ziele der Arbeit war
die Durchführung einer Literaturrecherche, die das Fundament dieser Arbeit ist. Um eine
Literaturrecherche durchzuführen sind im Vorfeld bestimmte Vorbereitungen zu treffen.
Wie eine systematische Literaturrecherche durchzuführen ist, ist in dem Artikel von Keele
University and University of Durham [
Kee07
] beschrieben. Die Richtlinie beinhaltet das
Erstellen von Forschungsfragen, Definition von Suchwörtern, auswählen von relevanten
Quellen und Einbeziehungs- oder Ausschusskriterien von vorhandenen Daten.
Die relevanten Forschungsfragen für die Literaturrecherche in dieser Arbeit sind folgende:
•Welche Referenzmodelle sind in der Literatur vorhanden und offen zugänglich?
•
Gibt es Untersuchungen und frühere Literaturrecherchen, die eine Klassifikation
vorgenommen haben?
•In welchen Sprachen wurden die Referenzmodelle modelliert?
•Welche Methoden sind in der Referenzmodellierungsforschung vorhanden?
•
Welche Autoren haben Referenzmodelle erstellt? Haben sie weitere Veröffentli-
chungen in diesem Bereich?
Bevor die eigentliche Untersuchung durchgeführt wird, müssen Suchbegriffe bestimmt
und verfeinert werden. Folgenden Suchbegriffe wurden für die Untersuchung genutzt: „re-
ference model“, „reference models“, „reference modelling“, „reference processes“,“reference
model classification“,’„Referenzmodelle“, „Referenzunternehmensmodelle“, „Referenz-
modellierung“ oder „Referenzprozesse“.
Während der Untersuchung kamen bestimmte Autoren häufig in Veröffentlichungen vor,
weshalb auch deren weitere Veröffentlichungen untersucht wurden. Folgende Autoren
wurden speziell untersucht: „August Wilhelm Scheer“, „Jörg Becker“, „Reinhard Schütte“,
„Peter Fettke“, „Michael Rosemann“, „Peter Loos“ oder „Jan vom Brocke“
6
1.5. Aufbau der Arbeit
Nachdem die Suchwörter definiert wurden, mussten die Datenbanken durchsucht wer-
den. Dabei wurden folgende Datenbanken und Suchmaschinen genutzt:
•Google Scholar
•Springer Link
•IEEE Xplore Digital Library
•Ebesco Host
Diese Datenbanken ermöglichen eine breite Durchsuchung von vorhandenen Veröf-
fentlichungen und ermöglichen somit einen guten Zugang zu neuen Veröffentlichungen.
Dabei wurden während der Suche nur Veröffentlichungen berücksichtigt, die auch explizit
das Thema der Referenzmodellierung und -modelle beschrieben haben. Veröffentlichun-
gen, die auf einer sehr allgemeinen Basis beruhen, wurden nicht berücksichtigt. Wichtig
ist, dass vorhandene Veröffentlichungen methodische Aspekte und/oder praktische
Referenzmodelle beschreiben und darstellen.
1.5. Aufbau der Arbeit
Die folgende Arbeit gliedert sich in sieben Kapitel. In den ersten Abschnitten wird die
Ausgangssituation, Problemstellung, Beitrag der Arbeit und die Forschungsmethode
vorgestellt. Sie führt den Leser in die Thematik ein und stellt den Gegenstand der Arbeit
vor. Im Anschluss dieses Kapitels folgt Kapitel 2 mit den Grundlagen. Dabei werden
die Begriffe Geschäftsprozess und Prozessmodellierung beschrieben. Die Grundlagen
enthalten auch die Werkzeuge der Kaskadierung und Segmentierung. Dabei wird in
diesem Kapitel auf die Grundsätze ordnungsmäßiger Modellierung eingegangen, welche
die Prozessqualität gewährleistet und in späteren Kapiteln auch eine Rolle spielt.
Im darauffolgenden Kapitel, Kapitel 3, wird auf die Referenzprozessmodellierung ein-
gegangen. Dieses Kapitel stellt die Terminologie dieses Begriffs vor und führt eine
Klassifikation durch. Innerhalb dieses Kapitels spielt das Vorgehensmodell zur Referenz-
7
1. Einleitung
modellierung und die Gestaltungswerkzeuge eine zentrale Rolle. Im letzten Abschnitt
erfolgt die Ergebnispräsentation der Literaturrecherche, welches die Basis für Kapitel 4
bildet.
Kapitel 4 beinhaltet ausgewählte Referenzmodelle, die in ereignisgesteuerten Prozess-
ketten modelliert wurden und stellt sie näher vor. Dabei werden die Referenzmodelle für
industriellen Geschäftsprozesse, Handel, vertriebslogistische Systeme und Handelslo-
gistik näher beschrieben und vorgestellt. Außerdem beinhaltet dieses Kapitel im letzten
Abschnitt die Vorstellung von weiteren Referenzmodellen, die nicht in ereignisgesteuerte
Prozessketten modelliert wurden.
Kapitel 5 stellt die Transformation und Modellierung von Referenzmodellen nach BPMN
2.0 vor. Dabei wird auf das Prozessmodellierungstool Signavio eingegangen. Vor der
eigentlichen Transformation werden die Vorgehensweise, ausgewählte Prozesse und
Transformationsregeln beschrieben. Kapitel 5 schließt mit den Erkenntnissen aus der
Transformation ab.
Das vorletzte Kapitel, Kapitel 6, beinhaltet eine Diskussion und kritische Betrachtung
der Themenbereiche der Referenzmodelle und der Transformation. Dabei werden die
Ergebnisse und Befunde der Arbeit kritisch gewürdigt. Dem Leser wird hier sowohl die
Kritik aus der Literatur als auch die praktischen Erkenntnisse der Arbeit argumentativ
präsentiert.
Kapitel 7 schließt die Arbeit mit einer Zusammenfassung und Ausblick ab. Dabei werden
die Ergebnisse noch einmal vorgestellt und weitere Bereiche in der ein Forschungsbedarf
ist aufgezeigt. Abbildung 1.1 verdeutlicht den Aufbau dieser Arbeit.
8
1.5. Aufbau der Arbeit
Abbildung 1.1.: Aufbau der Arbeit
9
2
Grundlagen
Geschäftsprozesse sind heute in vielen Bereichen und Industriezweigen allgegenwärtig.
Sie findet eine weite Verbreitung und Nutzung in der Automobilindustrie [
MHHR06
] sowie
im Gesundheitswesen [
LR07
] und ist ein fester Bestandteil akademischer Forschung.
Das Interesse an der Darstellung von Unternehmensstrukturen und seiner Umwelt hat
eine lange Historie. Angefangen von Strukturanalysen von
Gane und Sarson
[
GS79
]
zu Business Process Reengineering von
Hammer and Champy
[
HC94
] hinzu Workflow
Management von der Workflow Management Coalition [
Fis00
] nahm das Interesse an
Geschäftsprozessen stetig zu.
In der heutigen globalisierten Welt ist es für Unternehmen essenziell sich stets den
Markt- und Kundenanforderungen konsequent auszurichten. Diese stetigen Anpassun-
gen führen zu einer steigenden Dynamik und Komplexität in der Unternehmenswelt. Um
11
2. Grundlagen
nachhaltig in diesem Umfeld bestehen zu können sind die Unternehmen gezwungen
verstärkt die Faktoren wie Kundenorientierung, Flexibilität, Schnelligkeit, Beweglichkeit
und Innovation auszubauen und zu etablieren [
Sch04
, S.1], [
SAJK02
, 47]. Jedoch stehen
viele Unternehmen vor historisch gewachsenen und undokumentierten IT-Systemen und
Abläufen. Als Folge sind viele Unternehmen ineffizient aufgestellt und sind gezwungen
ihre Abläufe bzw. Geschäftsprozesse zu reorganisieren [
Gad04
, S.60]. Um die Reorga-
nisation zu verwirklichen sind Prozessmodelle notwendig, anhand der die Beteiligten die
Schwachstellen erschließen sowie Sollmodelle definieren können. Dabei sind stets die
Unternehmensziele mitzuberücksichtigen [BKR00, S.55].
Geschäftsprozesse bilden die Basis für viele Geschäftssysteme wie Supply Chain Mana-
gement, Customer Relationship Management, Enterprise Resource Planning, Product
Lifecyle Management oder Business Intelligence Systeme. Daher sind effektive und effizi-
ente Geschäftsprozesse und ein funktionierendes Geschäftsprozessmanagementsystem
unabdingbar.
Dieses Kapitel soll den Leser in die Thematik der Geschäftsprozesse, des Geschäftspro-
zessmanagements und ihrer Modellierung einführen.
2.1. Geschäftsprozesse
Geschäftsprozesse
1
werden in der Literatur grundsätzlich durch ähnliche Elemente defi-
niert. Jedoch unterscheiden Sie sich im Detail bei den Anforderungen und Eigenschaften.
Viele Autoren sind sich einig, das Geschäftsprozesse eine Abfolge von Aufgaben oder
Aktivitäten mit einem Input und Output sind [
Sch04
, S.41]. Nichtsdestotrotz, fehlt es an ei-
ner universellen und einheitlichen Definition des Prozessbegriffs. Die Tabelle 2.1 enthält
einen kurzen Überblick über die in der Literatur vorzufindenden Prozessdefinitionen.
Alle Autoren sehen das Unternehmen als ein hochkomplexes System an, die viele
Elemente wie Mitarbeiter, Maschinen, Funktionen und Organisationseinheiten enthält.
1auch Business Process genannt
12
2.1. Geschäftsprozesse
Außerdem besteht zwischen diesen Elementen eine Vielzahl an Beziehungen. Roberts
betont bei seiner Definition die Kunden des Prozessoutputs und stellt die internen als
auch die externen Kunden eines Prozesses gleich. Dabei zeigt er auch das interne
Kunden innerhalb desselben Unternehmens eine Rolle spielen.
Kruse
und
Rosemann
bringen die objektorientierte Sichtweise ein. Dabei werden Objekte durch Prozesse
transformiert und weitergereicht. Des weiteren betont
Kruse
die funktionsübergreifen-
de Eigenschaften der Prozesse, die über die Organisationseinheiten hinaus existieren
und stellt eine direkte Verbindung zu den Unternehmenszielen her.
Gadatsch
stellt die
Informations- und Kommunikationstechnologie in den Vordergrund und sieht in den
Prozessen die Eigenschaft der Leistungserstellung.
Schantin
versucht eine weitreichen-
de und viele Eigenschaften in sich vereinende Definition. In seiner Definition ist die
Wiederholbarkeit und der Prozess-Eigner hinzugekommen. An dieser Stelle könnte die
Diskussion über die Geschäftsprozessdefinition noch fortgeführt werden. Die Anzahl der
Autoren die Geschäftsprozessdefinitionen erstellt haben ist immens2.
Alle Definitionen haben auch Schnittpunkte in der Sie sich nicht unterscheiden. Folgende
Eigenschaften sind für ein Geschäftsprozess somit unerlässlich:
•
Menge von Aktivitäten, die eine zeitlich-logische und zielgerichtete Struktur aufwei-
sen
•beinhalten funktions- und organisationsübergreifende Schnittstellen
•
Aktivitäten transformieren und benötigen Ressourcen (Mitarbeiter, Maschinen) bzw.
Objekte (Informationen, Dokumente)
•unterstützen die Unternehmensziele (Business-It-Alignment)
Um die Leistungen für ihre Kunden herstellen zu können, bestehen Unternehmen aus
mehreren und unterschiedlichen Geschäftsprozessen. Deshalb findet in der Literatur als
auch in der Praxis eine Gruppierung der Geschäftsprozesse statt. Dabei wird die Value-
Chain Theorie Porter’s [
Por99
] herangezogen. Er unterscheidet zwischen Kernprozessen
2
Um einige weitere Autoren zu nennen Österle [
Hub95
], Rosenkranz [
Ros06b
], Scheer [
Sch93
], Hammer
und Champy [HC94], Davenport [Dav13]
13
2. Grundlagen
und unterstützenden Prozessen. In der Literatur haben sich die Begrifflichkeiten etabliert
und beinhalten folgende Eigenschaften:
Kernprozesse
beinhalten einen hohen Wertschöpfungsanteil. Sie sind wettbewerbskri-
tisch und bilden den Leistungserstellungsprozess im Unternehmen [
Gad04
, S.32].
Diese Art von Prozessen finden sich häufig in der Produktentwicklung, Beschaffung
und Serviceleistungen [
Sei06
, S.3]. Kernprozesse werden auch Leistungsprozesse
genannt und werden in dieser Arbeit Synonym verwendet.
Unterstützungs- bzw Supportprozesse
sind notwendig um die Ausführung der Kern-
prozesse zu gewährleisten. Sie sind nicht wertschöpfend [
Sei06
, S.3]. Dabei sollte
die Nennung als Supportprozess nicht abwertend sein, sie sind genauso essenziell
wie die Kernprozesse in einem Unternehmen, können jedoch viel einfacher an
Drittanbieter outgesourct werden.
Kernprozesse beinhalten aufgrund ihrer Notwendigkeit viele Aktivitäten, die auf unter-
schiedliche Ressourcen zugreifen, welches zu einer steigenden Komplexität führen
kann. Um die Komplexität zu reduzieren wird die Segmentierung und die Kaskadierung
eingesetzt [Sch04, S.119], welche im Abschnitt 2.4 erläutert werden.
Abbildung 2.1.: Geschäftsprozess Management nach [Gad04, S.1]
14
2.1. Geschäftsprozesse
Tabelle 2.1.: Überblick Definitionen
Autor Beschreibung
Roberts
„A (business) process consists of an activity, or a set of interrelated
activities, intended to transform one or more inputs - at least some of
which represent customer requirements - into one or more outputs that
represent solutions from the
internal or external customer’s
point of
view.[Rob94, S.14]“
Rosemann
„Ein Prozeß stellt die inhaltlich abgeschlossene, zeitliche und sachlogi-
sche Abfolge der Funktionen dar, die zur Bearbeitung eines
betriebs-
wirtschaftlich relevanten Objektes ausgeführt werden.[Ros96, S.9]“
Kruse
„Ein Geschäftsprozeß ist ein ziel gerichtetes Zusammenwirken betriebli-
cher Aufgabenträger mit direktem Bezug zu
strategischen Unterneh-
menszielen
. Er wird nach
objektorientierten
Kriterien gebildet. Ein
Geschäftsprozeß besteht aus einer Folge zeitlich, räumlich und logisch
miteinander in Beziehung stehender Vorgänge, Aufgaben und Funktio-
nen, den ausführenden Organisationseinheiten sowie den notwendigen
Ausführungs- und Steuerungsinformationen. Ein Geschäftsprozeß ist
funktions- bzw. organisationsübergreifend
ausgelegt und wird von
einem Ereignis angestoßen bzw. beendet.[Kru96, S.24]“
Gadatsch
„Ein Geschäftsprozess ist eine zielgerichtete, zeitlich-logische Abfol-
ge von Aufgaben, die arbeitsteilig von
mehreren Organisationen
oder
Organisationseinheiten unter Nutzung von Informations- und Kommuni-
kationstechnologien ausgeführt werden können. Er dient der Erstellung
von Leistungen entsprechend den vorgegebenen, aus der Unterneh-
mensstrategie abgeleiteten Prozesszielen.[Gad01, S.30]“
Schantin
„Ein Prozess ist eine sachlogische Abfolge von
betrieblichen Tätigkei-
ten
bzw. Aktivitäten mit dem Ziel eines klar festgelegten Outputs zur
Erzeugung von
Kundennutzen
. Er besitzt einen bestimmten Leistungs-
umfang, ist durch einen definierten, messbaren Input und Output be-
stimmt, ist
wiederholbar
, fügt Kundenwert an
Prozessobjekten
hinzu,
kann
fraktionsübergreifend
sein, hat einen durchgängig verantwortli-
chen
Prozess-Eigner
und fügt über alle notwendigen Ressourcen und
Informationen.[Sch04, S.43]“
Weske
„A business process consists of a set of activities that are performed in
coordination in an organizational and technical environment
. The-
se activities jointly realize a
business goal
. Each business process
is enacted by a single organization, but it may interact with business
processes performed by other organizations.[Wes07, S.5]“
Außerdem hat sich der Begriff des Prozessmanagements
3
innerhalb von Unternehmen
etabliert. Sie umfasst vier Ebenen und gewährleistet eine ganzheitliche Verwaltung der
3im englischen Business Process Management
15
2. Grundlagen
Geschäftsprozesse innerhalb des Unternehmens. Dieser Zusammenhang wird in Abbil-
dung 2.1 verdeutlicht. Die strategische Ebene legt den Grundgerüst eines Unternehmens
und seine Ziele fest. Anhand der Ziele werden die Prozesse innerhalb des Unterneh-
mens abgeleitet und modelliert, welches die fachliche Ebene bildet. Die operative Ebene
ist für die tatsächliche Durchführung der Prozesse, Gestaltung der Anwendungssysteme
und der Organisation zuständig. [Gad04, S.1]
2.2. Prozessmodellierung
Nachdem die Geschäftsprozesse definiert wurden, wird in diesem Abschnitt die Ge-
schäftsprozessmodellierung erläutert. Ursprünglich stammt die Modellierung aus dem
Bereich der Betriebswirtschaftslehre, die die Arbeitsabläufe innerhalb eines Unterneh-
mens dokumentieren wollte [Rum99, S.12].
Modelle dienen dazu die Komplexität zu reduzieren, um dem Betrachter die Informa-
tion einfach zugänglich darzustellen. Ein Modell soll die Gestaltung und Analyse rea-
ler Systeme vereinfachen sowie das Verhalten eines Objektsystems, aus dem realen
Weltausschnitt, originalgetreu, widerspiegeln [
Gad04
, S.59]. Jedoch können Modelle nur
eine Annäherung an die in der Realität vorhandene Systeme bieten [
RA00
, S.3]. Das
Abbilden eines relevanten Realitätsausschnittes wird als „modellieren“ bezeichnet. Das
Modellieren versucht durch die Abstraktion der Realität relevante Aspekte zu betrachten
und hervorzuheben [
Sch04
, S.71]. Ein Modell muss stets einen Zweck haben. Dieser
Zweck definiert die späte Nutzung und den Einsatz der entstandenen Modelle [
DLMR13
,
S.66].
Durch die Komplexität, die Unternehmen aufweisen, ist es nicht möglich alle relevanten
Aspekte in einem Modell darzustellen. Folgende Aspekte eines Unternehmens müssen
bei der Modellierung betrachtet und analysiert werden, welche zwangsläufig zu mehreren
Modellen führt [RA00, S.23]:
•Prozesse: administrative und operative Prozesse
16
2.2. Prozessmodellierung
•Ressourcen: Mitarbeiter, Maschinen, Informationsapplikationen, Hardware, usw.
•Informationen und Daten: Arbeitsabläufe und Produktionsdaten von Gütern
•Organisation: Ziele, Einheiten und Anforderungen
Abbildung 2.2.: Geschäftsprozessmodellierung und Ihre Aspekte [Wes07, S.77]
Um die Vielzahl der zu betrachtenden Aspekte zu berücksichtigen und die Anzahl
der Modelle einfacher zu verwalten, versuchen viele methodische Beschreibungen
den Umweltausschnitt zu gliedern und zu klassifizieren (siehe Abbildung 2.2), um
die Realität einfacher darzustellen. Die Klassifikation und Gliederung führen zu einer
Prozessarchitektur, die sich an betriebliche Funktionen, nach Wirtschaftszweigen oder
nach Branchen ausrichten kann. Dadurch erhält man eine erhöhte Transparenz sowie
eine schnellere Prozessmodellidentifikation [Hei02, S.110ff].
Ein Geschäftsprozessmodell stellt alle Aktivitäten innerhalb eines Unternehmens, um
die Geschäftsziele zu erreichen, dar. Es beinhaltet alle relevanten Aktivitäten, ihre Aus-
führungslogik, benötigte Ressourcen und Informationen [
HBR10
, S.520]. Geschäftspro-
zesse sind somit auch immaterielle Abbilder realer Strukturen. Um die Modellierung
komplexer Geschäftsprozesse zu strukturieren werden Phasen- bzw. Life-Cycle-Modelle
wie im Software-Engineering vorgeschlagen [
Gad04
, S.52]. Abbildung 2.3 verdeutlicht
die Phasen und ihren kontinuierlichen Zyklus.
17
2. Grundlagen
Abbildung 2.3.: Phasen-Lifecycle-Modell [DLMR13, S.21]
Die Phasen bestehen aus folgenden Elementen [DLMR13, S.21ff]:
Prozessidentifikation:
Alle relevanten Prozesse in einem Unternehmen werden identi-
fiziert und klassifiziert. Es ist wichtig die internen und externen Kunden im Umfeld
zu kennen.
Prozessmodellierung:
Identifizierte Prozesse werden in Ihrem Ist-Zustand modelliert.
Dabei entscheidet oftmals die Expertise des Modellierers, die gewählte Notation
und die Vorgehensweise über die Modellqualität. Zwei Begriffe sind für die Mo-
dellqualität wichtig zu erwähnen, die Syntax und die Semantik. Ein syntaktisch
richtiges Modell liegt vor wenn die Modellierungskonventionen der benutzen Nota-
tion bzw. Sprache alle eingehalten wurden. Ein semantisch richtiges Modell liegt
vor, wenn das Modell die Strukturen und das Verhalten in der realen Welt richtig
wiedergibt.[GF08, S.37]
Prozessanalyse:
Die Prozessanalyse soll Schwachstellen und Verbesserungspotentia-
le entdecken und die Performance im Unternehmen steigern.
18
2.2. Prozessmodellierung
Prozessverbesserung:
Aus dem Ergebnis der Prozessanalyse werden mögliche Ver-
besserungen abgeleitet und implementiert. Dadurch entsteht ein neues Prozess-
modell. In diesem Bereich ist es wichtig über die Adabtierbarkeit eines Prozessmo-
dells Bescheid zu wissen. Je einfacher ein Prozess verändert werden kann desto
einfacher ist sie adaptierbar bzw. veränderbar [All98, S.96].
Prozessteuerung/-überwachung:
Die Prozesse und die Verbesserungen werden Über-
wacht und relevante Prozessdaten werden gespeichert.
Somit ist die Prozessmodellierung eine elementare und essenzielle Phase, auf die die
anderen Phasen aufbauen. Deswegen ist es unabdingbar frühzeitig mit potenziellen
Perspektivenvertretern wie Fachexperten, Top-Management, Organisationsmanagement
und Informationsmanagement in Gespräch zu kommen [
BKR00
, S.54]. Perspektiven
sind Blickwinkeln aus der das Unternehmen betrachtet wird. Gerne wird hier über Sichten
und ein Sichtenkonzept gesprochen [
Gad04
, S.54]. Nach Scheer unterteilen sich die
Sichten in fünf Gruppen, die wie folgt definiert sind: Organisationssicht, Funktionssicht,
Datensicht, Steuerungssicht und Leistungssicht
4
[
Sch98a
]. Österle versucht unter dem
Begriff der Gestaltungsdimensionen eine Unterteilung in Organisation, Funktionen und
Daten [
Hub95
]. Die Unterteilungen vereinfachen die Modelle, in dem Sie nur bestimmte
Aspekte aufzeigen. Zusammenfassend kann man folgende Punkte festhalten [
CA09
,
S.54]:
Funktionale Sicht beschreibt die einzelnen Funktionen innerhalb eines Prozesses
Datensicht
bzw. die strukturelle Sicht beschreibt die eingehenden (Input) und ausge-
henden (Output) Daten, die durch Funktionen benötigt und transformiert werden.
Ein Input oder ein Output ist ein Informationsobjekt, welches in Form von einem
Bestellformular, Angebot, Beratung oder Gutschrift auftreten kann [Sch04, S.45].
Steuerungssicht/Verhaltenssicht
beschreibt die Reihenfolge in der die einzelnen
Funktionen ausgeführt werden
4welches seinen ARIS-Konzept bilden, näheres in Kapitel 4
19
2. Grundlagen
Organisationssicht
beschreibt die Personen und Rollen, die innerhalb eines Unterneh-
mens bzw. Prozesses vorkommen
Leistungssicht
beschreibt die Werkzeuge und Systeme, die die Laufzeit der Prozesse
gewährleisten.
Ein weiterer wichtiger Aspekt beim Modellieren ist die Frage des Detaillierungsgrades.
Grundsätzlich ist ein Prozess so weit zu verfeinern, dass alle Betrachter den Ablauf
und den Inhalt deutlich verstehen. Feingranulare Geschäftsprozesse sind für die opera-
tive Ebene essenziell, da Sie jeden einzelnen elementaren Schritt aufzeigen. Für die
fachliche Ebene eignen sich grobgranulare Geschäftsprozessmodelle, da hier das strate-
gische Geschäft dargestellt wird [
VR10
, S.150]. Wie die Abbildung 2.4 verdeutlicht folgt
die Detaillierung der Modelle einem vordefiniertem Zyklus. Das Geschäftsprozessmodell
wird dabei verfeinert und erweitert, welches als Workflowmodellierung bezeichnet wird.
Ein Workflow beschreibt sehr detailliert die einzelnen Arbeitsschritte an einem Arbeits-
platz und ist zum Teil oder im ganzen automatisiert [
Gad04
, S.39]. Der Zyklus verdeutlicht
die Ähnlichkeit zwischen der Geschäftsprozessmodellierung und Workflowmodellierung.
Abbildung 2.4.: Modellierungszyklus [Gad04, S.52]
20
2.3. Beschreibungssprachen zur Modellierung
2.3. Beschreibungssprachen zur Modellierung
Nachdem im vorherigen Kapiteln nun die Definition eines Geschäftsprozesses und
die Prozessmodellierung beschrieben wurde, wird in diesem Kapitel die vorhandenen
Beschreibungssprachen zur Modellierung näher erläutert. Die hohe Anzahl an Beschrei-
bungssprachen erfordert eine Beschränkung auf die in der Praxis häufig vorkommenden
Sprachen. Die vorhandenen Modellierungssprachen können in drei Gruppen unterteilt
werden [GF08, S.39]:
1.
einfache Metaphern, die nur die Aktivitäten und ihre logische Reihenfolge abbilden
2.
formale Sprachen, wie Petrinetze [
Pet62
] oder ereignisgesteuerte Prozessketten
(EPK) [Sch98a]
3.
programmnahe Sprachen, wie UML-Activity Diagramme [
Gro11a
] oder BPMN
[Gro13]
Die oben aufgeführten Gruppen sind grafische Sprachen, welche sich in objektorientierte,
datenflussorientierte und kontrollflussorientierte Ansätze weiter unterscheiden [
Gad04
,
S.56]. Eine weitere Gruppe sind die skriptbasierten Sprachen, auf die hier nicht einge-
gangen wird, da sie Programmiersprachen ähneln. Grafische Beschreibungssprachen
vereinfachen die Anschaulichkeit und das Verstehen eines Geschäftsprozessmodells
ohne detaillierte Sprachkenntnisse. Außerdem integrieren grafische Beschreibungsspra-
chen verschiedene Aspekte eines Prozesses, wie z.B. Aktivitäten, Ereignisse, Rollen,
Informationsobjekte und viele weitere Sachverhalte in einem Modell.
Dabei müssen die Beschreibungssprachen die verschiedenen Sichten unterstützen,
damit ein ganzheitliches Modell entwickelt werden kann. Viele Beschreibungssprachen
kommen mit einem Repository (Datenbank), die dem Modellierer beim Erstellen eines
Modell Unterstützung leisten sollen.
Bevor die zwei am häufigsten in der Praxis vorzufindenden Sprachen erläutert werden,
müssen zunächst die Begrifflichkeiten Meta-Modell, Modell und Modellinstanz geklärt
werden.
21
2. Grundlagen
2.3.1. Meta-Modell der Beschreibungssprachen
Ein Meta-Modell stellt die Notationsregeln bereit, mit der die einzelnen Modelle bzw.
Geschäftsprozesse abgebildet werden können [Gad04, S.60]. Somit kann das erstellte
Modell auf Vollständigkeit überprüft werden. Wie die Abbildung 2.5 verdeutlicht repräsen-
tieren Modelle Instanzen von Meta-Modellen. Ein Meta-Modell stellt die zur Verfügung
stehenden Komponenten miteinander in Beziehung und gibt den Aufbau des Modell-
systems wieder [
Wes07
, S.76]. Vergleichbar sind Meta-Modelle mit den Grammatiken
von Sprachen. Eine Grammatik beschreibt formal welche Wörter und Regeln innerhalb
einer Sprache vorhanden sind. Es ist eine Richtlinie für den Aufbau von Sätzen und
die daraus resultierende Bedeutung [
Hei02
, S.43]. Die Grammatik gibt somit die Syntax
und die Semantik der Sprache wieder. Eine genauere Definition einer Grammatik gibt
Heimig mit „Eine Grammatik beschreibt eine (potentiell unendliche) Menge von Mustern
(Patterns) in Form eines endlichen Lexikons und einer endlichen Menge von Regeln,
die die erlaubten Kombinationen aus Elementen des Lexikons angeben. Grammatiken
beschreiben strukturelle Eigenschaften der beschriebenen Sprache (des betrachteten
Systems) [Hei02, S.44].“
Abbildung 2.5.: Abstraktionslevel [Wes07, S.88]
22
2.3. Beschreibungssprachen zur Modellierung
Für die Geschäftsprozessmodellierung sind Meta-Modelle somit essenziell, welche durch
das vorgegebene Rahmenwerk, das Verstehen und Deuten der Modelle sowohl für Men-
schen als auch Maschinen vereinfacht. Ein Meta-Modell vereinfacht das Abbilden der
Realität durch einzelne Modelle, die versuchen, die Objekte der Realwelt abstrahierend
darzustellen. Die Modelle, die erstellt werden, basieren somit auf den Elementen der
Meta-Modelle. Die konkrete und spezifische Zuordnung eines Modells zu einer Rea-
len Gegebenheit wird durch die Modellinstanzen abgebildet. Bei Geschäftsprozessen
beschreibt eine Instanz einen konkreten Durchlauf.[FR12, S.23ff]
Abbildung 2.6.: Prozessmetamodell [ATW+15, S.9]
Das Meta-Modell verfügt viele Elemente, um die verschiedenen Sichten innerhalb ei-
nes Prozessmodells abbilden zu können, wie die Abbildung 2.6 verdeutlicht. Dem-
nach sind folgende Elemente notwendig, um ein Modell abbilden zu können [
Wes07
,
S.89ff][ATW+15, S.9ff]:
23
2. Grundlagen
Aktivitäten
können atomar oder komplex sein. Atomare Aktivitäten beinhalten nur eine
einzige Tätigkeit, wohingegen komplexere Aktivitäten mehrere Tätigkeiten bein-
halten und meistens Teilprozesse innerhalb eines Prozesses sind [
RW12
, S.60].
Eine Aktivität die nur ein einziges Mal ausgeführt wird, wird Transaktion genannt
[
Ros06b
, S.20]. Aktivitäten sind betriebliche Funktionen mit einem bestimmten
Ziel.
Ereignisse
haben keine Dauer, keine Kosten und benötigen auch keine Ressourcen.
Sie geben Informationen über den aktuellen Zustand eines Prozesses wieder
und werden für Informationszwecke genutzt [
Ros06b
, S.23]. Außerdem sind Sie
Auslöser oder Ergebnis einer Aktivität.
Verbindungselemente
sind Elemente von Graphen. Verbindungselemente verbinden
anhand von Knoten (Kreise, Rechtecke, etc.) und Kanten (Pfeile, Linien, etc.) die
Ereignisse und die Aktivitäten zu logischen Strukturen [
Ros06b
, S.42]. Sie zeigen
dadurch den Kontrollfluss auf und ermöglichen die Aufspaltung oder Zusammen-
führung des Flusses. [RW12, S.61]
Rollen
stellen die Strukturen der Organisationseinheit dar. Rollen sind für die Ausfüh-
rung von Aktivitäten zuständig und stellen die Ressourcen bereit.
Datenobjekte
sind prozessrelevante Informationsobjekte. Sie werden mit Aktivitäten
verknüpft und zeigen welche Daten die Aktivität transformiert oder benötigt um
ausgeführt werden zu können.
Zusammenfassend stellt das Meta-Modell die Basis für syntaktisch richtige Modelle.
Die Semantik entsteht erst durch das betrachten des gesamten Modells und dem
gleichzeitigen Abgleich mit den realen Strukturen.
2.3.2. Ereignisgesteuerte Prozessketten
Dieser Abschnitt behandelt nun die ereignisgesteuerten Prozessketten (EPK). EPK
ist eine in der Praxis weit verbreitete Sprache, die am Institut für Wirtschaftsinforma-
24
2.3. Beschreibungssprachen zur Modellierung
tik an der Universität des Saarlandes entwickelt worden ist [
KNS92
]. Sie wurde im
Rahmen der ARIS-Konzeptes weiterentwickelt und dort verankert. Im wesentlichen
ist die Methode der EPK eine Weiterentwicklung der Petri-Netze [
Gad04
, S.64]. Das
ARIS-Konzept stellt einen Ordnungsrahmen und Methoden für die Beschreibung von
Informationssystemen bereit. Sie unterteilt sich in Beschreibungssichten (Funktions-,
Daten-, Steuerungs-, Organisations- und Leistungssicht) und in Beschreibungsebenen
(Fachkonzept, DV-Konzept und Implementierung) [
Sch98a
, S.1]. EPK-Modelle stellen
semantische Sachverhalte durch einfaches Verbinden von Funktionen und Ereignissen
dar [KNS92, S.10] (siehe Abbildung 2.7) .
Folgende Elemente bzw. Symbole stehen zur Prozessmodellierung [
KNS92
, S.10ff] zur
Verfügung:
Ereignisse
sind passives Elemente und stellen einen eingetretenen Zustand dar. Nach
Keller et al. [
KNS92
] lösen Ereignisse Funktionen aus und determinieren den
weiteren Ablauf. Des weiteren bilden sie betriebswirtschaftliche Zustände ab. Bei-
spiele für Ereignisse sind „Angebot erstellt“, „Anfrage abgeschickt“. Ereignisse
verursachen keine Kosten und verbrauchen keine Zeit [Hei02, S.68].
Funktionen
sind aktive Elemente und stellen betriebswirtschaftliche Vorgänge ab. Es
wird als Aufgabe verstanden, welche durch physische oder geistige Tätigkeiten
durchgeführt werden. Als aktives Element enthalten Funktionen Entscheidungs-
kompetenzen und verursachen Kosten sowie Ressourcenverbrauch.
Verknüpfungsoperatoren
ermöglichen verschiedene Arten von Verknüpfungen. Es
wird zwischen konjunktiven, disjunktiven und adjunktiven Verknüpfungen unter-
schieden. Konjunktive Verknüpfungen repräsentieren eine „und“-Verknüpfung,
welche parallel Abläufe ermöglichen. Disjunktive Verknüpfungen repräsentieren
„entweder-oder“-Verknüpfungen. Adjunktive Verknüpfungen sind „und/oder“-Verknüpfungen.
Nach einem auslösendem Ereignis dürfen keine disjunktive und adjunktive Verknüp-
fungsoperatoren benutzt werden, da die Entscheidungskompetenz von Ereignissen
fehlt.
25
2. Grundlagen
Des weiteren werden EPK-Modelle durch Informationsobjekte und Organisationseinhei-
ten ergänzt [Rum99, S.58-59].
Informationsobjekte
stellen bzw. zeigen die Daten, die durch eine Funktion transfor-
miert werden auf.
Organisationseinheiten
determinieren die Verantwortlichkeiten für die Ausführung
einer Funktion.
Für die EPK-Modellierung sind fixe Regeln vorhanden, die die Syntax stets gewährleisten
sollen. Diese Regeln sind [Hei02, S.70]:
1.
Ein EPK-Modell beginnt immer mit einem Startereignis und endet mit einem
Endereignis.
2.
Nach jedem Ereignis kommt eine Funktion und nach jeder Funktion kommt ein
Ereignis. Dazwischen können Verknüpfungsoperatoren vorkommen, welches diese
Regel zu berücksichtigen hat.
Abbildung 2.7.: Beispielhaftes EPK-Modell
26
2.3. Beschreibungssprachen zur Modellierung
2.3.3. Business Process Model and Notation 2.0
Business Process Model and Notation (BPMN) in der Version 2.0 wurde im Januar
2011 veröffentlicht. Sie ist eine weitere weit verbreitete Notation für die Modellierung
von Geschäftsprozessen. Seit 2005 entwickelt die Object Management Group (OMG)
[
Gro13
] BPMN und sorgt für die notwendige Standardisierung. BPMN unterstützt nicht
nur die graphische Repräsentation von Geschäftsprozessen sondern ermöglicht auch
eine Transformation fachlicher Prozesse in technische Prozessmodelle [
Fet08
, S.504].
Diese Transformation erfolgt zum Beispiel in die Business Process Execution Language
(BPEL). BPMN unterstützt drei Arten von Prozessen: Orchestrierung (Orchestration),
Kollaboration (Collaboration) und Choreographie (Choreography) [WM08, S.27].
Die Geschäftsprozesse werden in BPMN in Geschäftsprozessdiagrammen (Business
Process Diagram) abgebildet. Aufgrund der Vielfalt an vorhandenen Elementen wer-
den die vier Grundelemente näher erläutert. Diese sind Flussobjekte (Flow Objects),
verbindende Objekte (Connecting Objects), Teilnehmer (Pools und Swimlanes) sowie
Artefakte (Artifacts) [VR10, S.216] [WM08][FR12].
Abbildung 2.8 zeigt die Symbole und ihre graphische Repräsentation. Im folgenden
werden diese nun näher nach [Wes07, FR12, WM08] näher erläutert.
Flussobjekte
Flussobjekte sind Aktivitäten, Ereignisse und Gateways.
Aktivitäten
werden durch abgerundete Rechtecke dargestellt. Wie bei den EPK-Modellen
können Aktivitäten atomare Aufgaben (Task) beinhalten oder sind zusammenge-
setzte Aufgaben (Teilprozess). Aktivitäten sind Aufgaben die etwas verrichten und
aktiv sind. Teilprozesse werden durch ein „+“-Symbol innerhalb des Rechteckes
kenntlich gemacht. BPMN unterscheidet zwischen verschiedenen Aufgabentypen.
Ereignisse
werden als Kreise modelliert und stellen Zustände dar. In BPMN wird zwi-
schen einem Startereignis, Zwischenereignis und Endereignis unterschieden. Da-
27
2. Grundlagen
Abbildung 2.8.: Grundelemente BPMN 2.0 [FR12, S.21]
bei werden Zwischenereignisse mit einer doppelten Umrandung und Endereignisse
mit einer dickeren Umrandung kenntlich gemacht. Es gibt verschiedene Typen von
Ereignissen: Timer-Event, Ausnahme-Event (Exception), Regel-Event, Link-Event,
Catching-Event sowie Throwing-Event. Je nach dem Typ des gewählten Ereignisse
wird der Prozess unterschiedlich ausgelöst bzw. getriggert.
Gateways
ermöglichen die Aufspaltung und Zusammenführung des Prozesspfades und
werden durch Rauten dargestellt. Zusammenführende Gateways führen zwei Pro-
zesspfade zu einem zusammen. Es gibt in BPMN fünf Arten von Gateways, Und-,
Oder-, Exklusives-Oder, Eventbasierte- sowie Komplexe-Gateways. Eventbasierte-
Gateways ermöglichen anhand von eintreffenden Ereignissen einen Prozesspfad
auszuwählen.
Verbindende Objekte
Verbindende Objekte sind Sequenzflüsse, Nachrichtenflüsse und Assoziationen.
28
2.3. Beschreibungssprachen zur Modellierung
Sequenzflüsse bestimmen die Reihenfolge der einzelnen Ereignisse und Aktivitäten.
Nachrichtenflüsse
verdeutlichen die ausgetauschten Informationen zwischen den Teil-
nehmern von Prozessen.
Assoziationen verbinden Artefakte und Flussobjekte miteinander
Teilnehmer
Teilnehmer werden in Pools und Swimlanes (dt. Schwimmbahn) repräsentiert und dienen
dazu Organisationseinheiten darzustellen. Sie zeigen die jeweiligen Zuständigkeiten für
die Aktivitäten in einem Prozess. Teilnehmer können Rollen, Organisationseinheiten oder
Systeme sein. Sequenzflüsse können die Grenzen eines Pools nicht überschreiten. Um
die Interaktion zwischen verschiedenen voneinander unabhängigen Pools darzustellen
werden zwei verschiedene Pools eingesetzt und die Kommunikation durch Nachrichten-
flüsse dargestellt. Falls die Prozesse eines Teilnehmers nicht bekannt sind, so kann für
diesen Teilnehmer nur ein leeres Pool verwendet werden.
Artefakte
Artefakte stellen zusätzliche Informationen dar. Hierbei werden zwischen Datenobjekten,
Annotationen und Gruppierung unterschieden.
Datenobjekte zeigen die Input- und Output-Objekte innerhalb eines Prozesses.
Annotationen
sind Anmerkungen und kleine Notizen, um Informationen zu speichern.
Annotationen sind in Textform und der Inhalt ist frei wählbar.
Gruppierungen
ermöglichen das Aufzeigen von zusammengehörenden Aktivitäten
und Ereignissen. Sie hat keine Bedeutung und dient lediglich der grafischen
Veranschaulichung.
29
2. Grundlagen
Erlaubte und Verbotene Konstrukte
Innerhalb von BPMN gibt es verschiedene verbotene Konstrukte. Die folgende Abbildung
verdeutlicht diesen Sachverhalt, die Abbildung 2.10 illustriert die erlaubten Konstrukte.
Abbildung 2.9.: Verbotene Konstruke innerhalb BPMN 2.0 [FR12, S.97]
Abbildung 2.10.: Erlaubte Konstruke innerhalb BPMN 2.0 [FR12, S.97]
2.4. Segmentierung und Kaskadierung von
Geschäftsprozessen
In diesem Abschnitt werden die Begrifflichkeiten Kaskadierung, Segmentierung und
Prozessvarianten erläutert.
Schantin [
Sch04
] nutzt die Prozesskaskadierung und Segmentierung als ein Instrument,
um Branchen- und Unternehmensstrukturen im Grazer Ansatz abbilden zu können. Im
Prinzip handelt es sich bei den beiden Begriffen um die klassische Organisationsplanung
30
2.4. Segmentierung und Kaskadierung von Geschäftsprozessen
und Arbeitsteilung. Bei der Segmentierung werden Prozessvarianten gebildet und bei der
Kaskadierung Aufgaben aufgeteilt. Im folgenden werden beide Begriffe näher erläutert.
Prozesskaskadierung:
hat das Ziel, durch wirtschaftlich sinnvolle Arbeitsteilungen, die
komplexen Prozesse in einem Unternehmen voneinander abhängigen Teilprozes-
sen aufzuteilen. Ein Teilprozess bzw. Prozesskaskade umfasst dabei betriebliche
Funktionen und alle notwendigen Aktivitäten sowie Ressourcen. Sie ist ein wichti-
ger Teil der Leistungserstellung. Durch Prozesskaskaden entsteht eine vertikale
Hierarchie zwischen den Prozessen und Prozesskaskaden. Diese Hierarchie wird
auch Kaskadenmodell genannt. [Sch04, S.91ff]
Prozesssegmentierung:
ist ein Instrument, bei der die Basisstruktur eines Prozesses
erhalten bleibt. Jedoch entstehen durch die Prozesssegmentierung verschiedene
Varianten ein und desselben Prozesses. Geschäftsprozesse die auf hohem Ab-
straktionsniveau modelliert wurden, können homogene Eigenschaften aufweisen,
die bei Detaillierung des Geschäftsprozesse verschwinden können. Als Beispiel
können hier Prozesssegmentierung bezüglich Kundenstruktur, Geographie, Wett-
bewerb oder Vertriebskanal genannt werden. Ein Unternehmen bietet zwar im
allgemeinen denselben Prozess wie Auftragsabwicklung für seine Kunden an,
jedoch unterscheiden sich Geschäftskunden, Privatkunden und öffentliche Institu-
tionen bei der Abwicklung. [Sch04, S.120ff]
Ein wichtiger Begriff, das bei der Prozesssegmentierung auffiel, ist die Prozessvariante.
Prozessvarianten sind notwendig, um bestimmte Anforderungen erfüllen zu können, die
nur zu bestimmten Zeitpunkten auftreten. Dabei wird ein Geschäftsprozess um die nöti-
gen Aktivitäten und Ressourcen erweitert. Somit entstehen viele separate Geschäftspro-
zessmodelle, die sich im Prinzip ähneln jedoch gering unterscheiden. Dabei können
diese Prozessvarianten in einem Geschäftsprozessmodell (Single-Modell-Approach)
oder in mehreren Geschäftsprozessmodellen (Multi-Model-Approach) abgebildet werden.
[HBR10, S.522-523] [VR10, S.239]
31
2. Grundlagen
Abbildung 2.11.: Beispielsegmentierung [Sch04, S.123]
Es gibt verschiedene Ansätze in der Literatur und Forschung, um die Prozessvarianten
abbilden, modellieren und verwalten zu können. Dabei werden vorhandene Modelle auf
die jeweiligen Anforderungen der Prozessvariante konfiguriert. Die wichtigsten werden
kurz erläutert.
Verhaltensbasierter Ansatz
auch behaviour-based approach genannt: Hierbei enthält
ein Referenzprozess
5
alle möglichen Varianten des Geschäftsprozesses und stellt
dem Modellierer dabei durch veränderbare Knoten und Kanten Hilfestellungen, um
die Prozessvariante zu entwickeln und die ursprüngliche Ablauflogik zu verändern.
[RW12, S.92]
Struktureller Ansatz
auch structural approach genannt: Bei diesem Ansatz kann der
Modellierer die Struktur des Geschäftsprozessmodels durch hinzufügen, entfernen
und verändern von Aktivitäten bearbeiten. [RW12, S.92]
Fragebogen Ansatz:
wird anhand von Fragen in natürlicher Sprache, die jeweilige
Prozessvariante erstellt. Der Modellierer kann somit anhand von Fragen zu der
benötigten Prozessvariante geführt werden. Dieser Ansatz verhindert das Erstellen
von semantisch falschen Prozessvarianten. [LRADTH09, LR09]
Funktionsorientierter Ansatz
ähnelt sehr dem Fragenbogen-Ansatz. Der funktions-
orientierter Ansatz wird durch Funktionsbäume (feature diagrams) dargestellt, in
der die einzelnen Funktionen ausgewählt werden können. Anhand von Regeln
wird gewährleistet, dass keine semantisch falschen Prozessvarianten entstehen.
[SHT06]
5näheres in Kapitel 3
32
2.5. Grundsätze ordnungsmäßiger Modellierung
Provop Ansatz
bietet ein Rahmenwerk für die Erstellung von Referenzprozessmodellen
(base process model), um daraus anhand von Anpassungen eine Prozessvariante
ableiten zu können. [HBR10]
Vivace Ansatz
bietet ein Rahmenwerk, das durch eine umfassende Recherche erstellt
wurde, mit der ein Modellierer die vorhandenen Werkzeuge für die Modellierung von
Prozessvarianten bewerten und für seine Anforderungen notwendige Werkzeuge
auswählen kann. [ATW+15]
2.5. Grundsätze ordnungsmäßiger Modellierung
Grundsätze ordnungsmäßiger Modellierung (GOM) dienen zur Sicherung der Modell-
qualität und bieten einen Leitfaden und Rahmenwerk für das Modellieren von Ge-
schäftsprozessen. Folgende Grundsätze sind in der GOM nach Rosemann [
Ros96
,
S.94ff] vertreten:
Grundsatz der Richtigkeit
ist sehr essenziell, da durch Sie die Richtigkeit der abgebil-
deten Realwelt gewährleistet wird. In diesem Zusammenhang fallen die Begrifflich-
keiten der Syntax und Semantik. Ein syntaktisch richtiges Modell liegt vor, wenn
die Regeln der Notationssprache vollständig eingehalten werden [
Ros96
, S.94].
Dies setzt ein Meta-Modell der Modellierungssprache voraus. Ein semantisch
richtiges Modell liegt vor, wenn das Modell die Strukturen und das Verhalten in der
realen Welt korrekt wiedergibt [
GF08
, S.37]. Die Struktur und Verhaltensweise des
Modells geben die in der Realwelt vorkommende Systeme richtig wieder.
Grundsatz der Relevanz
deutet auf die zu modellierenden Elemente innerhalb eines
Modells hin. Die Sachverhalte in der Realwelt, die modelliert werden, müssen für
die erstellte Modelle von Relevanz sein, d.h. ihr Fehlen würde eine essenzielle
Information nicht darstellen [
Bec
, S.4]. Dabei ist es wichtig den Zweck und späte-
ren Einsatz des Geschäftsprozessmodells zu kennen. Die Ziele müssen für alle
Beteiligten klar definiert sein [
Ros96
, S.96]. Die Vorgehensweise der Relevanz
33
2. Grundlagen
beruht auf dem Paradigma so viele Elemente wie nötig und so wenig wie möglich
in das Modell aufzunehmen. Dieser Grundsatz ist sehr subjektiv und muss vom
Modellersteller und Modellbetrachter entschieden werden.
Grundsatz der Wirtschaftlichkeit
enthält eine betriebswirtschaftliche Sichtweise auf
die Modellierung. Dabei ist die Wirtschaftlichkeit ein Verhältnis zwischen dem
Aufwand und dem Nutzen des erstellten Modells [
Bec
, S.5]. Die Betrachtung der
Wirtschaftlichkeit entscheidet über die Granularität des Modells. Die Wirtschaftlich-
keit kann durch Einsatz von Referenzmodellen bzw. den Ansätzen für den Umgang
mit Prozessvarianten erhöht werden.
Grundsatz der Klarheit
deutet auf die Verständlichkeit und die Leserlichkeit eines
Modells hin. Dieses ist ein sehr subjektiver Grundsatz. Die Klarheit kann durch
Strukturen, Anordnungen und grafischen Merkmalen erhöht werden.
Grundsatz der Vergleichbarkeit
setzt den Fokus auf die Modellierungssprachen und
ihre Überführbarkeit in eine andere Sprache. Ein Modell das durch unterschiedliche
Methoden modelliert wurde und denselben Sachverhalt abbildet, sollte im Idealfall
auch denselben Sachverhalt darstellen. Vergleichbarkeit erleichtert die Integration
von Modellen. Dies setzt jedoch wieder Meta-Modelle der genutzten Sprachen
voraus.
Grundsatz des systematischen Aufbaus
verfolgt die Sichten übergreifende Konsis-
tenz, d.h. Modelle, die unterschiedliche Sichten aus demselben Realweltausschnitt
abbilden, müssen untereinander Konsistent sein. Es dürfen keine Informations-
brüche entstehen. Daten, Funktion oder Organisationen die referenziert werden,
sollten auch vorhanden und modelliert sein.
Neben den GOM gibt es auch die sieben Richtlinien für die Prozessmodellierung (Seven
Process Modelling Guidlines) [
MRA10
]. Diese sieben Richtlinien entstanden durch
empirische Erfahrungen und Untersuchungen, in der viele Modelle syntaktische und
semantische Fehler enthielten. Die sieben Richtlinien sind im folgenden Artikel [
MRA10
]
34
2.6. Ziele der Prozessmodellierung
erläutert worden. Beide vorgestellten Ansätze ähneln sich Inhaltlich. Im folgenden sind
die sieben Grundsätze aufgelistet:
1. Use as few elements in the model as possible
2. Minimize the routing paths per element
3. Use one start and one end event
4. Model as structured as possible
5. Avoid OR routing Elements
6. Use verb-object acitivity labels
7. Decompose a model with more than 50 elements
2.6. Ziele der Prozessmodellierung
Durch die Prozessmodellierung werden innerhalb von Unternehmen die Strukturen und
Aufgaben sichtbar. Durch diese Informationen können Unternehmen einen besseren
Einblick in ihre Aufbau- und Ablauforganisation gewinnen. Daher sind mit der Prozessmo-
dellierung viele Vorteile und Ziele verbunden. Im folgenden werden die Ziele beschrieben
[Ros06b, S.16-17], [Hei02, S.7ff], [Rum99, S.20-21] :
•
Dokumentation und Speicherung von Prozesswissen: Die Prozesse in einem
Unternehmen sollten gut dokumentiert und zum Wiederverwenden gespeichert
werden. Hierbei sollte eine Prozess-Datenbank verwendet werden.
•
Verbesserung der Kundenzufriedenheit: Durch das Modellieren der Abläufe kann
das Unternehmen die Schwächen und die Stärken erkennen und sich besser
an den Kundenbedürfnissen orientieren. Anhand der Prozessmodelle kann die
IST-Situation einfacher untersucht und eine SOLL-Situation definiert werden.
•
Effizienzsteigerung: Die Durchlaufzeit kann durch die Optimierung der Prozessmo-
delle verringert werden.
35
2. Grundlagen
•
Möglichkeit der Simulation: bevor ein Prozessmodell in die Praxis umgesetzt wird,
ermöglicht es dem Unternehmen die Simulation und somit die Vorabanalyse.
Somit können verschiedene Lösungen simuliert und die beste Lösung ausgesucht
werden.
•
Unterstützung bei der Auswahl und Planung der notwendigen Anwendungsarchitek-
tur und IT-Landschaft. Durch die gesteigerte Transparenz kann das Unternehmen
bestimmte Abläufe automatisieren oder auf Standardsoftware umsteigen.
•
Unterstürzung bei der Zertifizierung. Viele Zertifizierungen wie ISO 9000 setzen
die prozessorientierte Unternehmensorganisation voraus.
•
Vereinfachung von Zusammenarbeit zwischen Kunden und Lieferanten: Durch
die genau definierte Abfolge von Aktivitäten können Unternehmen innerhalb von
Schnittstellen einfacher miteinander kooperieren und Informationen austauschen.
36
3
Referenzprozessmodellierung
Referenz-Informationsmodelle (RIM) sind seit den 90er Jahren in der Wirtschaftsinfor-
matik ein weit verbreitetes Konzept für die systematische Strukturierung von betriebswirt-
schaftlichen Vorgängen in Informationssystemen. Vorreiter in diesem Bereich ist Scheer
[
Sch93
], der durch das ARIS-Konzept ein vordefiniertes Modell für industrielle Unterneh-
men erschaffen hat (siehe [
Sch94
]). Die Begrifflichkeit der Referenz-Informationsmodelle,
auch Referenzmodelle (RM) genannt, beschränkt sich heute nicht nur auf betriebswirt-
schaftliche Sachverhalte. Die Einsatzbereiche von RM sind umfangreich und reichen
von Auswahl einzelner Prozesse bis hin zu ganzen Unternehmensmodellen und Zerti-
fizierungen nach DIN ISO [
Sch00
, S.61]. RM beinhalten dabei generische Lösungen
für ausgewählte Domänen und versuchen die Modellierung von Sachverhalten des
Realweltausschnittes zu vereinfachen [ZHMBA14, S.976].
37
3. Referenzprozessmodellierung
RM dienen dabei das Wissen und die Erfahrungen verschiedener Unternehmen durch
allgemeingültige Modelle festzuhalten, um sie für weitere Anwendungen wiederverwen-
den zu können, da die Strukturen einzelner Domänen sich sehr ähneln. Anhand der
RM ist es möglich Best-Practice oder Common-Practice Lösungen weiterzugeben. RM
bestehen aus aggregierten und allgemeinem Wissen über die Aufbau der Organisation,
der Geschäftsprozesse und der Informationstechnologie innerhalb eines Unternehmens,
um damit spezifischere Modelle erarbeiten zu können [
Hei02
, S.109]. Daher ist es vor
dem Einsatz eines RM essenziell bestimmte Punkte zu beachten [GF08, S.36]:
•Analyse vorhandener RM auf vorhandene Prozesse und ihrer Einsatzfelder
•Analyse der Anpassbarkeit vorhandener Konstrukte zur Individualisierung
•Überprüfung auf Vollständigkeit und fehlende Elemente des RM
Die Referenzprozessmodellierung beschäftigt sich mit der Modellierung von RM und er-
weitert die herkömmliche Geschäftsprozessmodellierung. In diesem Kapitel wird zuerst
die Definition von RM anhand der vorhandenen Literatur erläutert. Danach werden die
einzelnen Themenbereiche wie Klassifikation, Konstruktion, Grundsätze ordnungsmäßi-
ger Referenzmodellierung und Ziele beschrieben. Zuletzt werden vorhandene RM im
Überblick dargestellt.
3.1. Definition Referenzmodell
RM bieten sehr viele Vorteile für den Anwender und dienen zur Dokumentation von
Wissen. In diesem Abschnitt werden zuerst die in der Literatur vorhandenen Definitionen
für den Begriff der RIM beschrieben
1
. Aufgrund des recht neuen Forschungsgebietes
der RM hat sich in der Forschung kein einheitliches Verständnis über RM etabliert.
Die Begrifflichkeit setzt sich aus den Bereichen Referenz und Informationsmodelle
zusammen.
1Über eine detaillierte Analyse des Referenzprozessbegriff siehe [Fet06, S.20ff]
38
3.1. Definition Referenzmodell
Die Referenz wird im Duden unter den Stichworten „von einer Vertrauensperson gegebe-
ne [lobende] Beurteilung, Empfehlung“ und „Person oder Stelle, auf die verwiesen wird,
weil sie [lobende] Auskunft über jemanden geben kann“ beschrieben [
Gmb13
]. Somit
wird die Referenz sowohl im Sinne einer Empfehlung als auch im Sinne eines Verweises
benutzt. Als Informationsmodell wird das Resultat bezeichnet, dass ein Modellierer für
die Anwendungssystem- und Organisationsgestalter anhand der Informationen über das
vorhandene Systeme, durch eine geeignete Notation, ein Modell erstellt [
Sch98c
, S.63].
Ein Informationsmodell ist ein spezifisches Modell im betriebswirtschaftlichen Bereich.
Somit sind RM spezielle Informationsmodelle, die eine Empfehlung beziehungsweise
Verweis formulieren.
Schütte definiert ein RM als „das Ergebnis einer Konstruktion eines Modellierers, der
für Anwendungssystem- und Organisationsgestalter Informationen über allgemeingültig
zu modellierende Elemente eines Systems zu einer Zeit als Empfehlungen mit einer
Sprache deklariert, so daß ein Bezugspunkt für ein Informationssystem geschaffen
wird[
Sch98c
, S.69].“
2
Somit sind RM abstrakte Modelle, die als Grundgerüst für das
Modellieren von speziellen Unternehmensmodellen als Bezugspunkt herangezogen
werden können. Anhand dieser Beschreibung von Schütte könnte das Bild entstehen,
das RM ähnliche Funktionen übernehmen wie Meta-Modelle. Schütte stellt RM jedoch
auf dieselbe semantische Ebene wie ein anderes betriebswirtschaftliches Modell. Denn
Meta-Modelle beschreiben das Modell eines Modells und fokussieren sich auf die Syntax
des Modellsystems [
Sch98c
, S.72 f.]
3
. Im Zentrum der RM steht die Semantik des RM
und nicht die Syntax.
Ein weiterer Pioneer im Bereich der RM ist Scheer. Er definiert RM als „Dokumentationen
über Prozesswissen, das bei der Modellierung genutzt werden kann. Sie können aus
praktischen Anwendungsfällen (Best Practice Cases) oder theoretischen Überlegungen
entwickelt werden [
Sch98b
, S.61].“ Scheer hebt die Dokumentationsfunktion und die
Modellierungsvorlage von RM in den Vordergrund und sieht darin ein vermarktungs-
2Die Begriffe Bezugspunkt und Empfehlung sind die Merkmale einer Referenz wie oben beschrieben
3auch Kruse vertritt dieselbe Meinung [Kru96, S.15]
39
3. Referenzprozessmodellierung
fähiges Produkt. Er unterscheidet zwischen Vorgehensmodellen und Fachmodellen.
Becker hingegen hebt den Klassenbezug und hohen Abstraktionsgrad von RM her-
vor. „Referenzmodelle spiegeln nicht die Gegebenheiten eines spezifischen Objekts
(Unternehmung) wider, sondern gelten für eine Klasse von Objekten. Sie zeichnen
sich durch einen höheren Abstraktionsgrad als (untemehmens-)spezifische Modelle
aus und beinhalten häufig eine größere Anzahl von Teilmodell-Alternativen, die unter-
schiedliche (Untemehmens-) Szenarien wiedergeben [
BBM+01
, S.399].“ Auch Hars
sieht RM als „ein Modell, das für den Entwurf anderer Modelle herangezogen werden
kann [
Har94
, S.15].“ Zusammenfassend ist zu sehen, dass RM einen standardisierten
Sollprozess auf hohem Abstraktionsniveau repräsentieren. Ein RM kann aus vielen
einzelnen Teilmodellen bestehen, um verschiedene Szenarien abbilden zu können und
ihre Allgemeingültigkeit für verschiedene Problemsituationen zu gewährleisten. In dieser
Arbeit wird die Definition von Schütte für RM herangezogen.
Die Referenzprozessmodellierung befasst sich mit der Entwicklung und Anwendung von
RM. Aufgrund der hohen Anzahl zu modellierenden Prozessen werden Ordnungsrahmen
eingesetzt, die eine übersichtliche Sicht auf die RM ermöglichen. Der Ordnungsrahmen
bietet somit eine einfachere Navigation durch die einzelnen RM und ermöglicht eine
Top-Down-Vorgehensweise. Die Strukturen eines Unternehmens können anhand eines
Ordnungsrahmens besser dargestellt werden [
Bec04
, S.78ff]. Der Ordnungsrahmen
integriert die einzelnen RM in einen Gesamtmodell und stellt somit selber auch ein RM
dar [Sch00, S.54]. Ordnungsrahmen werden in späteren Abschnitten dargestellt.
Anhand der Definitionen
4
und der Begriffsanalyse der RM treten bestimmte Eigenschaf-
ten und Anforderungen für RM hervor. Diese werden im folgenden näher erläutert:
Allgemeingültigkeit:
Die RM erzielen durch die Abstraktion von verschiedenen prakti-
schen und theoretischen Modellen eine breiten Anwendungsbereich (wie ganze
Branchen oder Domänen). Als Sollmodell bietet es Gestaltungsempfehlungen
bzw. einen Gestaltungsgerüst an, der durch weitere Maßnahmen spezialisiert
4
Da nicht auf alle Definitionen, die in der Literatur vorhanden sind eingegangen wurde, sollte der
interessierte Leser auf die jeweiligen Quellen im Literaturverzeichnis zurückgreifen
40
3.1. Definition Referenzmodell
werden kann [
Ros96
, S.34]. Es dient als Ausgangspunkt für die Konstruktion von
detaillierten Modellen.
Empfehlungscharakter: Durch den allgemeinen Aufbau stellen die meisten RM Best-
Practice- oder Common-Practice-Lösungen für den Modellnutzer bereit. Im Ge-
gensatz zu Best-Practice-Lösungen bieten Common-Practice-Lösungen nicht den
besten Aufbau und Struktur für ein Problem sondern eine in der Praxis bewahrte
und sicheren Grundgerüst [BRR99, S.7].
Wiederverwendbarkeit
kann aus der Allgemeingültigkeit hergeleitet werden. Die RM
stellen dokumentiertes Wissen dar, dass immer wieder zur Erstellung von Modellen
bzw. ihrer Varianten herangezogen werden können. Da die RM nur die allgemeine
Struktur enthalten sind für die Wiederverwendung weitere Schritte notwendig um
es den eigenen Ansprüchen entsprechend nutzen zu können.
Adabtierbarkeit
bezieht sich auf den Änderungsaufwand, den ein Nutzer aufwenden
muss, um sie seinen Bedürfnissen entsprechend einsetzen zu können [
All98
,
S.96]. Je geringer der Aufwand für die Änderung desto adaptierbarer ist ein RM
für seinen Nutzer. RM bieten durch ihren Aufbau meistens Konfigurationsmög-
lichkeiten (erweitern, löschen, modifizieren) für den Nutzer an, der durch wenige
Entscheidungen es an seine Bedürfnisse anpassen kann.
Vollständigkeit
enthält sowohl die semantische als auch die syntaktische Richtigkeit
des RM. Die RM dürfen ihre Richtigkeit durch die Adabtierbarkeit nicht verlieren.
Dies ist durch geeignete Regeln zu formulieren und ins RM aufzunehmen. Au-
ßerdem bezieht sich die Vollständigkeit auf die inhaltliche Vollständigkeit [
BRR99
,
S.7]. Ein RM muss alle für ihn notwendigen Daten, Aktivitäten, Strukturen usw.
enthalten, sodass eine Anwendung mit geringem Aufwand gewährleistet werden
kann. Die Vollständigkeit trägt auch zum bessern Verständnis des RM bei. Ein
Ordnungsrahmen kann dabei helfen die Übersichtlichkeit und Vollständigkeit zu
gewährleisten. Die Qualität des RM wird durch die Grundsätze ordnungsmäßiger
Referenzprozessmodellierung (GOR) gesichert [Sch00, S.62].
41
3. Referenzprozessmodellierung
3.2. Klassifikation von Referenzmodellen
Nachdem im vorherigen Abschnitt die Definition und Eigenschaften von RM behandelt
wurden, wird in diesem Abschnitt die Klassifikation von RM beschrieben. In der Literatur
gibt es Ansätze, die die Klassifikation von Informationsmodellen auf die RM übertragen.
Dies ist insofern vertretbar, da RM spezielle Informationsmodelle darstellen. Schütte
versucht anhand eines ERM-Diagramms diese Klassifikation folgend darzustellen (siehe
Abbildung 3.1:
Abbildung 3.1.: Referenzmodellklassifikation nach Schütte [BRR99, S.24]
Die Rechtecke repräsentieren dabei die Objekttypen und geben die Spezialisierung
des RM an. Das übergeordnete Objekttyp ist hier das RM und die Untergeordneten
Objekttypen die restlichen Elemente. Die Abkürzung D steht für disjunkte und die
Abkürzung N steht für nicht disjunkte Spezialisierung eines übergeordneten Objektes in
ein untergeordnetes Objekt. Die Abkürzung T steht für die totale Spezialisierung des
übergeordneten Objektes [
Sch98c
, S.64]. Die Klassifikationsmerkmale unterstützen den
Ersteller als auch den Nutzer eines RM bei der Entscheidungsfindung und Einordnung.
Dabei beinhalten Strukturmodelle die Organisation- und Datensicht eines RM. Das
Verhaltensmodell besteht aus der Prozess- und Funktionssicht. Das Sichtkonzept wurde
in Kapitel 2 Grundlagen beschrieben. Eine weitere Unterteilung findet durch die Phasen,
die Scheer in seinem ARIS-Konzept eingeführt hat, statt. Dabei repräsentieren die Pha-
42
3.2. Klassifikation von Referenzmodellen
sen die Tiefe bzw. die Integrationsebene des RM wieder. Die Phasen sind Fachkonzept,
DV-Konzept und Implementierung.
Eine weitere Untergliederung findet in Organisationsmodelle und Anwendungssystem-
modelle statt. Organisationsmodelle werden auch Branchenmodelle genannt wenn sie
für eine ganze Branche Gültigkeit haben. Dabei beinhalten Organisationsmodelle be-
triebswirtschaftliches Wissen mit Empfehlungscharakter. Da RM Common-Practice- oder
Best-Practice-Lösungen beinhalten, können Unternehmen anhand der Organisationsmo-
delle bewährte Strukturen übernehmen oder für Ihre Bedürfnisse entsprechend weiter an-
passen. Anwendungssystemmodelle beschäftigen sich mit der betriebswirtschaftlichen
Inhalten von der Software eines Unternehmens und ihrer Funktionen. Hierbei kann das
SAP R3 System als Beispiel genommen werden, welches viele betriebswirtschaftliche
Funktionen implementiert hat [
BRR99
, S.24ff]. Bezieht sich das Anwendungssystemmo-
dell auf eine spezielle Software wie SAP R3 kann sie dazu beitragen, die notwendigen
Komponenten der Software für das Unternehmen auszuwählen. Dieser Art von Modellen
stellen Standardanwendungssysteme dar und repräsentieren die informationstechnische
Sicht. Im Vergleich zu Organisationsmodelle sind Anwendungssystemmodelle detail-
lierter. Bei Organisationsmodellen ist primär das Vermitteln von bewährten Abläufen
wichtig, die nicht detailliert sein müssen. Enthalten Anwendungssystemmodelle auch
organisationstechnische Aspekte ist die Trennung zwischen diesen beiden Modellen
nicht mehr einfach [
Sch99
, S.55]. Referenzorganisationsmodelle werden in Abschnitt
3.7 und Kapitel 4 näher erläutert.
Schwegmann unternimmt bei der Klassifikation des RM auch einen ähnlichen Ansatz.
Die in der Abbildung 3.2 grau hinterlegten Bereiche bilden für Schwegmann die Haupt-
klassifikationsmerkmale eines RM. Aus seiner Sicht dominiert die fachkonzeptionelle
Sicht. Die weiteren Bereiche in der Abbildung decken sich mit der Klassifikation von
Schütte überein, auch wenn Schwegmann eine detailliertere Darstellung bietet.
43
3. Referenzprozessmodellierung
Abbildung 3.2.: Referenzmodellklassifikation nach Schwegmann [Sch99, S.54]
3.3. Sprachen und Gestaltungsmöglichkeiten der
Referenzmodelle
Wie auch bei Geschäftsprozessen (GP) erfolgt die Darstellung der RM durch Model-
lierungssprachen. Die Modellierungssprachen bzw. Notationen, die für die Darstellung
verwendet werden, entscheiden über die syntaktische und semantische Aufbau des
RM. Es wird zwischen traditionellen, objektorientierten und hybriden Modellierungs-
sprachen unterschieden [
Sch00
, S.60f]
5
. Zu den traditionellen Sprachen zählen die
Entity-Relationship-Modell (ERM) zur Darstellung von statischen Strukturen, die ereig-
nisgesteuerte Prozesskette (EPK) sowie die Business Process Modelling and Notation
(BPMN) zur Darstellung von dynamischen Aspekten. Die EPK- und BPMN-Notationen
wurden im Kapitel abschnitt 2.3 beschrieben. Hybride Modellierungssprachen verknüpfen
die Elemente der traditionellen und objektorientierten Ansätze in sich.
Als objektorientierte Modellierungssprache kommt das Unified Modeling Language
(UML) [
Gro11b
] zum Einsatz. Dabei werden anhand von Objekten, Attributen, Opera-
5siehe auch Schütte [Sch98c, S.87]
44
3.3. Sprachen und Gestaltungsmöglichkeiten der Referenzmodelle
tionen, Klassen und Assoziationen das Modell erstellt. Jedes Objekt stellt dabei eine
Instanz einer Klasse dar. Die Klasse enthält alle Eigenschaften (Attribute) und Opera-
tionen (Funktionen) die ihre Instanzen (Objekte) haben. Somit enthalten UML-Modelle
Objekte die zueinander in einer Beziehung (Assoziationen) stehen [Kah01, S.20ff]. Für
das Struktur Aspekt in UML wird ein Klassendiagramm modelliert. Hauptsächlich wird
die UML-Modellierungssprache in der Softwareentwicklung eingesetzt. Ansätze RM
durch objektorientierte Sprachen zu beschreiben gibt es von Schwegmann [
Sch99
]
und Schlagheck [
Sch00
]. Jedoch schränkt Schwegmann die UML-Notation ein, damit
die Referenzmodellierung verständlicher und übersichtlicher wird (siehe dazu Schweg-
mann [
Sch99
, S.114ff]). In der Praxis werden EPK- und BPMN-Modelle häufiger für
die fachkonzeptionelle Ebene eingesetzt und UML-Modelle für die DV-technische und
Implementierungsebene.6
Ein weiterer wichtiger Aspekt im Vergleich zu den Modellierungssprachen sind die
Gestaltungsmöglichkeiten und die Vorgehensweise bei der Adaption der RM. Von ei-
nem RM zu einem unternehmensspezifischen Modell liegt ein Adaptationsprozess bzw.
Konfigurationsprozess dazwischen. In der Literatur wird zwischen generierenden und
nicht-generierenden Gestaltungsmöglichkeiten unterschieden [
BDK04a
] [
BG03
, S.77ff]
[BDK04b, S.251ff] [Bec04, S.30ff], welche im folgenden erläutert werden:
Generierende Gestaltungsmöglichkeiten
beinhalten festgelegte Regeln für die An-
passung des RM und halten je nach Anwendungskontext bestimmte vorkonfi-
gurierte Bausteine bereit, um eine unternehmensspezifische Modellvariante zu
generieren. Hierbei spricht man von der Konfiguration. Dadurch können aus dem
allgemeinen Modell spezifische Modelle abgeleitet werden, weshalb diese Art
der Gestaltungsmöglichkeit auch generierend bezeichnet wird [
BDK04b
, S.252].
Die generierende Gestaltungsmöglichkeiten unterscheidet fünf Kategorien für die
Konfiguration:
6
Für einen detaillierteren Einblick in die einzelnen Modellierungssprachen siehe [
Gro11b
,
Gro13
,
DLMR13
,
FR12, Rum99]
45
3. Referenzprozessmodellierung
1. Modelltypselektion
stellt Modelle in unterschiedlichen Modellierungsspra-
chen (EPK, ERM, BPMN, Petri-Netze) zur Auswahl, um verschiedene Ein-
satzbereiche abdecken zu können.
2. Elementtypselektion
stellt unterschiedliche Elemente für die verwendete
Modellierungssprache bereit, z.B. kann ausgewählt werden mit welchen wei-
teren Elementen (Organisationseinheit, Datenobjekt, Anwendungssystem)
die Funktionen verknüpft werden können.
3. Elementselektion
gibt dem RM-Nutzer die Möglichkeit bestimmte Elemente
im RM auszublenden oder einzublenden, je nach Anwendungskontext und
Anforderungen des Nutzers.
4. Beizeichnungsvariation
ermöglicht das Ändern der Fachbegriffe in einem
RM.
5. Darstellungsvariation ermöglicht die Darstellung zu ändern.
Nicht-Generierenden Gestaltungsmöglichkeiten
überlässt dem RM-Nutzer viel Spiel-
raum für die Anpassung des RM. Bei nicht-generierenden Gestaltungsmöglich-
keiten muss der Nutzer selbständig das spezifische Modell erzeugen. Ihm stehen
keine durch Regeln vordefinierten Bausteine bereit. Auch hier gibt es vier Kategori-
en für die Anpassung. Dabei zeigen diese Kategorien die Modellbeziehungen von
Ursprungsmodell zum neu erstellten Modell (siehe Abbildung 3.3). Im folgenden
werden die vier Kategorien näher beschrieben:
1. Aggregation
ist das Zusammensetzen bzw. die Kombination mehrerer Mo-
delle zu einer neuen Modellvariante. Dabei werden bestimmte Modelle als
Ursprung für ein neues Modell benutzt. Als Beispiel könnte die Integration
der Angebotsprüfung im Einkaufsprozess sein [
Bec04
, S.30]. Somit dienen
verschiedene Modelle als Baukasten für eine neue Modellvariante. Dabei wird
dem Nutzer die Stelle im Modell, an der eine Anknüpfung vorgesehen ist, an-
gezeigt und somit die syntaktische und semantische Richtigkeit gewährleistet.
46
3.3. Sprachen und Gestaltungsmöglichkeiten der Referenzmodelle
2. Instanziierung
bietet dem Nutzer eines RM die Möglichkeit einzelne Be-
zeichnungen und Attribute eines Modells bei der Erzeugung einer neuen
Modellvariante selber zu konkretisieren. Dabei beinhalten RM bei der Instanzi-
ierung nur generische und allgemeine Aussagen über das Ursprungsmodell.
3. Spezialisierung
bietet dem RM-Nutzer die Möglichkeit aus dem generellen
RM sämtliche Elemente zu ändern, zu erweitern sowie zu übernehmen.
Hierbei hat der RM-Nutzer uneingeschränkte Modellierungsfreiheit, welches
zu Inkonsistenzen führen kann.
4. Analogieschluss
ermöglicht bewährte Strukturen aus RM für die neue Mo-
dellvariante zu übernehmen. Dabei kann der RM-Nutzer einzelne Strukturen
analog auf sein neues Modell übernehmen.
Abbildung 3.3.:
Darstellung der Modellbeziehungen für nicht-generierende Gestaltungs-
möglichkeiten [Bec04, S.20]
47
3. Referenzprozessmodellierung
3.4. Vorgehensmodell zur Referenzmodellierung
Um die Referenzmodellierung zu systematisieren und den Konstruktionsprozess zu
strukturieren hat Schütte [
Sch98c
, S.184ff] ein Vorgehensmodell entworfen. Dieser be-
steht aus den fünf Phasen Problemdefinition, Konstruktion des Referenzmodellrahmens,
Konstruktion der Referenzmodellstruktur, Komplettierung und Anwendung. Die einzelnen
Phasen und ihre Beziehungen zueinander werden in Abbildung 3.4 verdeutlicht. Dieses
Vorgehensmodell eignet sich für nicht-objektorientiert Referenzmodelle.7
Abbildung 3.4.: Vorgehensmodell zur Referenzmodellierung [Sch98c, S.185]
Die einzelnen Phasen werden nun im folgenden näher beschrieben [
BG03
, 134ff.]
[Sch98c, S.184ff.] [Mai98, S.77ff.]:
Phase 1: Problemdefinition
ist der Ausgangspunkt und soll zu einem gemeinsamen
Verständnis aller Beteiligten über die Verwendung des RM beitragen. Schütte nennt
es den „multipersonellen Eignungsprozess“. Bei der Problemdefinition sollten auch
Namenskonventionen getroffen werden, damit der Konstruktionsprozess bei allen
Beteiligten zum selben Ergebnis und Verständnis führt. Somit lassen sich Fehler
7
für objektorientierte Referenzmodelle haben Schlagheck [
Sch00
, S.77ff.] sowie Schwegmann [
Sch99
,
S.183ff.] ein anderes Vorgehensmodell
48
3.4. Vorgehensmodell zur Referenzmodellierung
während der Modellierung und Konstruktion minimieren. Die Problemdefinition hat
das Ziel den Zweck und Einsatz des RM zu klassifizieren.
Phase 2: Konstruktion des Referenzmodellrahmens
soll das „Was?“ der Modellie-
rung definieren. Unternehmensspezifische Modelle repräsentieren die Varianten
der RM dar, weshalb der Modellierer die zu modellierende Merkmale und ihre
Ausprägungen identifizieren muss. Schütte erklärt dieses Vorgehen anhand eines
Master-Referenzmodells, welches die Standardisierung von Begriffen und Modell-
bausteinen vornimmt. Anhand dessen können die Bausteine die eine Konfiguration
benötigen kategorisiert und allgemeingültige Strukturen dargestellt werden.
Phase 3: Konstruktion der Referenzmodellstruktur
versucht die in der 2. Phase de-
finierten Rahmen zu formalisieren. Hierbei wird durch Modellierungssprachen
detailliert die Struktur abgebildet und versucht die Strukturanalogien in RM zu
konstruieren. Zum Einsatz kommen hier Build-Time-Operatoren um Alternativen
in der Verhaltensstruktur darzustellen. In dieser Phase wird meistens mit den
Sprachen der EPK oder ERM, für die Datensicht, gearbeitet. Der Fokus in dieser
Phase liegt auf der syntaktischen und semantischen Richtigkeit.
Phase 4: Komplettierung
sieht die Vervollständigung und Ergänzung des entstande-
nen Modells aus Phase 3 vor. Das Ergebnis aus der dritten Phase wird um Querver-
bindungen und inhaltlichen Aussagen ergänzt, damit die RM sowohl intern als auch
extern mit anderen Modellen konsistent sind. Das entstandene Modell, das aus der
isolierten Betrachtung eines bestimmten Problemfalles erzeugt wurde, muss sich in
das Ordnungsrahmen sowohl aus Daten- als auch aus der Prozesssicht integrieren
lassen. Deshalb ist es wichtig die Abhängigkeiten und Wechselbeziehungen zu
komplettieren.
Phase 5: Anwendung
sieht den Einsatz des RM vor. Dabei kann der Nutzer die all-
gemeine Struktur des RM nutzen oder durch vorgesehene Anpassungen seinen
Bedürfnissen entsprechend editieren.
49
3. Referenzprozessmodellierung
Das Vorgehensmodell wird durch die Grundsätze ordnungsmäßiger Referenzmodellie-
rung unterstützt und gewährleistet einen hohen Qualitätsniveau. Dadurch lassen sich
Referenzmodelle systematisch nutzen, kreieren und konfigurieren.
3.5. Grundsätze ordnungsmäßiger
Referenzprozessmodellierung
Der Ansatz der Grundsätze ordnungsmäßiger Modellierung (GOM) wurden für die allge-
meine Erstellung von Modellen in Kapitel 2 näher beschrieben. Die GOM besteht aus
den Grundsätzen der Richtigkeit, Relevanz, Wirtschaftlichkeit, Klarheit, Vergleichbarkeit
und systematischen Aufbau. Sie dienen als allgemeine Empfehlungen, um die vielen
Freiheitsgrade während der Modellierung einzugrenzen. Die GOM ist in der Referenzmo-
dellierung wiederverwendbar, kann jedoch Aufgrund des hohen Abstraktionsgrades der
RM die Grundsätze der Richtigkeit und Relevanz nicht direkt übernehmen [
BG03
, S.147].
Die semantische Richtigkeit kann jedoch bei RM nicht objektiv festgestellt werden. Daher
schlägt Schütte die Grundsätze der Konstruktionsadäquanz und Sprachadäquanz vor
[
Sch98c
, S.113]. Im folgenden werden die Grundsätze ordnungsmäßiger Referenzmo-
dellierung (GOR) näher beschrieben8:
Konstruktionsadäquanz
welches nach Remmert [
Rem01
, S.22] folgend formuliert
wird: „Konstruktionsadäquat sind Modelle dann, wenn sie das zu repräsentierende
Problem erfassen.“ Dabei ist die Intra- und Intermodellkonsistenz eine essenzi-
elle Grundvoraussetzung, denn Schütte [
Sch98c
, S.119] betont den „Nutzen des
Modells für Zwecke seiner praktischen Anwendung“. Für diesen Grundsatz ist es
wichtig, dass die Problemdefinition vollständig beschrieben wurde und ein Kon-
sens über die Problemfelder bestehen. Im Fokus steht die einheitliche Darstellung
von Sachverhalten sowohl innerhalb des Modells als auch mit unterschiedlichen
Modellen. Dieser Grundsatz analysiert dabei nicht die Zusammenhänge zwischen
8Die einzelnen Grundsätze werden in [Sch98c, S.138ff.] näher erläutert
50
3.5. Grundsätze ordnungsmäßiger Referenzprozessmodellierung
Modellen unterschiedlicher Modelltypen [
Sch98c
, S.121]. In dieser Hinsicht ist für
die Konstruktionsadäquanz die Darstellung der einzelnen Obejekte des Problem-
feldes mit Hilfe einer geeigneten Notation im zentralen Aufmerksamkeitsbereich
[Mai98, S.73].
Sprachadäquanz
stellt die Spracheignung für eine bestimmte Problemsituation in den
Fokus. Dabei wird eine Sprache auf ihre semantische Mächtigkeit, Formalisie-
rungsgrad und Sprachverständlichkeit untersucht [
Sch98c
, S.125]. Im Zentrum
dieses Grundsatzes steht die Angemessenheit und Richtigkeit (Syntax) der Spra-
che. Es werden auch Aspekte der technologischen Unterstützung der Sprache,
Erweiterbarkeit und die Ausdrucksstärke beachtet.
Wirtschaftlichkeit
ist wie bei GOM auf die Kosten und Nutzen der Modellierung ange-
legt, welches die ökonomische Sichtweise und Zielsetzung beinhaltet. Dabei sind
Aspekte wie die Einarbeitung der Mitarbeiter und Robustheit des RM, gegenüber
Veränderungen und Anpassungen, Elemente der Wirtschaftlichkeit [
Rem01
, S.23].
Systematischer Aufbau
erfordert eine übersichtliche und systematische Darstellung
der RM, um die hohe Komplexität besser in den Griff zu bekommen.
Klarheit
zielt die Anschaulichkeit und gute Verständlichkeit des RM. Jede Zielgruppe
sollte die RM verstehen können, damit eine Anwendung einfacher realisiert werden
kann.
Vergleichbarkeit
setzt das Existieren mehrerer Modelle voraus. Dabei spielen Soll-
und Ist-Modelle eine bedeutende Rolle. Modelle die miteinander integriert werden
müssen auch vergleichbar sein.
Abbildung 3.5 verdeutlicht die einzelnen Grundsätze und fasst sie zusammen. Dabei
werden die Grundsätze der Konstruktionsadäquanz und Sprachadäquanz als notwendige
Grundsätze gesehen. Bei den übrigen Grundsätzen handelt es sich um hinreichende,
da zwischen ihnen hohe Interdependenzen herrschen.
51
3.6. Ziele der Referenzprozessmodellierung
3.6. Ziele der Referenzprozessmodellierung
In diesem Abschnitt werden die Ziele der Referenzprozessmodellierung (RPM) zusam-
mengefasst. Aufgrund des recht neuen Forschungsgebietes sind empirische Untersu-
chungen schwer zu finden. Jedoch hat sich in der Literatur die Einteilung der Ziele
in Kostenreduktion, Erlösaspekte, Risiko und Nutzen der RM etabliert. Schütte hat in
diesem Bereich eine empirische Untersuchung anhand von Fragebogen durchgeführt
und die Ergebnisse veröffentlicht [
Sch98c
, S.75ff.]. RM unterstützen die Kostenminimie-
rung auf vielen Wegen
9
. RM, die auf hohem Abstraktionsniveau Unternehmensmodelle
darstellen, bieten durch ihren Aufbau vordefinierte Strukturen und Prozesse an, die
in Projekten verwendet werden können. Dadurch wird die Modellierung von unterneh-
mensspezifischen Modellen beschleunigt. Ein weiterer wichtiger Aspekt der RM ist die
Bereitstellung von allgemeingültigen Begrifflichkeiten innerhalb des Einsatzzweckes.
Dadurch wird der Koordinationsaufwand mehrerer Beteiligten reduziert und die Ver-
ständlichkeit stark gesteigert. Desweiteren bieten RM bessere Prozessintegrationen
durch vordefinierte Schnittstellen zu weiteren Prozessmodellen. RM bieten entweder
Best-Practice-Lösungen oder Common-Practice-Lösungen für wiederholt auftretende
Problemsituationen. Dadurch können Unternehmen auf bewährte Lösungen zurück-
greifen und ersparen sich aufwendige Projekte für die Lösungsfindung. Werden RM
erfolgreich eingesetzt tragen sie zur Entstehung von Erlösen bei. Auch Hars [
Har94
,
S.33] sieht dieselben Vorteile durch den Einsatz von RM. Er betont die Reduktion der
Entwicklungsdauer durch eingesparte Zeit und gesteigerten Qualität der neuen Modelle.
RM werden unternehmensübergreifend eingesetzt, weshalb das darin enthaltene Fach-
wissen qualitativer ist. Dadurch wird das Risiko inkonsistenter Modelle und Prozesse
reduziert. Die Ergebnisse der empirischen Untersuchung von Schütte werden im fol-
genden Anhand von Abbildungen gezeigt. Dabei beinhalten die Abbildungen die oben
beschriebenen Sachverhalte.
9Nachfolgende Erläuterungen sind nach [Kra97, S.431ff.]
53
3.7. Literaturrecherche und vorhandene Referenzmodelle
Die Einsatzziele für RM lassen sich in Anwendungssystem- und Organisationssystem-
gestaltung kategorisieren [
BRR99
, S.28ff.]. Hier wird nur auf die Organisationssystem-
gestaltung eingegangen. Diese sind folgende:
•Geschäftsprozessmanagement:
In diesem Bereich bieten RM durch vordefinier-
te Prozessmodelle mögliche Lösungen an.
•Zertifizierung
nach DIN ISO 9000ff setzt die Dokumentation der Vorgänge in
einem Unternehmen voraus. RM bieten hier durch ihre Modelle fertige und anpass-
bare Lösungen an.
•Benchmarking
ist eine Vergleichsmethode, an der Unternehmen ihren Status-
Quo messen können. Dabei müssen RM mit weiteren Informationen erweitert
werden, damit ein Benchmark möglich ist.
•Wissensmanagement
ist ein wesentlicher Bestandteil für die Weiterentwicklung
von Unternehmen. RM dokumentieren und speichern das Know-How und machen
es Unternehmen einfacher das Wissen zu präsentieren.
3.7. Literaturrecherche und vorhandene Referenzmodelle
In diesem Abschnitt wird eine Übersicht über die in der Literatur vorzufindenden RM
gegeben. Die deutsche Nationalbibliothek
10
führt unter dem Stichwort Referenzmodell*
471 Einträge. Des weiteren bietet die Universität Saarland
11
einen Referenzmodellkata-
log, in der RM tabellarisch dargestellt werden. Des weiteren gibt es veröffentlichte Paper,
die eine tiefgreifende Analyse über die vorhandenen RM beinhalten, wie von Fettke und
Loos [
FL03a
], Becker et al. [
BDK04a
] sowie von Fettke et al. [
FLZ06
]. Eine Übersicht
über die vorhandenen Referenzmodellübersichten befindet sich in der Arbeit Fettke im
Anhang B [
Fet06
]. Anhand dieser Quellen ist es möglich einen guten Überblick über die
10 Erreichbar unter http://www.dnb.de/DE/Home/home_node.html
11 Erreichbar unter http://rmk.iwi.uni-sb.de/index.php
55
3. Referenzprozessmodellierung
in der Literatur vorhandenen RM zu bekommen. Es ist jedoch hinzuweisen das diese
Quellen nur RM aufnimmt, die auch als solches deklariert wurden.
In der akademischen Forschung werden RM bezüglich ihrer Verwendung, Entwick-
lung und Analyse sehr stark thematisiert. Um einige Arbeiten zu nennen, welche aus
der akademischen Forschung entstanden sind: Hars [
Har94
], Kruse [
Kru96
], Remme
[
Rem12
], Becker und Schütte [
BS04
], Hamm [
Ham97
], Scheer [
Sch94
], Schwegmann
[
Sch99
], Schlagheck [
Sch00
], Remmert [
Rem01
], Lang [
Lan97
]. Die wichtigsten RM,
welche sehr bekannt sind, sind die von Becker und Schütte sowie von Scheer. Becker
und Schütte haben ein RM für die Handelsbranche generiert. Scheer hat ein RM für
Industrieunternehmen konstruiert.
Die Abbildung 3.8 zeigt die Klassifikation der Referenzmodelle und ihre Zuordnung
zu der jeweiligen Kategorie der generierenden oder nicht-generierenden Klasse. Die
zweite Abbildung 3.9 zeigt in tabellarischer Form die einzelnen RM und gibt weitere
Informationen über den Autor, die Modellierungssprache, der Verfügbarkeit und der
Branche für die es entwickelt wurde.
56
4
Referenzmodelle in EPK und ihre
Einsatzgebiete
Dieses Kapitel behandelt spezielle RM, die in der Notationssprache EPK modelliert
wurden. Selbstverständlich gibt es weitere RM, wie auch im vorherigen Kapitel gezeigt,
auf die im einzelnen nicht eingegangen wird. In diesem Kapitel werden die RM für
industrielle Geschäftsprozesse von Scheer (4.1), für den Handel von Schütte (4.2),für
vertriebslogistische Systeme von Kruse (4.3) sowie für die Handelslogistik von Remmert
(4.4) näher erläutert. Diese Arbeiten bieten sowohl methodische Ansätze als auch
konkrete Referenzmodelle an.
59
4. Referenzmodelle in EPK und ihre Einsatzgebiete
4.1. Referenzmodell für industrielle Geschäftsprozesse
Ein Referenzmodell für die industriellen Geschäftsprozesse entwickelte Scheer [
Sch94
]
anhand des Y-CIM-Modells (siehe Abbildung 4.1) und von ihm entwickelte ARIS-Konzept.
Dabei steht die Abkürzung CIM für die Computer Integrated Manufacturing. Das Ypsilon
(Y) deutet auf die zwei verschiedenen Aspekte innerhalb der Leistungserstellung hin.
Der eine Aspekt ist die betriebswirtschaftlich-planerische Seite der Produktionsplanungs-
und Steuerungssystem (PPS) und der andere Aspekt die ingenieurtechnische Seite
der Produktions- und Produktentwicklung. Wie in der Abbildung 4.1 dargestellt umfasst
die linke Seite die Prozesse von der Kundenauftragsbearbeitung bis hin zum Versand
des Produktes und die rechte Seite von der Produktanforderung bis hin zu der Produkti-
on und Verpackung des fertigen Produktes. Dabei werden diese einzelnen Prozesse
von den übergeordneten Prozessen der Informationsmanagement, Finanzbuchführung,
Informations- und Koordinationsprozesse sowie der Kosten- und Leistungsrechnung
unterstützt.
Abbildung 4.1.: Y-CIM Model [Sch94, S.93]
60
4.1. Referenzmodell für industrielle Geschäftsprozesse
Scheer untergliedert seine Arbeit dabei in die drei Bereiche [Sch94, S.91]:
1. Logistik
2. Leistungsentwurf
3. übergreifende Informations- und Koordinationssysteme
Die Logistik umfasst nach Scheer die „allgemeine Bewegung und Lagerung von Gütern
[Sch94, 91]“. Er beschreibt sowohl die operative als auch die planerische und dispositi-
ve Ebene der Logistik und unterscheidet zwischen der Vertriebs-, Beschaffungs- und
Produktionslogistik. Der zweite Bereich der Leistungsentwicklung beschreibt die com-
puterunterstützte Entwicklung von Produkten und ihrer Produktion. Die übergreifenden
Informations-und Koordinationssysteme beinhalten Prozesse des Rechnungswesens, Fi-
nanzbuchführung und des Informationsmanagements. Scheer präsentiert seine Modelle
auf einem mittleren Aggregationsniveau, um die „Realitätsnähe“ nicht zu verlieren und
um detailliert genug die Abläufe darstellen zu können.
Das ARIS-Konzept (Architektur integrierter Informationssysteme) welches in dieser
Arbeit oft erwähnt wurde, wird für die Modellierung und Darstellung der Modelle her-
angezogen, siehe Abbildung 4.2. Scheer präsentiert seine Modelle in den Sichten,
Organisationssicht, Datensicht, Funktionssicht, Leistungssicht und Steuerungssicht.
Damit verfolgt Scheer die Komplexitätsreduktion. Dabei stellt er für jede Sicht das Fach-
konzept, das DV-Konzept und die Implementierung vor. Die Implementierung spielt
jedoch eine geringe Rolle, weshalb Scheer darauf kaum detailliert eingeht.
Die Fachkonzepte in jeder Beschreibungssicht dienen als betriebswirtschaftliche Aus-
gangssituation in einer formalisierten Sprache und als Ausgangspunkt für die Umsetzung
in die Informationstechnik. Für die Erstellung des DV-Konzeptes werden die Fachkonzep-
te als Ausgangspunkt benötigt und werden durch informationstechnische Sachverhalte
ergänzt. Das DV-Konzept enthält die notwendigen Schnittstellen zur Informationstechnik.
Die Implementierung als letzter Schritt versucht das DV-Konzept in Programmcode
umzusetzen.
61
4. Referenzmodelle in EPK und ihre Einsatzgebiete
Abbildung 4.2.: ARIS-Konzept nach Scheer [Sch94, S.88]
Um dem Leser stets einen guten Überblick zu gewähren nutzt Scheer die Vorgangsket-
tendiagramme (VKD), um die zu beschreibenden Bereiche komprimiert darzustellen.
VKD stellen alle Beschreibungssichten von ARIS (Funktionen, Organisationen, Daten,
und ihre Verknüpfungen) tabellenförmig dar. Die Modelle werden in der EPK-Notation
modelliert. Dabei stellen Fachkonzepte für die Datensicht, Funktionssicht und Organisa-
tionssicht die Struktur und die Fachkonzepte für die Steuerungssicht bzw. Prozesssicht
das Verhalten des Modells dar. Dieser Sachverhalt wird in Abbildung 4.3 dargestellt.
62
4.2. Referenzmodell für den Handel
Abbildung 4.3.: Vorgangskettendiagramm Beispiel [Sch94, S.212]
4.2. Referenzmodell für den Handel
Ein weiteres weit verbreitetes RM in der Wirtschaftsinformatik ist das Handels-H-Modell.
Das RM wurde von Becker und Schütte [
BS04
] für den Handel entwickelt. Dabei set-
zen heute Handelsunternehmen im operativen Bereich Warenwirtschaftssysteme ein,
um die betriebswirtschaftlichen Sachverhalte informationstechnisch abbilden zu kön-
nen [
BRR99
, S.152]. Ein Warenwirtschaftssystem „repräsentiert die warenorientierten
dispositiven, logistischen und abrechnungsbezogenen Prozesse für die Durchführung
der Geschäftsprozesse eines Handelsunternehmens [
BS04
, S.46]“. Das Warenwirt-
schaftssystem wird durch das H repräsentiert. Um die Komplexität zu reduzieren und die
Navigation durch das RM zu erleichtern wird ein Ordnungsrahmen in Form des Buchsta-
ben H eingesetzt. Die folgende Abbildung 4.4 illustriert diesen Sachverhalt. Dabei bildet
das Ordnungsrahmen das klassische Lagergeschäft mit den Prozessen der Beschaffung,
63
4. Referenzmodelle in EPK und ihre Einsatzgebiete
der Lagerung sowie dem Verkauf ab. Dabei zeigt die linke Seite des Handels-H-Modells
die Beziehungen zum Lieferanten und die rechte Seite die Beziehungen zum Kunden
auf [BS04, S.114]. Das Lager dient dabei als Überbrückungsfunktion.
Abbildung 4.4.:
Handels-H-Model: Architektur für Handelsinformationssystemen [
BS04
,
S.43]
Desweiteren zeigt die Anordnung der einzelnen Bereiche Strukturanalogien, welche eine
Ähnlichkeit der Prozesse auf derselben Höhe aus der rechten und linken Seite erweist.
Diese Analogie wird in der Beziehung zwischen Lieferant-Ware auf der linken Seite und
Kunde-Ware auf der rechten Seite sichtbar. Die Anordnung der einzelnen Funktionen
innerhalb der rechten und linken Seite bilden ein Prozesscluster und zeigt Beziehungs-
zusammenhänge zwischen diesen [
BS04
, S.43]. Somit setzen die unten angeordneten
Prozesse die Ausführung der oberen Prozesse voraus. Das im Dach befindlichen Aufga-
ben des Handels-H-Modells stellen dabei Auswertungs- und Analysesysteme dar. Im
Fundament sind die betriebswirtschaftlich-administrative Funktionen.
Wie auch vorher erwähnt stellt das Handels-H-Modell das klassische Lagergeschäft
dar. Daneben gibt es jedoch vier weitere Geschäftsarten, die für den Handel relevant
64
4.2. Referenzmodell für den Handel
sind und nur eine leicht veränderte Variante des Handels-H-Modells sind. Im folgenden
werden die vier Geschäftsarten näher erläutert [BRR99, S.162]:
Streckengeschäft
stellt den logistischen Warenfluss ohne Zwischenlagerung direkt vom
Lieferanten zum Kunden. Das Handelsunternehmen agiert zwischen dem Lieferanten
und dem Kunden und sorgt für den nötigen dispositionsbezogenen Informations- und
Wertefluss, welche im Abbildung 4.5 dargestellt ist.
Abbildung 4.5.: Handels-H-Model: Streckengeschäft [BS04, S.638f.]
Zentralregulierungsgeschäft
übernimmt nur die Werteflüsse im Handelsunternehmen.
Die logistischen und dispositiven Flüsse handelt der Lieferant direkt mit dem Kunden
ab. Das Handelsunternehmen sorgt für die Fakturierung und der Buchhaltung, siehe
Abbildung 4.6.
Aktionsgeschäft
behandelt die Beschaffungsseite und Verkaufsseite des Handels-H-
Modells equivalent und unterscheidet nicht mehr zwischen diesen beiden Seiten, siehe
Abbildung 4.7 .
65
4. Referenzmodelle in EPK und ihre Einsatzgebiete
Abbildung 4.6.: Handels-H-Model: Zentralregulierungsgeschäft [BS04, S.644]
Abbildung 4.7.: Handels-H-Model: Aktionsgeschäft [BS04, S.654]
Dienstleistungsgeschäft
wird äquivalent zum normalen Warengeschäft behandelt und
wird als Erweiterung gesehen. Jedoch tritt das Handelsunternehmen hier als Produzent
auf und nicht als Händler.
66
4.3. Referenzmodell für vertriebslogistische Systeme
Schütte und Becker stellen die Beschreibungssichten für Funktionen, Daten und Pro-
zesse für das Handelsunternehmen und nutzen für die Prozessbeschreibung die EPK-
Notation. Durch das von Ihnen eingesetzte Ordnungsrahmen ist es für den Anwender
einfacher die einzelnen Informationsmodelle zuzuordnen und die Schnittstellen zu identi-
fizieren. Außerdem erarbeiten Sie die Anforderungen [
BS04
, S.35ff.] für die einzelnen
Handelsprozesse und stellen ihre Modelle auf mittlerem Aggregationsniveau. Dabei
ist das Handels-H-Modell sehr umfangreich und bietet ca. 110 Prozessmodelle mit je
3 Sichten (Funktion, Daten, Prozess) dar. Der Anwender kann durch die RM seine
Varianten erstellen.
Ein weiteres RM, welches das Handels-H-Modell als Basis nutzt und dem Anwender
detailliertere RM bietet befindet sich in der Arbeit von Stadler [
Sta10
]. Im Gegensatz zum
Handels-H-Modell bietet er konfigurierbare RM, welche durch Build-Time-Operatoren
an die Bedürfnisse des Anwenders angepasst werden können. Der Anwender kann
durch die Build-Time-Operatoren die für Ihn notwendigen Prozessschritte auswählen
und andere Schritte ausblenden. Dadurch sind Varianten einfacher zu konfigurieren.
Stadler berücksichtigt in seiner Arbeit dabei den Lebensmitteleinzelhandel, den Mode-
einzelhandel und den Hartwaren-Großhandel. Für die ausgewählten Domänen bietet
die Arbeit die wesentlichen warenwirtschaftlichen Funktionen des Handels. Die Arbeit
ist einer der wenigen die auch explizite konfigurierbare RM anbietet und diese nicht nur
methodisch evaluiert.
4.3. Referenzmodell für vertriebslogistische Systeme
Das RM für vertriebslogistische Systeme wurde von Kruse [
Kru96
] entworfen. In seiner
Arbeit entwirft er ein vertriebslogistisches System für kundenanonymer Lagerfertigung
und grenzt damit seine Arbeit ein. Anhand des Y-CIM-Modells ordnet er die Vertriebs-
logistik ein. Dadurch versucht er eine höhere Detaillierungsgrad zu erreichen, in dem
er für eine spezielle Domäne das RM entwickelt. Kruse verwendet dabei den Ansatz
von Scheer und nutzt für die Modellierung das ARIS-Konzept. Der Schwerpunkt liegt
67
4. Referenzmodelle in EPK und ihre Einsatzgebiete
dabei bei administrativ-dispositive Geschäftsprozesse der industriellen Vertriebslogistik.
Vertriebslogistische Geschäftsprozess beinhalten hauptsächlich Koordinationsaufgaben.
Kruse untersucht in seiner Arbeit die zeitlich-logische Ablauf der Geschäftsprozesse.
Dabei versteht er Vorgänge die „einen expliziten Zeitbezug aufweisen, aber zu keiner
Veränderung der Systemstruktur führen“[
Kru96
, S.20]. Insgesamt entwickelt Kruse 12
RM in seiner Arbeit. Hierbei werden Strukturmodelle und Verhaltensmodelle dargestellt.
Ziel vertriebslogistischer Systeme ist es die Güterverfügbarkeit effizient sicherzustellen.
Dabei spielt die Transportfunktion, Lagerhaltungsfunktion und Umschlagsfunktion der
Güter eine essenzielle Rolle.
Dabei zeigt Kruse in seiner Arbeit organisatorische, informationstechnische und instru-
mentelle Gestaltungspotentiale und Ihre Auswirkungen auf die vertriebslogistischen
Systeme auf. Die RM gehen dabei von der Auftragsbearbeitung, Versandbearbeitung,
Fakturierung, Wareneingang und Vertriebslogistiksteuerung [
Kru96
, 152ff.], wie in der
Abbildung 4.8 dargestellt.
Kruse nutzt wie Scheer ERM für Beschreibung von strukturellen Sachverhalten. Die
prozessbezogene bzw. verhaltensbezogene Ebenen werden durch EPK-Diagramme
modelliert. Innerhalb der Arbeit werden vier Modellierungssichten des ARIS-Konzeptes
dargestellt.
68
4.4. Referenzmodell für die Handelslogistik
Abbildung 4.8.: Grobablauf Vertriebslogistik [Kru96, S.152]
4.4. Referenzmodell für die Handelslogistik
Das RM für die Handelslogistik fokussiert sich auf den Lebensmittelhandel für Super-
märkte und befindet sich in der Arbeit von Remmert [
Rem01
]. Remmert entwickelt in
seiner Arbeit ein Vorgehensmodell und versucht das „Produktivitätsparadoxon der Infor-
mationstechnologie“ zu beseitigen [
Rem01
, S.1ff.]. Dabei wird unter diesem Begriff die
Beziehung zwischen dem Einsatz der IT und ihre Auswirkung verstanden. Theoretisch
erhofft man sich einen positiven Nutzen aus dem Einsatz der IT, welches jedoch nicht im-
69
4. Referenzmodelle in EPK und ihre Einsatzgebiete
mer eintritt. Daher wird für diesen Sachverhalt der Begriff des Produktivitätsparadoxons
verwendet.
Das Vorgehensmodell für die RM in der Handelslogistik umfasst mehrere Phasen
[
Rem01
, S.119]. Dabei beginnt es mit der Zielformulierung um Grundlegende Ziele
und Anforderungen, wie Auswahl des Betriebstyps, logistischen Ziele oder logistischen
Gestaltungsparameter, festzustellen. Die Phase der Prozessidentifikation versucht aus
den grundlegenden Handelsfunktionen [
Rem01
, S.74ff.] die Prozessaktivitäten zu er-
mitteln. Dabei werden diese in Module gegliedert und die Grenzen definiert. Auf dieser
Weise existieren Module wie „Lieferant-Lager“ oder „Lager-Filiale“. Sind die Module
identifiziert erfolgt in der Phase des Prozessdesigns unter Berücksichtigung der GOM
die Festlegung der physischen Struktur und Aktivitätenauswahl. Die Phase der Alter-
nativenbeurteilung betrachtet die Alternativen Gestaltungsmaßnahmen und wählt eine
Variante, welche die betriebstypenspezifischen Ziele am ehesten abbildet. Zum Schluss
erfolgt dann die Integration in die Informationstechnik.
In seiner Arbeit wird für die Modellierung die EPK-Notation verwendet. Insgesamt wird
nur die Prozesssicht in der Arbeit verwendet und nur vier RM zur Verfügung gestellt.
Die Beschränkung auf den Betriebstyp „Supermarkt“ und Handelslogistik wirkt dabei
komplexitätsreduzierend.
4.5. Weitere Referenzmodelle
In dieser Arbeit wurden die kommerziellen Referenzmodelle wie Supply Chain Opera-
tions Reference (SCOR) Model [
Wir15b
], welches die Lieferkette bzw. Supply Chains
betrachtet oder SAP R3 [
Wir15a
], welches ein branchenunabhängiges Softwarepaket
mit betriebswirtschaftlichen Funktionen ist, nicht näher betrachtet. Der Grund ist die be-
schränkte Verfügbarkeit der RM. In diesem Abschnitt werden drei weitere RM vorgestellt,
welche nicht mit der EPK-Notation modelliert wurden.
70
4.5. Weitere Referenzmodelle
Schlagheck [
Sch00
] bietet in seiner Arbeit RM für das computergestütze Controlling und
betrachtet auch die Bereiche des Prozess- und Projektcontrollings. Für die Modellierung
wird die UML-Notation mit ihren Klassen- und Aktivitätsdiagrammen genutzt [
Sch00
,
S.218ff.]. Der Fokus der Arbeit liegt dabei bei der Entwicklung der Informationssysteme
für den betrieblichen Einsatz. Jedoch bieten diese RM auch für die Organisationsgestal-
tung Anhaltspunkte. Um das Vorgehen für die objektorientierte Referenzprozessmodel-
lierung zu unterstützen entwirft Schlagheck ein iterativ-inkrementelles Vorgehensmodell
für die Modellierung, wie die Abbildung 4.9 illustriert.
Abbildung 4.9.: Vorgehensmodell nach Schlackheck [Sch00, S.78]
Das Vorgehensmodell besteht aus der ersten Phase der Problemdefinition und führt
über mehrere Analyseschritten zu der Entwicklung des RM. Als Resultat des Vorgehens-
modells sollte eine spezialisierte Variante des Referenzmodells entstehen. Außerdem
71
4. Referenzmodelle in EPK und ihre Einsatzgebiete
stehen für den Anwender für die Anpassung Build-Time-Operatoren zu Verfügung,
welches konfigurierbare RM beinhalten.
Ein weiteres objektorientiertes RM wurde von Schwegmann [
Sch99
] entworfen. In sei-
ner Arbeit evaluiert er objektorientierte Methoden und entwirft durch seine Fallstudie
ein RM für die Lagerverwaltung. Für die Referenzmodellierung wird die Sprache UML
und EPK verwendet. Eines der wichtigen Erkenntnisse der Arbeit ist, dass die Spra-
che UML für die fachkonzeptionelle Unternehmensmodellierung ungeeignet ist [Sch99,
S.225], da für die Variantenbildung spezielle Konstrukte notwendig sind. Des weiteren
sind UML-Diagramme zu detailliert (feingranular) und bringen nicht die erforderliche
Abstraktionsmöglichkeit, um die Komplexität zu reduzieren.
Im Gegensatz zu den vorher erwähnten RM, bietet Hamm [
Ham97
] ein RM für den
industriellen Einkauf. Für die Modellierung nutzt er die Methode des Process-Mappings,
welches ein weiteres Beschreibungssprache darstellt. In sieben Schritten entwirft Hamm
sein RM. Von der Analyse des Einkaufs, Definition des strategischen Einkaus bis hin zu
einem Vorgehensmodell. Er modelliert fünf informationstechnik-basierte Referenzmodel-
le: Marktorientierter, bedarfsträgergetriebener, risikoinduzierter, lieferantengetriebener
und beziehungsgetriebener Beschaffungsprozesstyp. Diese werden dann weiter unter
Leistung, Aktivität, Organisation und Informationssystem charakterisiert [
Ham97
, S.235].
Außerhalb der Betriebswirtschaft existieren weitere RM auf die in dieser Arbeit nicht
eingegangen wird. Des weiteren gibt es auch kleinere RM Veröffentlichungen als Paper,
die hier nicht erläutert wurden. Die Fülle an RM, welche als solches deklariert und nicht
deklariert wurden ist enorm. Die Arbeit beschränkte sich daher auf die bekanntesten
und ausführlichsten Arbeiten, welche außer methodischen Aspekten auch konstruktive
RM angeboten haben.
72
5
Modellierung und Transformation von
EPK-Referenzprozessen nach BPMN 2.0
Dieses Kapitel beinhaltet die Transformation von RM nach BPMN 2.0 Modellierungsspra-
che. Dabei wird zuerst das Tool Signavio, mit der die Modellierung durchgeführt wird,
vorgestellt und danach die ausgewählten Prozesse aufgezeigt, eine Vorgehensweise für
die Transformation erläutert und Regeln erarbeitet mit der die Modellierung durchgeführt
wird. Nachdem die Modelle transformiert wurden, werden sie validiert und die dabei
gewonnen Erkenntnisse zusammengefasst.
73
5. Modellierung und Transformation von EPK-Referenzprozessen nach BPMN 2.0
5.1. Signavio das BPMN-Modellierungstool
Signavio [
Gmb15a
] bietet mit seinem Process Editor eine webbasierte Umgebung für
die Prozessmodellierung an. Im Rahmen des BPM Academic Initative
1
können teil-
nehmende Institutionen dieses Tool frei nutzen. Der Process Editor ermöglicht das
Erstellen von Prozesslandkarten, Prozesssteckbriefen, Prozessdiagrammen, Konversati-
onsdiagrammen, Choreographiediagrammen, Ereignisgesteuerte Prozessketten, UML
Klassendiagrammen, Petri Netzen und Organigrammen. Dabei unterstützt der Editor die
BPMN 2.0 vollständig und bietet dem User anhand der Werkzeugpalette die Elemente
an. Aufgrund der Vielzahl an Symbolen stellt der Editor dem Modellierer verschiedene
Werkzeugleisten zur Verfügung, damit die Symbole überschaubarer bleiben.
Abbildung 5.1.: Signavio Process Editor
Abbildung 5.1 zeigt die Umgebung des Process Editors im Browser an. Auf der linken
Seite ist die Werkzeugleiste zu sehen, in der die Symbole durch hineinziehen in die
Zeichenfläche genutzt werden können. In der oberen Leiste befinden sich die Funktio-
1http://www.signavio.com/bpm-academic-initiative/
74
5.1. Signavio das BPMN-Modellierungstool
nen zum verkleinern, vergrößern, exportieren, speichern, drucken und versenden. Der
Editor bietet für BPMN 2.0 fünf verschiedene Werkzeugleisten an. Das sind Kernele-
mente, beschreibende Elemente, analytische Elemente, Ausführungselemente und die
vollständige Symbolpalette.
Der Process Editor bietet durch seine moderne Arbeitsumgebung und integrierte Funk-
tionen einige Vorteile für den Modellierer. Diese können folgend aufgezählt werden
[Gmb15b]:
•Übersichtliche Symbolpalette mit Drag & Drop Funktion
•
Automatische Positionierung der Symbole und Unterstützung durch Ausrichtungsli-
nien
•Automatische Syntaxprüfung, um Modellierungsfehler und unerlaubte Konstrukte
zu identifizieren
•Exportfunktion der modellierten Diagramme für die Dokumentation
•
Diagrammvergleichsfunktion für die Überprüfung der einzelnen erstellten Versionen
desselben Diagramms bzw. Modells
•Möglichkeit der Simulation der Prozessmodelle
•Zentrales Prozess-Repository mit Ordnerstrukturen und Prozesshierarchien
•
Unterstützung verschiedener Modellierungssprachen wie BPMN 2.0, EPK, Organi-
grammen, Wertschöpfungsketten
•Möglichkeit von Diagrammimporten
Signavio versucht ein sehr übersichtliches und einfaches Tool dem Modellierer zur
Verfügung zu stellen und bietet durch die webbasierte Lösung Plattformunabhängigkeit
an. Auf dem Markt sind weitere Modellierungstools wie MS Visio oder AristaFLow BPM
Suite vorhanden, auf die in dieser Arbeit nicht eingegangen wird.
75
5. Modellierung und Transformation von EPK-Referenzprozessen nach BPMN 2.0
5.2. Vorgehensweise für Transformation
Bevor die Transformation der RM durchgeführt wird, wird zunächst die Vorgehensweise
näher beschrieben. Die Vorgehensweise, wie in Abbildung 5.2, ermöglicht das syste-
matische Vorgehen und das Minimieren von Fehlern und besteht aus den folgenden
Schritten:
1. Ermitteln der zu transformierenden Prozesse (Abschnitt 5.3)
2. Konstruktion von Transformationsregeln (Abschnitt 5.4)
3.
Analyse der Transformationsregeln und der Beschreibungssprachen (Abschnitt
5.5)
4. Transformation der ausgewählten Prozesse mit Signavio Process Editor
5. Validierung der Modelle (Abschnitt 5.5)
6. Zusammenfassung der Ergebnisse und der Erfahrungen2(Abschnitt 5.6)
Abbildung 5.2.: Vorgehensweise
Aufgrund der vielen Prozessmodelle in den Werken, die in Kapitel 4 vorgestellt wurden,
werden im ersten Schritt nur ein Teil, für die Transformation ausgewählt. Dabei wird ver-
sucht die Prozessmodelle mit den meisten Konstrukten und Elementen auszuwählen. Im
zweiten Schritt werden die Modellierungssprachen EPK und BPMN näher betrachtet und
Transformationsregeln hergeleitet. Dieser Schritt dient der Überprüfung der einzelnen
Elemente in EPK und ihrer Repräsentation in BPMN 2.0. Sind diese Regeln aufgestellt
wird eine Analyse durchgeführt, welches die Defizite und mögliche Schwachpunkte ana-
lysiert. Im vierten Schritt wird anhand dieser Regeln die ausgewählten Prozessmodelle
2Lessons Learned
76
5.3. Auswahl und Überblick der Prozesse
transformiert und im Anschluss validiert. Die Erfahrungen, die durch die einzelnen Schrit-
te gesammelt werden, werden im letzten Schritt zusammengefasst und dokumentiert.
Die Diskussion der Ergebnisse wird im Kapitel 6 stattfinden.
5.3. Auswahl und Überblick der Prozesse
Um die in der Literatur vorzufindenden Referenzprozessmodelle (RPM) einzugrenzen,
werden nur bestimmte Prozesse für die Transformation ausgewählt. Die RPM werden
dabei aus den Arbeiten von Scheer, Becker und Schütte, Stadler, Kruse sowie von
Remmert genommen und dienen als Grundlage. Wichtige Aspekte bei der Auswahl der
Prozesse sind:
•Modellierungssprache: Die Prozessmodelle sollten in EPK modelliert sein
•Anzahl der Elemente:
Um eine gewisse Aussage über die Transformation machen
zu können ist es notwendig, dass die ausgewählten Modelle mindestens aus 20
einzelnen Elementen bestehen.
•Elemente im Einsatz:
Die vorhandenen Grundelemente, wenn möglich auch die
erweiterten Elemente, der EPK-Sprache sollten alle im Grundmodell vorhanden
sein
•Syntax: Die Regeln für die Modellierung in EPK sollten eingehalten sein
•Semantik:
Das Grundmodell sollte eine semantische Bedeutung haben und ein
reales Szenario in Unternehmen darstellen.
•Darstellung:
Übersichtliche, strukturierte und geordnete Darstellung des Grund-
modells
•Erweiterte Informationen:
Falls aus dem Modell die notwendigen Information wie
Daten und Organisationseinheiten nicht hervorgehen abgeleitet werden können.
Folgende Tabelle stellt die ausgewählten RPM dar:
77
5. Modellierung und Transformation von EPK-Referenzprozessen nach BPMN 2.0
Scheer Industrielle Geschäftsprozesse
1- EPK der Bedarfsauflösung [Sch95, S.141]
2- EPK der Auftragsdatenergänzung [Sch95, S.239]
3- EPK der Zeit- und Kapazitätsplanung [Sch95, S.266]
4- EPK der Beschaffungslogistik [Sch95, S.426]
5- EPK des Vertriebablaufs [Sch95, S.456]
6- EPK der Produktentwicklung [Sch95, S.539]
Becker und Schütte Geschäftsprozesse im Handel
7- EPK Lieferantenstammdatenpflege [BS04, S.279]
8- EPK Artikelstammdatenpflege [BS04, S.281]
9- EPK Konditionspflege [BS04, S.286]
10- EPK mehrstufige Disposition [BS04, S.316]
11- EPK Wareneingang Lager [BS04, S.345]
12- EPK Rechnungsprüfung [BS04, S.370]
Stadler Konfigurative Prozesse im Handel
13- EPK Artikelstammanlage (Grunddaten) [Sta10, S.128]
14- EPK Artikelstammanlage (Logistikdaten) [Sta10, S.136]
Kruse Vertriebslogistische Systeme
15- EPK Auftragsbearbeitung [Kru96, S.180f.]
16- EPK Versandbearbeitung [Kru96, S.186f.]
17- EPK Fakturierung [Kru96, S.192f.]
18- EPK Wareneingang [Kru96, S.196f.]
Remmert Handelslogistik
19- EPK Lieferant - Lager [Rem01, 227]
20- EPK Lager - Filiale [Rem01, 228]
Tabelle 5.1.: Ausgewählte Prozesse
78
5.4. Transformationsregeln der Referenzprozesse nach BPMN
5.4. Transformationsregeln der Referenzprozesse nach
BPMN
Dieser Abschnitt wird zunächst, auf Basis der vorhandenen Elemente der Notationsspra-
chen, Transformationsregeln ableiten. Dabei werden zwei Punkte berücksichtigt.
1. Welche Elemente in BPMN 2.0 repräsentieren die EPK-Elemente semantisch?
2.
Gibt es Konstrukte, welche in EPK nach BPMN 2.0 nicht abgebildet werden
können?
3.
Weicht die Semantik der Modelle durch die unterschiedliche Bedeutung von Ele-
menten in den Notationssprachen von Originalmodell ab?
Die Transformation darf nicht dazu führen, dass die Semantik des Originalmodells
verloren geht. Daher ist es wichtig vorher sich mit den einzelnen Sprachelementen
auseinander zu setzen, die im folgendem erläutert werden.
Funktionen
Funktionen stellen die Kernelemente in jedem Modell dar, da Sie die Arbeitsschritte
in einem Modell darstellen. Bei EPK-Modellen wird gerne dabei von Funktionen ge-
sprochen und in BPMN 2.0 von Aktivitäten. Innerhalb von BPMN 2.0 gibt es sehr viele
Möglichkeiten, um Aktivitäten darzustellen. Des weiteren besteht die Möglichkeit Sub-
prozesse, d.h. Funktionen mit mehreren Arbeitsschritten, innerhalb desselben Models
durch eine aufklappbare Aktivität darzustellen. Eine weitere Möglichkeit Arbeitsschritte
darzustellen bietet BPMN 2.0 durch Zwischenereignisse, in denen Nachrichten gesendet
bzw. empfangen werden können. Es ist ersichtlich das durch die große Anzahl der
Elemente in BPMN 2.0 im Vergleich zu EPK ein Problem entstehen kann.
79
5. Modellierung und Transformation von EPK-Referenzprozessen nach BPMN 2.0
Ereignisse
Ereignisse dienen in EPK-Modellen um Zustände abzubilden. Darin sehen wir ein wei-
teres wichtiges Konstrukt der EPK. Ereignisse sind ein elementarer Bestandteil von
Prozessmodellen, die jedoch in BPMN 2.0 anders gehandhabt werden. Im Fokus von
BPMN 2.0 sind die Aktivitäten und nicht die Ereignisse, weshalb die Semantik hier
sich von EPK unterscheidet. In BPMN 2.0 werden Ereignisse nur verwendet, wenn sie
essentiell für den Prozessverlauf sind. BPMN 2.0 unterscheidet zwischen drei Ereignis-
arten, dem Start-, Zwischen- und Endereignis. Dabei ist es wichtig zu unterscheiden,
ob das Ereignis in Folge eines Prozessschrittes eintritt oder ein Auslöser (Trigger) für
ein Prozessschritt ist [
GL13
, S.51f.]. Eine weitere Aufgabe die Ereignisse in BPMN 2.0
übernehmen ist es an anderen Stellen im Prozessverlauf über eingetretene Zustän-
de zu informieren. Die EPK unterscheidet nicht zwischen den einzelnen Ereignisse
und nutzt sie nur um Zustände darzustellen. Entscheidungen, die nach den XOR oder
ODER-Konnektoren kommen, müssen jedoch beachtet werden, da sie die Entschei-
dungsrelevante Ereignisse abbilden.
Teilprozesse und Prozessschnittstellen
Um Vorgänger- und Nachfolgeprozesse darzustellen werden innerhalb von EPK-Modellen
Prozessschnittstellen eingesetzt. Diese werden auch verwendet, um Unterprozesse dar-
zustellen. Innerhalb der EPK-Notation befindet sich jedoch nur ein Symbol, um diese
Vorgänge darstellen zu können. BPMN 2.0 bietet für die Darstellung von Unterprozessen
bzw. Teilprozessen und Prozessschnittstellen drei Symbole zu Verfügung:
•Verlinkung (auslösend)
•Verlinkung (eintretend)
•Aufklabbare Task bzw. Subprozess
80
5.4. Transformationsregeln der Referenzprozesse nach BPMN
Gateways
Gateways dienen sowohl bei der EPK als auch beim BPMN 2.0 um den Kontrollfluss
bzw. unterschiedliche Abläufe oder Entscheidungen innerhalb eines Modells darzustel-
len. Die gängigen Gateways in EPK wie AND, XOR sowie ODER können in BPMN
2.0 ohne weiteres abgebildet werden. Die Semantik der Gateways ist dieselbe. Der
ODER-Gateway ist in beiden Sprachen problembehaftet, da die Semantik nicht deutlich
genug ist. In BPMN 2.0 werden Kantenbeschriftungen für die jeweilige Entscheidung
oder Kontrollfluss verwendet, welches in EPK in Form von nachfolgenden Ereignissen
dargestellt wird. Desweiteren bietet die BPMN 2.0 weitere Gateways, die als solches
in EPK nicht vorhanden sind. Das komplexe Gateway, welches die Anzahl der erfüllten
Bedingungen für den Fortgang des Prozessverlaufs bestimmen und das ereignisbasierte
Gateway, welches den Fortgang des Prozesses an eintretende Ereignisse verknüpft
[GL13, S.42f.]. Diese Gateways könnten für das Abbilden mehrerer Startereignisse zur
Anwendung kommen, da BPMN 2.0 das Abbilden mehrerer Startereignisse wie in EPK
nicht vorgesehen hat.
Datenobjekte
Die Datenobjekte, die in EPK vorhanden sind können ohne weiteres in BPMN 2.0
dargestellt werden. Hier sollten keine Probleme entstehen.
Rollen bzw. Organisationseinheiten
Werden in EPK Organisationseinheiten abgebildet, bietet sich hier in BPMN 2.0 auf
die Pools und Lanes zurückzugreifen. Jedoch setzt die Verwendung von Pools und
Lanes eine klare Trennung von Verantwortlichkeiten für Aufgaben voraus. Eine Aufgabe,
die durch mehrere Organisationseinheiten durchgeführt wird, kann in EPK einfacher
dargestellt werden als in BPMN 2.0. Innerhalb BPMN 2.0 müssen daher auf alternative
Darstellungen zurückgegriffen werden.
81
5. Modellierung und Transformation von EPK-Referenzprozessen nach BPMN 2.0
Abbildung 5.3.: Übersicht der Transformationsregeln
82
5.5. Analyse der Transformationsregeln und der Beschreibungssprachen
5.5. Analyse der Transformationsregeln und der
Beschreibungssprachen
Im vorherigen Abschnitt wurden die Transformationsregeln gebildet und jedem Symbol
der EPK-Notation wurde ein äquivalentes Symbol der BPMN-Notation bereitgestellt.
Im Vergleich zu der EPK-Notation stellt die BPMN-Notation dem Modellierer viel mehr
Symbole zur Verfügung. Dies kann mit der Zielsetzung und dem Anspruch der BPMN-
Notation begründet werden, welches die Modellierung sowohl fachlicher Prozesse (auf
der semantischen Ebene) als auch ausführbare Prozesse ermöglichen möchte. Die
EPK-Notation, welches vor der BPMN-Notation entwickelt wurde ermöglicht nur das
Darstellen von fachlichen Prozessen und hat die Ausführbarkeit nicht im Fokus. Für
die Transformation stellt die BPMN-Notation somit sehr viele Symbole zur Verfügung,
welche unterschiedliche Modellvarianten eines einzigen Modells ermöglichen.
Für die fundierte und theoretische Evaluation der Beschreibungssprachen hat sich in
der Forschung das Bunge-Wand-Weber (BWW) Modell etabliert. Das BWW-Modell
wird hier nicht vollständig wiedergegeben. Den interessierten Leser sei auf die Lite-
ratur verwiesen [
WW93
,
WW95
,
WW90
]. Für die Evaluierung der Referenzmodelle
anhand des BWW-Modells haben Fettke und Loos [
FL03b
] ein Paper veröffentlicht.
Die Basis des BWW Modells basiert auf die von Bunge entwickelte Ontologie [
Bun77
].
Wand und Weber haben anhand dieser Ontologie verschiedene Modelle abgeleitet, um
sie für Informationssysteme anwendbar zu machen. Die BWW-Modelle stellen dabei
verschiedene Modelle für unterschiedliche Anwendungen zur Verfügung. Dabei hilft
das BWW-Repräsentationsmodell Modellierungssprachen zu evaluieren und sie auf
Vollständigkeit und Klarheit zu überprüfen. Dabei wird überprüft, ob die Modellierungs-
sprache das Ontologiemodell vollständig und klar abbilden kann. Abbildung 5.4 zeigt die
Hauptelemente des BWW-Modells für die Evaluierung der Modellierungssprachen.
Das Hauptelement des BWW-Modells bildet dabei das BWW-Gegenstand (Thing). Diese
Gegenstände besitzen BWW-Eigenschaften (Property), sowohl bekannte als unbekann-
83
5. Modellierung und Transformation von EPK-Referenzprozessen nach BPMN 2.0
Abbildung 5.4.: BWW-Modell enthaltene Elemente
te Eigenschaften. Dabei wird das BWW-Gegenstand durch BWW-Zustände (States)
beschrieben. Die BWW-Gegenstände erfahren Transformationen durch Funktionen
und ändern dadurch ihre BWW-Zustände. Die BWW-Gegenstände befinden sich in
einem BWW-System, welches aus mehreren BWW-Gegenstände zusammengesetzt
sind [Kro12, S.104].
In Rosemann et al. [
RRIG06
] untersuchten die Autoren die gängigen Modellierungs-
sprachen anhand des BWW-Repräsentationsmodell [
GR00
, S.76]
3
und fassten ihre
Ergebnisse in einer Tabelle [
RRIG06
, S.453] zusammen. Die Tabelle enthält die Über-
sicht der Ergebnisse der einzelnen Sprachen. Dabei zeigte sich, das die EPK-Notation im
Vergleich zu BPMN-Notation
4
Defizite aufweist. Nichtsdestotrotz ist die BPMN-Notation
ontologisch auch nicht vollständig, aber im Vergleich zu EPK bildet sie von der Ontologie
mehrere Elemente ab. Die Autoren begründen diese Ergebnisse mit der Einflussnahme
von EPK und Petri-Netzen bei der Entwicklung der BPMN-Notation. Die BPMN-Notation
bietet durch ihren vielfältige Symbolpalette eine detaillierte Unterscheidung der zu
modellierenden Vorgänge.
3Die einzelnen Elemente des Repräsentationsmodells wurden im Artikel [GR00] detailliert beschrieben
4hier wurde die BPMN Version 1.0 untersucht
84
5.6. Validierung der transformierten Prozesse
Eine weitere Möglichkeit Beschreibungssprachen zu evaluieren bieten die Workflow-
Patterns. In Recker et al. [
RRK07
, S.30ff.] wurde die BPMN-Notation anhand der
Workflow-Patterns und der BWW-Repräsentationsmodell verglichen und evaluiert. Als
Resultat ergänzen die Workflow-Patterns das Evaluieren einer Beschreibungssprache
anhand des BWW-Repräsentationsmodells.
5.6. Validierung der transformierten Prozesse
Nachdem die Prozesse in die BPMN-Notation transformiert wurden ist die Validierung
und die Überprüfung auf Fehler und Abweichungen durchzuführen. Bei der Transformati-
on wurden die im Abschnitt 5.4 beschriebenen Transformationsregeln angewendet.
Validierung: Scheer - Industrielle Geschäftsprozesse
Prozess-ID 1, 2, 6:
Die ausgewählten Prozesse von Scheer beinhalten aufgrund des
mittleren Aggregationsniveaus wenige Informationen bezüglich einzelnen Tätigkeiten.
Häufig kommen diese Tätigkeiten am Anfang seiner Prozesse, vor um die Herkunft der
Startereignisse zu verdeutlichen (siehe Prozesse 1, 2, 6). Diese Tätigkeiten wurden
in der BPMN-Notation nicht berücksichtigt. Stattdessen wurden die darauffolgenden
Ereignisse auf relevante Ereignisse hin untersucht.
Prozess-ID 1:
In Prozess 1 wurde kein Endereignis modelliert, welches zu einer Dauer-
schleife geführt hätte. In diesem Fall wurde in der BPMN-Notation vor dem Endereignis
eine XOR-Verknüpfung eingefügt, welches die Ausführung der Sekundärbedarfsplanung
überprüft und die zweite Ausführung verhindert.
Prozess-ID 1, 4, 5:
Innerhalb dieser Prozesse wurden Zwischenereignisse modelliert,
welche für den Prozessablauf essentiell waren. Diese Zwischenereignisse wurden in-
nerhalb der EPK-Notation jedoch nicht hervorgehoben. Zwischenereignisse sind die
Freigabe, das Empfangen oder das Absenden von Nachrichten oder das Abwarten einer
Zeit.
85
5. Modellierung und Transformation von EPK-Referenzprozessen nach BPMN 2.0
Prozess-ID 1, 2, 3, 4, 5, 6:
Startereignisse mussten für die Transformation analysiert
werden. Die Startereignisse bildeten meistens Geschäftsregel-, Zeit- und Nachrichtener-
eignisse ab. Einige Startereignisse konnte aufgrund ihrer Beschaffenheit und Informati-
onsgehalt nicht in die BPMN-Notation überführt werden. Generell sind Ereignisse nur
bei relevanten Ereignissen zu berücksichtigen und allgemeine Statusereignisse bei der
Transformation nicht zu berücksichtigen.
Validierung: Becker und Schütte - Geschäftsprozesse im Handel
Prozess-ID 7, 8, 9, 10, 11, 12:
Startereignisse sind auch bei Becker und Schütte auf
Relevanz zu überprüfen. Häufiger tauchen auch Ereignisse ohne eine vorherige Aktivität
mitten in Prozessmodellen auf, welche als Startereignis oder Zwischenereignisse be-
handelt wurden.
Prozess-ID 7, 8, 9, 10, 11, 12:
Prozessschnittstellen tauchen bei allen Prozessmodellen
auf und wurden anhand der vorher definierten Transformationsregeln behandelt. Da-
bei musste zwischen der Verlinkung und Teilprozess entschieden werden. Wurde die
Prozessschnittstelle am Ende eines Prozessmodells platziert, so wurde die Verlinkung
eingesetzt.
Prozess-ID 7, 8, 9, 10, 11, 12:
Die Tätigkeiten, die mit „Prüfe“ und anschließendem
XOR-Gateway modelliert wurden, wurden auch in BPMN analog modelliert, da die ein-
zelnen Schritte der Prüfung aus dem Modell nicht hervorgingen und Informationsverluste
vermieden wurden.
Validierung: Stadler - Konfigurative Prozesse im Handel
Die Prozessmodelle von Stadler
(ID 13,14)
konnten sehr gut transformiert werden. Dies
mag an der recht neuen Veröffentlichung und der detaillierten Prozessbeschreibungen
liegen. Außerdem verwendet Stadler nur selten bis kaum OR-Gateways, welches die
Semantik der Modelle verbessert.
86
5.7. Erkenntnisse und Lessons Learned
Validierung: Kruse - Vertriebslogistische Systeme
Das hohe Aggregationsniveau der Prozessmodelle von Kruse
(ID 15, 16, 17, 18)
führt
dazu das Aktivitäten nicht genau beschrieben sind. Diese wurden unverändert bei der
Transformation übernommen. Jedoch wurden die Organisationseinheiten, die genutzten
Module und Inputdaten bei der Transformation nicht berücksichtigt. Das liegt an der darin
enthaltenen hohen Anzahl und vielfältigen Informationen. Kamen Applikationsmodule
zum Einsatz nutzte Kruse eine eigene Darstellung, um diese abzubilden, welches kein
äquivalentes Flussobjekt in BPMN hatte. Daher wurden diese als Aktivitäten abgebildet.
Bei der Transformation kam es damit zu Informationsverlusten, welche jedoch nicht den
Kontrollfluss betrafen.
Validierung: Remmert - Handelslogistik
Remmert
(ID 19, 20)
nutzt für die Darstellung der RM die EPK-Notation innerhalb einer
VKD ähnlichen Tabelle mit 5 Spalten. Dabei wurden die ersten drei Spalten Organisati-
onseinheit, Ereignis und Funktion berücksichtigt. Aufgrund des hohen Aggregationsni-
veaus der Daten wurden die Daten und die IT-Applikationsspalte nicht berücksichtigt.
Daher kam es zu minimalen Informationsverlusten. Generell bieten die Modelle von
Remmert eine geringe Tiefe und sind auf sehr hohem Aggregationsniveau dargestellt.
5.7. Erkenntnisse und Lessons Learned
In diesem Abschnitt werden die Erfahrungen, die während der Transformation gewonnen
wurden, zusammengefasst. Im Großen und Ganzen ist es möglich mit der EPK-Notation
modellierte Prozessmodelle in die BPMN 2.0-Notation zu überführen. Je detaillierter
das EPK-Modell ist desto einfacher ist die Transformation. Die Transformation kann
nicht ohne Informationsverluste durchgeführt werden. Die Allgemeingültigkeit der RM
und die aggregierte Darstellung der Modelle führt zu komprimierten Darstellungen und
87
5. Modellierung und Transformation von EPK-Referenzprozessen nach BPMN 2.0
Beschreibungen. Daher können einige Informationen in BPMN 2.0 nicht abgebildet wer-
den. Dies Betrifft die Organisationszugehörigkeit und den Dateninput und Datenoutput.
Desweiteren sind nicht alle Elemente die in BPMN vorhanden sind für die Transformation
relevant. Dies betrifft hauptsächlich Ereignisse wie die Fehler, Eskalation, Abbruch,
Kompensation, Mehrfach und Mehrfach/Parallel.
Nichtsdestotrotz sollten folgende Punkte beachtet bzw. gesondert behandelt werden:
•
Generell müssen allgemeine Ereignisse, die den Status betreffen in BPMN 2.0
nicht modelliert werden. Jedoch müssen Ereignisse nach XOR-Gateways (Ent-
scheidungen) auf Relevanz überprüft werden. Es könnten wichtige Ereignisse
vorhanden sein, die für den weiteren Verlauf des Prozesses relevant sind.
•
Mehrere Startereignisse innerhalb eines EPK-Modells können nicht direkt über-
nommen werden. Es ist zu überprüfen, ob ein Ereignis basiertes Gateway oder ein
XOR-Gateway für die Verknüpfung der Startereignisse in BPMN 2.0 in Betracht
kommen. Die Nutzung eines mehrfach Startereignisses (ein Symbol in BPMN)
wird nicht empfohlen.
•
Ereignisse, die ohne einen Input-Knoten mitten im Prozessmodell auftauchen
müssen auf die Eigenschaft als Start- oder Zwischenereignis in BPMN 2.0 überprüft
werden.
•
Bei Ereignissen, die eine Nachricht enthalten ist es je nach Situation ein Signal-
oder Nachrichtereignis in BPMN 2.0.
•
Generell sollten bei Ereignissen auf die Semantik fokussiert werden. Handelt es
sich um eine Geschäftsregel-, Nachricht-, Zeit- oder Signalereignis.
•
RM bieten durch ihre Allgemeingültigkeit keine detaillierte Beschreibung von Aktivi-
täten. Daher muss während der Transformation bei der Namensgebung innerhalb
von BPMN 2.0 die Regel Objekt+Verb eingehalten werden und die Tätigkeit unbe-
nannt werden.
88
5.7. Erkenntnisse und Lessons Learned
•
Ein Prozessmodell kann mehrere Endereignisse enthalten. Diese sollten für die
Übersichtlichkeit in BPMN 2.0 auf ein Endereignis reduziert werden. Falls dies
nicht möglich sein sollte, ist wie in RM die Endereignisse zu modellieren.
•
Pools und Lanes sollten nur bei genauen Zugehörigkeiten der Aktivitäten eingesetzt
werden.
Die oben beschriebenen Punkte betreffen die Modellierung innerhalb der Transformation.
Jedoch weißen die einzelnen RM der Autoren Besonderheiten auf, die im vorherigen
Abschnitt erläutert wurden.
89
6
Diskussion
In vorherigen Kapiteln wurden die theoretischen Wissensbausteine der Arbeit präsentiert.
Dabei wurde nach der Top-Down-Vorgehensweise dem Leser die Thematik herangeführt
und zum eigentlichen Forschungsgegenstand der Arbeit, nämlich die Transformation
von EPK-Modellen nach BPMN 2.0, geleitet. Außerdem wurden viele Themengebiete
aufgezeigt und in einer komprimierten Art und Weise präsentiert. Dieses Kapitel erhebt
sich nun den Anspruch die Ergebnisse und die theoretische Basis der Arbeit einer
Diskussion zu unterziehen. Desweiteren wird auf die in der Literatur vorhandenen Kritik
eingegangen und die subjektive Sichtweise des Verfassers auf das Thema dargestellt.
Zuerst werden die Referenzmodelle, dann die Referenzmodellierung und zum Schluss
die Transformation kritisch gewürdigt.
91
6. Diskussion
Die Referenzmodellforschung steht vor der Herausforderung, dass die Forschungsrich-
tungen sich sehr unterscheiden. Die Forschung in diesem Bereich enthält sehr viele
Veröffentlichungen methodischer und theoretischer Basis als auch praktischer Natur,
welches sehr differenzierte Herangehensweisen beinhalten. Dies führt zu einer unüber-
schaubaren Anzahl an Ergebnissen, welche klassifiziert werden müssen (Klassifizierung
siehe [
FL03a
]). In dieser Hinsicht ist es für Referenzprozessnutzer unabdingbar sich vor-
her über die geeigneten Methoden und Modelle zu informieren, die viel Zeit in Anspruch
nimmt. Ein weiterer Punkt, welcher die Nutzung der Referenzprozesse erschwert ist die
Dokumentation der Prozesse. Die in der Forschung veröffentlichten Referenzprozesse
sind in Büchern und Papern enthalten und werden nicht in einer zentralen und digitalen
Datenbank gepflegt. Dies erschwert die Nutzung und das Auffinden von Informationen.
Das Hauptziel von Referenzmodellen ist es ein konzeptionelles Rahmenwerk für das
Erstellen von spezifischeren Modellen zu ermöglichen. Dabei werden stets die Eigen-
schaften Allgemeingültigkeit und Empfehlungscharakter hervorgehoben [
Fet06
, S.23].
Jedoch werden in den Arbeiten diese Eigenschaften nicht detailliert genug definiert und
erläutert. Mit der Eigenschaft der Allgemeingültigkeit kann eine Domäne oder ein be-
stimmtes Unternehmenstyp gemeint sein, da in vielen Arbeiten die Referenzmodelle für
ein bestimmtes Typus an Unternehmen entwickelt werden. Desweiteren ist nicht immer
ersichtlich, ob der Empfehlungscharakter bei Referenzmodellen sich auf Best-Practices
oder Common-Practices stützt. Die Eigenschaft des Empfehlungscharakters sieht auch
vom Brocke [
BG03
, S.32] kritisch und sieht darin eine mangelnde Überprüfbarkeit. Die
Methodik und Konzepte zu Erstellung von Referenzmodellen ist in der Literatur sehr de-
tailliert beschrieben worden, jedoch fehlt es an konkreten und praktischen Modellen, die
die Theorie ins praktische Umsetzen. Viele Modelle basieren auf denselben Methoden
und Konzepten. Neueren Methoden fehlt es an praktischen Beispielen.
Ein weiterer Punkt betrifft die Referenzmodellmodellierung. Hier sind die Aspekte Pro-
zesslandkarte bzw. Ordnungsrahmen, Beschreibungssprache und Gestaltungselemente
sowie die Modellierung zu betrachten. Die in dieser Arbeit vorgestellten Referenzmodelle
(siehe Kapitel 4) beinhalteten einen Ordnungsrahmen, in der die einzelnen Prozess-
92
modelle zugeordnet wurden. Das Handels-H-Modell und Y-CIM-Modell bieten dem
Anwender eine Orientierung in welchen Bereichen die Prozessmodelle zuzuordnen sind.
Nichtsdestotrotz kann ein Ordnungsrahmen, wie das Handels-H-Modell, eine Prozess-
landkarte nicht ersetzen, jedoch vereinfacht es die Navigation innerhalb der einzelnen
Referenzmodelle. Die Beschreibungssprachen der Referenzmodelle unterscheiden sich
je nach Autor und Zielsetzung der Arbeit stark. Hauptsächlich ist die Literatur von der
EPK-Notation gekennzeichnet und verwendet diese aufgrund der weiten Verbreitung des
ARIS-Konzeptes. Die Ordnungsrahmen ermöglichen bestimmte Unternehmenstypen
abzubilden, jedoch wird es nur durch einen hohen Aufwand möglich sein verschiedene
alternative Organisationsmodelle in einem Referenzmodell darzustellen. Viele vorhande-
ne Referenzmodelle grenzen auch ihre Allgemeingültigkeit durch die Definition eines
bestimmten Unternehmenstyps oder Rahmens stark ein.
Die Beschreibungssprachen der Modelle variieren von objektorientierten Sprachen
(UML) zu formalen Sprachen (EPK, BPMN 2.0) oder Petri-Netzen. Dabei wurden keine
Referenzmodelle in der BPMN-Notation gefunden, welches an der neuen Erscheinung
der Sprache zurückzuführen ist. Nichtsdestotrotz ist die BPMN 2.0 Sprache im Vergleich
zu ihren Vorgängern EPK und Petri-Netze mächtiger. BPMN 2.0 bietet durch sein Meta-
Modell die Möglichkeit den Austausch von Modellen zu vereinfachen. Ein Meta-Modell
verbessert auch das Verständnis der Sprache. Desweiteren bietet die Sprache weitere
Diagrammtypen, um die Darstellung von Organisationsstrukturen und Kommunikationss-
trukturen besser darzustellen. Die Möglichkeit, die Modelle in ausführbare Modelle zu
transformieren, bietet auch eine einfachere Handhabung und Implementierungsmöglich-
keit in die Informationstechnik. Ein möglicher Kritikpunkt gegen die BPMN 2.0 ist die
große Symbolpalette. Dies führt zu einer gesteigerten Komplexität bei der Modellierung
von Abläufen.
Als vorletzter Punkt innerhalb der Referenzmodellierung sind die Gestaltungselemente
zu erwähnen. Wie auch im Abschnitt 3.3 aufgezeigt wurde, wird zwischen generieren-
den und nicht-generierenden Gestaltungsmöglichkeiten unterschieden. Jedoch sind
Referenzmodelle, die auf die Analogie basierte Modellierung von spezifischen Un-
93
6. Diskussion
ternehmensmodellen setzen sehr weit verbreitet. Stadler [
Sta10
] bietet durch seine
Referenzmodelle generierende Gestaltungsmöglichkeiten an, welches eine der führen-
den Referenzmodelle in diesem Bereich ist. Jedoch benötigen Referenzmodelle, die
generische Gestaltungselemente anbieten, feingranulare Darstellungen, welches ein
hohes Aufwand bei der Modellierung bedeutet. Außerdem müssen die Referenzmodel-
lersteller mögliche zukünftige Alternativen und Verknüpfungen vorhersehen und diese in
das Referenzmodell einbetten. Dies würde nach Oliver [
Tho06
, S.144] die Flexibilität der
Referenzmodelle reduzieren. Schütte sieht es ähnlich und kritisiert die konfigurativen
Gestaltungsmöglichkeiten als „Vordefinierbarkeit von konkreten Ausgangslösungen“, die
in einem unvorhersehbaren Umfeld nicht funktionieren würde [
Sch98c
, S.256]. Die in
dieser Arbeit verwendeten Referenzmodelle beinhalteten lediglich nicht-generierende
Gestaltungsmöglichkeiten. Dies erschwert das Nutzen des Prozess-Know-Hows, er-
möglicht jedoch eine höhere Flexibilität. Daher sind aufwendige Transformationen der
Referenzmodelle notwendig. Auch die notwendigen Prozessschnittstellen werden nur
auf hohem bzw. mittlerem Darstellungsniveau aufgezeigt. Desweiteren kritisiert Rem-
me die mangelnde Nachvollziehbarkeit von Gestaltungsentscheidungen innerhalb von
Referenzmodellen und sieht darin eine mögliche Fehlerquelle [
Rem12
, S.3]. Viele Ge-
staltungsentscheidungen sind implizit übernommen wurden und werden nicht detailliert
erläutert.
Ein wichtiger Aspekt, welches bei der Referenzmodellierung essenziell ist, ist die Mo-
dellierung als solches anzusprechen. Für die Modellierung werden objektive Richtlinien
benötigt, die in dieser Arbeit wie die Richtlinien Grundsatz ordnungsmäßiger Model-
lierung bzw. Referenzmodellierung vorgestellt wurden. Diese beinhalten jedoch eine
subjektive Komponente des Modellerstellers. Daher ist es wichtig, die Richtlinien in eine
Modellierungskonvention umzusetzen und die Qualität der erstellten Referenzmodelle
zu gewährleisten [
Mai98
, S.70]. Diese sollte wiederum für die Nutzung der Modelle gut
dokumentiert sein. Die Qualität der Modelle wird auch von der Erfahrung der Modellierer
und in den Prozess involvierten Personen abhängig sein. Daher ist eine subjektive
Komponente stets vorhanden, die jedoch minimal gehalten werden sollte.
94
Nachdem nun die Themengebiete der Referenzmodelle und Referenzprozessmodellie-
rung besprochen wurden, ist es wichtig die Transformation kritisch zu betrachten und
auf Einzelheiten einzugehen. Wie auch im vorherigen Abschnitt beschrieben, ist die
Transformation mit Einschränkungen nach BPMN 2.0 möglich. Jedoch kommt es zu
gewissen Informationsverlusten, die durch ergänzende Maßnahmen minimiert werden
könnten. Bei der Transformation der Referenzmodelle von Scheer und Becker &Schütte
wurde auf Pools und Lanes verzichtet, da der Ordnungsrahmen, die die Autoren nutzen,
die einzelnen Prozesse den jeweiligen Abteilungen zuordnen und die Abteilungs- bzw.
Unternehmensübergreifende Kommunikation grobgranular aufzeigen. Scheer nutzt die
Vorgangskettendiagramme, um die gesamte Kommunikation zwischen den einzelnen
Prozessen und Abteilungen aufzuzeigen, welche jedoch nicht ausreichen, um Pools und
Lanes darstellen zu können. Schütte nutzt Prozessschnittstellen in seinen Modellen,
um die abteilungsübergreifende Verbindung herzustellen. Das Handels-H-Modell ist im
Vergleich zum Y-CIM-Modell besser mit den einzelnen Referenzmodellen innerhalb der
Ordnungsrahmen verknüpft. Desweiteren wurden bei einigen Referenzmodellen kleine
Verbesserungen durchgeführt wie das Einfügen von Endereignissen, um die BPMN
2.0 Konformität herzustellen (siehe dazu Kapitel 5). Außerdem sind Namenskonventio-
nen bei Aktivitätsbeschreibungen nicht eingehalten worden, sodass Aktivitäten nicht
durch Verben ausgedrückt und Ereignisse nicht als Zustand beschrieben wurden. Dieser
Sachverhalt wurde bei der Transformation korrigiert.
Ein weiterer Punkt betrifft die OR-Gateways in EPK-Modellen. Aufgrund der begrenzten
Anzahl an Elementen in EPK werden OR-Gateways häufiger genutzt. Jedoch ist die
Semantik eines OR-Gateways aufgrund der Mehrdeutigkeit problembehaftet. BPMN
2.0 bietet in dieser Hinsicht durch mehrere alternative Gateways, die Möglichkeit OR-
Gateways zu vermeiden. Jedoch wurden manche bei der Transformation übernommen,
da die Semantik der Modelle dadurch verändert werden würde und aus den Beschrei-
bungen dies nicht hervorging.
Zusammengefasst besteht die Referenzmodellierungsforschung aus sehr vielen einzel-
nen Insellösungen, die sich schwer mit vorhandenen Ergebnissen verknüpfen lassen.
95
6. Diskussion
Viele der vorhandenen Arbeiten basieren auf frühere Veröffentlichungen deren Methodik
übernommen wurden. Im Bereich von BPMN 2.0 gibt es sehr wenige Ansätze und keine
praktischen Modelle. Die Transformation erweist sich als sehr aufwendig und zeitintensiv.
96
7
Zusammenfassung und Ausblick
Dieses Kapitel schließt die Arbeit, fasst die wichtigsten Erkenntnisse zusammen und
bietet einen Ausblick über mögliche Arbeitsbereiche. Sie wird rückblickend auf die
einzelnen Bereiche eingehen und die Ergebnisse aufzeigen.
7.1. Zusammenfassung
Diese Arbeit beschäftigte sich mit der Transformation von Referenzmodellen in EPK nach
BPMN 2.0. Dabei wurden die einzelnen Bereiche der Referenzmodelle und ihrer Model-
lierung zuerst vorgestellt und erläutert. Dabei kamen die verschiedenen Aspekte und
Konzepte der Referenzmodelle zum Vorschein. Das durch die Fachliteratur erworbene
97
7. Zusammenfassung und Ausblick
Fachwissen wurde daraufhin für die Analyse und die Transformation der Referenzmodel-
le genutzt. Vor der eigentlichen Transformation wurde ein Konzept entwickelt und die
einzelnen Referenzmodelle betrachtet. Das Konzept beinhaltete eine Vorgehensweise,
die die Transformation systematisierte. Dabei wurden die Referenzmodelle zuerst ausge-
wählt, Anforderungen definiert, Transformationsregeln abgeleitet und die Transformation
durchgeführt. Die transformierten Referenzmodelle wurden validiert und die Erfahrungen
dokumentiert.
Außerdem erfolgte eine Analyse der beiden Modellierungssprachen EPK und BPMN
2.0. Dabei wurden das Bunge-Wand-Weber-Modell und die Workflow-Patterns kurz
vorgestellt und Ergebnisse aus vorherigen Forschungen vorgestellt. Im Vergleich zu EPK
zeigte sich die BPMN 2.0 Beschreibungssprache ausdrucksstärker und stellt dem Mo-
dellierer mehr Möglichkeiten und Diagrammtypen zur Verfügung. Im Diskussionskapitel
wurden auf diese Punkte eingegangen, die die gewonnen Erkenntnisse kritisch würdigen
und mögliche Schwächen aufzeigen. Außerdem wurde innerhalb des Diskussionskapi-
tels auf die einzelnen Themengebiete eingegangen.
Die Transformation erfolgte, unter gewissen Informationsverlusten, erfolgreich. Informati-
onsverluste entstehen bei der Transformation durch die unterschiedlichen Zielsetzungen
der einzelnen Modellierungssprachen. Die EPK, welches Unternehmensabläufe durch
Funktionen und Ereignisse abbildet, stellt die fachliche Ebene und die Ereignisse in den
Vordergrund. Im Vergleich dazu stehen bei BPMN 2.0 die Aktivitäten der fachlichen Ebe-
nen im Vordergrund. Ein weiterer Punkt für die Informationsverluste war die aggregierte
Darstellung der Referenzmodelle und die kompakte Darstellung ihrer Abläufe. Die kom-
pakte Darstellung führte zwangsweise zur Verknüpfung unterschiedlicher Informationen
in einem Modell, welches nicht immer eine äquivalente Darstellung in BPMN 2.0 hatte.
98
7.2. Ausblick
7.2. Ausblick
Mit dem Abschluss der Arbeit ist das Thema der Transformation von Referenzmodellen in
EPK nicht abgeschlossen. Die zunehmende Bedeutung von Geschäftsprozessen inner-
halb von Unternehmen und die steigende Komplexität von Unternehmensstrukturen führt
zu einer steigenden Nachfrage nach Best-Practice bzw. Common-Practice-Lösungen.
In diesem Bereich haben Referenzmodelle großes Potenzial. Durch Ihre vordefinierten
Modelle können sie Unternehmen innerhalb von Business Process Management un-
terstützen und so die Entstehung von Fehlern minimieren. Sie sind desweiteren dazu
geeignet als Wissensspeicher zu dienen und beim Aufbau von neuen Strukturen als
bewährte Basis zu dienen. Nichtsdestotrotz ist weiterer Forschungsbedarf vorhanden,
um diese Potenziale nutzen zu können.
Dabei sollten im Bereich der Standardisierung, Beschreibungssprachen und empirischer
Ergebnisse geforscht werden. Standardisierung der Beschreibungen und Darstellungen
von Referenzmodellen kann zu einer größeren Verbreitung und Nutzung führen. Die
heutigen „Insellösungen“ verhindern eine weite Verbreitung aufgrund der Vielzahl an
Methoden und Konzepten. Wenn es einen Standard geben würde, würden Erfahrungen
aus verschiedenen Referenzmodellen genutzt und ausgetauscht ohne Informationsver-
luste in Kauf nehmen zu müssen. Die Beschreibungssprachen sollten ausführlich für
den Einsatz bei Referenzmodellen untersucht werden. Dabei sollte nicht nur die Syntax
sondern auch die Semantik und die Meta-Modelle der Sprachen untersucht werden.
Objektorientierte Sprachen sollten dabei nicht vernachlässigt werden. Die Forschung
sollte sich auf empirische Ergebnisse fokussieren und praktische Modelle zur Verfügung
stellen. Innerhalb der veröffentlichten Referenzmodelle gab es keine die mit BPMN 2.0
modelliert wurden. Diese Lücke sollte geschlossen werden, um weitere Erfahrungen
über den Einsatz von BPMN 2.0 innerhalb von Referenzmodellen gewinnen zu können.
Dabei sollten Konzepte für den Einsatz von BPMN 2.0 innerhalb von Referenzmodellen
und ihre Gestaltungsmöglichkeiten entwickelt werden.
99
A
Übersicht vorhandener Referenzmodelle
101
RMK - Reference Modeling Catalog
http://rmk.iwi.uni-sb.de/show_searched_model.php[26.11.2014 12:33:50]
Contact Imprint
Project
Reference Model
Catalog
Browsing
Simple Search
Expert Search
Reference Model
Proposal
Publications
Intern
Supported by
Search Results
Type Name Domain
Generic Type Insurance Application
Architecture,
Versicheru... Institution: Insurer
Generic Type SCOR,
Supply Chain Operations
Reference Model Function: Supply Chain Management
Generic Type SKO-Data Model
("Sparkassenorganisation"-
Data M...
Institution: German Savings Banks
("Sparkassen")
Generic Type R/3 Reference Model,
R/3 Business Blueprint no statement
Generic Type Reference Model of
Mertens/Griese Institution: Industrial Enterprise
Generic Type ITIL,
Information Technology
Infrastructure Li... Function: IT-Management
Generic Type Reference Model of
Warnecke/Gissler/StammwitzFunction: Knowledge Management
Generic Type Schlagheck's Reference
Model Function: Controlling
Generic Type R?ffer's Reference Model Institution: Primary Insurer at the
Example of ...
Generic Type Remme's Reference Model Others: Management Organization
Generic Type Pumpe's Reference Model Institution: Seaport Container Terminal
Generic Type Kruse's Reference Model Function: Distribution Logistic
Generic Type Kr?mker's Reference Model Institution: Creation of Offers for
Unicums and...
Generic Type Herrmann's Reference Model Others: Reliability Requirements for
Business P...
Generic Type Reference Model of
Haas/Ahlemann/Hoppe Function: E-Learning Processes in
Enterprises
Generic Type Virtual Branch Bank
("Virtuelle Bankfiliale") Institution: Branch Business of Banks
Generic Type Buchwalter's Reference
Process Model Function: Electronical ITB-Systems in
Procurement
Generic Type PROMET I-NET Reference
Model Others: Intranet Conception
Generic Type ECOMOD - Reference
Business Processes and
Strat... Function: E-Commerce
Generic Type ECO-Integral Function: Environmental Management
Generic Type "Aachener PPS"-Model,
Aachen PPC-Model Function: Production, Planning and
Control Syst...
Generic Type Baan Reference Model no statement
RMK - Reference Modeling Catalog
http://rmk.iwi.uni-sb.de/show_searched_model.php[26.11.2014 12:33:50]
Generic Type
Tzouvaras's Reference
Model
Institution: Service Processes at Book
Publishers
Generic Type Schwegmann's Reference
Model Function: Warehouse Management
Generic Type Kluger's Reference Model,
Reference Model for ... Function: Vehicle-based Transport
System
Generic Type Process Framework of
Siemens AG Others: Development of Information and
Communic...
Generic Type "Handels-H"-Model Institution: Enterprises doing Commercial
Funct...
Generic Type Y-CIM Model Institution: Industrial Enterprise
Generic Type Schaich's Reference Model Object: Production Machinery
Generic Type IOOP Reference Model Function: Production Planning and
Control Systems
Generic Type Common Warehouse
Metamodel (CWM) Others: Data Warehousing
Generic Type RefModPM,
Ahlemann's Reference
Model
Function: Project Management and
Project Portfo...
Generic Type SKO-Reference Process
Model
("Sparkassenorganis...
Institution: German Savings Banks
("Sparkassen")
Generic Type CobiT,
Control Objectives for
Information and ... Function: IT-Management
Generic Type ITPM,
IBM IT Process Model Function: IT-Management
Generic Type HP ITSM,
HP IT Service Management
Reference Mo... Function: IT-Management
Generic Type Specks' Construction
Patterns no statement
Generic Type Bauer's Reference Model Institution: Mass Information Systems at
Financ...
Generic Type Dobrindt's Reference Model Function: Accounting in Higher
Education Instit...
Generic Type Brettschneider's Reference
Model Operational Learning Environment
Generic Type Hoffmann's Reference
Model,
QIS Reference Model Function: Quality Information System
Generic Type Ohlendorf's Reference Model Function: Production, Planing and
Control; Acco...
Generic Type Schildheuer's Reference
Model,
QIS Reference M... Function: Quality Information System
Generic Type Schl?gl's Reference Model Function: Production Simulation
Generic Type Simoneit's Reference Model Institution: Hospital
Generic Type IS-H Reference Model Institution: Hospital
Generic Type Business Engineering
Reference Model Others: Business Engineering
Generic Type IAA,
IBM Insurance Application
Architecture Institution: Insurer
Generic Type Reference Model
Manufacturing Systems Simulation of Manufacturing Systems
Generic Type RM-ODP,
Reference Model of Open Others: Open Distributed Processing
RMK - Reference Modeling Catalog
http://rmk.iwi.uni-sb.de/show_searched_model.php[26.11.2014 12:33:50]
Distributed Pr...
Generic Type OMA,
Object Management
Architecture Others: Open Distributed Processing
Generic Type Lang's Reference Process
Building Block Library... Function: Order Processing
Generic Type Lang's Generic Reference
Process Building Block... Others: Elementary Process Solutions
Generic Type Otto's Reference Model Others. Cross-enterprise Procurement
Processes
Generic Type E-Start Reference Model Function: Supplier Relationship
Management
Generic Type Spang's Reference Model Function: Investment Goods' Marketing
Generic Type Jost's Reference Model Institution: Industrial Enterprise
Generic Type Rautenstrauch's Reference
Mode Institution: Industrial Enterprise
Generic Type Kurbel's Reference Model Institution: Industiral Enterprise
Generic Type Reference Model of
Lindemann/Schmid Others: Electronic Market Systems
Generic Type Luxem's Reference Model Institution: Enterprises doing Commercial
Funct...
Generic Type MPRM,
Mobile Payment Reference
Model Others: Mobile Payment Procedures
Generic Type Silverston et al.'s Universal
Data Models
Universal Data Models for Several
Domains,
Ins...
Generic Type Reference Architectures of
Lockemann, and Dittr... Architectures for Database Management
System
Generic Type Sch?nsleben's Reference
Model Institution: Industrial Enterprises
Generic Type Rohloff's Reference Model Function: Production, Planning, and
Control Sys...
Generic Type Rottwinkel's Reference
Model Function: Coordination of Contacts of
Partners ...
Generic Type Vering's Reference
Procedure Model Procedure for Selecting Merchandising
Informati...
Generic Type Hay's Data Model Patterns Open
Generic Type Fowler's Analysis Patterns Open
Generic Type Meise's Order Framework
Procedure Model Reorganization Projects
Generic Type Marent's Reference Model Institution: Enterprises doing Commercial
Funct...
Generic Type Remmert's Reference Model Function: Interoganizational Logistic
Processes...
Generic Type Scharl's Reference Model Mass Information Systems for the World
Wide Web
Generic Type K?bernik's Reference Model Function: Job Shop Scheduling
Generic Type PRO-NET Reference Model Function: Cross-enterprise Order
Processing in ...
Generic Type Wirtz's Reference Model Function: Product Data Management
Generic Type Brenner's Reference Model,
Reference Meta Mode... Business Engineering
Generic Type Winter's Reference Model,
Reference Schema fo ... no statement
Generic Type Umeda's Reference Model Institution: Industrial Enterprise
Reference Model of
RMK - Reference Modeling Catalog
http://rmk.iwi.uni-sb.de/show_searched_model.php[26.11.2014 12:33:50]
Generic Type Rine/Nada
Software Reuse Re...
Software Development Using Software
Reuse
Generic Type Bayrak's Reference Model Function: Ratio-based Logistic Control
Generic Type Boles's Reference Model of
Digital Libraries Digital Libraries
Generic Type Boles's Reference Model of
eMall Systems eMall Systems
Generic Type Boles's Reference Model of
Digital Shop respect... Shop or Mall Information Systems for
Selling Di...
Generic Type Coper (Components for
Project Management
Experi...
Developing Project Management
Experience Base
Generic Type Reference Model of KoopA
for Task Processing in... Function: Task Processing in Public
Administrat...
Generic Type Reference Model of
Carpinetti/Buosi/Ger?lamo Function: Process of Quality
Management and Imp...
Generic Type Reference Framework of
Fernandes/Duarte Institution: Software Development
Organizations
Generic Type Reference Model of
Remus/Schub Process-oreinted Knowledge
Management
Generic Type Dorp's Reference Model Function: Tracking and Tracing of
Production Ac...
Generic Type Loos's Reference Model for
Manufacturing Function: Manufacturing in Industrial
Enterprises
Generic Type Goeken's Reference Model Executive Information System
Generic Type Reference Model of After-
Sales-Services Function: After-Sales-Services
Generic Type Referenzmodell f?r IT-
Service Informationssyste...
Generic Type Referenzmodell f?r die
Koordination von Prozess...
Generic Type eTOM, enhanced
Telecommunications
Operations Map Institution: Telecommunications
Generic Type DIN SPEC 1041 Outsourcing
technologieorientiert... Outsourcing
The reference models including all their attributes can be displayed in table format.
B
Transformierte Modelle in BPMN 2.0
107
1- EPK der Bedarfsauflösung (Scheer)
Methode Net-
Change oder
Neuentwurf
auswählen bzw.
analysieren
Aufgaben auf
Sachbearbeiter
aufteilen
Bruttobedarf
berechnen
Lagebestand
ermitteln und
reservieren
Nettobedarf
berechnen
Lose / Aufträge
für die
Disposition
bilden
Termine der
Lose üperprüfen
Vorwärts
terminieren der
Lose
Sekundarbedarf
berechnen
Sekundarbedarfrechnung
durchgeführt ?
Lieferung geändert
Stückliste geändert
Betriebsstörung aufgetreten
Planungszeitpunkt erreicht
Originärer Bedarf aufgetreten
Freigabe der Lose für Sekundarbedarfsrechnung
Termin in der Vergangenheit
Neu-Entwurf
Net-Change
Ja
Nein
2- EPK der Auftragsdatenergänzung
(Scheer)
Auftrag geändert
Arbeitsplan geändert
Betriebsstörung aufgetreten
Methode Net-
Change oder
Neuentwurf
analysieren und
auswählen
Aufgaben auf
Sachbearbeiter
aufteilen
Arbeisplan
auswählen
Werk auswählen
Arbeitsgangrei-
henfolge
auswählen
Arbeitsgang
auswählen
Arbeitsplatzgrup-
pe auswählen
Prüfung, ob
weitere
Arbeitsgänge
vorhanden
druchführen
Ja
Nein
Net-Change
Neuentwurf
3- EPK der Zeit und Kapazitätsplanung
(Scheer)
Stücklistenänderung aufgetreten
Verfahrensänderung aufgetreten
Organisatorische Änderung aufgetreten
Grunddaten der
Arbeitspläne ändern
Betriebsstörung aufgetreten
Auftragsänderung durchgeführt
Methode Net-
Change oder
Neuentwurf
analysieren und
auswählen
Aufgaben auf
Sachbearbeiter
aufteilen
Auftragsdaten
ergänzen
Zeitrechnung
durchführen
Arbeitsgänge zu
Kapazitäten und
Belastungsrechnung
zuordnen
Kapazitätsüberschreitung?
Automatischer
oder interaktiver
Kapazitätsab-
gleich auswählen
Kapazitätsab-
gleich Interaktiv
durchführen
Algorithmus
starten
Überprüfung des
Auftragsnetzes auf
Konzequenzen
Neuentwurf
Net-Change
InteraktivAutomatisch
Nein
Ja
4- EPK der Beschaffungslogistik
(Scheer)
Planungszeitpunkt der
Nettobedarfsrechnung erreicht
Änderungen im Net-Change
Bedarfsmeldung der Fachabteilung
Bestellanforde-
rungen
bearbeiten,
Kostenstelle
kontieren
Lieferanten
anfragen
Angebote eingetroffen
Lieferant
Grunddaten
aktualisieren
Lieferant und
Bestellmenge
ermitteln; Pro-
Forma-
Rechnung
erstellen
Bestellung
erstellen und
übermittelln
Auftragsbestätigung
Bestellung
überwachen /
monitoren
Liefertermin gefährdet?
Mahnung
erstellen
Bestellung eingetroffen
Qualitätsprüfung
durchführen
Wareneingang
buchen
Rechnung eingetroffen
Prüfung OK?
Reklamation
erstellen
Wareneingangsda-
ten korrigieren
Rechnung
überprüfen
Rechnung OK?
Rechnung
korrigieren
Rechnung
buchen
Ware an Lager
verteilen und
buchen
Rechnungsüperprüfung setzt voraus das die
buchhalterische Buchung und Rückmeldung aus
der Qualitätsprüfung vorhanden sind
AND-Gateway für
die
Übersichtlichkeit
Angebote sind aktuell
Neues Angebot erforderlich (nicht aktuell)
Ja
Nein
Nein
Ja
Nein
Ja
5- EPK des Vertriebsablaufs (Scheer)
Kundenanfrage erhalten
Verkaufsaktion
Angebot
anfertigen
Angebot
absenden
Angebot
überwachen
Kundenauftrag eingetroffen
Verfügbarkeits-
prüfung
durchführen
Grunddaten
aktualisieren
Auftragsbestätigung
Reservierung
durchführen
Artikel auslagern
Buchungen
durchführen
Produktionsauf-
trag anlegen
Produktionsauf-
trag überwachen
Artikelqualität
überprüfen
Qualität OK?
Transportres-
sourcen
bereitstellen
Versandpapiere
erstellen
Transport
anzeigen
Transport
durchführen
Rechnung
erstellen
Rechnung
buchen
Kundenmahnung eingetroffen
Nein
Ja
6- EPK der Produktentwicklung
(Scheer)
Produkt(-änderungs) Vorschlag Marketing
Produkt(-änderungs) Vorschlag Konstrutkion
Produkt(-änderungs) Vorschlag Beschaffung
Produkt(-änderungs) Vorschlag Produktvorbereitung
Produkt(-änderungs) Vorschlag Qualitätssicherung
Produkt(-änderungs) Vorschlag Betriebsmittelbau
Produkt(-änderungs) Vorschlag Produktion
Produkt(-änderungs) Vorschlag Service
Produkt(-änderungs) Vorschlag Kalkulation
Grobentwurf
erstellen
Prüfung ob
kundengerecht
Prüfung ob be-
schaffungsge-
recht
Prüfung, ob ferti-
gungsgerecht
Prüfung
qualitätsgerecht
Prüfung ob
kostengerecht
Prüfung ob
Servicegerecht
Prüfung ob
recyclegerecht
Prüfung positiv?
Detailentwurf
anfertigen
Detailentwurf vorhanden?
Dokumentation
erstellen
Nein
Ja
JaNein
7- EPK Lieferantenstammdatenpflege
(HModell)
Angebot
einholen
Angebot eingetroffen
Verbraucher fragen Ware nach
eines Bestimmten Lieferanten nach
Lieferant auf der
Messe
auswählen
Fachliche Liefe-
rantenüberprü-
fung
durchführen
Lieferant annehmen?
Lieferatnenver-
handlung
durchführen
Lieferantentyp
bestimmen
Unternehmen
bestimmen
Einmal Lieferant,
Warenlieferant,
ohne logistische
Funktion
Lieferantenrollen
bestimmen
Lieferantensich-
ten bestimmen
Prüfung ob LTS
anzulegen ist
durchführen
Lieferantenteile-
sortiment (LTS)
Daten wie
Logistik,
Beschaffung,
Allgemein
Anlegen?
LTS anlegen
Prüfung
Konditionspflege
durchführen
Konditionspflege notwendig?
HModell Konditionspflege
Ja Nein
Ja
Nein
Nein
Ja
8- EPK Artikelstammdatenpflege
(HModell)
Artikel ist ins
Sortiment aufzunehmen
Onlineverfügbar-
keit der Daten
prüfen
Online Verfügbar?
Grunddaten
online abrufen
Stücklistenartikel anlegen?
Stücklistenartikel
anlegen Einzelartikel vorhanden?
Lege
Einzelartikel an
Einzelartikel und
Mengen
bestimmen
Einzelartikel
anlegen
Grunddaten
anlegen
Artikelpflege ist erforderlich
Zu pflegende
Sichten
bestimmen
Einkaufsdaten-
pflegen
Logistikdaten
pflegen
Verkaufsdaten
pflegen
Prüfung weiterer
Verzweigungen
auf andere
Prozesse
durchführen
HModell Konditionspflege
Aufteileranlage
Artikellistung
Ja
Nein
Nein
Ja
JaNein
9- EPK Konditionspflege (HModell)
Konditionsänderung aufgetreten
HModell Artikelstammdatenpflege
HModell Lieferantenstammdatenpflege
HModell Aktionsplanung
Konditionen sind
zu pflegen
Kalkulationssche-
ma pflegen
Lege Abzugsrei-
henfolge fest
Kondition
Anpassungen
sind zu prüfen
Anpassung notwendig?
Vertiebskonditi-
on Anpassungen
prüfen
Vertriebsspezifische Anpassung notwendig?
Kondition für
Vertriebs.
bestimmen
Abnehmerkonditi-
on Anpassung
prüfen
Abnehmerkondition ist anzupassen?
Abnehmerspezifi-
sche Kondition
bestimmen
Konditionkalkula-
tionsrelevanz
prüfen
Relevant?
Berechnungs-
grundlage
bestimmen
Verzweigung zu
Aktionsplanungs-
prozess prüfen
Verzweigung notwendig?
Konditionstyp
bestimmen
Zu Aktionspla-
nungsprozess
verzweigen
Disposition mehrstufig
Ja
Ja
Ja
Nein
Nein
Nein
Ja
Nein
NeinJa
Rechnungskondition
10- EPK mehrstufige Disposition
(HModell)
HModell Konditionspflege
Abnehmer der
bestellt prüfen
Disposition
Lager
Disposition
Filiale/Kunde
Wareneingang Filiale / Kunde
Bestellmengen-
verdichtung
überprüfen
Bestellung verdichten?
Bestellmengen
verdichten Anlegen des
Aufteilers prüfen
Aufteiler anlegen?
Aufteileranlage
Notwendigkeit
des Lieferanten-
auswahls
überprüfen
Lieferantenauswahl erforderlich?
Lieferant
auswählen
Liegt ein
Rahmenvertrag
vor?
Kontrakt
auswählen
Art der
Bestellauflösung
bestimmen
Bestellung
erzeugen
Bestellung
übermitteln
Prüfung bei
welchem
Abnehmer der
Wareneingang
zu erwarten ist
durchführen
Wareneingang Lager
Wareneingang Filiale / Kunde
Nein
Ja
Ja
Nein
Ja
Nein
11- EPK Wareneingang Lager (HModell)
HModell mehrstufige Disposition Avisierung notwendig?
Avisierung
überprüfen
Avisdaten
erfassen
Desadv
übermitteln
Bestellung mit
Avisdaten
vergleichen Differenz vorhanden?
Differenzmel-
dung an
Wareneingang
übermitteln
Normale Waren-
eingangsbearbei-
tung
durchführen
Fahrer hat sich im WE
gemeldet
Warenlieferung
identifizieren
Bestellung vorhanden?
Disponenten
benachrichtigen
Entscheidung
über Annahme
treffen Lieferung annehmen?
Wareneingang
über Ablehnung
der Lief.
benachrichtigen
Bestellung
erstellen
Wareneingang
über Bestellung
benachrichtigen
Rampe ermitteln Überprüfung Lie-
ferscheinanga-
ben
Prüfung ob
Recadv-Versand
durchführen Versenden?
Recadv senden
MTV Abwicklung
durchführen
Prüfung auf Liefe-
rantenretoure
durchführen Lieferanten retoure?
Retoure an den
Lieferanten
Prüfung ob
Lieferant
Leergut abholt
durchführen Leergut wird abgeholt?
Einlagerung der Ware
Leergutretoure an den Lieferanten
Ja
Ja
Nein
Nein
Nein
NeinJa
Ja
Nein
Ja
Nein
Ja
Nein
Nein
Ja
12- EPK Rechnungsprüfung (HModell)
Rechnungserfassung
Warenbewertung
Aktionsabwicklung
Rechnung freigegeben
Belege sortieren
Rechnung bew.
Wareneingang
zuordnen
Zuordnung möglich?
Vorgänge
manuell
zuordnen
Auf
vorhandene Dif
ferenzen zw.
Rechnung und
Wareneingang
prüfen
Differenz innerhalb
Toleranz?
Ursache
analysieren Abweichungsk
ontrolle
Kreditorische
Nachbearbeitu
ng prüfen
Nacharbeit notwendig?
Rechnungsnac
hbearbeitung
Rechnung
archivieren
Prüfung auf
Diff. in
Bestandsbewe
rtung zu
buchen durchf.
Prüfung auf
stat.
Fortschreibung
für nachtr.
Verg. durchf.
Prüfung auf
Sofortzahlung
durchführen
Differenz buchen?
Warenbewertung
Fortschreibung notwendig?
Abrechnung nachtr. Vergütung
Sofortzahler?
Zahlsperre aus
offenen Posten
löschen
Zahlungsausgangsbuchung
Lieferant
Ja
Nein
Ja
Nein
Ja
Nein
Nein
Ja Ja
13- EPK Artikelstammanlage
(Logistikdaten) (HModell Konf)
Art der
Bestandsführu
ng ermitteln
Wertmäßig
Bestandsführung?
Logistische
Einheit für
Lager festlegen
Mengenmäßige
Bestandsführung
Relevante
Dispositionsart
ermitteln
Automatische
Disposition?
Dispomaterial manuell oder
prognosebasiert setzen?
Prognosemode
ll auswählen
Dispositionsve
rfahren
bestimmen
Bestellpunktpa
rameter
festlegen
Bestellrhytmus
parameter
festlegen
Bestellrhytmusd
isposition oder
Bestellpunktdis
position
Relevante
Automatisierun
gsart ermitteln
MHD Relevanz
des Artikels
prüfen
MHD Relevant?
Min. MHD / min
Restlaufzeit
festlegen
Relevanz
Lageranforder
ungen prüfen
Relevant?
Relevante
Lageranforder
ungen ermitteln
Temperaturbe
dingungen
festlegen
Lagerraumbedi
ngungen
festlegen
Artikelanlage Bestandführungsprüfung
Lageranforderungen
Ja
Nein
Ja
Nein Nein
Ja
Nein
Ja
14- EPK Artikelstammanlage
(Grunddaten) (HModell Konf)
Verfügbare
Quellen für
Grunddaten
prüfen
Online verfügbar?
Online Medium
für
Grunddaten pr
üfen
Anlegen eines
strukturierten
Artikels
überprüfen
Relevanten
Artikel aus St.-
pool selektieren
Relevante
Artikel aus
Datei selektiere
Selektierte
Artikel aufrufen
Stammdatenpool
Datei aus
bilaterale
n Austau
sch
Zuordnung der
WGr
durchführen
Zuordnung der
Farbe
durchführen
Zuordnung der
Größe
durchführen
Einzelartikel
anlegen?
Prüfung auf
vorhandene
Einzelartikel
durchführen
Strukturierter
Artikel anlegen
Vorhanden?
Einzelartikel
anlegen
Mengengerüst
der
Einzelartikel be
stimmen
Grunddaten
manuell anlegen
Ersatzartikel
mit
Zugrifffolge zu
ordnen
Pflege Artikelsichten
Nein
St.-poolbilateral
Ja
Nein
Nein
Ja
Ja
15- EPK Auftragsbearbeitung (Kruse)
Vertriebssachbearbeiter / Außendienst
Vertriebssachbearbeiter / Außendienst
Kundenauftrag
Auftrag erfassen
Auftrag
vollständig?
Auftragsablauf-
steuerung
festlegen
Auftragsart?
Rahmenverträge
verwalten
Reklamations
bearbeiten
Exportabwick-
lung
durchführen
Normalauftrags-
bearbeitung
durchführen
Unternehmen
Vertrieb
Vertrieb
Vertrieb
Preisermittlung starten?
Artikelpreise
ermitteln
Bonitätsprüfung
starten
Bonität ok?
Auftrag
ablehnen
Liefertermin
ermitteln
Verfügbarkeits-
überprüfung
durchführen
Ware vollständig
verüfgbar?
Teillieferung
planen
Kontingentie-
rung planen
Ersatzliefe-
rung planen
Lieferückstände
verwalten
Fertigungsauf-
trag erstellen
Ware bestellen
Ware
umdisponieren
Ware reservieren
Auftragsbestäti-
gung erstellen
Nein
Ja
Nein
Ja
Ja Nein
Ja
Nein
16- EPK Versandbearbeitung (Kruse)
Versandfälligkeit
erreicht
Rückstandsauflösung
starten
Bei Fehlmengenlie-
ferungen
Lieferschein
erstellen
Verfügbarkeits-
prüfung
auslösen
Versandterminie-
rung auslösen
Lagerplatzermitt-
lung auslösen
Packstückermitt-
lung auslösen
Vollständig
verfügbar?
Teillieferung
veranlassen
Frachtraumbe-
darfsplanung
starten
Kommissionierab-
laufsteuerung
ermitteln
kommissionieren
Transport
planen und
Fracht
berechnen
Transportdaten
übermitteln
Beladeplanung
erstellen
Kommissionierung
vollständig?
Verpackungsab-
laufsteuerung
starten
Waren
verpacken
Warenausgangs-
kontrolle
durchführen
Verladerampe
ermitteln
Waren Ok?
Waren verladen Versandpapiere
drucken
Warenausgang
buchen
Fakturierung
Ja
Nein
Nein
Nein
Ja
17- EPK Fakturierung (Kruse)
EPK Kruse Versandbearbeitung
Fakturablauf-
steuerung
festlegen
Preisfindung
starten
Gut/Lastschrift-
bearbeitung
starten
Rechnungstyp
ermitteln
Proforma Rech-
nungserstellung
starten
Rechnung
erstellen
Rechnungsdaten
übermitteln
Kontenfindung
starten
Konto ermittelt?
Warenlieferung
verbuchen
Rechnungsstor-
nierung einleiten
Warenausgang
gebucht
Kommissionierung
beendet
Auftrag
vollständig
Ja
Nein
18- EPK Wareneingang (Kruse)
Wareneingang zur
Rückstandauflösung
Retoureneingang
Wareneingang Umlagerung/
Wiederauffüllung
Abladestelle
ermitteln
Ware entladen
Datenerfassung
Warenidentifikati-
on starten
Wareneingangs-
prüfung
durchführen
Daten korrekt?
Ware fehlerfrei?
Abweichungsbe-
arbeitung
starten
Warenrücksen-
dung
durchführen
Nachbearbeitung
durchführen
Verschrottung
durchführen
Fertigungsauf-
trag generieren
Verkauf 2. Wahlt
veranlassen
Nachbestellung
durchführen
Wareneingang
buchen
Retoureabwick-
lung
durchführen
Einlagerungsab-
laufsteuerung
starten
Ware einlagern
Rückstände
auflösen
Lagerplatz
zubuchen
Wareneingang
Produktion
Nein
Ja
Nein
Ja
19- EPK Lieferant-Lager (Remmert)
Lagereinheit
Lagereinheit
Nachfrage
Folgeeinheit
Prognosebere-
chung
durchführen
Beschaffungs-
rechnung
durchführen
Bedarf?
Bestellung
übermitteln
Bestellung
Lieferung
erfolgt
Wareneingang /
Retourenabwick-
lung
durchführen
Waren einlagern
Lieferant
Lieferant
Bestellung
bearbeiten
Transportpla-
nung /
Steuerung
durchführen
Wareneingangs-
planung
durchführen
Transport
durchführen
Ja
Nein
20- EPK Lager-Filiale (Remmert)
Filiale
Filiale
Bestandsbu-
chung
durchführen
Bestandsrech-
nung starten
Bedarf
vorhanden?
Bestellübermitt-
lung starten
Retouren
erfassen
Bestellung
Anlieferung erfolgt
Retourenrückga-
be
Wareneingang
erfassen
Bestellung
einlagern, Regale
bestücken
Lager
Lager
Bestellung
Bestellung
bearbeiten
Kommissionie-
rung planen
Transport planen
Bestellung
kommissionieren
Bestellung
transportieren
Transport erfolgt
Ja
Nein
Literaturverzeichnis
[All98]
ALLWEYER, Thomas:
Adaptive Geschäftsprozesse: Rahmenkonzept und
Informationssysteme
. Wiesbaden : Gabler, 1998 (Schriften zur EDV-
orientierten Betriebswirtschaft). – ISBN 9783409123259
[ATW+15]
AYORA, Clara ; TORRES, Victoria ; WEBER, Barbara ; REICHERT, Man-
fred ; PELECHANO, Vicente: VIVACE: A Framework for the Systematic
Evaluation of Variability Support in Process-Aware Information Systems.
In:
Information and Software Technology
57 (2015), January, 248–276.
http://dbis.eprints.uni-ulm.de/1058/
[BBM+01]
BACK, Andrea ; BECKER, Jörg ; MERTENS, Peter ; KÖNIG, Wolfgang ;
KRALLMANN, Hermann ; RIEGER, B. ; SCHEER, A.W. ; SEIBT, D. ; STAHL-
KNECHT, P. ; STRUNZ, H. u.a.:
Lexikon Der Wirtschaftsinformatik
. Sprin-
ger Berlin Heidelberg, 2001
https://books.google.de/books?id=
KhnQer-rzRgC. – ISBN 9783540423393
[BDK04a]
BECKER, Jörg ; DELFMANN, Patrick ; KNACKSTEDT, Ralf: Adaption fach-
konzeptioneller Referenzprozessmodelle. In:
Industrie Management
20
(2004), Nr. 1, S. 19–22
[BDK04b]
BECKER, Jörg ; DELFMANN, DIPL-WIRT INFORM PATRICK ;
KNACKSTEDT, DIPL-WIRT INFORM RALF: Konstruktion von Refe-
renzmodellierungssprachen Ein Ordnungsrahmen zur Spezifikation von
129
Literaturverzeichnis
Adaptionsmechanismen für Informationsmodelle. In:
Wirtschaftsinformatik
46 (2004), Nr. 4, S. 251–264
[Bec]
BECKER, Jörg:
Die Grundsätze ordnungsmäßiger Modellierung und ih-
re Einbettung in ein Vorgehensmodell zur Erstellung betrieblicher Infor-
mationsmodelle
.
http://www.wi-inf.uni-duisburg-essen.de/
MobisPortal/pages/rundbrief/pdf/Beck98.pdf
[Bec04]
BECKER, Jörg:
Referenzmodellierung: Grundlagen, Techniken und do-
mänenbezogene Anwendung ; mit 6 Tabellen
. Heidelberg : Physica-Verl.,
2004. – ISBN 978–3–7908–0245–0
[BG03]
BROCKE, J.V. ; GROB, H.L.:
Referenzmodellierung: Gestaltung und Ver-
teilung von Konstruktionsprozessen
. Logos-Verlag, 2003 (Advances in in-
formation systems and management science).
http://books.google.
de/books?id=5wV2Ol2Cw4gC. – ISBN 9783832501792
[BKR00]
BECKER, Jörg ; KUGELER, Martin ; ROSEMANN, Michael:
Prozessmana-
gement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung
.
Zweite, korrigierte Auflage. Berlin, Heidelberg : Springer Berlin Heidelberg,
2000. – ISBN 3662095351
[BRR99]
BECKER, Jörg ; ROSEMANN, Michael ; REINHARD, Schütte.:
Referenz-
modellierung: State of the art und Entwicklungsperspektiven : mit 6 Tab
.
Heidelberg : Physica-Verl, 1999. – ISBN 978–3–7908–1149–0
[BS04]
BECKER, J. ; SCHÜTTE, R.:
Handelsinformationssysteme
. mi-
Wirtschaftsbuch, 2004 (Redline Wirtschaft bei moderne industrie).
https://books.google.de/books?id=LbXrCQ-aIcUC
. – ISBN
9783636031440
[Bun77]
BUNGE, Mario:
Treatise on Basic Philosophy
. Bd. 3:
Treatise on Basic
Philosophy: Ontology I: The Furniture of the World
. Dordrecht : Springer
Netherlands, 1977. – ISBN 978–94–010–9924–0
130
Literaturverzeichnis
[CA09]
CARDOSO, Jorge ; AALST, WIL VAN DER:
Hanbook of research on busi-
ness process modeling
. Hershey and New York : Information Science
Reference, 2009. – ISBN 1605662895
[Dav13]
DAVENPORT, Thomas H.:
Process innovation: reengineering work through
information technology. Harvard Business Press, 2013
[DLMR13]
DUMAS, Marlon ; LAROSA, Marcello ; MENDLING, Jan ; REIJERS, Ha-
jo A.:
Fundamentals of Business Process Management
. Berlin, Hei-
delberg : Springer Berlin Heidelberg, 2013.
http://dx.doi.org/
10.1007/978-3-642-33143-5
.
http://dx.doi.org/10.1007/
978-3-642-33143-5. – ISBN 978–3–642–33142–8
[Fet06]
FETTKE, Peter:
Wirtschaftsinformatik - Theorie und Anwendung
. Bd.
Bd. 5:
Referenzmodellevaluation: Konzeption der strukturalistischen Re-
ferenzmodellierung und Entfaltung ontologischer Gütekriterien
. Berlin :
Logos-Verl., 2006. – ISBN 978–3–8325–1446–4
[Fet08]
FETTKE, Peter: Business Process Modeling Notation. In:
WIRTSCHAFTS-
INFORMATIK
50 (2008), Nr. 6, S. 504–507.
http://dx.doi.org/10.
1007/s11576-008-0096-z
. – DOI 10.1007/s11576–008–0096–z. –
ISSN 0937–6429
[Fis00]
FISCHER, Layna (Hrsg.):
Workflow handbook, 2001
. Lighthouse Point,
Fla. : Future Strategies, 2000. – ISBN 978–0970350909
[FL03a]
FETTKE, Peter ; LOOS, Peter: Classification of reference models: a me-
thodology and its application. In:
Information systems and e-business
management 1 (2003), Nr. 1, S. 35–53
[FL03b]
FETTKE, Peter ; LOOS, Peter: Ontologische Evaluierung von Referenzmo-
dellen auf Basis des Bunge-Wand-Weber-Modells-Methode und Anwen-
dungen. In: MobIS, 2003, S. 155–173
131
Literaturverzeichnis
[FLZ06]
FETTKE, Peter ; LOOS, Peter ; ZWICKER, Jörg: Business process reference
models: Survey and classification. In:
Business Process Management
Workshops Springer, 2006, S. 469–483
[FR12]
FREUND, Jakob ; RÜCKER, Bernd:
Praxishandbuch BPMN 2.0
. [s.l.] :
Hanser Fachbuchverlag, 2012. – ISBN 3446429875
[Gad01]
GADATSCH, Andreas:
Management von Geschäftsprozessen
. Wiesbaden
: Vieweg+Teubner Verlag, 2001. – ISBN 978–3–528–05759–6
[Gad04]
GADATSCH, Andreas:
Grundkurs Geschäftsprozess Management
. Wies-
baden : Vieweg+Teubner Verlag, 2004. – ISBN 978–3–528–25759–0
[GF08]
GÖTZER, Klaus G. ; FREUND, Jakob:
Vom Geschäftsprozess zum Work-
flow: Ein Leitfaden für die Praxis
. München : Hanser, 2008. – ISBN
3446418873
[GL13]
GÖPFERT, Jochen ; LINDENBACH, Heidi:
Geschäftsprozessmodellie-
rung mit BPMN 2.0: Business Process Model and Notation
. De Gruy-
ter, 2013
https://books.google.de/books?id=zETpBQAAQBAJ
. –
ISBN 9783486721218
[Gmb13]
GMBH, Bibliographisches I.:
Referenz, die
.
http://www.duden.
de/rechtschreibung/Referenz
. Version:2013. – Letzter Zugriff:
08.03.2015
[Gmb15a]
GMBH, Signavio:
Signavio
.
http://www.signavio.com/de/
.
Version:2015. – Letzter Zugriff: 18.04.2015
[Gmb15b]
GMBH, Signavio:
Signavio
.
http://www.signavio.com/docs/de/
funktionsumfang.pdf. Version:2015. – Letzter Zugriff: 18.04.2015
[GR00]
GREEN, Peter ; ROSEMANN, Michael: Integrated process modeling: an
ontological evaluation. In:
Information Systems
25 (2000), Nr. 2, S. 73–87.
– ISSN 03064379
132
Literaturverzeichnis
[Gro11a]
GROUP, Object M.:
Unified Modeling Language (UML), V2.4.1
.
http://
www.omg.org/spec/UML/
. Version:2011. – Letzter Zugriff: 19.02.2015
[Gro11b]
GROUP, Object M.:
Unified Modeling Language (UML), V2.4.1
.
http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF
.
Version:2011. – Letzter Zugriff: 11.03.2015
[Gro13]
GROUP, Object M.:
Business Process Model And Notation (BPMN)
.
http://www.omg.org/spec/BPMN/index.htm
. Version:2013. –
Letzter Zugriff: 19.02.2015
[GS79]
GANE, Christopher ; SARSON, Trish:
Structured Systems Analysis: Tools
and Techniques
. Englewood Cliffs, N.J. : Prentice Hall, 1979. – ISBN
978–0138545475
[Ham97]
HAMM, Volker:
Informationstechnik-basierte Referenzprozesse: Prozess-
orientierte Gestaltung des industriellen Einkaufs
. Wiesbaden and Wies-
baden : Dt. Univ.-Verl. and Gabler, 1997 (Gabler Edition Wissenschaft). –
ISBN 978–3–8244–6612–2
[Har94]
HARS, Alexander:
Referenzdatenmodelle: Grundlagen Effizienter Daten-
modellierung. Gabler, 1994. – ISBN 978–3–322–90398–3
[HBR10]
HALLERBACH, Alena ; BAUER, Thomas ; REICHERT, Manfred: Capturing
variability in business process models: the Provop approach. In:
Journal of
Software Maintenance and Evolution: Research and Practice
22 (2010),
Nr. 6-7, S. 519–546.
http://dx.doi.org/10.1002/smr.491
. – DOI
10.1002/smr.491. – ISSN 1532060X
[HC94]
HAMMER, Michael ; CHAMPY, James:
Reengineering the corporation: A
manifesto for business revolition
. New York, NY : HarperBusiness, 1994.
– ISBN 978–0887306877
[Hei02]
HEIMIG, Ingo:
Grammatikbasierte Beschreibung von Geschäftsprozes-
sen: Methodik für das strukturierte Verarbeiten von Modellen
. Wiesbaden
133
Literaturverzeichnis
: Gabler Verlag, 2002. – ISBN 10.1007/978–3–663–10192–5
[Hub95]
HUBERT, Österle:
Business Engineering: Prozess-und Systementwick-
lung, Band1, Entwurfstechniken. Berlin : Springer, 1995
[Kah01]
KAHLBRANDT, Bernd:
Software-Engineering mit der Unified Modeling
Language. Springer Berlin Heidelberg, 2001
[Kee07]
KEELE, Staffs: Guidelines for performing systematic literature reviews in
software engineering. (2007)
[KNS92]
KELLER, Gerhard ; NÜTTGENS, Markus ; SCHEER, August-Wilhelm:
Semantische Prozeßmodellierung auf der Grundlage „Ereignisgesteuerter
Prozeßketten (EPK)“. (1992).
https://www.wiso.uni-hamburg.
de/fileadmin/wiso_fs_wi/Team/Mitarbeiter/Prof._Dr.
_Markus_Nuettgens/Publikationen/heft089.pdf
[Kra97]
KRALLMANN, Hermann:
Wirtschaftsinformatik ’97: Internationale Ge-
schäftstätigkeit auf der Basis flexibler Organisationsstrukturen und leis-
tungsfähiger Informationssysteme
. Heidelberg : Physica-Verlag HD, 1997.
– ISBN 978–3–642–63341–6
[Kro12]
KROGSTIE, John:
Model-based development and evolution of information
systems: A quality approach
. London and New York : Springer, 2012. –
ISBN 978–1–4471–2936–3
[Kru96]
KRUSE, Christian:
Referenzmodellgestütztes Geschäftsprozeßmanage-
ment: Ein Ansatz zur prozeßorientierten Gestaltung vertriebslogistischer
Systeme
. Wiesbaden : Gabler Verlag, 1996. – ISBN 978–3–322–90823–0
[Lan97]
LANG, Klaus:
Gestaltung von Geschäftsprozessen mit Referenzprozess-
bausteinen
. Wiesbaden : Dt. Univ.-Verl., 1997 (Gabler Edition Wissen-
schaft). – ISBN 978–3–8244–6540–8
134
Literaturverzeichnis
[LR07]
LENZ, Richard ; REICHERT, Manfred: IT support for healthcare processes–
premises, challenges, perspectives. In:
Data & Knowledge Engineering
61 (2007), Nr. 1, S. 39–58
[LR09]
LAROSA, Marcello:
Managing variability in process-aware information
systems
, Queensland University of Technology Brisbane, Australia 25,
Diss., 2009
[LRADTH09]
LAROSA, Marcello ; AALST, Wil M. d. ; DUMAS, Marlon ; TER HOFSTEDE,
Arthur H.: Questionnaire-based variability modeling for system configurati-
on. In: Software & Systems Modeling 8 (2009), Nr. 2, S. 251–274
[Mai98]
MAICHER, Michael:
Informationsmodellierung: Referenzmodelle und
Werkzeuge
. Wiesbaden : Dt. Univ.-Verl, 1998. – ISBN 978–3–8244–
6742–6
[MHHR06]
MÜLLER, Dominic ; HERBST, Joachim ; HAMMORI, Markus ; REICHERT,
Manfred:
IT support for release management processes in the automo-
tive industry
. Springer, 2006 (Proceedings of the Fourth International
Conference on Business Process Management (BPM’06). – 368–377 S.
[MRA10]
MENDLING, Jan ; REIJERS, Hajo A. ; AALST, Wil M. d.: Seven process
modeling guidelines (7PMG). In:
Information and Software Technology
52 (2010), Nr. 2, S. 127–136
[Pet62] PETRI, Carl A.: Kommunikation mit automaten. (1962)
[Por99]
PORTER, Michael E.:
Wettbewerbsstrategie: (Competitive strategy) : Me-
thoden zur Analyse von Branchen und Konkurrenten
. [10., durchges.
und erw. Aufl.]. Frankfurt/Main [etc.] : Campus-Verlag, 1999. – ISBN
3593361779
[RA00]
ROLSTADÅS, Asbjørn ; ANDERSEN, Bjørn:
Enterprise Mode-
ling
. Boston, MA : Springer US, 2000.
http://dx.doi.org/
135
Literaturverzeichnis
10.1007/978-1-4615-4475-3
.
http://dx.doi.org/10.1007/
978-1-4615-4475-3. – ISBN 978–1–4613–7016–1
[Rem01]
REMMERT, Jan:
Referenzmodellierung für die Handelslogistik
. 1. Aufl.
Wiesbaden : Dt. Univ.-Verl., 2001 (Gabler Edition Wissenschaft Integrierte
Logistik und Unternehmensführung). – ISBN 978–3–8244–7546–9
[Rem12]
REMME, Markus:
Konstruktion von Gesch(ä)ftsprozessen: Ein modell-
gest(ü)tzter Ansatz durch Montage generischer Prozeßpartiekl
. [Wiesba-
den : Gabler, 2012. – ISBN 978–3–322–84501–6
[Rob94]
ROBERTS, Lon:
Process Reengineering: The Key to Achieving
Breakthrough Success
. ASQC Quality Press, 1994. – ISBN
9780873892742
[Ros96]
ROSEMANN, Michael:
Komplexitätsmanagement in Prozessmodellen: Me-
thodenspezifische Gestaltungsempfehlungen für die Informationsmodel-
lierung. Wiesbaden : Gabler, 1996. – ISBN 9783322992321
[Ros06a]
ROSEMANN, Michael: Potential pitfalls of process modeling: part A. In:
Business Process Management Journal 12 (2006), Nr. 2, S. 249–254
[Ros06b]
ROSENKRANZ, Friedrich:
Geschäftsprozesse: Modell- und computer-
gestützte Planung
. 2., verb. Aufl. Berlin : Springer, 2006. – ISBN
9783540283430
[RRIG06]
ROSEMANN, Michael ; RECKER, Jan ; INDULSKA, Marta ; GREEN, Peter: A
study of the evolution of the representational capabilities of process mode-
ling grammars. In:
Advanced Information Systems Engineering
Springer,
2006, S. 447–461
[RRK07] RECKER, Jan ; ROSEMANN, Michael ; KROGSTIE, John: Ontology-versus
pattern-based evaluation of process modeling languages: a comparison.
In:
Communications of the Association for Information Systems
20 (2007),
Nr. 1, S. 48
136
Literaturverzeichnis
[Rum99]
RUMP, Frank J.:
Geschäftsprozeßmanagement auf der Basis ereignis-
gesteuerter Prozeßketten: Formalisierung, Analyse und Ausführung von
EPKs. Wiesbaden : Vieweg+Teubner Verlag, 1999. – ISBN 3322898784
[RW12]
REICHERT, Manfred ; WEBER, Barbara:
Enabling flexibility in process-
aware information systems: Challenges, methods, technologies
. Heidel-
berg and New York : Springer, c
2012. – ISBN 978–3–642–30408–8
[SAJK02]
SCHEER, August-Wilhelm ; ABOLHASSAN, Ferri ; JOST, Wolfram ; KIRCH-
MER, Mathias:
Business Process Excellence
. Berlin, Heidelberg : Springer
Berlin Heidelberg, 2002. – ISBN 978–3–642–53419–5
[Sch93]
SCHEER, August-Wilhelm: ARIS—Architektur integrierter Informations-
systeme. In:
Handbuch Informationsmanagement
. Springer, 1993, S.
81–112
[Sch94]
SCHEER, August-Wilhelm:
Wirtschaftsinformatik: Referenzmodelle für in-
dustrielle Geschäftsprozesse
. Fünfte, durchgesehene Auflage. Berlin,
Heidelberg, s.l. : Springer Berlin Heidelberg, 1994. – ISBN 978–3–662–
10958–8
[Sch95]
SCHEER, August W.:
Wirtschaftsinformatik: Referenzmodelle für indus-
trielle Geschäftsprozesse
. Springer, 1995. – ISBN 9783540600466. –
Studienausgabe
[Sch98a]
SCHEER, August-Wilhelm:
ARIS - Modellierungsmethoden, Metamodelle,
Anwendungen. Berlin : Springer, 1998. – ISBN 9783540416012
[Sch98b]
SCHEER, August-Wilhelm:
ARIS - Vom Geschäftsprozeß zum Anwen-
dungssystem
. Dritte, völlig neubearbeitete und erweiterte Auflage. Berlin,
Heidelberg : Springer Berlin Heidelberg, 1998. – ISBN 978–3–642–97820–
3
[Sch98c]
SCHÜTTE, Reinhard:
Neue betriebswirtschaftliche Forschung
. Bd. Bd.
233:
Grundsätze orddnungsmässiger referenzmodellierung: Konstruktion
137
Literaturverzeichnis
konfigurations- und anpassungsorientierter Modelle
. Wiesbaden : Gabler,
c
1998. – ISBN 978–3–409–12843–8
[Sch99]
SCHWEGMANN, Ansgar:
Objektorientierte Referenzmodellierung: Theo-
retische Grundlagen und praktische Anwendung
. Wiesbaden and Wies-
baden : Dt. Univ.-Verl. and Gabler, 1999 (Gabler Edition Wissenschaft :
Informationsmanagement und Controlling). – ISBN 978–3–8244–7014–3
[Sch00]
SCHLAGHECK, Bernhard:
Objektorientierte Referenzmodelle für das
Prozeß- und Projektcontrolling: Grundlagen, Konstruktion, Anwendungs-
möglichkeiten
. Wiesbaden : Dt. Univ.-Verl. [u.a.], 2000. – ISBN 978–3–
8244–7162–1
[Sch04]
SCHANTIN, Dietmar:
Makromodellierung von Geschäftsprozessen: Kun-
denorientierte Prozessgestaltung durch Segmentierung und Kaskadie-
rung
. 1. Aufl. Wiesbaden : Dt. Univ.-Verl., 2004 (Gabler Edition Wis-
senschaft). – ISBN 9783824479887
[Sei06]
SEIDLMEIER, Heinrich:
Prozessmodellierung mit ARIS: Eine beispielori-
entierte Einführung für Studium und Praxis
. 2., aktualisierte Aufl. Wiesba-
den : Vieweg, 2006. – ISBN 978–3–8348–0280–4
[SHT06]
SCHOBBENS, Pierre-Yves ; HEYMANS, Patrick ; TRIGAUX, Jean-Christophe:
Feature diagrams: A survey and a formal semantics. In:
Requirements
Engineering, 14th IEEE international conference
IEEE, 2006, S. 139–148
[SRS96]
SCHOLZ-REITER, B. ; STICKEL, Eberhard:
Business Process Modelling
.
Berlin, Heidelberg : Springer Berlin Heidelberg, 1996. – ISBN 3642803172
[Sta10]
STADLER, D.:
Konfigurative Referenzmodelle im Handel: warenwirtschaft-
liche Funktionen ausgewählter Handelsbranchen
. Logos Verlag Ber-
lin, 2010 (Advances in information systems and management science).
https://books.google.de/books?id=XiWquAAACAAJ
. – ISBN
9783832527471
138
Literaturverzeichnis
[Tho06]
THOMAS, Oliver:
Wirtschaftsinformatik - Theorie und Anwendung
. Bd. 1:
Management von Referenzmodellen: Entwurf und Realisierung eines In-
formationssystems zur Entwicklung und Anwendung von Referenzmodel-
len. Berlin : Logos Berlin, 2006. – ISBN 3832513442
[VR10]
VOM BROCKE, Jan ; ROSEMANN, Michael:
Handbook on business process
management: Introduction, methods and information systems
. Berlin and
London : Springer, 2010 (International handbooks on information systems).
– ISBN 3642004164
[Wes07]
WESKE, Mathias:
Business process management: Concepts, langua-
ges, architectures
. Berlin and New York : Springer, 2007. – ISBN
9783540735212
[Wir15a]
WIRTSCHAFTSLEXIKON24:
SAP R/3
.
http://www.
wirtschaftslexikon24.com/d/sap-r3/sap-r3.htm
.
Version:2015. – Letzter Zugriff: 29.03.2015
[Wir15b]
WIRTSCHAFTSLEXIKON24:
SCOR-Modell (Supply Chain Operations
Reference Model)
.
http://www.wirtschaftslexikon24.com/d/
scor-modell-supply-chain-operations-reference-model/
scor-modell-supply-chain-operations-reference-model.
htm. Version:2015. – Letzter Zugriff: 29.03.2015
[WM08]
WHITE, Stephen A. ; MIERS, Derek:
BPMN modeling and reference guide:
Understanding and using BPMN : develop rigorous yet understandable
graphical representations of business processes
. Lighthouse Point, Fla. :
Future Strategies Inc., 2008. – ISBN 978–0–9777527–2–0
[WW90]
WAND, Yair ; WEBER, Ron: An ontological model of an information sys-
tem. In:
Software Engineering, IEEE Transactions on
16 (1990), Nr. 11, S.
1282–1292
139
Literaturverzeichnis
[WW93]
WAND, Yair ; WEBER, Ron: On the ontological expressiveness of infor-
mation systems analysis and design grammars. In:
Information Systems
Journal 3 (1993), Nr. 4, S. 217–237
[WW95]
WAND, Yair ; WEBER, Ron: On the deep structure of information systems.
In: Information Systems Journal 5 (1995), Nr. 3, S. 203–223
[ZHMBA14]
ZAABOUB HADDAR, Nahla ; MAKNI, Lobna ; BEN ABDALLAH, Hanene:
Literature review of reuse in business process modeling. In:
Software &
Systems Modeling
13 (2014), Nr. 3, S. 975–989.
http://dx.doi.org/
10.1007/s10270-012-0286-4. – DOI 10.1007/s10270–012–0286–4.
– ISSN 1619–1366
140
Name: Mutlu Oytun
Karlstraße 11
89150 Laichingen Matrikelnummer: 833960
Erklärung
Ich erkläre, dass ich die Arbeit selbstständig verfasst und keine anderen als die angege-
benen Quellen und Hilfsmittel verwendet habe.
Ulm,den .............................................................................
Mutlu Oytun
