Modellierung der Unternehmensarchitektur - unisg.chFILE/dis3285.pdf · Vorwort iii Vorwort Die vorliegende Arbeit entstand im Rahmen meiner mehrjährigen Forschungstätigkeit als

Modellierung

der Unternehmensarchitektur

Weiterentwicklung einer bestehenden Methode und

deren Abbildung in einem Meta-Modellierungswerkzeug

DISSERTATION

der Universität St. Gallen,

Hochschule für Wirtschafts-,

Rechts- und Sozialwissenschaften (HSG)

zur Erlangung der Würde eines

Doktors der Wirtschaftswissenschaften

vorgelegt von

Christian Braun

aus Deutschland

Genehmigt auf Antrag der Herren

Prof. Dr. Robert Winter

und

Prof. Dr. Walter Brenner

Dissertation Nr. 3285

Logos Verlag, Berlin 2007

Die Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften

(HSG), gestattet hiermit die Drucklegung der vorliegenden Dissertation, ohne damit zu den

darin ausgesprochenen Anschauungen Stellung zu nehmen.

St. Gallen, den 22. Januar 2007

Der Rektor:

Prof. Ernst Mohr, PhD

Vorwort iii

Vorwort

Die vorliegende Arbeit entstand im Rahmen meiner mehrjährigen Forschungstätigkeit als

wissenschaftlicher Mitarbeiter am Institut für Wirtschaftsinformatik (IWI-HSG). Die

praxisorientierte Forschung am Institut in Form so genannter Kompetenzzentren, in denen

zusammen mit Unternehmensvertretern in Workshops und bilateralen Projekten

Lösungsansätze zu übergeordneten Forschungsthemen erarbeitet werden, bot ein einzigartiges

Forschungsumfeld. Rückblickend haben vor allem die Menschen dieses Umfeldes die

erfolgreiche Fertigstellung meiner Arbeit ermöglicht.

Mein besonderer Dank gilt Herrn Prof. Dr. Robert Winter, der die Dissertation von der

Themenfindung bis zur Veröffentlichung intensiv betreute und mir ein ausgezeichnetes

Arbeits- und Forschungsumfeld am Institut bot. Herrn Prof. Dr. Walter Brenner danke ich für

die Übernahme des Korreferats und seine wertvollen Anregungen.

Herrn Dr. Jochen Müller, Studienleiter des Executive MBA in Business Engineering (MBE

HSG), und Herrn Dr. Joachim Schelp, Projektleiter des Kompetenzzentrums „Integration

Factory“, bin ich für die unkomplizierte und freundschaftliche Zusammenarbeit sowie die

fachliche und persönliche Unterstützung dankbar. Desweiteren danke ich dem gesamten

MBE-Team mit Monika Schlumpf, Bernadette Mayer, Myriam Groebli und Rudolf Brühwiler

für die angenehme Zusammenarbeit, die meine Zeit am Institut positiv prägte.

Prof. Ghiassi, von der Leavey School of Business der Santa Clara University in Kalifornien,

sowie dem Schweizerischen Nationalfonds danke ich für die Unterstützung meines

einjährigen Forschungsaufenthaltes in den USA. Dieser hat sowohl meine fachlichen

Kenntnisse als auch meinen persönlichen und kulturellen Horizont erweitert.

Mein herzlicher Dank gilt meinen Kollegen und Freunden des IWI-HSG Malte Dous, Ronny

Fischer, Dr. Malte Geib, Susanne Glissmann, Dr. Clemens Herrmann, Dr. Axel Hochstein,

Mario Klesse, Dr. Florian Melchert, Dr. Annette Reichold, Alexander Ritschel, Ragnar

Schierholz, Harald Salomann, Dr. Alexander Schwinn, Christian Wilhelmi, Oliver Wilke, Dr.

Felix Wortmann und Dr. Gregor Zellner. Gerne blicke ich nicht nur auf die freundschaftliche

Zusammenarbeit, sondern vor allem auch auf die schönen gemeinsamen Erlebnisse ausserhalb

der Institutsarbeit zurück.

Praxisorientierte Forschung kann nur gelingen, wenn die entwickelten Konzepte auf ihre

Praxistauglichkeit überprüft werden können. Prof. Karagiannis der Universität Wien sowie

Franz Bayer der BOC Business Object Consulting danke ich deshalb für die Unterstützung

bei der technischen Umsetzung der Konzepte meiner Arbeit in einem Softwareprototypen.

Dadurch konnten die Konzepte in der Praxis überprüft werden. Hierfür danke ich

insbesondere Dario Bee, Urs Bernet und Fiorenzo Maletta, die für mich wertvolle

Ansprechpartner für die Aufnahme der Fallstudie bei der Winterthur Group waren.

Vorwort iv

Ausserdem danke ich herzlich Kuno Braun für das gründliche Korrekturlesen am Ende der

Erstellung der Arbeit.

Ein besonders herzlicher Dank gilt meiner Freundin Adele Alimkulova für die Unterstützung,

Motivation und das Verständnis während der Dissertationsphase.

Mein grösster Dank gilt schliesslich meinen Eltern Linde und Helmut Braun, ohne deren

Unterstützung und Förderung meine akademische Ausbildung sowie die Fertigstellung der

Dissertation nicht möglich gewesen wären. Ihnen widme ich diese Arbeit von ganzem

Herzen.

Zürich, im Januar 2007

Christian Braun

Inhaltsübersicht v

Inhaltsübersicht

Vorwort ....................................................................................................................................iii

Inhaltsübersicht ........................................................................................................................v

Inhaltsverzeichnis ..................................................................................................................viii

Abkürzungsverzeichnis .........................................................................................................xiv

Abbildungsverzeichnis ..........................................................................................................xvi

Tabellenverzeichnis ................................................................................................................xx

Kurzfassung ..........................................................................................................................xxii

Abstract ................................................................................................................................xxiii

1 Einführung ...........................................................................................................................1

1.1 Problemstellung und Handlungsbedarf ..........................................................................1

1.2 Ziele und Adressaten der Arbeit.....................................................................................4

1.3 Forschungsmethodik ......................................................................................................6

1.4 Aufbau der Arbeit.........................................................................................................10

2 Konzeptionelle Grundlagen der Unternehmensmodellierung.......................................12

2.1 Methoden......................................................................................................................12

2.2 Modelle.........................................................................................................................15

2.3 Modellierung der Unternehmensarchitektur ................................................................24

2.4 Werkzeugkonstruktion und -unterstützung ..................................................................33

2.5 Ziele und treibende Kräfte der Unternehmensarchitektur............................................38

2.6 Konsequenzen für das weitere Vorgehen.....................................................................43

3 Bisherige relevante Ansätze ..............................................................................................47

3.1 Auswahl der Ansätze....................................................................................................48

3.2 Diskussion ausgewählter Methoden aus der Wissenschaft ..........................................50

3.3 Diskussion ausgewählter Bezugsrahmen aus der Praxis..............................................74

3.4 Zusammenfassung und Übersicht der Bewertung........................................................85

4 Ansatz zur Modellierung der Unternehmensarchitektur ..............................................89

4.1 Modellierung auf Strategieebene .................................................................................92

4.2 Modellierung auf Organisationsebene .......................................................................109

Inhaltsübersicht vi

4.3 Modellierung auf Informationssystemebene..............................................................132

4.4 Modellierung auf Infrastrukturebene .........................................................................150

4.5 Vorschlag zur Integration serviceorientierter Konzepte ............................................152

4.6 Ebeneninterne Abhängigkeiten zwischen Modellen ..................................................161

4.7 Ebenenübergreifende Abhängigkeiten .......................................................................171

4.8 Detaillierungsgrad und Schnittstellen zu domänenspezifischen

Architekturmodellen und Modellierungssprachen .....................................................178

4.9 Zusammenfassung......................................................................................................181

5 Konstruktion eines Prototyps mit Hilfe eines Metamodellierungswerkzeuges..........182

5.1 Auswahl eines geeigneten Werkzeuges für die Abbildung des Ansatzes ..................183

5.2 Beschreibung der Abbildung in ADONIS .................................................................186

5.3 Überblick über den Aufbau und die generellen Funktionalitäten ..............................192

5.4 Erstellen von Modellen im Modelleditor ...................................................................194

5.5 Durchgängigkeit und Abbildung der Gesamtzusammenhänge ..................................195

5.6 Analyse der erstellten Modelle...................................................................................200

5.7 Export/Import und Dokumentation ............................................................................204

6 Multiperspektivische Evaluation....................................................................................206

6.1 Fallstudie bei der Winterthur Group ..........................................................................209

6.2 Metamodellbasierter Vergleich mit bestehenden Ansätzen .......................................235

6.3 Natürlichsprachliche und merkmalbasierte Evaluation..............................................240

7 Zusammenfassung und Ausblick....................................................................................244

7.1 Zusammenfassung der Arbeit.....................................................................................244

7.2 Kritische Würdigung ..................................................................................................247

7.3 Zukünftiger Forschungs- und Entwicklungsbedarf....................................................249

Anhang A: Dokumentation der Abbildung der Metamodelle in ADONIS.....................252

A.1. Strategieebene ............................................................................................................252

A.2. Organisationsebene ....................................................................................................256

A.3. Applikationsebene......................................................................................................262

A.4. Softwarekomponenten- und Datenstrukturebene.......................................................265

A.5. Infrastrukturebene ......................................................................................................267

Inhaltsübersicht vii

A.6. IT-Services .................................................................................................................268

Anhang B: Darstellung einer Auswahl kommerziell verfügbarer

Modellierungswerkzeuge.................................................................................................270

Anhang C: Ansprechpartner bei der Winterthur Group.................................................279

Literatur ................................................................................................................................281

Inhaltsverzeichnis viii

Inhaltsverzeichnis

Vorwort ....................................................................................................................................iii

Inhaltsübersicht ........................................................................................................................v

Inhaltsverzeichnis ..................................................................................................................viii

Abkürzungsverzeichnis .........................................................................................................xiv

Abbildungsverzeichnis ..........................................................................................................xvi

Tabellenverzeichnis ................................................................................................................xx

Kurzfassung ..........................................................................................................................xxii

Abstract ................................................................................................................................xxiii

1 Einführung ...........................................................................................................................1

1.1 Problemstellung und Handlungsbedarf ..........................................................................1

1.2 Ziele und Adressaten der Arbeit.....................................................................................4

1.3 Forschungsmethodik ......................................................................................................6

1.4 Aufbau der Arbeit.........................................................................................................10

2 Konzeptionelle Grundlagen der Unternehmensmodellierung.......................................12

2.1 Methoden......................................................................................................................12

2.1.1 Method Engineering ..........................................................................................12

2.1.2 Methodenbestandteile ........................................................................................14

2.2 Modelle.........................................................................................................................15

2.2.1 Modell und Modellierung ..................................................................................15

2.2.2 Referenzmodell und Referenzmodellierung ......................................................18

2.2.3 Metamodell und Metamodellierung...................................................................20

2.2.4 Verwendete Meta-Modellierungssprachen ........................................................21

2.2.4.1 Notation für Metamodelle .............................................................................22

2.2.4.2 Notation für Vorgehensmodelle ....................................................................23

2.3 Modellierung der Unternehmensarchitektur ................................................................24

2.3.1 Darstellung von Gesamtzusammenhängen in Unternehmungen .......................25

2.3.2 Business Engineering.........................................................................................27

2.3.3 Methoden und Konsistenz .................................................................................31

Inhaltsverzeichnis ix

2.3.4 Die BAI-Methode ..............................................................................................32

2.4 Werkzeugkonstruktion und -unterstützung ..................................................................33

2.5 Ziele und treibende Kräfte der Unternehmensarchitektur............................................38

2.6 Konsequenzen für das weitere Vorgehen.....................................................................43

2.6.1 Anforderungen an einen Ansatz zur Modellierung der

Unternehmensarchitektur...................................................................................43

2.6.2 Anforderungen an die Werkzeugunterstützung .................................................44

3 Bisherige relevante Ansätze ..............................................................................................47

3.1 Auswahl der Ansätze....................................................................................................48

3.2 Diskussion ausgewählter Methoden aus der Wissenschaft ..........................................50

3.2.1 Architektur integrierter Informationssysteme (ARIS) .......................................50

3.2.1.1 Übersicht und Architekturebenen..................................................................50

3.2.1.2 Metamodelle von ARIS.................................................................................52

3.2.1.3 Weitere strukturelle Bestandteile ..................................................................59

3.2.1.4 Inhaltliche Charakterisierung ........................................................................60

3.2.2 Multi-Perspective Enterprise Modeling (MEMO).............................................61


3.2.2.2 Metamodelle von MEMO .............................................................................62



3.2.3 Semantisches Objektmodell (SOM) ..................................................................67


3.2.3.2 Metamodelle der SOM-Methode...................................................................68



3.3 Diskussion ausgewählter Bezugsrahmen aus der Praxis..............................................74

3.3.1 Das Zachman Framework..................................................................................74

3.3.1.1 Überblick und Architekturebenen .................................................................74

3.3.1.2 Methodenbestandteile des Zachman Framework ..........................................76


Inhaltsverzeichnis x

3.3.2 Federal Enterprise Architecture Framework (FEAF) ........................................78


3.3.2.2 Methodenbestandteile von FEAF..................................................................79


3.3.3 The Open Group Architecture Framework (TOGAF) .......................................81


3.3.3.2 Methodenbestandteile von TOGAF ..............................................................81


3.4 Zusammenfassung und Übersicht der Bewertung........................................................85

4 Ansatz zur Modellierung der Unternehmensarchitektur ..............................................89

4.1 Modellierung auf Strategieebene .................................................................................92

4.1.1 Vorgehensmodell ...............................................................................................94

4.1.2 Metamodell ........................................................................................................95

4.1.2.1 Metamodell des Geschäftsnetzwerks ............................................................95

4.1.2.2 Metamodell des Kundenprozessmodells .......................................................97

4.1.2.3 Metamodell des Leistungsmodells ................................................................98

4.1.2.4 Metamodell des Zielsystems .......................................................................100

4.1.2.5 Definition der Metaentitätstypen auf Strategieebene ..................................102

4.1.2.6 Festlegung der verwendeten Symbole auf Strategieebene ..........................108

4.2 Modellierung auf Organisationsebene .......................................................................109

4.2.1 Vorgehensmodell .............................................................................................111

4.2.2 Metamodell ......................................................................................................114

4.2.2.1 Metamodell der Prozesslandkarte ...............................................................114

4.2.2.2 Metamodell der Prozessvision.....................................................................115

4.2.2.3 Metamodell der Prozessführung..................................................................116

4.2.2.4 Metamodell der Aufbauorganisation...........................................................118

4.2.2.5 Metamodell der Ablauforganisation............................................................120

4.2.2.6 Metamodell der Informationslandkarte .......................................................124

4.2.2.7 Definition der Metaentitätstypen auf Organisationsebene ..........................126

Inhaltsverzeichnis xi

4.2.2.8 Festlegung der verwendeten Symbole auf Organisationsebene ..................131

4.3 Modellierung auf Informationssystemebene..............................................................132

4.3.1 Vorgehensmodell .............................................................................................134

4.3.2 Metamodell ......................................................................................................137

4.3.2.1 Metamodell der Applikationslandschaft .....................................................137

4.3.2.2 Metamodell des Geschäftsfunktions- und Informationsobjektmodells.......139

4.3.2.3 Metamodell der Integrationsarchitektur ......................................................140

4.3.2.4 Metamodell der Softwarekomponenten und Plattformen ...........................140

4.3.2.5 Metamodell des Datenstrukturmodells........................................................142

4.3.2.6 Metamodell der Autorisierung ....................................................................143

4.3.2.7 Definition der Metaentitätstypen auf Informationssystemebene.................145

4.3.2.8 Festlegung der verwendeten Symbole auf Informationssystemebene ........149

4.4 Modellierung auf Infrastrukturebene .........................................................................150

4.5 Vorschlag zur Integration serviceorientierter Konzepte ............................................152

4.6 Ebeneninterne Abhängigkeiten zwischen Modellen ..................................................161

4.6.1 Strategieebene ..................................................................................................161

4.6.2 Organisationsebene ..........................................................................................164

4.6.3 Informationssystemebene ................................................................................168

4.7 Ebenenübergreifende Abhängigkeiten .......................................................................171

4.7.1 Zusammenhänge zwischen Strategie- und Organisationsebene ......................172

4.7.2 Zusammenhänge zwischen Organisations- und Informationssystemebene.....174

4.8 Detaillierungsgrad und Schnittstellen zu domänenspezifischen

Architekturmodellen und Modellierungssprachen .....................................................178

4.9 Zusammenfassung......................................................................................................181

5 Konstruktion eines Prototyps mit Hilfe eines Metamodellierungswerkzeuges..........182

5.1 Auswahl eines geeigneten Werkzeuges für die Abbildung des Ansatzes ..................183

5.2 Beschreibung der Abbildung in ADONIS .................................................................186

5.2.1 Metamodellierungskonzept..............................................................................186

5.2.2 Basiskonzepte in ADONIS ..............................................................................187

5.2.3 Das ADONIS-Administrations-Toolkit ...........................................................188

Inhaltsverzeichnis xii

5.2.4 Abbildung der Metamodelle ............................................................................190

5.3 Überblick über den Aufbau und die generellen Funktionalitäten ..............................192

5.4 Erstellen von Modellen im Modelleditor ...................................................................194

5.5 Durchgängigkeit und Abbildung der Gesamtzusammenhänge ..................................195

5.6 Analyse der erstellten Modelle...................................................................................200

5.7 Export/Import und Dokumentation ............................................................................204

6 Multiperspektivische Evaluation....................................................................................206

6.1 Fallstudie bei der Winterthur Group ..........................................................................209

6.1.1 Allgemeine Informationen zur Winterthur Group ...........................................209

6.1.2 Ausgangssituation und Problembeschreibung .................................................210

6.1.3 Ein zentral gepflegtes Metamodell als Lösungsansatz ....................................212

6.1.4 Metamodell der Winterthur Group ..................................................................214

6.1.5 Vergleich der Metamodelle .............................................................................216

6.1.6 Abbildung mit Hilfe des Prototyps ..................................................................220

6.1.7 Fazit .................................................................................................................234

6.2 Metamodellbasierter Vergleich mit bestehenden Ansätzen .......................................235

6.2.1 Metamodellbasierter Vergleich mit ARIS .......................................................235

6.2.2 Metamodellbasierter Vergleich mit MEMO....................................................237

6.2.3 Metamodellbasierter Vergleich mit SOM........................................................239

6.2.4 Fazit .................................................................................................................240

6.3 Natürlichsprachliche und merkmalbasierte Evaluation..............................................240

7 Zusammenfassung und Ausblick....................................................................................244

7.1 Zusammenfassung der Arbeit.....................................................................................244

7.2 Kritische Würdigung ..................................................................................................247

7.3 Zukünftiger Forschungs- und Entwicklungsbedarf....................................................249

Anhang A: Dokumentation der Abbildung der Metamodelle in ADONIS.....................252

A.1. Strategieebene ............................................................................................................252

A.2. Organisationsebene ....................................................................................................256

A.3. Applikationsebene......................................................................................................262

Inhaltsverzeichnis xiii

A.4. Softwarekomponenten- und Datenstrukturebene.......................................................265

A.5. Infrastrukturebene ......................................................................................................267

A.6. IT-Services .................................................................................................................268

Anhang B: Darstellung einer Auswahl kommerziell verfügbarer

Modellierungswerkzeuge.................................................................................................270

Anhang C: Ansprechpartner bei der Winterthur Group.................................................279

Literatur ................................................................................................................................281

Abkürzungsverzeichnis xiv

Abkürzungsverzeichnis

ADL ADONIS Definition Language

AQL ADONIS Query Language

ADM Architecture Development Method

ARIS Architektur integrierter Informationssysteme

BAI Bankenarchitekturen im Informationszeitalter

BE Business Engineering

BPMN Business Process Management Notation

CASE Computer Aided Software Engineering

CIM Computation Independent Model

CWM Common Warehouse Metamodel

DoDAF Department of Defense Architecture Framework

DS Design Science

EA Enterprise Architecture

EAM Enterprise Architecture Manager

eEPK Erweiterte ereignisgesteuerte Prozesskette

EPK Ereignisgesteuerte Prozesskette

ESP Exclusive Service Provider

FEAF Federal Enterprise Architecture Framework

IAS Interaktionsschema

IFEAD Institute For Enterprise Architecture Development

IKS Informations- und Kommunikationssysteme

IO Informationsobjekt

IS Informationssystem

ISA Informationssystem-Architektur

ITIL IT Infrastructure Library

ITSM IT-Service-Management

IWI-HSG Institut für Wirtschaftsinformatik der Universität St. Gallen

J2EE Java 2 Platform Enterprise Edition

KEF Kritischer Erfolgsfaktor

KOS Konzeptuelles Objektschema

MDA Model Driven Architecture

Abkürzungsverzeichnis xv

MEMO Multi-Perspective Enterprise Modeling

OE Organisationseinheit

OE des PM Organisationseinheit des Prozessmanagements

OLA Operational Level Agreement

OML OPEN Modeling Language

PIM Platform Independent Model

PL Prozesslandkarte

PS Public Service

PSM Platform Specific Model

SI Service Integrator

SITM Strategic IT Management

SOA Serviceorientierte Architektur

SOM Semantisches Objektmodell

SOP Solution Evaluation Process

SSP Shared Service Provider

SW Software

TEAF Treasury Enterprise Architecture Framework

TOGAF The Open Group Architecture Framework

UML Unified Modeling Language

VES Vorgangs-Ereignisschema

VOS Vorgangs-Objektschema

WGR Winterthur Group

Abbildungsverzeichnis xvi

Abbildungsverzeichnis

Abbildung 1: Information Systems Research Framework .........................................................8

Abbildung 2: Aufbau der Arbeit...............................................................................................11

Abbildung 3: Bestandteile einer Methode ................................................................................14

Abbildung 4: Bestandteile einer Modellierungstechnik ...........................................................16

Abbildung 5: Strukturierung von Modellen .............................................................................18

Abbildung 6: Referenzmodellanwendung ................................................................................19

Abbildung 7: Modellierungshierarchie.....................................................................................21

Abbildung 8: Unternehmensarchitektur ...................................................................................27

Abbildung 9: Business-Engineering-Landkarte .......................................................................29

Abbildung 10: Vereinfachtes Metamodell des BE...................................................................30

Abbildung 11: Beispiel für Wechselwirkungen zwischen den Ebenen....................................32

Abbildung 12: Metamodellierungskonzepte für die Werkzeugkonstruktion ...........................35

Abbildung 13: Kategorisierung der Werkzeugunterstützung...................................................37

Abbildung 14: ARIS-Haus .......................................................................................................51

Abbildung 15: Metamodell des strategischen Geschäftsprozessmodells .................................53

Abbildung 16: Metamodell des strategischen Vorgangskettendiagramms ..............................54

Abbildung 17: Metamodell der Funktionssicht ........................................................................55

Abbildung 18: Metamodell der Organisationssicht..................................................................56

Abbildung 19: Metamodell der Datensicht (Makro) ................................................................57

Abbildung 20: Metamodell der Leistungssicht ........................................................................58

Abbildung 21: Metamodell der Steuerungssicht ......................................................................59

Abbildung 22: Multi-Perspective Enterprise Modeling (MEMO) ...........................................62

Abbildung 23: Metamodell der MEMO-SML (Strategy Modeling Language) .......................63

Abbildung 24: Metamodell der MEMO-OrgML .....................................................................64

Abbildung 25: Metamodell der MEMO-OML.........................................................................65

Abbildung 26: SOM-Ebenen....................................................................................................67

Abbildung 27: Metamodell der Geschäftsprozessebene ..........................................................70

Abbildungsverzeichnis xvii

Abbildung 28: Metamodell der Anwendungssystemebene ......................................................71

Abbildung 29: Das Zachman Framework ................................................................................75

Abbildung 30: Federal Enterprise Architecture Framework ....................................................79

Abbildung 31: TOGAF ADM ..................................................................................................82

Abbildung 32: Gestaltungsebenen und Sichten des entwickelten Ansatzes.............................89

Abbildung 33: Vorgehensmodell auf Strategieebene (Level 1) ...............................................95

Abbildung 34: Metamodell des Geschäftsnetzwerkmodells ....................................................97

Abbildung 35: Metamodell des Kundenprozessmodells ..........................................................98

Abbildung 36: Metamodell des Leistungsmodells ...................................................................99

Abbildung 37: Metamodell des Zielsystems (BSC) ...............................................................101

Abbildung 38: Vorgehensmodell auf Organisationsebene (Level 1) .....................................111

Abbildung 39: Metamodell der Prozesslandkarte ..................................................................115

Abbildung 40: Metamodell der Prozessvision .......................................................................116

Abbildung 41: Metamodell der Prozessführung.....................................................................117

Abbildung 42: Metamodell der Aufbauorganisation..............................................................119

Abbildung 43: Metamodell der Ablauforganisation...............................................................121

Abbildung 44: Metamodell der Informationslandkarte ..........................................................125

Abbildung 45: Vorgehensmodell auf Informationssystemebene (Level 1)............................134

Abbildung 46: Metamodell der Applikationslandschaft ........................................................138

Abbildung 47: Metamodell des Geschäftsfunktionen- und Informationsobjektemodells.....139

Abbildung 48: Metamodell der Integrationsarchitektur .........................................................140

Abbildung 49: Metamodell der Softwarekomponenten und Datenstrukturen........................141

Abbildung 50: Vereinfachtes Metamodell des UML-Klassendiagramms .............................143

Abbildung 51: Metamodell der Autorisierung .......................................................................144

Abbildung 52: Metamodell des Infrastrukturmodells ............................................................151

Abbildung 53: Metamodell der IT-Servicesicht.....................................................................154

Abbildung 54: Integration der IT-Servicesicht.......................................................................157

Abbildung 55: Metamodell der SOA-Sicht ............................................................................160

Abbildung 56: Verknüpfung der Modelle auf Strategieebene (OE).......................................163

Abbildungsverzeichnis xviii

Abbildung 57: Verknüpfung der Modelle auf Strategieebene (Marktleistung) .....................164

Abbildung 58: Verknüpfung der Modelle auf Organisationsebene (Prozess)........................166

Abbildung 59: Verknüpfung der Modelle auf Organisationsebene (Organisationseinheit)...167

Abbildung 60: Verknüpfung der Modelle auf Organisationsebene (Führungsgrösse)...........168

Abbildung 61: Verknüpfung der Modelle auf Informationssystemebene (Applikation) .......169

Abbildung 62: Verknüpfung der Modelle auf Informationssystemebene (OE) ....................170

Abbildung 63: Zusammenhänge zwischen Strategie- und Organisationsebene.....................173

Abbildung 64: Zusammenhänge zwischen Organisations- und Informationssystemsebene 176

Abbildung 65: Schnittstellen zu domänenspezifischen Architekturen...................................180

Abbildung 66: Architektur der ADONIS-Plattform...............................................................187

Abbildung 67: Basiskonzepte in ADONIS.............................................................................188

Abbildung 68: Konzepte des ADONIS-Administrations-Toolkits ........................................189

Abbildung 69: Schritte bei der Implementierung des Metamodells in ADONIS ..................190

Abbildung 70: Komponenten und Funktionalitäten des Prototyps ........................................194

Abbildung 71: Anlage eines neuen Modells ..........................................................................195

Abbildung 72: Modellübergreifende Referenzen ...................................................................196

Abbildung 73: Prozesshierarchie............................................................................................197

Abbildung 74: Beispiel Prozessführung.................................................................................198

Abbildung 75: Referenzbaum.................................................................................................200

Abbildung 76: Standardisierte und benutzerdefinierte Abfragen...........................................201

Abbildung 77: Beziehungstabelle...........................................................................................202

Abbildung 78: Pfadanalyse und Simulation ...........................................................................203

Abbildung 79: Dokumentation und Veröffentlichung im Intranet.........................................205

Abbildung 80: Multiperspektivische Evaluation....................................................................206

Abbildung 81: Vereinfachtes Metamodell der Winterthur Group..........................................214

Abbildung 82: Sichten und Inhalte des Metamodells der WGR ............................................215

Abbildung 83: Dokumentation des WGR-Metamodells im Intranet......................................216

Abbildung 84: Geschäftsnetzwerk..........................................................................................221

Abbildung 85: Kundenprozessmodell ....................................................................................223

Abbildungsverzeichnis xix

Abbildung 86: Prozesslandkarte der WGR ............................................................................224

Abbildung 87: Ablaufplanung Schadenbearbeitung...............................................................226

Abbildung 88: Aufbauorganisation ........................................................................................227

Abbildung 89: Geschäftsfunktionen- und Informationsobjektemodell ..................................228

Abbildung 90: Applikationsbestandsführung.........................................................................229

Abbildung 91: Softwarekomponenten....................................................................................229

Abbildung 92: Beziehungstabellen (Applikationsdomäne zu Prozess)..................................230

Abbildung 93: Auswertung Metamodellbeziehungen............................................................232

Abbildung 94: Impact-Analyse (Szenario „Plattform fällt aus“) ...........................................233

Tabellenverzeichnis xx

Tabellenverzeichnis

Tabelle 1: Richtlinien für die Erfüllung des Design-Science-Paradigma.................................10

Tabelle 2: Modellierungskonstrukte für das Metamodell ........................................................22

Tabelle 3: Modellierungskonstrukte für das Vorgehensmodell ...............................................24

Tabelle 4: Bewertungskriterien ................................................................................................47

Tabelle 5: Übersicht der analysierten Ansätze .........................................................................49

Tabelle 6: Übersicht über die Bewertung existierender Ansätze .............................................87

Tabelle 7: Domänenspezifische Literaturquellen .....................................................................90

Tabelle 8: Metaentitätstypen der Strategieebene....................................................................108

Tabelle 9: Symbole der Strategieebene ..................................................................................109

Tabelle 10: Metaentitätstypen der Organisationsebene..........................................................131

Tabelle 11: Symbole der Organisationsebene ........................................................................132

Tabelle 12: Metaentitätstypen der Informationssystemebene ................................................149

Tabelle 13: Symbole der Informationssystemebene...............................................................150

Tabelle 14: Metaentitätstypen der Infrastrukturebene............................................................152

Tabelle 15: Symbole der Infrastrukturebene ..........................................................................152

Tabelle 16: Metaentitätstypen der IT-Servicesicht.................................................................156

Tabelle 17: Symbole der IT-Servicesicht ...............................................................................156

Tabelle 18: Metaentitätstypen der SOA-Sicht........................................................................161

Tabelle 19: Wesentliche Anforderungen an die Werkzeugunterstützung ..............................183

Tabelle 20: Übersicht über kommerziell verfügbare Werkzeuge...........................................184

Tabelle 21: Erfüllung der wichtigsten Kriterien.....................................................................185

Tabelle 22: Modelltyp Geschäftsnetzwerk .............................................................................192

Tabelle 23: Fakten zur Winterthur Group ..............................................................................210

Tabelle 24: Vergleich Metaentitätstypen Ablauforganisation................................................217

Tabelle 25: Vergleich Metaentitätstypen Aufbauorganisation...............................................218

Tabelle 26: Vergleich Metaentitätstypen Softwarekomponenten ..........................................219

Tabelle 27: Metamodellbasierter Vergleich mit ARIS...........................................................236

Tabelle 28: Metamodellbasierter Vergleich mit MEMO .......................................................238

Tabellenverzeichnis xxi

Tabelle 29: Metamodellbasierter Vergleich mit SOM ...........................................................240

Tabelle 30: Merkmalbasierte Evaluierung .............................................................................243

Kurzfassung xxii

Kurzfassung

Die Entwicklung einer Unternehmensarchitektur ist eine fundamentale Voraussetzung für die

Bereitstellung von Informationssystemen, die mit den organisatorischen und strategischen

Richtlinien des Unternehmens konsistent sind. Eine für das gesamte Unternehmen definierte

und zentral gepflegte Architektur trägt dazu bei, redundante und inkonsistente Informationen

über das Unternehmen zu beseitigen. Sie dient als zentrales Koordinationsinstrument zwi-

schen unterschiedlichen Unternehmensbereichen für die integrierte Gestaltung von Informati-

onssystemen, Organisationsstrukturen und Unternehmensstrategien. Sowohl in der Praxis als

auch in der Wissenschaft fehlt bisher ein allgemein akzeptiertes Verständnis der wesentlichen

Ebenen, Elemente und Beziehungen einer Unternehmensarchitektur. Vor allem existiert für

diese keine umfassende, (semi-)formale Spezifikation. Ziel der vorliegenden Arbeit ist daher

die Entwicklung eines Ansatzes zur Modellierung der Unternehmensarchitektur und dessen

Abbildung in einem kommerziellen Metamodellierungswerkzeug zur Sicherstellung der An-

wendbarkeit. Im Mittelpunkt steht dabei zum einen die Definition eines ebenen- und sichten-

übergreifenden Metamodells, das die grundlegenden Elemente eines Unternehmens sowie

deren Beziehungen festlegt. Zum anderen wird ein Software-Prototyp mit Hilfe des Metamo-

dellierungswerkzeuges erstellt. Damit sollen die Konsistenz und Umsetzbarkeit des entwi-

ckelten Metamodells gezeigt werden. Darüber hinaus erfolgt eine multiperspektivische Evalu-

ation des Prototyps und des zugrunde liegenden Metamodells in Form einer Fallstudie sowie

einer natürlichsprachlichen, merkmalbasierten und metamodellbasierten Evaluierung. Den

Forschungsrahmen der Dissertation bilden das Business Engineering sowie die Prinzipien des

Methoden-Engineering. Der entwickelte Ansatz umfasst die drei Gestaltungsebenen „Ge-

schäftsstrategie“, „Organisation“ und „Informationssystem“. Der Dissertation liegen die kon-

struktiven Forschungsansätze „Deduktion“, „Modellierung“ sowie „Entwicklung und Test

eines Prototyps“ zugrunde. Sie lässt sich auch dem Design-Science-Paradigma zuordnen,

welches im Umfeld des „Information Systems Research“, dem angelsächsischen Pendant der

Wirtschaftsinformatik, anerkannt ist. Ausgangspunkt für die Entwicklung des Ansatzes bilden

eine bereits bestehende Methode, eine umfangreiche Literaturanalyse sowie ein detaillierter

Vergleich existierender Ansätze.

Schlüsselwörter: Unternehmensarchitektur, Modellierung, Metamodellierung, Business

Engineering, Methoden-Engineering, Werkzeugunterstützung, Softwareprototyp,

Metamodellierungsplattform

Abstract xxiii

Abstract

The design of information systems as well as the redesign of corporate strategies and

organizational structures are both challenging tasks. They need to be coordinated in order to

provide information systems that are consistent with the strategic and organizational

guidelines of the enterprise. To describe the structure of information systems, both from a

technical and a business view, the design of information systems is increasingly integrated

with adequate methods on other levels of abstraction and discussed as a broad or holistic

design concept called “Enterprise Architecture”. The goal of enterprise architecture is to

represent the whole structure of an enterprise and its information systems in order to support

the future development and design of the enterprise. In recent years, both in science as well as

in practice, various approaches for modeling the enterprise architecture have been developed

on different levels of abstraction. These different levels reflect the well known cultural

differences between business and information technology professionals. Holistic approaches

use a framework or a hierarchy of design layers to structure the different views on an

enterprise. These approaches are often rather abstract, do not consider all design layers, or

provide various views on the enterprise without defining specific modeling languages. Many

of these approaches have less elaborated meta models, which integrate the models on different

layers. Furthermore, some of them are too much focused on domain-specific concepts (e.g.

software development or business process management). This dissertation develops an

approach for the design of enterprise architectures, which provides models on all relevant

design layers and gives a holistic view on all key artefacts and their relationships within an

enterprise that are relevant for strategic decisions in the overlapping area between business

and IT (e.g. services, performance indicators, business processes, organizational units,

applications, software components). The applicability of the proposed approach and its meta

model is shown by means of a software prototype that is tested in practice. The research

model is based on the Business Engineering (BE) approach and the guidelines of Method

Engineering (ME). It incorporates the three BE design layers business strategy, organization,

and information system. The underlying constructive research methodologies are deduction,

modeling, as well as development and test of a prototype. These are considered valid research

approaches of Information Systems Research (ISR) in the German-speaking community.

Furthermore, this dissertation can also be assigned to design science, a generally accepted

research approach in the Anglo-Amercian ISR community. The starting point for the

development of the meta model and prototype is an existing method and a comprehensive

analysis of related work in the field of enterprise modeling.

Key Words: Enterprise Architecture, Modeling, Metamodeling, Business Engineering,

Method Engineering, Tool Construction, Software Prototype, Metamodeling Platform

Einführung 1

1 Einführung

1.1 Problemstellung und Handlungsbedarf

Die Planung, Einführung und der Betrieb von Informationssystemen stellen eine grosse Her-

ausforderung dar. Gerade Unternehmen mit überwiegend immateriellen Produkten, wie bei-

spielsweise Finanzdienstleister, sind bei der Entwicklung, dem Vertrieb und der Abwicklung

ihrer Produkte bzw. Leistungen stark an informationsverarbeitende Systeme gebunden.1 Zu-

dem müssen sich Unternehmen des Informationszeitalters dessen bewusst sein, dass neue In-

formationstechnologien ein „Enabler“ für neue Geschäftsmodelle bzw. -lösungen sein kön-

nen.2 Strategische und organisatorische Veränderungen müssen deshalb die Informationssys-

teme mit einbeziehen. Umgekehrt müssen aber auch bei der Einführung neuer Informations-

technologien strategische und organisatorische Aspekte berücksichtigt und gegebenenfalls

verändert werden.

Der Entwurf von Informationssystemen sowie die Umgestaltung von Unternehmensstrategien

und Organisationsstrukturen sind für sich genommen bereits herausfordernde Aufgaben. Sie

bedürfen zudem einer Koordination, um Informationssysteme bereitstellen zu können, die mit

den strategischen und organisatorischen Richtlinien des Unternehmens konsistent sind.3 Um

die Struktur von Informationssystemen sowohl aus technischer als auch aus fachlicher Sicht

beschreiben zu können, wird die Gestaltung der Informationssystem-Architektur zunehmend

mit entsprechenden Methoden auf anderen Betrachtungsebenen integriert und als umfassendes

Gestaltungskonzept „Unternehmensarchitektur“ („Enterprise Architecture”) diskutiert.4 Das

Ziel einer Unternehmensarchitektur ist es, die Strukturen des Unternehmens und seiner In-

formationssysteme ganzheitlich abzubilden und damit die zukünftige Entwicklung und Ge-

staltung des Unternehmens zu unterstützen.5

In den letzten Jahren sind sowohl in der Wissenschaft als auch in der Praxis zahlreiche Ansät-

ze zur Modellierung der Unternehmensarchitektur auf unterschiedlichen Abstraktionsebenen

entwickelt worden.6 Diese unterschiedlichen Abstraktionsebenen und Sichten auf ein Unter-

nehmen reflektieren die unterschiedlichen Fachkenntnisse und Interessenslagen zwischen

Mitarbeitern aus den Fachabteilungen und Mitarbeitern aus dem IT-Bereich.7

1 Vgl. Winter (2005), S. 575.

2 Vgl. Baumöl et al. (2005), Kalakota/Robinson (2001) und Orlikowski/Barley (2001).

3 Vgl. Frank (2002), S. 1.

4 Vgl. Schwinn/Winter (2005), S. 587.

5 Vgl. Krcmar (2003), S. 39f.

6 Vgl. z.B. OMG (2003b), Firesmith et al. (1998), Teubner (1999), Frese (1995), Heinrich (2000).

7 Vgl. Frank (2002), S. 2.

Einführung 2

Ansätze zur Gestaltung der Anwendungssysteme sind z.B. das Software Engineering8, Infor-

mation Systems Engineering9 und Information Management10. Aufgrund ihrer Mikrosicht

sind diese Ansätze nur bedingt für eine umfassende Abbildung der Unternehmensarchitektur

geeignet. Sie berücksichtigen meist nicht oder nur unzulänglich die Modellierung der Unter-

nehmensstrategie und der Geschäftsprozesse.11 Generelle Modellierungssprachen wie bei-

spielsweise UML12 oder OML13 ermöglichen im Prinzip auch die Abbildung von Geschäfts-

abläufen und Organisationsstrukturen. Sie sind aber primär für die Entwicklung von Soft-

waresystemen entworfen worden und bieten daher keine Konzepte und grafischen Repräsen-

tationen, die für alle Bereiche der Unternehmensmodellierung geeignet sind. Aspekte der Un-

ternehmensorganisation sowie der strategischen Unternehmensführung werden nur in gerin-

gem Umfang berücksichtigt. Zudem bietet beispielsweise die UML eine Vielzahl unterschied-

licher Modelle, deren Zusammenhänge oftmals nicht klar definiert sind.14 Sie sind daher für

Mitarbeiter aus den Fachbereichen nur schwer verständlich.

Ansätze aus dem Bereich der Organisationstheorie15 (z.B. Business Process Reengineering)

und der strategischen Unternehmensführung16 (z.B. „Market based View“, „Resource based

View“, „Value based View“) ermöglichen dagegen zwar die Gestaltung von Unternehmens-

strategien und Organisationsstrukturen. Sie basieren meist auf einfachen, grafischen Model-

len, mit denen grundlegende Sachverhalte und Beziehungen leicht kommunizierbar und auf

hohem abstraktem Niveau dargestellt werden können. Strategie- und Organisationsmodelle

basieren aber in der Regel auf unterschiedlichen Konzepten und haben keine Gemeinsamkei-

ten mit den konzeptionellen Modellen der Softwareentwicklung.

Umfassendere Ansätze17 (z.B. ARIS, SOM, Zachman) verwenden einen Bezugsrahmen oder

eine Hierarchie von Modellierungsebenen, um die verschiedenen Perspektiven auf das Unter-

nehmen zu strukturieren. Diese sind allerdings meist auf einem eher abstrakten Niveau ange-

setzt, berücksichtigen nicht alle relevanten Modellierungsebenen und/oder stellen eine Viel-

zahl unterschiedlicher Sichten auf das Unternehmen zur Verfügung (wie z.B. Daten, Funktio-

nen, Personen und Standorte), ohne konkrete Modellierungssprachen und -techniken zu spezi-

8 Vgl. z.B. Balzert (2000).

9 Vgl. z.B. van Hee (1994).

10 Vgl. z.B. Heinrich (2002c), Teubner (1999).

11 Vgl. z.B. Jacobson et al. (1994).

12 Vgl. OMG (2003b).

13 Vgl. Firesmith et al. (1998).

14 Vgl. hierzu z.B. Jonkers et al. (2004), S. 262.

15 Vgl. z.B. Frese (1995), Hammer/Champy (1993), Hess/Brecht (1996) und Teubner (1999), S. 125-140.

16 Vgl. z.B. Porter (1999), Rockart (1979), Grant (1998), Heinrich (2000), S. 28-38, Hahn (1997), S. 157-161

und Müller-Stewens/Lechner (2003). 17

Vgl. z.B. Ferstl/Sinz (1995), Krcmar (1990), Österle/Winter (2003), Scheer (1998), Opengroup (2002), FEA (2001) und Zachman (1987).

Einführung 3

fizieren. Einige dieser Ansätze stellen vor allem die Gestaltung der Geschäftsprozesse in den

Mittelpunkt und/oder fokussieren zu stark auf softwareentwicklungsrelevante Aspekte.

Des Weiteren stehen bei vielen Ansätzen die einzelnen, auf unterschiedlichen Modellierungs-

ebenen erstellten Modelle unabhängig nebeneinander und sind nicht durchgängig miteinander

integriert, z.B. durch ein umfassendes, ebenenübergreifendes Metamodell. Ein solches Meta-

modell ist allerdings eine wesentliche Voraussetzung für die systematische Integration und

damit Konsistenz der einzelnen Teilsichten. Bisher existieren keine Konzepte, die die Zu-

sammenhänge zwischen den verschiedenen Modellierungsebenen definieren.18 Die Definition

dieser Zusammenhänge würde die Konsistenz zwischen Modellen auf unterschiedlichen Ebe-

nen gewährleisten und die Durchführung von Impact-Analysen ermöglichen. Damit wäre

auch eine wichtige Grundlage für die systematische, modellbasierte Lösung von Problemstel-

lungen des IT-Business-Alignment19 geschaffen.

Für die praktische Anwendung eines bestimmten Ansatzes ist entscheidend, dass entspre-

chende unterstützende (Software-)Werkzeuge verfügbar sind, die die Modellierung, Speiche-

rung, Darstellung und Weiterentwicklung von Modellen der Unternehmensarchitektur ermög-

lichen.20 Da die Methoden zur Gestaltung der Unternehmensarchitektur immer umfassender

werden, wird zunehmend auch nach Werkzeugen verlangt, welche die durchgängige Abbil-

dung und Analyse von Geschäftsstrategien, Organisationsstrukturen, Geschäftsprozessen und

Applikationen eines Unternehmens unterstützen.21 Im Vordergrund steht dabei vor allem die

Abbildung der Gesamtzusammenhänge zwischen den einzelnen Gestaltungsebenen, die in den

meisten Fällen ein nur schwer zu erkennendes und zu verstehendes System darstellen. Werden

diese Zusammenhänge nicht erkannt und verstanden, so ist die Änderung des Systems immer

mit einer gewissen Unsicherheit behaftet, da die Auswirkungen nicht abgeschätzt werden

können.22

Viele Unternehmen verwenden bereits einfache Visualisierungswerkzeuge, wie z.B. Micro-

soft Visio oder Powerpoint, um ihre Architektur zu dokumentieren.23 Allerdings kann dadurch

die Konsistenz und Redundanzfreiheit in den verschiedenen Dokumenten nur schwer über-

prüft und eingehalten werden. Wenn beispielsweise ein Geschäftsprozess oder eine Applikati-

on in mehreren Modellen auftaucht, dann müssen bei einer Änderung des Geschäftsprozesses

bzw. der Applikation alle Modelle aktualisiert werden. Dies birgt die Gefahr von Inkonsisten-

zen, da die Änderungen in allen Modellen bei diesen Werkzeugen manuell erfolgen müssen.

Darüber hinaus können mit diesen Werkzeugen keine Impact-Analysen durchgeführt werden.


19 Vgl. Henderson/Venkatraman (1993).

20 Vgl. Frank (2002), S.4.

21 Vgl. Schekkerman (2004), S. 201.

22 Vgl. James (2005a), S. 2.

23 Vgl. IFEAD (2004), S. 26.

Einführung 4

1.2 Ziele und Adressaten der Arbeit

Ausgehend von den im vorhergehenden Abschnitt beschriebenen Herausforderungen werden

im Folgenden die Forschungsfrage sowie die Ziele und Adressaten des Dissertationsvorha-

bens definiert.

Im Kompetenzzentrum Bankenarchitekturen im Informationszeitalter (CC BAI)24 wurde ge-

meinsam mit Partnerunternehmen aus der Finanzindustrie entsprechend den Grundsätzen des

Business Engineering25 und dem Methoden-Engineering26 eine Methode zur Gestaltung der

Unternehmensarchitektur erarbeitet (BAI-Methode). Da diese bereits einen weitgehend um-

fassenden Ansatz darstellt, der alle relevanten Gestaltungsebenen eines Unternehmens be-

rücksichtigt sowie auf allen Ebenen Metamodelle und Vorgehensweisen definiert, dient sie als

Ausgangsbasis für die vorliegende Arbeit.

Eine weitere Grundlage bildet der in dieser Arbeit durchgeführte, detaillierte Vergleich zwi-

schen bereits existierenden Ansätzen der Unternehmensmodellierung. Die dabei identifizier-

ten Konzepte sowie Stärken und Schwächen sollen anschliessend in die Spezifizierung des in

der vorliegenden Arbeit präsentierten Ansatzes und dessen Implementierung einfliessen.

Ziel ist es, die BAI-Methode im Sinne der im Grundlagenteil identifizierten Anforderungen

sowie der Stärken und Schwächen bereits existierender Ansätze genauer zu definieren und zu

erweitern sowie in einem Softwareprototyp abzubilden. Dabei sind insbesondere alle Gestal-

tungsebenen einer Organisation bzw. eines Unternehmens einzubeziehen und eine möglichst

breite Darstellung der Sachverhalte mit einem geringen Fokus auf softwareentwicklungsrele-

vante Aspekte zu erreichen. Als Ergebnis soll ein ebenenübergreifendes Metamodell zur kon-

sistenten Abbildung aller Artefakte und deren Zusammenhänge vorliegen, die für strategische

Entscheidungen im Schnittbereich von Fachbereich und IT relevant sind (z.B. Leistungssys-

tem, Zielsystem, Prozesse, Organisationseinheiten und Applikationen). Da es nicht möglich

ist, alle Artefakte in einem Totalmodell abzubilden und ausreichend zu pflegen, wird ein sinn-

voller Aggregationsgrad angestrebt.27

Der in dieser Arbeit entwickelte Ansatz soll bereits existierende Ansätze, die auf einen be-

stimmten Anwendungsbereich fokussiert sind und einen hohen Detaillierungsgrad besitzen,

nicht ersetzen, sondern deren Konzepte in aggregierter Form abbilden und miteinander integ-

rieren. Der Fokus liegt dabei auf der Modellierung des Ist-Zustandes der Unternehmensarchi-

tektur und nicht auf deren Transformation. Da allerdings für zukünftige Transformationspro-

24 Vgl. Leist/Winter (2002).

25 Vgl. Österle/Winter (2003).

26 Vgl. Heym (1993) und Brinkkemper (1996).

27 Viele Unternehmen sind in der Vergangenheit bereits während der Modellierung eines unternehmensweiten

Datenmodells (Totalmodells) an der hohen Komplexität dieser Aufgabe gescheitert. In anderen Fällen wurden die erstellten Modelle nicht mehr gepflegt oder nicht konsequent implementiert. Vgl. hierzu auch Frie/Auth (2001), S. 5.

Einführung 5

jekte konsistente Informationen über die aktuellen Strukturen des Unternehmens vorliegen

sollten, stellt die Entwicklung einer einheitlichen Terminologie in Form eines Metamodells

eine wichtige Grundlage dafür dar. Gestaltungsrichtlinien und Handlungsanweisungen für die

Transformation der Unternehmensarchitektur sind nicht Teil dieser Arbeit und müssen in

nachfolgenden Arbeiten entwickelt werden.

Um die Konsistenz, Umsetzbarkeit und Anwendbarkeit des entwickelten Ansatzes zu illustrie-

ren, wird dieser in einem kommerziellen Metamodellierungswerkzeug abgebildet. Der daraus

entstehende (Software-)Prototyp28 wird zuletzt anhand eines Fallbeispiels in der Praxis getes-

tet. Darüber hinaus erfolgt eine merkmalbasierte und metamodellbasierte Evaluierung der in

dem Ansatz verwendeten Konzepte. Im Hinblick auf einen iterativen Entwicklungsprozess,

die Orientierung an den Anforderungen der Anwender sowie die Notwendigkeit zur Gewin-

nung von Managementunterstützung wird die Erstellung eines Prototyps als wichtige Grund-

lage für die Akzeptanz des Ansatzes in der Praxis gesehen, da dieser einerseits die Möglich-

keit einer schnelleren Überprüfung von Entwurfsentscheidungen bietet sowie andererseits die

Kommunikation zwischen (Methoden-)Entwicklern, Fachbereichen und dem Management

erleichtert.

Anhand der dargestellten Herausforderungen im Umfeld der Unternehmensmodellierung lässt

sich die Forschungsfrage des Dissertationsvorhabens wie folgt formulieren:

Wie kann die BAI-Methode zu einem Ansatz für die Modellierung der Unternehmensarchitek-

tur erweitert und mit Hilfe eines Metamodellierungswerkzeuges implementiert werden?

Im Einzelnen verfolgt die Arbeit somit folgende Gestaltungsziele:

• Metamodelle: Für die drei Gestaltungsebenen „Geschäftsstrategie“, „Organisation“ und

„Informationssystem“ sind jeweils einzelne Metamodelle zu spezifizieren und deren Dar-

stellungsmöglichkeiten zu beschreiben.

• Ebenenübergreifendes Metamodell: Zwischen den Metamodellen der drei Ebenen sind die

Zusammenhänge klar zu definieren, so dass als Ergebnis ein konsistentes, ebenenübergrei-

fendes Metamodell vorliegt.

• Konstruktion des Prototyps: Die Metamodelle sollen mit Hilfe eines Meta-

Modellierungswerkzeuges prototypisch abgebildet werden. Dabei ist auf die notwendigen

Anpassungen des Werkzeuges einzugehen. Darüber hinaus ist die Darstellung der einzel-

nen Metamodellobjekte zu spezifizieren.

28 Ein Prototyp kann als eine spezielle Ausprägung eines ablauffähigen Softwaresystems, welches

ausgewählte Aspekte des Zielsystems im Anwendungsbereich realisiert, definiert werden. Er dient als Kommunikationsbasis für alle beteiligten Gruppen (Benutzer, Entwickler und Wissenschaftler) und vermittelt experimentelle und praktische Erfahrungen für die Auswahl zwischen Gestaltungsalternativen. Des Weiteren dient er in der Wissenschaft vor allem dazu, Ansätze und Konzepte auf ihre Umsetzbarkeit zu testen. Vgl. Rechenberg/Pomberger (1999), S. 779.

Einführung 6

• Test des Prototyps: Anhand eines Fallbeispiels wird der entwickelte Prototyp beschrieben

und getestet.

Die Arbeit richtet sich an Personen, die sich in Theorie und Praxis mit der Entwicklung von

Ansätzen und unterstützenden Werkzeugen für die Modellierung von Unternehmensarchitek-

turen auseinandersetzen. Für die Praxis können folgende primäre Nutzenpotenziale genannt

werden:

• die Bereitstellung eines umfassenden Ansatzes zur Gestaltung und Abbildung der Unter-

nehmensarchitektur sowie eine Übersicht und Bewertung bereits existierender Ansätze

und aktuell verfügbarer Werkzeuge,

• die Bereitstellung eines Metamodells, das in der Praxis insbesondere als Basis einer ein-

heitlichen Kommunikation verwendet werden kann,

• die Bereitstellung eines Softwareprototyps für den Test und die Evaluierung des entwi-

ckelten Ansatzes im eigenen Unternehmensumfeld.

Darüber hinaus bietet es Herstellern von Werkzeugen für die Unternehmensmodellierung die

Möglichkeit, ihre Werkzeuge besser an die Anforderungen eines umfassenden, ebenenüber-

greifenden Ansatzes anzupassen.

Für Wissenschaftler, die sich mit den Themen Unternehmensmodellierung, Metamodellierung

und deren Werkzeugunterstützung beschäftigen, bietet die Arbeit folgende primäre Nutzenpo-

tenziale:

• Herleitung und Diskussion eines Ansatzes sowie eines umfassenden Metamodells zur

Gestaltung der Unternehmensarchitektur,

• Beschreibung, wie anhand eines Prototyps ein Ansatz validiert werden kann,

• Verwendung des Prototyps in der Lehre, um die theoretischen Ansätze und Ideen der

Unternehmensmodellierung anschaulich und praktisch vermitteln zu können.

Weitere Nutzenpotenziale bestehen für Wissenschaftler und Praxisvertreter, die andere Ansät-

ze in dem für die Umsetzung verwendeten Werkzeug abbilden möchten.

1.3 Forschungsmethodik

Die vorliegende Arbeit ist der Wirtschaftsinformatik zuzuordnen. Nach der Wissenschaftli-

chen Kommission Wirtschaftsinformatik sind Informations- und Kommunikationssysteme

(IKS) in Wirtschaft und Verwaltung Gegenstand der Wirtschaftsinformatik.29 IKS werden

dabei als soziotechnische Systeme aufgefasst, die menschliche und maschinelle Komponenten

(Teilsysteme) als Aufgabenträger umfassen, die voneinander abhängig sind, ineinander grei-

29 Vgl. auch im Folgenden WKWI (1994) und Braun et al. (2004).

Einführung 7

fen und/oder zusammenwirken. Im Mittelpunkt der Untersuchungen der Wirtschaftsinforma-

tik steht die Unterstützung bei der Erfüllung betrieblicher Aufgaben. IKS werden in Organisa-

tionen implementiert, um die Effektivität und die Effizienz der Prozesse innerhalb dieser Or-

ganisation zu verbessern.30 Die Forschung muss dabei die Zusammenhänge zwischen Ge-

schäftsstrategie, Organisationsstruktur und IKS berücksichtigen. Diese Zusammenhänge ge-

winnen zunehmend an Bedeutung, da die Informationstechnologie als „Enabler“ neuer Ge-

schäftsstrategien und Organisationsstrukturen gesehen wird.31

Ihre Ursprünge hat die Wirtschaftsinformatik sowohl in den Wirtschaftswissenschaften als

auch in der Informatik.32 Während die Wirtschaftswissenschaften primär durch empirische

Forschungsansätze geprägt sind, verwendet die Informatik vor allem formalwissenschaftliche

Ansätze zur Konstruktion technischer Systeme. Aufgrund dieser unterschiedlichen for-

schungsmethodischen Ausrichtung der Mutterdisziplinen kommt in der Wirtschaftsinformatik

eine Vielzahl unterschiedlicher Forschungsmethoden zum Einsatz.33

König et al. ermittelten im Jahr 1996 im Zuge einer Delphi-Studie34, welche grundlegenden

Forschungsmethoden die Wirtschaftsinformatik in den nächsten Jahren verwenden soll, um

ihre Wettbewerbsposition gegenüber der Betriebswirtschaftslehre und der Informatik zu be-

haupten. Als wesentliche konstruktive Methoden wurden „Entwicklung und Test eines Proto-

typs“, „Simulation“, „Modellierung“, „Deduktion“, „Learning by Doing“ und „Kreativitäts-

techniken“ ermittelt.

Die vorliegende Arbeit entstand am Institut für Wirtschaftsinformatik der Universität St. Gal-

len (IWI-HSG) als Resultat angewandter, konstruktiver Forschung. Die Forschung am IWI-

HSG ist in Form so genannter Kompetenzzentren organisiert. Zusammen mit Unternehmens-

vertretern werden dabei in Workshops und bilateralen Projekten Lösungsansätze zu überge-

ordneten Forschungsthemen erarbeitet. Die Ergebnisse der Forschungsarbeit bestehen aus

Artefakten, wie z.B. Methoden und Modellen.

Das Dissertationsvorhaben baut auf bereits am IWI-HSG erarbeiteten Ergebnissen auf. Die im

Kompetenzzentrum BAI35 entwickelte Methode und deren Modelle bilden die Grundlage für

das Dissertationsprojekt. Diese Methode wird basierend auf einem Vergleich existierender

Ansätze genauer spezifiziert und erweitert sowie in Form eines Software-Prototyps abgebil-

det. Anhand eines Fallbeispiels wird der Prototyp anschliessend getestet. Dem Dissertations-

vorhaben können somit die konstruktiven Forschungsansätze „Deduktion“, „Modellierung“

sowie „Entwicklung und Test eines Prototyps“ zugrunde gelegt werden.

30 Vgl. Hevner et al. (2004), S. 75.

31 Vgl. z.B. Kalakota/Robinson (2001), Orlikowski/Barley (2001) und Österle/Winter (2003).

32 Vgl. Becker et al. (2003), S. 3.

33 Vgl. Becker et al. (2003), S. 3.

34 Vgl. König et al. (1996) und Braun et al. (2004).


Einführung 8

Auch im Umfeld des „Information Systems Research (ISR)“, dem angelsächsischen Pendant

der Wirtschaftsinformatik, wird der Konstruktion von Artefakten eine zunehmende Bedeu-

tung beigemessen, wie das Design-Science-Paradigma zeigt.36 Das Dissertationsvorhaben

lässt sich somit auch dem Design-Science-Paradigma zuordnen, welches im Folgenden ge-

nauer dargestellt wird (vgl. Abbildung 1).37

Das Design-Science-Paradigma ist wie folgt definiert: „The design-science paradigm is fun-

damentally a problem-solving paradigm. It seeks to create innovations that define the ideas,

practices, technical capabilities, and products through which the analysis, design, implementa-

tion, management, and use of information systems can be effectively and efficiently accom-

plished“.38 Ziel des Paradigmas ist die Lösung bestimmter organisatorischer Probleme durch

die Konstruktion innovativer Artefakte. Artefakte können üblicherweise Konstrukte (z.B.

Begriffe und Symbole), Modelle (z.B. Abstraktionen und Abbildungen), Methoden (z.B. Al-

gorithmen und Vorgehensweisen) oder Instanzen (z.B. implementierte oder prototypische

Systeme) sein. Die Artefakte werden in strukturierter Form repräsentiert, z.B. in Form von

Software, formaler Logik, mathematischen Formeln oder natürlichsprachlichen Beschreibun-

gen.

Abbildung 1: Information Systems Research Framework39

Im Gegensatz zum Design-Science-Paradigma steht beim Behavioral-Science-Paradigma die

Entwicklung und Validierung von Theorien im Mittelpunkt. In der Regel werden bereits exis-

tierende Artefakte betrachtet, die in einem bestimmten organisatorischen Umfeld eingesetzt

werden. Theorien versuchen bestimmte Phänomene zu erklären, die in Verbindung mit dem

36 Vgl. hierzu Hevner et al. (2004) und die im Februar 2006 durchgeführte Konferenz zum Thema „Design

Science Research in Information Systems and Technology“ (http://ncl.cgu.edu/designconference/). 37

Vgl. auch im Folgenden Hevner et al. (2004). 38

Vgl. Hevner et al. (2004), S. 76. 39

Vgl. Wortmann (2005), S. 6 und Hevner et al. (2004), S. 80.

Einführung 9

Einsatz eines bestimmten Artefakts auftreten.40 Das von HEVNER ET AL. vorgeschlagene „In-

formation Systems Research Framework“ soll dazu dienen, die Informationssystemforschung

zu verstehen, durchzuführen und zu evaluieren, indem das Design-Science- und Behavioral-

Science-Paradigma miteinander kombiniert werden. Es besteht aus den folgenden Elemen-

ten:41

• Umfeld: Das Umfeld legt den Gegenstandsbereich der Forschung fest. Es besteht aus den

Dimensionen Mensch, Organisation und Technologie.

• Anforderungen: Das Umfeld beschreibt Ziele, Aufgaben, Probleme und Möglichkeiten

und definiert damit Anforderungen an die Forschung aus Sicht der betroffenen Menschen

innerhalb der Organisation. Durch die Ausrichtung der Forschung an den Anforderungen

des Umfeldes wird die Relevanz der Forschung garantiert.

• Forschung: Die Informationssystemforschung wird mit Hilfe von zwei sich ergänzenden

Ansätzen durchgeführt. Die konstruktionsorientierte Forschung (Design Science) kon-

struiert und beurteilt Artefakte, die die aus dem Umfeld abgeleiteten Anforderungen sowie

Ergebnisse der behavioristischen Forschung umsetzen. Die behavioristische Forschung

untersucht dagegen die Phänomene, die durch den Einsatz von zuvor konstruierten Arte-

fakten entstehen, und entwickelt und validiert daraus entsprechende Theorien.

• Wissensbasis: Die Wissensbasis stellt dem Forscher Grundlagen und Methodologien zur

Verfügung, die von früheren Arbeiten der Informationssystemforschung oder von Arbei-

ten aus Referenzdisziplinen stammen. Die Grundlagen bestehen beispielsweise aus Theo-

rien, Bezugsrahmen, Methoden und Modellen, die für die Konstruktion von Artefakten

verwendet werden können. Methodologien geben Richtlinien für die Validierung von

Theorien und Artefakten vor.

• Anwendbares Wissen: In einem konkreten Forschungsprozess verwendet der Forscher

Teile der Wissensbasis. Durch die konsequente, kontextbezogene Anwendung von Teilen

der Wissensbasis wird die Stringenz des Forschungsprozesses gewährleistet.

Die Ergebnisse der konstruktionsorientierten sowie der behavioristischen Forschungsarbeit

können anhand der Erfüllung der Anforderungen eines bestimmten Umfeldes bzw. anhand

des Beitrags zur Wissensbasis beurteilt werden.

Hevner et al. haben basierend auf ihrem Bezugsrahmen sieben Richtlinien aufgestellt, an de-

nen sich der Forscher bei einem bestimmten Forschungsprojekt orientieren kann, um erfolg-

reich und effektiv Design-Science-Forschung zu betreiben. Für eine vollständige Design-

Science-Forschungsarbeit sollte jede der sieben Richtlinien zumindest ansatzweise adressiert

werden. Tabelle 1 zeigt, wie die vorliegende Arbeit die einzelnen Richtlinien adressiert.

40 Vgl. Hevner et al. (2004), S. 77.

41 Vgl. Hevner et al. (2004), S. 79-80.

Einführung 10

Richtlinien für die Erfüllung des Design-Science-Paradigma

Richtlinie Beschreibung Adressierung in der vorliegenden Arbeit

1. Konstruktion

Artefakt

Die DS-Forschung verlangt die Ent-

wicklung eines anwendbaren Arte-

fakts in Form einer Methode, eines

Modells oder einer Instanz.

Die konstruierten Artefakte sind der entwickelte

Ansatz zur Modellierung der Unternehmensarchitek-

tur sowie der implementierte Softwareprototyp.

2. Problemlösung

und Relevanz

Das Ziel der DS-Forschung ist die

Entwicklung technologiebasierter

Lösungen für wichtige und relevante

Probleme.

Die Relevanz ergibt sich aus der Bedeutung (Ziele

und treibende Kräfte) der Unternehmensarchitektur

sowie den Defiziten bestehender Ansätze und

Werkzeuge.

3. Bewertung des

Artefakts

Die Anwendung, Effektivität und

Qualität des Artefakts müssen strin-

gent und nachvollziehbar dargelegt

werden.

Das Metamodell wird in einem Prototyp implemen-

tiert und anhand eines Fallbeispiels getestet. Darüber

hinaus erfolgt eine metamodellbasierte sowie natür-

lichsprachliche und merkmalbasierte Evaluation.

4. Forschungsbeitrag Die DS-Forschung muss klar nach-

vollziehbare Ergebnisse liefern.

Der Forschungsbeitrag ist sichergestellt, wenn die

Defizite bestehender Ansätze und Werkzeuge adres-

siert werden konnten.

5. Stringenz

Die DS-Forschung verlangt bei der

Konstruktion und Bewertung eines

Artefakts die Einhaltung

forschungsmethodischer Grundsätze.

Es werden die konstruktiven Methoden Deduktion,

Modellierung sowie Entwicklung und Test eines

Prototyps angewendet.

6. Suchprozess

Die DS-Forschung ist ein Suchpro-

zess. Die endgültige Problemlösung

wird durch einen iterativen Prozess

erreicht.

Die Ergebnisse des Tests und der Evaluation sowie

das Feedback bei den Workshops fliessen in einem

iterativen Prozess in die Verbesserung des Prototyps

und Metamodells ein.

7. Kommunikation

der Ergebnisse

Die Ergebnisse müssen sowohl einem

technologieorientierten als auch

einem managementorientierten Publi-

kum vermittelt werden.

Die Ergebnisse werden in der Forschungsgemein-

schaft veröffentlicht sowie vor Vertretern der Partner-

unternehmen präsentiert.

Tabelle 1: Richtlinien für die Erfüllung des Design-Science-Paradigma42

1.4 Aufbau der Arbeit

In der Einführung wurden auf der Basis der Problemstellung und des identifizierten Hand-

lungsbedarfs die Zielsetzungen abgeleitet, die Adressaten festgelegt und die zugrunde liegen-

de Forschungsmethodik erläutert. Nach der Einführung befasst sich das folgende Kapitel zwei

mit den konzeptionellen Grundlagen der Dissertation. Hierzu werden zunächst relevante Be-

grifflichkeiten aus den Bereichen Methoden, Modelle und Unternehmensarchitektur erläutert.

Anschliessend folgt eine Beschreibung der wesentlichen Ziele und treibenden Kräfte der Un-

ternehmensarchitektur. Darauf aufbauend werden Anforderungen an den zu entwickelnden

Ansatz sowie die Werkzeugunterstützung formuliert. Im darauf folgenden Kapitel drei werden

die für das Dissertationsvorhaben relevanten Entwicklungen dargestellt. Zum einen wird ein

Überblick über Methoden zur Unternehmensmodellierung, die primär aus der Wissenschaft

stammen, gegeben. Zum anderen erfolgt eine Darstellung von Bezugsrahmen (Frameworks),

die in der Praxis am häufigsten zum Einsatz kommen und die von den meisten aktuell am

Markt verfügbaren Werkzeugen unterstützt werden. Im vierten Kapitel wird der eigene An-

42 In Anlehnung an Hevner et al. (2004), S. 83.

Einführung 11

satz zur Modellierung der Unternehmensarchitektur beschrieben. Dabei liegt der Fokus vor

allem auf der Definition eines Metamodells mit den wesentlichen Schlüsselelementen einer

Unternehmensarchitektur sowie deren Zusammenhänge. Die Beschreibung der Abbildung

dieses Metamodells mit Hilfe einer kommerziellen Metamodellierungsplattform folgt im Ka-

pitel fünf. Der daraus entstandene Software-Prototyp wird im Hinblick auf dessen wesentliche

Komponenten und Funktionalitäten vorgestellt. Zum Ende des Hauptteils wird eine multiper-

spektivische Evaluation des in dieser Arbeit vorgeschlagenen Ansatzes in Form einer Fallstu-

die sowie einer natürlichsprachlichen, merkmalbasierten und metamodellbasierten Evaluie-

rung durchgeführt. Abschliessend erfolgen eine Zusammenfassung der wesentlichen Ergeb-

nisse dieser Arbeit und deren kritische Würdigung sowie ein Ausblick auf zukünftige For-

schungs- und Entwicklungsmöglichkeiten. Die folgende Abbildung 2 visualisiert den Aufbau

der Arbeit.

EinführungProblemstellung und HandlungsbedarfForschungskonzeption

1. Kapitel

Einführu

ng

Gru

ndlagen

Konzeptionelle GrundlagenMethoden und ModelleUnternehmensarchitektur und WerkzeugunterstützungZiele und treibende KräfteKonsequenzen für das weitere Vorgehen

2. Kapitel

Vorhandene AnsätzeAuswahl der AnsätzeMethoden aus der WissenschaftBezugsrahmen aus der PraxisZusammenfassung und Übersicht der Bewertung

3. Kapitel

Hauptte

il

Eigener Ansatz zur Modellierung

der UnternehmensarchitekturModellierung auf StrategieebeneModellierung auf OrganisationsebeneModellierung auf InformationssystemebeneEbeneninterne und -übergreifende ZusammenhängeIntegration serviceorientierter Konzepte

4. Kapitel

Konstruktion eines PrototypsAbbildung mit Hilfe einer MetamodellierungsplattformAufbau und generelle Funktionalitäten des PrototypsErstellen von ModellenDurchgängigkeit und Abbildung der GesamtzusammenhängeAnalyse und Dokumentation der Modelle

5. Kapitel

Multiperspektivische EvaluationFallstudie bei der Winterthur GroupMetamodellbasierte EvaluationMerkmalbasierte und natürlichsprachliche Evaluation

6. Kapitel

Kritische Würdigung und AusblickErgebniszusammenfassungKritische WürdigungZukünftiger Forschungs- und Entwicklungsbedarf

7. Kapitel

Schluss

Abbildung 2: Aufbau der Arbeit

Konzeptionelle Grundlagen der Unternehmensmodellierung 12

2 Konzeptionelle Grundlagen der Unternehmens-

modellierung

In diesem Kapitel werden die begrifflichen Grundlagen der vorliegenden Arbeit gelegt. Für

die relevanten Themenbereiche Methoden, Modelle, Unternehmensarchitektur und Werk-

zeugunterstützung werden die in den späteren Kapiteln verwendeten Begriffe erläutert. An-

schliessend folgt eine Beschreibung der wesentlichen Ziele und treibenden Kräfte der Unter-

nehmensarchitektur. Darauf aufbauend werden zuletzt Anforderungen an den zu entwickeln-

den Ansatz und die Werkzeugunterstützung abgeleitet.

2.1 Methoden

Das „Information Systems Research (ISR)“ (angelsächsisches Pendant der Wirtschaftsinfor-

matik) wurde bisher vor allem durch einen behavioristischen Forschungsansatz dominiert.

Nach HEVNER wird in Zukunft aber auch das „Design Science (DS)“ als komplementärer For-

schungsansatz zunehmend an Bedeutung gewinnen.43 Während vor allem der Einsatz von

Informationssystemen als auch Konstrukte und Modelle sehr ausführlich und umfangreich in

der IS-Forschung diskutiert wurden, wurde die Konstruktion von Methoden nur selten adres-

siert.

Grundsätzlich sollten alle wissenschaftlichen Methoden eine bestimmte Forschungsfrage, die

Validität der Ergebnisse und die aktuelle Diskurswelt reflektieren.44 In Bezug auf den DS-

Ansatz wurden zahlreiche epistomologische Aspekte diskutiert.45 Nach GREIFFENBERG kön-

nen Methoden als Theorien der DS-Forschung betrachtet werden, sofern sie entsprechend

konstruiert und validiert wurden.46

In den folgenden beiden Abschnitten werden gängige Methodenverständnisse zusammenge-

fasst und deren übergreifende Charakteristika sowie Elemente identifiziert. Diese werden spä-

ter zur Beschreibung und Beurteilung bereits existierender Methoden sowie für die Konstruk-

tion des eigenen Methoden-Ansatzes verwendet.

2.1.1 Method Engineering

Die Gestaltung von Organisationsstrukturen erfordert, ebenso wie die Entwicklung von Soft-

waresystemen, ein ingenieurmässiges Vorgehen, um systematisch geplant und nachvollzogen

werden zu können.47 Sie verlangt somit eine Konstruktionssystematik. Die Anwendung von

43 Vgl. Hevner et al. (2004) sowie Abschnitt 1.3.

44 Vgl. Lührs (2001) und Yin (2002).

45 Vgl. z.B. Ferstl/Sinz (1998), Greiffenberg (2003) und Schütte et al. (1999).

46 Vgl. Greiffenberg (2003).

47 Vgl. Braun et al. (2005), S. 1297.


Methoden bildet den Ausgangspunkt ingenieurmässigen Vorgehens.48 Wer methodisch vor-

geht, kann die Mittel und Vorgehensweisen, die er zur Erreichung bestimmter Ziele gewählt

hat, begründen.49 Es herrscht weitestgehend Einigkeit darüber, dass der Einsatz von Methoden

die Grundlage für ein ingenieurmässiges Vorgehen darstellt.50 Dennoch existieren für den

Methodenbegriff eine Vielzahl unterschiedlicher Definitionen und Interpretationen. Führt man

die unterschiedlichen Verständnisse in ihrem Kern zusammen, kann eine Methode anhand der

folgenden wesentlichen Eigenschaften charakterisiert werden:

• Zielorientierung/Problemlösung als Ziel: Methoden sind stets zielorientiert. Sie geben

Vorschriften des Vorgehens bzw. Handelns, um festgelegte Ziele zu erreichen oder Pro-

bleme zu lösen.51

• Systematik/Planmässigkeit: Wenn Methoden Handlungsvorschriften bzw. Anleitungen

zur Lösung von Problemen oder zur Erreichung von Zielen liefern sollen, dann müssen sie

eine systematische Struktur aufweisen, damit sich konkrete Arbeitsschritte bzw. Aufgaben

zur Erreichung der Ziele ableiten lassen.52

• Prinzipienorientierung: Viele Definitionen verweisen auf die Relation der Methode zu

Prinzipien, wie grundsätzliche Gestaltungskriterien und/oder Strategien (z.B. Top-Down-

oder Bottom-Up-Ansatz).53

• Nachvollziehbarkeit: Von einigen Autoren wird die intersubjektive Nachvollziehbarkeit

von Methoden gefordert.54

BRINKKEMPER betrachtet die Entwicklung von Informationssystemen als ein Phänomen, das

starke Parallelen zu den Ingenieurswissenschaften aufweist.55 Er schlägt deshalb einen For-

schungsrahmen für Methoden und Werkzeuge für die Entwicklung von Informationssystemen

vor, genannt Methoden-Engineering (ME). Er definiert ME als eine Ingenieurswissenschaft,

die sich mit dem Entwurf, der Konstruktion und Anpassung von Methoden, Techniken und

Werkzeugen für die Entwicklung von Informationssystemen beschäftigt.56 Seine Arbeit kon-

zentriert sich überwiegend auf situationsbezogene Methoden, die er als Methoden definiert,

die für ein bestimmtes Projekt bzw. ein bestimmtes unternehmensindividuelles Umfeld konfi-

guriert sind. Die Konstruktion einer situationsbezogenen Methode erfordert standardisierte

48 Vgl. Greiffenberg (2003), S. 955.

49 Vgl. Lorenz (1995).

50 Vgl. Braun et al. (2005), S. 1297.

51 Vgl. Balzert (2000), Becker et al. (2001), Hesse et al. (1992), Stahlknecht/Hasenkamp (1999), Teubner

(1999) und Zelewski (1999). 52

Vgl. Becker et al. (2001), Greiffenberg (2003), Gutzwiller (1994), Heym (1993), Stahlknecht/Hasenkamp (1999), Zelewski (1999).

53 Vgl. Becker et al. (2001), Stahlknecht/Hasenkamp (1999) und Teubner (1999).

54 Vgl. Balzert (2000), Hesse et al. (1992) und Zelewski (1999).

55 Vgl. Brinkkemper (1996), S. 276.



Bausteine sowie Richtlinien, um die Bausteine richtig zusammensetzen zu können. Diese

Richtlinien werden durch so genannte Metamethoden definiert.57 Zudem sollte ein Konfigura-

tionsprozess festgelegt werden, der die Zusammensetzung der einzelnen Methodenbausteine

zu einer situationsbezogenen Methode anleitet. Da alle Projekte unterschiedlich sind, können

sie nicht durch eine Standardmethode unterstützt werden.58 Es stellt sich somit die Frage, wie

den Entwicklern von Informationssystemen eine adäquate methodische Vorgehensweise und

eine entsprechende Werkzeugunterstützung zur Verfügung gestellt werden können.

2.1.2 Methodenbestandteile

Das Methoden-Engineering wendet die Prinzipien von Methoden, bzw. den ingenieurmässi-

gen Entwurf von Informationssystemen, auf den Entwurf von Methoden an.59 Es schafft somit

eine zusätzliche Abstraktionsebene und bildet die Grundlage für die Entwicklung und Be-

schreibung von Methoden. GUTZWILLER und HEYM haben zahlreiche Ansätze des Methoden-

Engineering analysiert und daraus allgemeingültige Bestandteile der Methodenbeschreibung

sowie deren Beziehungen zueinander abgeleitet (vgl. Abbildung 3).60 Eine Methode umfasst

demnach die Elemente „Aktivität“, „Rolle“, „Ergebnisdokument“, „Metamodell“ und „Tech-

nik“.

Abbildung 3: Bestandteile einer Methode61

Durch eine Methode wird ein Vorgehen in Form von Aktivitäten festgelegt. Die Spezifikation

des Ablaufs dieser Aktivitäten hinsichtlich ihrer Reihenfolge und zulässiger Überlappungen

wird als Vorgehensmodell bezeichnet. Aktivitäten erzeugen und/oder verwenden ein oder

mehrere Ergebnisse. Ergebnisse werden in zuvor durch Metamodelle spezifizierten Ergebnis-

dokumenten hinterlegt. Die Aktivitäten werden bestimmten Rollen (z.B. Personen, Stellen



59 Vgl. Brenner (1995), S. 11.

60 Vgl. Gutzwiller (1994) und Heym (1993).

61 Vgl. Gutzwiller (1994), S. 13.


oder Organisationseinheiten) zugeordnet. Die jeweilige Vorschrift zur Erstellung (und damit

zur Dokumentation) der Ergebnisse wird als (Modellierungs-)Technik bezeichnet. Im Gegen-

satz zum Vorgehensmodell, das das Vorgehen im Grossen definiert, beschreiben Techniken

das Vorgehen im Kleinen.62 Aktivitäten spezifizieren, wann welche Ergebnisse produziert

werden.63 Techniken liefern dagegen die detaillierten Handlungsanweisungen zur Erstellung

der Ergebnisse.64 Software-Werkzeuge können verwendet werden, um die Anwendung einer

Technik zu unterstützen. Die in den verschiedenen Ergebnisdokumenten repräsentierten Er-

gebnisse und deren Zusammenhänge können im Metamodell der Methode abgebildet werden.

Eine Methode lässt sich somit durch ihr Vorgehensmodell, das Metamodell (d.h. die Menge

aller Ergebnisspezifikationen), das Rollenmodell sowie die verwendeten Techniken beschrei-

ben.

2.2 Modelle

Die Abbildung natürlicher oder künstlicher Originale in Form von Modellen ist sowohl in der

Wissenschaft als auch in der Praxis weit verbreitet. Auch bei der Gestaltung bzw. Modellie-

rung von Informationssystemen und Unternehmensstrukturen werden die Ergebnisse in Form

von Modellen repräsentiert. Sie sind somit für das Dissertationsvorhaben von Interesse und

werden daher in den folgenden Abschnitten näher erläutert. Dabei wird insbesondere auf Be-

griffe aus den Bereichen der Modellierung, Metamodellierung und Referenzmodellierung

eingegangen.

2.2.1 Modell und Modellierung

In der Literatur finden sich zahlreiche Definitionen zum Modellbegriff.65 Ein domänenüber-

greifender und von breiten Kreisen der Forschung66 akzeptierter Modellbegriff wird von

STACHOWIAK vorgeschlagen. Nach STACHOWIAK besitzt ein Modell drei wesentliche Merk-

male:67

• Abbildung: Ein Modell ist ein Abbild oder eine Repräsentation eines realen oder gedach-

ten Sachverhaltes.

• Verkürzung: Ein Modell erfasst nicht alle Attribute des entsprechenden Originals.



64 Vgl. Gutzwiller (1994), S. 14 und Winter (2003d), S. 88.

65 Vgl. z.B. Alpar et al. (2005), S. 20, Ferstl/Sinz (1998), S. 18, Schütte (1998), S. 45, Teubner (1999), S. 14,

Winter (2003d), S.89. 66

Vgl. z.B. Lehner (1995), S. 27, Schelp (2000), S. 15-17, Schütte (1998), S. 41-45 und Teubner (1999), S. 14.

67 Vgl. Stachowiak (1973), S. 131f.


• Pragmatismus: Ein Modell sollte sich am Nützlichen orientieren. Es wird innerhalb einer

bestimmten Zeitspanne und zu einem bestimmten Zweck für ein Original eingesetzt.

Die Modellierungstechnik schreibt vor, wie ein Modell zu konstruieren ist. Sie besteht aus

einer Modellierungssprache und einer Vorgehensweise (vgl. Abbildung 4). Von der Vorge-

hensweise (Vorgehen im Kleinen68) als Vorschrift zur Erstellung eines Modells ist die Spra-

che zu unterscheiden, mit der das Modell beschrieben wird.69 Die Sprache legt die Elemente

fest, die bei der Erstellung eines Modells verwendet werden können. Sie wird durch ihre Syn-

tax, Semantik und Notation beschrieben. Die Notation definiert die Darstellung der Elemente

der Modellierungssprache (Symbole) und visualisiert somit ihre Syntax. Die Syntax definiert

die Grammatik der Elemente und die Semantik deren Bedeutung. Die Darstellung der Ele-

mente bzw. Symbole sollte so gewählt sein, dass sie die Bedeutung des Elements (Semantik)

der Sprache möglichst intuitiv wiedergeben. Bestimmte Sprachen oder Notationen sind in der

Regel an bestimmte Vorgehensweisen gebunden und umgekehrt. Die Vorgehensweise defi-

niert die Schritte, die durchgeführt werden müssen, um mit der Sprache bestimmte Modelle zu

erstellen.

Abbildung 4: Bestandteile einer Modellierungstechnik70

Modelle entstehen als Ergebnisse der Modellierung mit einer bestimmten Technik.71 Für das

Dissertationsvorhaben wird die folgende Begriffsdefinition verwendet: „Als Modellierung

wird der Vorgang der Konstruktion eines Abbilds realer oder gedachter Sachverhalte verstan-

den, welcher auf der Grundlage der Wahrnehmung dieser Sachverhalte durch den/die Model-

lierer/in erfolgt und durch den jeweiligen Modellierungszweck beeinflusst wird“72. Nach

68 Im Unterschied zur Vorgehensweise der Methode (vgl. Abschnitt 2.1.2).

69 Vgl. Winter (2003d), S. 89.

70 Vgl. Karagiannis/Kühn (2002), S. 184.

71 Vgl. Schütte (1998), S. 40.

72 Vgl. Winter (2003d), S. 89.


LEIST lassen sich beispielsweise die unterschiedlichen in der Literatur genannten Zwecke der

Modellierung zu folgenden Gruppen zusammenfassen:73

• Schulungszweck: Der Schulungszweck beinhaltet sowohl das Erlernen der Modellierungs-

technik als auch das einfache Vermitteln organisatorischer Abläufe oder Funktionen eines

Informationssystems an dessen Nutzer.

• Kommunikationsbasis: Ergebnisdokumente einer Modellierungstechnik können inner-

halb/ausserhalb eines Unternehmens zur Kommunikation unterschiedlichster Sachverhalte

dienen. Zudem dienen sie der Kommunikation zwischen verschiedenen an einem Projekt

beteiligten Rollen, indem relevante Objekte, ihre Beziehungen sowie ihre Attribute festge-

legt werden.

• Analysezweck: Ergebnisse der Modellierung können zum Analysieren von Sachverhalten

herangezogen werden.

• Gestaltungs- und Entwicklungszweck: Ergebnisse der Modellierung können als Grundlage

für die Entwicklung und Gestaltung beispielsweise von Informationssystemen oder Orga-

nisationsstrukturen dienen.

Trotz unterschiedlicher Wahrnehmungen und Modellierungszwecke können Modelle anhand

von zwei wesentlichen Dimensionen strukturiert werden:74

• Generalisierung vs. Spezialisierung: Spezielle Modelle bilden Sachverhalte in einem be-

stimmten Anwendungskontext ab, beispielsweise in einer bestimmten Branche oder in ei-

nem bestimmten Unternehmen. Generalisierte Modelle abstrahieren dagegen von einem

bestimmten Anwendungskontext (Generalisierungsgrad).

• Aggregation vs. Dekomposition: Architekturmodelle, wie beispielsweise Prozessarchitek-

turmodelle (Prozesslandkarten), bilden Zusammenhänge zwischen Komponenten im Gro-

ben ab. Ein Detailmodell (z.B. Ablaufplanungsmodell eines bestimmten Prozesses) bildet

dagegen eine ganz bestimmte Komponente eines Architekturmodells ab (Aggregati-

onsgrad).

In der Realität existieren eine Vielzahl unterschiedlicher Originale bzw. Sachverhalte, die in

Modellen abgebildet werden können. Für das Dissertationsvorhaben sind insbesondere Mo-

delle von Unternehmen von Interesse. Grundlage der Modellierung ist somit die betriebliche

Diskurswelt.

Innerhalb der betrieblichen Diskurswelt stellt der Grad der Abstraktion eine weitere Dimensi-

on zur Strukturierung der unterschiedlichen Modelle dar.75 Eine Organisation bzw. ein Unter-

73 Vgl. Leist (2002), S. 8-9.

74 Vgl. Winter (2003d), S. 90.

75 Vgl. z.B. Anaya/Ortiz (2005), S. 26.


nehmen kann mit unterschiedlichen Abstraktionsgraden betrachtet bzw. in unterschiedliche

Abstraktionsebenen76 eingeteilt werden. Häufig wird davon ausgegangen, dass Mitarbeiter aus

den Fachabteilungen einen abstrakteren, gesamthafteren Blick auf das Unternehmen sowie

dessen Strukturen und deren Strategie haben als Mitarbeiter aus dem IT-Bereich aufgrund der

Informationen, die ihnen zur Verfügung stehen und mit denen sie arbeiten. Ein Geschäftspro-

zessverantwortlicher betrachtet das Unternehmen beispielsweise als eine Menge von Prozes-

sen, die bestimmte Leistungen erzeugen und verwenden. Ein IT-Verantwortlicher betrachtet

dagegen das Unternehmen als eine Menge von Informationssystemen, die bestimmte Funkti-

onalitäten zur Verfügung stellen. Innerhalb jeder dieser Abstraktionsebenen gibt es Modelle

mit unterschiedlichen Generalisierungs- und Aggregationsgraden (vgl. Abbildung 5).

Gra

d d

er

Ab

str

aktio

n

Abbildung 5: Strukturierung von Modellen

2.2.2 Referenzmodell und Referenzmodellierung

Die Modellierung kann durch Referenzmodelle unterstützt werden. Der Begriff Referenz

kennzeichnet üblicherweise einen Verweis oder einen Bezug, dem eine Empfehlung zuge-

sprochen wird, so dass die Referenz den Best Practice oder Common Practice markiert.77 Re-

ferenzmodelle entstehen als Ergebnisse der Referenzmodellierung, welche häufig auch als

Referenzmodellkonstruktion bezeichnet wird.78 Referenzmodellierung kann beschrieben wer-

den als die Menge aller Handlungen, welche die Konstruktion und Anwendung wieder ver-

76 Die Begriffe Abstraktions-, Betrachtungs-, Modellierungs-, Architektur- und Gestaltungsebene werden in

dieser Arbeit synonym verwendet. Oftmals wird auch aus Gründen der Einfachheit lediglich von einer „Ebene“ gesprochen.

77 Vgl. vom Brocke (2003a), S. 31.

78 Vgl. z.B. Becker/Delfmann (2004), S. 1.


wendbarer Modelle (Referenzmodelle) beabsichtigen.79 Analog zur Definition eines Modells

wird ein Referenzmodell als Ergebnis einer Konstruktion beschrieben, das die Repräsentation

eines Originals als Empfehlung deklariert.80 Ein Referenzmodell gilt somit als Empfehlung

für einen bestimmten Anwendungskontext. Referenzmodelle repräsentieren Abbildungen von

allgemein gültigen Strukturen (z.B. Prozessen und Daten), die für eine Gruppe von Unter-

nehmen (innerhalb eines Sektors oder einer Branche) oder für eine betriebswirtschaftliche

Funktion Gültigkeit haben sollen.81 Durch die Verwendung von Referenzmodellen bei der

Konstruktion von unternehmensspezifischen Modellen können Kosteneinsparungen erzielt

werden, da das in den Referenzmodellen enthaltene Know-how wieder verwendet werden

kann.82 Sie beinhalten ausserdem in vielen Fällen den aktuellen Best Practice bzw. Common

Practice für einen bestimmten betriebswirtschaftlichen Anwendungskontext, so dass der An-

wender zwar nicht von der besten, aber zumindest von einer guten Lösung ausgehen kann.83

Der Grundgedanke der Referenzmodellierung ist demnach – analog zur Konstruktion von

Methoden bzw. zum Methoden-Engineering (vgl. Abschnitt 2.1.1) – die Konstruktion unter-

nehmensspezifischer Modelle auf Basis vorgefertigter Modelle bzw. Modellbausteine. Das

Referenzmodell stellt dabei ein Modell für einen bestimmten Typ von Unternehmen dar (z.B.

Unternehmen der Versicherungsbranche), das für den Einsatz in einem bestimmten unterneh-

mensindividuellen Umfeld (Versicherung XY), in einem bestimmten Anwendungsbereich

(z.B. Schadenbearbeitung), angepasst und wieder verwendet werden kann (vgl. Abbildung 6).

Dadurch soll eine Steigerung der Effektivität und Effizienz von Modellierungsprozessen er-

reicht werden.

Abbildung 6: Referenzmodellanwendung

79 Vgl. Fettke/Loos (2004b), S. 331.

80 Vgl. Schütte (1998), S. 69.

81 Vgl. Becker (2004a), S. 325.

82 Vgl. Becker (2004b), S. 325.

83 Im Bereich der Referenzmodellierung kann zwischen Common-Practice- und Best-Practice-

Referenzmodellen unterschieden werden. Vgl. hierzu Becker et al. (2002a).


Sowohl die Referenzmodellierung als auch die in Abschnitt 2.1 beschriebene

Methodenentwicklung können in die zwei Vorgänge Konstruktion und Anwendung zerlegt

werden.84 Das Ziel der Konstruktion ist die Entwicklung eines Referenzmodells bzw. einer

Methode, das/die für eine Klasse von Unternehmen (z.B. Unternehmen einer bestimmten

Branche) Gültigkeit hat und das/die in unterschiedlichen Situationen eingesetzt werden kann.

Die Anwendung des konstruierten Referenzmodells bzw. der konstruierten Methode erfolgt

im Anschluss an den Konstruktionsprozess. Dazu wird das Referenzmodell bzw. die Methode

für den Einsatz im jeweiligen unternehmensspezifischen Umfeld durch den Anwender

manuell modifiziert.

2.2.3 Metamodell und Metamodellierung

Bei der Modellbildung wird aus einem Problembereich, dem Original, durch Abbildung und

Verkürzung mit einer gegebenen Pragmatik ein Modell für einen bestimmten Zweck gebildet.

Wenn Modelle und Modellbildung selbst zum Gegenstand der Modellierung werden, spricht

man von Metamodellierung.85 Metamodelle definieren Konstruktionsregeln für die Erstellung

von Modellsystemen, indem sie die verfügbaren Arten von Bausteinen (Metaobjekte, Objekt-

typen, Klassen, Metaentitätstypen), die Beziehungen zwischen den Bausteinen (Meta-

Beziehungen, Beziehungstypen) sowie Konsistenzbedingungen für die Verwendung von Bau-

steinen und Beziehungen spezifizieren.86

Metamodelle sind ein wesentlicher Bestandteil einer Methode (vgl. Abbildung 3). Sie definie-

ren die Ergebnisse (Instanzen bzw. Objekte und Beziehungen), welche bei der Anwendung

einer bestimmten Technik erzeugt werden. Die erzeugten Ergebnisse werden meist in Form

von Modellen dargestellt. Ein Metamodell bezeichnet somit ein Modell, welches eine Menge

gleichartiger, mit derselben Technik erstellter Modelle repräsentiert (Typ). Da in den ver-

schiedenen Ergebnissen bzw. Modellen Informationen dokumentiert werden, wird häufig

auch von einem Informationsmodell einer Methode anstelle von einem Metamodell gespro-

chen.

Das in Abbildung 3 dargestellte Modell ist ebenfalls ein Metamodell. Es handelt sich dabei

um das Metamodell des Methoden-Engineering87, da es die wesentlichen konstituierenden

Elemente einer Methode definiert. Es stellt somit den „Bauplan“ für Methoden bereit. Ausge-

hend von der Aktivität wird die Methode mit ihren Elementen „Rolle“, „Ergebnis“, „Tech-

nik“, „Werkzeug“ und „Metamodell“ aufgebaut.88 Durch das Metamodell wird sichergestellt,

dass Methoden mit den gleichen Komponenten, wenn auch unterschiedlicher Ausprägung,

84 Vgl. im Folgenden Fettke/Loos (2002), S. 10 und Wortmann (2005), S. 100.

85 Vgl. Strahringer (1998), S. 1.

86 Vgl. Sinz (1999b). S. 1035.

87 Vgl. Heym (1993).

88 Vgl. Gutzwiller (1994), S.11-17, Winter (2003d), S. 88.


entwickelt und so einerseits vergleichbar und andererseits nachvollziehbar werden. Darüber

hinaus wird sichergestellt, dass keine Komponente, wie z.B. das Ergebnis bzw. das Ergebnis-

dokument, unberücksichtigt bleibt.89

Modelle werden mit Hilfe von Modellierungstechniken erstellt. Aus Sicht der Metamodellie-

rung beinhalten Modellierungstechniken eine Modellierungssprache sowie eine Vorgehens-

weise (vgl. Abschnitt 2.2.1 und die dortige Abbildung 4). Modellierungssprachen werden

durch Metamodelle definiert. Die Metamodelle werden ebenfalls mit Hilfe einer Modellie-

rungssprache erstellt. Diese wird als Metamodellierungssprache bezeichnet. Das Meta-

Metamodell definiert wiederum die Metamodellierungssprache. Dadurch entsteht eine Hierar-

chie von Modellen, Metamodellen etc. (vgl. Abbildung 7).

Instanziierung

Klassifikation

Abbildung 7: Modellierungshierarchie90

2.2.4 Verwendete Meta-Modellierungssprachen

Für die Darstellung der Metamodelle und der Vorgehensmodelle der in Kapitel 3 und 4 be-

schriebenen Ansätze wird die Unified Modeling Language (UML) verwendet, da diese sich

als führender Notationsstandard in Praxis und Wissenschaft etabliert hat.91

Die UML ist eine durch die Object Management Group (OMG) standardisierte graphische

Sprache zur Beschreibung objektorientierter Modelle.92 Die UML ermöglicht die Modellie-

rung verschiedenartiger Systeme, wie beispielsweise Software-Systeme oder Geschäftssyste-

me. Sie wurde durch Vertreter verschiedener Firmen entwickelt und standardisiert.

UML-Aktivitätsdiagramme dienen der Darstellung des Kontroll- und Informationsflusses bei

Software-Systemen und können beispielsweise auch für die Modellierung von Geschäftspro-

89 Vgl. Baumöl et al. (2005), S. 4.

90 In Anlehnung an Karagiannis/Kühn (2002), S. 184.

91 Vgl. z.B. Balzert (2000), S. V.

92 Vgl. OMG (2003b) und Jeckle et al. (2004a).


zessen oder Workflows eines Unternehmens verwendet werden.93 Mit Hilfe von UML-

Klassendiagrammen kann die Struktur eines Systems dargestellt werden. Sie eignen sich bei-

spielsweise für die Abbildung der Beziehungen zwischen einzelnen Mitarbeitern, Organisati-

onseinheiten, Geschäftsobjekten und aussenstehenden Parteien eines Unternehmens.

2.2.4.1 Notation für Metamodelle

Wie bereits in Abschnitt 2.1 und 2.2.3 beschrieben, sind Metamodelle ein wesentlicher Be-

standteil einer Methode. Sie definieren die Ergebnisse (Modelle bestehend aus Objekten und

Beziehungen), welche bei der Anwendung einer bestimmten Technik erzeugt werden. Für die

Darstellung aller Metamodelle der im Folgenden beschriebenen Methoden sowie des entwi-

ckelten Ansatzes werden UML-Klassendiagramme verwendet. Ein Klassendiagramm bietet

die Möglichkeit, die Struktur eines Systems darzustellen. Es zeigt dessen wesentliche stati-

sche Eigenschaften sowie ihre Beziehungen zueinander. Das zentrale Konzept sind Klassen.

Eine Klasse wird in der UML 2 als eine Sammlung von Exemplaren definiert, die über ge-

meinsame Eigenschaften, Einschränkungen und Semantik verfügen. Jede Klasse stellt dem-

nach einen abstrahierten Sammelbegriff für eine Menge gleichartiger Dinge dar.94 Für die

Darstellung der Metamodelle werden Modellierungskonstrukte verwendet, die mit der in

Tabelle 2 beschriebenen Bedeutung und der in UML verwendeten Notation belegt sind.

Metamodell UML-Klassendiagramm

Modellierungs-

konstrukt Beschreibung UML-Konstrukt Notation (Symbol)

Metaentitätstyp

Ein Metaentitätstyp beschreibt eine Sammlung von Objekten, die über gemeinsame Eigenschaften und eine gemeinsame Semantik verfügen.

Klasse

Assoziation

Generalisierung Beziehungstyp

Ein Beziehungstyp beschreibt eine Menge semantisch gleichartiger Bezie-hungen zwischen zwei Metaentitätsty-pen. Komposition

Eigenschaft Eigenschaften beschreiben bestimmte Charakteristika eines Metaentitätstyps.

Klassenattribut

Kardinalität Jeder Beziehungstyp wird durch die Angabe von Kardinalitäten spezifiziert.

Multiplizität

Tabelle 2: Modellierungskonstrukte für das Metamodell

93 Vgl. hierzu z.B. Oestereich et al. (2004).

94 Vgl. Jeckle et al. (2004b), S. 32.


2.2.4.2 Notation für Vorgehensmodelle

Die Vorgehensmodelle beschreiben Aktivitäten und deren Reihenfolge. Aktivitäten erzeugen

bzw. verwenden Ergebnisse in Form von Ergebnisdokumenten. Dieser Zusammenhang wird

durch ein- und ausgehende Ergebnisdokumente in den Vorgehensmodellen kenntlich ge-

macht. Die Ergebnisdokumente stellen eine Verbindung zu den Metamodellen her, da sie von

diesen spezifiziert werden.

Für die Darstellung der Vorgehensmodelle gibt es eine Vielzahl möglicher Modellierungs-

sprachen. Vor allem wegen ihrer weiten Verbreitung und ihrer Ausdrucksmächtigkeit werden

sehr häufig die ereignisgesteuerten Prozessketten (EPK)95 oder UML-Aktivitätsdiagramme96

eingesetzt. Mit der Anwendung der EPK würde eine Modellierungssprache gewählt, die for-

mal spezifiziert ist97 und die über eine ausreichende semantische Ausdrucksmächtigkeit ver-

fügt. Jedoch zwingt das Metamodell der EPK zu einer abwechselnden Folge von Aktivitäten

und Ereignissen, die den Ablauf unnötig verlängert und damit zu einem unter Umständen un-

verständlicheren und unübersichtlicheren Diagramm führt.98 Da auf den Zwang der Abbil-

dung solcher Ereignisse zugunsten einer übersichtlicheren Darstellung verzichtet wird, wer-

den im Folgenden UML-Aktivitätsdiagramme zur Modellierung der Aktivitäten der Vorge-

hensmodelle verwendet. UML-Aktivitätsdiagramme sind ebenfalls im Gesamtkontext der

UML formal spezifiziert.99 Da die Übertragung des Gesamtkontextes zu aufwendig erscheint,

wird im Folgenden lediglich der relevante Ausschnitt betrachtet. Hierzu werden in Tabelle 3

die in Vorgehensmodellen enthaltenen Modellierungskonstrukte und deren Beziehungen so-

wie deren Repräsentation innerhalb der UML beschrieben.

Vorgehensmodell UML-Aktivitätsdiagramm

Modellierungs-

konstrukt Beschreibung

UML-

Konstrukt Notation (Symbol)

Aktivität Durchführung einer atomaren Aktivität innerhalb des Vorgehensmodells

Aktionszustand Aktivität

Aktivitätshierarchie Durchführung einer Aktivität, die aus Sub-Aktivitäten bzw. einem weiteren Vorgehensmodell besteht

Unteraktions- zustand

Kontrollfluss Übergang zwischen einer Aktivität und einer nachfolgenden Aktivität

Transition

Objektfluss Erzeugung oder Verwendung eines Ergebnisdokuments

Objektfluss

95 Vgl. z.B. Becker et al. (2002b).

96 Vgl. z.B. Jeckle et al. (2004b), S. 199-266.

97 Vgl. Scheer (2001), S. 170-171.

98 Vgl. Leist (2004), S. 142.

99 Vgl. OMG (2003b) und Jeckle et al. (2004b), S. 199-266.


Input/Output Ergebnisdokumenttyp, der von einer Aktivität verwendet bzw. erzeugt wird

Objektzustand

Start Beginn des Vorgehensmodells Anfangszustand

Ende Abschluss des Vorgehensmodells Endzustand

Tabelle 3: Modellierungskonstrukte für das Vorgehensmodell

2.3 Modellierung der Unternehmensarchitektur

Der Begriff Architektur wird in der Literatur sehr unterschiedlich verwendet.100 Allen Defini-

tionen liegt aber zugrunde, dass die Architektur mit einer Struktur in Verbindung gebracht

wird, deren Komponenten und Beziehungen im Vordergrund stehen. Der IEEE-Standard-

1471 definiert den Begriff Architektur beispielsweise wie folgt: „Architecture is the funda-

mental organization of a system embodied in its components, their relationships to each other,

and to the environment, and the principle guiding its design and evolution".101

In der vorliegenden Arbeit wird der Begriff Architektur als Konzept verstanden, welches nicht

nur einzelne Komponenten und Beziehungen strukturiert abbildet, sondern auch deren Kon-

struktionsregeln festlegt.102

Um die Struktur von Informationssystemen sowohl aus technischer als auch aus fachlicher

Sicht beschreiben zu können, wird die Gestaltung der Informationssystemarchitektur zuneh-

mend mit entsprechenden Methoden und Modellen auf anderen Betrachtungs- bzw. Abstrak-

tionsebenen integriert und als umfassendes Gestaltungskonzept „Unternehmensarchitektur“

(„Enterprise Architecture”) diskutiert.103 Das Ziel einer Unternehmensarchitektur ist es, die

Strukturen des Unternehmens und dessen Informationssysteme ganzheitlich abzubilden und

damit die zukünftige Entwicklung und Gestaltung des Unternehmens zu unterstützen.104 Die

Architektur eines Unternehmens besteht aus verschiedenen Sichten auf dieses Unternehmen,

wobei jede Sicht wiederum verschiedene Modelle enthält, die Ausschnitte des Unternehmens

für einen bestimmten Zweck repräsentieren.105 Dabei stehen vor allem die Identifikation der

Gesamtzusammenhänge zwischen unterschiedlichen Bereichen innerhalb des Unternehmens

sowie deren komplexitätsreduzierende Darstellung im Vordergrund. Im folgenden Abschnitt

wird auf diese Gesamtzusammenhänge genauer eingegangen.

100 Vgl. z.B. IEEE (2000), Heinrich (1993), S. 327, Krcmar (1990), S. 396, Scheer (1998), S.1 und Zachman

(1987), S. 277. 101

IEEE (2000). 102

Vgl. Sinz (1999b), S. 1035 und IEEE (2000). 103

Vgl. Schwinn/Winter (2005), S. 587. 104

Vgl. Krcmar (2003), S. 39f. und Opengroup (2002). 105

Vgl. Leist (2002), S. 7.


2.3.1 Darstellung von Gesamtzusammenhängen in Unternehmungen

Unternehmen können als offene Systeme hoher Komplexität in einer ebenfalls komplexen

Umwelt definiert werden, deren Gestaltung und Lenkung ein umfassendes, integrierendes

Denken erfordert.106 Die komplexen Strukturen eines Unternehmens lassen sich aus den un-

terschiedlichsten Perspektiven und für die unterschiedlichsten Zwecke modellieren.107 Um die

Komplexität der Strukturen zu reduzieren, wird bei den meisten bereits existierenden Ansät-

zen108 eine Hierarchie von Modellierungsebenen109 gebildet. Die Modelle der verschiedenen

Ebenen unterscheiden sich üblicherweise hinsichtlich des Aggregationsgrades, des Generali-

sierungsgrades, des Abstraktionsgrades sowie der jeweiligen Ziele der Modellbildung (vgl.

hierzu Abschnitt 2.2.1). Viele Ansätze folgen dem hierarchischen Systemansatz nach

MESAROVIC, demzufolge die Informationssysteme entsprechend den fachlichen Anforderun-

gen gestaltet werden und damit die Ergebnisse der Modellierung einer Gestaltungsebene die

Freiheitsgrade bei der Modellierung der nachfolgenden Ebenen einschränken.110

Architekturmodelle unterstützen Gestaltungs- und Entwicklungsprozesse. Die Unternehmens-

architektur sollte daher alle relevanten Elemente eines Unternehmens in aggregierter Form

abbilden. Eine Einteilung in Architekturebenen und Sichten ist dabei sehr hilfreich, um unter-

schiedliche Aspekte in unterschiedlichen Modellen darzustellen, solange die Konsistenz durch

die Definition eines ebenen- und sichtenübergreifenden Metamodells gewährleistet ist.

Eine Analyse der Literatur zum Thema Unternehmensarchitektur hat gezeigt, dass folgende

Architekturebenen differenziert werden können:111

• Geschäftsarchitektur als Gesamtzusammenhang der Leistungsverflechtung zwischen Or-

ganisationen in einem Wertschöpfungsnetzwerk

• Prozessarchitektur als Gesamtzusammenhang der Leistungsentwicklung, Leistungserstel-

lung und des Leistungsvertriebs innerhalb einer Organisation

• Applikations- bzw. Integrationsarchitektur als Gesamtzusammenhang der informatori-

schen Verflechtung von Applikationen innerhalb einer Organisation

• Softwarearchitektur als Gesamtzusammenhang der funktionalen Verflechtung zwischen

Softwareartefakten einschliesslich Datenstrukturen innerhalb des Informationssystems

106 Vgl. Ulrich (2001), S. 118.

107 Vgl. Winter (2003d), S. 81.

108 Vgl. z.B. Ferstl/Sinz (1995), Frank (2002), Krcmar (1990) und Scheer (1998).

109 Die Begriffe Gestaltungs-, Modellierungs-, Abstraktions- und Architekturebene werden in dieser Arbeit

synonym verwendet. 110

Vgl. Mesarovic et al. (1970). 111

Die Ergebnisse der Analyse finden sich in Winter (2003d), S. 92-93, Winter/Fischer (2006), S. 6-7 und Hafner (2005), S. 32-34.


• Technologie- bzw. Infrastrukturarchitektur als Gesamtzusammenhang der eingesetzten IT-

Komponenten, wie beispielsweise Server, Workstations, Netzwerkkomponenten etc.

Die zuvor genannten Ebenen finden sich nicht in allen Ansätzen. So definiert die Architektur

integrierter Informationssysteme (ARIS)112 beispielsweise nicht explizit eine Strategieebene.

Das Zachman-Framework113 enthält zwar ein so genanntes Geschäftsmodell (Business Mo-

del). Dieses beschreibt allerdings die geschäftsorientierten Artefakte wie Wertschöpfungsket-

ten, Ziele, Organisationseinheiten und Geschäftsprozesse nicht mit einem ausreichenden De-

taillierungsgrad.

Zur weiteren Strukturierung und Komplexitätsreduktion werden in der Regel innerhalb jeder

Architekturebene verschiedene Sichten gebildet.114 Diese reflektieren oftmals die verschiede-

nen Anspruchsgruppen in einem Unternehmen. Für jede Anspruchsgruppe ist in der Regel

nicht die gesamte Unternehmensarchitektur, sondern lediglich ein bestimmter Ausschnitt da-

von relevant.115 Typische Sichten innerhalb der Ebenen der Prozess- und Applikationsarchi-

tektur sind beispielsweise die Organisations- und Prozesssicht, die Funktions- und Kommuni-

kationssicht sowie die Informations- bzw. Datensicht.116 Neben diesen primär ebeneninternen

Sichten werden aber auch häufig für bestimmte Fragestellungen ebenenübergreifende Sichten

definiert. So unterteilen ZACHMAN/SOWA beispielsweise in ihrem Architektur-Framework alle

Ebenen nach den Sichten Data, Function, Network, People, Time und Motivation, die der

Beantwortung verschiedener Fragestellungen dienen sollen (Was? Wie? Wo? Wer? Wann?

Warum?).117

Innerhalb der betrieblichen Diskurswelt lassen sich die verschiedenen Modelle, wie bereits in

2.2.1 dargestellt, nach unterschiedlichen Abstraktionsebenen, Aggregations- und Generalisie-

rungsgraden sowie ebenenübergreifenden Sichten strukturieren. Die Unternehmensarchitektur

umfasst im Verständnis der vorliegenden Arbeit lediglich diejenigen Modelle, die alle aggre-

gierten Artefakte und deren Beziehungen auf allen Abstraktionsebenen eines Unternehmens

bzw. einer Organisation abbilden (vgl. Abbildung 8).118 Die detaillierte Zerlegung dieser Ar-

tefakte erfolgt dementsprechend in spezifischen Architekturen, wie beispielsweise Prozessar-

chitekturen, Datenarchitekturen oder Software- und Technologiearchitekturen. Für diese lie-

gen oftmals bereits entsprechende Modellierungskonzepte vor. Allerdings existieren bisher

keine Konzepte, die die Zusammenhänge zwischen diesen Architekturebenen definieren.119

Die Definition dieser Zusammenhänge ermöglicht die Gewährleistung der Konsistenz zwi-

112 Vgl. Scheer (1998).

113 Vgl. Zachman/Sowa (1992).

114 Vgl. Sinz (1999a), S. 1036.

115 Vgl. Lankhorst (2005), S. 55.

116 Vgl. hierzu auch Hafner (2005), S. 36.

117 Vgl. Zachman/Sowa (1992), S. 600f.

118 Vgl. hierzu Winter/Fischer (2006), S. 4.



schen Modellen auf unterschiedlichen Architekturebenen und bildet somit beispielsweise auch

eine wichtige Grundlage für die systematische, modellbasierte Lösung von Problemstellungen

des IT-Business-Alignment120, Service Management121 oder Compliance Management122. G

rad

de

r A

bstr

aktio

n

Aggregation

Aggregation

Aggregation

Aggregation

Aggregation

Abbildung 8: Unternehmensarchitektur123

2.3.2 Business Engineering

Für die Entwicklung einer Unternehmensarchitektur ist, analog zur Konstruktion von

Methoden und Referenzmodellen, ein systematischer, umfassender Ansatz erforderlich, um

die Konsistenz der erzeugten Ergebnisse gewährleisten zu können. Der Begriff „Business

Engineering“ (BE)124 bezeichnet einen Ansatz zur ingenieurmässigen, methoden- und mo-

dellbasierten Konstruktion von Unternehmensmodellen. Das Business Engineering bildet

daher den Forschungsrahmen des Dissertationsvorhabens. Im Folgenden werden die

120 Zum Thema IT-Business-Alignment vgl. z.B. Henderson/Venkatraman (1993).

121 Zum Thema IT-Service-Management vgl. z.B. Hochstein/Hunziker (2003).

122 Für eine Erläuterung zum Thema Compliance Management vgl. z.B. Geissler (2004).

123 Vgl. Winter/Fischer (2006), S. 4.

124 Vgl. Österle/Winter (2003).


grundlegende Ausrichtung, die Gestaltungsebenen und Inhalte sowie das vereinfachte

Metamodell des Business Engineering vorgestellt.

Der BE-Ansatz verfolgt das Ziel, Unternehmen bei der Transformation in das Informations-

zeitalter zu unterstützen. Transformation bedeutet dabei, vorhandene Unternehmen zu restruk-

turieren oder neue Unternehmen zu schaffen. Die Transformation wird meist durch IT-

Innovationen ausgelöst.125 Um diese systematisch umzusetzen, sind entsprechende Vorge-

hensweisen, Methoden und Werkzeuge notwendig. Das in Abschnitt 2.1 beschriebene Metho-

den-Engineering stellt deshalb ein wichtiges Element des Business Engineering dar, da es das

ingenieurmässige Vorgehen bei der Transformation eines Unternehmens sichert.

Der BE-Ansatz ist ein interdisziplinärer Ansatz, der die vielfältigen Aspekte der Transforma-

tion nach unterschiedlichen Ebenen gliedert (vgl. Abbildung 9). Die wesentlichen Dimensio-

nen des Ansatzes sind die fachliche Dimension, bestehend aus einer Strategie-, Organisations-

und Informationssystemebene, sowie die politisch-kulturelle Dimension, die Themengebiete

wie Motivation und Führung, Verhalten, Kommunikation und Machtverhältnisse abdeckt.

Nach ÖSTERLE ET AL. sind verteilte Strukturen nicht nur ein Phänomen von Informationssys-

temen und Softwarekomponenten.126 Auch Geschäftsprozesse erstrecken sich zunehmend

über die Grenzen einzelner Geschäftseinheiten oder sogar Unternehmen hinweg. Zudem ba-

sieren neue Geschäftsmodelle immer häufiger auf Kooperationen oder Kooptionen. Nach

WINTER verfolgt der Business Engineering-Ansatz deshalb das Ziel, die konsistente Spezifi-

kation von vernetzten Strukturen auf allen Architekturebenen eines Unternehmens zu unter-

stützen.127

Auf Strategieebene werden die Rolle des Unternehmens im Wertschöpfungsnetzwerk, die

relevanten Kundenprozesse und -segmente sowie die wesentlichen Leistungen des Unterneh-

mens festgelegt. Des Weiteren wird das Zielsystem des Unternehmens in Form von kritischen

Erfolgsfaktoren und Kennzahlen beschrieben. Modellierungstechniken für die Gestaltung von

Geschäftsnetzwerken und -strategien sowie entsprechende Notationen finden sich beispiels-

weise in Arbeiten von WINTER und HEINRICH.128

Auf Organisationsebene werden die zur Umsetzung der Strategien notwendigen Geschäfts-

prozesse und ihr Zusammenwirken beschrieben. Die Geschäftsprozesse erstrecken sich in der

Regel über die Grenzen eines einzelnen Unternehmens bzw. einer einzelnen Geschäftseinheit

hinweg. Für jeden Geschäftsprozess werden zudem die zu erbringenden Prozessleistungen

spezifiziert, die zu deren Erbringung notwendigen Aktivitäten einschliesslich deren Abfolgen

festgelegt und Performance-Indikatoren für die Führung der Prozesse sowie Verantwortlich-

125 Vgl. Österle/Winter (2003), S. 4.

126 Vgl. Österle et al. (2001).

127 Vgl. Winter (2003d).

128 Vgl. z.B. Winter (2003b), Heinrich/Winter (2004) und Heinrich (2002b).


keiten bzw. Organisationsstrukturen definiert. Ausserdem werden auf dieser Ebene Informati-

onsobjekte und -flüsse in Form abstrakter Informationsmodelle abgebildet. Techniken für die

Modellierung von Geschäftsprozessen und Organisationsstrukturen finden sich beispielsweise

in Arbeiten von ÖSTERLE, BRECHT und IMG.129

Abbildung 9: Business-Engineering-Landkarte130

Die Informationssystemebene wird weiter unterteilt in die Ebenen Applikationen sowie Soft-

warekomponenten und Datenstrukturen. Das Gestaltungsziel auf der Applikationsebene be-

steht darin, Komponenten der Informationssysteme mit den Geschäftsanforderungen zu ver-

binden, indem entsprechende Applikationsstrukturen und Integrationssysteme (z.B. Data-

Warehouse-Systeme, Operational-Data-Store-Systeme oder Enterprise-Application-

Integration-Systeme) entworfen werden. Applikationen repräsentieren konzeptionelle Kon-

strukte, die zur Strukturierung der Informationsflüsse, Geschäftsprozessunterstützung und

Verantwortlichkeiten auf Unternehmens- bzw. Geschäftseinheitsebene verwendet werden.131

Ihre Strukturen werden aus der Analyse von Aktivitäten, Informationsbedürfnissen und Ver-

antwortlichkeiten abgeleitet. Ausserdem werden Informations- und Kontrollflüsse zwischen

Applikationen spezifiziert, die auf unterschiedlichen Plattformen laufen oder in unterschiedli-

chen Unternehmen bzw. Geschäftseinheiten eingesetzt werden. Ein umfassender Ansatz zur

Modellierung der Unternehmensarchitektur sollte vernetzte und verteilte Strukturen sowie die

durch diese Strukturen resultierenden Herausforderungen an das Management reflektieren.

Ein Modell für die Abbildung der Applikationsarchitektur wird beispielsweise von WINTER

vorgeschlagen.132

129 Vgl. z.B. Österle (1995), IMG (1997) und Brecht (2002).

130 Vgl. Österle/Winter (2003), S. 12.

131 Vgl. Braun/Winter (2005b), S. 67.

132 Vgl. Winter (2003a).


Applikationen

Komponenten

Abbildung 10: Vereinfachtes Metamodell des BE133

Das primäre Ziel auf der Softwarekomponenten- und Datenstrukturenebene ist die optimale

(Wieder-)Verwendung von Softwareartefakten und entsprechenden Datenstrukturen. Gestal-

tungsobjekte für die Modellierung der Softwarekomponenten- und Datenstrukturebene wer-

den beispielsweise von SCHWINN134 vorgeschlagen. Er stellt vor allem diejenigen Gestal-

tungsobjekte in den Vordergrund, die zur Durchführung eines Applikationsintegrationspro-

jekts notwendig sind. Abbildung 10 zeigt zur Veranschaulichung eine vereinfachte Version

des ebenenübergreifenden Metamodells, das die Konsistenz zwischen den einzelnen Ebenen

gewährleistet.

Mit Hilfe des BE-Ansatzes sind in den letzten Jahren einige Methoden entstanden, die auf

verschiedene Branchen oder spezielle Problemstellungen ausgerichtet sind. Einige dieser Me-

thoden wurden für die Anwendung in der Praxis in einem Methodenset mit dem Namen

PROMET (Prozessmethode)135 zusammengefasst und weiterentwickelt. Eine weitere Methode

133 Vgl. Braun/Winter (2005b), S. 66 und Wortmann (2005), S. 14.

134 Vgl. Schwinn (2005).

135 Vgl. IMG (1997) und http://www.promet-web.com.


ist die BAI-Methode136, welche im Kompetenzzentrum Bankenarchitekturen im Informations-

zeitalter (CC BAI)137 entwickelt wurde und als Grundlage für das Dissertationsprojekt dient.

Die Methoden von PROMET als auch die BAI-Methode sind einheitlich nach den Grundsät-

zen des Methoden-Engineering138 strukturiert.

2.3.3 Methoden und Konsistenz

Nach der Beschreibung der Gestaltungsebenen des Business Engineering wird in diesem Ab-

schnitt darauf eingegangen, warum ein systematischer, umfassender Ansatz, basierend auf

einem ebenen- und sichtenübergreifenden Metamodell, für die Gestaltung von Organisations-

strukturen wichtig ist.139

Traditionell verfolgt der BE-Ansatz ein Top-Down-Vorgehen (Top-Down-Alignment), d.h.

eine Veränderung der Geschäftsstrategie erfordert eine Umgestaltung der Geschäftsprozesse

sowie Organisationsstrukturen und dies wiederum eine Anpassung der unterstützenden In-

formationssystemstrukturen.140 Entsprechend den Vorgehensweisen auf den einzelnen Gestal-

tungsebenen werden unterschiedliche Ergebnisdokumente erzeugt. Liegt diesen Ergebnisdo-

kumenten ein ebenenübergreifendes Metamodell zugrunde, so kann die Konsistenz der ge-

samten Spezifikation der Unternehmensarchitektur gewährleistet werden. Die Konstruktion

und Anwendung entsprechender Methoden ist deshalb für die Generierung konsistenter Er-

gebnisse bei der Abbildung der Unternehmensstrukturen unerlässlich. In der Praxis ist es oft-

mals schwierig, alle Abhängigkeiten zu identifizieren und in einem Metamodell zu erfassen.

Dies liegt unter anderem darin begründet, dass die Schlüsselelemente auf den unterschiedli-

chen Gestaltungsebenen unterschiedliche Lebenszyklen besitzen und im Verantwortungsbe-

reich von unterschiedlichen Unternehmensbereichen bzw. Organisationseinheiten liegen. Die

meisten existierenden Ansätze zur Gestaltung und Abbildung von Unternehmensstrukturen

schlagen Modellierungssprachen für bestimmte Ebenen oder Sichten vor, die allerdings nicht

durch ein gemeinsames zugrunde liegendes Metamodell miteinander verbunden sind. Da-

durch entstehen oftmals inkonsistente Modelle.

Ein ebenenübergreifendes Metamodell, das die Abhängigkeiten zwischen den einzelnen Mo-

dellen definiert, ist nicht nur für ein Top-Down-Vorgehen, sondern auch für einen Bottom-

Up-Ansatz (Bottom-Up-Alignment) eine wichtige Grundlage.141 Dadurch kann besser analy-

siert und abgeschätzt werden, welche Auswirkungen die Veränderung von Schlüsselelemen-

ten einer Ebene auf die Elemente der übergeordneten Ebenen hat (vgl. Abbildung 11). Typi-

136 Vgl. Choinowski et al. (2003).


138 Vgl. Gutzwiller (1994) und Heym (1993).

139 Vgl. im Folgenden auch Winter (2005).

140 Vgl. Österle (1995), S. 24.

141 Nach ÖSTERLE/BLESSING erfordert die Ebenenbildung im Business Engineering keine ausschliessliche

Top-Down-Vorgehensweise. Vgl. Österle/Blessing (2003), S. 77.


sche Fragen, die dadurch beantwortet werden können, sind beispielsweise: Welche Auswir-

kungen hat die Veränderung der technischen Architektur auf die Struktur der Applikationen?

Wie wirkt sich die Implementierung neuer Applikationen auf die Organisationsstrukturen und

Abläufe aus? Welche Auswirkungen haben organisatorische Veränderungen auf die Gestal-

tung der Vertriebskanäle und Partnerbeziehungen? Erfahrungen mit Veränderungen der Orga-

nisationsstrukturen und Geschäftsmodelle, die durch neue Technologien induziert wurden,

wie beispielsweise E-Commerce oder mobile Technologien, bestätigen die Relevanz dieses

Bottom-Up-Ansatzes in der Praxis.

Abbildung 11: Beispiel für Wechselwirkungen zwischen den Ebenen142

2.3.4 Die BAI-Methode

Die BAI-Methode unterstützt die systematische Gestaltung von Unternehmensarchitekturen,

insbesondere im Bankensektor. Der aktuelle Entwicklungsstand der BAI-Methode ist das Er-

gebnis des Kompetenzzentrums Bankenarchitekturen im Informationszeitalter (CC BAI).143

Im CC BAI wurden gemeinsam mit den Partnerunternehmen Architekturkonzepte für den

Vertriebsbereich im Retail Banking erarbeitet. Auf der Grundlage von Good Practices wurden

unternehmensspezifische Modelle sowie Referenzmodelle für die Geschäfts-, Organisations-

und Informationssystemebene identifiziert. Zusätzlich wurde ein Vorgehensmodell für die

konsistente Gestaltung von Geschäftsmodellen, Prozessen und Applikationen aufgestellt.

Die BAI-Methode wurde entsprechend den Grundsätzen des Methoden-Engineering (vgl.

Abschnitt 2.1.2) konstruiert. Sie bietet auf jeder Gestaltungsebene Vorgehensmodelle, Aktivi-

täten, Techniken sowie Metamodelle für die Spezifikation der Ergebnisdokumente. Um die

142 Vgl. in Anlehnung an Vogler (2003), S. 21.

143 Vgl. Leist/Winter (2002) und Choinowski et al. (2003).


Zusammenhänge zwischen den drei Ebenen abzubilden, besitzt die Methode ansatzweise ein

ebenenübergreifendes Metamodell.

Grundsätzlich beschreibt die BAI-Methode ein Top-Down-Vorgehen. Zunächst wird auf Stra-

tegieebene das Geschäftsnetzwerk festgelegt, das Leistungsmodell entwickelt, die Kunden-

prozessanalyse durchgeführt sowie das Zielsystem definiert. Anschliessend folgen auf Orga-

nisationsebene der Entwurf der Prozesslandkarte, der Prozessvision und der Prozessführung

sowie die Entwicklung der Ablauf- und Aufbauorganisation. Auf Applikationsebene wird

letztendlich anhand der Vorgaben auf Organisationsebene die Applikationsarchitektur abge-

leitet. Beim Übergang von einer Ebene zur nächsten werden jeweils diejenigen Elemente her-

ausgestellt, die in der darunter liegenden Ebene Verwendung finden bzw. einfliessen.144

Der in der vorliegenden Arbeit präsentierte Ansatz zur Modellierung der Unternehmensarchi-

tektur enthält die wesentlichen Konzepte der BAI-Methode. Diese werden daher in Kapitel 4

detaillierter beschrieben.

Trotz der ursprünglichen Fokussierung der BAI-Methode auf die Finanzbranche lassen sich

deren Konzepte weitgehend auch auf andere Branchen übertragen. Diese analog zur Refe-

renzmodellierung als Allgemeingültigkeit bezeichnete Eigenschaft einer Methode kann zwar

nur eingeschränkt erzielt und überprüft werden.145 Dennoch wird an den in dieser Arbeit auf

Basis der BAI-Methode entwickelten Ansatz ein branchenübergreifender Allgemeingültig-

keitsanspruch gestellt. Dieser Allgemeingültigkeitsanspruch muss durch den Einsatz des ent-

wickelten Prototyps und des Metamodells in zahlreichen Unternehmen verschiedener Bran-

chen überprüft und damit auf eine breite Fallstudienbasis gestellt werden.

2.4 Werkzeugkonstruktion und -unterstützung

Aufgrund der sich schnell und ständig ändernden Geschäftsanforderungen wird die Entwick-

lung geeigneter Informationssysteme zunehmend komplexer. Es hat sich gezeigt, dass Soft-

ware-Werkzeuge, deren zugrunde liegende Metamodelle nicht fest vorgegeben sind, sondern

flexibel angepasst werden können, den Umgang mit dieser Komplexität vereinfachen.146 Das

Methoden-Engineering (vgl. Abschnitt 2.1.1) erfordert folglich ebenfalls entsprechende Soft-

ware-Werkzeuge, um die Modellierungstechniken, Modellierungssprachen und Vorgehens-

modelle einer bestimmten Methode einrichten, umsetzen und flexibel anpassen zu können.

Anpassbare und erweiterbare Metamodelle sowie wieder verwendbare Mechanismen sind

eine wichtige Voraussetzung für die effiziente Konstruktion, Anwendung und Modifikation

von Methoden und Modellen.

144 Vgl. Choinowski et al. (2003), S. 35.

145 Vgl. hierzu z.B. vom Brocke (2003b), S. 31f. und Wortmann (2005), S. 100.

146 Vgl. hierzu z.B. Karagiannis/Kühn (2002).


Methoden für die Gestaltung von Unternehmensarchitekturen umfassen Vorgehensweisen,

Metamodelle und Modellierungstechniken auf den drei Ebenen Geschäftsstrategie, Organisa-

tion und Informationssystem (vgl. Abschnitt 2.1). In der Vergangenheit konzentrierte sich die

werkzeugunterstützte Modellierung auf Teilaspekte der gesamten Unternehmensarchitektur,

z.B. die Prozessmodellierung mit dem ARIS Toolset. Ausserdem basierten diese Werkzeuge

vor allem auf unveränderlichen, nicht anpassbaren Metamodellen.

Viele wissenschaftliche Arbeiten haben sich auf die Entwicklung von Software-Werkzeugen

für die Erfassung von Methodenwissen147 als auch auf die Konstruktion von anpassbaren Me-

tamodellierungswerkzeugen148 konzentriert. Metamodellierungswerkzeuge, oftmals auch als

Meta-CASE-Tools149 bezeichnet, bieten die Möglichkeit, Modellierungswerkzeuge für die

Verwendung einer bestimmten Methode zu konfigurieren. Sie können formale Beschreibun-

gen von Methoden interpretieren und daraus geeignete Modellierungswerkzeuge generieren,

die bestimmte Methoden unterstützen.150 Diese Metamodellierungswerkzeuge konnten sich

allerdings trotz ihrer Relevanz in der Praxis bisher nicht durchsetzen. Ein Grund dafür ist

vermutlich deren höhere Komplexität.

In den letzten Jahren versuchen nun aber zunehmend Hersteller von Modellierungswerkzeu-

gen für bestimmte Anwendungsbereiche, wie z.B. das Business Process Management oder das

Architekturmanagement151, Metamodellierungskonzepte in ihre Produkte zu integrieren, um

diese einfacher an die verwendete Methode und das unternehmensindividuelle Umfeld anpas-

sen zu können. Diese werden in der vorliegenden Arbeit nicht als Meta-CASE-Tools, sondern

als Metamodellierungsplattformen bezeichnet.152 Metamodellierungsplattformen ermöglichen

im Verständnis der vorliegenden Arbeit153

• die problemspezifische Definition von Methodenelementen, wie z.B. von Metamodellen,

• die Definition von Mechanismen, die auf Modelle und deren zugrunde liegende Metamo-

delle angewendet werden können,

• die Definition von Vorgehensmodellen, die das Vorgehen bei der Anwendung der Meta-

modelle und der entsprechenden Mechanismen beschreiben.

Die folgende Abbildung 12 zeigt die Anwendung des Metamodellierungskonzeptes auf die

Werkzeugkonstruktion. Spezifische Modellierungswerkzeuge (Konfigurationen) können von

147 Vgl. z.B. Heym (1993).

148 Vgl. z.B. Kelly/Smolander (1996) und Junginger et al. (2000).

149 CASE steht für Computer Aided Software Engineering.

150 Vgl. hierzu Nuseibeh et al. (1996), S. 267.

151 Vgl. z.B. Junginger et al. (2000) und James (2004b).

152 Vgl. z.B. Karagiannis/Kühn (2002).

153 Vgl. Karagiannis/Kühn (2002), S. 186f.


der Metaebene der Metamodellierungsplattform durch Anpassung des zugrunde liegenden

Meta-Metamodells abgeleitet werden.154

Abbildung 12: Metamodellierungskonzepte für die Werkzeugkonstruktion155

Es gibt zahlreiche Gründe für die Verwendung von Modellierungswerkzeugen:156 Sie bieten

zum einen Unterstützung bei der Standardisierung von Semantik und Syntax der verwendeten

Modellierungssprachen und -techniken einer Methode. Darüber hinaus gewährleisten sie die

Korrektheit und Konsistenz der erstellten Modelle durch automatisierte Konsistenzprüfungen

und die Anwendung von Gestaltungsprinzipien. In der Regel können auch Impact-Analysen

und quantitative Analysen durchgeführt werden. Zudem können Modellierungswerkzeuge den

Modellierer bei der Verwendung bzw. Wiederverwendung der erstellten Modelle unterstüt-

zen.

Die meisten neueren Ansätze zur Gestaltung von Unternehmensarchitekturen fokussieren auf

die Abbildung von Beziehungen zwischen aggregierten Artefakten unterschiedlichen Typs.

Vorrangiges Ziel dabei ist vor allem die Identifizierung von Inkonsistenzen zwischen den

einzelnen Artefakten sowie von Richtlinien für die konsistente, gesamthafte Abbildung von

Unternehmen und insbesondere deren Informationssystemen. Getrieben durch Aspekte wie

Anwendbarkeit und betriebswirtschaftlicher Nutzen wird die Unternehmensarchitektur zu-

nehmend als Konzept betrachtet, das die Analyse, Optimierung und Abstimmung von Ge-

schäftsstrategien, Organisationsstrukturen, Geschäftsprozessen, Informationsflüssen sowie

Informationssystemen unterstützt.157 Damit die Unternehmensarchitektur diese aktive Rolle

übernehmen kann, ist es erforderlich, dass hierfür geeignete Modellierungswerkzeuge zur

154 Vgl. Junginger et al. (2000), S. 393. 155

Vgl. Junginger et al. (2000), S. 393. 156

Vgl. im Folgenden auch Lankhorst (2005), S. 248. 157

Vgl. Schekkerman (2004), S. 201.


Verfügung stehen. Diese müssen nicht nur die Dokumentation von Artefakten und die Identi-

fizierung von Inkonsistenzen ermöglichen. Ein geeignetes Werkzeug muss zudem die Ent-

wicklung, die Speicherung, die Kommunikation, die Analyse sowie die Modifikation und

Erweiterung von allen relevanten Bestandteilen der Unternehmensarchitektur unterstützen.

Ebenso wie die Methoden befinden sich auch die Werkzeuge zur Unterstützung der Unter-

nehmensmodellierung noch in einem frühen Entwicklungsstadium.158 Von grosser Bedeutung

ist dabei vor allem die Definition und Abbildung von Abhängigkeiten zwischen Modellen auf

unterschiedlichen Architekturebenen. Aufgrund der Komplexität von Geschäftsstrukturen in

der Praxis können diese Abhängigkeiten oft nur schwer identifiziert und verstanden werden.

Für den Erfolg einer Unternehmensarchitektur ist es aber entscheidend, dass solche Abhän-

gigkeiten identifiziert und die Auswirkungen von Änderungen an den Elementen analysiert

und abgeschätzt werden können.

Auf dem Markt existieren bereits zahlreiche Anbieter für Werkzeuge zur Unternehmensmo-

dellierung.159 Deren Produkte unterstützen allerdings oftmals nur Teilbereiche der Unterneh-

mensarchitektur oder bieten begrenzt Schnittstellen zu anderen Werkzeugen. Dies lässt sich

damit begründen, dass viele der bisher als Werkzeuge für die Modellierung von Unterneh-

mensarchitekturen angebotenen Lösungen ursprünglich als anwendungsspezifische Werkzeu-

ge, beispielsweise für die Softwareentwicklung oder die Geschäftsprozessmodellierung, ent-

wickelt wurden. Die geringe Interoperabilität zwischen den Werkzeugen hat sowohl techni-

sche als auch konzeptionelle Gründe. Die aktuell auf dem Markt verfügbaren Werkzeuge

können nach TER DOERST/LANKHORST in folgende Kategorien eingeteilt werden (vgl.

Abbildung 13):160

• Unternehmensarchitektur: Dabei handelt es sich um speziell für die Unternehmensmodel-

lierung entwickelte Werkzeuge, die unterschiedliche Modellierungskonzepte für unter-

schiedliche Architekturebenen umfassen.

• Softwareentwicklung: Diese Werkzeuge stammen ursprünglich aus der Softwareentwick-

lung und integrieren zunehmend Techniken für die Modellierung von Geschäftsprozessen

und Unternehmensarchitekturen.

• Geschäftsprozessmanagement: Analog zu den Softwareentwicklungswerkzeugen integrie-

ren diese Werkzeuge zunehmend Modellierungstechniken der Softwareentwicklung (z.B.

UML) und abstraktere Modellierungskonzepte für die Unternehmensmodellierung.

• Repositorys und IT-Management: Diese Werkzeuge werden um Modellierungs- und Ana-

lysefunktionalitäten erweitert, die auch für die Unternehmensmodellierung relevant sind.


159 Für eine Übersicht aktuell auf dem Markt verfügbarer Werkzeuge zur Unternehmensmodellierung vgl.

IFEAD (2006). 160

Vgl. ter Doest/Lankhorst (2004), S. 2.


Abbildung 13: Kategorisierung der Werkzeugunterstützung161

In der Praxis werden oftmals Grafik-Tools wie Microsoft Visio oder Microsoft Powerpoint

verwendet, um die Artefakte der Unternehmensarchitektur zu dokumentieren.162 Allerdings

werden durch diese Werkzeuge die Prüfung der Konsistenz zwischen den einzelnen Modellen

und die Wiederverwendung von Modellen bzw. Modellkomponenten nicht unterstützt. Für

den Erfolg eines Unternehmensarchitektur-Projektes ist daher entscheidend, dass von Beginn

an professionelle, speziell für die Unternehmensmodellierung entwickelte Werkzeuge zum

Einsatz kommen. Professionelle Modellierungswerkzeuge speichern alle Artefakte der Unter-

nehmensarchitektur in einer Datenbank (Repository) und stellen Mechanismen für die Wie-

derverwendung und die Darstellung in unterschiedlichen Formen zur Verfügung.163 Entspre-

chend der in dieser Arbeit angeführten Charakterisierung der Unternehmensarchitektur (vgl.

Abschnitt 2.3) sollten Werkzeuge für die Unternehmensmodellierung daher auf einer Daten-

bank basieren,

• die Informationen über (a) Produkte/Services, (b) Ziele, Erfolgsfaktoren, Performance-

Indikatoren und Messgrössen, (c) Geschäftsnetzwerke, Rollen und Leistungsflüsse inner-

halb des Netzwerkes, (d) Aktivitäten, Organisationseinheiten und Kontrollflüsse, (e) In-

formationsobjekte und Informationsflüsse, (f) Applikationen, Funktionen und Verantwort-

lichkeiten sowie (g) Softwarekomponenten und eventuell auch (h) IT-Plattformen spei-

chert,

• der ein verständliches Metamodell zugrunde liegt, das diese Artefakte zueinander in Be-

ziehung stellt,

• die die Darstellung der Informationen in unterschiedlichen Formen, z.B. grafisch oder

textuell, ermöglicht und

161 Vgl. ter Doest/Lankhorst (2004), S. 3.

162 Vgl. hierzu z.B. IFEAD (2005), S. 29.



• die die Auswertung und Analyse der gespeicherten Informationen unterstützt.164

Da die Artefakte der Unternehmensarchitektur lediglich in einer verständlichen, aggregierten

Form abgebildet werden, ist es erforderlich, dass das Werkzeug Schnittstellen zu den operati-

ven Systemen besitzt. Operative Systeme, die Detailinformationen über Artefakte einer be-

stimmten Anwendungsdomäne verwalten, sind beispielsweise Application-Management-

Systeme, Product-Data-Management-Systeme oder Performance-Management-Systeme.165

2.5 Ziele und treibende Kräfte der Unternehmensarchitektur

Eines der primären Ziele und damit auch eine der wesentlichen treibenden Kräfte der Unter-

nehmensarchitektur stellt die Erreichung des schon seit längerer Zeit in der Praxis wie in der

Wissenschaft diskutierten IT-Business-Alignment dar.166 Das IT-Business-Alignment wird

allgemein als ein wichtiges Koordinationsinstrument gesehen, um organisatorische Strukturen

und Informationssysteme möglichst effektiv aufeinander abzustimmen.167

HENDERSON/VENKATRAMAN haben bereits vor einiger Zeit ein grundlegendes IT-Business-

Alignment-Modell aufgestellt.168 Der Grundgedanke dieses Modells ist die Ausrichtung der

Informationstechnologie an den strategischen Zielen eines Unternehmens. Die Autoren ver-

folgen mit diesem Modell das Ziel, einen Ansatz für die Ausrichtung der Informationstechno-

logie an den betriebswirtschaftlichen Anforderungen und Zielen des Unternehmens zu bieten,

um den Nutzen von IT-Investitionen zu steigern bzw. zu optimieren.

IT-Business-Alignment bedeutet allerdings nicht nur, dass die Informationstechnologie und

die Geschäftsstrategie eines Unternehmens aufeinander abzustimmen sind. Vielmehr kommt

es im Hinblick auf die Integration auch darauf an, die eingesetzten Technologien, die Organi-

sationsstrukturen und Abläufe sowie die benötigten Qualifikationen und Ressourcen zu koor-

dinieren.169

Das IT-Business-Alignment wird nach Ansicht einiger Autoren nicht durch die Optimierung

einzelner Komponenten oder Bereiche, sondern durch die bereichsübergreifende Koordination

aller organisatorischen Schlüsselelemente eines Unternehmens erreicht.170 LANKHORST ET AL.

sehen beispielsweise primär in der Definition der Beziehungen und Abhängigkeiten zwischen

Schlüsselelementen und nicht in der detaillierten Spezifikation aller Einzelkomponenten eine

164 Vgl. hierzu auch Braun/Winter (2005b), S. 68.

165 Vgl. hierzu auch Winter/Fischer (2006), S. 8-9.

166 Vgl. z.B. Aziz et al. (2005), IFEAD (2005), Lankhorst (2005) und Jonkers et al. (2004).

167 Vgl. z.B. Henderson/Venkatraman (1993), Luftman et al. (1993), Luftman et al. (1999) und

Sledgianowski/Luftman (2005). 168

Vgl. Henderson/Venkatraman (1993). 169

Vgl. Henderson/Thomas (1992), S. 72. 170

Vgl. z.B. Nadler et al. (1992), Lankhorst (2005), S. 6 und Schekkerman (2004), S. 30.


wichtige Voraussetzung für das erfolgreiche IT-Business-Alignment.171 Jede Organisation

sollte eine klare Vorstellung über ihre Strukturen, Produkte, Prozesse, Technologien etc. und

deren Zusammenhänge haben sowie über die Beziehungen zu ihrer Umwelt, wie beispiels-

weise Kunden, Lieferanten und Konkurrenten. Gerade grosse Organisationen mit komplexen

Strukturen sind auf die strukturierte Gestaltung und Dokumentation ihrer Architektur ange-

wiesen, da eine Veränderung der Geschäftsstrategie und Unternehmensziele erhebliche Aus-

wirkungen auf alle Bereiche des Unternehmens hat, wie beispielsweise auf die Organisations-

strukturen, Geschäftsprozesse, Informationssysteme sowie die technische Infrastruktur.172 Ein

passendes Beispiel zur Veranschaulichung dieses Sachverhaltes ist die Einführung eines neu-

en Produktes bzw. einer neuen Leistung. Diese erfordert die Änderung bestehender oder die

Definition neuer Geschäftsprozesse, eventuell die Einstellung zusätzlicher Mitarbeiter, die

Änderung oder Neueinführung unterstützender Applikationen sowie den Ausbau der techni-

schen Infrastruktur aufgrund der zunehmenden Belastung durch die neuen Applikationen.

Diese Auswirkungen auf die Unternehmensstrukturen sollten idealerweise vor der Einführung

eines neuen Produktes erörtert und abgeschätzt werden können. Darüber hinaus sind bei einer

solchen Entscheidung viele unterschiedliche Personen sowohl innerhalb als auch ausserhalb

des Unternehmens, von der Unternehmensführung bis zum Softwareentwickler, mit einzube-

ziehen. Jede in die Entscheidungsfindung eingebundene Person benötigt spezifische Informa-

tionen in einer ihr zugänglichen und verständlichen Form, um die Auswirkungen einer solch

weit reichenden Entscheidung beurteilen zu können. Es ist allerdings sehr schwierig, einen

Gesamtüberblick über die Veränderungen und deren Auswirkungen zu erhalten und Entschei-

dungsträger sowie Prozessgestalter und Softwareentwickler mit den für sie relevanten Infor-

mationen zu versorgen.

Die Definition und Dokumentation einer Unternehmensarchitektur stellt daher ein wichtiges

Instrument dar, um die Kommunikation und Diskussion zwischen den verantwortlichen Per-

sonen über die wesentlichen Elemente sowie deren Beziehungen und Funktionsweisen inner-

halb des Unternehmens zu ermöglichen. Sie stellt konsistente Informationen über das Unter-

nehmen an einem zentralen Ort für Mitarbeiter aus unterschiedlichen Geschäftsbereichen zur

Verfügung. Dadurch trägt sie entscheidend dazu bei, dass Mitarbeiter aus unterschiedlichen

Bereichen eine gemeinsame Sicht auf das Unternehmen haben und eine gemeinsame Sprache

und ein gemeinsames Verständnis über das Unternehmen und dessen Strukturen aufbauen

können. Mit Hilfe einer dokumentierten Unternehmensarchitektur können Führungskräfte

zudem besser beurteilen, wie gut die Ressourcen für die Erstellung von Leistungen bzw. Pro-

dukten eingesetzt werden und welche Technologien benötigt werden, um die Kundenprozesse

besser unterstützen zu können. Sie erleichtert somit auch die Reaktion auf Veränderungen und

das Treffen der richtigen Entscheidungen. Zudem reduziert eine für das gesamte Unterneh-

171 Vgl. Lankhorst (2005), S. 6-7.

172 Vgl. Jonkers et al. (2004), S. 257.


men definierte Architektur redundante und inkonsistente Informationen über das Unterneh-

men und trägt somit dazu bei, dass der Nutzen zukünftiger IT-Investitionen wesentlich besser

beurteilt werden kann.173

Die internen Treiber der Unternehmensarchitektur lassen sich entsprechend den obigen Aus-

führungen wie folgt zusammenfassen:174

• Änderungen der Strategie eines Unternehmens können besser beurteilt und umgesetzt

werden. (Strategieumsetzung)

• Auswirkungen von Veränderungen an der Unternehmensstruktur können besser abge-

schätzt werden. (Veränderung/Auswirkung)

• Die Kommunikation zwischen Mitarbeitern aus unterschiedlichen Unternehmensberei-

chen kann verbessert werden. (Kommunikationsbasis/IT-Business-Alignment)

• Die Abstimmung zwischen den Geschäftsanforderungen und der Informationstechnologie

führt zu niedrigeren Kosten und einer Steigerung des Nutzens von IT-Investitionen. (Kos-

ten/Nutzen)

• Die Qualität der erzeugten und angebotenen Produkte bzw. Leistungen kann gesteigert

werden. (Qualität)

• Die Einführung neuer Leistungen bzw. Produkte kann reduziert werden. (Time-to-Market)

• Die zuvor genannten Punkte können letztendlich eine gesteigerte Kundenzufriedenheit

bewirken. (Kundenzufriedenheit)

Neben den internen Treibern existieren auch externe Einflussfaktoren, die die systematische

Gestaltung und Dokumentation der Unternehmensarchitektur erfordern. In einer zunehmend

vernetzten Welt kann ein Unternehmen sich nicht mehr nur auf die eigenen Strukturen und

Prozesse konzentrieren. Verteilte Strukturen sind nicht nur ein Phänomen von

Informationssystemen und Softwarekomponenten.175 Auch Geschäftsprozesse erstrecken sich

zunehmend über die Grenzen einzelner Geschäftseinheiten oder sogar Unternehmen hinweg.

Zudem basieren neue Geschäftsmodelle immer häufiger auf Kooperationen oder Kooptionen.

Die Unternehmensarchitektur spielt dabei eine wichtige Rolle, da sie die Beziehungen und

Leistungsverflechtungen mit Kunden, Lieferanten und anderen Partnern im

Geschäftsnetzwerk abbildet.


174 Vgl. hierzu auch Lankhorst (2005), S. 10 und Infosys (2005).

175 Vgl. Österle et al. (2001).


Ein aktuelles Beispiel für die Bedeutung einer klar definierten Unternehmensarchitektur stellt

das Outsourcing von beispielsweise Geschäftsprozessen oder der IT-Infrastruktur dar.176 Für

den Erfolg eines jeden Outsourcing-Projektes ist es entscheidend, dass alle beteiligten Partner

einen klaren Einblick in die Abläufe und Verantwortlichkeiten haben und der Leistungsaus-

tausch sowie die Schnittstellen zwischen den Partnern klar definiert sind.177

Ein weiterer wichtiger externer Treiber sind Regulationen. Externe Regulationen zwingen

oftmals Unternehmen sowie staatliche Organisationen dazu, ihre Abläufe und Strukturen zu

dokumentieren, um nachweisen zu können, dass sie bestimmte gesetzliche Vorgaben erfüllen.

Aktuelle Beispiele für solche externen Regulationen sind der Clinger-Cohen Act178, Basel

II179 und der Sarbanes-Oxley-Act180. Die Übereinstimmung mit diesen bzw. die Einhaltung

(Compliance) dieser Gesetze kann ohne eine klar dokumentierte Unternehmensarchitektur nur

schwer gewährleistet werden.181

Die externen Treiber einer Unternehmensarchitektur lassen sich wie folgt zusammenfassen:

• Die Beziehungen zu Kunden, Lieferanten und anderen Partnern können besser gepflegt

und kontrolliert werden. (Beziehungen)

• Die Einhaltung externer Regulationen kann besser kontrolliert werden. (Regula-

tionen/Compliance)

• Unternehmensübergreifende Geschäftsprozesse lassen sich einfacher realisieren und kon-

trollieren. (Vernetzung)

Trotz der vielen zuvor genannten Faktoren, die für die Einführung einer Unternehmensarchi-

tektur sprechen bzw. diese erfordern, bestehen bei der praktischen Umsetzung in Unterneh-

men noch erhebliche Probleme. Diese liegen einerseits in der Definition des adäquaten Detail-

lierungsgrades und andererseits im Fehlen eines einheitlichen, für Mitarbeiter aus unterschied-

lichen Unternehmensbereichen verständlichen Modellierungskonzeptes begründet.182

Eine detaillierte Dokumentation der Schlüsselelemente aller Bereiche eines Unternehmens ist

eine aufwendige und zeitintensive Aufgabe. Dadurch rückt das eigentliche Ziel der Unter-

nehmensarchitektur, nämlich das Alignment, in den Hintergrund. Dies kann dazu führen, dass

176 Ein Überlick sowie eine Klassifikation aktueller Phänomene des Outsourcing findet sich z.B. in

Braun/Winter (2005a). 177

Vgl. z.B. Masak (2005), S. 14. 178

Vgl. CIO-Council (1996). 179

Vgl. z.B. Bundesbank (2004). 180

Vgl. Sarbanes-Oxley (2002). 181

DINNER/KOLBER haben in ihrer Arbeit beispielsweise einige Anforderungen von Basel II und des Sarbanes-Oxley-Act in den Bezugsrahmen von Zachman eingeordnet. Vgl. Dinner/Kolber (2005).

182 Im Rahmen eines Workshops des Kompetenzzentrums „Integration Factory“ (CC IF) gemeinsam mit

Praxisvertretern aus sechs verschiedenen Unternehmen der Finanzbranche zum Thema Unternehmensarchitekturen am 28.06.2005 wurden diese beiden Punkte als wesentliche Gründe für die Probleme bei der praktischen Umsetzung einer Unternehmensarchitektur genannt.


die wesentlichen und für den Erfolg einer Unternehmensarchitektur wichtigen ebenen- und

bereichsübergreifenden Zusammenhänge innerhalb des Unternehmens zu wenig berücksich-

tigt werden. Die detaillierte Dokumentation der einzelnen Bereiche sollte daher eher ausser-

halb des Betrachtungsraums der Unternehmensarchitektur erfolgen. Der Detaillierungsgrad

bei der Definition der Elemente der Unternehmensarchitektur sollte so gewählt sein, dass vor

allem die Zusammenhänge zwischen den Schlüsselelementen der einzelnen Ebenen und Be-

reiche innerhalb einer Organisation im Sinne eines Alignment möglichst gut und verständlich

abgebildet werden. Zusätzlich können die aggregierten Elemente der Unternehmensarchitek-

tur in domänenspezifischen Architekturen detaillierter abgebildet werden, was oftmals schon

der Fall ist.

Des Weiteren sollten die Elemente der Unternehmensarchitektur möglichst eindeutig und ver-

ständlich beschrieben sein, damit Mitarbeiter aus unterschiedlichen Unternehmensbereichen,

wie beispielsweise Softwareentwickler, Anwender und Manager, diese als gemeinsame

Kommunikationsbasis verwenden können. Bisher verwendet allerdings in den meisten Unter-

nehmen jeder Unternehmensbereich seine eigenen Beschreibungssprachen und -konventio-

nen.183 Es existiert bisher keine Standardsprache zur exakten Beschreibung von Unterneh-

mensarchitekturen, die für alle Bereiche eingesetzt werden kann.184 In manchen Unterneh-

mensbereichen erfolgt die Dokumentation von Strukturen in Fliesstext oder in Form von nicht

formal spezifizierten Diagrammen. In anderen werden die Strukturen dagegen sehr detailliert

mit formalen oder semi-formalen Modellierungssprachen abgebildet, die für Mitarbeiter ande-

rer Unternehmensbereiche nur schwer verständlich sind. Dies führt zu Missverständnissen

und erschwert die Abstimmung zwischen Architekten, Softwareentwicklern und Mitarbeitern

aus den Fachabteilungen. Aufgrund der Heterogenität der für die Abbildung der Unterneh-

mensarchitektur verwendeten Modellierungssprachen und -techniken können die Zusammen-

hänge zwischen den unterschiedlichen Domänen nur schwer identifiziert werden. Für die

Kommunikation zwischen unterschiedlichen Unternehmensbereichen und somit auch für die

Realisierung des IT-Business-Alignment ist aber eine klare und einheitliche Sicht auf die Zu-

sammenhänge eine grundlegende Voraussetzung.

Ein Ansatz zur Gestaltung der Unternehmensarchitektur sollte daher die Identifikation der

Abhängigkeiten zwischen Schlüsselelementen unterschiedlicher Bereiche bzw. Domänen

adressieren. Die Modelle der Methode sollten die Schlüsselelemente und deren Beziehungen

innerhalb einer Domäne in aggregierter und auch für Nicht-Domänenexperten verständlicher

Form abbilden. Ferner sollten die Beziehungen zwischen den Schlüsselelementen der unter-

schiedlichen Domänen klar definiert sein, um mögliche Auswirkungen von Veränderungen in

183 Vgl. hierzu z.B. IFEAD (2005), S. 30-31. Im Rahmen des zuvor genannten Workshops hat sich zudem

gezeigt, dass innerhalb jedes Unternehmens eine Vielzahl von Modellierungssprachen zum Einsatz kommt, die nicht durch ein übergreifendes Konzept miteinander integriert sind. Dadurch können Inkonsistenzen zwischen den in verschiedenen Unternehmensbereichen erzeugten Ergebnissen entstehen.

184 Vgl. Lankhorst (2005), S. 83.


einer Domäne nachvollziehen zu können. Damit die einzelnen Modelle, Elemente und Bezie-

hungen unmissverständlich interpretiert werden können, ist die formale oder zumindest semi-

formale Spezifikation der Modelle anhand eines zugrunde liegenden Metamodells notwendig.

Im Hinblick auf eine Werkzeugunterstützung können so die Modelle der Methode auch erst

implementiert und auf deren Grundlage anschliessend Analysen, wie beispielsweise Impact-

Analysen oder Konsistenzprüfungen, durchgeführt werden.

2.6 Konsequenzen für das weitere Vorgehen

Basierend auf den zuvor beschriebenen Grundlagen sowie den Zielen und treibenden Kräften

der Unternehmensarchitektur (Abschnitt 2.1 bis 2.5) können wesentliche Anforderungen an

die weitere Vorgehensweise formuliert werden.185 Diese sind unterteilt in Anforderungen an

den zu entwickelnden Ansatz sowie in Anforderungen an die Werkzeugunterstützung.

2.6.1 Anforderungen an einen Ansatz zur Modellierung der Unterneh-

mensarchitektur

Im Folgenden werden wesentliche Anforderungen zusammengefasst, die für das weitere Vor-

gehen zweckmässig sind. Ein Ansatz zur Modellierung der Unternehmensarchitektur muss

folgende Anforderungen erfüllen:

• Er muss alle Schlüsselelemente, die im Hinblick auf strategische Fragestellungen im

Schnittbereich zwischen Fachbereich und IT-Bereich relevant sind, in aggregierter Form

abbilden186 (Ganzheitlichkeit/Aggregation).

• Eine Einteilung in Architekturebenen und Sichten ist hilfreich, um unterschiedliche As-

pekte in unterschiedlichen Modellen darzustellen und somit die Komplexität beherrschbar

zu machen (Strukturierung/Komplexitätsreduktion).

• Der Ansatz muss die Abhängigkeiten zwischen den Schlüsselelementen abbilden sowie

die Konsistenz zwischen den einzelnen Architekturebenen und Sichten gewährleisten

(Konsistenz).

• Die verwendeten Konzepte müssen anschaulich und verständlich sein (Anschaulich-

keit/Verständlichkeit). Dies hängt vor allem von der graphischen Notation ab. Die graphi-

sche Notation sollte daher eine deutliche Abbildung von Sprachkonzepten auf graphische

Symbole bieten, zudem sollten die Symbole semantisch nicht überladen sein.187 Bei der

Modellierung betrieblicher Informationssysteme wird die Anschaulichkeit vor allem durch

185 Die Ableitung der Anforderungen erfolgt in Anlehung an Kremer (2004), S. 33.

186 Vgl. hierzu auch die in Winter/Fischer (2006) als wesentlich identifizierten Elemente einer

Unternehmensarchitektur. 187

Vgl. z.B. Frank/Van Laak (2003), S. 29f.


Sprachkonzepte gefördert, die vertraute Darstellungen spezieller Sichten, wie z.B. von

Geschäftsprozessen oder Organisationsstrukturen, ermöglichen.

• Die für den jeweiligen Modellierungszweck erforderlichen Aspekte des abzubildenden

Sachverhaltes müssen in einer sinnvollen Detaillierung und Formalisierung dargestellt

werden (Angemessenheit/Mächtigkeit).

• Der Ansatz muss erweiterbar sein, da sich die Vorstellungen über die abzubildenden

Sachverhalte im Zeitverlauf ändern können (Flexibilität).

• Die verwendeten Konzepte müssen formal spezifiziert sein, damit sie unmissverständlich

interpretiert werden können (Formalisierung). Zudem erfordert die ingenieurmässige

Entwicklung von Informationssystemen eine (semi-)formale Definition der Semantik kon-

zeptueller Modelle mittels entsprechender Metamodelle. Im Idealfall bedeutet dies, dass

aus dem Metamodell alle zulässigen Modelle generiert werden können und dass für jedes

Modell entschieden werden kann, ob es zulässig ist.

• Die systematische Gestaltung der Unternehmensarchitektur muss durch eine umfassende

Berücksichtigung aller Bestandteile des Methoden-Engineering unterstützt werden (Me-

thodenelemente).

Neben den zuvor genannten Anforderungen an einen Ansatz zur Modellierung der Unterneh-

mensarchitektur lassen sich auch wesentliche Anforderungen an die softwaretechnische

Werkzeugunterstützung ableiten.

2.6.2 Anforderungen an die Werkzeugunterstützung

Die Anforderungen an die Werkzeugunterstützung können aus unterschiedlichen Perspektiven

betrachtet werden. Es kann nach den Perspektiven „Metamodellierung und Mechanismen“,

„Organisation“ und „Technologie“ differenziert werden. Die Anforderungen der Perspektive

„Metamodellierung und Mechanismen“ garantieren eine entsprechende Unterstützung der

Modellierungstechniken und entsprechender zielgerichteter Mechanismen, wie beispielsweise

der Simulation, der Prüfung von Abhängigkeiten und Konsistenz sowie der Referenzmodel-

lierung. Vorgehensmodelle, Richtlinien und Benutzerfreundlichkeit sind die wesentlichen

Kriterien der organisatorischen Perspektive. Die technologische Perspektive betrachtet Krite-

rien wie Anpassbarkeit, Skalierbarkeit, Multi-Client-Fähigkeit und offene Architekturen.

Die Anforderungen der Perspektive „Metamodellierung und Mechanismen“ bilden die Grund-

lage der Umsetzung eines Metamodellierungskonzeptes. Sie stehen daher mit allen anderen

Anforderungen in Verbindung.

• Aufgrund einer Änderung der Ziele der verwendeten Methode oder einer veränderten Pro-

jektsituation muss eine einfache Erweiterbarkeit und Anpassbarkeit des zugrunde liegen-


den Metamodells ohne Programmieraufwand möglich sein.188 (Erweiterbar-

keit/Anpassbarkeit)

• Die Verbindung oder Integration von Metamodellen mit unterschiedlichen Anwendungs-

bereichen sollte ohne grossen Programmieraufwand möglich sein, um beispielsweise eine

integrierte Prozess-, Produkt- und Informationssystem-Modellierung zu ermöglichen. (In-

tegration)

• Es müssen entsprechende Mechanismen für die Überprüfung der Konsistenz zwischen den

erstellten Modellen und deren Abhängigkeiten implementiert sein. (Konsistenz)

• Bei der Änderung des zugrunde liegenden Metamodells muss eine einfache Migration von

Modellen, die noch auf einer alten Version des Metamodells basieren, möglich sein.189

(Migration)

• Es müssen Mechanismen für die Klassifikation und Kategorisierung sowie Suchmuster für

die Wiederverwendung von Modellen bereitgestellt werden. (Wiederverwendung)

• Eine Datenbank mit Import-/Export-Funktionalitäten für Metamodelle, Modelle und Me-

thodenfragmente ist ein zentraler Bestandteil eines Metamodellierungswerkzeuges.190

(Import/Export)

• Es müssen Funktionen für die Generierung unterschiedlicher Sichten auf Modelle, Objek-

te und Attribute zur Verfügung stehen, um dadurch generelle Mechanismen für die Mo-

dellanalyse zu ermöglichen.191 (Analyse)

• Funktionalitäten für die Automatisierung bestimmter Modellierungsaktivitäten erleichtern

die Erstellung von Modellen.192 Beispiele für solche Funktionalitäten sind die Modellge-

nerierung basierend auf Referenzmodellen oder die Sichtengenerierung basierend auf im-

portierten Modellinformationen. (Automatisierung)

In Bezug auf die Erstellung, Verwaltung und Verwendung von Methoden und deren Bestand-

teilen können unterschiedliche Rollen und Aktivitäten differenziert werden, die jeweils unter-

schiedliche Anforderungen an die Modellierungsplattform stellen.193 Der Methodenkonstruk-

teur ist verantwortlich für die Einhaltung der Konsistenz der gesamten Methode. Der Spra-

chenentwickler definiert die Syntax, Semantik und Notation der verwendeten Modellierungs-

sprachen. Der Prozessentwickler ist verantwortlich für die Vorgehensweise und deren Aktivi-

täten. Der Werkzeugentwickler bildet die Methode und deren Komponenten in dem Werk-

188 Vgl. Junginger et al. (2000).

189 Vgl. Kühn et al. (2004).

190 Vgl. Kühn et al. (2003).

191 Vgl. Kühn et al. (1999).

192 Vgl. Kühn et al. (2003).

193 Vgl. im Folgenden Karagiannis/Kühn (2002).


zeug ab, und der Anwender setzt die Methode und das Werkzeug letztendlich ein. Die organi-

satorische Perspektive umfasst folgende wesentlichen Anforderungen:

• Die Integration mit Projektmanagement-Werkzeugen ermöglicht die Einhaltung und Pla-

nung der von der verwendeten Methode definierten Vorgehensweisen und Ergebnisse.

(Planung)

• Das Werkzeug muss unterschiedliche, vom jeweiligen Anwendungsbereich abhängige

Versionierungskonzepte unterstützen, wie beispielsweise zeitliche Versionierung, modell-

basierte Versionierung oder Check-In/Check-Out-Mechanismen. (Versionierung)

• Anwendungskonzepte werden durch Rollenmodelle und Verantwortlichkeiten unterstützt.

Diese müssen auch in dem Rechte- bzw. Autorisierungskonzept des Werkzeuges imple-

mentiert sein. (Rechtekonzept)

• Eine intuitiv bedienbare Benutzeroberfläche erleichtert die Einarbeitung von Anwendern.

Unterschiedliche Sichten, abhängig von den Kenntnissen der Anwender, sollten ohne Pro-

grammieraufwand flexibel generiert werden können. (Benutzerfreundlichkeit)

• Wenn die Methode Best Practices beinhaltet, sollte das Werkzeug das Vorgehen zur An-

wendung und Anpassung dieser Best Practices unterstützen. (Referenzmodellierung)

Die Anforderungen der technologischen Perspektive lassen sich wie folgt zusammenfassen:194

• Es sollte eine verteilte Modellierung und Ergebnisdokumentation möglich sein. Die Er-

gebnisdokumentation könnte beispielsweise in Form von Web-Seiten, auf die zentral im

Intranet zugegriffen werden kann, erfolgen. (Verteilung)

• Das Werkzeug muss Schnittstellen zu den operativen Systemen anbieten, um die aggre-

gierten Informationen der Unternehmensarchitektur mit den Detailinformationen der ope-

rativen Systeme verknüpfen zu können. (Schnittstellen)

• Das Werkzeug sollte für unterschiedliche Architekturen, wie Stand-alone, Client-Server

und Application Hosting, konfigurierbar sein. Eine offene, serviceorientierte Architektur

ermöglicht die Integration zusätzlicher Modellierungswerkzeuge, Standard-Interfaces so-

wie wieder verwendbare Komponenten. (Architektur)

• Das Werkzeug sollte plattformunabhängig einsetzbar sein. (Plattformunabhängigkeit)

Das folgende Kapitel 3 vergleicht bestehende Ansätze anhand der in Abschnitt 2.6.1 genann-

ten Anforderungen an einen Ansatz zur Modellierung der Unternehmensarchitektur. Die in

diesem Abschnitt zusammengefassten Anforderungen an die Werkzeugunterstützung werden

bei der Wahl einer geeigneten Metamodellierungsplattform sowie der anschliessenden Kon-

struktion des Prototyps berücksichtigt.

194 Vgl. im Folgenden auch Kühn/Bayer (2004) und Karagiannis/Kühn (2002).

Bisherige relevante Ansätze 47

3 Bisherige relevante Ansätze

Das Ziel des Dissertationsvorhabens ist die Entwicklung eines Ansatzes sowie die prototypi-

sche Konstruktion eines Werkzeuges zur Modellierung der Unternehmensarchitektur, basie-

rend auf einer bestehenden Methode. Der Vorschlag eines neuen Ansatzes in diesem Bereich

ist nur dann sinnvoll, wenn keine Methode vorhanden ist oder existierende Methoden in Be-

zug auf die an sie gestellten Anforderungen unvollständig sind. Auf Grundlage der in Ab-

schnitt 2.6 abgeleiteten Kriterien werden in diesem Kapitel existierende Ansätze zur Model-

lierung der Unternehmensarchitektur anhand des inhaltlichen Beitrages (inhaltliche Charakte-

ristika) sowie der definierten Methodenelemente (strukturelle Charakteristika) beurteilt.195 Im

Hinblick auf die Entwicklung eines eigenen ebenenübergreifenden Metamodells liegt der Fo-

kus bei der Beschreibung der verwandten Ansätze auf dem Methodenelement „Metamodell“.

Die folgende Tabelle 4 gibt einen Überblick über die angewendeten Bewertungskriterien.

Kriterium Beschreibung Inhaltliche Charakteristika

Aggregation/

Ganzheitlichkeit

Abbildung aller Schlüsselelemente und deren Beziehungen in aggregierter Form, die für strategische Entscheidungen im Schnittbereich zwischen Fachbereich und IT-Abteilung relevant sind

Strukturierung Strukturierung der Schlüsselelemente nach unterschiedlichen Architekturebenen und Sichten

Konsistenz Abbildung der Abhängigkeiten zwischen den Schlüsselelementen sowie Gewähr-leistung der Konsistenz zwischen den einzelnen Architekturebenen und Sichten

Verständlichkeit Deutliche Abbildung von Sprachkonzepten auf grafische Symbole, mit denen der Anwender oder Betrachter der Modelle vertraut ist

Angemessenheit Darstellung der abzubildenden Sachverhalte in einer sinnvollen Detaillierung und Formalisierung

Flexibilität Erweiterbarkeit der Metamodelle im Hinblick auf eine mögliche Änderung der abzubildenden Sachverhalte im Zeitverlauf

Formalisierung (Semi-)formale Definition der Semantik konzeptueller Modelle mittels entspre-chender Metamodelle

Strukturelle Charakteristika

Methodenelemente

Darstellung von Methodenbestandteilen im Sinne des Methoden-Engineering, wie z.B. Vorgehensmodelle, Metamodelle, Techniken, Rollenmodelle und Ergebnisdo-kumente

Tabelle 4: Bewertungskriterien

Im folgenden Abschnitt erfolgt zunächst die Auswahl der bestehenden Ansätze anhand defi-

nierter Kriterien. Diese werden anschliessend beschrieben und anhand der oben genannten

195 In Anlehnung an Kremer (2004) und Legner (1999).


Kriterien bewertet. Aus der Analyse bestehender Ansätze werden Konsequenzen für den ei-

genen Ansatz abgeleitet.

3.1 Auswahl der Ansätze

Die Auswahl der zu betrachtenden Ansätze erfolgt anhand von drei wesentlichen Kriterien:

Ein Kriterium stellt die Anzahl der aktuell am Markt verfügbaren Software-Werkzeuge dar,

die einen bestimmten Ansatz unterstützen.196 Darüber hinaus wird betrachtet, wie gross die

Anzahl und Verfügbarkeit von Veröffentlichungen zu einem bestimmten Ansatz sind und wie

gross seine wissenschaftliche Bedeutung ist. Letztere kann beispielsweise daran gemessen

werden, wie häufig dieser in Publikationen referenziert wird. Da das Dissertationsvorhaben

die umfassende Modellierung der Unternehmensarchitektur fokussiert, wird ausserdem vor-

ausgesetzt, dass der Ansatz das Unternehmen in mehrere Gestaltungsebenen und Sichten ein-

teilt und diese konsistent abbildet.

Der Vergleich basiert auf der Auswertung von Publikationen (Bücher, Zeitschriftenartikel,

Konferenzbeiträge) zu den einzelnen Ansätzen. Die Analyse wurde im Oktober 2005 abge-

schlossen. Sie umfasst die in Tabelle 5 aufgeführten Ansätze.

Weitere Ansätze, die im Rahmen des Vergleichs betrachtet wurden, sind die Model Driven

Architecture (MDA)197, die Informationssystem-Architektur (ISA) nach KRCMAR198 sowie das

Treasury Enterprise Architecture Framework (TEAF) und das Department of Defense Archi-

tecture Framework (DoDAF). Diese werden allerdings aus folgenden Gründen nicht in die

detaillierte Beschreibung relevanter Ansätze der vorliegenden Arbeit aufgenommen:

• MDA ist zu sehr auf softwareentwicklungsrelevante Aspekte fokussiert, wie beispielswei-

se die plattformunabhängige Modellierung von Softwaresystemen und die automatische

Code-Generierung aus UML-Modellen. Die OMG hat zwar durch die Einführung des so

genannten Computer Independent Model (CIM) den Fokus von MDA um fachliche As-

pekte erweitert.199 Im traditionellen Sinne stellt dieses allerdings lediglich die Fachspezi-

fikation eines Softwaresystems dar. Der MDA-Ansatz bietet daher zu wenig Konzepte im

Sinne der Unternehmensarchitektur, wie sie in der vorliegenden Arbeit definiert ist.

• ISA bietet keine Metamodelle für die Definition der einzelnen Sichten und ist daher für

die Entwicklung des eigenen Ansatzes lediglich im Hinblick auf die Einteilung in Archi-

196 Eine Übersicht über gängige Ansätze und deren Werkzeugunterstützung bieten z.B. James (2004a) und

Schekkerman (2004). 197

Vgl. hierzu z.B. OMG (2003a) und Völter (2003). 198

Vgl. Krcmar (1990). 199

Vgl. Masak (2005), S. 252.


tekturebenen und Sichten interessant. Eine entsprechende Analyse von ISA wurde bereits

in der Arbeit von WINTER durchgeführt.200

• Im Bereich der Bezugsrahmen (Frameworks) aus der Praxis wurden lediglich FEAF (Fe-

deral Enterprise Architecture Framework), TOGAF (The Open Group Architecture Fra-

mework) und das Zachman Framework ausgewählt, da diese einer Studie von IFEAD (In-

stitute For Enterprise Architecture Developments) zufolge in der Praxis am weitesten ver-

breitet sind.201

• Zudem basieren einige weitere Bezugsrahmen, wie beispielsweise DoDAF und TEAF, auf

dem Zachman Framework und sind auf einander ausgerichtet.

Ansatz Kurzbeschreibung Architektur integrierter Informations-systeme (ARIS) Primäre Quellen: Scheer (1998), Scheer (2001), Scheer/Jost (2002), Scheer/Thomas (2005)

ARIS ist auf den Geschäftsprozess ausgerichtet und verfolgt den Ansatz, Informationssystem und Geschäftsprozesse integrativ zu betrachten.

Semantisches Objektmodell (SOM) Primäre Quellen: Ferstl/Sinz (1995), Ferstl/Sinz (1998)

SOM wurde mit dem Ziel der geschäftsorientierten Gestal-tung von Informationssystemen entwickelt.

Met

hod

en a

us

der

Wis

sen

sch

aft

Multi-Perspective Enterprise Model-ling (MEMO) Primäre Quellen: Frank (1994), Frank (1998b), Frank (2002)

MEMO ist eine Methode zur multiperspektivischen Unter-nehmensmodellierung. Die Methode bietet einen Bezugs-rahmen, der die Strukturierung eines Unternehmens bzw. einer Organisation auf einem hohen Abstraktionsniveau ermöglicht.

Zachman Framework Primäre Quellen: Zachman (1987), Zachman/Sowa (1992)

Das Zachman Framework stellt einen Bezugsrahmen für die Klassifizierung von Konzepten zur Verfügung, um Objekte der realen Welt mit den entsprechenden Repräsentationen in den Informationssystemen zu verbinden.

Federal Enterprise Architecture Framework (FEAF) Primäre Quellen: FEA (1999), FEA (2001)

FEAF ist ein Bezugsrahmen für die gemeinsame Entwick-lung von Prozessen und Informationsstrukturen zwischen US-staatlichen Organisationen.

Bezu

gsr

ah

men

au

s d

er P

raxis

The Open Group Architecture Frame-work (TOGAF) Primäre Quellen: Opengroup (2002)

TOGAF ist ein Industriestandard für die Entwicklung von IT-Architekturen. Die aktuelle Version wurde im Sinne der Unternehmensarchitektur um weitere Ebenen erweitert.

Tabelle 5: Übersicht der analysierten Ansätze

Im folgenden Abschnitt werden die ausgewählten Ansätze analysiert und hinsichtlich der in

Tabelle 4 aufgeführten Kriterien bewertet.

200 Vgl. dazu Winter (2003d).

201 Vgl. IFEAD (2005), S. 28.


3.2 Diskussion ausgewählter Methoden aus der Wissenschaft

Methoden zur Modellierung der Unternehmensarchitektur, die vor allem im deutschsprachi-

gen Raum von Bedeutung sind und im universitären Umfeld entwickelt wurden, sind das Se-

mantische Objektmodell (SOM), Multi-Perspective Enterprise Modeling (MEMO) sowie die

Architektur Integrierter Informationssysteme (ARIS). Für alle diese drei Methoden wurden

Werkzeuge erstellt, es ist umfangreiche Literatur über sie vorhanden, die frei verfügbar ist,

und sie werden in anderen Arbeiten häufig referenziert. Ausserdem streben alle Methoden

eine umfassende Unternehmensmodellierung an. Um die Vergleichbarkeit der Methoden si-

cherzustellen, werden diese im Folgenden einerseits in Bezug auf die Einteilung in Modellie-

rungsebenen und Sichten sowie andererseits anhand der in Abschnitt 2.1 genannten wesentli-

chen Methodenbestandteile (Metamodell, Vorgehensmodell, Techniken, Ergebnisdokumente

und Rollen) beschrieben. Die Beurteilung der Methoden erfolgt zudem anhand der in Ab-

schnitt 2.6 definierten inhaltlichen Charakteristika. Im Hinblick auf den eigenen zu entwi-

ckelnden Ansatz werden vor allem die Metamodelle der einzelnen Methoden detailliert be-

trachtet.

3.2.1 Architektur integrierter Informationssysteme (ARIS)

3.2.1.1 Übersicht und Architekturebenen

Die Architektur integrierter Informationssysteme (ARIS) ist auf den Geschäftsprozess ausge-

richtet. Ein Geschäftsprozess wird im ARIS-Konzept als zusammengehörende Abfolge von

Unternehmensverrichtungen zum Zweck einer Leistungserstellung definiert.202 ARIS verfolgt

den Ansatz, Informationssystem und Geschäftsprozesse integrativ zu betrachten.203 Dabei

werden die folgenden fünf Sichten auf das Unternehmen unterschieden: 204

Die Funktionssicht legt die Funktionen (oftmals werden synonym die Begriffe Vorgang,

Aktivität, Tätigkeit oder Aufgabe verwendet) fest, die ein Unternehmen effizient ausführen

muss. Sie werden meist in Verbindung mit Daten beschrieben, da sie Input-Daten zu Output-

Daten transformieren. Eine Funktion unterstützt eines oder mehrere Ziele, welche hierar-

chisch gegliedert und netzartig untereinander verflochten sein können. Daneben wird in der

Funktionssicht die Anwendungssoftware abgebildet, welche die computerunterstützten Funk-

tionen definiert.

Die Organisationssicht beschreibt die Aufbauorganisation, also die Organisationseinheiten

mit den zwischen ihnen bestehenden Kommunikations- und Weisungsbeziehungen. Zusätz-

lich wird mit dem Rollenkonzept das Anforderungsprofil einer Organisationseinheit definiert.

202 Vgl. Leist (2002), S. 14.

203 Vgl. Winter (2003d), S. 93.

204 Vgl. im Folgenden Scheer (1998), S. 36, Scheer (2001), Scheer/Jost (2002) und Scheer/Thomas (2005).


Die Datensicht enthält die Beschreibung der Datenobjekte, die von Funktionen manipuliert

bzw. transformiert werden, sowie Nachrichten, die Funktionen auslösen oder von Funktionen

erzeugt werden.

Abbildung 14: ARIS-Haus205

Die Leistungssicht umfasst alle materiellen und immateriellen Leistungen, die als Input oder

Output von Funktionen festgelegt werden können.

Diese Sichten sollen möglichst unabhängig voneinander entwickelt und bearbeitet werden

können, um die Komplexität beherrschbar zu machen. Um trotz der getrennten Modellierung

der einzelnen Sichten die Beziehungen innerhalb des Gesamtmodells berücksichtigen zu kön-

nen, wird die Steuerungssicht eingeführt. Diese stellt die zentrale Sicht innerhalb von ARIS

dar. Sie verbindet die einzelnen Sichten miteinander und bildet somit den gesamten Ge-

schäftsprozess ab.

Die Ebenenbildung erfolgt in ARIS erst nach der Entwicklung der Sichten (vgl. Abbildung

14). Grundlage hierfür ist ein Phasenmodell, das drei Stufen der Umsetzung vom fachlichen

Konzept bis hin zur Implementierung der Informationssysteme umfasst. Auf der Ebene des

Fachkonzepts werden betriebswirtschaftliche Konzepte abgebildet, die die fachlichen Grund-

lagen für die zu entwickelnden Informationssysteme beschreiben. Auf der Ebene DV-

Konzept werden die Beschreibungen des Fachkonzepts an generelle Schnittstellen der Infor-

205 Vgl. Scheer (2001), S.1.


mationstechnik angepasst. Die Ebene der Implementierung beschreibt die programmiertech-

nische Umsetzung des DV-Konzepts.

Für alle Sichten bestehen Metamodelle, die zu einem integrierten Metamodell verknüpft wer-

den können. ARIS schreibt keine bestimmten Metamodelle für die Ausgestaltung der Model-

lierungssprachen einzelner Ebenen vor. Exemplarisch liegen für alle Ebenen Metamodelle

vor, um insbesondere für die Steuerungssicht im Sinne der Geschäftsprozessmodellierung

Referenzmodelle als Konstruktionshilfen anzubieten.206

3.2.1.2 Metamodelle von ARIS

Im Hinblick auf die Entwicklung eines eigenen Ansatzes und Metamodells für die Modellie-

rung der Unternehmensarchitektur werden an dieser Stelle lediglich die Metamodelle des

Fachkonzepts (vgl. Abbildung 14) von ARIS beschrieben.

Die Modellierung der strategischen Geschäftsprozesse geht der Beschreibung der einzelnen

Sichten des ARIS-Hauses (vgl. Abbildung 14) voraus. Sie umfasst das Metamodell des strate-

gischen Geschäftsprozessmodells sowie das Metamodell des strategischen Vorgangsketten-

diagramms.

Für die Gestaltung der Kernprozesse werden Ansätze der strategischen Planung herangezo-

gen, die eine Analyse der strategischen Geschäftsprozesse sowie eine Bestimmung der strate-

gischen Soll-Konzeption beinhalten. Als Ergebnis dieser beiden Aktivitäten liegen die we-

sentlichen Ziele, Geschäftsfelder und die auf hoher Aggregationsstufe neu zu gestaltenden

Geschäftsprozesse mit den zu beseitigenden Schwachstellen vor. Des Weiteren wird die stra-

tegische Ausrichtung bezüglich der die Geschäftsprozesse unterstützenden Informationstech-

nologie festgelegt.

Im Metamodell werden mehrere Ansätze der strategischen Planung integriert, wie beispiels-

weise das Wertschöpfungskettendiagramm nach PORTER207 und das Konzept der kritischen

Erfolgsfaktoren nach ROCKART208. Zudem werden Effizienzkriterien betrachtet, Leistungsfel-

der differenziert und Organisationseinheiten (in Form von Organisationssegmenten darge-

stellt) untersucht. Abbildung 15 zeigt die wesentlichen Elemente des Metamodells des strate-

gischen Geschäftsprozessmodells.

Die Wertschöpfungskette besteht aus mehreren Wertschöpfungsfunktionen. Eine Wertschöp-

fungsfunktion ist als eine mächtige Funktion definiert, die in einem Wertschöpfungsdia-

gramm dargestellt wird.209 Die Segmente der Aufbauorganisation werden durch den Metaenti-

tätstyp „Organisationssegment“ repräsentiert. Dabei wird zwischen einer mehr horizontalen

206 Vgl. Schlitt (2003), S. 178.

207 Vgl. Porter (1999).

208 Vgl. Rockart (1979).

209 Vgl. Scheer (2001), S. 14.


Organisation (Funktionssegment) und einer mehr vertikalen Gliederung (Geschäftsprozess-

segment) unterschieden.210 Ein Leistungsfeld beschreibt wichtige Produkt- bzw. Leistungs-

gruppen des Unternehmens. Die Anzahl der Ausprägungen der Beziehungen zwischen Orga-

nisationssegment und Leistungsfeld sowie Organisationssegment und Wertschöpfungsfunkti-

on zeigt, ob es sich eher um eine funktions- oder prozessorientierte Organisation handelt. Die

unterschiedlichen Organisationskonzepte (funktionale Gliederung, prozessorientierte Organi-

sation, hybride Organisation) müssen gewissen Effizienzkriterien folgen.211 Einem Organisa-

tionssegment können daher ein oder mehrere Effizienzkriterien zugeordnet werden, für das es

einen bestimmten Beitrag leistet. Der abstrakte Metaentitätstyp „Effizienzkriterium“ wird in

die organisatorischen Effizienzkriterien „Prozesseffizienz“, „Ressourceneffizienz“ und

„Markteffizienz“ spezialisiert. Ein Geschäftsprozesssegment besteht aus mehreren Prozessen,

die vom Typ „Unterstützungsprozess“ oder „Kernprozess“ sein können. Ausserdem können

den Kernprozessen sowie einzelnen Wertschöpfungsfunktionen kritische Erfolgsfaktoren zu-

geordnet werden. Die Kernprozessvarianten spezialisieren die Kernprozesse und werden an-

hand der Kundengruppen segmentiert.

Metamodell des strategischen Geschäftsprozessmodells

Geschäfts-

prozesssegment

Wertschöpfungs-

kette

Kernprozess-

variante

Kritischer

Erfolgsfaktor

Wertschöpfungs-

funktion

Unterstützungs-

prozess

Organisations-

segment

Leistungsfeld

spezialisiert

segmentiert

Funktions-

segment

Kernprozess

Kunden-

gruppe

unterstützt

hat

ist zugeordnet

ist notwendig für

ist zugeordnet

Abbildung 15: Metamodell des strategischen Geschäftsprozessmodells212

Die bei der Erstellung des strategischen Geschäftsprozessmodells identifizierten Kernpro-

zessvarianten werden mit Hilfe von strategischen Vorgangskettendiagrammen in einzelne

Aufgabenschritte zerlegt.213 Das Vorgangskettendiagramm unterscheidet sich nur aufgrund

der Anordnung der Objekte im Diagramm sowie der eingeschränkten Anzahl an verfügbaren

Metaentitätstypen von einer EPK (Ereignisgesteuerte Prozesskette). Die Kernprozesse werden

lediglich so weit zerlegt, dass wesentliche strategische Mängel des gegenwärtigen Ablaufs

210 Vgl. Scheer (2001), S. 13.

211 Vgl. Scheer (2001), S. 7.

212 Vgl. Scheer (2001), S. 12.

213 Vgl. Scheer (2001), S. 15.


und die Vorteile des zukünftigen Ablaufs identifiziert werden können. Die Darstellung bleibt

somit auf einer rein strategischen Ebene. Das Metamodell wird in Anlehnung an das von

LEIST vorgeschlagene vereinfachte Metamodell der EPK dargestellt (vgl. Abbildung 16).

Abbildung 16: Metamodell des strategischen Vorgangskettendiagramms214

Die Funktionssicht wird häufig im Zusammenhang mit Komponenten anderer Sichten mo-

delliert, wie beispielsweise in Verbindung mit Daten, die von Funktionen transformiert wer-

den, oder Organisationseinheiten, die für die Durchführung einer bestimmten Funktion ver-

antwortlich sind. Der Begriff Funktion ist nicht allgemeingültig definiert und wird häufig sy-

nonym mit den Begriffen Vorgang, Tätigkeit, Aktivität oder Aufgabe verwendet. In ARIS ist

eine Funktion definiert als eine Verrichtung, die zur Erfüllung einer oder mehrerer Ziele an

einem Informationsobjekt (z.B. Auftrag, Kunde, Rechnung) durchgeführt wird.215 Die Ziele

können netzartig untereinander verflochten sein (n:m-Beziehung). Ein Ziel kann in mehrere

detailliertere (Teil-)Ziele zerlegt werden oder auch mehreren abstrakteren Zielen zugeordnet

sein. Ebenso wie die Ziele können auch die Funktionen auf unterschiedlichen Aggregati-

onsstufen beschrieben werden. Komplexe Funktionsbündel auf der obersten Aggregationsstu-

fe können mit Hilfe von Hierarchiediagrammen in Teilfunktionen gegliedert werden.

Für die Modellierung einer geschäftsprozessorientierten Organisation wird in ARIS eine

Gliederung der Funktionen entsprechend den Geschäftsprozessen vorgeschlagen, während für

eine spätere Systementwicklung eine verrichtungsorientierte Gliederung bevorzugt wird.216

Im Metamodell der Funktionssicht werden beide Gliederungsarten der Funktionen abgebildet.

Der Objekttyp „AFunktion“ (allgemeine Funktion) mit rekursiver Beziehung beschreibt Tä-

tigkeiten unabhängig von Gliederungszusammenhängen, so dass jede Funktion nur einmal

erfasst werden muss.

Abbildung 17 zeigt die wesentlichen Metamodellobjekte der Funktionssicht. Ein Geschäfts-

prozess unterstützt die Erreichung bestimmter Unternehmensziele. Er kann in Unter- oder

214 In Anlehnung an Leist (2004), S. 159.

215 Vgl. Scheer (2001), S. 22.

216 Vgl. Scheer (2001), S. 26.


Teilprozesse zerlegt werden. Dabei können Teilprozesse in mehreren übergeordneten Prozes-

sen vorkommen. Funktionen werden Geschäftsprozessen zugeordnet und unterstützen wie

diese die Erreichung bestimmter Ziele. Zur Charakterisierung, ob eine Funktion primär infor-

mationssystem-unterstützt oder manuell bearbeitet wird, werden die beiden Subklassen „Ma-

nuelle Funktion“ und „Systemfunktion“ differenziert.217 Der Systemfunktion wird ein ent-

sprechendes Anwendungssystem zugeordnet. Darüber hinaus können Funktionen danach dif-

ferenziert werden, ob sie primär einen material- oder informationsverarbeitenden Charakter

besitzen.

Abbildung 17: Metamodell der Funktionssicht218

Die Organisationssicht beschreibt die Aufbauorganisation, also die Organisationseinheiten

mit den zwischen ihnen bestehenden Kommunikations- und Weisungsbeziehungen.219 Ferner

wird mit dem Rollenkonzept das Anforderungsprofil einer Organisationseinheit definiert. Ab-

gebildet wird das Organigramm eines Unternehmens, indem gleichartige Aufgabenkomplexe

zu Organisationseinheiten zusammengefasst werden.220 Organisationseinheiten können eben-

so wie Funktionen nach verrichtungsorientierten, objektorientierten und prozessorientierten

Kriterien zerlegt werden. Bei einer prozessorientierten Gliederung wird das üblicherweise in

einer Baumstruktur abgebildete Organigramm in eine vernetzte Struktur überführt. Zudem

können Ausprägungen der Organisationseinheiten auf generischer Typebene (Unternehmens-

leitung, Hauptabteilung, Abteilung usw.), auf Typebene (Vertrieb, Abwicklung, Personal,

usw.) oder auf Instanzebene (Vertrieb Privatkunden, Filiale XY, usw.) dargestellt werden.221

217 Vgl. Scheer (2001), S. 34.

218 Vgl. Scheer (2001), S. 38.

219 Vgl. Scheer (2001), S. 52.

220 Vgl. Scheer (2001), S. 53.

221 Vgl. Scheer (2001), S. 53-54.


Organisationseinheiten können nach primär menschlichen und primär technischen Leistungs-

trägern differenziert werden. Maschinelle Leistungsträger können menschliche Leistungsträ-

ger bei der Ausführung der Aufgaben unterstützen. Des Weiteren wird eine Organisationsein-

heit durch den Objekttyp „Stelle“ spezialisiert. Eine Stelle bildet die kleinste Einheit einer

Organisationsstruktur. Ihr Aufgabenumfang wird so definiert, dass ein Mitarbeiter diesen be-

wältigen kann.222 Die geographische Verteilung von Organisationseinheiten wird durch die

Beziehung zum Objekttyp „Standort“ abgebildet.

Der Objekttyp „Organisationsstruktur“ definiert die Strukturbeziehungen zwischen Organisa-

tionseinheiten. Um unterschiedliche Typen von Organisationsstrukturen modellieren zu kön-

nen, wird der Objekttyp „Organisationstyp“ dem Metamodell hinzugefügt (beispielsweise zur

Differenzierung von fachlicher und disziplinarischer Weisungsbefugnis).

Neben den Organisationseinheiten werden auch Mitarbeitertypen mit einer definierten Quali-

fikation und Kompetenz betrachtet, die unter dem Begriff Rolle zusammengefasst werden.223

Die Klasse „Qualifikation“ erfasst die Qualifikationskriterien, die einer Rolle zugeordnet

werden können. Aus Sicht der Stelle können Anforderungen an die Qualifikation gestellt wer-

den. Den Stellen können dann bestimmte Rollen entsprechend der Übereinstimmung der Qua-

lifikations- und Anforderungskriterien zugeordnet werden. Die Klasse „Rolle“ wird weiter

spezialisiert durch die Klasse „Benutzerklasse“. Diese kann beispielsweise für die Definition

von unterschiedlichen Berechtigungen bei der Nutzung von Anwendungssystemen verwendet

werden. Die folgende Abbildung 18 zeigt die zuvor beschriebenen Klassen der Organisations-

sicht und deren Beziehungen.

Abbildung 18: Metamodell der Organisationssicht224

222 Vgl. Scheer (2001), S. 57.

223 Vgl. Scheer (2001), S. 57.

224 Vgl. Scheer (2001), S. 56.


Die Datensicht beschreibt die Datenobjekte, die von Funktionen manipuliert werden. Diese

Datenobjekte können als Grundlage für die Definition von Klassen einer objektorientierten

Modellierungsmethode, wie z.B. UML, verwendet werden. Überschneidungen mit der Leis-

tungssicht kann es bei Datenobjekten geben, die als Informationsdienstleistungen an nachfol-

gende Organisationseinheiten weitergegeben werden.225 Bei der Datensicht wird eine Makro-

und Mikrosicht unterschieden. Die Makrosicht beschreibt Daten auf abstrakter Ebene, die in

feinere Daten zerlegt werden können, z.B. in ER-Diagramme. Aus Gründen der Anschaulich-

keit werden die aggregierten Datenobjekte der Makrosicht für die Modellierung der in einem

Geschäftsprozess benötigten Daten verwendet. Der Begriff Makro-Datenobjekt umfasst alle

Datensammlungen der Makrosicht. Er wird durch zahlreiche Subtypen (z.B. Voice, Brief,

Nachricht, Video, Akte Datencluster und Datenmodell) spezialisiert. Diese können unterein-

ander in Beziehung stehen. Zudem können Makro-Datenobjekte in elektronisch-

alphanumerischer Form oder elektronisch als Sound, Bitmap sowie konventionell auf Papier

erfasst werden.226 Elektronisch gespeicherte Datenobjekte können Anwendungssystemen zu-

geordnet werden, die sie speichern oder manipulieren.227

Abbildung 19: Metamodell der Datensicht (Makro)228

Die Mikrosicht zerlegt die Makro-Datenobjekte in kleinere Einheiten. In der Regel werden für

die Modellierung der detaillierten Datenstruktur eines fachlichen Anwendungsbereichs ob-

jektorientierte Klassendiagramme, z.B. UML-Klassendiagramme229, oder ER-Diagramme230

225 Vgl. Scheer (2001), S. 67.

226 Vgl. Scheer (2001), S. 70.

227 Vgl. Scheer (2001), S. 70.

228 Vgl. Scheer (2001), S. 69.

229 Für eine Darstellung des Metamodells von UML-Klassendiagrammen vgl. z.B. OMG (2003b).

230 Für eine Darstellung des Metamodells von ER-Diagrammen vgl. z.B. Chen (1976) und Scheer (2001),

S. 72.


verwendet. Zu den Objekten des einfachen ER-Diagramms gehören der Entitytyp, das Attri-

but sowie der Beziehungstyp. Das erweiterte ER-Diagramm ermöglicht zudem die Modellie-

rung von Kardinalitäten sowie Spezialisierungs- und Generalisierungsbeziehungen.

Geschäftsprozesse erzeugen und verwenden Leistungen. Durch diese enge Beziehung hat die

Granularität der Leistungsdefinition Einfluss auf die Granularität der Prozessbeschreibung.

Die Modellierung der Leistungssicht nimmt daher innerhalb der Prozessbeschreibung eine

Kernfunktion ein. Der Begriff Leistung wird mit dem Begriff Produkt gleichgesetzt.231 Das

Metamodell der Leistungssicht teilt den generellen Leistungs- bzw. Produktbegriff in Sach-

und Dienstleistungen auf (vgl. Abbildung 20). Dienstleistungen werden weiter differenziert

nach Informations- und sonstige Dienstleistungen. Für die Modellierung der Leistungssicht

werden Produktbäume mit Kompositionsbeziehung „besteht aus“ verwendet. Die Leistungen

werden mit den zu ihrer Erstellung benötigten Kosten bewertet.

Abbildung 20: Metamodell der Leistungssicht232

Die Steuerungssicht bildet das Bindeglied zwischen den zunächst getrennt voneinander mo-

dellierten Sichten (Funktion, Organisation, Daten und Leistung).233 Die Steuerungssicht be-

steht somit aus sechs weiteren Teilsichten, die die bilateralen Beziehungen zwischen den

Sichten darstellen. Für jede dieser Teilsichten existieren Metamodelle, die unterschiedliche

Beziehungen zwischen den Objekttypen der Sichten definieren. Da nach SCHEER insbesonde-

re das Prozessmodell für die Integration der unterschiedlichen Teilsichten von Bedeutung ist,

wird in dieser Arbeit das Metamodell zur Beschreibung der Modellierungssprache der eEPK

vorgestellt.234 Das von SCHEER entwickelte Metamodell der EPK weist laut LEIST allerdings

einige Mängel auf.235 Deshalb wird in dieser Arbeit, wie bei LEIST, das von ROSEMANN ent-

wickelte Metamodell zur Beschreibung der EPK verwendet, das die Beziehungen zwischen

231 Vgl. Scheer (2001), S. 93.

232 Vgl. Scheer (2001), S. 97.

233 Vgl. Scheer (2001), S. 102.

234 Vgl. Scheer (2001), S. 102ff. und Scheer/Thomas (2005).

235 Vgl. Leist (2004), S. 172.


Funktion, Ereignis und Operator der EPK anders wiedergibt (vgl. Abbildung 21).236 Diese

drei Objekttypen sind Teile eines Geschäftsprozesses. Um Vorgänger- und Nachfolgerbezie-

hungen darstellen zu können, ist jedes dieser Elemente zweifach mit den anderen Elementen

verbunden. Der Objekttyp Operator wird differenziert nach „UND“, „ODER“ und „XOR“.

Zur Darstellung der Gesamtsicht werden Elemente der Daten- (z.B. Umfelddatum, Nach-

richt), Organisations- (z.B. Organisationseinheit und menschliche Arbeitsleistung), Funkti-

ons- (z.B. Funktion) und Leistungssicht (z.B. Leistung) in das Metamodell integriert.

Abbildung 21: Metamodell der Steuerungssicht237

3.2.1.3 Weitere strukturelle Bestandteile

ARIS beinhaltet kein striktes Vorgehensmodell, das festlegt, in welcher Reihenfolge die ein-

zelnen Sichten zu modellieren sind. Es bietet aber ein Phasenmodell, das für jede Sicht durch-

laufen wird und festlegt, wie Geschäftsprozesse ausgehend vom Fachkonzept bis zu ihrer in-

formationstechnischen Implementierung modelliert werden können. Das Phasenmodell be-

steht aus den Phasen Fachkonzept, DV-Konzept und Implementierung. Zuerst wird das Fach-

konzept entwickelt, anschliessend folgt die Gestaltung des DV-Konzepts und zuletzt wird das

DV-Konzept implementiert. Je Ebene des Phasenmodells können dabei die einzelnen Sichten

in beliebiger Reihenfolge oder auch parallel modelliert werden.

In ARIS kommen für die Modellierung der einzelnen Sichten verschiedene Techniken zum

Einsatz, wie beispielsweise ER-Diagramme, UML-Klassendiagramme, USE-CASE-

Spezifikationen und EPKs (Ereignisgesteuerte Prozesskette). Zudem werden oftmals einfache

236 Vgl. dazu Rosemann (1996).

237 Vgl. Rosemann (1996), S. 122-123.


Beschreibungstechniken, wie Tabellen, Matrizen und Netz- bzw. Baumstrukturen, eingesetzt,

um die Instanzen von Objekttypen (z.B. Funktionen und Ziele) einer Sicht auf unterschiedli-

che Weise einander gegenüberzustellen.

Für jede Sicht werden in ARIS Ergebnisdokumente vorgeschlagen, denen ein gemeinsames

Metamodell zugrunde liegt, welches die Konsistenz zwischen den Dokumenten gewährleistet.

Die Ergebnisdokumente sind unabhängig voneinander, d.h. keines der Dokumente wird als

Input für die Erstellung eines anderen Dokumentes benötigt. Das wichtigste Dokument stellt

das EPK-Diagramm dar, da es Objekte aus anderen Sichten beinhaltet und die verschiedenen

Sichten dadurch miteinander verbindet.

3.2.1.4 Inhaltliche Charakterisierung

Der Fokus von ARIS liegt stark auf der Modellierung der Geschäftsprozesse (fünf Sichten)

und deren informationstechnischer Implementierung. Die Abbildung der strategischen Aus-

richtung eines Unternehmens wird dagegen nicht unterstützt. Das Kriterium der Ganzheitlich-

keit wird von ARIS somit nicht erfüllt.

Jede Sicht auf den Geschäftsprozess wird durch ein zugrunde liegendes Metamodell beschrie-

ben. Sechs weitere Teilsichten definieren die bilateralen Beziehungen zwischen ausgewählten

Sichten bei der Modellierung der Steuerungssicht. Die Strukturierung und Komplexitätsre-

duktion sowie die Konsistenz zwischen den unterschiedlichen Sichten ist folglich gegeben.

ARIS verwendet für die Darstellung von Geschäftsprozessen und Organisationsstrukturen

vertraute Sprachkonzepte, wodurch die Anschaulichkeit und Verständlichkeit der Modelle

gesteigert wird. Dies ist auch darauf zurückzuführen, dass ARIS in der Praxis weit verbreitet

ist und dessen Konzepte oftmals bereits bekannt und etabliert sind.

Bezogen auf den Modellierungszweck der Geschäftsprozessmodellierung stellt ARIS die er-

forderlichen Aspekte des abzubildenden Sachverhaltes mit einem hohen Detaillierungs- und

Formalisierungsgrad dar. Allerdings ist gerade bei der Modellierung strategischer Aspekte die

Detaillierung sehr gering. So werden beispielsweise wichtige Produkt- und Leistungsgruppen

des Unternehmens lediglich von dem Metaentitätstyp „Leistungsfeld“ in sehr aggregierter

Form abgebildet. Hier wäre eine detailliertere Abbildung, auch im Hinblick auf die anschlies-

sende Prozessmodellierung, angebracht.

Die Anpassbarkeit und Erweiterbarkeit der von ARIS verwendeten Modellierungssprachen ist

eher gering, da diese sehr anwendungsspezifisch definiert sind.

Die von ARIS definierten Sichten auf den Geschäftsprozess werden alle anhand eines

zugrunde liegenden Metamodells (semi-)formal spezifiziert. Für die Beschreibung der einzel-

nen Metamodelle werden Klassendiagramme nach der Unified Modeling Language (UML)-

Notation verwendet. Das Kriterium der Formalisierung wird somit von ARIS erfüllt.


3.2.2 Multi-Perspective Enterprise Modeling (MEMO)


MEMO ist eine Methode zur multiperspektivischen Unternehmensmodellierung.238 Die Me-

thode bietet einen Bezugsrahmen, der die Strukturierung eines Unternehmens bzw. einer Or-

ganisation auf einem hohen Abstraktionsniveau ermöglicht. Sie ist nicht allein auf die Ent-

wicklung des Informationssystems gerichtet, sondern bezieht auch strategische und organisa-

torische Aspekte in die Betrachtung ein. Dadurch soll eine wechselseitige Abstimmung des

Informationssystems mit der Gestaltung von Geschäftsprozessen und der Unternehmensstra-

tegie gefördert werden.239

Ziel von MEMO ist es, methodische Unterstützung bei der Modellierung verschiedener Sich-

ten auf ein Unternehmen zu leisten, indem es den Entwurf unterschiedlicher Unternehmens-

modelle anleitet. Bei der Wahl der Sichten wurden sowohl betriebswirtschaftliche als auch

softwaretechnische Sichtweisen berücksichtigt. Der Bezugsrahmen der Methode unterscheidet

drei Gestaltungsebenen: Die Ebene der Strategie repräsentiert die Perspektive der Unterneh-

mensführung. Die Perspektive der Organisation wird auf der zweiten Ebene durch Modelle

der Aufbau- und Ablauforganisation dargestellt. Die dritte Ebene wird aus der Perspektive der

Informationssysteme konzeptualisiert.

Diese drei Ebenen werden jeweils durch die Sichten „Ressource“, „Struktur“, „Prozess“ und

„Ziel“ differenziert. Dadurch entsteht eine Matrix mit zwölf Zellen, die unterschiedliche Un-

ternehmensmodelle und Modellierungssprachen beinhalten. Geschäftsprozesse können bei-

spielsweise innerhalb der Gestaltungsebene „Organisation“ aus der Sicht „Prozess“ mit der in

MEMO enthaltenen Modellierungssprache „OrgML“ modelliert werden. Die unterschiedli-

chen Modellierungssprachen sind Bestandteile einer Spracharchitektur. Die Metamodelle der

Modellierungssprachen für die unterschiedlichen Ebenen und Sichten (z.B. MEMO-OML für

Objektmodelle240) werden durch eine einheitliche Beschreibungsform, basierend auf einem

gemeinsamen Meta-Metamodell sowie gemeinsamen Konzepten, dargestellt.241 Dadurch ist es

möglich, Beziehungen zwischen Elementen unterschiedlicher Ebenen abzubilden. Zusätzlich

zu den Unternehmensmodellen und Modellierungssprachen bietet MEMO ein Vorgehensmo-

dell, das aus einem zyklischen Phasenmodell besteht, dessen Phasen strukturiert beschrieben

sind.

238 Vgl. im Folgenden Frank (1994), Frank (1995), Frank (1998b), Frank (1999a), Frank (1999b) und

Frank (2002). 239

Vgl. Frank (1995), S. 46. 240

Vgl. Frank (1998b). 241

Vgl. Frank (1998a).


Abbildung 22: Multi-Perspective Enterprise Modeling (MEMO)242

3.2.2.2 Metamodelle von MEMO

MEMO-SML (Strategy Modeling Language) dient der Erstellung von Modellen, die die Zie-

le und die Geschäftsstrategie eines Unternehmens beschreiben. Die Sprache beinhaltet vier

wesentliche Konzepte.243 Rollen beschreiben wichtige Akteure im Geschäftsnetzwerk, wie

z.B. Kunden, Zulieferer und Wettbewerber. Diese Klassen repräsentieren keine einzelnen

Instanzen, sondern eine Menge von Instanzen. Das gleiche gilt für Ressourcen, wie finanzielle

Ressourcen, Mitarbeiter, Technologie etc. Märkte dienen der strategischen Planung. Dafür

bietet MEMO-SML beispielsweise die Klassen Markt, Teilmarkt, Segment, etc. Um den Mo-

dellierer bei der Strukturierung und Analyse der Unternehmensstrategie zu unterstützen, bietet

die Sprache Konzepte wie z.B. Aktivität, Aktivitätsgruppe, Wertschöpfungskette, Allgemeine

Strategie etc. Einige Klassen bzw. Konzepte stehen in Verbindung mit Klassen aus anderen

Modellierungssprachen. So ist beispielsweise die Klasse Geschäftseinheit mit der Klasse Or-

ganisationseinheit der MEMO-OrgML assoziiert. Da die Spezifikation von MEMO-SML und

deren Notation strikt voneinander getrennt sind, können beliebige graphische Repräsentatio-

nen verwendet werden. Abbildung 23 zeigt die wesentlichen Klassen (Konzepte bzw. Metaen-

titätstypen) der MEMO-SML sowie deren Beziehungen.

242 Vgl. Frank (2002), S. 3.

243 Vgl. im Folgenden Frank (2002), S. 3025-3027.


Abbildung 23: Metamodell der MEMO-SML (Strategy Modeling Language)244

Auf Grundlage der Unternehmensstrategie werden die wesentlichen Geschäftsprozesse sowie

die darauf abgestimmte Organisationsstruktur des Unternehmens entworfen. MEMO-OrgML

dient der Modellierung der organisatorischen Perspektive des Unternehmens.245 Die Sprache

bietet Konzepte bzw. Metaentitätstypen für die Abbildung von Geschäftsprozessen (z.B. Pro-

zesstyp, Komplexer Prozesstyp, Einfacher Prozesstyp), Organisationsstrukturen (z.B. Organi-

sationseinheit, Stelle, Aggregierte Einheit) und operativen Ressourcen (z.B. Faxgerät, Tele-

fon, Formular). Die wesentlichen Metaentitätstypen für die Prozessmodellierung in MEMO-

OrgML sind „Prozesstyp“, „Prozesseinsatz“, „Kontext Prozesseinsatz“, „Input-Spezifikation“,

„Output-Spezifikation“ und „Ereignistyp“ (vgl. Abbildung 24). Der abstrakte Metaentitätstyp

„Prozesstyp“ wird durch die beiden Metaentitätstypen „Komplexer Prozesstyp“ und „Einfa-

cher Prozesstyp“ spezialisiert. Eine Instanz von „Komplexer Prozesstyp“ kann aus mehreren

Instanzen von „Prozesstyp“ zusammengesetzt sein. Für die Unterscheidung zwischen ver-

schiedenen Erscheinungsformen einer Instanz von „Prozesstyp“ wurde der Metaentitätstyp

„Prozesseinsatz“ definiert.

Ein „Prozesstyp“ kann eine „Input-Spezifikation“ verwenden und eine oder mehrere „Output-

Spezifikationen“ erzeugen. Bei diesen Spezifikationen handelt es sich um Behälter (Contai-

ner) für Informationen, wie beispielsweise Formulare, Akten oder Objekte, die in einem asso-

ziierten Objektmodell abgebildet sind. Jeder „Output-Spezifikation“ kann für Simulations-

zwecke eine Wahrscheinlichkeit zugewiesen werden. Ereignisse werden für die Modellierung

des Kontrollflusses innerhalb eines Prozesses verwendet. Sie werden durch bestimmte Zu-

stände eines Prozesses ausgelöst. Die drei Basiskonstrukte für die Modellierung des Kontroll-

flusses sind sequentielle, alternative und parallele Teilprozesse sowie ein abgeleitetes Kon-

strukt für die Modellierung von Schleifen. Ausserdem können jedem Prozess Organisations-

244 Vgl. Frank (2002), S. 3028.

245 Vgl. im Folgenden Frank (1999b), S. 3028f.


einheiten und zusätzliche Ressourcen, wie beispielsweise Rollen, Applikationen und Kom-

munikationsgeräte, zugeordnet werden.

Abbildung 24: Metamodell der MEMO-OrgML246

Auf der Ebene der Informationssysteme dient MEMO-OML der Modellierung von statischen

Objektmodellen. Dabei handelt es sich um eine objektorientierte Modellierungssprache, deren

Konzepte durch Smalltalk inspiriert sind und die in diesem Bereich ähnlich zur UML ist.247

Im Unterschied zur UML ist in MEMO-OML die Semantik von Vererbung genau spezifiziert.

Zudem besitzt MEMO-OML das Konzept der Delegation. Dieses soll die Vorteile der Verer-

bung mit denen von Assoziationen kombinieren.248 Der Metaentitätstyp Klasse der MEMO-

OML wird ausserdem durch die Metaentitätstypen Attribut, Service, Guard und Trigger ge-

nauer definiert (vgl. Abbildung 25).

246 Vgl. Frank (2002), S. 3028.

247 Vgl. Frank (1999b), S. 162.

248 Vgl. Frank (2002), S. 3027.


Abbildung 25: Metamodell der MEMO-OML249


MEMO umfasst ein zyklisches Phasenmodell, dessen Phasen strukturiert beschrieben sind

und durch Heuristiken unterstützt werden.250 Es wurde allerdings keine veröffentlichte Quelle

gefunden, in der dieses Phasenmodell detailliert beschrieben ist. In den vorhandenen Quellen

wird lediglich darauf hingewiesen, dass bei der Anwendung der Methode in der Regel ein

Top-Down-Ansatz verfolgt wird.

MEMO bietet für die Modellierung der unterschiedlichen Perspektiven und Sichten die Mo-

dellierungssprachen MEMO-SML, MEMO-OrgML und MEMO-OML an. Eine detaillierte

Handlungsanleitung für die Anwendung dieser Modellierungssprachen liegt allerdings nur für

MEMO-OML vor.251 Somit sind insbesondere für die Organisations- und Strategieebene kei-

ne Techniken spezifiziert.

Die mit den Modellierungssprachen der MEMO-Methode erstellten Diagramme können als

Ergebnis der Modellierung betrachtet werden. Es werden somit auf allen Ebenen strukturierte

Ergebnisdokumente erzeugt, deren Zusammenhänge ansatzweise im Metamodell der Model-

lierungssprachen festgelegt sind.


MEMO unterteilt das Unternehmen in drei Architekturebenen und definiert unterschiedliche

Sichten. Diese decken allerdings nicht alle wesentlichen Elemente der Unternehmensarchitek-

249 Vgl. Frank (2002), S. 3028.

250 Vgl. hierzu die Beschreibung von MEMO auf der Internetseite des Instituts für Informatik und

Wirtschaftsinformatik der Universität Duisburg-Essen (http://www.wi-inf.uni-duisburg-essen.de). 251

Vgl. Frank (1999a).


tur ab.252 Zudem werden nicht für alle Sichten entsprechende Modellierungssprachen und

Metamodelle definiert. Auf Organisationsebene dient beispielsweise die Sprache MEMO-

OrgML für die Abbildung der Aufbau- und Ablauforganisation. Metaentitätstypen für die

Abbildung von operativen Zielen und Erfolgsfaktoren sind in dieser Sprache allerdings nicht

enthalten. Ausserdem erlaubt die Matrixstruktur des verwendeten Bezugsrahmens der

MEMO-Methode keine flexible Definition von unterschiedlichen Sichten auf den einzelnen

Ebenen. Für jede Ebene sind die gleichen Sichten festgelegt. Das Kriterium der Ganzheitlich-

keit wird daher von der MEMO-Methode nicht vollständig erfüllt.

Den in MEMO verwendeten Modellierungssprachen liegen Metamodelle zugrunde, die mit-

einander über gemeinsame Metaentitätstypen verknüpft sind. Zudem existieren für die unter-

schiedlichen Sprachen gemeinsame Konzepte in Form einer Spracharchitektur und eines Me-

ta-Metamodells. Dadurch kann die Konsistenz zwischen den erstellten Modellen gewährleis-

tet werden.

In Bezug auf die Erfüllung des Kriteriums der Angemessenheit bietet MEMO beispielsweise

unterschiedliche Diagrammarten zur Darstellung von Prozessen. Ein Dekompositionsdia-

gramm dient der Darstellung der Kompositionshierarchie von Prozessen. Ein Generalisie-

rungsdiagramm zeigt die Generalisierungsbeziehungen zwischen Prozesstypen. Das Prozess-

diagramm erlaubt die detaillierte Beschreibung eines Prozesses. Dadurch ist eine Modellie-

rung der Prozesse mit unterschiedlichen Detaillierungsgraden möglich. Zudem bietet MEMO

eine vereinfachte Version der graphischen Notation für Prozesse an. Die anderen Modellie-

rungssprachen werden im Hinblick auf unterschiedliche Ansprüche an die Detaillierung nicht

weiter spezifiziert.

Die einzelnen Modellierungssprachen der MEMO-Methode werden formal durch ein zugrun-

de liegendes Metamodell definiert. Das Metamodell der Sprache MEMO-OML ist zudem in

eine Modellierungstechnik eingebunden, d.h. die Ergebnisdokumente werden durch eine vor-

gegebene Sprache und eine Handlungsanleitung erstellt. Darüber hinaus liegen den verwende-

ten Modellierungssprachen gemeinsame Konzepte sowie ein einheitliches Meta-Metamodell

zugrunde. Dadurch wird die Integration der mit unterschiedlichen Perspektiven korrespondie-

renden Modelle gefördert und die Erweiterung um weitere Modellierungssprachen im Zeitab-

lauf ermöglicht.

Die Anforderung der Verständlichkeit der verwendeten Notationen ist bei MEMO weitgehend

erfüllt, da diese die bekannten Symbole der jeweiligen Domäne umfassen. So wird die Orga-

nisationsstruktur beispielsweise mit Hilfe von Organigrammen dargestellt, und gewisse As-

pekte der Unternehmensstrategie werden als Wertschöpfungsketten visualisiert. Zudem kön-

252 Vgl. hierzu z.B. die in Winter/Fischer (2006) als wesentlich identifizierten Elemente einer

Unternehmensarchitektur.


nen in dem unterstützenden Software-Werkzeug (MEMO-Center) die graphischen Symbole

modifiziert werden, um eine flexible Anpassung an individuelle Präferenzen zu ermöglichen.

Die in MEMO enthaltende Architektur für die Spezifikation von Sprachen zur Unterneh-

mensmodellierung sieht eine gegebenenfalls im Zeitverlauf wachsende Zahl von Modellie-

rungssprachen vor, deren Integration durch die Verwendung eines einheitlichen Meta-

Metamodells sowie gemeinsamer Konzepte erfolgt. Ausserdem ist, wie bereits zuvor genannt,

eine Modifikation der graphischen Symbole möglich. Die Flexibilität von MEMO ist aller-

dings durch die Matrixstruktur des Bezugsrahmens und damit durch die für alle Ebenen (Per-

spektiven) fest vorgegebenen Sichten eingeschränkt. Das Kriterium der Flexibilität ist deshalb

nur teilweise erfüllt.

3.2.3 Semantisches Objektmodell (SOM)


SOM wurde mit dem Ziel der geschäftsorientierten Gestaltung von Informationssystemen

entwickelt.253 Dies soll durch ein dreistufiges Top-Down-Vorgehen erreicht werden. Die Er-

gebnisse der Modellierung einer Ebene gelten als Anforderungen für die jeweils nachfolgende

Ebene. Die Modellierungsebenen beschreiben nicht nur eine Vorgehensweise, die schrittweise

durchzuführen ist, sondern repräsentieren auch die unterschiedlichen Abstraktionsschichten

und die betriebswirtschaftlichen Zusammenhänge in einem Unternehmen. SOM unterscheidet

drei aufeinander aufbauende Modellierungsebenen (vgl. Abbildung 26):

Unter-

nehmensplan

Geschäftsprozesse

AufbauorganisationAnwendungs-

systemarchitektur

Ressourcen

Abbildung 26: SOM-Ebenen254

Der Unternehmensplan ist das Ergebnis einer Analyse exogener (Chancen und Risiken) und

endogener Erfolgsfaktoren (Stärken und Schwächen). Sie orientiert sich am Erfolg der aktuel-

253 Vgl. im Folgenden Ferstl/Sinz (1998), S. 1041, Ferstl/Sinz (1995) und Ferstl/Sinz (2001).

254 Vgl. Ferstl/Sinz (1995), S. 12.


len und potentiellen Geschäfte des Unternehmens. Dabei werden Wertschöpfungsketten fest-

gelegt sowie Ziele konkretisiert. Die Beschreibung der Analyse und deren Ergebnisse erfolgt

auf dieser ersten Ebene in der Regel in textueller Form.

Der Unternehmensplan wird auf der zweiten Ebene durch Geschäftsprozessmodelle umge-

setzt. Diese sind durch Leistungsbeziehungen miteinander verbunden. Die Geschäftsprozesse

werden hierarchisch in Form von semi-formalen Diagrammen modelliert.

Um die Geschäftsprozesse umsetzen bzw. unterstützen zu können, werden entsprechende

Ressourcen, wie z.B. Anwendungssysteme, Personal und Anlagen, benötigt. Die jeweiligen

Zusammenhänge werden durch eine Aufbauorganisation, eine Anwendungssystem-

Architektur und eine Anlagen-Architektur dargestellt.

Auf allen Gestaltungsebenen werden verschiedene Sichten unterschieden. Der Unterneh-

mensplan wird in die Sichten Objektsystem und Zielsystem unterteilt. Das Objektsystem be-

schreibt das Unternehmen sowie dessen Beziehungen zur Umwelt. Das Zielsystem legt die

Unternehmensziele sowie Restriktionen und Rahmenbedingungen fest.255 Die Geschäftspro-

zessebene unterscheidet die Sichten Interaktionsschema (IAS) und Vorgangs-Ereignis-

Schema (VES). Das IAS beschreibt das Unternehmen anhand von Objekten (z.B. Kunden,

Lieferanten, Produkte) sowie deren Beziehungen untereinander. Das VES besteht aus einer

Folge von Aufgabenzerlegungen, die als Petri-Netze dargestellt werden.

Auf Ebene der Ressourcen wird für den Ressourcentyp Anwendungssystem zwischen einem

konzeptuellen Objektschema (KOS) und einem Vorgangsobjektschema (VOS) differen-

ziert.256 Das KOS stellt eine objektorientierte Erweiterung eines konzeptuellen Datenmodells

dar. Es wird auf der Grundlage der in den IAS und VES definierten Objekttypen und deren

Beziehungen modelliert. Das VOS beschreibt darauf aufbauend das Zusammenwirken kon-

zeptueller Objekttypen bei der Durchführung betrieblicher Aufgaben.257

3.2.3.2 Metamodelle der SOM-Methode

Für den Unternehmensplan definiert die SOM-Methode kein Metamodell. Das Objekt- und

Zielsystem des Unternehmensplans werden lediglich in natürlichsprachlichem Fliesstext be-

schrieben.258

Auf der Geschäftsprozessebene werden die Lösungsverfahren für die Realisierung des Unter-

nehmensplans realisiert.259 Die Geschäftsprozesse werden in Abgrenzung zur dritten Ebene

255 Vgl. Ferstl/Sinz (2001), S. 183.

256 Vgl. Ferstl/Sinz (1998), S. 179ff.

257 Vgl. Ferstl/Sinz (2001), S. 184.

258 Vgl. Ferstl/Sinz (2001), S. 185.

259 Vgl. Ferstl/Sinz (1998), S. 178.


ohne explizite Betrachtung von Aufgabenträgern gestaltet, um mögliche Freiheitsgrade bei

der Zuordnung zwischen Aufgaben und Aufgabenträgern ermitteln und nutzen zu können.260

Die Geschäftsprozessebene wird in zwei unterschiedliche Sichten eingeteilt. Betriebliche Ob-

jekte und deren Transaktionen werden in einem IAS abgebildet.261 Dieses stellt die betriebli-

chen Objekte (Umwelt- und Diskursweltobjekte) sowie deren Transaktionen (Anbahnungs-,

Vereinbarungs-, Durchführungs-, Steuer- und Regelungstransaktionen) dar. Zusätzlich wird

der durch Ereignisse gesteuerte Ablauf des Geschäftsprozesses in Form eines VES modelliert.

Das VES bildet Aufgaben und Ereignisse sowie deren Beziehungen zu Transaktionen und

Objekten ab. Dabei wird festgelegt, dass zwei Aufgaben, die den jeweiligen Objekten zuge-

ordnet sind, eine Transaktion durchführen.262

Sowohl für das IAS als auch für das VES definiert die SOM-Methode ein Metamodell.

Abbildung 27 zeigt das von LEIST ergänzte Metamodell der Geschäftsprozessebene.

Nach Festlegung des Unternehmensplans werden aus Umwelt und Diskurswelt auf der Ge-

schäftsprozessebene betriebliche Objekte (beispielsweise Organisationseinheiten oder Aufga-

benträger) abgeleitet. Ein betriebliches Objekt umfasst eine Menge von Aufgaben, die zu-

sammengehörende Sach- und Formalziele verfolgen und die auf einem gemeinsamen Aufga-

benobjekt (z.B. Information, materielle Güter, Energie, Zahlungen) durchgeführt werden.263

Objekte sind hierarchisch zerlegbar und Komponenten eines Lenkungs- oder Leistungssys-

tems.264

Der Transfer von Leistungspaketen und der Austausch von entsprechenden Nachrichten zwi-

schen zwei Objekten werden durch die Klasse Transaktion modelliert.265 Leistungspakete sind

beispielsweise Güter, Dienstleistungen oder Zahlungen, die als einzelne Pakete abgrenzbar

sind oder durch den Bezug auf eine Zeitperiode abgegrenzt werden können.266 Der Austausch

von Nachrichten koordiniert den Transfer der Leistungspakete.267 Leistungspakete sind Be-

standteile der Leistung.268 Mit Hilfe von Transaktionen, Nachrichten und Leistungspaketen

können die Leistungs- und Lenkungssicht der betrieblichen Aufgaben dargestellt werden.

Aufgaben werden in einer Innensicht und einer Aussensicht beschrieben. Die Aussensicht

definiert das Aufgabenobjekt, d.h. den Gegenstand der Aufgabe, die Ziele der Aufgabe (Sach-

und Formalziele), die Vorereignisse, die eine Aufgabendurchführung auslösen, und die Nach-

260 Vgl. Schlitt (2003), S. 184.

261 Vgl. Ferstl/Sinz (2001), S. 186.

262 Vgl. Ferstl/Sinz (2001), S. 199.

263 Vgl. Ferstl/Sinz (2001), S. 188.



266 Vgl. Leist (2004), S. 227.

267 Vgl. Ferstl/Sinz (2001), S. 60-61.

268 Vgl. Ferstl/Sinz (2001), S. 188-189.


ereignisse, die aus einer Aufgabendurchführung resultieren.269 Ereignisse können auch danach

differenziert werden, ob sie Beziehungen zwischen Aufgaben eines betrieblichen Objekts her-

stellen (objektinterne Ereignisse, repräsentiert durch den Objekttyp „O-Ereignis“) oder ob-

jektextern entstehen (Umweltereignisse, repräsentiert durch den Objekttyp „U-Ereignis“), wie

beispielsweise das Eintreten eines bestimmten Zeitpunkts (z.B. der erste Tag eines Mo-

nats).270

Abbildung 27: Metamodell der Geschäftsprozessebene271

Die Innensicht der Aufgabe legt dagegen das Lösungsverfahren (den Verrichtungsvorgang)

und den Aufgabenträgertyp (z.B. Mitarbeiter oder Rechner) der Aufgabe fest.272 Aufgaben

werden weiter differenziert nach Transformations- und Entscheidungsaufgaben. Geben die

Zielsetzungen einer Aufgabe eindeutig an, welcher Nachzustand mit der Aufgabendurchfüh-

rung erreicht wird, dann liegt eine Transformationsaufgabe vor. Andernfalls wird von einer

Entscheidungsaufgabe gesprochen.273


270 Vgl. Ferstl/Sinz (2001), S. 199.

271 Vgl. Leist (2004), S. 232.


273 Vgl. Ferstl/Sinz (2001), S. 188.


Um die Ergebnisse, die auf der Geschäftsprozessebene entwickelt wurden, auch umsetzen zu

können, werden auf der dritten Ebene entsprechende Ressourcen benötigt. In Abhängigkeit

von den Festlegungen der ersten beiden Ebenen sind hier die Aufgabenträger für die Unter-

nehmensaufgabe zu spezifizieren.274 Aufgabenträger sind Ressourcen, zu denen Personal,

Anwendungssysteme sowie Maschinen und Anlagen zählen.275 Die SOM-Methode be-

schränkt sich auf die Gestaltung der Anwendungssysteme, da diese eine wesentliche Ressour-

ce zur Durchführung der Geschäftsprozesse darstellen. Ein gut detailliertes Geschäftspro-

zessmodell bildet die Grundlage für die fachliche Spezifikation einzelner Anwendungssyste-

me und ihrer Integrationsbeziehungen innerhalb der Gesamtarchitektur aller Anwendungssys-

teme.276 Für die fachliche Spezifikation von Anwendungssystemen werden die beiden Sichten

konzeptuelles Objektschema und Vorgangsobjektschema unterschieden (vgl. Abbildung 28).

Diese dienen als Grundlage für den systemtechnischen Entwurf und die Implementierung der

Anwendungssysteme.277

Abbildung 28: Metamodell der Anwendungssystemebene278

Ein konzeptueller Objekttyp wird durch seinen Namen, eine Menge von Attributen, eine

Menge von Nachrichtendefinitionen sowie eine Menge von Operatoren (Methoden) spezifi-

ziert. Mit Hilfe der Nachrichtendefinitionen wird festgelegt, welche Nachrichten die Instanzen

des Objekttyps verstehen.279 Vorgangsobjekttypen beschreiben das Zusammenwirken von

konzeptuellen Objekttypen bei der Durchführung einer betrieblichen Aufgabe. Sie werden

274 Vgl. Schlitt (2003), S. 184.

275 Vgl. Ferstl/Sinz (1998), S. 178.

276 Vgl. Ferstl/Sinz (1995), S. 212.

277 Vgl. Leist (2004), S. 232.

278 Vgl. Leist (2004), S. 237.

279 Vgl. Ferstl/Sinz (2001), S. 203.


ebenfalls durch einen Namen, Attribute, Nachrichtendefinitionen und Operatoren charakteri-

siert.280

Auf der Anwendungssystemebene werden lediglich automatisierbare Aufgaben und Transak-

tionen betrachtet. Folglich dient die Automatisierbarkeit als ein wichtiges Kriterium zur wei-

teren Verfeinerung der auf Geschäftsprozessebene erstellten Modelle. Eine Aufgabe wird als

automatisierbar betrachtet, wenn ein Lösungsverfahren angegeben werden kann, für das ein

Anwendungssystem zur Verfügung steht oder eines konstruierbar ist.281 Eine Transaktion ist

automatisierbar, wenn ein Kommunikationssystem die Nachrichtenübertragung und die Aus-

führung des Kommunikationsprotokolls durchführt.282

Für die Spezifikation neuer Anwendungssysteme wird zunächst ein KOS und darauf aufbau-

end ein VOS erstellt. Neben dem Kriterium der Automatisierbarkeit wird darüber hinaus der

betrachtete Ausschnitt aus IAS und VES anhand eines oder mehrerer betrieblicher Objekte

abgegrenzt, für die ein Anwendungssystem spezifiziert werden soll.283

Ein KOS umfasst die konzeptuellen Objekttypen, die weiter nach objektspezifischen, leis-

tungsspezifischen und transaktionsspezifischen Objekttypen differenziert werden können. Die

Objekttypen werden entsprechend aus Diskurs-/Umweltobjekten, Leistungsspezifikationen

und den Transaktionen des Geschäftsprozessmodells abgeleitet.


Neben den Metamodellen für die zuvor genannten Modellierungssprachen umfasst die SOM-

Methode auch ein Vorgehensmodell. Dieses beschreibt ein reines Top-Down-Vorgehen. Zu-

nächst wird die Unternehmensaufgabe in Form des Unternehmensplans spezifiziert. Auf der

Grundlage dieses Unternehmensplans werden relevante Objekte der Diskurswelt und Umwelt

sowie deren Leistungsbeziehungen identifiziert und in einem IAS abgebildet. Leistungsbezie-

hungen werden dabei durch Transaktionen repräsentiert. Anschliessend wird korrespondie-

rend zum IAS das VES erstellt, welches die Ablaufplanung eines Geschäftsprozesses darstellt.

Die beiden Modelle werden in Folge so weit verfeinert, bis der von der Modellierungszielset-

zung erreichte Detaillierungsgrad erreicht wurde. Vor der Spezifikation der Anwendungssys-

temebene wird der vorhandene und umzusetzende Automatisierungsgrad von Aufgaben und

Transaktionen festgestellt und ebenfalls in das IAS eingetragen. Aus dem IAS und VES wer-

den auf der Anwendungssystemebene konzeptuelle Objekttypen abgeleitet und in einem KOS

abgebildet. Dieses wird daraufhin sukzessive erweitert und verfeinert. Analog zum KOS wird

das VOS aus dem IAS und VES abgeleitet und daraufhin in mehreren Schritten verfeinert.

280 Vgl. Ferstl/Sinz (2001), S. 210.

281 Vgl. Ferstl/Sinz (2001), S. 200.

282 Vgl. Ferstl/Sinz (2001), S. 200.

283 Vgl. Ferstl/Sinz (2001), S. 206.


Das hier nur grob vorgestellte Vorgehen stellt einen idealtypischen Verlauf eines Projektes

dar. Es wird unterstellt, dass die Entwicklung des Unternehmensmodells unabhängig von der

aktuellen Situation ist und von Unternehmensplanebene über die Geschäftsprozessebene bis

zur Ressourcenebene völlig neu gestaltet werden kann („Grüne-Wiese-Ansatz“). Abhängig

von der Zielsetzung und den Rahmenbedingungen ist nach FERSTL/SINZ aber auch eine andere

Vorgehensweise möglich. Die einzelnen Modelle sollten aber immer von oben nach unten

aufeinander abgestimmt werden.284

Für die Durchführung der Aktivitäten des Vorgehensmodells können unterschiedliche Tech-

niken eingesetzt werden, wie beispielsweise die Modellierungssprachen IAS, VES, KOS und

VOS, sowie tabellarische Darstellungen, natürliche Sprache, formale Zerlegungsregeln und

Ableitungsregeln.285 Jedes Metamodell ist in eine Modellierungstechnik eingebunden, d.h. die

Ergebnisdokumente werden durch eine vorgegebene Sprache und eine Handlungsanleitung

erstellt.

Die Dokumente der SOM-Methode können als Ergebnis der Modellierung betrachtet werden.

Bis auf die Unternehmensplanebene werden auf allen Ebenen strukturierte Ergebnisdokumen-

te erzeugt.


SOM unterteilt das Unternehmen zwar in drei Architekturebenen und definiert für jede Ebene

unterschiedliche Sichten. Allerdings ist die Anzahl der Elemente und Sichten je Ebene für

einen umfassenden Ansatz, der alle Unternehmensbereiche abdecken soll, zu gering.286 Das

Kriterium der Ganzheitlichkeit wird von der SOM-Methode daher nur ansatzweise erreicht.

Die Konsistenz der Ergebnisse der Methode wird durch die Abstimmung der erstellten Mo-

delle in einem Top-Down-Ansatz gewährleistet. Die Ergebnisse einer Ebene sind im Kern als

Anforderungen zu verstehen, die in der jeweils folgenden Ebene zu konkretisieren sind.

Bezogen auf die Angemessenheit macht SOM keine Angaben zur Zerlegung und Verfeine-

rung der erstellten Modelle. Es wird lediglich darauf hingewiesen, dass der Detaillierungsgrad

auf die Modellierungszielsetzung auszurichten ist. Soll das Geschäftsprozessmodell bei-

spielsweise als Grundlage für die Entwicklung des Anwendungssystems verwendet werden,

so bedingt dies nach FERSTL/SINZ einen wesentlich höheren Detaillierungsgrad, als wenn nur

die Leistungsbeziehungen im Unternehmen erfasst werden sollen.287

284 Vgl. Ferstl/Sinz (2001), S. 184.

285 Vgl. Leist (2004), S. 248.

286 Vgl. hierzu die in Winter/Fischer (2006) als wesentlich identifizierten Elemente einer

Unternehmensarchitektur. 287

Vgl. Ferstl/Sinz (2001), S. 195.


Bis auf den Unternehmensplan werden die Modellierungssprachen der Methode formal durch

zugrunde liegende Metamodelle definiert. Für die Erstellung der Ergebnisdokumente sind

zudem Modellierungstechniken spezifiziert.

Die Modellierungssprachen der Methode besitzen eine klar definierte, aber anspruchsvolle

Syntax, die von dem Anwender bzw. Modellierer sicher eine längere Einarbeitungszeit erfor-

dert. Zudem entsprechen die verwendeten grafischen Symbole nicht direkt den Anwendungs-

bereichen. Eine deutliche Abbildung von Sprachkonzepten auf grafische Symbole ist dem-

nach nicht gegeben.

Das Kriterium der Flexibilität ist nur teilweise gegeben, da die Erweiterung der Modellie-

rungssprachen und der zugrunde liegenden Metamodelle um weitere Konzepte zwar möglich

ist, es allerdings einige Arbeit erfordern dürfte, die neuen Konzepte mit den eher proprietären,

der SOM-Methode sehr eigenen Sprachkonzepten in Beziehung zu setzen, um so die Konsis-

tenz zwischen den Modellen gewährleisten zu können.

3.3 Diskussion ausgewählter Bezugsrahmen aus der Praxis

Nach der Diskussion von Methoden zur Unternehmensmodellierung, die primär aus dem uni-

versitären Umfeld stammen, werden in diesem Abschnitt ausgewählte Bezugsrahmen aus der

Praxis vorgestellt. Im Unterschied zu den oben beschriebenen Methoden bieten diese Ansätze

lediglich einen Bezugsrahmen (Framework) für die Kategorisierung von unternehmensrele-

vanten Informationen anhand von unterschiedlichen Architekturebenen und Sichten. Eine

Ausnahme stellt TOGAF dar, welches auch ein detailliertes Vorgehensmodell zur Entwick-

lung der Architektur vorschreibt.

Zu den am häufigsten von den aktuell am Markt verfügbaren Werkzeugen unterstützten und

von Organisationen in der Praxis eingesetzten Bezugsrahmen gehören das Zachman Frame-

work, das Federal Enterprise Architecture Framework (FEAF) und The Open Group Architec-

ture Framework (TOGAF).288 Die ausgewählten Bezugsrahmen werden hinsichtlich der Ein-

teilung des Unternehmens in Gestaltungsebenen und Sichten beschrieben. Zudem erfolgt eine

inhaltliche Charakterisierung entsprechend der in Abschnitt 2.6.1 definierten Kriterien.

3.3.1 Das Zachman Framework

3.3.1.1 Überblick und Architekturebenen

Einer der ersten Ansätze zur Abbildung der Informationssystemarchitektur eines Unterneh-

mens wurde 1987 von John Zachman entwickelt und ist auch heute noch weit verbreitet.289

Viele der heute in Software-Werkzeugen standardmässig zur Verfügung gestellten Bezugs-

288 Vgl. z.B. James (2004b), James (2004a), IFEAD (2005) und Schekkerman (2004).

289 Vgl. im Folgenden Zachman (1987) und Zachman/Sowa (1992).


rahmen basieren auf dem Zachman Framework. Es stellt eine Klassifizierung von Konzepten

zur Verfügung, um Objekte der realen Welt mit den entsprechenden Repräsentationen in den

Informationssystemen zu verbinden.290 Es ermöglicht den Blick auf ein Informationssystem

aus mehreren Perspektiven und zeigt, wie diese miteinander in Beziehung stehen. Die erste

Version des Bezugsrahmens entwickelte Zachman in Analogie zur Architektur eines Hauses.

Anhand verschiedener Rollen („planner“, „owner“, „designer“, „builder“ und „subcontrac-

tor“) wird gezeigt, dass jeweils unterschiedliche Konzeptualisierungen des Hauses und seiner

Teile im Vordergrund stehen. Die mit den Rollen verbundenen Sichten differenziert er weiter

in drei Aspekte, die mit „Was", „Wie“ und „Wo“ bezeichnet werden. Die Übertragung dieser

Überlegungen auf betriebliche Informationssysteme führt zu einem Bezugsrahmen mit fünf

Sichten und drei Betrachtungsaspekten (vgl. Abbildung 29). Dabei schränken die Ergebnisse

einer Sicht jeweils die Modellierung der darunter liegenden Sichten ein. Jede der auf diese

Weise entstehenden fünfzehn Teilsichten wird mit einer bestimmten Repräsentationsform

assoziiert.

Das Zachman Framework besteht aus den folgenden fünf Sichten:

• Anwendungsbereich: Diese Sicht ist für den „Bauherrn“ oder „Investor“ gedacht. Sie gibt

einen Überblick über den Anwendungsbereich, die Kosten und den Funktionsumfang des

Systems.

Abbildung 29: Das Zachman Framework291

290 Vgl. Zachman/Sowa (1992), S. 590.

291 Vgl. Zachman/Sowa (1992), S. 593.


• Geschäftsmodell (fachkonzeptionell): Dieses Modell beschreibt, beschränkt auf die ein-

zelnen Teilsichten, die Geschäftsobjekte und -prozesse sowie deren Interaktion.

• Systemmodell (logisch): Das Systemmodell bildet die physische Verteilung eines Infor-

mationssystems ab und definiert die Datenobjekte und Funktionen, welche die Geschäfts-

objekte und -prozesse repräsentieren.

• Technologiemodell (physisch): Für die Umsetzung des Informationssystems muss festge-

legt werden, welche Programmiersprache, Hardware oder welche sonstigen Technologien

verwendet werden sollen.

• Komponenten: Detaillierte Spezifikationen werden an die Programmierer übergeben. Die-

se kodieren dann anhand der Spezifikationen individuelle Module, ohne den Gesamtzu-

sammenhang oder die Gesamtstruktur des Systems zu kennen.

Die ersten drei Spalten, welche bereits in der ersten Version des Zachman Framework292 be-

schrieben wurden, repräsentieren die Entitäten, Funktionen und Standorte eines Informations-

systems. In einer späteren Arbeit293 wurde das Framework um die Spalten Personen, Zeit und

Motivation bzw. Strategien erweitert. Innerhalb der 30 Zellen der resultierenden Matrix kön-

nen unterschiedliche Modellierungssprachen für die Beschreibung der entsprechenden Sicht

auf das Informationssystem verwendet werden.

3.3.1.2 Methodenbestandteile des Zachman Framework

Für jede Zelle der Matrix des Zachman Framework werden Ergebnisdokumente vorgeschla-

gen, wie beispielsweise Entity-Relationship-Diagramme für die Datenmodellierung oder

Flussdiagramme für die Prozessmodellierung der Geschäftsmodellsicht. Dadurch können die

unterschiedlichen Diagramme und Dokumente, die in einem Unternehmen verwendet werden

und die verschiedene Aspekte bzw. Sichten auf dieses Unternehmen repräsentieren, in das

Zachman Framework eingeordnet werden. Das Zachman Framework beinhaltet allerdings

kein Metamodell, welches die Konsistenz zwischen den einzelnen Ergebnisdokumenten ga-

rantiert.

Das Zachman Framework schreibt kein Vorgehensmodell und keine Techniken vor, um die

Ergebnisdokumente der einzelnen Zellen zu erzeugen. Es werden lediglich einige generelle

Regeln und Prinzipien, die bei der Anwendung des Zachman Framework beachtet werden

sollten, vorgeschlagen. Die Reihenfolge, in der die einzelnen Sichten bzw. Zellen entwickelt

werden sollen, ist nicht festgelegt. Es kann aber davon ausgegangen werden, dass im Sinne

eines Top-Down-Vorgehens die oberen Zeilen der Matrix zu Beginn der Entwicklung einer

292 Vgl. Zachman (1987).

293 Vgl. Zachman/Sowa (1992).


Unternehmensarchitektur verwendet werden, während die unteren Zellen dagegen eher bei

den späteren Entwicklungsphasen von Bedeutung sind.


Das Zachman Framework bildet wesentliche Aspekte der Unternehmensarchitektur ab. Der

Bezugsrahmen berücksichtigt allerdings nicht die strategische Ausrichtung eines Unterneh-

mens. Der Anwendungsbereich beschreibt lediglich den Kontext, in dem das Informationssys-

tem eingesetzt werden soll, sowie die daraus abgeleiteten Anforderungen. Das Geschäftsmo-

dell bildet Informationsobjekte, Geschäftsprozesse sowie Organisationseinheiten ab und kor-

respondiert daher mit der in Abschnitt 2.3.1 identifizierten Prozess- bzw. Organisationsarchi-

tektur.

Das Zachman Framework erfüllt das Kriterium der Strukturierung, indem es eine Matrix defi-

niert, in der Informationen über das Unternehmen nach unterschiedlichen Sichten klassifiziert

werden können.

Das Zachman Framework stellt lediglich einen Bezugsrahmen für die Klassifizierung von

Modellen zur Verfügung. Den für die Modellierung der unterschiedlichen Zellen der Matrix

verwendeten Modellierungssprachen liegt aber kein gemeinsames Metamodell zugrunde. Da-

durch ist die Konsistenz zwischen den erstellten Modellen nicht gewährleistet.

Da das Zachman Framework keine Modellierungssprachen vorschreibt, kann deren Verständ-

lichkeit nicht bewertet werden. Der Bezugsrahmen sollte aber auch für Mitarbeiter aus den

Fachabteilungen aufgrund der Analogie zur Architektur eines Hauses weitgehend verständlich

sein.

Der Grad der Detaillierung nimmt nicht von den oberen zu den unteren Zeilen zu, sondern

innerhalb einer Zelle durch die Dekomposition der jeweiligen Modelle. Hinweise, wie diese

Dekomposition zu erfolgen hat und bis zu welchem Grad, werden nicht gegeben. Dies er-

schwert auch eine mögliche Integration der Modelle in unterschiedlichen Zellen, da diese e-

ventuell nicht den gleichen Detaillierungsgrad aufweisen.

Für die Modellierung der Inhalte der einzelnen Zellen werden keine Modellierungssprachen

fest vorgegeben. Diese sind somit flexibel anpassbar. Allerdings definiert die Matrix eine sehr

starre Struktur. Es können zwar zusätzliche Spalten definiert werden. Diese erstrecken sich

dann aber über alle Zeilen bzw. Sichten. Dadurch können Zellen entstehen, zu denen keine

Informationen vorliegen und die folglich nicht modelliert werden können.

Das Kriterium der Formalisierung erfüllt das Zachman Framework nicht. Zum einen wird

nicht formal spezifiziert, wie die Inhalte der einzelnen Komponenten dargestellt bzw. doku-

mentiert werden sollen. Darüber hinaus existiert kein zugrunde liegendes Metamodell, das die

abzubildenden Informationen und deren Zusammenhänge definiert. Dadurch ist die Gefahr

von Inkonsistenzen zwischen den einzelnen Zellen bzw. Modellen sehr hoch. Diese wird zu-


dem dadurch gesteigert, dass keine systematische Vorgehensweise für die Modellierung der

Zellen vorgegeben wird.

3.3.2 Federal Enterprise Architecture Framework (FEAF)


Aufgrund des Clinger-Cohen Act von 1996294, welcher von staatlichen Organisationen der

USA die Entwicklung und die Pflege einer Unternehmensarchitektur fordert, wurde das Fede-

ral Enterprise Architecture Framework (FEAF)295 aufgestellt. Das Ziel dieses Frameworks ist

es, die gemeinsame Entwicklung von Prozessen und Informationsstrukturen zwischen staatli-

chen Organisationen zu vereinfachen. Wie die anderen Frameworks ist auch FEAF ein Be-

zugsrahmen, der dazu dient, die Informationen der Unternehmensarchitektur strukturiert ab-

zubilden.

Das Framework besteht aus den Komponenten Architekturtreiber, strategische Ausrichtung,

Ist-Architektur, Soll-Architektur, Transformationsprozess, Architektursegmente, Architek-

turmodelle und Standards.296

• Architekturtreiber sind externe Einflussfaktoren (z.B. Regulationen, Budgetrestriktionen,

Marktänderungen sowie neue Technologien), die eine Änderung oder Anpassung der Un-

ternehmensarchitektur erfordern.

• Die strategische Ausrichtung beschreibt, welchen Anforderungen die Zielarchitektur ge-

nügen muss. Sie besteht aus einer Vision, Prinzipien und Zielvorgaben.

• Die Ist-Architektur beschreibt die bestehende Unternehmensarchitektur.

• Die Soll-Architektur legt die zu entwickelnde Unternehmensarchitektur fest.

• Der Transformationsprozess definiert die Migration von der bestehenden Architektur zur

Soll-Architektur in Übereinstimmung mit bestimmten Architekturstandards.

• Die Architektursegmente stellen Teilbereiche des gesamten Unternehmens dar.

• Die Komponente Standards umfasst alle zur Verfügung stehenden Standards, Richtlinien

und Best Practices.

Die zuvor genannten Komponenten werden anhand von vier unterschiedlichen Detaillie-

rungsgraden („Level“) beschrieben. Level 1 beschreibt die acht Komponenten lediglich über-

blicksartig. Auf Level 2 und 3 wird im Anschluss entschieden, welche Informationen von

Level 1 detaillierter abgebildet werden sollen. Level 4 definiert letztendlich die Modelle, wel-

294 Vgl. CIO-Council (1996).

295 Vgl. im Folgenden FEA (1999) und FEA (2001).

296 Vgl. im Folgenden FEA (1999), S. 6-7.


che die Geschäftsarchitektur, die Applikations- und Datenarchitektur sowie die Technologie-

architektur abbilden (vgl. Abbildung 30).

Abbildung 30: Federal Enterprise Architecture Framework

FEAF unterteilt somit die Unternehmensarchitektur in diese vier Architekturebenen, wobei

jedes Level einen Bezugsrahmen für das nachfolgende Level darstellt. Zusätzlich bietet es auf

Level 4 eine logische Struktur zur Klassifizierung der Komponenten, die auf den ersten drei

Spalten des Zachman Framework basiert.

3.3.2.2 Methodenbestandteile von FEAF

FEAF schlägt für jede Zelle der Matrix bestimmte Modellierungssprachen und Ergebnisdo-

kumente vor. So werden zum Beispiel für die Beschreibung der Applikationsarchitektur aus

Sicht des „Owner“ ein Geschäftsprozessmodell in Form eines UML-Aktivitätsdiagramms

oder für die Datenarchitektur aus Sicht des „Designer“ ein logisches Datenmodell in Form

eines UML-Klassendiagramms vorgeschlagen. Ein Metamodell, welches die Ergebnisdoku-

mente und vor allem deren Zusammenhänge festlegt, ist allerdings nicht vorhanden. Zudem

stellt FEAF keine detaillierte Beschreibung zur Verfügung, wie die einzelnen Ergebnisdoku-

mente erstellt werden sollen. Um die Zielarchitektur zu entwickeln, gibt FEAF lediglich ein

sehr unspezifisches Vorgehensmodell an, welches aus vier wesentlichen Phasen besteht: Da-

tenerfassung, vorläufige Produkterstellung, Bewertungs- und Anpassungsphase, Publikations-

und Umsetzungsphase. Die einzelnen Aktivitäten dieses generellen Vorgehens werden aller-

dings nicht weiter detailliert. Für die Modellierung der ersten beiden Ebenen des Zachman

Framework („Planner“ und „Owner“) auf Level 4 wird zudem die Vorgehensweise „Enter-

prise Architecture Planning“ (EAP) nach SPEWAK297 vorgeschlagen. Diese besteht aus sieben

Schritten, in denen ein Plan für den Entwurf und die Implementierung aufgestellt wird. EAP

ist allerdings lediglich auf die Analyse von Daten, Applikationen und den zugrunde liegenden

Technologien in Form von Matrizen fokussiert.

297 Vgl. Spewak/Hill (1993).



FEAF stellt einen weitgehend ganzheitlichen Ansatz zur Abbildung der Unternehmensarchi-

tektur dar. Allerdings wird auch von FEAF die strategische Ausrichtung des Unternehmens

vernachlässigt. Die Komponente „strategische Ausrichtung“ soll zwar gewährleisten, dass die

Ziel-Architektur mit den Zielen der gesamten Organisation übereinstimmt. Welche Informati-

onen dort abgebildet werden sollen, welche Modellierungstechniken verwendet werden sollen

und welches Vorgehen dafür notwendig ist, wird allerdings nicht festgelegt. Überdies sind die

Beziehungen zu den anderen Komponenten der Unternehmensarchitektur nicht spezifiziert.

FEAF liefert eine detaillierte Strukturierung der abzubildenden Informationen. Zum einen

besteht der Bezugsrahmen aus unterschiedlichen Komponenten. Jede dieser Komponenten

wird mit einem zunehmenden Detaillierungsgrad (Level) beschrieben. Auf Level 4 wird das

Unternehmen in unterschiedliche Architekturebenen eingeteilt. Zusätzlich werden die Infor-

mationen der Daten-, Applikations- und Technologiearchitektur anhand der ersten drei Spal-

ten des Zachman Framework klassifiziert.

Trotz der detaillierten Strukturierung besitzt FEAF den wesentlichen Mangel, dass den für die

Modellierung der unterschiedlichen Zellen der Matrix verwendeten Modellierungssprachen

kein gemeinsames Metamodell zugrunde liegt. Dadurch kann die Konsistenz zwischen den

erstellten Modellen nicht durch FEAF gewährleistet werden. Der Anwender muss selbst die

einzelnen Modelle konsistent halten. Bei einer derart grossen Zahl an Zellen und damit unter-

schiedlichen Modellierungssprachen ist dies eine erhebliche Herausforderung.

Das Kriterium der Verständlichkeit in Bezug auf die eingesetzten Modellierungssprachen

kann nicht bewertet werden, da FEAF diese nicht explizit vorschreibt. Der Anwender ist

selbst für die Wahl geeigneter Modellierungssprachen verantwortlich. Es ist allerdings frag-

lich, ob diese detaillierte Strukturierung nach unterschiedlichen Komponenten, Detaillie-

rungsgraden, Architekturebenen sowie zahlreichen Perspektiven und Sichten noch zu der ei-

gentlich intendierten Komplexitätsreduktion führt.

Die unterschiedlichen Level sollen einen zunehmenden Detaillierungsgrad bei der Abbildung

der Informationen über das Unternehmen ermöglichen. Allerdings ist die Definition dieser

Level sehr unspezifisch, so dass der Anwender bzw. Architekt nur wenig Anhaltspunkte für

den richtigen Detaillierungsgrad und die entsprechende Darstellungsform für den jeweiligen

Level erhält. Das Kriterium der Angemessenheit ist demzufolge nur unzureichend erfüllt.

In Bezug auf die verwendeten Modellierungssprachen macht FEAF keine Vorgaben und ist

demzufolge flexibel anpassbar. Allerdings stellt die auf Level 4 definierte Matrix des Zach-

man Framework eine fest vorgegebene Struktur zur Verfügung, die die Flexibilität bei der

Definition neuer Sichten einschränkt.

Das Kriterium der Formalisierung wird von FEAF nicht erfüllt. Zum einen wird nicht vorge-

schrieben, in welcher Form die Inhalte der einzelnen Komponenten dargestellt bzw. doku-


mentiert werden sollen. Zum anderen existiert kein zugrunde liegendes Metamodell, das die

abzubildenden Informationen und deren Zusammenhänge definiert.

3.3.3 The Open Group Architecture Framework (TOGAF)


TOGAF298 ist ein Industriestandard, der Mitte der 90er Jahre von einer Gruppe, bestehend aus

Vertretern führender IT-Anwender- und IT-Anbieterorganisationen, entwickelt wurde und bis

heute stetig weiterentwickelt wird. Im Unterschied zum Zachman Framework, das lediglich

einen Bezugsrahmen zur Klassifizierung von Informationen über das Unternehmen definiert,

beinhaltet TOGAF auch ein zyklisches Vorgehensmodell.

Ursprünglich war die von TOGAF verwendete Methode auf die Entwicklung von IT-

Architekturen fokussiert. Erst in der aktuellen Version 8.0 wurde diese Methode für die Ent-

wicklung anderer Ebenen einer Unternehmensarchitektur erweitert. Diese unterstützt die Ges-

taltung der folgenden vier Ebenen:

• Die Geschäftsarchitektur definiert die Geschäftsstrategie, die Organisationsstruktur sowie

die Kern-Geschäftsprozesse.

• Die Datenarchitektur beschreibt die Struktur der logischen und physischen Daten und Da-

tenquellen eines Unternehmens.

• Die Applikationsarchitektur gibt einen Überblick über die einzelnen zu entwickelnden

Anwendungssysteme sowie deren Beziehung zu den Kern-Geschäftsprozessen.

• Die Technologiearchitektur beschreibt die Software- und Hardware-Infrastruktur, die der

Unterstützung der Kernapplikationen dient.

TOGAF schreibt keine speziellen Sichten auf die unterschiedlichen Architekturebenen vor.

Stattdessen werden lediglich exemplarisch unterschiedliche Arten von Sichten beschrieben,

die für die Gestaltung einer bestimmten Unternehmensarchitektur von Bedeutung sein könn-

ten. Zudem bietet TOGAF Richtlinien für die Wahl bestimmter Sichten und deren Entwick-

lung.

3.3.3.2 Methodenbestandteile von TOGAF

Das Kernstück von TOGAF ist die Architecture Development Method (ADM). Diese dient

der systematischen Ableitung einer unternehmensspezifischen, die Geschäftsanforderungen

unterstützenden Architektur. Sie besteht aus einem systematischen, iterativen Vorgehen, un-

terschiedlichen Sichten, Vorschlägen für zu verwendende Modellierungstechniken, Verweisen

auf praktische Fallstudien sowie Hinweisen zu Software-Werkzeugen. Ziel ist die Ausrich-

298 Vgl. im Folgenden Opengroup (2002) und Varveris/Harrison (2005).


tung der Geschäfts-, Informationssystem- und Technologiearchitektur an den Geschäftsanfor-

derungen und -zielen des Unternehmens.

Der iterative Prozess der ADM besteht aus acht Phasen (vgl. Abbildung 31): Architekturvisi-

on, Geschäftsarchitektur, Informationssystemarchitektur, Technologiearchitektur, Lösungen,

Migrationsplanung, Umsetzung und Change Management. Jede dieser acht Phasen enthält

weitere Schritte, um eine spezifische Unternehmensarchitektur zu entwickeln.

Abbildung 31: TOGAF ADM

In der Phase „Architekturvision“ werden zunächst bereits existierende Architekturen im Hin-

blick auf eine mögliche Wiederverwendung betrachtet. Jede Phase verwendet und erzeugt

Ergebnisse. In der ersten Phase wird ein „Request for Architecture Work“ als Input verwen-

det. Dabei handelt es sich um ein Dokument, das Informationen über Geschäftsziele, strategi-

sche Geschäftspläne und verfügbare Ressourcen enthält.

In der zweiten Phase werden die Ist- und Soll-Geschäftsarchitektur modelliert. TOGAF

schlägt dafür die Verwendung von Industriestandards vor, wie beispielsweise BPMN299,

IDEF300 und UML301. Die Geschäftsarchitektur enthält zum einen die Aufbauorganisation mit

den Standorten der einzelnen Organisationseinheiten. Zum anderen werden in der Geschäfts-

architektur die Vision und Geschäftsziele jeder Organisationseinheit in textueller Form do-

kumentiert. Neben den Organisationseinheiten werden auch die Geschäftsfunktionen mit un-

terschiedlichen Detaillierungsgraden abgebildet. Dafür werden IDEF0 und UML-Use-Case-

299 BPMI (2002).

300 NIST (1993).

301 OMG (2005).


Diagramme vorgeschlagen. Weitere Elemente der Geschäftsarchitektur sind Leistungen, die

das Unternehmen sowohl externen als auch internen Kunden anbietet, sowie Ist- und Soll-

Geschäftsprozesse. Für die Modellierung der Geschäftsprozesse werden beispielsweise

BPMN, IDEF3 und UML-Aktivitätsdiagramme vorgeschlagen. Zuletzt werden noch Rollen

sowie die Beziehung zwischen Organisationseinheiten und Geschäftsfunktionen abgebildet.

Unter einer Rolle wird dabei ein Mitarbeiter des Unternehmens verstanden, der bestimmte

Qualifikationen besitzt. Die Gegenüberstellung von Organisationseinheiten und Geschäfts-

funktionen in Form von Matrizen soll deutlich machen, welche Organisationseinheiten für die

Durchführung welcher Geschäftsfunktionen verantwortlich sind.

Im dritten Schritt findet die Abbildung der Informationssystemarchitektur statt. Diese wird

weiter in eine Daten- und Applikationsarchitektur unterteilt. Die Datenarchitektur spezifiziert

die wesentlichen Daten und Datenquellen auf einem hohen abstrakten Niveau. Als mögliche

Modellierungstechniken werden konzeptionelle Datenmodellierung und logische Datenmo-

dellierung genannt. Zudem werden die identifizierten Datenobjekte und Geschäftsfunktionen

einander gegenübergestellt, um zu veranschaulichen, welche Datenobjekte von welchen Funk-

tionen manipuliert werden, und um mögliche Schnittstellen zu identifizieren. Nach der Daten-

architektur wird die Applikationsarchitektur betrachtet. Dabei werden die wesentlichen Ap-

plikationen spezifiziert, die für die Datenverarbeitung und die Unterstützung der Geschäfts-

prozesse benötigt werden. Als Techniken werden wiederum Matrizen für die Gegenüberstel-

lung von Applikationen und Geschäftsfunktionen vorgeschlagen.

Nach der Abbildung der Informationssystemarchitektur folgt im nächsten Schritt die Abbil-

dung der Technologiearchitektur. Diese bildet die Grundlage für die anschliessende Umset-

zung der Soll-Architektur. Sie beschreibt die Netzwerk-Infrastruktur sowie Hardware- und

Softwareplattformen des Unternehmens. Für jede Plattform werden Informationen, wie bei-

spielsweise Verantwortlichkeiten, unterstützte Geschäftsfunktionen und Organisationseinhei-

ten, unterstützte Applikationen, Standorte und Netzwerke, erhoben. Der Grad der Detaillie-

rung für die Beschreibung der einzelnen Komponenten wird von TOGAF nicht definiert.

In den drei nachfolgenden Phasen des Vorgehensmodells wird nach möglichen Lösungen ge-

sucht, darauf folgt eine Migrationsplanung und zuletzt die Umsetzung sowie das Change Ma-

nagement.

Die Verwendung von Referenzmodellen und Richtlinien kann als wichtige Aktivität im Rah-

men der Entwicklung einer Unternehmensarchitektur betrachtet werden. Dafür stellt TOGAF

zusätzlich zur ADM eine Sammlung von Referenzmodellen, Architekturmustern und Archi-

tekturbeschreibungen zur Verfügung. Diese können von Unternehmen für die Entwicklung

ihrer eigenen Architekturen herangezogen werden. Allerdings sind sie rein auf technische

Aspekte bezogen.


TOGAF besteht im Wesentlichen aus den drei Teilen ADM, Enterprise Continuum und Re-

source Base. Für keines dieser Teile liegt ein Metamodell vor, das eine konsistente (Wie-

der)Verwendung von Elementen gewährleistet.

Obwohl TOGAF die unterschiedlichen Inputs und Ergebnisse der einzelnen Phasen der ADM

definiert, liegen keine Ergebnisdokumente vor, die die Ergebnisse strukturiert beschreiben.

Die Ergebnisse bestehen meist aus Prinzipien und Richtlinien. Durch die Anwendung be-

stimmter Techniken, wie z.B. ER-Modellierung, werden zwar eindeutige Ergebnisdokumente

erzeugt (ER-Diagramm), die Vorgehensweise von TOGAF definiert allerdings nicht, in wel-

cher Phase des Entwicklungsprozesses welche Ergebnisdokumente erzeugt werden.

TOGAF definiert keine spezifischen Modellierungssprachen oder -techniken für eine Ebene,

sondern beschreibt lediglich exemplarisch einige Modellierungssprachen, die für die Model-

lierung der Architekturebenen verwendet werden können. Für einige Entwicklungsphasen der

TOGAF ADM werden Techniken vorgeschlagen. So werden beispielsweise in der Phase „In-

formationssystemarchitektur“ (Schritt 2 Architekturmodell) ER-Diagramme für die Modellie-

rung von Sichten auf die Datenarchitektur und Entitäten-Geschäftsfunktionen-Matrizen für

die Abbildung von Beziehungen oder Geschäftsszenarios verwendet.

Weitere Bestandteile, die durch das Framework abgebildet werden können, sind Informations-

flüsse, die den Austausch von Daten zwischen Applikationen und den unterstützenden Soft-

warekomponenten beschreiben, sowie Geschäftsobjekte und deren Zustand, die von Ge-

schäftsprozessen oder Applikationen verwendet werden, um „reale“ Daten, wie z.B. Kunden,

Produkte und Verträge, zu beschreiben.


Seit der Version 8.0 geht TOGAF in die Richtung eines ganzheitlichen Ansatzes, der nicht

mehr nur die Abbildung der IT-Architektur unterstützt, sondern auch Elemente der Geschäfts-

architektur umfasst. Dennoch fehlt gerade auf der Ebene der Geschäftsarchitektur noch eine

umfassende und formale Beschreibung der strategischen Ausrichtung eines Unternehmens.

Der Fokus von TOGAF liegt deshalb auch in der aktuellen Version immer noch zu stark auf

der Abbildung der Technologiearchitektur.

Das Kriterium der Strukturierung wird von TOGAF zumindest im Hinblick auf die Einteilung

in unterschiedliche Architekturebenen erfüllt. Allerdings werden keine speziellen Sichten für

die unterschiedlichen Architekturebenen definiert.

Einer der wesentlichsten Mängel von TOGAF ist, dass die Konsistenz zwischen den Archi-

tekturebenen und unterschiedlichen, vom Anwender bzw. Architekten selbst zu definierenden

Sichten, von der Methode nicht gewährleistet wird. TOGAF definiert kein zugrunde liegendes

Metamodell, das die wesentlichen Metaentitätstypen auf unterschiedlichen Architekturebenen

zueinander in Beziehung setzt. Zwar werden verschiedene Modellierungssprachen vorge-


schlagen, wie z.B. UML und BPMN, deren Syntax durch ein Metamodell spezifiziert ist. Al-

lerdings werden dadurch nicht die Abhängigkeiten zwischen den mit der jeweils verwendeten

Modellierungssprache erstellten Modellen spezifiziert. Der Anwender ist folglich mit dem

Problem konfrontiert, selbst die Abhängigkeiten zwischen den Modellen zu identifizieren und

deren Konsistenz zu überprüfen.

Das Kriterium der Verständlichkeit der verwendeten Notationen kann nicht beurteilt werden,

da TOGAF nicht die Verwendung bestimmter Modellierungssprachen vorschreibt. Die Erfül-

lung dieses Kriteriums hängt davon ab, welche Modellierungssprachen der Anwender im

konkreten Fall auswählt.

TOGAF gibt keine konkreten Hinweise, mit welchem Detaillierungsgrad bestimmte Sachver-

halte abgebildet werden sollten. Somit liegt es im Ermessen des Architekten, die passenden

Modellierungssprachen und einen sinnvollen Detaillierungsgrad zu wählen.

Aufgrund der zuvor genannten Freiheitsgrade, die TOGAF dem Anwender zugesteht, besitzt

die Methode eine hohe Flexibilität. Dies geht allerdings auf Kosten der Konsistenz der er-

zeugten Ergebnisse. Zudem werden viele Entscheidungen bei der konkreten Modellierung

dem Anwender selbst überlassen.

Aus den vorhergehenden Punkten lässt sich schliessen, dass TOGAF einen sehr niedrigen

Formalisierungsgrad aufweist. TOGAF definiert keine bestimmten Modellierungssprachen

und Sichten sowie kein zugrunde liegendes Metamodell.

Insgesamt betrachtet ist die Dokumentation von TOGAF zwar sehr umfangreich. Dieser man-

gelt es aber sehr häufig an konkreten Hinweisen, wie die Modellierung der Architektur prak-

tisch erfolgen soll. Sie bietet dem Anwender somit bei entscheidenden Problemen oftmals

nicht ausreichend Unterstützung.

3.4 Zusammenfassung und Übersicht der Bewertung

Zusammenfassend ist festzuhalten, dass alle zuvor beschriebenen Ansätze eine Hierarchie von

Modellierungsebenen zur Strukturierung der einzelnen Modelle verwenden. Des Weiteren

verfolgen alle Ansätze das Prinzip, dass die Informationssysteme eines Unternehmens ent-

sprechend den fachlichen Anforderungen gestaltet sein müssen. Bei einem Top-Down-

Vorgehen schränken somit die Ergebnisse der Modellierung einer Ebene jeweils die Gestal-

tungsmöglichkeiten auf der darunter liegenden Ebene ein, wobei gleichzeitig die Implemen-

tierungsnähe zunimmt.

Konsolidiert man die in den verwandten Ansätzen beschriebenen Ebenen, so erhält man im

Wesentlichen die vier Ebenen „Strategieebene“, „Organisationsebene“, „Applikationsebene“

und „IT-Ebene“. Die vier genannten Ebenen finden sich nicht in allen Ansätzen. ARIS sowie

Zachman und FEAF definieren nicht explizit eine Strategieebene. SOM und TOGAF bilden

die Strategieebene lediglich in natürlichsprachlichem Fliesstext ab. Einige Ansätze wiederum


bilden die Sachverhalte einer Ebene nur sehr vereinfachend ab. ARIS und Zachman sind sehr

stark von softwareentwicklungsrelevanten Aspekten dominiert. Andere, wie beispielsweise

TOGAF, sind dagegen stark auf die detaillierte Dokumentation der IT-Architektur fokussiert.

ARIS integriert zwar wichtige Sichten auf den Geschäftsprozess, für die auch eine umfassen-

de Werkzeugunterstützung verfügbar ist, doch ist ARIS nur beschränkt hierarchisierbar, da

die Ebenen an den Phasen des Entwicklungsprozesses ausgerichtet sind (Fachkonzept, DV-

Konzept und Implementierung) und somit zu stark auf softwareentwicklungsrelevante Aspek-

te fokussiert. Zudem beziehen sich die fünf Sichten lediglich auf den Geschäftsprozess. Ande-

re Sichten auf das Unternehmen, wie z.B. Geschäftsziele und Geschäftsnetzwerk, werden ver-

nachlässigt.

Zusätzlich zu den Ebenen werden in den meisten Ansätzen Sichten eingeführt, um die Kom-

plexität der abzubildenden Sachverhalte auf einer Ebene zu reduzieren. Die Anzahl der Sich-

ten pro Ebene variiert bei den einzelnen Ansätzen sehr stark. Aufgrund der Prozessorientie-

rung bietet ARIS auf Ebene der Geschäftsprozesse sechs verschiedene Sichten. SOM definiert

dagegen lediglich zwei Sichten. Der Bezugsrahmen von Zachman differenziert auf allen Ebe-

nen nach sechs Sichten, wodurch eine Matrix zur Strukturierung der Artefakte entsteht.

Die beschriebenen Bezugsrahmen aus der Praxis unterscheiden zwischen zahlreichen Teil-

sichten, die allerdings eine reine Aufzählung darstellen und nicht durch ein umfassendes Me-

tamodell spezifiziert und zueinander in Beziehung gesetzt sind, so dass die Konsistenz zwi-

schen den Modellen der unterschiedlichen Teilsichten nicht gewährleistet werden kann. Eben-

so wird nicht festgelegt, welche Modellierungssprachen oder -techniken für die einzelnen

Sichten verwendet werden sollen. Es werden lediglich Beispiele angegeben. Zachman unter-

scheidet beispielsweise 30 Teilsichten. Aufgrund der Vielfalt möglicher Perspektiven auf die

Informationssysteme eines Unternehmens ist diese Anzahl sicher gerechtfertigt. Allerdings

besteht dadurch die Gefahr, der ursprünglichen Intention einer Unternehmensarchitektur,

nämlich der komplexitätsreduzierenden und damit anschaulichen und verständlichen Abbil-

dung des Unternehmens und seiner Informationssysteme, entgegenzuwirken. Unternehmens-

modelle sind nicht vordergründig auf die detaillierte Beschreibung für Entwickler von Infor-

mationssystemen ausgerichtet, sondern sollen in erster Linie dazu dienen, auch Personen aus

den Fachbereichen eine anschauliche Beschreibung wichtiger Sachverhalte und Zusammen-

hänge in einem Unternehmen zu liefern und damit den Diskurs über das Unternehmen zu för-

dern. Deshalb sollte eine möglichst breite Darstellung der Unternehmensstrukturen mit einem

angemessenen Detaillierungsgrad angestrebt werden. Darüber hinaus definieren die genannten

Bezugsrahmen zur Strukturierung der Unternehmensmodelle bis auf TOGAF keine Vorge-

hensweise, die die systematische Erstellung der unterschiedlichen Sichten auf das Unterneh-

men ermöglicht.

Mit Ausnahme von ARIS und MEMO verfügen die betrachteten Ansätze über kein oder ein

nur wenig ausgearbeitetes Metamodell, in dem die Beschreibungskonzepte der verschiedenen


Sichten zueinander in Beziehung gesetzt werden. Für die Strategieebene definieren die meis-

ten Ansätze keine Metamodelle. Das Objekt- und das Zielsystem des Unternehmensplans der

SOM-Methode werden beispielsweise lediglich in natürlichsprachlichem Fliesstext darge-

stellt. Die Modellierungssprachen der SOM-Methode sind häufig für mehrere Modelle einer

Ebene spezifiziert, so dass das Metamodell Modellierungskonstrukte enthalten kann, die in

einem Modell nicht verwendet werden.

In ARIS liegen für alle Sichten auf den Geschäftsprozess Metamodelle vor, die zu einem in-

tegrierten Metamodell verknüpft werden können. ARIS schreibt aber keine bestimmten Me-

tamodelle für die Ausgestaltung der Modellierungssprachen anderer Ebenen vor. MEMO ver-

fügt zwar über ein Metamodell und eine Spracharchitektur für die verwendeten Modellie-

rungssprachen. Allerdings verwendet MEMO, wie die Bezugsrahmen aus der Praxis, eine

Matrix zur Festlegung der Ebenen (Perspektiven) und Sichten. Dies vereinfacht zwar die De-

finition der Beziehungen zwischen Elementen auf unterschiedlichen Ebenen, dadurch wird

aber gleichzeitig die Flexibilität im Hinblick auf die Definition unterschiedlicher Sichten auf

unterschiedlichen Ebenen eingeschränkt, da die Sichten bzw. Spalten für alle Ebenen der Mat-

rix festgelegt sind. Ausserdem kann es vorkommen, dass bei der Definition einer neuen Sicht

nicht alle Zellen „ausgefüllt“ bzw. modelliert werden können.

Tabelle 6 zeigt zusammenfassend den Erfüllungsgrad der inhaltlichen sowie strukturellen

Kriterien durch die zuvor betrachteten Ansätze. Darin ist ersichtlich, dass keiner der Ansätze

alle Methodenbestandteile umfasst und jeder Ansatz unterschiedliche Stärken und Schwächen

in Bezug auf die inhaltlichen Kriterien aufweist. Auffallend ist, dass die in der Praxis weit

verbreiteten Bezugsrahmen (Framework) die Kriterien am wenigsten erfüllen, insbesondere

die Kriterien der Ganzheitlichkeit, Konsistenz und Formalisierung.

Inhaltliche Charakteristika Strukturelle Charakteristika

Methode/

Framework

Gan

zhei

tlic

hk

eit

Str

uk

turi

eru

ng

Kon

sist

enz

Ver

stän

dli

chk

eit

An

gem

esse

nh

eit

Fle

xib

ilit

ät

Form

ali

sier

un

g

Vorg

ehen

Roll

en

Erg

eb

nis

se

Tec

hn

iken

Met

am

od

ell

ARIS MEMO

SOM

FEAF TOGAF

Zachman

Tabelle 6: Übersicht über die Bewertung existierender Ansätze

Legende: erfüllt/vorhanden teilweise

erfüllt/vorhanden nicht

erfüllt/vorhanden


Aufgrund dieser Schwächen wird in Kapitel 4 ein eigener Ansatz vorgeschlagen, der die Stär-

ken der bewerteten Ansätze berücksichtigt und vor allem die Kriterien der Ganzheitlichkeit,

Konsistenz und Formalisierung adressiert. Der Fokus des eigenen Ansatzes liegt deshalb auf

der Entwicklung eines möglichst umfassenden bzw. ganzheitlichen, (semi-)formal definierten

Metamodells, das auch die ebenen- und sichtenübergreifenden Abhängigkeiten berücksichtigt.

Ansatz zur Modellierung der Unternehmensarchitektur 89

4 Ansatz zur Modellierung der Unternehmens-

architektur

In den folgenden vier Abschnitten dieses Kapitels wird ein Ansatz zur Modellierung der

Unternehmensarchitektur bestehend aus den Methodenelementen Vorgehensmodell,

Metamodell und Ergebnisdokumente auf Strategie-, Organisations-, Informationssystem- und

Infrastrukturebene präsentiert. Die folgende Abbildung 32 visualisiert überblicksartig die

einzelnen Gestaltungsebenen und Sichten des entwickelten Ansatzes.

Abbildung 32: Gestaltungsebenen und Sichten des entwickelten Ansatzes


Als Ausgangsbasis für die Entwicklung des in der vorliegenden Arbeit präsentierten Ansatzes

dient die bereits existierende BAI-Methode.302 Diese wird einerseits genauer spezifiziert und

erweitert anhand der zuvor beschriebenen verwandten Methoden und Frameworks (vgl.

Kapitel 3) sowie andererseits anhand der Ergebnisse einer Literaturanalyse (vgl. Tabelle 7),

die unterschiedliche Teilbereiche der Unternehmensarchitektur abdeckt (z.B. Strategiegestal-

tung, Prozessmanagement, Applikationsintegration, Autorisierung, Servicemanagement). In

Abbildung 32 sind die im Vergleich zur BAI-Methode neu hinzugefügten Sichten schraffiert

dargestellt. Nicht schraffiert dargestellte Sichten sind von der BAI-Methode übernommen und

werden genauer spezifiziert und/oder erweitert.

Domäne Primär verwendete Literaturquellen

Strategiegestaltung

Böh/Meyer (2004), Buhl et al. (1999), Grant (1998), Hahn (1997), Harengel (2000), Heinrich/Winter (2004), Kaplan/Norton (1997), Kühn/Karagiannis (2005), Leidecker/Bruno (1984), Leist/Winter (2002), Mintzberg (1987), Müller-Stewens/Lechner (2003), Österle et al. (2001), Scholz (1998), Winter (2003d), Winter (2003b)

Prozess- und Organisati-

onsgestaltung

Brecht (2002), Hess/Brecht (1996), IMG (1997), Jonkers et al. (2004), Junginger et al. (2000), Kühn/Karagiannis (2005), Legner (1999), Nüttgens/Rump (2002), Oestereich et al. (2004), Österle (1995), Rosemann/zur Mühlen (1997), Scheer (1998), Scheer (2001), Scheer/Thomas (2005), Strauch (2002), Vogler (2003), Winter (2003d), Winter (2004a), Zellner (2003), Wortmann (2005)

Informationssystem-

gestaltung und Autorisie-

rung

Ferraiolo et al. (2001), Greenfield/Short (2003), IBM-Corporation (1984), IMG (1999), Jeckle et al. (2004b), Jonkers et al. (2004), Kern et al. (2002), Kühn/Karagiannis (2005), OMG (2003a), OMG (2005), Samarati/de Capitani di Vimercati (2002), Schwinn (2005), Seufert (2001), Winter (2003a), Wortmann (2005)

Serviceorientiertes IT-

Management/ Serviceori-

entierte Architektur

(SOA)

Arsanjani (2004), Böhmann et al. (2002), Commerce (2000), Dan et al. (2004), Hafner et al. (2006), Hegering et al. (1999), Hochstein et al. (2004), Hochstein/Hunziker (2003), Mayerl et al. (2005), Schelp et al. (2004), Schemm et al. (2006), Stojanovic (2005), Winter/Schelp (2005), W3C (2004a), Zarnekow et al. (2004)

Tabelle 7: Domänenspezifische Literaturquellen

Wie eingangs ausgeführt (vgl. Abschnitt 1.2), stellt diese Arbeit lediglich einen Ansatz und

keine vollständige Methode303 zur Gestaltung der Unternehmensarchitektur dar. Es wird nicht

auf einzelne Techniken sowie die ausführenden Rollen eingegangen, da die Beschreibung

dieser Methodenelemente zu umfangreich wäre und den Rahmen dieser Arbeit sprengen wür-

de. Der Fokus liegt auf der Definition der Metamodelle, deren wesentlichen Metaentitätstypen

und Zusammenhänge sowie auf den wesentlichen Aktivitäten des Vorgehensmodells (ledig-

lich Level 1). Die einzelnen Vorgehensmodelle werden in Form von UML-Aktivitätsdiagram-

302 Vgl. Choinowski et al. (2003) und Abschnitt 2.3.4.

303 Vgl. hierzu die in Abschnitt 2.1.2 beschriebenen Methodenbestandteile.


men abgebildet (vgl. Abschnitt 2.2.4.2). Für die Darstellung der Metamodelle werden UML-

Klassendiagramme304 verwendet (vgl. Abschnitt 2.2.4.1).

Das Metamodell ist das konzeptionelle Datenmodell der Ergebnisse einer Methode, das die

Bestandteile und deren Zusammenhänge aller Entwurfsergebnisse gesamthaft darstellt.305 Es

besteht aus den Elementen Metaentitätstyp, Attribut und Beziehungstyp.306 Metaentitätstypen

sind Bestandteile von Entwurfsergebnissen. Beziehungstypen beschreiben die logische Ver-

bindung zwischen Metaentitätstypen. Attribute sind Eigenschaften von Metaentitätstypen.

Durch die Darstellung einer grösseren Zahl an Metaentitätstypen sowie der Beziehungstypen

wird das Metamodell rasch unübersichtlich. Aus diesem Grund wird das Metamodell in prob-

lemorientierte Sichten bzw. (Teil-)Modelle unterteilt, welche thematisch zusammengehörende

Metaentitätstypen zusammenfassen.307 Die problemorientierten Sichten müssen nicht zwin-

gend disjunkt sein.308

Das Metamodell umfasst neben der grafischen Darstellung der Metaentitätstypen und ihrer

Beziehungen auch eine detaillierte verbale Beschreibung, um mögliche Fehlinterpretationen

zu vermeiden. Zur Beschreibung der Metaentitätstypen wird folgende Struktur angewendet:

• Bezeichnung: Name des Metaentitätstyps,

• Definition: genaue Beschreibung des Metaentitätstyps,

• Beziehungen zu: Beschreibung der Beziehungstypen zu anderen Metaentitätstypen.

Aus Gründen der Übersichtlichkeit wird auf die Definition von Attributen für die einzelnen

Metaentitätstypen verzichtet. Ausserdem ist es sinnvoll, die Attribute erst bei der Anwendung

in einem unternehmensspezifischen Umfeld zu definieren.

Das Vorgehensmodell des hier vorgestellten Ansatzes verfolgt entsprechend der Vorgehens-

weise im Business Engineering einen Top-Down-Ansatz309, wenngleich die Ebenenbildung

keine ausschliessliche Top-Down-Vorgehensweise erfordert.310 Demzufolge impliziert eine

Veränderung innerhalb der Strategieebene die Ausrichtung der Organisationsebene, diese

anschliessend die Umgestaltung der Applikationsebene und diese wiederum die Umgestaltung

der Softwarekomponenten- und Datenstrukturebene.

304 Vgl. OMG (2003b).

305 Vgl. Gutzwiller (1994), S. 14 und Abschnitt 2.1.2.



308 Vgl. Kaiser (2000), S. 80.

309 Vgl. Österle (1995), S. 24.

310 Vgl. Österle/Blessing (2003), S. 77.


4.1 Modellierung auf Strategieebene

Die Strategieebene stellt die oberste Gestaltungsebene bei der Entwicklung einer Unterneh-

mensarchitektur dar (vgl. Abschnitt 2.3.1 und 2.3.2). Bei ihrer Gestaltung müssen die Poten-

ziale der Informationstechnologie erkannt und deren Umsetzungsrestriktionen berücksichtigt

werden. Wesentliche Anforderungen an einen Ansatz für die Modellierung auf Strategieebene

sind: 311

• Abbildung des Zusammenwirkens von Unternehmungen bzw. Geschäftseinheiten zur ge-

meinsamen Abdeckung des Kundenprozesses,

• Beschreibung der wesentlichen Elemente der strategischen Ausrichtung eines Unterneh-

mens bzw. einer Geschäftseinheit,

• Operationalisierung der Strategie durch Formulierung entsprechender Ziele und Kennzah-

len.

Als Bezugseinheiten für die Strategiegestaltung kommen Unternehmen, einzelne Geschäfts-

einheiten oder Rollen im Geschäftsnetzwerk in Betracht.

Da die im Kapitel zuvor beschriebenen Ansätze zur Gestaltung der Unternehmensarchitektur

nur eine sehr geringe Menge an Metaentitätstypen und Sichten für die Abbildung der strategi-

schen Ausrichtung eines Unternehmens bieten, wird für die Beschreibung der Modelle, Meta-

entitätstypen und deren Beziehungen auf Strategieebene primär auf die BAI-Methode sowie

die in Tabelle 7 enthaltenen Literaturquellen zurückgegriffen.

Geschäftsstrategien werden bisher in der Praxis nur selten systematisch entwickelt und ledig-

lich in natürlicher Sprache dokumentiert und kommuniziert.312 Im Hinblick auf die ständige

Erweiterung und schnelle Änderung von Strategien in der heutigen Geschäftswelt birgt diese

Vorgehensweise die Gefahr, dass die Geschäftsstrategie eines Unternehmens unvollständig

dokumentiert ist und Unklarheiten sowie Inkonsistenzen aufweist. Dies kann durch den Ein-

satz von zumindest semi-formalen Modellen und damit durch eine strukturierte und standardi-

sierte Dokumentation vermieden werden.

Im Unterschied zu ARIS und MEMO (vgl. Abschnitt 3.2.1 und 3.2.2) wird auf Strategieebene

nicht auf das Konzept der Wertschöpfungskette nach PORTER313 zurückgegriffen. Aufgrund

der Positionierung der vorliegenden Arbeit im BE orientieren sich die Modelle zur Strategie-

gestaltung an der Kundenprozessorientierung und der Bildung von Geschäftsnetzwerken.

Nach ÖSTERLE ist das Unternehmen des Informationszeitalters nicht mehr produkt-, sondern

311 Vgl. Winter (2004b), Kühn/Karagiannis (2005), S. 1494 sowie Abschnitt 2.3.1 und 2.3.2.

312 Vgl. Heinrich/Winter (2004), S. 2.

313 Vgl. Porter (1999).


kundenorientiert.314 Es muss das Kundenbedürfnis umfassend abdecken und dem Kunden so

viele zusammenhängende Teilprobleme wie möglich abnehmen, also den gesamten Prozess

des Kunden bei seiner Problemlösung abdecken. Dazu ist die Integration von Leistungen

notwendig, die von unterschiedlichen Geschäftspartnern bezogen werden. Das Ergebnis sind

die Aufspaltung der Wertschöpfungskette und die Bildung von Geschäftsnetzwerken. Die

lineare vertikale Wertschöpfungskette hat sich so zu einem verzweigten Wertschöpfungs-

netzwerk gewandelt, in dem unterschiedliche Unternehmen und Geschäftseinheiten Teilauf-

gaben in der Wertschöpfungskette übernehmen.315

Auf der Strategieebene können folgende Ergebnisdokumenttypen unterschieden werden:

• Das Geschäftsnetzwerk beschreibt das Zusammenwirken von Unternehmen bzw. Ge-

schäftseinheiten in einem Wertschöpfungsnetzwerk zur gemeinsamen Abdeckung von be-

stimmten Kundenbedürfnissen.316

• Das Kundenprozessmodell beschreibt die Schritte, die der Kunde durchläuft, um ein be-

stimmtes Bedürfnis zu befriedigen, sowie die zur Bedürfnisbewältigung notwendigen Ser-

viceleistungen.317

• Das Leistungsmodell legt die strategische Ausrichtung eines Unternehmens bzw. einer

Geschäftseinheit in Bezug auf einen bestimmten Stichtag anhand von Ausprägungen be-

stimmter vorgefundener (z.B. Markt) und gestaltbarer (z.B. Produkte, Organisation) Di-

mensionen fest.318

• Das Zielsystem systematisiert in Form einer Balanced Scorecard (BSC) die zur Errei-

chung der Ziele notwendigen zentralen strategischen Erfolgsfaktoren eines Unternehmens

bzw. einer Geschäftseinheit und operationalisiert diese durch die Definition entsprechen-

der Kennzahlen.319

Im folgenden Abschnitt wird das Vorgehen zur Erstellung der zuvor genannten Ergebnisdo-

kumente beschrieben.

314 Zur Aufspaltung der Wertschöpfungskette und der Bildung von Wertschöpfungsnetzwerken vgl. Österle

(2003), Buhl et al. (1999), Leist/Winter (2000) und Scholz (1998). 315

Vgl. Österle (2003), S. 32-34. 316

Vgl. Winter (2003d), S. 96 und Österle (2003), S. 32-34. 317

Vgl. Heinrich (2002b), S. 84 und Österle et al. (2001), S. 45-51. 318

Zur Definition des Leistungsmodells vgl. Heinrich (2000), Heinrich (2002a) und Heinrich/Winter (2004). HEINRICH verwendet allerdings im Unterschied zu dieser Arbeit den Begriff Geschäftsmodell.

319 Vgl. Kaplan/Norton (1997) und Harengel (2000).


4.1.1 Vorgehensmodell

Das Vorgehensmodell zur Strategiegestaltung besteht auf Level 1 aus vier wesentlichen Akti-

vitäten (vgl. Abbildung 33):320

Zunächst wird das Geschäftsnetzwerk festgelegt. Dabei werden den Unternehmen bzw. Ge-

schäftseinheiten entsprechende Rollen im Geschäftsnetzwerk zugeordnet. Zusätzlich sollten

die wichtigsten Leistungsverflechtungen abgebildet werden. Ausgangspunkt für die Gestal-

tung eines Geschäftsnetzwerks sind bestimmte Kundenprozesse, hinter denen in den meisten

Fällen auch spezifische Kundensegmente stehen. Ausgewählte Kundenprozesse werden durch

Service Integrators ganzheitlich unterstützt, wobei ein Kundenprozess (bzw. Kundensegment)

auch durch mehrere Service Integrators unterstützt werden kann.

Im nächsten Schritt sind die abzudeckenden Kundenprozesse zu analysieren. Diese bilden die

Grundlage für die detaillierte Leistungsbeschreibung sowie für die auf Organisationsebene zu

definierenden Geschäftsprozesse. Zunächst werden bei der Kundenprozessanalyse die ver-

schiedenen Teilaspekte oder Teilschritte des zu unterstützenden Kundenprozesses und deren

Abfolge strukturiert. Darauf aufbauend wird für jeden Teilaspekt bzw. Teilschritt geprüft,

welche Teilleistungen erbracht werden müssen, um den jeweiligen Teilaspekt bzw. Teilschritt

zu unterstützen. In nachfolgenden Schritten ist zu prüfen, ob die jeweiligen Teilleistungen auf

Grundlage des Geschäftsmodells des jeweiligen Unternehmens bzw. der jeweiligen Ge-

schäftseinheit selbst erbracht werden sollten oder besser fremdbezogen werden. Schliesslich

sind geeignete Bündelungen und Vertriebskanäle zu identifizieren, die sich auf die eigener-

stellten Teilleistungen, aber auch auf zu integrierende Fremdleistungen beziehen.

Im dritten Schritt wird das Leistungsmodell sowohl aus einer exogenen als auch aus einer en-

dogenen Perspektive entwickelt. Bei der Spezifikation der exogenen Perspektive stehen Di-

mensionen zur Beschreibung der marktbezogenen strategischen Ausrichtung des Unterneh-

mens bzw. der Geschäftseinheit im Mittelpunkt, wie beispielsweise Land/Region, Kunde,

Kernprodukte und Leistungen, Marke und Vertriebsweg.321 Die endogene Perspektive umfasst

dagegen Dimensionen, die die interne Konstitution des Unternehmens bzw. der Geschäftsein-

heit beschreiben, wie beispielsweise Kompetenzfelder, Ziele, Partner und Organisationsstruk-

tur.

Im letzten Schritt wird das Zielsystem des Unternehmens bzw. der Geschäftseinheit anhand

einer Balanced Scorecard322 beschrieben. Diese bildet die Grundlage für die Spezifikation der

zur Prozessgestaltung benötigten Führungsgrössen und Erfolgsfaktoren. Die zentralen strate-

gischen Erfolgsfaktoren eines Unternehmens werden nach den Perspektiven Finanzen, Kun-

320 Vgl. Choinowski et al. (2003), S. 16f.

321 Vgl. Heinrich (2002a), S. 62.

322 Vgl. Kaplan/Norton (1997).


den, Prozess und Potenzial systematisiert und anschliessend durch die Bildung perspektiven-

orientierter Kennzahlen operationalisiert.

Die zuvor genannten Aktivitäten des Vorgehensmodells auf Strategieebene sollten nacheinan-

der durchgeführt und durch Konsistenzprüfungen ergänzt werden (vgl. hierzu die in Abschnitt

4.6.1 identifizierten Abhängigkeiten auf Strategieebene).

Abbildung 33: Vorgehensmodell auf Strategieebene (Level 1)

4.1.2 Metamodell

Das Metamodell der Strategieebene lässt sich entsprechend den bei der Strategiegestaltung

erstellten Ergebnisdokumenttypen in die Sichten Geschäftsnetzwerk, Kundenprozess, Leis-

tungsmodell sowie Zielsystem (BSC) einteilen.

4.1.2.1 Metamodell des Geschäftsnetzwerks

In Geschäftsnetzwerken nimmt jedes Unternehmen bzw. jede Geschäftseinheit eine oder meh-

rere Rolle(n) wahr. Die Rollen orientieren sich dabei an den kompetenzbasierten Typen von

Organisationseinheiten:323

Ein Service Integrator integriert (im Normalfall nicht selbst erstellte) Leistungskomponen-

ten, um damit einen bestimmten Kundenprozess ganzheitlich zu unterstützen. Seine Kern-

kompetenz ist demzufolge die umfassende Kenntnis von Kundenbedürfnissen bzw. Kunden-

prozessen.

Ein Shared Service Provider produziert Leistungskomponenten für verschiedene andere

Service Providers oder Service Integrators. Im Gegensatz zu Service Providern decken sie

keine Bedürfnisse ganzheitlich ab, sondern spezialisieren sich auf die effiziente Herstellung

spezifischer, aber standardisierter Leistungskomponenten in grossen Mengen.

323 Vgl. im Folgenden Winter (2003d), S. 53-54.


Ein Exclusive Service Provider erzeugt ebenfalls Leistungskomponenten für andere Service

Providers oder Service Integrators. Im Gegensatz zu Shared Service Providers werden aller-

dings nicht grosse Mengen von Leistungskomponenten für mehrere Abnehmer produziert,

sondern spezifischere Leistungskomponenten für einen oder wenige Abnehmer und damit in

eher kleineren Mengen. An die Stelle von Kunden- bzw. Kundenprozessorientierung (Service

Integrator) bzw. Kostenführerschaft (Shared Service Provider) treten als Haupt-

erfolgsfaktoren Schnelligkeit, Flexibilität und/oder spezifische Prozesskompetenzen.

Ein Public Service stellt Leistungskomponenten bereit, die keinen spezifisch fachlichen Cha-

rakter haben, aber zur Abwicklung der Leistungserstellung unverzichtbar sind. Im engeren

Sinne handelt es sich dabei um Dienste mit quasi-hoheitlicher Funktion wie z.B. Zertifizie-

rung oder Authentifizierung. Im weiteren Sinne können auch andere elektronische Dienste

wie z.B. Informationsdienste, Katalogdienste, Zahlungsabwicklung und Logistikabwicklung

darunter subsumiert werden.

Die folgende Abbildung 34 zeigt das Metamodell des Geschäftsnetzwerkmodells. Im Ge-

schäftsnetzwerkmodell werden die Geschäftseinheiten bzw. Unternehmen entsprechend der

ihnen zugeordneten Rollen dargestellt. Zusätzlich sollten die wichtigsten Leistungsverflech-

tungen abgebildet werden. Jede Rolle erbringt und/oder bezieht eine oder mehrere Marktleis-

tungen. Eine Marktleistung ist ein Produkt oder eine Dienstleistung, die ein Unternehmen

oder eine Geschäftseinheit am Markt bzw. im Geschäftsnetzwerk anbietet.324 Sie wird durch

das Zusammenwirken eines Bündels von Leistungen erbracht. Eine Marktleistung kann stan-

dardisiert oder individualisiert sein. Standardisierte Marktleistungen werden von Shared

Service Providers in grossen Mengen für zahlreiche andere Service Provider oder Service

Integrators erbracht. Merkmal von standardisierten Marktleistungen ist, dass die Leistung für

einen fiktiven Durchschnittskunden (Dienstnehmer) erstellt wird. Individualisierte Markt-

leistungen werden dagegen von Exclusive Service Providern für einige wenige andere Servi-

ce Provider oder Service Integrators in geringer Menge erbracht. Der Grad der Beteiligung

(Integrationsgrad) des Dienstnehmers (Service Provider oder Integrator) ist bei der Erstellung

individualisierter Marktleistungen höher, da sie auf die individuellen Bedürfnisse des Dienst-

nehmers zugeschnitten sind.

Ausgangspunkt für die Gestaltung eines Geschäftsnetzwerks sind bestimmte Kundenprozes-

se, hinter denen in den meisten Fällen auch spezifische Kunden und Kundengruppen stehen.

Ausgewählte Kundenprozesse werden durch Service Integrators ganzheitlich unterstützt, wo-

bei ein Kundenprozess auch durch verschiedene Service Integrators unterstützt werden kann.

Bei Längsschnittbetrachtungen ist dies allgemein der Fall, da sich die Unterstützung oft auf

Kundenprozesse bezieht, die nur selten oder gar einmalig auftreten: Das Kundensegment

„wandert“ dann von einem prozessspezifischen Service Integrator zum Nächsten. Service

324 Vgl. Glossar in IMG (1997).


Integrators sowie Service Providers beziehen Leistungskomponenten von Shared Service

Providers, Exclusive Service Providers und Public Services. Dabei werden im Normalfall

mehrstufige Leistungsketten entstehen. Während Exclusive Service Provider nur einen oder

wenige Service Provider bzw. Service Integrators beliefern und deshalb unter Umständen aus

Effizienzgründen direkte Vernetzungen aufbauen, erfolgen alle anderen Vernetzungen im

Normalfall über eine gemeinsame, offene Kollaborationsinfrastruktur, genannt Business Col-

laboration Infrastructure (BCI).

Abbildung 34: Metamodell des Geschäftsnetzwerkmodells

An die Stelle einer Vielzahl bilateraler Vernetzungen zwischen Geschäftsmodellen tritt dann

jeweils nur ein einziger „Adapter“ zu dieser Kollaborationsinfrastruktur. Der direkte Zugriff

von Konsumenten auf Leistungskomponenten von Service Providers ist – sinnvollerweise

über die Kollaborationsinfrastruktur – möglich, wenn seitens der Konsumenten die Nutzung

eines Service Integrator nicht erwünscht ist oder wenn die zu unterstützenden Prozesse so

spezifisch sind, dass eine individuelle Kombination von Leistungskomponenten unausweich-

lich ist.

4.1.2.2 Metamodell des Kundenprozessmodells

Der Kundenprozess beschreibt, welche Aktivitäten der Kunde durchführt und in welcher

Reihenfolge diese ablaufen. Für jede Kundenaktivität wird festgelegt, welche Serviceaktivi-

täten durchgeführt werden müssen, um die jeweilige Kundenaktivität zu unterstützen. Die

einzelnen Serviceaktivitäten sowie deren Reihenfolge werden durch den Serviceprozess be-

schrieben. Das Kundenprozessmodell definiert zudem für jede Serviceaktivität, ob diese von

dem jeweiligen Unternehmen bzw. der jeweiligen Geschäftseinheit selbst erbracht oder

fremdbezogen wird. Zusätzlich werden in dem Kundenprozessmodell geeignete Bündelungen


und Vertriebskanäle identifiziert, die sich auf die eigenerstellten Teilleistungen, aber auch auf

zu integrierende Fremdleistungen beziehen.

Abbildung 35: Metamodell des Kundenprozessmodells

Die Modellierung des Kundenprozesses und des korrespondierenden Serviceprozesses ermög-

licht die systematische Planung der Leistungs- und Informationsflüsse zwischen Kunde, in-

ternen Geschäftseinheiten sowie einzubindenden Partnern.325 Zudem bietet die umfassende

Unterstützung eines Kundenprozesses und damit eines Kundenbedürfnisses eine Chance zur

Wettbewerbsdifferenzierung gegenüber Konkurrenten sowie zur Steigerung der Kundenloya-

lität.

4.1.2.3 Metamodell des Leistungsmodells

Das Leistungsmodell beschreibt die strategische Ausrichtung eines Unternehmens bzw. einer

Geschäftseinheit in Bezug auf die Ausprägung bestimmter vorgefundener (z.B. Markt) und

gestaltbarer (z.B. Produkte, Organisation) Dimensionen.326 Eine Dimension beschreibt einen

Teilaspekt der strategischen Ausrichtung eines Unternehmens oder einer Geschäftseinheit.

Jede Dimension besitzt eine Menge möglicher (meist branchenspezifischer) Ausprägungen.

Dadurch steht eine Beschreibungsstruktur für die strategische Ausrichtung von Unternehmen

oder Geschäftseinheiten zur Verfügung, die gegenüber der meist nur als Fliesstext vorliegen-

den konventionellen Beschreibungen den Vorteil hat, die strategische Ausrichtung systema-

tisch kommunizieren und standardisiert dokumentieren zu können. Darüber hinaus ist es mög-

lich, auf Grundlage einer ausreichend grossen Fallbasis Abhängigkeiten und Typisierungen zu

ermitteln. Während Abhängigkeitsregeln helfen, bei der Strategiebildung auf mögliche Wi-

dersprüche aufmerksam zu machen, kann Typisierung dazu benutzt werden, den weiter oben

325 Vgl. Heinrich (2002b), S. 87-88.

326 Vgl. Heinrich (2000), S. 11.


beschriebenen Rollen in Geschäftsnetzwerken bestimmte Dimensionen und Ausprägungen im

Sinne von Referenzmodellen zuzuordnen. Während beispielsweise die Spezifikation von

Zielkundengruppen oder Vertriebskanal-Zuordnungen für Service Integrators einen hohen

Stellenwert hat und in der Beschreibung von deren strategischer Ausrichtung besonders de-

tailliert erfolgen sollte, ist aus Sicht von Exclusive Service Providers eher die Spezifikation

von Produktionsverfahren oder Ressourcenmanagement von Interesse.

Abbildung 36: Metamodell des Leistungsmodells

Das Leistungsmodell soll nicht nur die fokussierten Märkte und das Wettbewerbsverhalten

repräsentieren (Aussensicht), sondern auch die internen Abläufe, Strukturen und Potenziale

der Organisation abbilden (Innensicht). Die beiden Sichten auf das Leistungsmodell können

wie folgt strukturiert werden:327

• Aussensicht („Leistungsangebotsmodell“): Die Aussensicht bildet ab, auf welchem Markt

die Bezugseinheit tätig sein will, d.h. mit welchen Produkttypen/Prozessklassen das Un-

ternehmen den Markt „bedienen“ will und welche Endkunden in welchen Regionen letzt-

endlich angesprochen werden sollen. Dabei sind die Produkttypen/Prozessklassen nicht al-

leine nach ihrer Art zu unterscheiden (Kredit, Anlage usw.), sondern auch dahingehend,

ob sie einzeln, in einem Bündel oder ausgerichtet an den Kundenprozessen angeboten

werden. Abhängig davon sind auch die Festlegung der Marke sowie die Auswahl des Ver-

triebswegs und des Vertriebskonzepts. In der Aussensicht wird somit im Wesentlichen der

Marktauftritt der Bezugseinheit bestimmt. Typische Dimensionen für die Spezifikation

der jeweiligen Merkmale sind Land/Region, Kunde, Kernprodukte und Leistungen, Marke

und Vertrieb.

• Innensicht („Leistungserstellungsmodell“): Die Innensicht bildet die Kompetenzen und

die Form der Faktorkombination einer Bezugseinheit ab. Orientierung für eine Spezifika-

tion bieten dabei die Ziele und Erfolgsfaktoren. Darüber hinaus sind Kooperationen und

327 Vgl. im Folgenden Heinrich/Winter (2004).


die Organisationsstruktur (eher zentrale oder eher dezentrale Ausrichtung) zu berücksich-

tigen. Typische Dimensionen für die Spezifikation der jeweiligen Merkmale sind bei-

spielsweise Kompetenzfelder, Ziele/ Erfolgsfaktoren, Kooperationen und Organisations-

struktur.

4.1.2.4 Metamodell des Zielsystems

Das Zielsystem eines Unternehmens bzw. einer Geschäftseinheit bildet die Grundlage für die

nachfolgende Spezifikation der zur Prozessgestaltung benötigten Führungsgrössen und Er-

folgsfaktoren. Es kann beispielsweise anhand der Balanced Scorecard (BSC)328 beschrieben

werden. Diese hat sich in den letzten Jahren als Managementmethode für die strategische Un-

ternehmensführung weitgehend etabliert329 und wird deshalb auch in der vorliegenden Arbeit

verwendet. Die BSC ist ein Kennzahlen- und Managementsystem, bei dem eine rein finanziel-

le Betrachtung des Unternehmens um die Berücksichtigung immaterieller Werte erweitert

wird.330 Die Strategie wird dabei durch strategische Ziele und Erfolgsfaktoren abgebildet und

mittels monetärer und nicht monetärer Kennzahlen messbar gemacht. Die BSC systematisiert

die zentralen strategischen Erfolgsfaktoren eines Unternehmens in die vier Perspektiven Fi-

nanzen, Kunden, Prozesse und Potenziale. Diese werden durch die Bildung perspektivenori-

entierter Kennzahlen operationalisiert. Abbildung 37 zeigt das Metamodell des Zielsystems

(BSC).

Ein kritischer Erfolgsfaktor (KEF) bezeichnet eines der wenigen Merkmale, die den Erfolg

eines Unternehmens massgeblich beeinflussen. Die kritischen Erfolgsfaktoren konkretisieren

die Unternehmensziele und helfen damit der Unternehmensführung, sich auf die wesentli-

chen Aspekte zur Erreichung der Unternehmensziele zu konzentrieren.331 Eine Massnahme

bezeichnet eine Tätigkeit zur Realisierung eines bestimmten Zieles. Dabei kann es sich bei-

spielsweise um ein Vorhaben, strategisches Projekt oder Programm handeln. Die Durchfüh-

rung einer Massnahme liegt in der Verantwortung einer bestimmten Organisationseinheit.

Jeder KEF wird durch eine oder mehrere Kennzahlen operationalisiert. Eine Kennzahl kann

als Zahl betrachtet werden, die einen quantitativ erfassbaren Sachverhalt in konzentrierter

Form als Information erfasst.332 Das Ziel von Kennzahlen ist es, komplexe Sachverhalte in

Unternehmen in relativ einfacher Form darzustellen. Dabei steht insbesondere der Aspekt der

optimalen Aggregation im Vordergrund, da zum einen die Anzahl der Kennzahlen möglichst

gering und sie selbst möglichst einfach gehalten werden sollten. Andererseits sollten sie aber

auch den realen Sachverhalt möglichst originalgetreu und unverfälscht wiedergeben.333 Diese


329 Vgl. hierzu z.B. Horváth&Partners (2005).

330 Vgl. Böh/Meyer (2004), S. 106.

331 In Anlehnung an die Definition eines KEF des Prozessmanagements. Vgl. Brecht (2002), S. 159.

332 Vgl. Reichmann (1997), S. 19.

333 Vgl. Harengel (2000), S. 34.


Originaltreue kann nur begrenzt erreicht werden, da die Ermittlung der Kennzahlen von der

Genauigkeit der Messmethode und von stochastischen Schwankungen abhängig ist.334 Aus-

serdem können einzelne Kennzahlen unterschiedlich interpretiert werden, da weitere Informa-

tionen für eine genaue Beurteilung des Sachverhalts fehlen.335

Zielsystem

Perspektive

Ziel Erfolgsfaktor Kennzahl

StrategieOrganisa-

tionseinheit

Massnahme

operatio-

nalisiert

1 *

ist zugeordnet

konkre-

tisiert

verantwortet

hat

realisiert

definiert

**

*

1

1 1

*

*

*

* *

1

ist übergeordnet*

*

ist über-

geordnet

*

*

Strategisches

ProjektVorhabenProgramm

Abbildung 37: Metamodell des Zielsystems (BSC)

Diese Nachteile einzelner Kennzahlen können teilweise durch Kennzahlensysteme behoben

werden. Unter einem Kennzahlensystem versteht man eine geordnete Gesamtheit von Kenn-

zahlen, die in sachlich sinnvoller Beziehung zueinander stehen und somit einen bestimmten

Sachverhalt vollständig beschreiben sollen.336

Nach KAPLAN/NORTON ist die Balanced Scorecard (BSC) ein Kennzahlensystem, bestehend

aus finanziellen und nichtfinanziellen Grössen, das die verschiedenen Dimensionen (Kunden,

Finanzen, interne Prozesse, Potenzial) eines Unternehmens gleichberechtigt nebeneinander

darstellen soll.337 Die BSC stellt eine Weiterentwicklung konventioneller Kennzahlensysteme

dar (z.B. des DuPont- oder ZVEI-Kennzahlensystems). Durch die BSC sollen alle Mitarbeiter

und Manager motiviert und in die Lage versetzt werden, die Unternehmensstrategie erfolg-

reich umzusetzen.338 Die BSC wird deshalb oftmals mit einem Flugzeug-Cockpit verglichen,

in dem der Pilot (Manager) einen Überblick über die relevanten Informationen zur Steuerung

des Flugzeugs (Unternehmens) angezeigt bekommt.339

334 Vgl. Harengel (2000), S. 35.

335 Vgl. Weber et al. (1997), S. 442.

336 Vgl. Weber et al. (1997), S. 35f.


338 Vgl. Kaplan/Norton (1997), S. 7f.

339 Vgl. Kaplan/Norton (1997), S. 1.


KAPLAN/NORTON schlagen vier wesentliche Dimensionen für die Systematisierung der zentra-

len Erfolgsfaktoren und Kennzahlen eines Unternehmens bzw. einer Geschäftseinheit vor:340

• Die finanzielle Perspektive enthält monetäre Kennzahlen, um den wirtschaftlichen Erfolg

des Unternehmens bzw. der Geschäftseinheit abzubilden. Im Mittelpunkt stehen finanz-

wirtschaftliche Messgrössen, basierend auf vergangenheitsorientierten Daten, wie z.B.

Rentabilität und Liquidität. Indirekt geben diese Daten Aufschluss darüber, ob die Unter-

nehmensstrategie und die daraus abgeleiteten Massnahmen erfolgreich waren oder nicht.

• Die Markt-/Kundenperspektive identifiziert Kunden- und Marktsegmente, die für das

Unternehmen bzw. die Geschäftseinheit wichtig sind. Entsprechend dieser Analyse kön-

nen darauf aufbauend Kennzahlen für die Kundenzufriedenheit, die Anzahl der Kunden-

akquisitionen, die Kundenrentabilität sowie für Gewinn- und Marktanteile festgelegt wer-

den. Dadurch soll sichergestellt werden, dass das Unternehmen die Möglichkeit hat, sich

besser am Markt zu orientieren.

• Die Geschäftsprozessperspektive konzentriert sich auf Leistungsprozesse zur Erreichung

der in der Finanz- und Markt-/Kundenperspektive definierten Ziele. Zielsetzung in diesem

Bereich muss es sein, kritische Prozesse anhand zweier Einflussfaktoren zu identifizieren:

Kundenbedürfnisse und Erwartungen der Anteilseigner. Ausgehend von dieser Analyse

müssen auf diese Prozesse Verbesserungsschwerpunkte gelegt werden. Dies beinhaltet

nicht nur die existierenden Prozesse, vielmehr fördert die BSC auch die Entwicklung neu-

er Prozesse. Die BSC erweitert ausserdem den Begriff der Wertkette in der Hinsicht, dass

auch der Innovationsprozess völlig neuer Produkte und Dienstleistungen integriert wird.

Somit soll sichergestellt werden, dass auch ein langfristiger Aspekt der Wertschöpfung

berücksichtigt wird.

• Die Lern- und Entwicklungsperspektive identifiziert und schafft eine Infrastruktur im

Unternehmen, die ein kontinuierliches Wachstum und Lernen ermöglicht. Diese Entwick-

lung betrifft drei Bereiche im Unternehmen: Menschen, Systeme und Unternehmenskul-

tur. Es muss darauf geachtet werden, dass Wachstum und Lernen dieser drei Elemente

aufeinander abgestimmt sind.

Mit der Balanced Scorecard wird versucht, jede Kennzahl auf der Basis einer Ursache-

Wirkungskette mit monetären und nicht-monetären Zielgrössen zu verbinden.

4.1.2.5 Definition der Metaentitätstypen auf Strategieebene

In der folgenden Tabelle 8 sind die im vorhergehenden Abschnitt erwähnten Metaentitätsty-

pen sowie deren Beziehungen genauer definiert.

340 Vgl. Kaplan/Norton (1997), S. 24f. Die von Kaplan und Norton vorgeschlagenen Dimensionen der BSC

sind nur Anhaltspunkte. In den letzten Jahren haben sich in einigen Unternehmen weitere Dimensionen etabliert, wie beispielsweise die ökologische Perspektive.


Abhängigkeitsregel

Definition Eine Abhängigkeitsregel definiert eine direkte Abhängigkeit zwischen zwei oder mehreren Dimensionen des Leistungsmodells. Sie kann beispielsweise als Wenn-Dann-Regel formuliert sein.

Beziehungen zu Dimension Eine Abhängigkeitsregel besteht zwischen zwei oder mehreren Dimensionen.

Business Collaboration Infrastructure (BCI)

Definition

Die BCI ist definiert als multilaterale Kooperationsinfrastruktur, die die Herstellung einer technischen n:m-Konnektivität ermöglicht und von Unternehmen bzw. Ge-schäftseinheiten für den übergreifenden Informations- oder Leistungsaustausch inner-

halb des Geschäftsnetzwerkes eingesetzt wird.341

Beziehungen zu Rolle Die BCI wird von zwei oder mehreren Rollen im Geschäfts-netzwerk verwendet.

Dimension

Definition

Eine Dimension beschreibt einen Teilaspekt der strategischen Ausrichtung eines Un-ternehmens oder einer Geschäftseinheit. Typische Dimensionen für die Spezifikation der strategischen Ausrichtung sind z.B. Region, Kernprodukte und -leistungen, Mar-

ke, Vertrieb, Kompetenzfelder und Erfolgsfaktoren.342

Ausprägung Eine Dimension hat eine oder mehrere Ausprägung/en.

Rolle Eine Dimension beschreibt eine oder mehrere Rolle/n. Beziehungen zu

Abhängigkeitsregel Zwischen zwei oder mehreren Dimensionen kann/können kei-ne, eine oder mehrere Abhängigkeitsregel/n definiert sein.

Dimensionsausprägung

Definition Eine Dimensionsausprägung beschreibt ein konkretes, für eine Dimension festgeleg-

tes Merkmal.343

Dimension Eine Dimensionsausprägung ist genau einer Dimension zuge-ordnet.

Beziehungen zu Leistungs-spezifikation

Eine Dimensionsausprägung ist Teil einer oder mehrerer Leis-tungsspezifikation/en.

Exclusive Service Provider (ESP)

Definition

Ein ESP erzeugt Leistungskomponenten für andere Service Provider oder Service Integrators. Im Gegensatz zu Shared Service Providers werden aber nicht grosse Mengen von Leistungskomponenten für mehrere Abnehmer produziert, sondern spe-zifischere Leistungskomponenten für einen oder wenige Abnehmer und damit in eher kleineren Mengen. An die Stelle von Kunden- bzw. Kundenprozesskenntnis (SI) bzw. Kostenführerschaft (SSP) treten als Haupt-Erfolgsfaktor Schnelligkeit, Flexibilität

sowie spezifische Prozesskompetenzen.344

Beziehungen zu Marktleistung Ein ESP bezieht Marktleistungen von anderen Service Provi-ders und erbringt individualisierte Marktleistungen für Service Integrators oder Service Providers.

341 Vgl. Winter (2003c), S. 54.



344 Vgl. Winter (2003c), S. 53.


Kennzahl

Definition Eine Kennzahl dient der Objektivierung und Visualisierung von Unternehmenszielen und Verbesserungsbemühungen. Sie aggregiert mehrere in einem Unternehmen vor-

handene Zahlen zu einem Wert.345

Erfolgsfaktor Eine Kennzahl operationalisiert genau einen Erfolgsfaktor. Beziehungen zu

Perspektive Eine Kennzahl ist genau einer Perspektive zugeordnet.

Kontaktpräferenz

Definition Die Kontaktpräferenz beschreibt die Art und Weise, in der der Kunde oder eine be-stimmte Kundengruppe bevorzugt mit dem Unternehmen in Kontakt tritt.

Beziehungen zu Kunde Eine Kontaktpräferenz ist einem oder mehreren Kunden zuge-ordnet.

Kritischer Erfolgsfaktor (KEF)

Definition Ein kritischer Erfolgsfaktor (KEF) bezeichnet eines der wenigen Merkmale, die den

Erfolg eines Unternehmens ausmachen.346

Kennzahl Ein KEF wird durch keine, eine oder mehrere Kennzahl/en operationalisiert.

Ziel Ein KEF ist für die Erreichung eines oder mehrerer Unterneh-mensziels/-ziele erfolgsentscheidend.

Beziehungen zu

Perspektive Ein KEF ist genau einer Perspektive zugeordnet.

Kunde

Definition Ein Kunde bezeichnet eine Person oder Organisation, die Produkte oder Leistungen eines Unternehmens bzw. einer Geschäftseinheit bezieht.

Kundensegment Ein Kunde gehört einem oder mehreren Kundensegment/en an.

Kundenprozess Ein Kunde hat keinen, einen oder mehrere Kundenprozess/e. Beziehungen zu

Kontaktpräferenz Ein Kunde hat eine oder mehrere Kontaktpräferenz/en.

Kundenaktivität

Definition Eine Kundenaktivität stellt einen Teilschritt innerhalb des gesamten Kundenprozesses

dar.347

Serviceaktivität Eine Kundenaktivität bedarf einer oder mehrerer Serviceaktivi-tät/en. Beziehungen zu

Kundenprozess Eine Kundenaktivität ist Teil eines Kundenprozesses.

Kundenprozess

Definition Als Kundenprozess wird die Gesamtheit der Teilschritte und deren Reihenfolge be-zeichnet, die einem Kunden zugeordnet werden können.

Kunde Ein Kundenprozess ist einem oder mehreren Kunden zugeord-net.

Marktleistung Ein Kundenprozess bedarf einer oder mehrerer Leistung/en. Beziehungen zu

Kundenaktivität Ein Kundenprozess besteht aus einer oder mehreren Kundenak-tivität/en

345 Vgl. Reichmann (1997), S. 19.

346 In Anlehnung an die Definition eines KEF des Prozessmanagements. Vgl. Brecht (2002), S. 159.



Kundensegment

Definition Wird eine heterogene Gesamtmenge von Kunden in disjunkte, homogene Mengen aufgeteilt, so spricht man von Kundensegmenten. Die Untergliederung kann dabei unter verschiedenen Gesichtspunkten erfolgen.

Beziehungen zu Kunde Ein Kundensegment umfasst einen oder mehrere Kunden.

Leistungsspezifikation

Definition Eine Leistungsspezifikation beschreibt eine oder mehrere Marktleistungen, die von einem Unternehmen bzw. einer Geschäftseinheit angeboten werden.

Dimensionsausprä-gung

Eine Leistungsspezifikation wird durch eine oder mehrere Dimensionsausprägung/en definiert.

Marktleistung Eine Leistungsspezifikation spezifiziert eine oder mehrere Marktleistung/en.

Beziehungen zu

Prozessleistung Eine Leistungsspezifikation beeinflusst die Definition einer oder mehrerer Prozessleistung/en auf Organisationsebene.

Marktleistung

Definition

Eine Marktleistung ist ein Produkt oder eine Dienstleistung, die ein Unternehmen oder eine Geschäftseinheit am Markt bzw. im Geschäftsnetzwerk anbietet. Sie wird

durch das Zusammenwirken eines Bündels von Leistungen erbracht.348

Eine Markt-leistung kann standardisiert oder individualisiert sein.

Prozessleistung Eine Marktleistung umfasst eine oder mehrere Prozessleis-tung/en auf Organisationsebene.

Kundenprozess Eine Marktleistung wird für die Unterstützung keines, eines oder mehrerer Kundenprozesse/s verwendet.

Rolle Eine Marktleistung wird von einem oder mehreren Unterneh-men bzw. einer oder mehreren Geschäftseinheit/en im Ge-schäftsnetzwerk verwendet bzw. erbracht.

Serviceprozess Eine Marktleistung ist Teil keines, eines oder mehrerer Servi-ceprozesse/s.

Beziehungen zu

Leistungsspezifika-tion

Eine Marktleistung wird durch eine oder mehrere Leistungs-spezifikation/en spezifiziert.

Massnahme

Definition Eine Massnahme bezeichnet eine Tätigkeit zur Realisierung eines bestimmten Zieles.

Ziel Eine Massnahme realisiert ein oder mehrere Ziel/e.

Beziehungen zu OE

Eine Massnahme wird von einer oder mehreren Organisations-einheit/en durchgeführt.

Organisationseinheit (OE)

Definition

Eine Organisationseinheit ist ein eigenständiger, permanenter Teil der organisatori-schen Struktur eines Unternehmens (z.B. Abteilung, Unternehmensbereich, Stelle).

Sie kann mehr oder weniger aggregiert sein.349

Neben weiteren Organisationseinhei-ten und Mitarbeitern umfasst sie auch Geschäftsobjekte. Eine Organisationseinheit kann auf Strategieebene eine Geschäftseinheit oder das Unternehmen selbst darstel-len.

Beziehungen zu Rolle Eine OE nimmt eine oder mehrere Rolle/n im Geschäftsnetz-werk ein.




Massnahme Eine OE ist für die Durchführung keiner, einer oder mehrerer Massnahm/en verantwortlich.

Strategie Eine OE verfolgt eine bestimmte Strategie.

Serviceaktivität Eine OE ist für die Durchführung keiner, einer, oder mehrerer Serviceaktivität/en verantwortlich.

Geschäftsprozess Eine OE ist für einen oder mehrere Geschäftsprozess/e auf Organisationsebene verantwortlich.

Perspektive

Definition

Der Erfolg eines Unternehmens bei der Strategieumsetzung wird anhand von vier möglichst gleich gewichteten Perspektiven beurteilt. Die zentralen strategischen Er-folgsfaktoren eines Unternehmens werden in diese Perspektiven systematisiert und anschliessend durch die Bildung perspektivenorientierter Kennzahlen operationali-

siert.350

KEF Eine Perspektive umfasst einen oder mehrere Erfolgsfaktor/en.

Kennzahl Eine Perspektive umfasst eine oder mehrere Kennzahl/en. Beziehungen zu

Ziel Eine Perspektive umfasst ein oder mehrere Ziel/e.

Public Service (PS)

Definition

Ein PS stellt Leistungskomponenten bereit, die keinen spezifischen fachlichen Cha-rakter haben, aber zur Abwicklung der Leistungserstellung unverzichtbar sind. Im engeren Sinne handelt es sich dabei um Dienste mit quasi-hoheitlicher Funktion, wie z.B. Zertifizierung oder Authentifizierung. Im weiteren Sinne können auch andere elektronische Dienste, wie z.B. Informationsdienste, Applikationsbetrieb, Katalog-dienste, Zahlungsabwicklung und Logistikabwicklung, darunter subsumiert wer-

den.351

Beziehungen zu Marktleistung Ein Public Service erbringt eine oder mehrere standardisierte Marktleistung/en.

Rolle (Geschäftsnetzwerk)

Definition Eine Rolle definiert einen kompetenzbasierten Typ von Organisationseinheit (Unter-

nehmen oder Geschäftseinheit) im Geschäftsnetzwerk. 352

Es handelt sich dabei um eine abstrakte Klasse, von der keine Objekte erzeugt werden können.

BCI Eine Rolle kann die BCI nutzen.

Dimension Eine Rolle wird durch eine oder mehrere Dimension/en be-schrieben.

Marktleistung Eine Rolle verwendet oder erzeugt eine oder mehrere Markt-leistung/en.

Beziehungen zu

OE Eine Rolle wird durch ein oder mehrere Unternehmen bzw. eine oder mehrere Geschäftseinheiten wahrgenommen.

Serviceaktivität

Definition Eine Serviceaktivität stellt einen Teilschritt innerhalb des gesamten Serviceprozesses dar. Für jede Serviceaktivität kann festgelegt werden, ob diese selbst oder durch einen

Kooperationspartner im Geschäftsnetzwerk durchführt werden soll.353


351 Vgl. Winter (2003c), S. 53.

352 Vgl. Winter (2003c), S. 53.

353 Vgl. Heinrich (2002b), S. 87.


Kundenaktivität Eine Serviceaktivität unterstützt eine oder mehrere Kundenak-tivität/en.

Serviceprozess Eine Serviceaktivität ist Teil eines Serviceprozesses oder mehrerer Serviceprozesse.

Geschäftsprozess Eine Serviceaktivität wird durch einen oder mehrere Ge-schäftsprozess/e (bzw. dessen Aktivitäten) auf Organisations-ebene unterstützt.

Beziehungen zu

OE Eine Serviceaktivität ist genau einer (internen oder externen) Organisationseinheit (Unternehmen bzw. Geschäftseinheit) zugeordnet.

Service Integrator (SI)

Definition Ein SI integriert Leistungskomponenten, um damit einen bestimmten Kundenprozess ganzheitlich zu unterstützen. Kernkompetenz des Service Integrator ist deshalb die

umfassende Kenntnis von Kundenbedürfnissen bzw. Kundenprozessen.354

Beziehungen zu Marktleistung Ein SI bezieht Marktleistungen von Service Providern und erbringt Marktleistungen für einen bestimmten Kundenpro-zess.

Serviceprozess

Definition Ein Serviceprozess beschreibt die einzelnen Serviceaktivitäten sowie deren Reihen-folge, die ein Unternehmen oder eine Geschäftseinheit durchführen muss, um einen

bestimmten Kundenprozess und dessen Kundenaktivitäten zu unterstützen.355

Serviceaktivität Ein Serviceprozess besteht aus einer oder mehreren Serviceak-tivität/en.

Beziehungen zu

Marktleistung Ein Serviceprozess umfasst eine oder mehrere Marktleis-tung/en

Shared Service Provider (SSP)

Definition Ein SSP produziert Leistungskomponenten für viele andere Service Providers oder Service Integrators in grossen Mengen. Haupterfolgsfaktoren des SSP sind folglich

die Kostenführerschaft und effiziente Leistungserstellung.356

Beziehungen zu Marktleistung Ein SSP bezieht Leistungen von anderen Service Providers und erbringt standardisierte Leistungen für Service Integrators oder Service Providers.

Strategie

Definition Eine Strategie beschreibt die geplanten Verhaltensweisen eines Unternehmens oder einer Geschäftseinheit zur Erreichung ihrer Ziele. Sie legt somit fest, auf welche Art

und Weise ein mittelfristiges oder langfristiges Ziel erreicht werden soll.357

Ziel Eine Strategie definiert ein oder mehrere Ziel/e.

Beziehungen zu OE

Eine Strategie ist genau einer Organisationseinheit zugeord-net.

354 Vgl. Winter (2003c), S. 53.

355 Vgl. Heinrich (2002b), S. 85.

356 Vgl. Winter (2003c), S. 53.

357 Vgl. hierzu z.B. Mintzberg (1987).


Vertriebsweg

Definition Der Vertriebsweg kennzeichnet den Weg, auf dem Produkte oder Dienstleistungen zum Kunden gelangen. Typische Beispiele für Vertriebswege sind Filiale, Internet und Versandhandel.

Beziehungen zu Serviceprozess Ein Vertriebsweg kann einen oder mehrere Serviceprozess/e beeinflussen.

Ziel

Definition Das Ziel definiert ein bestimmtes Ergebnis, das in der Zukunft erreicht werden soll.

KEF Ein Ziel wird durch einen oder mehrere Erfolgsfaktor/en kon-kretisiert.

Perspektive Ein Ziel ist genau einer Perspektive zugeordnet. Beziehungen

Strategie Ein Ziel wird von einer Strategie definiert.

Tabelle 8: Metaentitätstypen der Strategieebene

4.1.2.6 Festlegung der verwendeten Symbole auf Strategieebene

Die folgende Tabelle 9 zeigt die für die zuvor definierten Metaentitäts- und Beziehungstypen

verwendeten Notationselemente (Symbole).

Symbole der Strategieebene

BCI Dimension Dimensionsausprägung

Kennzahl Exclusive Service Provider Kritischer Erfolgsfaktor

Kunde Kundenaktivität Kundenprozess

Kundenaktivität

Kundensegment Massnahme Organisationseinheit

Perspektive Public Service Serviceaktivität

Perspektive

Serviceaktivität


Service Integrator Serviceprozess Shared Service Provider

Strategie Ziel

bezieht Leistung (direkt) (von Rolle zu Rolle)

bezieht Leistung (über BCI) (von Rolle zu Rolle)

gehört zu (von Kunde zu Kundensegment)

bedarf (von Kundenakt. zu Serviceakt.)

beeinflusst (von Erfolgsfaktor zu Strategie)

hat (von Ziel zu Erfolgsfaktor)

Tabelle 9: Symbole der Strategieebene

Die Notationselemente sind getrennt von den Metaentitäts- und Beziehungstypen definiert

und stellen lediglich einen Vorschlag dar. Dadurch ist eine Anpassung an ein spezifisches

Umfeld und an individuelle Präferenzen möglich.

Für die Metaentitätstypen „Marktleistung“, „Leistungsspezifikation“, „Kontaktpräferenz“ und

„Vertriebsweg“ wurden keine eigenen Symbole definiert, da sie durch die generischen

Metaentitätstypen „Dimension“ und „Dimensionsausprägung“ repräsentiert werden können.

Der Metaentitätstyp „Rolle (Geschäftsnetzwerk)“ stellt eine abstrakte Klasse im Sinne der

UML-Spezifikation dar. Von einer abstrakten Klasse können nicht direkt Objekte erzeugt

werden. Sie besitzt somit kein Notationselement. Durch Vererbung können allerdings von

einer abstrakten Klasse Unterklassen abgeleitet werden. Objekte werden dann von den

Unterklassen („Service Integrator“, „Shared Service Provider“ etc.) erzeugt.

Bei Beziehungstypen, denen kein Notationselement zugeordnet ist, handelt es sich entweder

um eine modellübergreifende Beziehung oder um eine Aggregationsbeziehung, die in Form

einer Schachtelung von Symbolen dargestellt wird (z.B. die Beziehung zwischen

„Serviceprozess“ und „Serviceaktivität“).

4.2 Modellierung auf Organisationsebene

Die Gestaltung der Organisationsebene stellt das Bindeglied zwischen Strategieentwicklung

und Systementwicklung dar (vgl. Abschnitt 2.3.2). Wesentliche Anforderungen an einen An-

satz für die Modellierung der Organisationsebene sind:358

358 Vgl. Winter (2004a), Kühn/Karagiannis (2005), S. 1495 und Abschnitt 2.3.2.


• Abbildung einer Übersicht der Leistungs-, Unterstützungs- und Führungsprozesse eines

Unternehmens bzw. einer Geschäftseinheit,

• transparente Definition der Geschäftsprozesse anhand des Kontroll- und Informationsflus-

ses,

• Beschreibung der in einem Geschäftsprozess bearbeiteten Objekte, eingesetzten Ressour-

cen sowie beteiligten Rollen bzw. Organisationseinheiten und

• Sicherstellung der Führbarkeit.

Für die Identifikation von Schlüsselelementen auf der Organisationsebene sowie deren Zu-

sammenhänge bieten die in dieser Arbeit bewerteten Methoden zur Unternehmensmodellie-

rung (vgl. Abschnitt 3.2) bereits einige wesentliche Anhaltspunkte und Konzepte. Zudem

wird auf domänenspezifische Ansätze/Methoden des Prozessmanagements und zur Gestaltung

der Aufbauorganisation zurückgegriffen (vgl. Tabelle 7).359

Auf der Organisationsebene können folgende Ergebnisdokumenttypen unterschieden werden:

• Die Prozesslandkarte gibt einen Überblick über die relevanten Prozesse sowie deren

Leistungs- und Informationsbeziehungen zu anderen Prozessen innerhalb und ausserhalb

des Unternehmens bzw. der Geschäftseinheit.360

• Die Prozessvision beschreibt die grundlegenden Prinzipien zur langfristigen Gestaltung

eines bestimmten Prozesses.361

• Die Prozessführung bestimmt die Steuerung des Prozesses. Sie plant Soll-Werte, erhebt

Ist-Werte, legt Erfolgsfaktoren und Führungsgrössen fest und löst notwendige Massnah-

men aus.362 Ziel der Prozessführung ist die Erhöhung der Effizienz und Effektivität des

Prozesses durch permanente Weiterentwicklung.363

• Die Ablauforganisation bildet die konkreten Aktivitäten eines Prozesses sowie ihre Ab-

folge und ihre Zuordnung zu den Rollenträgern ab.364

• Die Aufbauorganisation beschreibt die organisatorischen Rollenträger365 eines Unter-

nehmens mit den zwischen ihnen bestehenden Kommunikations- und Weisungsbeziehun-

gen.366

359 Zur Identifikation von wesentlichen Metaentitätstypen der Organisationsebene wird primär auf folgende

Quellen zurückgegriffen: Österle (1995), Scheer (2001), Brecht (2002), IMG (1997), Rosemann/zur Mühlen (1997).

360 Vgl. Ergebnisse in IMG (1997).

361 Vgl. Techniken in IMG (1997).

362 Vgl. Österle (1995), S. 54.

363 Vgl. Ergebnisse IMG (1997).

364 Vgl. hierzu die Modellierung der Steuerungssicht in Scheer (2001).


• Die Informationslandkarte identifiziert die in einem Unternehmen bzw. einer Ge-

schäftseinheit zur Verfügung stehenden Informationen und stellt diese aus verschiedenen

Blickwinkeln dar.367


Das Vorgehensmodell zur Gestaltung der Organisationsebene basiert in Teilen auf der Me-

thode PROMET-BPR.368 Diese dient dazu, Prozesse in Unternehmen zu identifizieren, zu

verbessern und neu zu gestalten. Sie besteht auf Level 1 aus sechs wesentlichen Aktivitäten

(vgl. Abbildung 38).

Abbildung 38: Vorgehensmodell auf Organisationsebene (Level 1)

Im ersten Schritt wird eine Prozesslandkarte entworfen. Die Zielsetzung einer Prozessland-

karte ist es, Notwendigkeiten, bestehende Abhängigkeiten und Schnittstellen näher darzule-

gen. Dabei sind unter dem Begriff Notwendigkeiten die Elemente einer Organisation zu ver-

stehen, welche unverzichtbar für ein Bestehen am Markt sind (z. B. F&E, Personalmanage-

ment). Die Abhängigkeiten und Schnittstellen sollen dabei den Zusammenhang und das Zu-

sammenspiel der Prozesse verdeutlichen.369 Die Prozesslandkarte gibt somit einen Überblick

über die wettbewerbsentscheidenden Prozesse des eigenen Unternehmens, die wichtigsten

365 Im folgenden bezeichnet der Oberbegriff organisatorischer Rollenträger in Anlehnung an die Definition

eines organisatorischen Konstrukts nach ROSEMANN/ZUR MÜHLEN die Generalisierung von Rolle, Stelle, Stellentyp, Person und Organisationseinheit (vgl. Rosemann/zur Mühlen (1997)).

366 Vgl. Scheer (2001), S. 52.

367 Vgl. Strauch (2002), S. 180.

368 Vgl. IMG (1997) und http://www.promet-web.com.

369 Vgl. Zellner (2003), S. 275.


Prozesse der Geschäftspartner sowie den Leistungs- und Informationsaustausch zwischen den

Prozessen. Die Identifikation der Leistungsprozesse ist überwiegend an die Leistungen, die

das Unternehmen nach aussen abgibt, und an die ermittelten Produkt-/Marktkombinationen

des Unternehmens angelehnt. Neben den Leistungsprozessen müssen auch die zum kontinu-

ierlichen Betrieb der Prozesskoordination benötigten Unterstützungs- und Führungsprozesse

definiert werden.370 Wenn alle Prozesstypen definiert sind und deren Leistungsaustausch be-

stimmt ist, kann als Ergebnisdokument die Prozesslandkarte angefertigt werden.

Im zweiten Schritt „Prozessvision entwickeln“ wird die Prozessvision entwickelt und die Pro-

zessführung entworfen. Dabei soll die Suche nach neuen Lösungen für die Gestaltung von

Prozessabläufen im Unternehmen unterstützt werden.371 Es werden radikale Innovationen im

Rahmen eines Abgleichs zwischen Geschäftsstrategie und Prozess angestrebt, d.h. aus der

Geschäftsstrategie werden Vorgaben für die Prozesse abgeleitet, so dass ein realistischer und

langfristiger Rahmen für die Gestaltung von Prozessen geschaffen werden kann.372 Als Er-

gebnisdokument und Vorgabe für die Prozessgestaltung fungieren die Prozessgrundsätze.

Umgekehrt können aber auch die im Rahmen der Prozessvision identifizierten, neuen Ideen

bzw. Lösungen zu einer Anpassung von Teilen der Geschäftsstrategie führen.

Parallel zur Prozessvision kann die Prozessführung entwickelt werden. Die Prozessführung

bestimmt die Steuerung eines Prozesses. Sie plant Soll-Werte, erhebt Ist-Werte, legt Füh-

rungsgrössen fest und löst notwendige Massnahmen aus. Input erhält die Prozessführung aus

der Geschäftsstrategie in Form von Kennzahlen der BSC und aus Anregungen aus der Pro-

zessvision.373 Bei der Entwicklung der Prozessführung werden zunächst mögliche Erfolgsfak-

toren des Unternehmens bzw. der Geschäftseinheit (aus der BSC) und generelle Prozesser-

folgsfaktoren (z.B. Zeit, Qualität, Kosten, Flexibilität usw.) identifiziert und im Anschluss die

für den Unternehmenserfolg kritischen Faktoren benannt. Anschliessend erfolgt die Operatio-

nalisierung der Erfolgsfaktoren in Form von Führungsgrössen. Diese sind Indikatoren für die

Effektivität und Effizienz eines Prozesses und dienen der Planung und Beurteilung der Pro-

zessqualität.374 Auf Basis der Führungsgrössen werden Prozessziele (Zielwerte) festgelegt.

Diese repräsentieren den erwünschten Zustand (Sollwerte) des Prozesses. Die Aktivitäten und

Ergebnisse der kontinuierlichen Prozessführung sind mittels Berichtswesen (z.B. Prozesssta-

tusbericht) festzuhalten. Zielabweichungen und Schwachstellen sollen so dokumentiert und

eine graphische Übersicht über die Entwicklung der wichtigsten Führungsgrössen dargeboten

werden. Zuletzt sind noch die Aufgaben und Verantwortlichkeiten festzulegen.

370 Vgl. Techniken in IMG (1997), S. 36-38.

371 Vgl. Techniken in IMG (1997), S. 45-56.

372 Vgl. Hess (1996), S. 179.

373 Vgl. zur Prozessführung Techniken in IMG (1997), S. 89ff.

374 Zur Messung des Erfolgsfaktors „Geschwindigkeit“ sind z.B. die Durchlaufzeit, Liegezeit und Kontrollzeit

typische Führungsgrössen.


Nach dem Entwurf der Prozessführung kann die Ablaufplanung entwickelt werden. Die Auf-

gabe der Ablaufplanung besteht darin, sowohl die konkreten Funktionen bzw. Aktivitäten375

eines Prozesses und deren Abfolge als auch die Zuordnung der Aktivitäten zu den Rollenträ-

gern festzulegen. Ferner werden die für die einzelnen Aktivitäten verwendeten Applikationen

und Informationsobjekte festgelegt. Die Erstellung der Ablaufplanung basiert im Wesentli-

chen auf der EPK.376 Zunächst müssen die einzelnen Aktivitäten innerhalb eines Prozesses

identifiziert werden. Dabei sind diejenigen Aktivitäten aus der Geschäftsstrategie abzuleiten,

welche ein Unternehmen bzw. eine Geschäftseinheit effizient ausführen können muss. Die

Auslöser einer Aktivität (Ereignisse) werden zu diesem Zeitpunkt noch nicht definiert, son-

dern nur die logische Folge der einzelnen Aktivitäten.377 Anschliessend müssen die an den

jeweiligen Aktivitäten beteiligten Personen, Stellen oder Organisationseinheiten festgelegt

und den Aktivitäten zugeordnet werden. Sind mehrere Organisationseinheiten an einer Aktivi-

tät beteiligt, so kann durch Angabe der Art der Beteiligung genauer differenziert werden. Zu-

letzt können die für den Geschäftsablauf relevanten Ereignisse in das Modell aufgenommen

werden.378 Ereignisse lösen Nachrichten aus, welche wiederum Aktivitäten auslösen können.

Eine Verknüpfung von Ereignissen und Aktivitäten wird durch die Verwendung von Operato-

ren (UND, Inklusiv-Oder, Exklusiv-Oder) unterstützt. Als Ergebnisdokument erhält man eine

EPK, die den Ablauf eines bestimmten Prozesses darstellt.

Im nächsten Schritt können, ausgehend von den Prozessaktivitäten, die jeweiligen Rollenträ-

ger innerhalb der Ablaufplanung näher bestimmt und beschrieben werden. Diese stellen die

Basis für die Erstellung der Stellenanforderung bzw. der Stellenbeschreibung dar. Durch

Schaffung der beschriebenen Stellen, Stellentypen oder Organisationseinheiten und deren

Beziehungen wird die Aufbauorganisation konkretisiert und festgelegt. Diese stellt die Orga-

nisationseinheiten in hierarchische Beziehungen zueinander. Untergeordnete Organisations-

einheiten berichten an die ihnen übergeordnete Organisationseinheit und haben Weisungsbe-

fugnis gegenüber den ihnen untergeordneten Organisationseinheiten.

Im letzten Schritt wird eine Informationslandkarte erstellt. Die Informationslandkarte stellt

die in einem Unternehmen bzw. einer Geschäftseinheit zur Verfügung stehenden Informatio-

nen aus verschiedenen Blickwinkeln dar.379 Die einzelnen Informationen zur Erstellung der

Informationslandkarte werden durch eine Inventur des Berichtswesens gesammelt. Dazu müs-

sen die im Unternehmen zur Verfügung stehenden Berichte erfasst und ausgewertet werden.

375 Der Begriff Aktivität wird in dieser Arbeit synonym zu den Begriffen Funktion, Aufgabe, Vorgang und

Tätigkeit verwendet. 376

EPK steht für Ereignisgesteuerte Prozesskette. Vgl. im Folgenden Scheer (2001) und Scheer/Thomas (2005). Auf die Gründe zur Wahl dieser Modellierungstechnik wird in Abschnitt 4.2.2.5 genauer eingegangen.

377 Vgl. Scheer (2001), S. 31.

378 Vgl. Scheer (2001), S. 124.

379 Für eine detaillierte Beschreibung der einzelnen Schritte zur Erstellung der Informationslandkarte vgl.

Strauch (2002), Strauch/Winter (2002) und Winter/Strauch (2004).


4.2.2 Metamodell

Das Metamodell der Organisationsebene lässt sich entsprechend den bei der

Organisationsgestaltung erstellten Ergebnisdokumenttypen in die Sichten Prozesslandkarte,

Prozessvision, Ablaufplanung, Prozessführung, Aufbauorganisation und Informationsland-

karte einteilen.

4.2.2.1 Metamodell der Prozesslandkarte

Eine Prozesslandkarte ist eine grafische Übersicht über alle relevanten Prozesse mit ihren

Leistungs- und Informationsbeziehungen zu anderen Prozessen innerhalb und ausserhalb des

Unternehmens bzw. der Geschäftseinheit.380 Ein Prozess wird dabei als eine zusammengehö-

rende Abfolge von Unternehmensverrichtungen zum Zweck einer Leistungserstellung defi-

niert. Input bzw. Output eines Prozesses sind seine Leistungen, die von internen oder externen

Kunden angefordert und abgenommen werden.381

Jeder Prozess der Prozesslandkarte wird einem von drei Prozesstypen zugeordnet. Der Typ

Leistungsprozess beschreibt Prozesse zur Erstellung und Vermarktung der Produkte und

Dienstleistungen des Unternehmens. Die Leistungsprozesse werden auf dem Weg vom Er-

kennen eines Kundenbedürfnisses bis zu seiner Befriedigung durchlaufen.382 Dies beinhaltet

nicht nur die gesamte Auftragsabwicklung von der Anfrage über die Beschaffung und Pro-

duktion bis zur Auslieferung, sondern genauso die Akquisition der Kunden, die Pflege der

Kundenbeziehungen oder auch die Betreuung des Kunden nach der Abwicklung eines Auf-

trags.383 Leistungsprozesse geben direkt Leistungen an Kunden ab und erzeugen damit unmit-

telbar Nutzen für ihre Abnehmer. In der Regel werden die Leistungsprozesse anhand der Pro-

dukte bzw. Leistungen, die ein Unternehmen seinen externen Kunden anbietet, definiert.384

Dem Prozesstyp Unterstützungsprozess werden alle Prozesse zugeordnet, die die Ressour-

cen zur Leistungserstellung aufbauen und pflegen.385 Sie ermöglichen die kontinuierliche

Ausführung mehrerer Leistungsprozesse, insbesondere durch die Bereitstellung von Ressour-

cen (Personal, Material und Hilfsstoffe), die Bereitstellung und Pflege der Infrastruktur und

die (Weiter-) Entwicklung der Produkte und Dienstleistungen.386

380 Vgl. IMG (1997), S. 17.

381 Vgl. Scheer (1998), S. 3.

382 Vgl. Österle (1995), S. 130.



385 Vgl. Österle (1995), S. 130.



Der Prozesstyp Führungsprozess fasst alle Prozesse zusammen, die die übergreifende Pla-

nung, Steuerung und Kontrolle des zu führenden Objektes (z.B. andere Prozesse) gewährleis-

ten. Ihre Ergebnisse gehen an die Leistungs- und Unterstützungsprozesse.387

Die von einem Prozess erzeugte Leistung (Prozessleistung) geht an interne oder externe

Kunden bzw. an deren Prozesse. Empfänger einer Prozessleistung ist somit ein anderer Pro-

zess innerhalb oder ausserhalb der Unternehmung bzw. Geschäftseinheit. Ist der Leistungs-

empfänger ein Prozess ausserhalb der eigenen Unternehmung, ist eine Prozessleistung Teil

einer Marktleistung.388 Eine Prozessleistung kann materiell (Sachleistung) oder immateriell

(Dienstleistung) sein und mit den zu ihrer Erstellung benötigten Kosten bewertet werden.389

Dienstleistungen können weiter in Informations- und sonstige Dienstleistungen unterteilt

werden. Handelt es sich um eine Informationsleistung, die zwischen zwei Prozessen ausge-

tauscht wird, so besteht zwischen den Prozessen eine Informationsbeziehung. Andernfalls

besteht zwischen diesen Prozessen eine Leistungsbeziehung. Die zwischen den Prozessen

der Prozesslandkarte ausgetauschten Leistungen können in einem eigenen (Prozess-)

Leistungsmodell in hierarchischer Form abgebildet werden.

Jeder Prozess der Prozesslandkarte lässt sich durch einen oder mehrere Prozesse spezialisieren

(Generalisierungs-Spezialisierungs-Zusammenhang) oder in detailliertere (Teil-)Prozesse zer-

legen (Aggregations-Dekompositions-Zusammenhang).390

Abbildung 39: Metamodell der Prozesslandkarte

4.2.2.2 Metamodell der Prozessvision

Als wichtige Ideenquellen für neue Lösungen und damit als Grundlage für die Prozessvision

können Mitarbeiter und deren Know-how, Beispiele vorhandener innovativer Lösungen, In-

387 Vgl. Gossar in IMG (1997)

388 Vgl. Brecht (2002), S. 170.

389 SCHEER differenziert den generellen Leistungs- bzw. Produktbegriff nach Sach- und Dienstleistungen. Vgl.

Scheer (2001), S. 93. 390

Vgl. hierzu Abschnitt 2.2.1 und Winter (2003d), S. 90-91.


formationstechnologien und deren Potenziale sowie die Unternehmensstrategie bzw. Vorga-

ben aus dieser herangezogen werden.391

Jedem Prozess der Prozesslandkarte kann eine Prozessvision zugeordnet werden. Die Pro-

zessvision beschreibt anhand von Prozessgrundsätzen, wie der Prozess gestaltet sein sollte.

Die Prozessgrundsätze werden unterteilt in die Dimensionen Leistungen, Ablauf, Erfolgsfak-

toren und IT-Unterstützung. Dabei besitzt jede Dimension ein oder mehrere Ausprägungen

und jede Ausprägung kann in der Regel auf genau eine Dimension zurückgeführt werden.

Anhand der prozessspezifischen IT-Unterstützung können diejenigen Informationstechniken

zusammengefasst werden, welche für die Prozessunterstützung als geeignet erscheinen. Die

Dimension Leistungen beschreibt die von einem Prozess zu erzeugenden Leistungen sowie

die Partner, die für die Leistungserstellung mit einzubeziehen sind. Die Dimension Ablauf

fasst Hinweise aus der Strategiegestaltung zusammen, die bei der Modellierung des Prozess-

ablaufs bzw. der Festlegung der einzelnen Aktivitäten sowie deren Reihenfolge zu berück-

sichtigen sind. Im Hinblick auf die Prozessführung werden Erfolgsfaktoren zur Bewertung

und Steuerung des Prozesses in der Dimension Prozessführung zusammengefasst.

Abbildung 40: Metamodell der Prozessvision

4.2.2.3 Metamodell der Prozessführung

Die Steuerung des Prozesses wird durch die Prozessführung bestimmt. Sie plant Soll-Werte,

erhebt Ist-Werte, legt Erfolgsfaktoren und Führungsgrössen fest und löst notwendige Mass-

nahmen aus.392 Input erhält die Prozessführung aus der Geschäftsstrategie in Form von aus

der Balanced Scorecard abgeleiteten Kennzahlen und aus den Prozessgrundsätzen der Pro-

zessvision.

Die folgende Beschreibung der Prozessführung enthält einige Begriffe, die auch auf Strate-

gieebene Verwendung finden. Diese beziehen sich bei der Modellierung der Organisations-

ebene auf den Prozesskontext.

391 Vgl. Techniken in IMG (1997) und Hess (1996), S. 183-189.

392 Vgl. Österle (1995), S. 54.


Ein kritischer Erfolgsfaktor (KEF) der Organisationsebene beschreibt ein erfolgsentschei-

dendes Merkmal eines Prozesses. Er wird aus der Geschäftsstrategie (BSC) und der Prozess-

vision abgeleitet und durch eine oder mehrere Führungsgrössen operationalisiert.393 Typische

Merkmale und damit kritische Erfolgsfaktoren eines Prozesses, die aus Kundensicht relevant

sind, sind beispielsweise Qualität, Zeit, Kosten und Flexibilität.

Eine Führungsgrösse beschreibt einen quantitativ messbaren, für die Führung eines Prozes-

ses relevanten Sachverhalt. Sie operationalisiert einen oder mehrere Erfolgsfaktoren eines

Prozesses und dient der Planung und Beurteilung der Prozessqualität im Sinne der kritischen

Erfolgsfaktoren.394

Der Wert einer Führungsgrösse, der für einen bestimmten Zeitpunkt angestrebt wird, wird

durch das Prozessziel definiert. Es ist das Ergebnis der Planungsaktivitäten und verkörpert

Vorgaben, auf die die Entscheidungen auszurichten sind.395 Sie bilden die Grundlage für die

Soll-Ist-Vergleiche im Rahmen der Kontrolle und Neuausrichtung der Prozesse.

Die Prozessziele, kritischen Erfolgsfaktoren und Führungsgrössen werden in Berichten zu-

sammengefasst. Ein Bericht stellt das Ausmass und die Ursachen von Abweichungen zwi-

schen den geplanten und den effektiven Ergebnissen dar und geht an eine oder mehrere Orga-

nisationseinheiten.396 Im Hinblick auf eine informationstechnisch unterstützte Prozessführung

kann jedem Prozess eine Applikation im Sinne eines Messsystems zugeordnet werden. Diese

misst die für den Prozess definierten Führungsgrössen und erstellt aus den Messergebnissen in

regelmässigen Abständen einen elektronischen Bericht, der an die verantwortliche(n) Organi-

sationseinheit(en) geschickt wird.

Abbildung 41: Metamodell der Prozessführung

393 Vgl. Brecht (2002), S. 159.

394 Vgl. Österle (1995), S. 54.

395 Vgl. Brecht (2002), S. 178.

396 Vgl. Brecht (2002), S. 149.


Eine Organisationseinheit des Prozessmanagements (OE des PM) stellt eine speziell für

die Führung eines Prozesses eingerichtete organisatorische Einheit dar.397 Dadurch wird die

Führung eines Prozesses Teil der Organisationsstruktur eines Unternehmens.

4.2.2.4 Metamodell der Aufbauorganisation

Das Modell der Aufbauorganisation beschreibt die Organisationseinheiten eines Unterneh-

mens mit den zwischen ihnen bestehenden Kommunikations- und Weisungsbeziehungen.398

Es dient dazu, die komplexen Strukturen einer Organisation in vereinfachter Form darzustel-

len, indem gleichartige Aufgabenkomplexe zu Organisationseinheiten zusammengefasst wer-

den. Abbildung 42 zeigt das Metamodell der Aufbauorganisation.

Eine Organisationseinheit bezeichnet einen eigenständigen, permanenten Teil der organisa-

torischen Struktur eines Unternehmens (z.B. Abteilung, Division, Geschäftseinheit).399 Sie

kann mehr oder weniger aggregiert sein und eine Geschäftseinheit oder das Unternehmen

selbst darstellen. Die Über- und Unterordnungsbeziehungen geben an, in welche organisatori-

schen Einheiten und Untereinheiten sich eine Organisation untergliedern lässt. Sie spiegeln

gleichzeitig die Ergebnisse der Abteilungs- und Bereichsbildung wider.400 Auf der obersten

Aggregationsstufe entspricht die organisatorische Einheit der gesamten Unternehmung. Un-

terstützungsbeziehungen bestehen z. B. zwischen den Stabs- und den Linienabteilungen.

Organisationseinheiten bilden die Grundstruktur der Unternehmung (Primärorganisation).

Alternative Strukturen (z. B. organisatorische Einheiten auf Zeit oder für periodisch wieder-

kehrende Aufgaben) können diese Grundstruktur überlagern. Man spricht dann von temporä-

ren Organisationseinheiten. Eine temporär bestehende Organisationseinheit wird durch den

Metaentitätstyp sekundäre Organisationseinheit repräsentiert. Sekundäre Organisationsein-

heiten sind in der Regel orthogonal zu den dauerhaften Organisationseinheiten, repräsentiert

durch den Metaentitätstyp primäre Organisationseinheit, positioniert.

Die Führung von Prozessen führt in der Regel zu einer Überlagerung der Primärstruktur.401

Daher wird zusätzlich das Konstrukt Organisationseinheit des Prozessmanagement (OE

des PM) eingeführt. Eine OE des PM ist eine speziell für die Führung eines Prozesses einge-

richtete Organisationseinheit.402 Bei einer reinen Prozessorganisation ist die OE des PM nicht

erforderlich, da die Prozesse zu primären organisatorischen Einheiten werden.

397 Vgl. Glossar in IMG (1997) oder Brecht (2002), S. 165.

398 Vgl. Scheer (2001), S. 52.


400 Vgl. Brecht (2002), S. 164.

401 Vgl. Brecht (2002), S. 164.



Abbildung 42: Metamodell der Aufbauorganisation

Eine Organisationseinheit besteht aus mehreren Stellen, wobei eine Stelle eine Zusammenfas-

sung von Aufgaben beschreibt, die einer Person übertragen werden können und diese dauer-

haft bei definierter, im Regelfall kontinuierlicher Arbeitszeit auslasten.403 Die Stelle stellt so-

mit, im Gegensatz zur Rolle, ein dauerhaftes, langfristiges Konstrukt innerhalb der Aufbauor-

ganisation dar. Stellen mit gleichen Kompetenzen können zu einem Stellentyp zusammenge-

fasst werden.

Die (Prozess-)Rolle repräsentiert ein organisatorisches Konstrukt, das als Bindeglied zwi-

schen Aufbau- und Ablauforganisation dient. Sie bündelt einzelne Aktivitäten der Ablaufor-

ganisation, die letztendlich von Menschen (organisatorischen Rollenträgern) oder Maschinen

(technischen Rollenträgern) wahrgenommen werden. Darüber hinaus definiert die Prozessrol-

le zum einen die für die Ausführung einer Aktivität notwendige minimale Qualifikation (z.

B. „spricht Spanisch“), zum anderen beschreibt eine Rolle Kompetenzen, welche einem Rol-

lenträger übertragen werden (z. B. „ist zeichnungsberechtigt“).404

Eine Stelle kann von einer bestimmten Person oder aber auch im Sinne von Teilzeitstellen

und Schichtarbeit von mehreren Personen besetzt werden. Zudem wird keine zwingende

Zuordnung zwischen Person und Stelle gefordert, so dass auch freie Mitarbeiter im Modell

der Aufbauorganisation erfasst werden können.405

Um eine Zuordnung zwischen einer Prozessrolle und unterschiedlichen organisatorischen

oder technischen Ressourcen zu ermöglichen, enthält das Metamodell der Aufbauorganisation

403 Vgl. Rosemann/zur Mühlen (1997), S. 80.




den abstrakten Metaentitätstyp Rollenträger. Ein Rollenträger kann in einen organisatori-

schen Rollenträger und einen technischen Rollenträger differenziert werden.406 Zu den

organisatorischen Rollenträgern gehören die Konstrukte Stelle, Person, Stellentyp und Or-

ganisationseinheit. Dadurch kann eine Rolle von einem dieser vier Konstrukte der Aufbau-

organisation übernommen werden. Technische Rollenträger sind beispielsweise Maschinen

oder Informationssysteme. Sie können dementsprechend weiter nach materialverarbeitend

und informationsverarbeitend unterschieden werden.407

Ein organisatorischer Rollenträger kann in Bezug auf eine bestimmte Prozessrolle eine Rol-

lenstellvertretung haben.408 Im Rahmen dieser Rollenstellvertretung wird ein Rolleninhaber

durch einen oder mehrere Stellvertreter vertreten. Analog lässt sich eine Stellenstellvertre-

tung definieren.

Die geographische Verteilung der Organisationseinheiten und Stellen wird durch den Metaen-

titätstyp Standort abgebildet. Ein Standort ist ein geographischer Punkt, an dem sich eine

oder mehrere organisatorische Einheiten bzw. Stellen befinden.

4.2.2.5 Metamodell der Ablauforganisation

Die Ablauforganisation bildet, basierend auf der Prozessvision, die konkreten Aktivitäten409

eines Prozesses sowie ihre Abfolge und ihre Zuordnung zu den Rollenträgern ab.

Für die Modellierung von Prozessabläufen existieren bereits zahlreiche Modellierungsspra-

chen. Vor allem wegen ihrer hohen Verbreitung und ihrer Ausdrucksmächtigkeit werden sehr

häufig die ereignisgesteuerten Prozessketten (EPK)410 oder auch UML-

Aktivitätsdiagramme411 eingesetzt. Während die EPK speziell für die Modellierung von Ge-

schäftsprozessen entwickelt wurde, fokussiert die UML dagegen auf die objektorientierte

Entwicklung von Softwaresystemen. Die im Folgenden beschriebenen Metaentitätstypen und

deren Repräsentationen für die Abbildung von Prozessabläufen basieren daher primär auf der

EPK bzw. eEPK (erweiterte ereignisgesteuerte Prozesskette). Zudem wird mit der Verwen-

dung der EPK als Grundlage für die Entwicklung des Metamodells der Ablauforganisation

eine Modellierungssprache gewählt, die formal spezifiziert ist412 und die über eine ausrei-

chende semantische Ausdrucksmächtigkeit verfügt.

406 Vgl. Scheer (2001), S. 56. SCHEER nimmt in der Organisationssicht von ARIS eine ähnliche

Differenzierung vor. Er unterscheidet dabei zwischen primär menschlichen und primär technischen Leistungsträgern.

407 Vgl. z.B. Scheer (2001), S. 56.

408 Vgl. Wortmann (2005), S. 120.

409 Synonym werden oftmals die Begriffe Funktion, Vorgang, Tätigkeit oder Aufgabe verwendet.

410 Vgl. z.B. Becker et al. (2002b) und Scheer/Jost (2002).

411 Vgl. z.B. Jeckle et al. (2004b).

412 Vgl. Scheer (2001), S. 170-171 und Rosemann (1996), S. 122-123.


Die EPK ist ein wesentliches Element des ARIS-Konzepts (Architektur integrierter Informa-

tionssysteme).413 Mit EPKs können Geschäftsprozesse grafisch dargestellt werden. Wesentli-

che Elemente einer EPK sind Ereignisse, Funktionen und Verknüpfungsoperatoren.414 Jede

Funktion kann zusätzlich mit einem Informationsobjekt verbunden werden, dessen Informati-

on bei der Durchführung einer Funktion manipuliert wird. Reichert man die Funktionen der

EPK mit zusätzlichen Informationen über ausführende Personen, unterstützende Systeme,

verwendete Daten etc. an, erhält man eine so genannte erweiterte EPK (eEPK), mit der die

Verbindung zu anderen Modellen und Sichten des ARIS-Konzepts hergestellt werden kann.415

Da der in dieser Arbeit verfolgte Ansatz im Sinne einer Unternehmensarchitektur die wesent-

lichen Metaentitätstypen definieren soll, werden auch für die Modellierung der Ablauforgani-

sation lediglich ausgewählte Metaentitätstypen der EPK verwendet und definiert. Diese sind

in der Regel auch in anderen Modellierungssprachen in ähnlicher Form vorhanden. Im Mittel-

punkt steht vor allem die Abfolge und Nebenläufigkeit von Aktivitäten sowie deren Zuord-

nung zu den Rollenträgern. Für ein umfassendes und detailliertes Prozessmanagement sollte

aus diesem Grunde ein entsprechend spezialisiertes Metamodell verwendet werden.

Die wesentlichen Metaentitätstypen des Metamodells der Ablauforganisation sind im Ansatz

dieser Arbeit, in Anlehnung an die EPK, Aktivitäten416, Ereignisse und Verknüpfungsoperato-

ren (vgl. Abbildung 43).

Abbildung 43: Metamodell der Ablauforganisation

Eine Aktivität ist eine betriebliche Tätigkeit mit einem definierten Handlungsziel, die ein

Objekt manipuliert und von einer Rolle bzw. einem (organisatorischen oder technischen) Rol-

413 Vgl. z.B. Scheer/Jost (2002).

414 Vgl. hierzu auch Abschnitt 3.2.1.2.

415 Vgl. hierzu die in Abschnitt 3.2.1 beschriebenen Metamodelle der unterschiedlichen Sichten von ARIS.

416 Eine Funktion der EPK wird im Metamodell dieser Arbeit als Aktivität bezeichnet.


lenträger durchgeführt wird.417 Sie stellen die aktiven Elemente der Ablauforganisation dar.

Eine Aktivität wird von einer oder mehreren Geschäftsfunktionen durchgeführt. Eine Ge-

schäftsfunktion ist eine Verarbeitungseinheit, die aus einer geschäftlichen (betriebswirt-

schaftlichen) Perspektive erhoben wurde.418 Sie definiert eine bestimmte Funktionalität, die

für die Durchführung einer oder mehrerer Aktivitäten benötigt wird. Die Geschäftsfunktionen

stellen das Bindeglied zur Applikationsunterstützung von Aktivitäten der Geschäftsprozesse

dar.419 Durch die Definition von Geschäftsfunktionen wird somit festgelegt, welche Aktivitä-

ten der Geschäftsprozesse automatisiert bzw. automatisierbar sind.

Im Gegensatz zu einer Aktivität, die ein zeitverbrauchendes Geschehen darstellt, ist ein Er-

eignis auf einen Zeitpunkt bezogen.420 Ereignisse sind die passiven Elemente der Ablauforga-

nisation.

Eine Kontrollflussbeziehung verbindet Ereignisse und Aktivitäten.421 Ereignisse können

sowohl Aktivitäten auslösen als auch deren Ergebnis sein. Um auszudrücken, dass eine Akti-

vität durch ein Ereignis oder mehrere gestartet wird bzw. eine Aktivität ein Ereignis oder

mehrere auslösen kann, wird der Metaentitätstyp Verknüpfungsoperator verwendet.422 Ver-

knüpfungsoperatoren können nach konjunktiven, adjunktiven und disjunktiven423 Verknüp-

fungen differenziert werden. Die entsprechenden Operatoren werden als AND-, OR- und

XOR-Operatoren bezeichnet. Des Weiteren können die Verknüpfungsoperatoren dahinge-

hend unterschieden werden, ob sie eine eingehende und mehrere ausgehende (Split-

Operator) oder mehrere eingehende und eine ausgehende Kontrollflusskante (Join-

Operator) besitzen.

Das Metamodell der EPK zwingt zu einer abwechselnden Folge von Aktivitäten (Funktionen)

und Ereignissen. Dadurch wird der Ablauf unnötig verlängert, wodurch unter Umständen ein

unverständliches und unübersichtliches Diagramm entsteht. Dies trifft insbesondere dann zu,

wenn Aktivitäten mit einem Verb im Infinitiv beschrieben werden (z.B. „Beleg bearbeiten“)

und die anschliessenden Ereignisse lediglich das Verb in ein Partizip umsetzen (z.B. „Beleg

bearbeitet“). Deshalb wird im Metamodell dieser Arbeit auf diese Einschränkung verzichtet.

Eine Aktivität kann folglich auch ein direkter Nachfolger bzw. Vorgänger einer anderen Akti-

vität sein. Semantisch bedeutet dies, dass die nachfolgende Aktivität gestartet wird, sobald die

417 Vgl. Brecht (2002), S. 147, Österle (1995), S. 50 und Scheer (2001), S. 22. BRECHT und ÖSTERLE

verwenden synonym den Begriff Aufgabe, SCHEER verwendet dagegen die Bezeichnung Funktion. KELLER ET AL. setzen den Funktionsbegriff in der EPK mit dem der Aufgabe gleich. Vgl. Keller et al. (1992), S. 8.

418 Vgl. Schwinn (2005), S. 19 und Gutzwiller (1994), S. 81.


420 Vgl. Scheer/Thomas (2005), S. 5.



423 In Anlehnung an die Terminologie der Aussagenlogik.


vorhergehende Aktivität beendet wurde. Nebenläufige Aktivitäten müssen weiterhin durch

Verknüpfungsoperatoren modelliert werden.

Aus Gründen der Übersichtlichkeit und besseren Lesbarkeit wird der Ablauf von Prozessen in

der Regel nicht durch ein einziges Modell repräsentiert, sondern in mehrere Teilmodelle zer-

legt.424 Dabei ist sowohl eine Schachtelung als auch eine Zerlegung der Modelle bzw. Aktivi-

täten möglich. Die Schachtelung von Aktivitäten dient der Hierarchisierung bzw. Dekompo-

sition von Ablaufmodellen. Bei der Dekomposition wird die übergeordnete Aktivität (Kom-

plexe Aktivität) mit dem Namen des entsprechenden Detailmodells bezeichnet. Ein Pro-

zesswegweiser ermöglicht dagegen die Verknüpfung von zwei Ablaufmodellen, die den glei-

chen Detaillierungsgrad besitzen. Dadurch kann ein Prozess in Teilprozesse zerlegt werden,

ohne eine „künstliche“ Hierarchisierung erzeugen zu müssen. Der Prozesswegweiser wird,

analog zur Dekomposition, mit dem Namen des Modells bezeichnet, auf das er verweist.

Modelle der Ablauforganisation dienen oftmals als Grundlage für die Entwicklung von

Workflow-Modellen.425 Sie stellen Ergebnisdokumente dar, die gemäss den verfolgten Zwe-

cken um workflowspezifische Informationen angereichert oder in neue Ergebnisdokumente

transformiert werden. Um die Transformation in entsprechende Workflow-Modelle zu er-

leichtern, sollte sich die Konstruktion von Ablaufmodellen nach einer bestimmten, vorgege-

benen Syntax richten. Regeln für die Konstruktion syntaktisch richtiger Modelle der Ablauf-

organisation definieren beispielsweise NÜTTGENS/RUMP.426

Die Ablauforganisation stellt, analog zur Steuerungssicht in ARIS (EPK)427, die zentrale Sicht

der Organisationsebene dar, in der Metaentitätstypen aus anderen Sichten mit Aktivitäten in

Beziehung gesetzt werden. So können beispielsweise Instanzen der Metaentitätstypen organi-

satorischer oder technischer Rollenträger, Prozessleistung, Informationsobjekt oder Applika-

tion mit einer bestimmten Aktivität innerhalb eines Prozessablaufs assoziiert sein. Dadurch

wird die Ablauforganisation mit anderen Sichten der Unternehmensarchitektur, wie z.B. der

Aufbauorganisation oder Applikationsbestandsführung, verbunden. Im Unterschied zum Me-

tamodell der EPK können zudem die von einer Aktivität erzeugten Prozessleistungen durch

Führungsgrössen bewertet werden. Diese Führungsgrössen stellen wichtige Indikatoren für

424 Vgl. z.B. Scheer/Thomas (2005), S. 11 und Jeckle et al. (2004b), S. 216.

425 Vgl. hierzu z.B. Holten et al. (1997), S. 10-12.

426 Für eine detaillierte Beschreibung der Syntax und Semantik von EPKs siehe z.B. Nüttgens/Rump (2002).

427 Die EPK stellt die zentrale Modellierungssprache des ARIS-Sichtenkonzepts dar. An EPK-Funktionen

können zusätzliche Sprachkonstrukte aus anderen Sichten, wie z.B. Umfelddaten, menschliche Arbeitsleistung, maschinelle Ressourcen, Anwendungssoftware, Leistungen, Finanzmittel, Organisationseinheiten oder Unternehmensziele annotiert werden. Dadurch kann neben dem Kontrollfluss auch zwischen Organisations-/Ressourcen-, Informations-, Leistungs- sowie Finanzmittelfluss unterschieden werden. Vgl. Scheer/Thomas (2005), S. 7-8.


die Effektivität und Effizienz eines Prozesses bzw. einer Aktivität dar.428 Sie verknüpfen so-

mit die Ablauforganisation mit der Prozessführung.

Das Metamodell der EPK ermöglicht eine sehr detaillierte Spezifikation von Prozessabläufen.

Dies widerspricht dem Anspruch der groben und aggregierten Darstellung der Zusammen-

hänge der Unternehmensarchitektur (vgl. Abschnitt 2.3.1). Deshalb wird alternativ zu dem in

dieser Arbeit leicht vereinfachten Metamodell der EPK das Metamodell von Ablaufketten429

empfohlen. Dieses ermöglicht lediglich die Abbildung der groben Ablauffolge von Aktivitä-

ten eines Prozesses sowie deren Zuordnung zu Rollenträgern und garantiert somit einen für

die Modellierung der Unternehmensarchitektur angemesseneren Detaillierungsgrad.

4.2.2.6 Metamodell der Informationslandkarte

Das Ziel einer Informationslandkarte ist es, die in einem Unternehmen bzw. einer Geschäfts-

einheit zur Verfügung stehenden Informationen zu identifizieren und aus verschiedenen

Blickwinkeln darzustellen.430 Für ihre Erstellung müssen Informationen zu den im Folgenden

beschriebenen Metaentitätstypen gesammelt und ausgewertet werden:431

Die einzelnen Informationen werden durch eine Inventur des Berichtswesens gesammelt. Da-

zu müssen die im Unternehmen zur Verfügung stehenden Berichte erfasst werden. Ein Be-

richt stellt einer oder mehreren Organisationseinheit(en) Informationen nach bestimmten Kri-

terien (Dimensionen) zur Verfügung.432 Er kann von einem bestimmten Messsystem elektro-

nisch erzeugt und hierarchisch strukturiert sein. So kann ein Bericht beispielsweise auf bereits

zuvor definierten Berichten basieren. Ein Bericht im Sinne der Prozessführung fasst Prozess-

ziele, kritische Erfolgsfaktoren und Führungsgrössen eines bestimmten Prozesses zusammen

und stellt das Ausmass und die Ursachen von Abweichungen zwischen den geplanten und den

effektiven Ergebnissen des Prozesses dar.433

Für jeden Bericht sind dessen Konsumenten und Produzenten zu identifizieren. Der Metaenti-

tätstyp Konsument beschreibt die Stelle (und damit indirekt die Person), die den Bericht

nachfragt, sowie die Organisationseinheit, in welcher die Person arbeitet. Dementsprechend

gibt der Metaentitätstyp Produzent die Person an, die für die Produktion des Berichts zustän-

dig ist sowie die Organisationseinheit, in welcher die Person arbeitet. Darüber hinaus müssen

die in dem Bericht aufgelisteten Informationsobjekte (Berichtspositionen)434 erfasst werden.


429 Vgl. z.B. Ablaufplanung in IMG (1997) und Brecht (2002), S. 138 und S. 362f.

430 Vgl. Strauch (2002), S. 180. Vgl. im Folgenden auch Strauch/Winter (2002) und Winter/Strauch (2004).

431 Vgl. Strauch (2002), S. 181-182.

432 Vgl. Strauch (2002), S. 139.

433 Vgl. Abschnitt 4.2.2.3.

434 STRAUCH verwendet anstelle des Begriffs Informationsobjekte den Begriff Berichtsposition, den er

synonym mit dem Begriff Information verwendet. Vgl. Strauch (2002).


Für die Strukturierung bzw. Auflistung der einzelnen Informationsobjekte können bestimmte

Dimensionen definiert werden.

Informationslandkarte

Messsystem

Auswertung

Dimension

Organisa-

tionseinheit

Person

Informations-

objekt

Stelle

konsumiert/

produziertbesetzt

erzeugt enthält

ist Teil von

* ***

**

*

1

1

1

Informations-

dienstleistung

*

*

Repräsenta-

tionsform

besitzt

*

*

Bericht

AktivitätProzessrolle

nimmt wahr

führt durch

erzeugt/

verwendet

**

*

1

* *

Abbildung 44: Metamodell der Informationslandkarte

Ein Informationsobjekt stellt eine Sammlung von Informationen dar, auf die bei der Durch-

führung von Aktivitäten wiederholt zurückgegriffen wird.435 Jedem Informationsobjekt kön-

nen eine oder mehrere Repräsentationsformen zugeordnet werden.436 Diese lassen sich bei-

spielsweise nach dem verwendeten Medium (z.B. Papier, elektronisch, Audio) oder dem ver-

wendeten Format (z.B. PDF, HTML) unterscheiden. Informationsobjekte können Teil der

Prozessleistung sein, wenn diese als Informationsdienstleistungen an nachfolgende Prozesse

weitergegeben werden.437 Im Rahmen der Prozessführung umfassen Informationsobjekte In-

formationen über Prozessziele, kritische Erfolgsfaktoren oder Führungsgrössen. Auf der Or-

ganisationsebene können elektronische (durch Informationssystem unterstützte) und konven-

tionelle Informationsobjekte unterschieden werden.438 Für die nachfolgende Gestaltung der

Applikationsebene sind lediglich die elektronisch erfassbaren bzw. erfassten Informationsob-

jekte relevant. Diese werden auf Applikationsebene bestimmten Applikationen zugeordnet,

die sie verwalten und/oder manipulieren.

Auf Basis der erfassten Ausprägungen der oben genannten Metaentitätstypen lassen sich an-

schliessend Auswertungen durchführen.439 So können beispielsweise Informationsobjekte und

Organisationseinheiten bzw. Personen in Beziehung gesetzt werden. Dadurch wird für jedes

im Unternehmen bzw. in der Geschäftseinheit zur Verfügung gestellte Informationsobjekt

ersichtlich, welche Organisationseinheit bzw. Person dieses Informationsobjekt produziert

435 In Anlehnung an die Definition eines Informationsobjektes auf Applikationsebene. Vgl. Schwinn (2005), S.

138. 436

Vgl. Jonkers et al. (2004), S. 269. 437

Vgl. hierzu z.B. auch Scheer (2001), S. 70. 438

Vgl. hierzu Frank (1995), S. 5 und Scheer (2001), S. 69. 439

Vgl. Strauch (2002), S. 185-186.


bzw. verwendet. Zudem können potenzielle homonyme oder synonyme Informationsobjekte

identifiziert werden, indem aufgezeigt wird, in welche Organisationseinheit die entsprechende

Information geliefert wird. Sind es mehrere Organisationseinheiten, welche die Information

nachfragen, liegt die Vermutung nahe, dass dieselbe Information unterschiedlich interpretiert

wird. Die Auflistung potenzieller Homonyme und Synonyme unterstützt die spätere auf Ap-

plikationsebene erfolgende Erstellung des Informationsobjektmodells und die anschliessende

Durchführung der Homogenisierung.

In Verbindung mit dem Modell der Ablaufplanung lässt sich darüber hinaus nachvollziehen,

welche Organisationseinheiten oder Personen bei der Durchführung bestimmter Aktivitäten

innerhalb der Geschäftsprozesse welche Informationsobjekte verwenden und/oder erzeugen.

Dadurch wird ersichtlich, für die Erfüllung welcher Aktivität(en) die jeweilige Information

wichtig ist und umgekehrt, welche Informationen für die Erfüllung einer bestimmten Aktivität

benötigt werden. Folglich lässt sich sowohl der Informationsfluss zwischen Prozessen bzw.

Aktivitäten als auch zwischen Organisationseinheiten bzw. Stellen/Personen auswerten. Da

der Informationsfluss zwischen Prozessen und Aktivitäten bereits in der Prozesslandkarte und

im Modell der Ablaufplanung abgebildet ist, steht bei der Informationslandkarte der Informa-

tionsfluss zwischen Organisationseinheiten und Stellen im Vordergrund.

4.2.2.7 Definition der Metaentitätstypen auf Organisationsebene

Die folgende Tabelle 10 spezifiziert die zuvor erwähnten Metaentitätstypen sowie deren

Beziehungen im Detail.

Aktivität

Definition Eine Aktivität (synonym verwendeter Begriff für Aufgabe, Funktion, Vorgang) ist eine betriebliche Tätigkeit mit einem definierten Handlungsziel, die ein Objekt manipuliert

und von einer Rolle bzw. einem Rollenträger durchgeführt wird.440

Prozess Eine Aktivität ist Bestandteil von einem oder mehreren Pro-zess/en.

(Prozess-)Rolle Eine Aktivität wird von keiner, einer oder mehreren Rolle/n durchgeführt.

Informationsobjekt Eine Aktivität manipuliert ein oder mehrere Informationsobjekt/e.

Geschäftsfunktion Eine Aktivität wird von einer oder mehreren Geschäftsfunkti-on/en durchgeführt.

Applikation Eine Aktivität wird von keiner, einer oder mehreren Applikati-on/en unterstützt.

Beziehungen zu

Ereignis Eine Aktivität wird von einem oder mehreren Ereignis/sen ausge-löst.

Bericht

Definition Ein Bericht stellt einer oder mehreren Organisationseinheiten Informationen nach be-

stimmten Kriterien (Dimensionen) zur Verfügung.441

Ein Bericht der Prozessführung stellt das Ausmass und die Ursachen von Abweichungen zwischen den geplanten und den

440 Vgl. Brecht (2002), S. 147, Österle (1995), S. 50 und Scheer (2001), S. 22.

441 Vgl. Strauch (2002), S. 139.


effektiven Ergebnissen eines Prozesses dar. Er gibt einen Überblick über die Entwicklung

der Führungsgrössen.442

Organisationseinheit Ein Bericht geht an eine oder mehrere Organisationseinheit/en.

Erfolgsfaktor Ein Bericht enthält einen oder mehrere Erfolgsfaktor/en.

Führungsgrösse Ein Bericht enthält eine oder mehrere Führungsgrösse/n.

Prozessziel Ein Bericht umfasst ein oder mehrere Prozessziel/e.

Stelle Ein Bericht wird von einer oder mehreren Stelle/n konsu-miert/produziert.

Messsystem Ein Bericht wird von einem Messsystem erzeugt.

Beziehungen zu

Informationsobjekt Ein Bericht enthält ein oder mehrere Informationsobjekt/e.

Ereignis

Definition

Ein Ereignis ist definiert als ein punktuelles Geschehen, das einen Tatbestand enthält

(Was) und zu einem Zeitpunkt stattfindet (Wann).443

Eine Bedingung legt fest, unter welchen Voraussetzungen ein Ereignis relevant ist. Die Aktion beschreibt, wie auf das Eintreten eines Ereignisses bei Erfüllung der entsprechenden Bedingung reagiert werden soll.

Aktivität Ein Ereignis wird von einer oder mehreren Aktivität/en ausgelöst. Beziehungen zu

Operator Ein Ereignis hat keinen, einen oder mehrere Operator/en als Vor-gänger/Nachfolger.

Führungsgrösse

Definition

Eine Führungsgrösse ist ein operationalisiertes Merkmal eines Prozesses. Führungsgrös-sen dienen der Planung und Beurteilung der Prozessqualität im Sinne der kritischen Er-

folgsfaktoren, insbesondere der Zeit, Qualität, Kosten und Flexibilität.444

Sie sind die Messgrössen für die kritischen Erfolgsfaktoren und stellen wichtige Indikatoren für die

Effektivität und Effizienz eines Prozesses dar.445

KEF Eine Führungsgrösse operationalisiert einen oder mehrere KEF/en eines Prozesses.

Prozessziel Für eine Führungsgrösse werden ein oder mehrere Ziel/e defi-niert.

Bericht Eine Führungsgrösse ist Teil eines Berichts.

Applikation Eine Führungsgrösse wird von keiner oder einer Applikation gemessen.

Beziehungen zu

Prozessleistung Eine Führungsgrösse bewertet eine oder mehrere Prozessleis-tung/en.

Führungsprozess

Definition

Führungsprozesse gewährleisten die prozessübergreifende Planung, Steuerung und Kon-trolle des Gesamtunternehmens. Ihre Leistungen gehen an die Leistungs- und Unterstüt-zungsprozesse. Im Rahmen der Führungsprozesse werden Aufgaben wie die Kontrolle der Finanzen, die Entwicklung der Unternehmensstrategie sowie die Überwachung von deren Umsetzung ausgeführt.

Geschäftsfunktion

Definition Eine Geschäftsfunktion ist eine Verarbeitungseinheit, die aus einer geschäftlichen (be-

triebswirtschaftlichen) Perspektive erhoben wurde.446

442 Vgl. Brecht (2002), S. 149.

443 Vgl. Scheer (2001), S. 124.

444 Vgl. Österle (1995), S. 54.

445 Vgl. Österle (1995), S. 116 und Glossar in IMG (1997).

446 Vgl. Schwinn (2005), S. 19 und Gutzwiller (1994), S. 81.


Aktivität Eine Geschäftsfunktion führt eine Aktivität aus. Beziehungen zu

Applikationsfunktion Eine Geschäftsfunktion kann durch eine oder mehrere Applikati-onsfunktion/en auf Applikationsebene realisiert werden.

Informationsobjekt

Definition

Ein Informationsobjekt der Organisationsebene stellt eine Sammlung von Informationen

dar, auf die bei der Durchführung von Aktivitäten wiederholt zurückgegriffen wird.447

Es

können elektronische und konventionelle Informationsobjekte differenziert werden.448

Aktivität Ein Informationsobjekt wird von einer oder mehreren Aktivität/en manipuliert.

Bericht Ein Informationsobjekt kann Teil eines Berichtes sein. Beziehungen zu

Informations-dienstleistung

Ein Informationsobjekt kann Teil einer oder mehrerer Informati-onsdienstleistung/en sein.

Kritischer Erfolgsfaktor (KEF)

Definition Ein kritischer Erfolgsfaktor bezeichnet eines der wenigen Merkmale, die den Erfolg eines Prozesses ausmachen. Die kritischen Erfolgsfaktoren helfen der Prozessführung, sich auf

das Wesentliche zu konzentrieren.449

Führungsgrösse Ein KEF wird durch keine, eine oder mehrere Führungsgrösse/n operationalisiert.

Beziehungen zu

Prozess Ein KEF ist für einen oder mehrere Prozess/e erfolgsentschei-dend.

Leistungsprozess

Definition Gegenstand von Leistungsprozessen ist die Erstellung und der Vertrieb von Produkten

und Dienstleistungen.450

Mittels dieses Prozesstyps besitzt das Unternehmen Kontakt zum Kunden, da die Prozessleistung direkt an diesen abgegeben wird.

Messsystem

Definition

Ein Messsystem dient der informationstechnischen Unterstützung der Prozessführung. Ein Messsystem erhebt den Ist-Zustand eines Prozesses, indem es die im Rahmen der Prozess-führung definierten Führungsgrössen misst und Berichte erstellt, die die Messergebnisse

zusammenfassen.451

Applikation Ein Messsystem wird durch eine Applikation auf Applikations-ebene realisiert.

Bericht Ein Messsystem erzeugt einen oder mehrere Bericht/e.

Prozess Ein Messsystem ist einem oder mehreren Prozess/en zugeordnet. Beziehungen zu

Führungsgrösse Ein Messsystem misst keine, eine oder mehrere Führungsgrös-se/n.

Operator

Definition Ein Operator stellt eine logische Verknüpfung zwischen Ereignissen und Aktivitäten dar. Typische logische Verknüpfungen sind UND, ODER (Inklusiv-Oder) und XOR (Exklu-

siv-Oder).452

Aktivität Ein Operator ist der Vorgänger/Nachfolger von einer oder mehre-ren Aktivität/en.

Beziehungen zu Ereignis

Ein Operator ist der Vorgänger/Nachfolger von einem oder meh-reren Ereignis/sen.

447 In Anlehnung an die Definition eines Informationsobjektes auf Applikationsebene. Vgl. Schwinn (2005),

S. 138. 448

Vgl. Scheer (2001), S. 69. 449

Vgl. Brecht (2002), S. 159. 450

Vgl. Österle (1995), S. 130. 451

Vgl. hierzu auch Brecht (2002), S. 162. 452

Vgl. Scheer (2001), S. 125.


Organisationseinheit des Prozessmanagements (OE des PM)

Definition Eine organisatorische Einheit des Prozessmanagements ist eine speziell für die

Führung eines Prozesses eingerichtete Organisationseinheit.453

Organisationseinheit Eine OE des PM ist eine Organisationseinheit.

Prozess Eine OE des PM ist für das Management genau eines Prozesses verantwortlich.

Beziehungen zu

Prozessgrundsatz Eine OE des PM pflegt einen Prozessgrundsatz oder mehrere.

Prozess

Definition

Der Prozess wird als eine zusammengehörende Abfolge von Unternehmensverrichtungen zum Zweck einer Leistungserstellung definiert. Input bzw. Output eines Prozesses sind seine Leistungen, die von internen oder externen Kunden angefordert und abgenommen

werden.454

Prozessleistung Ein Prozess erbringt oder bezieht keine, eine oder mehrere Pro-zessleistung/en.

Organisationseinheit Ein Prozess ist einer oder mehreren Organisationseinheit/en (des PM) zugeordnet.

Serviceaktivität Ein Prozess korrespondiert mit keiner oder einer Serviceaktivität auf Strategieebene.

KEF Für einen Prozess sind ein oder mehrere kritische Erfolgsfaktor/en erfolgsentscheidend.

Applikationsdomäne Ein Geschäftsprozess kann durch eine oder mehrere Applikati-onsdomäne/n auf Applikationsebene unterstützt werden.

Aktivität Ein Geschäftsprozess beinhaltet eine oder mehrere Aktivität/en.

Beziehungen zu

Applikation Einem Prozess ist keine oder eine Applikation als Messsystem zugeordnet.

Prozessgrundsatz

Definition

Ein Prozessgrundsatz beschreibt ein grundlegendes, langfristig gültiges Prinzip bei der

Weiterentwicklung eines Prozesses.455

Ein Prozessgrundsatz bezieht sich beispielsweise auf die von einem Prozess erzeugte Leistung, seinen Ablauf, seine Erfolgsfaktoren oder seine IT-Unterstützung.

Prozess Ein Prozessgrundsatz beschreibt die Gestaltung eines Prozesses oder mehrerer Prozesse.

Beziehungen zu Organisationseinheit

Ein Prozessgrundsatz wird von einer verantwortlichen OE ge-pflegt.

Prozessleistung

Definition

Prozessleistungen sind das Ergebnis (der Output) der Leistungserstellung eines Prozesses, das an interne oder externe Kunden geht. Empfänger einer Leistung ist ein anderer Pro-zess innerhalb oder ausserhalb der Unternehmung. Eine Prozessleistung kann materiell oder immateriell sein. Ist der Leistungsempfänger ein Prozess ausserhalb der eigenen

Unternehmung, ist eine Prozessleistung Teil einer Marktleistung.456

Prozess Eine Prozessleistung wird von einem oder mehreren Prozess/en erzeugt und von einem oder mehreren Prozess/en entgegenge-nommen. Beziehungen zu

Marktleistung Eine Prozessleistung ist Teil keiner, einer oder mehrerer Markt-leistung/en auf Strategieebene.


454 Vgl. Scheer (1998), S. 3.

455 Vgl. Brecht (2002), S. 168.

456 Vgl. Brecht (2002), S. 170.


Informationsobjekt Eine Prozessleistung kann als Informationsdienstleistung ein oder mehrere Informationsobjekt/e umfassen.

Führungsgrösse

Eine Prozessleistung wird durch eine oder mehrere Führungsgrös-se/n bewertet.

Prozessrolle

Definition

Eine Prozessrolle repräsentiert zum einen die für die Ausführung einer Aktivität notwen-dige minimale Qualifikation (z. B. „spricht Spanisch“), zum anderen beschreibt eine Rolle Kompetenzen, welche einem Rollenträger übertragen werden (z. B.

„ist zeichnungsberechtigt“).457

Die Prozessrolle dient als Bindeglied zwischen der Auf-bau- und Ablauforganisation.

Aktivität Eine Rolle führt eine oder mehrere Aktivität/en innerhalb eines Prozesses aus.

Anforderung Eine Prozessrolle definiert eine oder mehrere Anforderung/en. Beziehungen zu

Rollenträger Eine Prozessrolle wird von einem Rollenträger wahrgenommen.

Prozessziel

Definition Das Prozessziel definiert den Wert einer Führungsgrösse, der für einen bestimmten Zeit-

punkt angestrebt wird.458

Beziehung zu Führungsgrösse Ein Prozessziel bestimmt eine oder mehrere Führungsgrösse/n.

Rollenträger

Definition Organisationseinheiten bzw. die ihnen zugeordneten Mitarbeiter (organisatorische Rollen-träger) und/oder Maschinen (technische Rollenträger) führen im Rahmen einer Prozess-

rolle Aktivitäten aus.459

Rolle Ein Rollenträger nimmt eine oder mehrere (Prozess-)Rolle/n wahr.

Beziehungen zu Benutzerkonto

Ein Rollenträger verfügt über kein/ein/mehrere Konto/Konten auf Systemebene.

Stelle

Definition Eine Stelle bezeichnet eine Zusammenfassung von Aufgaben, die eine derartige Kapazi-tätsnachfrage bilden, dass sie einer Person übertragen werden können und diese dauerhaft

bei definierter, im Regelfall kontinuierlicher Arbeitszeit auslasten.460

Person Eine Stelle kann durch eine oder mehrere Person/en besetzt wer-den, z.B. aufgrund von Schichtarbeitsplätzen oder Teilzeit.

Beziehungen zu Bericht

Eine Stelle konsumiert/produziert keinen, einen oder mehrere Bericht/e.

Stellentyp

Definition Ein Stellentyp fasst Stellen mit gleichen Kompetenzen zusammen (z. B. Stellentyp „Sek-

retärin“ im Gegensatz zur Stelle „Sekretärin von Prof. Winter“).461

Beziehungen zu Stelle Ein Stellentyp fasst eine oder mehrere Stelle/n zusammen.

Stellvertretung

Definition

Eine Stellenstellvertretung stellt einen begrenzten oder unbegrenzten Einsatz eines oder mehrerer Stelleninhaber (Person) für einen anderen Stelleninhaber dar, sowohl in räumli-

cher, funktionsmässiger als auch in zeitlicher Hinsicht.462

Analog lässt sich eine Rollen-stellvertretung für einen Rollenträger definieren.

Person Eine Stellvertretung ist einer oder mehreren Person/en zugeord-net. Beziehungen zu

Stelle Eine Stellvertretung bezieht sich auf eine oder mehrere Stelle/n.


458 Vgl. Brecht (2002), S. 178.

459 Vgl. Scheer (2001), S. 56 und Metamodell in IMG (1997).



462 Vgl. Wortmann (2005), S. 122.


Unterstützungsprozess

Definition

Unterstützungsprozesse ermöglichen die kontinuierliche Ausführung mehrerer Leistungs-prozesse, insbesondere durch die Bereitstellung von Ressourcen (Personal, Material und Hilfsstoffe), die Bereitstellung und Pflege der Infrastruktur und die (Weiter-) Entwicklung

der Produkte und Dienstleistungen.463

Tabelle 10: Metaentitätstypen der Organisationsebene

4.2.2.8 Festlegung der verwendeten Symbole auf Organisationsebene

Die folgende Tabelle 11 gibt einen Überblick über die Notationselemente (Symbole) für die

auf Organisationsebene definierten Metaentitäts- und Beziehungstypen. Metaentitätstypen

ohne zugeordnetes Notationselement werden lediglich textuell (z.B. in Form von Listen)

repräsentiert.

Symbole der Organisationsebene

Atomare Aktivität Ereignis Führungsgrösse

Führungsprozess Geschäftsfunktion Informationsobjekt

Komplexe Aktivität Kritischer Erfolgsfaktor Leistungsprozess

Operator Organisationseinheit Prozessleistung

Prozessrolle Prozessstart Prozesswegweiser



Prozessziel Stelle Unterstützungsprozess

erbringt/bezieht Information

(von Prozess zu Prozess)

bestimmt

(von Prozessziel zu Führungsgrösse)

erbringt/bezieht Leistung


führt aus

(von Rollenträger zu Aktivität)

ist Input für

(von IO zu Aktivität)

ist Output von


unterstützt

(von Applikation zu Aktivität)

ist zugeordnet

(von Führungsgrösse zu Aktivität)

ist übergeordnet

(von OE zu OE)

nimmt wahr

(von Rollenträger zu Rolle)

gehört zu

(von Stelle zu OE)

kommuniziert mit

(von OE zu OE)

ist Teil von

(von Leistung zu Leistung)

ist Nachfolger/Vorgänger von

(von Ereignis zu Aktivität/Operator)

ist Stellvertretung für

(von Person zu Stelle)

Tabelle 11: Symbole der Organisationsebene

Bei Beziehungstypen, denen kein Notationselement zugeordnet ist, handelt es sich entweder

um eine modellübergreifende Beziehung oder um eine Aggregationsbeziehung. Aggregations-

beziehungen werden in Form einer Schachtelung von Symbolen (z.B. bei der Beziehung

zwischen „Erfolgsfaktor“ und „Führungsgrösse“) dargestellt. Modellübergreifende

Beziehungen werden später bei der softwaretechnischen Implementierung durch Referenzen

abgebildet (vgl. hierzu Abschnitt 5.2.4).

4.3 Modellierung auf Informationssystemebene

Die Systemebene ist die der Organisationsebene logisch nachfolgende Gestaltungsebene (vgl.

Abschnitt 2.3.2). Sie wird weiter unterteilt in die Applikationsebene sowie Softwarekompo-

nenten- und Datenstrukturebene.

Auf der Informationssystemebene werden Integrationsbereiche innerhalb des Informations-

systems festgelegt, ausgehend von den zuvor spezifizierten Organisationsstrukturen, Informa-

tionsbedarfen und Prozessabläufen. Im Normalfall wird ein eng gekoppelter Integrationsbe-

reich durch eine Applikation realisiert, während lose Kopplungen zwischen Integrationsberei-

chen durch Schnittstellen zwischen Applikationen realisiert werden. Wichtige Ergebnisse der


Applikationsgestaltung sind gesamthaft die Integrationsarchitektur und auf detaillierter Ebene

Fachkonzepte für einzelne Applikationen bzw. Informationssystem-Komponenten.

Wesentliche Anforderungen an einen Ansatz für die Modellierung der Systemebene sind:464

• Unterstützung bei der Ableitung einer effektiven und effizienten IT-Unterstützung für die

Prozessebene,

• Unterstützung bei der optimalen Strukturierung von Applikationen und ihrer Integration

unter Vermeidung ungewollter Redundanzen oder Lücken.

Auf der Systemebene können folgende Ergebnisdokumenttypen unterschieden werden:

• Mit Hilfe des Informationsobjekte- bzw. Geschäftsfunktionenmodells werden die in

Bezug auf die Prozesse relevanten Informationsobjekte (z.B. Kunde, Partner, Produkt)

und Geschäftsfunktionen (z.B. Kunde aufnehmen) ermittelt, miteinander verglichen und

in einem Homogenisierungsschritt hinsichtlich Synonymen und Homonymen vereinheit-

licht und dokumentiert.465 Sie dienen als Basis für die Ableitung von neuen Applikationen

im Rahmen der Definition der Integrationsarchitektur.

• Die Applikationslandschaft (Applikationsbestandsführung) dokumentiert den Gesamtbe-

stand an Applikationen, die sich in einem Unternehmen bzw. in einer Geschäftseinheit in

Betrieb oder in Planung befinden.466

• Die Integrationsarchitektur beschreibt eine applikatorische Beziehungsstruktur. Diese

wird aus den Beziehungselementen Informationsobjekte, Geschäftsfunktionen, Prozesse

bzw. Organisationseinheiten und deren unterschiedlichen Beziehungen untereinander her-

geleitet.467 Den daraus abgeleiteten Integrationsbereichen können neu zu entwickelnde

Applikationen zugeordnet werden.

• Das Softwarekomponenten- und Plattformenmodell dokumentiert die einzelnen Kom-

ponenten ausgewählter Applikationen sowie die von ihnen manipulierten Datenobjekte

und die Plattformen, auf denen sie betrieben werden. Zudem werden wichtige Schnittstel-

len und Datenspeicher abgebildet. Die Abbildung der Softwarekomponenten, Plattformen,

Schnittstellen und Datenstrukturen stellt vor allem im Hinblick auf zukünftige Applikati-

onsintegrationsprojekte eine wichtige Grundlage dar.468

464 Vgl. Winter (2004c), Kühn/Karagiannis (2005) sowie Abschnitt 2.3.1 und 2.3.2.



467 Der Ansatz geht auf WINTER zurück, nach welchem die beiden Methoden der

Applikationsarchitekturmodellierung „Business System Planning“ (vgl. IBM 1984) und Promet®STP (System- und Technologieplanung) (vgl. IMG 2000) zu einer integrierten Verfahrensweise kombiniert wurden. Vgl. Winter (2003a).

468 Vgl. hierzu z.B. die von SCHWINN entwickelte Methode für Applikationsintegrationsprojekte Schwinn

(2005).


• Das Autorisierungsmodell ordnet den menschlichen Rollenträgern für die Durchführung

der informationstechnisch unterstützten Aufgaben entsprechende Systemberechtigungen

zu. Diese Berechtigungen regeln den Zugriff auf die Methoden und Datenobjekte der exis-

tierenden Softwarekomponenten und werden über Benutzerkonten den Rollenträgern zu-

geordnet.469

• Das Datenmodell bildet die detaillierte Datenstruktur eines fachlichen Anwendungsbe-

reichs ab.470 Als Grundlage für die Erstellung des Datenmodells dienen die auf Applikati-

ons- sowie Softwarekomponenten- und Datenstrukturebene identifizierten Informations-

objekte bzw. Datenobjekte. Das noch aus fachkonzeptioneller Sicht entworfene Datenmo-

dell stellt eine hilfreiche Grundlage für die objektorientierte Softwareentwicklung dar.

Im folgenden Abschnitt wird das Vorgehen zur Erstellung der zuvor genannten Ergebnisdo-

kumente beschrieben.


Applikationsbestandsführung

einführen

Geschäftsfunktionenmodell

erstellen

Informationsobjektemodell

erstellen

Integrationsarchitektur ableiten

Applikationsbestandsführung

Informationsobjekte

SW-Komponenten und DS

Applikationslandschaft

Softwarekomponenten- und

Datenstrukturen abbilden

Autorisierung festlegen

Geschäftsfunktionen

Autorisierungen

Aufbauorganisation

Ablauforganisation

Abbildung 45: Vorgehensmodell auf Informationssystemebene (Level 1)

Als erstes wird eine Applikationsbestandsführung eingeführt, da aus ihr die Integrationsarchi-

tektur abgeleitet wird.471 Die Applikationsbestandsführung soll den aktuellen Gesamtbestand

an geplanten und realisierten Applikationen anhand vordefinierter Attribute dokumentieren.

469 Vgl. hierzu z.B. die von Wortmann entwickelte Methode für die unternehmensweite Autorisierung

Wortmann (2005). 470

SCHEER definiert beispielsweise eine Mikrosicht auf die Datenobjekte, die mit Hilfe eines erweiterten ERM abgebildet wird (vgl. Scheer (2001), S. 70).



Das Vorgehensmodell zur Erstellung der Applikationsbestandsführung besteht aus vier

Schritten:472 Zuerst wird das Modell der Bestandsführung in Absprache mit den unterschiedli-

chen Fachbereichen und deren Informationsbedarf erstellt und im zweiten Schritt verabschie-

det. Im dritten Schritt wird ein entsprechendes Modell für die Bestandsführung in einer Da-

tenbank angelegt, auf die über das Intranet zugegriffen werden kann. Im vierten Schritt wer-

den die notwendigen Verantwortlichkeiten und involvierten Organisationseinheiten festgelegt.

Im letzten Schritt folgt die unternehmensinterne Implementierung.

Nach der Einführung der Applikationsbestandsführung werden parallel ein Informationsob-

jekte- und Geschäftsfunktionenmodell erstellt. Mit Hilfe des Informationsobjektmodells wer-

den die auf Organisationsebene nach unterschiedlichen Konventionen abgebildeten Prozesse

hinsichtlich der verwendeten Begriffe für Informationsobjekte harmonisiert. Es werden die in

Bezug auf die Prozesse relevanten Informationsobjekte, wie z.B. Kunde, Partner, Produkt,

ermittelt, miteinander verglichen und in einem Homogenisierungsschritt hinsichtlich Syn-

onymen und Homonymen vereinheitlicht und in einem Modell dokumentiert. Die Ableitung

der Informationsobjekte für das unternehmens- bzw. geschäftsbereichweite Informationsob-

jektmodell erfolgt anhand von zwei Quellen: erstens aus den Ergebnisdokumenten der Orga-

nisationsebene und zweitens aus der Applikationsbestandsführung. Das Vorgehensmodell

besteht aus drei Schritten:473 Zuerst werden die Informationsobjekte anhand der Dokumenta-

tion der Prozessabläufe und der Organisationsstruktur ermittelt, harmonisiert und in einem

Informationsobjektmodell dokumentiert. Dabei werden lediglich die als elektronisch bzw.

informationstechnisch-unterstützt klassifizierten Informationsobjekte betrachtet. Danach er-

folgt die Synchronisation mit den Informationsobjekten der Applikationsbestandsführung und

als drittes die entsprechende Dokumentation mit Weisung an die Verantwortlichen der Appli-

kationsbestandsführung, die entsprechenden Anpassungen in der Ist-Dokumentation vorzu-

nehmen. Als Ergebnis liegt ein harmonisiertes, unternehmensweites Informationsobjektmo-

dell mit den entsprechenden Begriffen, Definitionen und Hinweisen auf Synonyme und Ho-

monyme vor.

Ebenso wie die Informationsobjekte werden auch die Geschäftsfunktionen ermittelt und in

einem Geschäftsfunktionenmodell harmonisiert.

Aus der Applikationsbestandsführung (Applikationslandschaft) sowie dem Geschäftsfunktio-

nen- und Informationsobjektemodell wird die Integrationsarchitektur abgeleitet. Diese

besteht aus einer Ist- und Soll-Integrationsarchitektur. Beide werden mittels eines doppelten

Clusteranalyseverfahrens ermittelt, welches pro Verfahrensindikation dieselben Variablen

über unterschiedliche Grundmengen verwendet. Der Ansatz geht auf WINTER zurück, nach

welchem die beiden Methoden der Applikationsarchitekturmodellierung „Business System




Planning“ (BSP)474 und Promet® STP (System- und Technologieplanung)475 zu einer

integrierten Verfahrensweise kombiniert wurden.476 Als Variablen werden Informationsob-

jekt, Geschäftsfunktion und Organisationseinheit verwendet, die im doppelten

Matrixverfahren mit vordefinierten Werten einander gegenübergestellt und durch die

Bündelung gleicher Wertebezüge zu Integrationsbereichen ausgewertet werden. Für die Ist-

Integrationsarchitektur wird als Grundmenge die Gesamtmenge der im Informations-

objektmodell, Geschäftsfunktionsmodell und Aufbauorganisationsmodell dokumentierten

Entitäten genommen. Für die Soll-Integrationsarchitektur gilt als Grundmenge die entlang der

neuen Soll-Prozessabläufe ermittelte Menge an neuen Informationsobjekten,

Geschäftsfunktionen und Organisationseinheiten. Die ermittelten Integrationsbereiche über Ist

und Soll werden danach miteinander verglichen und ausgewertet, sowohl hinsichtlich eines

Redundanz- und Lückennachweises an bestehender Applikationsunterstützung als auch

hinsichtlich der Gestaltungsvorgaben aus den Gestaltungsgrundsätzen der Prozessebene. Eine

Priorisierung der Integrationsbereiche hinsichtlich der Geschäftsanforderungen wird während

dieser Entwurfsphase noch nicht durchgeführt, sondern erfolgt später während der IT-

Strategiefestlegung unter dem Punkt „Soll-Ist-Konzeption definieren“. Als Ergebnisdokument

liegen die aufeinander abgestimmten Integrationsbereiche aus Ist und Soll auf Mikroebene

vor, inklusive eines Lücken- und Redundanznachweises hinsichtlich bestehender

Applikationsunterstützung. Integration auf Mikroebene bedeutet, dass eine optimale und

aufeinander abgestimmte Integration der Daten-, Funktions- und Organisationseinheiten

hergeleitet worden ist.

Im nächsten Schritt werden die für die Implementierung ausgewählter Applikationen

benötigten Implementierungsbausteine abgebildet, wie beispielsweise Softwarekomponenten,

Middlewarekomponenten, Schnittstellen sowie Plattformen, auf denen die Softwarekompo-

nenten installiert sind.477

Ausgangsbasis zur Erstellung des Datenstrukturmodells bilden die im Informationsobjekte-

modell sowie im Modell der Softwarekomponenten identifizierten Informations- bzw. Daten-

objekte. Die detaillierte Datenstruktur, d.h. die Datenobjekte sowie deren Beziehungen, wird

mit Hilfe einer objektorientierten Entwurfsmethode (z.B. UML478 und ERM479) in einem oder

mehreren Klassendiagramm/en abgebildet. Diese können später als Vorlage für die software-

technische Implementierung verwendet werden.

474 Vgl. IBM-Corporation (1984).

475 Vgl. IMG (1999).

476 Vgl. Winter (2003a).

477 Für eine detaillierte Beschreibung des Vorgehens zur Abbildung der Implementierungsbausteine,

insbesondere im Hinblick auf zukünftige Applikationsintegrationsprojekte, vgl. Schwinn (2005). 478

Vgl. OMG (2005). 479

Vgl. Chen (1976).


Basierend auf den Modellen der Aufbau- und Ablauforganisation der Organisationsebene

sowie dem Modell der Softwarekomponenten und Datenstrukturen kann in einem letzten

Schritt die Autorisierung festgelegt werden. Diese verwaltet und kontrolliert die Zugriffsrech-

te der einzelnen Rollenträger auf die Softwarekomponenten und Datenobjekte und stellt somit

ein wichtiges Konzept für die Gewährleistung der Sicherheit eines Informationssystems dar.

Für die Festlegung der Autorisierung muss jedem Rollenträger ein Benutzerkonto zugeordnet

werden, das entsprechende Berechtigungen umfasst, die den Zugriff auf bestimmte Software-

komponenten und Datenobjekte definieren.480

4.3.2 Metamodell

Das Metamodell der Systemebene lässt sich entsprechend den bei der Systemgestaltung

erstellten Ergebnisdokumenttypen in die Sichten Informationsobjekte und Geschäftsfunktio-

nen, Applikationsbestandsführung (Applikationslandschaft), Integrationsarchitektur,

Softwarekomponenten und Plattformen, Autorisierung sowie Datenstrukturen einteilen.

4.3.2.1 Metamodell der Applikationslandschaft

Die Applikationslandschaft (Bestandsführung) enthält den aktuellen Gesamtbestand an ge-

planten und realisierten Applikationen und dokumentiert diese anhand vordefinierter Attribu-

te. Für die Ist-Integrationsarchitektur sind die Informationen zu Informationsobjekten, Ge-

schäftsfunktionen und zu den involvierten Organisationseinheiten von Bedeutung und müssen

pro Applikation erfasst werden. Sie stellen die Vergleichsbasis mit der Soll-

Integrationsarchitektur dar, welche die entsprechenden Informationsobjekte, Geschäftsfunkti-

onen und involvierten Organisationseinheiten aus der Prozessmodellierung ableitet. Zusätzli-

che Informationen können ebenso in der Applikationsbestandsführung erfasst werden, wie

z.B. Informationen über den Technologielebenszyklus einer Applikation, die in Bezug auf zu

tätigende Investitionen von Relevanz sein können. Die Konzeptualisierung der Applikations-

bestandsführung fällt unternehmensindividuell aus, je nach erwünschtem Informationsgrad.

Im Laufe der Zeit kann sie um Attribute erweitert werden, da es sich um eine laufende Doku-

mentation handelt. In dem hier präsentierten Ansatz werden für die Applikationsbestandsfüh-

rung lediglich die Angaben zu Informationsobjekten, Geschäftsfunktionen und den involvier-

ten Organisationseinheiten vorausgesetzt, weiterführende Attribute sind unternehmens-

individuell zu definieren.

Eine Applikation besteht aus Applikationsfunktionen und deren Operationen auf Informati-

onsobjekten. Applikationen können zur Beherrschung der Komplexität in einer Applikati-

onsdomäne logisch zusammengefasst werden. Diese kann auf Organisationsebene einen oder

mehrere Prozesse unterstützen. Jeder Applikation ist ein Owner zugeordnet, der aus einer

480 Für eine detaillierte Beschreibung des Vorgehens zur Festlegung der Autorisierung vgl. Wortmann (2005).


bestimmten Organisationseinheit stammt und für die Applikation und deren Dokumentation

verantwortlich ist. Ein Owner kann eine Stelle, eine Person oder eine Organisationseinheit

sein.

Eine Applikationsfunktion realisiert eine oder mehrere Geschäftsfunktionen mit Hilfe von

Informationstechnologie.481 Sie kann als Input Informationsobjekte erhalten und/oder als Out-

put neue oder veränderte Informationsobjekte erzeugen.

Ein Informationsobjekt stellt eine Sammlung dauerhaft gespeicherter Informationen dar, auf

die (von Applikationsfunktionen) wiederholt zurückgegriffen wird. Es ist einer verwaltenden

und einer oder mehreren operierenden Applikation(en) zugeordnet und wird auf der Ebene der

Softwarekomponenten und Datenstrukturen als Datenobjekt repräsentiert.482 Jedes Datenob-

jekt ist letztendlich einem bestimmten Datenspeicher zugeordnet. SCHWINN definiert

zusätzlich den Metaentitätstyp „Datenspeicherobjekt“, welcher eine Instanz eines

Datenobjekts in dem Datenspeicher repräsentiert. Im Sinne der Unternehmensarchitektur und

im Hinblick auf einen angemessenen Detaillierungsgrad wird auf die Verwendung dieses

Metaentitätstyps in diesem Ansatz verzichtet.

Abbildung 46 zeigt das Metamodell der Applikationslandschaft mit den zuvor definierten

Metaentitätstypen sowie deren Beziehungen.

Abbildung 46: Metamodell der Applikationslandschaft

Dank der durchgängigen Dokumentation der Applikationen bzw. Applikationsdomänen und

der unterstützten Geschäftsprozesse können Aussagen über betroffene Applikationen bei Ver-

änderung oder Wegfall vorhandener Prozesse getroffen werden. Typische Fragestellungen

wären dabei „Welche Applikationen sind bei der Veränderung eines Prozesses betroffen?“

481 Vgl. Schwinn (2005), S. 20.

482 Vgl. Schwinn (2005), S. 138.


oder „Welche Applikationen (oder Teile davon) können aufgrund weggefallener Prozesse

stillgelegt werden?“.

4.3.2.2 Metamodell des Geschäftsfunktions- und Informationsobjektmodells

Jedes Informationsobjekt bzw. jede Geschäftsfunktion verfügt über eine Begrifflichkeit, die

hinsichtlich eines festzulegenden Standard-Begriffs und seiner Synonyme und Homonyme

mit Hilfe von Gestaltungskriterien harmonisiert wird (vgl. Abbildung 47). Als Erhebungs-

quelle kommen Prozesse, Organisationseinheiten und die Applikationsbestandsführung in

Frage. Die Applikationsbestandsführung verfügt über bereits begrifflich standardisierte In-

formationsobjekte und Geschäftsfunktionen, die anderen Erhebungsquellen jedoch nicht. Die

Informationsobjekte bzw. Geschäftsfunktionen und ihre Beschreibung werden in einem Ge-

schäftsfunktionen- bzw. Informationsobjektmodell dokumentiert. Für das Modell und den

Harmonisierungsprozess wird ein Owner definiert, welcher die Verantwortung für das Infor-

mationsobjekt- bzw. Geschäftsfunktionenmodell übernimmt. Die (unternehmensweit) stan-

dardisierten Informationsobjekte sind Bezugsgrösse und Voraussetzung für die Erstellung der

Integrationsarchitektur sowie für zukünftige Projekte der Applikationsintegration. Die Doku-

mentation der Informationsobjekte und Geschäftsfunktionen ermöglicht zukünftig die einfa-

chere Durchführung von Analysen, die für Integrationsfragestellungen relevant sind.483 Bei-

spielsweise können bei Veränderungen von Informationsobjekten oder Geschäftsfunktionen

(z. B. ein zusätzliches Attribut im Informationsobjekt „Kunde“) Rückschlüsse auf betroffene

Applikationen gezogen werden. Daneben können Redundanzen leichter aufgedeckt werden.

Geschäftsfunktionenmodell

Geschäfts-

funktionBegrifflichkeit

Prozess

Organisat.

Rollenträger

Homonym SynonymStandard-

begriff

Erhebungs-

quelle

Gestaltungs-

kriterium

hat

harmonisiert

*

*

*

*

*

*hat

Abbildung 47: Metamodell des

Geschäftsfunktionen- und Informationsobjektemodells

483 Vgl. hierzu Schwinn (2005), S. 199.


4.3.2.3 Metamodell der Integrationsarchitektur

Die Integrationsarchitektur dokumentiert die Beziehungsstrukturen zwischen den Entitäten

Informationsobjekt, Geschäftsfunktion und Organisationseinheit der Reihe nach in Bezug auf

die unterschiedlichen Beziehungsarten wie beispielsweise Informationsfluss, Datenfluss, Leis-

tungsfluss und Controllingfluss, um die relevanten Integrationsbereiche hervorzuheben. Die-

sen Integrationsbereichen können bestehende oder neu zu entwickelnde Applikationen zuge-

ordnet werden.

Abbildung 48: Metamodell der Integrationsarchitektur

4.3.2.4 Metamodell der Softwarekomponenten und Plattformen

Das in dieser Arbeit vorgeschlagene Metamodell der Softwarekomponenten- und Datenstruk-

turebene richtet sich in Teilen nach dem von SCHWINN definierten Metamodell für Applikati-

onsintegrationsprojekte.484

Die Arbeit von SCHWINN konzentriert sich ausschliesslich auf Integrationsaspekte der Appli-

kations- sowie Softwarekomponenten- und Datenstrukturebene. In der Realität existieren al-

lerdings meist keine reinen Integrationsprojekte oder Integrationsarchitekturen, sondern sie

sind Bestandteil eines umfassenden Projekts oder einer Unternehmensarchitektur. Zudem ist

in der Regel von einem Integrationsprojekt die Gestaltung der Organisations- und in manchen

Fällen auch der Strategieebene betroffen. Deshalb sollten die in seiner Arbeit vorgeschlage-

nen Methodenelemente in vorhandene Methoden bzw. Ansätze zur Gestaltung der Unterneh-

mensarchitektur eingebunden werden.485 Da der Fokus des in der vorliegenden Arbeit präsen-

tierten Ansatzes auf der Definition eines umfassenden Metamodells zur Abbildung der Unter-

484 Vgl. Schwinn (2005).

485 Vgl. Schwinn (2005), S. 242.


nehmensarchitektur liegt, werden lediglich die wesentlichen Metaentitätstypen des Metamo-

dells seiner Methode übernommen und integriert.486 Diese und weitere Metaentitätstypen so-

wie deren Beziehungen werden im Folgenden beschrieben (vgl. Abbildung 49).

Infrastrukturebene

Softwarekomponenten und Datenstrukturen

Applikation

Software-

komponenteDatenobjekt

Daten-

speicherBetriebs-

komponente

Entwicklungs-

technologie

Plattform

Schnittstelle

Owner

Hersteller

Lieferant

Informations-

objekt

Infrastruktur-

element

Standort

Relationale

DatenbankTabelle

wird erstellt mit benötigt für Betrieb

läuft auf läuft aufläuft auf

operiert auf/verwaltet

verbindet

ist

zugeordnet

hat

operiert auf/

verwaltet ist implementiert als

hat

ist installiert auf

wird implementiert

durch

**

*

**

* *

**

**

* *

*

*

*

1

1

1

1

1

1

1

1

11

1 1

1

*

Kommunika-

tionselement

ist installiert auf

1

*

hat

1

* *

ist verbunden

mit

*

besteht aus

**

Abbildung 49: Metamodell der Softwarekomponenten und Datenstrukturen

Eine Applikation auf Applikationsebene wird durch eine oder mehrere Softwarekomponenten

implementiert.487 Eine Softwarekomponente ist ein abgeschlossener Softwarebaustein, der

eine bestimmte Menge an Applikationsfunktionen einer Applikation anbietet. Sie kann als

Ganzes konfiguriert und ausgeliefert werden und bedarf der Wartung.488 Zusätzlich besitzt sie

einen bestimmten Owner, Hersteller sowie Lieferanten. Softwarekomponenten operieren

auf einem/mehreren Datenobjekt(en) oder verwalten ein/mehrere Datenobjekt(e), wobei ein

Datenobjekt eine Kategorie von auf Dauer gespeicherten Daten darstellt, auf die wiederholt

von Softwarekomponenten zurückgegriffen wird. Ein Datenobjekt korrespondiert mit genau

einer Klasse eines UML-Klassendiagramms oder mit einem Datenobjekt einer anderen Da-

tenmodellierungssprache, wie beispielsweise ER-Diagramme.489 Auf der Softwarekomponen-

ten- und Datenstrukturebene repräsentiert ein Datenobjekt ein oder mehrere Informationsob-

jekte oder Teile davon. Es ist genau einem Datenspeicher zugeordnet und wird in diesem auf

Dauer gespeichert. Ein Datenspeicher kann beispielsweise eine relationale oder objektorien-

486 Vgl. im Folgenden Schwinn (2005), S. 127-142 und Schelp/Schwinn (2005).


488 Vgl. Schwinn (2005), S. 85.

489 Vgl. hierzu z.B. auch Jonkers et al. (2004), S. 271.


tierte Datenbank sein. Jede Softwarekomponente benötigt für den Betrieb eine Betriebskom-

ponente.490 Sie stellt die unmittelbare Run-Time-Umgebung einer Softwarekomponente dar.

Für die Erstellung einer Softwarekomponente wird eine bestimmte Entwicklungstechnologie

(z.B. J2EE oder .NET) benötigt. Softwarekomponenten, Betriebskomponenten sowie Ent-

wicklungstechnologien laufen auf einer bestimmten Plattform, wie beispielsweise Windows

oder Unix. Softwarekomponenten sowie Datenobjekte können durch eine Schnittstelle mit-

einander verbunden sein.

Die detaillierte Abbildung der IT-Infrastruktur (z.B. Server, Router etc.) ist nicht von zentra-

ler Bedeutung für die Unternehmensarchitektur. Stattdessen sollten dafür bereits existierende

Ansätze und Werkzeuge für das IT-Portfoliomanagement zum Einsatz kommen.491 Da aller-

dings zu diesen Werkzeugen und deren zugrunde liegenden Konzepten Anknüpfungspunkte

definiert sein müssen, um beispielsweise die Konsistenz der Informationen gewährleisten so-

wie Impact-Analysen durchführen zu können, wird in Abschnitt 4.4 ein Infrastrukturmodell

mit den Metaentitätstypen „Infrastrukturelement“ und „Kommunikationselement“ eingeführt.

Für ausgewählte Softwarekomponenten und Plattformen kann somit dokumentiert werden,

auf welchen Infrastrukturelementen diese installiert sind. Dadurch lassen sich die Auswirkun-

gen eines Ausfalls eines bestimmten Infrastruktur- oder Kommunikationselements analysieren

und vorhersagen.

4.3.2.5 Metamodell des Datenstrukturmodells

Informationsobjekte werden in Form von Datenobjekten implementiert. Für die Modellierung

der Datenobjekte sowie deren Beziehungen, d.h. der detaillierten Datenstruktur eines fachli-

chen Anwendungsbereichs, werden in der Regel objektorientierte Klassendiagramme, wie

beispielsweise UML-Klassendiagramme492, oder ER-Diagramme493 verwendet.

In diesem Ansatz kommen UML-Klassendiagramme für die Abbildung der Datenstrukturen

zum Einsatz, da sich die UML als führender Notationsstandard in Praxis und Wissenschaft

etabliert hat.494 Ausserdem werden auch bereits die Metamodelle und Vorgehensmodelle die-

ser Arbeit mit Hilfe der UML dargestellt. Sie kommt somit im Rahmen dieser Arbeit sowohl

als Modellierungs- als auch als Metamodellierungssprache zum Einsatz.

Wie bereits in Abschnitt 2.2.4 beschrieben, bietet ein UML-Klassendiagramm die Möglich-

keit, die statische Struktur eines Systems darzustellen. Es zeigt dessen wesentliche statische

Eigenschaften sowie ihre Beziehungen zueinander. Das zentrale Konzept sind Klassen. Eine

490 Vgl. Schwinn (2005), S. 85.

491 Vgl. hierzu z.B. Adams (2005).

492 Für eine detaillierte Darstellung des Metamodells von UML-Klassendiagrammen vgl. z.B. OMG (2005).

493 Für eine detaillierte Darstellung des Metamodells von ER-Diagrammen vgl. z.B. Chen (1976) und Scheer

(2001), S. 72. 494

Vgl. z.B. Balzert (2000), S. V.


Klasse wird in der UML 2 als eine Sammlung von Exemplaren bzw. Objekten definiert, die

über gemeinsame Eigenschaften, Einschränkungen und eine gemeinsame Semantik verfü-

gen.495 Jede Klasse stellt demnach einen abstrahierten Sammelbegriff für eine Menge gleich-

artiger Dinge bzw. Objekte dar.496 Jede Klasse besitzt Attribute, Operationen und Beziehun-

gen (vgl. Abbildung 50).

Abbildung 50: Vereinfachtes Metamodell des UML-Klassendiagramms

Attribute beschreiben bestimmte Charakteristika einer Klasse. Eine Operation definiert Na-

me, Typ und Parameter für den Aufruf des internen Verhaltens von Objekten einer Klasse und

bietet somit den Anknüpfungspunkt zu den Verhaltensdiagrammen der UML, die die dynami-

schen Konstrukte eines Systems beschreiben (z.B. Aktivitäten, Interaktionen etc.). Klassen

können über Assoziationen miteinander verbunden sein.

Eine Assoziation beschreibt eine Menge semantisch gleichartiger Beziehungen zwischen

zwei oder mehreren Klassen. Eine Assoziation wird weiter spezialisiert in eine Aggregation,

Komposition und Generalisierung. Jede Assoziation besitzt zwei oder mehrere Assoziati-

onsenden, für die eine Multiplizität definiert sein kann.

Die in Form eines oder mehrerer objektorientierter Klassendiagramme detailliert abgebildete

Datenstruktur eines fachlichen Anwendungsbereichs kann als Vorlage für die softwaretechni-

sche Implementierung dienen.

4.3.2.6 Metamodell der Autorisierung

Durch die zunehmende softwaretechnische Unterstützung von Geschäftsprozessen kann ein

Ausfall von Informationssystemen oder der unerwünschte Zugriff auf unternehmensinterne

Daten zu erheblichen Geschäftseinbussen führen. Die Informationssysteme und deren Daten

müssen daher entsprechend geschützt werden. Die Autorisierung stellt ein wichtiges Konzept

495 Vgl. OMG (2005), S. 45.

496 Vgl. Jeckle et al. (2004b), S. 32.


für die Gewährleistung der Sicherheit von Informationssystemen in einem Unternehmen dar

und sollte daher auch Bestandteil einer Unternehmensarchitektur sein.497

Der Begriff Autorisierung bezeichnet die Verwaltung und Kontrolle von Zugriffsrechten.498

Synonym wird oftmals der Begriff Zugriffskontrolle verwendet. Die Kontrolle bzw. Überprü-

fung von Zugriffsrechten umfasst die Behandlung von Zugriffen auf Informationssysteme und

Daten und deren Gewährung oder Zurückweisung entsprechend den definierten Rechten.499

Die Verwaltung von Zugriffsrechten umfasst dagegen das Erteilen, Entziehen und Pflegen

von Zugriffsrechten.500

Die zuvor definierten Modelle der Aufbau- und Ablauforganisation auf Organisationsebene

sowie die Modelle der Softwarekomponenten und Datenstrukturen bilden die Basis für die

Vergabe von Zugriffsberechtigungen. Anknüpfungspunkte des Metamodells der Autorisie-

rung zu diesen Modellen sind die Metaentitätstypen menschlicher Rollenträger und Prozess-

rolle der Aufbauorganisation, Aktivität der Ablauforganisation sowie die Metaentitätstypen

Softwarekomponente, Applikationsfunktion und Datenobjekt des SW-Komponenten- und

Datenstrukturmodells. Diese Metaentitätstypen werden nun im Autorisierungsmodell mit den

Metaentitätstypen Benutzerkonto, Ressource, Berechtigung und Berechtigungskonzept in Be-

ziehung gesetzt.501 Das Metamodell der Autorisierung definiert somit eine ebenenübergrei-

fende Sicht, die Elemente der Informationssystem- und Organisationsebene enthält (vgl.

Abbildung 51).

Autorisierung

Rollenträger

Berechtigung

Berecht.-

konzept

Benutzer-

konto

Autoris.-

komponenteDatenobjekt

Methode

AktivitätSoftware-

komponenteProzessrolle

Ressource

nimmt

wahr

führt

durchunterstützt

verfügt

über

setzt in Bezug

zueinander

bezieht

sich aufbenötigt

bezieht

sich auf

bezieht

sich auf

operiert auf

* * ***

*

*

*

*

*** *

*

* *

* * * * * *

*

*

ist Input/Output

von

ist

zugeordnetumfasst

1

1

wird verwaltet/

umgesetzt mittels

*

*

Abbildung 51: Metamodell der Autorisierung502

497 Vgl. im Folgenden Wortmann (2005), S. 123-125.

498 Vgl. Jonscher/Dittrich (1994), S. 27.

499 Vgl. Samarati/de Capitani di Vimercati (2002), S. 137.

500 Vgl. Rupprecht (2002), S. 22.

501 Vgl. Wortmann (2005), S. 123.

502 Vgl. Wortmann (2005), S. 123.


Damit die menschlichen Rollenträger die informationstechnisch unterstützten Aktivitäten ei-

nes Prozesses durchführen können, müssen sie über entsprechende (System-)Berechtigungen

verfügen.503 Diese Berechtigungen regeln den Zugriff auf die Methoden und Datenobjekte der

existierenden Softwarekomponenten und werden über Benutzerkonten den Rollenträgern zu-

geordnet. Eine Berechtigung ermöglicht somit die Ausführung einer bestimmten Methode

auf einem bestimmten geschützten Datenobjekt.504 Jeder Rollenträger verfügt über kein, ein

oder mehrere Benutzerkonto/en, wobei jedem Benutzerkonto eine oder mehrere Ressource/n

zugeordnet sein können.

Ein Benutzerkonto repräsentiert eine Person im Informationssystem.505 Eine Ressource ist ein

intermediäres Konstrukt, das für die Zuweisung der Berechtigungen zu Benutzerkonten ver-

wendet wird.506 Das Berechtigungskonzept setzt die einzelnen Berechtigungen miteinander

in Beziehung und legt damit fest, welcher Benutzer auf welche Methode bzw. auf welches

Datenobjekt zugreifen darf. Die im Berechtigungskonzept definierten Regelungen werden

informationstechnisch in einer Autorisierungskomponente abgebildet und verwaltet.

4.3.2.7 Definition der Metaentitätstypen auf Informationssystemebene

Die folgende Tabelle 12 spezifiziert die im vorhergehenden Abschnitt beschriebenen

Metaentitätstypen sowie deren Beziehungen im Detail.

Applikation

Definition Eine Applikation enthält Applikationsfunktionen, die eine oder mehrere Funktion/en auf Basis von Informationstechnologie realisieren. Die Zusammenfassung mehrerer Applika-

tionsfunktionen und ihrer Operationen auf Informationsobjekten bildet die Applikation.507

Informati-onsobjekt

Eine Applikation verwaltet/operiert auf einem oder mehreren Informati-onsobjekt/en.

Applikations-funktion

Eine Applikation beinhaltet eine oder mehrere Applikationsfunktion/en.

Software-komponente

Eine Applikation wird durch eine oder mehrere Softwarekomponente/n implementiert.

Applikati-onsdomäne

Eine Applikation ist genau einer Applikationsdomäne zugeordnet.

Beziehungen zu

Owner Eine Applikation besitzt eine Organisationseinheit als Owner.

Applikationsdomäne

Definition Eine Applikationsdomäne ist eine logische Zusammenfassung von Applikationen. Appli-kationsdomänen werden zur Beherrschung der Komplexität gebildet und sind unabhängig

von konkreten Applikationen und Softwarekomponenten.508

503 Vgl. Wortmann (2005), S. 123.

504 Vgl. Ferraiolo et al. (2001), S. 233.

505 Vgl. Kern et al. (2002), S. 46.

506 Für eine genaue Definition und Begründung für die Einführung dieses Metaentitätstyps vgl. Wortmann

(2005), S. 123. 507

Vgl. Schwinn (2005), S. 130. 508

Vgl. Schwinn (2005), S. 74. Synonym für eine Applikationsdomäne werden häufig die Begriffe „logische Einheit“ (vgl. Lankes et al. (2005), S. 1445) oder „Building Block“ (Vgl. Jung (2004), S. 313) verwendet.


Applikation Eine Applikationsdomäne umfasst eine oder mehrere Applikation/en.

Prozess Eine Applikationsdomäne unterstützt einen oder mehrere Geschäftspro-zess/e auf Organisationsebene. Beziehungen zu

OE Einer Applikationsdomäne ist eine verantwortliche Organisationseinheit zugeordnet.

Applikationsfunktion

Definition Eine Applikationsfunktion ist eine von einer bestimmten Applikation realisierte Funktion.

Geschäfts-funktion

Eine Applikationsfunktion realisiert eine oder mehrere Geschäftsfunkti-on/en auf Organisationsebene. Beziehungen zu

Applikation Eine Applikationsfunktion ist Teil einer Applikation.

Assoziation

Definition Eine Assoziation beschreibt eine Menge semantisch gleichartiger Beziehungen zwischen

zwei oder mehreren Klassen.509

Beziehungen Assoziation-sende

Eine Assoziation besitzt zwei oder mehrere Assoziationsenden.

Autorisierungskomponente

Definition Eine Autorisierungskomponente ist eine Softwarekomponente, die Funktionalitäten zur Verwaltung und/oder Kontrolle von Berechtigungen

bereitstellt.510

Beziehungen zu Berechti-gungskon-zept

Eine Autorisierungskomponente implementiert und verwaltet ein oder mehrere Berechtigungskonzept/e.

Benutzerkonto

Definition Ein Benutzerkonto repräsentiert eine bestimmte Person, Stelle oder Rolle im Informations-

system.511

Beziehungen zu Rollenträger Ein Benutzerkonto ist einem bestimmten Rollenträger auf Organisations-ebene zugeordnet.

Berechtigung

Definition Eine Berechtigung ermöglicht die Ausführung einer Methode auf

einem geschützten Datenobjekt.512

Aktivität Eine Berechtigung wird für die Durchführung einer oder mehrerer Aktivi-tät/en benötigt.

Datenobjekt Eine Berechtigung bezieht sich auf ein oder mehrere geschützte Datenob-jekt/e.

Beziehungen zu

Methode Eine Berechtigung bezieht sich auf eine oder mehrere geschützte Metho-de/n.

Berechtigungskonzept

Definition Ein Berechtigungskonzept legt fest, welcher Benutzer auf welche

Methoden und/oder Datenobjekte zugreifen darf.513

Autorisie-rungskompo-nente

Ein Berechtigungskonzept wird in einer oder mehreren Autorisierungs-komponente/n umgesetzt und verwaltet.

Beziehungen zu

Berechtigung Ein Berechtigungskonzept setzt mehrere Berechtigungen in Bezug zuein-ander.

509 Vgl. OMG (2005), S. 36.

510 Vgl. Wortmann (2005), S. 124.

511 Vgl. Kern et al. (2002), S. 46.

512 Vgl. Ferraiolo et al. (2001), S. 233.

513 Vgl. Seufert (2001), S. 31f.


Betriebskomponente

Definition Eine Betriebskomponente ist ein technisches System (Subsystem), welches die unmittelba-re Run-Time-Umgebung einer Softwarekomponente bildet.

Plattform Eine Betriebskomponente läuft auf einer bestimmten Plattform. Beziehungen zu Software-

komponente Eine Betriebskomponente unterstützt den Betrieb einer oder mehrerer Softwarekomponente/n.

Beziehungsstruktur

Definition Eine Beziehungsstruktur beschreibt den Leistungs-, Informations- und Kontrollfluss zwi-schen Geschäftsfunktionen, Informationsobjekten und Prozes-

sen/Organisationseinheiten/Leistungstypen.514

Beziehungen zu Integrationsbereich Aus einer Beziehungsstruktur werden ein oder mehrere Integrati-onsbereich/e abgeleitet.

Datenobjekt

Definition Ein Datenobjekt stellt eine Kategorie von auf Dauer gespeicherten Daten dar, auf die wie-

derholt von Softwarekomponenten zurückgegriffen wird.515

Informationsobjekt Ein Datenobjekt repräsentiert auf der Softwarekomponenten- und Datenstrukturebene ein oder mehrere Informationsobjekt/e oder Teile davon.

Softwarekomponente Ein Datenobjekt kann von einer oder mehreren Softwarekompo-nente/n manipuliert werden.

Datenspeicher Ein Datenobjekt ist genau einem Datenspeicher zugeordnet.

Methode Eine Methode verwendet/erzeugt ein oder mehrere Datenob-jekt/e.

Beziehungen zu

Klasse Ein Datenobjekt korrespondiert mit genau einer Klasse.

Datenspeicher

Definition Ein Datenspeicher ermöglicht die dauerhafte Speicherung von Datenobjekten.

Beziehungen zu Datenspeicherobjekt Ein Datenspeicher enthält mehrere dauerhaft gespeicherte Daten-objekte.

Entwicklungstechnologie

Definition Eine Entwicklungstechnologie, z. B. J2EE/.NET, eignet sich für die Erstellung von Soft-warekomponenten.

Plattform Eine Entwicklungstechnologie läuft auf einer Plattform. Beziehungen zu Software-

komponente Eine Entwicklungsplattform unterstützt die Erstellung einer oder mehrerer Softwarekomponente/n.

Informationsobjekt

Definition Ein Informationsobjekt stellt eine Sammlung von auf Dauer gespeicherten

Informationen dar, auf die wiederholt zurückgegriffen wird.516

Applikation Ein Informationsobjekt ist einer verwaltenden und einer oder mehreren operierenden Applikation/en zugeordnet.

Beziehungen zu

Datenobjekt Ein Informationsobjekt wird auf der Softwarekomponenten- und Datenstrukturebene als ein oder mehrere Datenobjekt/e repräsen-tiert.

514 Es wird dabei vorausgesetzt, dass Leistungstypen in einem prozessorientiert organisierten Unternehmen mit

Organisationseinheiten bzw. Prozessen korrespondieren. Vgl. hierzu Winter (2006), S. 12. 515

Vgl. Schwinn (2005), S. 23. 516

Vgl. Schwinn (2005), S. 138.


Integrationsbereich

Definition Ein Integrationsbereich umfasst Informationsobjekte, Geschäftsfunktionen und Organisa-

tionseinheiten/Prozesse, die eine enge Beziehungsstruktur besitzen.517

Beziehungen zu Beziehungsstruktur Ein Integrationsbereich wird aus einer oder mehreren Bezie-hungsstruktur/en abgeleitet.

Applikation Einem Integrationsbereich ist eine Applikation zugeordnet.

Klasse

Definition Eine Klasse repräsentiert eine Sammlung von Exemplaren bzw. Objekten, die über ge-

meinsame Eigenschaften, Einschränkungen und eine gemeinsame Semantik verfügen.518

Attribut Eine Klasse besitzt ein oder mehrere Attribut/e.

Operation Eine Klasse besitzt eine oder mehrere Operation/en.

Datenobjekt Eine Klasse korrespondiert mit genau einem Datenobjekt. Beziehungen zu

Assoziationsende Eine Klasse ist das Ziel eines Assoziationsendes oder mehrerer.

Methode

Definition Eine Methode implementiert eine bestimmte Funktionalität einer Softwarekomponente

und stellt diese nach aussen hin zur Verfügung.519

Softwarekomponente Eine Methode ist Teil einer Softwarekomponente.

Datenobjekt Eine Methode verwendet/erzeugt ein oder mehrere Datenob-jekt/e.

Berechtigung Auf eine Methode bezieht/beziehen sich eine oder mehrere Be-rechtigung/en.

Beziehungen zu

Operation Eine Methode ruft eine oder mehrere Operation/en zur Manipula-tion von Datenobjekten auf.

Operation

Definition Eine Operation definiert das Verhalten einer Klasse bzw. deren Instanzen. Sie wird durch

ihre Signatur (Operationsname, Parameter, Rückgabewert) beschrieben.520

Klasse Eine Operation ist genau einer Klasse zugeordnet. Beziehungen zu

Methode Eine Operation wird von einer oder mehreren Methode/n aufge-rufen.

Owner

Definition Ein Owner ist eine Organisationseinheit, eine Stelle oder eine Person, die für ein bestimm-tes Element der Systemebene (z.B. Applikation, Softwarekomponente, Informationsobjekt, Datenspeicher) verantwortlich ist.

Applikation Ein Owner ist für eine oder mehrere Applikation/en verantwort-lich.

Softwarekomponente Ein Owner ist für eine oder mehrere Softwarekomponente/n verantwortlich.

Beziehungen zu

Datenspeicher Ein Owner ist für einen oder mehrere Datenspeicher verantwort-lich.

517 Vgl. Winter (2006), S. 17-20.

518 Vgl. OMG (2005), S. 45.

519 Vgl. Schwinn (2005), S. 22.

520 Vgl. OMG (2005), S. 99.


Plattform

Definition Betriebskomponenten und Entwicklungstechnologien laufen auf Plattformen. Beispiele für Plattformen sind OS/390, Windows oder Unix.

Softwarekomponente Auf einer Plattform laufen eine oder mehrere Softwarekompo-nente/n. Beziehungen zu

Infrastrukturelement Eine Plattform ist auf einem Infrastrukturelement installiert.

Schnittstelle

Definition Eine Schnittstelle beschreibt, wie von aussen auf Softwarekomponenten, Applikations-funktionen oder Datenobjekte zugegriffen werden kann.

Applikationsfunktion Eine Schnittstelle kann von einer Applikationsfunktion angebo-ten werden.

Softwarekomponente Eine Schnittstelle kann von einer Softwarekomponente angebo-ten werden.

Beziehungen zu

Datenobjekt Eine Schnittstelle kann von einem Datenobjekt angeboten wer-den.

Softwarekomponente

Definition Eine Softwarekomponente ist ein abgeschlossener Softwarebaustein, der eine bestimmte Menge an Applikationsfunktionen einer Applikation anbietet.

Betriebskomponente Eine Softwarekomponente benötigt für den Betrieb eine Be-triebskomponente.

Entwicklungstechno-logie

Eine Softwarekomponente wird mit einer Entwicklungstechnolo-gie entwickelt.

Applikation Eine Softwarekomponente ist Teil einer oder mehrerer Applika-tion/en.

Datenobjekt Eine Softwarekomponente operiert auf/verwaltet Datenobjekte/n.

Methode Eine Softwarekomponente enthält eine oder mehrere Methode/n, die Datenobjekte verwenden/erzeugen.

Beziehungen zu

Plattform Eine Softwarekomponente läuft auf einer Plattform.

Tabelle 12: Metaentitätstypen der Informationssystemebene

4.3.2.8 Festlegung der verwendeten Symbole auf Informationssystemebene

Die folgende Tabelle 13 zeigt die Notationselemente (Symbole) für die auf

Organisationsebene definierten Metaentitäts- und Beziehungstypen. Metaentitätstypen ohne

zugeordnetes Notationselement werden wiederum lediglich textuell erfasst.

Symbole der Informationssystemebene

Applikation Applikationsdomäne Applikationsfunktion

Benutzerkonto Betriebskomponente Datenobjekt


Datenspeicher Entwicklungstechnologie Geschäftsfunktion

Informationsobjekt Integrationsbereich Klasse

Plattform Schnittstelle Softwarekomponente

Datenfluss

(zw. SW-Komponente/Datenspeicher

und Schnittstelle)

Informationsfluss

(von Applikation zu Applikation)

ist zugeordnet

(von Integrationsbereich zu

Applikation)

Generalisierung

(von Klasse zu Klasse)

Assoziation


Aggregation


Tabelle 13: Symbole der Informationssystemebene

Analog zur Strategie- und Organisationsebene handelt es sich bei Beziehungstypen ohne

zugeordnetes Notationselement um eine modellübergreifende Beziehung (z.B. zwischen

„Applikation“ und „Informationsobjekt“) oder um eine Aggregationsbeziehung (z.B.

zwischen „Applikationsdomäne“ und „Applikation“).

4.4 Modellierung auf Infrastrukturebene

Die IT-Infrastruktur eines Unternehmens ist der Ausschnitt der Informationstechnik

(Computer- und Kommunikationstechnik), der in einem Unternehmen zum Einsatz kommt.521

Sie ist im engeren Sinne nicht mehr Betrachtungsgegenstand des Business Engineering (vgl.

Abschnitt 2.3.2). Die im Grundlagenteil durchgeführte Analyse der Literatur zum Thema

Unternehmensarchitektur (vgl. Abschnitt 2.3.1) sowie die Diskussion existierender

Bezugsrahmen in der Praxis (vgl. Abschnitt 3.3) haben allerdings gezeigt, dass die

eingesetzten Infrastrukturelemente (z.B. Server, Workstations, Netzwerkkomponenten etc.)

sowie deren Beziehungen einen wichtigen Bestandteil einer Unternehmensarchitektur

darstellen. Gerade im Hinblick auf die spätere Durchführung so genannter Impact-Analysen

521 Vgl. Brenner (1994).


ist die Dokumentation der auf einem Infrastrukturelement installierten Softwarekomponenten

und Plattformen erforderlich. Dadurch lässt sich beispielsweise feststellen, welche anderen

Elemente und Bereiche der Unternehmensarchitektur durch den Ausfall eines bestimmten

Infrastrukturelements betroffen sind.

Für die detaillierte Abbildung der zugrunde liegenden Infrastruktur existieren bereits

zahlreiche Modelle, Methoden und Werkzeuge (z.B. für das IT-Portfoliomanagement522).

Diese sollten auch weiterhin im Unternehmen zum Einsatz kommen. Um einen

Anknüpfungspunkt zu den Detailmodellen herzustellen, werden auf der Infrastrukturebene die

beiden Metaentitätstypen „Infrastrukturelement“ und „Kommunikationselement“ eingeführt

(vgl. Abbildung 52).

Abbildung 52: Metamodell des Infrastrukturmodells

Ein Infrastrukturelement bezeichnet einen Computer bzw. alle festen Bestandteile eines

Computers inklusive der Peripherie. Unter Peripheriegeräten werden alle Geräte, die an einen

Computer angeschlossen werden können, verstanden. Hierzu zählen z.B. Drucker, Monitor,

Tastatur, Maus, Modem, Scanner etc. Auf einem Infrastrukturelement können mehrere

Softwarekomponenten und Plattformen installiert sein. Infrastrukturelemente sind über

Kommunikationselemente miteinander verbunden. Ein Kommunikationselement bezeichnet

ein Netzwerkelement, das die Schnittstelle zwischen Infrastrukturelementen (z.B. zwischen

Clients und Servern) bzw. zwischen räumlich getrennten Netzwerken bildet. Zu übermittelnde

Daten werden über Kommunikationselemente und Datenleitungen an den Empfänger

(Infrastrukturelement) versandt. Die folgende Tabelle 14 fasst die Metaentitätstypen der

Infrastrukturebene sowie deren Beziehungen zusammen.

Infrastrukturelement

Definition

Ein Infrastrukturelement bezeichnet einen Computer bzw. alle festen Bestandteile eines Computers inklusive der Peripherie. Unter Peripheriegeräten werden alle Geräte, die an einen Computer angeschlossen werden können, verstanden. Hierzu zählen z.B. Drucker, Monitor, Tastatur, Maus, Modem, Scanner usw.

Beziehungen zu Kommunikations-element

Ein Infrastrukturelement ist mit keinem, einem oder mehreren Kommunikationselement/en verbunden.

522 Für einen Überblick über Werkzeuge für das IT-Portfoliomanagement vgl. z.B. Adams (2005).


IT-Service Ein Infrastrukturelement ist Teil eines oder mehrerer IT-

Services.523

Plattform Auf einem Infrastrukturelement ist/sind eine oder mehrere Platt-form/en installiert.

Softwarekomponente Auf einem Infrastrukturelement ist/sind eine oder mehrere Soft-warekomponent/en installiert.

Standort Ein Infrastrukturelement hat einen bestimmten Standort.

Kommunikationselement

Definition

Ein Kommunikationselement bezeichnet ein Netzwerkelement, das die Schnittstelle zwi-schen Computern (z.B. zwischen Clients und Servern) bzw. zwischen räumlich getrennten Netzwerken bildet. Zu übermittelnde Daten werden über Kommunikationselemente und Datenleitungen an den Empfänger (Computer) versandt.

Infrastrukturelement Ein Kommunikationselement ist mit keinem, einem oder mehre-ren Infrastrukturelement/en verbunden.

IT-Service Ein Kommunikationselement ist Teil eines oder mehrerer IT-

Services.524

Beziehungen zu

Standort Ein Kommunikationselement hat einen bestimmten Standort.

Tabelle 14: Metaentitätstypen der Infrastrukturebene

Für die Darstellung der auf Infrastrukturebene definierten Metaentitäts- und Beziehungstypen

können die in Tabelle 15 dargestellten Symbole verwendet werden.

Symbole der Infrastrukturebene

Infrastrukturelement Kommunikationselement ist verbunden mit

(von I-Element zu K-Element)

Tabelle 15: Symbole der Infrastrukturebene

4.5 Vorschlag zur Integration serviceorientierter Konzepte

Die Kundenorientierung stellt für heutige Betreiber der IT eine der wichtigsten strategischen

Ausrichtungen im Rahmen des strategischen IT-Managements dar.525 Sowohl externe IT-

Betreiber als auch interne IT-Abteilungen treten nicht mehr als reine Technologieanbieter auf,

sondern positionieren sich zunehmend als Dienstleister gegenüber Anwendern von IT. Diese

Anwender fragen als Dienstnehmer im Rahmen der Durchführung ihrer Aktivitäten innerhalb

der Geschäftsprozesse nach informationsverarbeitender Funktionalität mit einer definierten

Qualität.526 Die Kooperation zwischen IT-Dienstleister und Dienstnehmer wird dabei durch so

523 Vgl. hierzu Abschnitt 4.5.


525 Vgl. Hochstein/Hunziker (2003), S. 46.

526 Vgl. Mayerl et al. (2005), S. 1.


genannte IT-Services gestaltet, für die bestimmte Leistungs- und Qualitätsmerkmale verhan-

delt und in Form von Service Level Agreements (SLA) vertraglich festgelegt werden. Die

vertragliche Festlegung von SLAs ist unabhängig davon, ob der IT-Anwender bzw. Dienst-

nehmer die Leistungen von einer internen IT-Abteilung oder einem externen IT-

Dienstleistungsunternehmen bezieht.

Dieser Wandel von einem technologieorientierten IT-Betreiber zu einem kundenorientierten

IT-Dienstleister mit einer methodischen Gestaltung der internen IT-Prozesse kann nur mit

Hilfe eines serviceorientierten IT-Management vollzogen werden.527 Mittlerweile existiert

eine Reihe von serviceorientierten Referenzmodellen für das IT-Management. Die wohl um-

fangreichste Sammlung von Vorgehensbeschreibungen im Bereich IT Service Management

(ITSM) und den internationalen De-facto-Standard für IT-Dienstleister stellt die IT Infrastruc-

ture Library (ITIL) dar.528 Dabei handelt es sich um ein generisches Referenzmodell, mit dem

IT-Leistungen geplant, überwacht und gesteuert werden können.529 Die wichtigsten Kompo-

nenten sind „Service Delivery“ und „Application Management“ auf der taktischen Ebene so-

wie „Service Support“ und „ ICT Infrastructure Management“ auf der operativen Ebene. Bei-

träge für die Bereitstellung von IT-Services liefert ITIL mit den Empfehlungen zum Service

Support und Service Delivery, und hier insbesondere mit der Definition des Prozesses für das

Service Level Management (SLM).

Eine strukturiert entwickelte und klar dokumentierte Unternehmensarchitektur bildet eine

wertvolle Grundlage für das IT-Service-Management.530 IT-Verantwortliche können mit ihrer

Hilfe einen klaren Blick auf die IT-Infrastruktur und Applikationen, die unterstützten Ge-

schäftsprozesse sowie auf die unterschiedlichen Abhängigkeiten zwischen diesen Bereichen

erhalten. Davon profitieren nahezu alle in ITIL definierten Kernprozesse. Um effiziente und

effektive Betriebsprozesse gewährleisten zu können, sollten deshalb die Schlüsselelemente

des ITSM, wie beispielsweise IT-Services, SLAs und IT-Service-Prozesse sowie deren Be-

ziehungen zu anderen Bereichen und Elementen der Unternehmensarchitektur, dokumentiert

sein. Im Folgenden wird daher ein Metamodell für eine IT-Servicesicht vorgeschlagen (vgl.

Abbildung 53) und mit den anderen in dieser Arbeit definierten Sichten auf die Unterneh-

mensarchitektur integriert (vgl. Abbildung 54). In Tabelle 16 werden die Metaentitätstypen

der IT-Servicesicht sowie deren Beziehungen genauer spezifiziert.

Ein IT-Service stellt eine Menge zusammengehörender Dienstleistungen dar, die von einem

IT-System oder der IT-Abteilung bzw. einem externen IT-Dienstleister bereitgestellt werden,

um die Geschäftsprozesse des Unternehmens oder Kunden zu unterstützen.531 IT-Services

527 Vgl. Hochstein/Hunziker (2003), S. 46 und Hochstein et al. (2004), S. 68.

528 Vgl. Commerce (2000).

529 Vgl. Hochstein/Hunziker (2003), S. 50.

530 Vgl. Lankhorst (2005), S. 17-18 und IFEAD (2005), S. 17.

531 Vgl. z.B. Commerce (2000) und Zarnekow et al. (2005).


variieren in ihrer Ausprägung sehr stark. Sie können sowohl aus einzelnen Softwarekompo-

nenten (bzw. deren Funktionalitäten) als auch aus kompletten Bündeln bestehen. Diese Bün-

del enthalten heterogene Servicekomponenten, wie beispielsweise Softwarekomponenten,

Infrastrukturelemente und entsprechende Zusatzdienste. Die Zusatzdienste umfassen in der

Regel Informations-, Beratungs-, Schulungs-, Problembehebungs- sowie Änderungsdurchfüh-

rungsleistungen und werden durch definierte Betriebsprozesse (IT-Service-Prozesse) inner-

halb der IT-Abteilung bzw. des externen IT-Dienstleisters erbracht.532 Ein IT-Service-Prozess

stellt somit, im Sinne von zu erbringenden Dienstleistungen, eine Teilkomponente des IT-

Services dar. Die von einem IT-Dienstleister angebotenen IT-Services werden in einem Ser-

vicekatalog mit entsprechenden Kostenangaben erfasst.533 Analog zu den Geschäftsprozessen

und Applikationen ist jedem IT-Service eine verantwortliche Organisationseinheit zugeord-

net.

Abbildung 53: Metamodell der IT-Servicesicht

Ein Service Level Agreement (SLA) ist eine schriftliche Vereinbarung zwischen dem Servi-

ce-Lieferanten und dem Kunden, welche die für den IT-Service vereinbarten Service Level

dokumentiert.534 Ein Service Level ist wiederum ein (Qualitäts-)Merkmal eines bereitgestell-

ten IT-Services (wie bspw. Service-Zeiten, Verfügbarkeitsrate und Antwortzeiten). Nach Ab-

schluss von SLAs steht ein IT-Dienstleister in der Pflicht, die definierten Services mit der

vereinbarten Qualität (Service Levels) den jeweiligen Dienstnehmern zur Verfügung zu stel-

532 Vgl. z.B. Hegering et al. (1999).

533 Vgl. Mayerl et al. (2005).

534 Vgl. Dan et al. (2004), S. 136.


len.535 Nach ITIL können für verschiedene beteiligte Partner neben SLAs weitere vertragliche

Vereinbarungen, wie Operational Level Agreement (OLA) und Underpinning Contract, unter-

schieden werden.

IT-Service

Definition Ein IT-Service stellt eine Menge zusammengehörender Dienstleistungen dar, die von ei-nem IT-System oder der IT-Abteilung bzw. einem externen IT-Dienstleister bereitgestellt

werden, um die Geschäftsprozesse des Unternehmens zu unterstützen. 536

Infrastrukturelement Ein IT-Service umfasst ein oder mehrere Infrastrukturelement/e.

IT-Dienstleister Ein IT-Service wird von einem oder mehreren IT-Dienstleister/n erbracht/unterstützt.

IT-Service-Prozess Ein IT-Service wird von einem oder mehreren IT-Service-Prozess/en erzeugt/verwendet.

Marktleistung Ein IT-Service kann Teil einer oder mehrerer Marktleistung/en sein.

Organisationseinheit Ein IT-Service wird von einer Organisationseinheit verantwor-tet/kontrolliert.

Service Level Agreement (SLA)

Ein IT-Service wird von einem SLA definiert.

Beziehungen zu

Softwarekomponente Ein IT-Service umfasst eine oder mehrere Softwarekompo-nent/en.

IT-Service-Prozess

Definition Ein IT-Service-Prozess beschreibt einen Betriebsprozess innerhalb der IT-Abteilung bzw. des IT-Dienstleisters zur Erzeugung bestimmter Zusatzdienste eines IT-Services.

IT-Service Ein IT-Service-Prozess erzeugt/verwendet einen oder mehrere IT-Service/s.

Beziehungen zu IT-Dienstleister

Ein IT-Service-Prozess wird von einem externen IT-Dienstleister bzw. der internen IT-Abteilung durchgeführt.

Servicekatalog

Definition Ein Servicekatalog erfasst die von einem IT-Dienstleister angebotenen IT-Services mit

entsprechenden Kostenangaben.537

IT-Service Ein Servicekatalog umfasst mehrere IT-Services. Beziehungen zu

Organisationseinheit Ein Servicekatalog wird von einer Organisationseinheit verwaltet.

Service Level

Definition Ein Service Level beschreibt ein (Qualitäts-)Merkmal eines bereitgestellten IT-

Services.538

Beziehungen zu Service Level Agreement

Ein Service Level ist Teil eines Service Level Agreements.


536 Vgl. Commerce (2000).


538 Vgl. Dan et al. (2004), S. 84.


Service Level Agreement (SLA)

Definition Ein Service Level Agreement (SLA) ist eine schriftliche Vereinbarung zwischen dem Service-Lieferanten (externer IT-Dienstleister oder IT-Abteilung) und dem Kunden, die

die für den IT-Service vereinbarten Service Levels dokumentiert.539

IT-Service Ein SLA definiert einen bestimmten IT-Service. Beziehungen zu

Service Level Ein SLA umfasst mehrere Service Levels.

Tabelle 16: Metaentitätstypen der IT-Servicesicht

Ein IT-Service wird durch einen IT-Service-Prozess erbracht und stellt folglich eine Prozess-

leistung im Sinne der bereits in der Ablaufplanung definierten Prozessleistung dar. Prozess-

leistungen sind das Ergebnis (der Output) der Leistungserstellung eines Prozesses, in diesem

Fall eines IT-Service-Prozesses, das an interne oder externe Kunden geht. Empfänger einer

Prozessleistung ist ein anderer Prozess innerhalb oder ausserhalb der Unternehmung. Ist der

Leistungsempfänger ein Prozess ausserhalb der eigenen Unternehmung, ist eine Prozessleis-

tung Teil einer Marktleistung.540 Somit können die von einer IT-Abteilung erbrachten IT-

Services auch Teil von Marktleistungen eines Unternehmens sein, wenn beispielsweise die

IT-Abteilung ihre Leistungen im Sinne eines Insourcings auch externen Unternehmen anbie-

tet. IT-Service-Prozesse können dementsprechend auch nach Unterstützungsprozessen oder

Leistungsprozessen differenziert werden. Ein IT-Service-Prozess stellt einen Leistungsprozess

dar, wenn dessen IT-Leistungen Teil der Marktleistungen sind und somit direkt an externe

Kunden gehen.

Symbole der IT-Servicesicht

Infrastrukturelement IT-Service IT-Service-Prozess

Service Level Agreement (SLA) definiert

(von SLA zu IT-Service)

erzeugt/verwendet

(von IT-Service-Prozess zu IT-Service)

Tabelle 17: Symbole der IT-Servicesicht

Grundsätzlich lässt sich die IT-Servicesicht der Informationssystemebene zuordnen, da Soft-

warekomponenten Teil von IT-Services sind. Bei der Definition der IT-Services spielt aber

auch die Orientierung an den fachlichen Anforderungen der Geschäftsseite des Unternehmens

539 Vgl. Dan et al. (2004), S. 136.

540 Vgl. Brecht (2002), S. 170.


eine wichtige Rolle. Deshalb enthält die IT-Servicesicht einige wesentliche Verknüpfungen

und Metaentitätstypen der anderen Ebenen und Sichten der Unternehmensarchitektur, so dass

sie im Unterschied zu den zuvor definierten Sichten eher als ebenenübergreifende Sicht be-

trachtet werden kann. Im Wesentlichen lassen sich dabei die folgenden sechs Verknüpfungen

der IT-Servicesicht mit den übrigen Sichten identifizieren, welche in Abbildung 54 über-

blicksartig dargestellt sind:

(1) Eine grundlegende Beziehung besteht zwischen der IT-Servicesicht und der auf Organisa-

tionsebene definierten Prozesslandkarte. IT-Services stellen Prozessleistungen der IT-

Service-Prozesse dar und dienen der Unterstützung von Prozessen der Prozesslandkarte.

Darüber hinaus können die in den IT-Services enthaltenen IT-Service-Prozesse in einer

eigenen IT-Prozesslandkarte des IT-Bereichs dokumentiert sein.

Strategieebene

Organisations-

ebene

Inform

ations-

systemebene

Infrastruktur-

ebene

Abbildung 54: Integration der IT-Servicesicht

(2) Eine weitere Abhängigkeit existiert zwischen dem Komponentenmodell und der IT-

Servicesicht. Jeder IT-Service umfasst eine oder mehrere Softwarekomponenten, deren

Funktionalitäten über Schnittstellen und mit entsprechenden Zusatzdiensten (IT-Service-

Prozess) angeboten werden. Die von einer Softwarekomponente angebotenen Funktionali-

täten können im Sinne einer serviceorientierten Architektur (SOA) ebenfalls als Services

(Fachlicher Service) definiert werden, sofern sie gekapselt und ihre standardisierten


Schnittstellen in einem Serviceverzeichnis publiziert sind (vgl. Abbildung 55).541 Dadurch

können sie flexibel genutzt und wieder verwendet werden. Die eigentliche Implementie-

rung der Komponente ist somit unabhängig von der Schnittstelle, so dass die Implementie-

rung jederzeit geändert werden kann, ohne die Konsumenten (andere Softwarekomponen-

ten) zu beeinflussen.

(3) Die Technologie- und Infrastrukturebene ist im engeren Sinne nicht Betrachtungsgegens-

tand des Business Engineering.542 Für die Definition und Integration einer IT-Servicesicht

sind aber auch die eingesetzten Technologien und Infrastrukturelemente von Bedeutung,

da sie wesentliche Bestandteile der IT-Services darstellen.

(4) Wie bereits zuvor erwähnt wurde, ist jedem IT-Service analog zu den Geschäftsprozessen

eine verantwortliche Organisationseinheit im Sinne eines Owner zuzuordnen. Dement-

sprechend steht die IT-Servicesicht auch mit der Aufbauorganisation des Unternehmens

bzw. der Geschäftseinheit in Beziehung.

(5) Des Weiteren können die zu einem IT-Service gehörenden IT-Service-Prozesse Service-

aktivitäten zur Unterstützung der Kundenaktivitäten im Kontext des Kundenprozessmo-

dells darstellen bzw. diese unterstützen.

(6) Die Einführung einer Serviceorientierung wirkt sich offensichtlich nicht nur auf die Orga-

nisation und die zugrunde liegenden Informationssysteme eines Unternehmens aus, son-

dern beeinflusst auch dessen Geschäftstrategie. IT-Services können, wie zuvor bereits be-

schrieben, Teil von Marktleistungen sein und beziehen sich somit auf das Leistungsmodell

eines Unternehmens oder einer Geschäftseinheit.

In Verbindung mit dem zuvor beschriebenen serviceorientierten IT-Management und der

Gestaltung der Kooperation zwischen IT-Dienstleister und Dienstnehmer durch so genannte

IT-Services wird auch das Konzept der serviceorientierten Architektur (SOA) sowohl in der

Praxis als auch in der Wissenschaft stark diskutiert.543 Bisher liegt dem SOA-Konzept

allerdings kein allgemein akzeptiertes Verständnis zugrunde. Ursprünglich stammt der Begriff

SOA aus der Softwareentwicklung. Die W3C definiert beispielsweise SOA als eine Art

mehrschichtige, verteilte Systemarchitektur, die aus einer Menge von gekapselten

Funktionalitäten besteht, deren standardisierte Schnittstellen publiziert sind.544 Dadurch

können sie in Softwaresystemen flexibel genutzt und gut wiederverwendet werden. Prinzipiell

spielt es dabei keine Rolle, ob Services von internen Softwarekomponenten bereitgestellt oder

extern bezogen werden.

541 Vgl. hierzu z.B. Winter/Schelp (2005), S. 241 und Schemm et al. (2006), S. 24-30.

542 Vgl. Schelp/Schwinn (2005), S. 1334.

543 Vgl. z.B. Arsanjani (2004), Dan et al. (2004), W3C (2004a), Winter/Schelp (2005), Schemm et al. (2006),

Böhmann et al. (2002). 544

Vgl. W3C (2004a).


Wenn die Serviceorientierung tatsächlich so vorteilhaft ist, wie allgemein vermutet wird, dann

sollte dieses Konzept nicht nur aus technischer Sicht, sondern auch auf den „oberen“ Ebenen

der Unternehmensarchitektur aus fachlicher Sicht angewandt werden.545 Eine

serviceorientierte Architektur wird deshalb in dieser Arbeit als eine mehrschichtige, verteilte

Integrationsarchitektur verstanden, die Teile der Applikationsarchitektur als fachliche

Services kapselt und das Bindeglied zwischen Organisations- und Informationssystemebene

darstellt.546 Ein fachlicher Service stellt dabei ein abstraktes Software-Element bzw. eine

Schnittstelle dar, die anderen Applikationen unter Nutzung von verbreiteten Standards stabile,

wieder verwendbare Software-Funktionalität auf einer anwendungsorientierten, fachlichen

Granularitätsstufe anbietet.547 Das SOA-Konzept wird dementsprechend in den

Bezugsrahmen des Ansatzes der vorliegenden Arbeit als horizontale Servicesicht der

Applikationsebene eingeordnet (vgl. Abbildung 32). Diese Servicesicht kapselt

Fachfunktionalität von unterschiedlichen Applikationen, um diese anschliessend für die

Unterstützung der Prozesse flexibel einsetzen und kombinieren zu können. Dadurch lässt sich

der Übergang von der Organisationsebene zur Informationssystemebene flexibler gestalten

und vereinfachen.

Da es nicht sinnvoll erscheint, die Funktionalität aller Applikationen eines Unternehmens in

Services zu kapseln, und die Transformation zu einer serviceorientierten Architektur in der

Regel einen längeren Zeitraum in Anspruch nimmt,548 wird das Konzept der Applikationen

weiterhin parallel zu den fachlichen Services beibehalten. Folglich kann eine

Geschäftsfunktion sowohl von einer oder mehreren Applikation(en) als auch von einem oder

mehreren fachlichen Services unterstützt werden (vgl. Abbildung 55).

Darüber hinaus können fachliche Services Teil von IT-Services sein, wenn sie zusammen mit

anderen Servicekomponenten, wie z.B. Infrastrukturelementen, und entsprechenden

Zusatzdiensten angeboten werden.

545 Vgl. Winter/Schelp (2005), S. 46.

546 Vgl. Schemm et al. (2006), S. 24.

547 Vgl. Schemm et al. (2006), S. 29 und W3C (2004b).

548 Vgl. hierzu z.B. auch Dan et al. (2004), S. 84.


Organisations-

ebene

Applikations-

ebene

Software-

komponenten

IT-Services

IT-Service

Software-

komponente

Applikation

Schnittstelle

Fachlicher

Service

Service-

schnittstelle

Geschäfts-

funktion

Service-

spezifikation

Service-

verzeichnisunterstützt

definiert umfasst

hat

bietet an

nutzt

ist Teil von

bietet an/

nutzt

*

1 *

*

*

*

*

*

*

*

**

1 1 **

*

*

*

1

AktivitätProzess-

leistung

unterstützt

umfasst

*

***

ist Teil

von

erzeugt/

verwendet

Abbildung 55: Metamodell der SOA-Sicht

Die wesentlichen Metaentitätstypen der SOA-Sicht sind in der folgenden Tabelle 18 genauer

spezifiziert.

Fachlicher Service

Definition

Ein Service im Zusammenhang mit einer serviceorientierten Architektur (Fachlicher Ser-vice) stellt ein abstraktes Software-Element bzw. eine Schnittstelle dar, die anderen Soft-warekomponenten unter Nutzung von verbreiteten Standards stabile, wieder verwendbare

Software-Funktionalität auf einer fachlichen Granularitätsstufe anbietet.549

Softwarekomponente Ein fachlicher Service wird von einer oder mehreren Software-komponente/n genutzt/angeboten.

Servicespezifikation Ein fachlicher Service wird von einer Servicespezifikation be-schrieben.

Serviceschnittstelle Ein fachlicher Service besitzt eine oder mehrere Serviceschnitt-stelle/n.

IT-Service Ein fachlicher Service ist Teil eines oder mehrerer IT-Services.

Beziehungen zu

Geschäftsfunktion Ein fachlicher Service unterstützt eine oder mehrere Geschäfts-funktion/en.

Servicespezifikation

Definition Eine Servicespezifikation enthält sämtliche Informationen, die ein Servicenutzer benötigt,

ohne die interne Realisierung des Services zu kennen.550

Serviceverzeichnis Eine Servicespezifikation ist in einem oder mehreren Servicever-zeichnis/sen enthalten.

Beziehungen zu Fachlicher Service

Eine Servicespezifikation definiert genau einen fachlichen Servi-ce.

Serviceverzeichnis

Definition In einem Serviceverzeichnis werden die verfügbaren fachlichen Services registriert und ihre Servicespezifikation abgelegt. Das ermöglicht dem Servicenutzer, einen geeigneten

Service zu identifizieren und aufzurufen.551

549 Vgl. Schemm et al. (2006), S. 29 und W3C (2004b).

550 Vgl. Stojanovic (2005), S. 40-41 und W3C (2004b).


Beziehungen zu Servicespezifikation Ein Serviceverzeichnis enthält eine oder mehrere Servicespezifi-kation/en.

Serviceschnittstelle

Definition Eine Serviceschnittstelle stellt die softwaretechnische Realisierung einer Servicespezifika-tion dar. Sie nutzt über Komponentenschnittstellen die (Fach-)Funktionalität von Soft-

warekomponenten.552

Fachlicher Service Eine Serviceschnittstelle wird von genau einem fachlichen Servi-ce angeboten.

Beziehungen zu Schnittstelle (SW-Komponente)

Eine Serviceschnittstelle nutzt eine oder mehrere Schnittstelle/n einer Softwarekomponente.

Tabelle 18: Metaentitätstypen der SOA-Sicht

4.6 Ebeneninterne Abhängigkeiten zwischen Modellen

Wie bereits zu Beginn dieses Kapitels erwähnt wurde, wird das gesamte Metamodell durch

die Darstellung einer grösseren Zahl an Metaentitätstypen sowie der Beziehungstypen rasch

unübersichtlich. Aus diesem Grund wurde das Metamodell in problemorientierte Sichten bzw.

Modelle unterteilt, welche thematisch zusammengehörende Metaentitätstypen zusammenfas-

sen. Diese problemorientierten Sichten sind nicht disjunkt, und es bestehen zahlreiche Abhän-

gigkeiten zwischen den Modellen auf einer Ebene sowie zwischen den Modellen auf unter-

schiedlichen Ebenen. Da die Definition der Abhängigkeiten für die Gewährleistung der mo-

dellübergreifenden Konsistenz und für die Werkzeugunterstützung im Hinblick auf die Imp-

lementierung von Mechanismen, wie beispielsweise Konsistenzprüfungen, Abhängigkeitsana-

lysen, Simulation etc. von besonderer Bedeutung ist, werden in diesem Abschnitt die Abhän-

gigkeiten nochmals genauer betrachtet und definiert sowie die zentralen Metaentitätstypen

identifiziert. Im Hinblick auf die zukünftige Formulierung von Gestaltungsrichtlinien für die

Entwicklung der einzelnen Modelle der Unternehmensarchitektur liefern diese zentralen Me-

taentitätstypen wichtige Hinweise, welche Informationen über das Unternehmen insbesondere

in der Anfangsphase eines Unternehmensarchitektur-Projektes erhoben werden sollten.

Auf jeder Ebene gibt es mindestens zwei zentrale Metaentitätstypen, die die unterschiedlichen

Modelle einer Ebene zueinander in Beziehung setzen. Auf diese sowie deren Beziehungen zu

den Metaentitätstypen der einzelnen Modelle einer Ebene wird im Folgenden genauer einge-

gangen.

4.6.1 Strategieebene

Die beiden zentralen Metaentitätstypen, die alle Modelle der Strategieebene zueinander in

Beziehung setzen und folglich bei der Gestaltung der strategischen Ausrichtung eines Unter-

551 Vgl. Schemm et al. (2006), S. 29.

552 Vgl. W3C (2004b).


nehmens im Mittelpunkt stehen, sind die Organisationseinheit553 sowie die Marktleistung.

Die folgende Nummerierung der Beziehungen korrespondiert mit der in Abbildung 56 ver-

wendeten Nummerierung.

(1) Eine Organisationseinheit (Unternehmen oder Geschäftseinheiten) nimmt aus strategi-

scher Sicht eine bestimmte kompetenzbasierte Rolle im Geschäftsnetzwerk wahr.554

(2) Abhängig von dieser kompetenzbasierten Rolle enthält das Leistungsmodell der betrachte-

ten Organisationseinheit im Sinne eines Referenzmodells bzw. einer Typisierung entspre-

chende Dimensionen und Ausprägungen. Das Leistungsmodell spezifiziert nach

HEINRICH, bezogen auf einen bestimmten Stichtag, den markt-, wertschöpfungs- und po-

tenzialbezogenen Zustand einer Organisationseinheit (Unternehmen oder Geschäftsein-

heit), die selbständig am Markt agiert oder agieren könnte, anhand der Ausprägung be-

stimmter Dimensionen.555 Die Rolle der Organisationseinheit im Geschäftsnetzwerk wird

somit durch die Dimensionen und Ausprägungen des Leistungsmodells beschrieben. Dar-

über hinaus bezieht bzw. erbringt jede am Markt agierende Organisationseinheit Markt-

leistungen von bzw. für Kooperationspartner im Geschäftsnetzwerk.556

(3) Die Verbindung zum Zielmodell (BSC) wird durch die Metaentitätstypen Strategie und

Massnahme hergestellt. Das Zielmodell bzw. die BSC unterstützt das Unternehmen bzw.

die Geschäftseinheit dabei, ihre Strategie mit den kurz- bis mittelfristigen Massnahmen in

Einklang zu bringen.557 Das Unternehmen bzw. jede Geschäftseinheit verfolgt eine be-

stimmte Strategie, die durch Erfolgsfaktoren und Kennzahlen konkretisiert wird. Da die

BSC der Strategieumsetzung dienen soll, liegt der Schwerpunkt auf der Übersetzung der

Vision und Strategie in operative Ziele und Massnahmen.558 Für die Durchführung be-

stimmter Massnahmen zur Erreichung der Ziele ist eine bestimmte Organisationseinheit

verantwortlich.

553 Auf Strategieebene werden lediglich Unternehmen oder Geschäftseinheiten betrachtet. Diese werden bei

der Modellierung der Aufbauorganisation auf Organisationsebene in kleinere Organisationseinheiten eingeteilt.

554 Vgl. Winter (2003d), S. 96-97.

555 Vgl. Heinrich (2000), S. 11.

556 Vgl. hierzu z.B. Österle (2003), S. 32-34.

557 Vgl. Kaplan/Norton (1996), S. 75.

558 Vgl. Harengel (2000), S. 81.


Abbildung 56: Verknüpfung der Modelle auf Strategieebene (OE)

(4) Die Verknüpfung mit dem Kundenprozessmodell besteht über den Metaentitätstyp Servi-

ceaktivität. Bei der Erstellung des Kundenprozessmodells ist für jede Serviceaktivität zu

prüfen, ob sie auf Grundlage des Geschäftsmodells des jeweiligen Unternehmens bzw. der

jeweiligen Geschäftseinheit selbst erbracht oder besser von einem Kooperationspartner

fremdbezogen werden sollte.559 Folglich ist jeder Serviceaktivität des Serviceprozesses ei-

ne interne oder externe Organisationseinheit zugeordnet, die diese Serviceaktivität ver-

antwortet und durchführt.

Neben der Organisationseinheit stellt auch die Marktleistung einen zentralen Metaentitätstyp

bei der Gestaltung der Strategieebene dar (vgl. Abbildung 57).

(1) Jede am Markt angebotene Leistung wird von einer oder mehreren Rollen im

Geschäftsnetzwerk erbracht bzw. bezogen.

(2) Die von einem Unternehmen oder einer Geschäftseinheit angebotene Marktleistung wird

im Leistungsmodell durch eine oder mehrere Dimensionsausprägungen spezifiziert.

559 Vgl. Heinrich (2002b), S. 87.


Abbildung 57: Verknüpfung der Modelle auf Strategieebene (Marktleistung)

(3) Marktleistungen setzen sich aus Prozessleistungen zusammen, die von entsprechenden

Geschäftsprozessen auf Organisationsebene erzeugt werden. Analog zur Definition der

kritischen Erfolgsfaktoren und Ziele für Geschäftsprozesse lassen sich folglich auf

Strategieebene Erfolgsfaktoren und Ziele für Marktleistungen auf Basis externer

Anforderungen (Kundenanforderungen) ableiten und in der BSC als strategische Ziele der

internen Geschäftsprozessperspektive abbilden (vgl. hierzu Abschnitt 4.1.2.4).

(4) Die von einem Unternehmen im Geschäftsnetzwerk angebotene Leistung wird durch

einen internen Serviceprozess oder durch einen externen Serviceprozess eines Partners

erbracht.

Analog zur Strategieebene lassen sich auch auf Organisationsebene zentrale Metaentitätstypen

identifizieren.

4.6.2 Organisationsebene

Auf der Organisationsebene sind der Prozess, die Organisationseinheit sowie die Füh-

rungsgrösse die zentralen Metaentitätstypen, die die unterschiedlichen Modelle bzw. Sichten

dieser Ebene miteinander verknüpfen. Die folgenden sechs Beziehungen werden in Abbildung

58 dargestellt.560

(1) Der Metaentitätstyp Prozess ist zum einen ein Element der Prozesslandkarte, in der die

wesentlichen Leistungs- und Informationsbeziehungen zwischen den Leistungs-, Un-

terstützungs- und Führungsprozessen des Unternehmens bzw. der Geschäftseinheit abge-

560 Vgl. hierzu auch jeweils das entprechende Metamodell, mit dem eine Verknüpfung besteht.


bildet werden. Jeder Prozess verwendet und/oder erzeugt keine, eine oder mehrere Pro-

zessleistung(en).561

(2) Zudem knüpft er über den Metaentitätstyp Aktivität an das Modell der Ablauforganisation

an. Jeder Prozess besteht aus einer Menge von Aktivitäten, die in der Ablauforganisation

in eine bestimmte Reihenfolge gebracht und den entsprechenden Rollenträgern zugeordnet

werden.562

(3) Eine Verknüpfung zur Aufbauorganisation stellt der Prozess einerseits indirekt über die

Beziehungskette Aktivität, Prozessrolle und Rollenträger (vgl. Abbildung 43), andererseits

direkt über die Beziehung zur Organisationseinheit her. Jede Aktivität eines Prozesses

kann von einer Prozessrolle durchgeführt werden, die wiederum von einem bestimmten

Rollenträger der Aufbauorganisation übernommen wird.563 Ausserdem ist jeder Prozess

einer verantwortlichen Organisationseinheit zugeordnet.564 Dabei kann es sich um eine

speziell für das Prozessmanagement eingerichtete Organisationseinheit handeln.

(4) Die Verbindung des Prozesses zur Prozessvision wird über die Prozessgrundsätze herge-

stellt, die beschreiben, wie der Prozess idealerweise gestaltet sein sollte. Jeder Prozess

wird durch mehrere Prozessgrundsätze beschrieben.565

(5) Der Prozess ist sowohl über den Metaentitätstyp kritischer Erfolgsfaktor als auch mit dem

Metaentitätstyp Messsystem mit der Prozessführung verknüpft. Jeder Prozess besitzt einen

oder mehrere kritische Erfolgsfaktoren, die durch Führungsgrössen operationalisiert wer-

den.566 Zudem kann einem Prozess ein Messsystem zugeordnet sein, das die für diesen

Prozess definierten Führungsgrössen misst.

(6) Die Ergebnisse der Prozessführung werden in Form von Berichten dokumentiert und aus-

gewertet. Diese Berichte können anschliessend durch eine Inventur für die Erstellung der

Informationslandkarte herangezogen werden.567

561 Vgl. hierzu z.B. Österle (1995), S. 52.

562 Vgl. hierzu z.B. Scheer (2001), S. 31.

563 Vgl. hierzu z.B. Rosemann/zur Mühlen (1997), S. 79.

564 Vgl. hierzu z.B. Frank (2002), S. 3028.

565 Vgl. hierzu z.B. Brecht (2002), S. 168.

566 Vgl. hierzu z.B. Österle (1995), S. 54.

567 Vgl. hierzu z.B. Strauch (2002), S. 139.


Abbildung 58: Verknüpfung der Modelle auf Organisationsebene (Prozess)

Einen weiteren zentralen Metaentitätstyp auf der Organisationsebene stellt die Organisations-

einheit dar (vgl. Abbildung 59).568

(1) Eine Organisationseinheit kann Owner eines oder mehrerer Prozesse(s) sein, die in der

Prozesslandkarte abgebildet sind.569

(2) An diese Organisationseinheit geht der Bericht der entsprechenden Prozessführung.570

(3) Als wichtige Ideenquellen für neue Lösungen zur Prozessgestaltung und damit als Grund-

lage für die Prozessvision können unter anderem Mitarbeiter und Organisationseinheiten

herangezogen werden. Ausserdem ist für die Entwicklung und Pflege der Prozessgrund-

sätze eine bestimmte Organisationseinheit, meist eine speziell für das Prozessmanagement

eingerichtete, zuständig.571

(4) Wie bereits zuvor festgestellt, wird die Verbindung zwischen der Aufbauorganisation und

Ablauforganisation über den Metaentitätstyp Prozessrolle hergestellt, die von einem be-

stimmten Rollenträger übernommen wird. Dabei kann es sich um eine Organisationsein-

heit handeln.

(5) Die Organisationseinheit ist Teil der Aufbauorganisation und kann selbst wiederum meh-

rere Organisationseinheiten oder mehrere Stellen umfassen.572

(6) Zuletzt ist die Organisationseinheit auch mit der Informationslandkarte verknüpft, da eine

Organisationseinheit bzw. deren Stellen sowohl Konsument als auch Produzent von In-

formationen sein kann.573


569 Vgl. hierzu z.B. Frank (2002), S. 3028.


571 Vgl. hierzu z.B. Hess (1996), S. 183-189.

572 Vgl. hierzu z.B. Glossar in IMG (1997) und Rosemann/zur Mühlen (1997), S. 80.

573 Vgl. hierzu z.B. Strauch (2002), S. 181.


Abbildung 59: Verknüpfung der Modelle auf Organisationsebene (Organisationseinheit)

Neben den beiden zuvor genannten Metaentitätstypen ist auch die Führungsgrösse von

zentraler Bedeutung für die Gestaltung der Organisationsebene (vgl. Abbildung 60).

(1) Jedem Prozess der Prozesslandkarte sind bestimmte Führungsgrössen zugeordnet, die aus

der Geschäftsstrategie abgeleitet wurden. Eine Führungsgrösse beschreibt einen

quantitativ messbaren, für die Führung eines Prozesses relevanten Sachverhalt. Die einem

Prozess zugeordneten Führungsgrössen dienen der Planung und Beurteilung der

Prozessqualität im Sinne der kritischen Erfolgsfaktoren, insbesondere der Zeit, Qualität,

Kosten und Flexibilität.574

(2) Im Modell der Ablauforganisation können die für einen Prozess abgeleiteten

Führungsgrössen konkreten Aktivitäten oder dem Output von Aktivitäten

(Prozessleistungen) zugeordnet werden. Dadurch lassen sich sowohl die Effektivität als

auch die Effizienz eines Prozesses steuern, planen und kontrollieren.

(3) Die für einen Prozess definierten Führungsgrössen werden von der verantwortlichen

Organisationseinheit kontrolliert. Diese setzt die Führungsgrössen zur Analyse des

Prozesses und zur Kontrolle der Prozesszielerreichung ein, um Defizite aufzeigen zu

können. Somit besteht auch über die Führungsgrössen eine Verbindung zur

Aufbauorganisation.

(4) Die Prozessvision enthält Ideen für die Neugestaltung eines Prozesses und bildet die

Umrisse des neuen Prozesses ab.575 Als Vorgabe für die Prozessgestaltung fungieren in

der Prozessvision die Prozessgrundsätze. Die Gestaltungsmerkmale für die

Prozessgrundsätze umfassen unter anderem auch die Erfolgsfaktoren des neu zu

gestaltenden Prozesses. Diesen können neue oder bereits definierte Führungsgrössen

zugeordnet werden.

574 Vgl. Egebnissse in IMG (1997) und Brecht (2002), S. 155.

575 Vgl. Techniken in IMG (1997).


Abbildung 60: Verknüpfung der Modelle auf Organisationsebene (Führungsgrösse)

(5) Eine Führungsgrösse operationalisiert einen oder mehrere Erfolgsfaktor(en) eines

Prozesses und stellt somit das wesentliche Gestaltungselement der Prozessführung dar.

(6) Die Werte der Führungsgrössen lassen sich aus unterschiedlichen betrieblichen Quellen

bestimmen. Je nach Quelle ist zwischen den Ist-Werten und den Plan- oder Soll-Werten

zu unterscheiden. Diese Werte werden in regelmässigen Abständen ausgewertet und

beispielsweise in Form eines Berichts der verantwortlichen Organisationseinheit

(Konsument) zur Verfügung gestellt. Folglich sind die Führungsgrössen auch Teil der

Informationslandkarte.

4.6.3 Informationssystemebene

Auf der Informationssystemebene werden, ausgehend von den zuvor spezifizierten Organisa-

tionsstrukturen, Informationsbedarfen und Prozessabläufen, Integrationsbereiche innerhalb

des Informationssystems festgelegt. Im Normalfall wird ein eng gekoppelter Integrationsbe-

reich durch eine Applikation realisiert, während lose Kopplungen zwischen Integrationsberei-

chen durch Schnittstellen zwischen Applikationen realisiert werden.576 Das generelle Gestal-

tungsziel der Applikationsebene ist die optimale Integration (bzw. Entkopplung) von Applika-

tionen aus fachlicher Sicht.

Die einzelnen Modelle der Informationssystemebene werden daher unter anderem durch den

zentralen Metaentitätstyp Applikation miteinander verknüpft. Die folgenden sieben Bezie-

hungen werden in Abbildung 61 dargestellt.577

(1) Die einzelnen geplanten sowie realisierten Applikationen eines Unternehmens oder einer

Geschäftseinheit werden in der Applikationsbestandsführung anhand vordefinierter Eigen-

schaften erfasst und in Applikationsdomänen gruppiert.578

576 Vgl. Winter (2003a), S. 9.



(2) Ferner manipuliert und/oder verwaltet jede Applikation Informationsobjekte, die im In-

formationsobjektemodell begrifflich harmonisiert und dokumentiert sind.579

(3) Jede Applikation beinhaltet eine oder mehrere Applikationsfunktion(en), die wiederum

eine oder mehrere Geschäftsfunktion(en) realisieren.580 Somit ist die Verbindung zum Ge-

schäftsfunktionenmodell hergestellt.

(4) Durch die Beziehungsstruktur zwischen Geschäftsfunktionen, Informationsobjekten und

Organisationseinheiten werden bei der Definition der Integrationsarchitektur Integrations-

bereiche abgeleitet, die anschliessend bestimmten neu zu entwickelnden Applikationen

zugeordnet werden.581

(5) Die Verbindung zwischen der Applikation und dem Modell der Komponenten und Platt-

formen besteht über eine Kompositionsbeziehung mit dem Metaentitätstyp Softwarekom-

ponente sowie mit den von einer Applikation manipulierten bzw. verwalteten Informati-

onsobjekten, die als Datenobjekte auf der Ebene der Softwarekomponenten und Daten-

strukturen implementiert sind.582

Abbildung 61: Verknüpfung der Modelle auf Informationssystemebene (Applikation)

(6) Im Autorisierungsmodell werden die Berechtigungen für den Zugriff auf die Methoden

und Datenobjekte der existierenden Softwarekomponenten und damit der Applikationen

578 Vgl. hierzu z.B. Choinowski et al. (2003), S. 72.

579 Vgl. hierzu z.B. Schwinn (2005), S. 138.


581 Vgl. hierzu z.B. Winter (2003a).



festgelegt.583 Somit ist auch die Verknüpfung der Applikation mit dem Autorisierungsmo-

dell indirekt über deren Softwarekomponenten hergestellt.

(7) Ebenso besteht eine indirekte Beziehung zum Datenmodell. Jede Applikation umfasst eine

oder mehrere Softwarekomponenten, die auf Datenobjekten operieren und/oder diese

verwalten.584 Jedes Datenobjekt korrespondiert mit genau einer Klasse des Datenmodells.

Die Organisationseinheit stellt auch auf der Informationssystemebene wiederum ein zentra-

les Verknüpfungselement dar (vgl. Abbildung 62). Hier tritt sie vor allem in der Rolle eines

Owners für die unterschiedlichen Elemente der Applikations- sowie der Softwarekomponen-

ten- und Datenstrukturebene auf. Aus diesem Grunde erscheint es sinnvoll, analog zur Defini-

tion des Metaentitätstyps Rollenträger (vgl. 4.2.2.4), einen zusätzlichen generalisierten Meta-

entitätstyp Owner zu definieren. Ein Owner könnte dann sowohl eine Organisationseinheit als

auch einzelne Stellen, Personen oder Stellentypen repräsentieren, so dass eine flexiblere und

detailliertere Zuordnung von Verantwortlichkeiten möglich ist.

(1) Eine Organisationseinheit kann für eine oder mehrere Applikation(en), die in der Applika-

tionsbestandsführung erfasst ist/sind, im Sinne eines Owner verantwortlich sein.585 Diese

Verantwortlichkeit kann sowohl die (Weiter-)Entwicklung und Verwaltung der zugeord-

neten Applikation(en) als auch die Pflege bzw. Aktualisierung der Dokumentation der

Applikation(en) in der Applikationsbestandsführung umfassen.

Abbildung 62: Verknüpfung der Modelle auf

Informationssystemebene (OE)

(2) Ebenso besitzt jede Softwarekomponente, jede Plattform, auf der die Softwarekomponen-

ten laufen, sowie jeder Datenspeicher eine bestimmte Organisationseinheit als Owner, die

583 Vgl. hierzu z.B. Ferraiolo et al. (2001), S. 233.


585 Vgl. hierzu z.B. die Fallstudien in Schwinn (2005).


für die Entwicklung und Verwaltung zuständig ist.586 Somit knüpft die Organisationsein-

heit als Owner unterschiedlicher Elemente an das Modell der Komponenten und Plattfor-

men an.

(3) Eine Organisationseinheit kann bei der Herleitung der Integrationsbereiche der Integrati-

onsarchitektur eine Erhebungsquelle von Begrifflichkeiten für Informationsobjekte

sein.587

(4) Analog zur Verantwortlichkeit für die Pflege und Aktualisierung der Einträge in der Ap-

plikationsbestandsführung müssen auch für die Pflege des Informationsobjekte- und

(5) Geschäftsfunktionenmodells verantwortliche Organisationseinheiten (Owner) festgelegt

werden.588

(6) Die Verknüpfung der Organisationseinheit zum Autorisierungsmodell besteht indirekt

über den Metaentitätstyp Prozessrolle. Damit die (organisatorischen) Rollenträger (Orga-

nisationseinheiten, Stellen, Personen) die informationstechnisch unterstützten Aktivitäten

innerhalb eines Prozesses durchführen können, müssen sie über entsprechende Systembe-

rechtigungen verfügen. Diese werden über Benutzerkonten den Rollenträgern zugeordnet

und im Autorisierungsmodell dokumentiert.589

4.7 Ebenenübergreifende Abhängigkeiten

Nachdem in den vorherigen Abschnitten auf die ebeneninternen Zusammenhänge eingegan-

gen wurde, sollen nun die Zusammenhänge zwischen Metaentitätstypen auf unterschiedlichen

Ebenen näher betrachtet werden. Durch die Darstellung der Zusammenhänge lässt sich erken-

nen, welche Inhalte einer Ebene bei der Modellierung der darunter liegenden Ebene verwen-

det werden sollen bzw. müssen, wenn von einem Top-Down-Vorgehen ausgegangen wird.

Die Identifikation und Spezifikation dieser Abhängigkeiten bildet somit eine wichtige Grund-

lage für die Beantwortung von Fragestellungen des IT-Business-Alignment.

Wie sich zuvor herausgestellt hat, ist die Organisationseinheit auf allen drei Ebenen ein zen-

traler Metaentitätstyp. Deshalb erscheint es sinnvoll, die Sicht der Aufbauorganisation nicht

nur der Organisationsebene zuzuordnen, sondern orthogonal zu den anderen Ebenen, also

ebenenübergreifend zu definieren. Auf Strategieebene wird dann lediglich auf Unternehmen

oder Geschäftseinheiten in der Aufbauorganisation verwiesen, auf der Organisations- und

Systemebene auf Organisationseinheiten sowie einzelne Stellen oder Personen.

586 Vgl. hierzu z.B. Siegenthaler/Schwinn (2005), S. 222.



589 Vgl. hierzu z.B. Wortmann (2005), S. 123.


Die Elemente der Aufbauorganisation treten dabei oftmals als Owner unterschiedlicher Ele-

mente der Unternehmensarchitektur auf unterschiedlichen Ebenen auf, so beispielsweise als

Owner von Serviceaktivitäten auf Strategieebene, Prozessen auf Organisationsebene, Appli-

kationen bzw. Applikationsdomänen auf Applikationsebene sowie Softwarekomponenten,

Plattformen und Datenspeichern auf der Ebene der Softwarekomponenten und Datenstruktu-

ren.

4.7.1 Zusammenhänge zwischen Strategie- und Organisationsebene

Abbildung 63 zeigt vereinfacht die wesentlichen Zusammenhänge zwischen Metaentitätsty-

pen auf der Strategie- und Organisationsebene. Aus Gründen der Übersichtlichkeit sind die

meisten ebeneninternen Beziehungen nicht dargestellt. Die folgende Nummerierung der Be-

ziehungen korrespondiert mit der in Abbildung 63 verwendeten Nummerierung.

(1) Eine Organisationseinheit (Unternehmen oder Geschäftseinheit) nimmt aus strategischer

Sicht eine bestimmte Rolle im Geschäftsnetzwerk wahr. Bei der Modellierung der Pro-

zesslandkarte auf Prozessebene müssen anschliessend die Geschäftsprozesse bestimmten

Unternehmen bzw. Geschäftseinheiten zugeordnet werden, um einen reibungslosen Ab-

lauf gewährleisten zu können. Dabei kann es sich um das eigene Unternehmen bzw. inter-

ne Geschäftseinheiten oder andere Unternehmen bzw. externe Geschäftseinheiten (z.B. im

Sinne eines Outsourcings von Geschäftsprozessen590) handeln. Heutige Unternehmen

bzw. Organisationen besitzen in der Regel eine prozessorientierte Organisationsform, so

dass die Organisationseinheiten mit den Geschäftsprozessen korrespondieren bzw. jede

Organisationseinheit für einen oder mehrere Geschäftsprozesse verantwortlich ist.591

(2) Darüber hinaus umfasst jede Organisationseinheit (Unternehmen oder Geschäftseinheit)

auf Strategieebene eine oder mehrere Organisationseinheiten auf Organisationsebene, die

wiederum Organisationseinheiten umfassen können oder letztendlich aus einzelnen Stel-

len und Personen bestehen.592

(3) Das Zielsystem (Balanced Score Card) liefert Vorgaben in Form von Erfolgsfaktoren und

Kennzahlen, die bei der Gestaltung der Prozesse sowie der Prozessführung berücksichtigt

werden müssen und zur Einhaltung der Prozessziele beitragen sollen. Die im Zielsystem

definierten kritischen Erfolgsfaktoren repräsentieren die für den Erfolg bzw. die für die

Erreichung der Unternehmensziele entscheidenden Merkmale der Geschäftsstrategie.593

Analog kann ein kritischer Erfolgsfaktor eines Prozesses als eines der wenigen, erfolgs-

590 Zum Outsourcing von Geschäftsprozessen (Business Process Outsourcing) siehe z.B. Braun/Winter

(2005a). 591

Vgl. hierzu z.B. Winter (2003a). 592

Vgl. hierzu z.B. Frank (2002), S. 3028. 593

Vgl. hierzu z.B. Rockart (1979), S. 85.


entscheidenden Merkmale eines Prozesses definiert werden.594 Um eine Ausrichtung der

Prozesse an der Geschäftsstrategie und den Unternehmenszielen zu erreichen, erscheint es

sinnvoll, dass ein kritischer Erfolgsfaktor eines Prozesses aus einem oder mehreren kriti-

schen Erfolgsfaktor(en) des Zielsystems der Strategie abgeleitet und durch entsprechende

Führungsgrössen operationalisiert wird. Die Erfolgsfaktoren und Führungsgrössen der

Prozessführung korrespondieren somit mit den kritischen Erfolgsfaktoren und Kennzahlen

des Zielsystems.

Abbildung 63: Zusammenhänge zwischen Strategie- und Organisationsebene

(4) Das Prozessverständnis dieser Arbeit ist dadurch charakterisiert, dass ein Prozess seine

Leistungen nicht an organisatorische Einheiten, sondern ausschliesslich an andere Prozes-

se innerhalb oder ausserhalb des eigenen Unternehmens bzw. der eigenen Geschäftsein-

heit übergibt (Kunden-Lieferanten-Verhältnis zwischen Prozessen).595 Prozessleistungen,

die an Prozesse von Marktpartnern gehen, sind Teil der Marktleistungen einer Unterneh-

mung.596 Marktpartner sind entweder Kooperationspartner im Geschäftsnetzwerk (andere

Unternehmen oder Geschäftseinheiten) oder Endkunden. Folglich kann eine Marktleistung

eine oder mehrere Prozessleistung(en) der Organisationsebene umfassen.

(5) Die Ausprägungen der Dimensionen des Leistungsmodells liefern die Leistungsspezifika-

tion. Diese steht in engem Zusammenhang mit der von einem Prozess erzeugten Prozess-

594 Vgl. hierzu z.B. Leidecker/Bruno (1984), S. 24.

595 Vgl. hierzu z.B. Österle (1995) und Brecht (2002).

596 Vgl. Nieschlag et al. (1994), S. 234-252.


leistung, welche in der Ablaufplanung auf Prozessebene abgebildet wird, da es beispiels-

weise für die Prozessmodellierung massgeblich ist, welche Leistungen das Unternehmen

anbieten will bzw. kann (z.B. ob das Kerngeschäft einer Bank das Kredit- oder Anlagege-

schäft ist).597 Die Leistungsspezifikation hat somit unmittelbaren Einfluss auf die Identifi-

zierung der Prozesse, zumindest der Leistungsprozesse der zugrunde liegenden Unter-

nehmung sowie der von ihnen erzeugten Prozessleistungen. In der Regel werden die Leis-

tungsprozesse anhand der Leistungen, die ein Unternehmen anbietet, definiert.598

(6) Das Kundenprozessmodell legt fest, welche Serviceaktivitäten durchgeführt werden müs-

sen, um die einzelnen Kundenaktivitäten eines Kundenprozesses zu unterstützen. Da die

Serviceaktivität zum Ausdruck bringt, welche Aktivitäten das Unternehmen bzw. die Ge-

schäftseinheit im Kundenprozess unterstützen will/kann, werden Vorgaben für die zu mo-

dellierenden Prozesse bzw. deren Aktivitäten zur Leistungserbringung aufgestellt. Dar-

über hinaus muss für jede Serviceaktivität festgelegt werden, welche Prozesse diese unter-

stützen sollen. FRANK definiert beispielsweise in seiner Arbeit eine ähnliche Beziehung

zwischen Aktivitäten der Wertschöpfungskette und Prozesstypen auf Organisationsebe-

ne.599

Eine weitere Abhängigkeit, die aus Gründen der Übersichtlichkeit nicht in Abbildung 63 dar-

gestellt ist, besteht zwischen der Strategie eines Unternehmens bzw. einer Geschäftseinheit

und den auf Organisationsebene festgelegten Prozessgrundsätzen. Diese werden unter ande-

rem aus der Strategie abgeleitet.600 Somit hat die Definition der Strategie und Ziele unmittel-

baren Einfluss auf die Gestaltung der Geschäftsprozesse.

4.7.2 Zusammenhänge zwischen Organisations- und Informationssys-

temebene

Abbildung 64 zeigt die wesentlichen Zusammenhänge zwischen Metaentitätstypen der Orga-

nisations- und Applikationsebene. Die folgende Nummerierung der Beziehungen korrespon-

diert wiederum mit der in Abbildung 64 verwendeten Nummerierung.

(1) Jede Geschäftsfunktion und jedes Informationsobjekt auf Organisationsebene besitzt eine

oder mehrere Begrifflichkeiten, die aus unterschiedlichen Erhebungsquellen stammen

können. Dabei können homonyme und synonyme Begriffe unterschieden werden. Diese

werden in einem Homogenisierungsschritt harmonisiert und somit auf einen Standardbe-

griff festgelegt. Die bezüglich ihrer Begriffe harmonisierten Geschäftsfunktionen und In-



599 Vgl. Frank (2002), S. 3028.

600 Vgl. hierzu z.B. Techniken in IMG (1997).


formationsobjekte dienen als Grundlage für die Ableitung neuer Applikationen bei der

nachfolgenden Gestaltung der Integrationsarchitektur.601

(2) Als Erhebungsquelle der Begrifflichkeiten von Geschäftsfunktionen bzw. Informations-

objekten kommen die Beschreibungen von Organisationseinheiten sowie Geschäftspro-

zessen in Betracht.602

(3) Die unterschiedlichen Informations- und Leistungsflüsse zwischen den harmonisierten

Informationsobjekten, Geschäftsfunktionen sowie Geschäftsprozessen bzw. Organisati-

onseinheiten603 definieren eine Beziehungsstruktur. Anhand dieser Beziehungsstruktur

können Integrationsbereiche identifiziert werden. Diesen Integrationsbereichen wird an-

schliessend eine bereits existierende oder neu zu entwickelnde Applikation zugeordnet.

(4) Eine Applikationsfunktion ist Bestandteil einer Applikation und realisiert eine oder meh-

rere Geschäftsfunktionen auf Organisationsebene, die bestimmte Aktivitäten von Prozes-

sen ausführen. Darüber hinaus benötigen Applikationsfunktionen als Eingabe Informati-

onsobjekte und/oder erzeugen als Ausgabe neue oder veränderte Informationsobjekte. Im

Gegensatz zur Definition von Gutzwiller604 geht SCHWINN in seiner Arbeit nicht davon

aus, dass jede Funktion von genau einer Applikationsfunktion realisiert wird, sondern

dass gleiche Funktionen auch von mehreren Applikationsfunktionen realisiert werden

können.605 Diese Annahme wird auch in dieser Arbeit übernommen, da dadurch die häu-

fig in der Realität existierenden funktionalen Redundanzen berücksichtigt werden kön-

nen. Durch die Dokumentation dieser Redundanzen wird gleichzeitig eine Grundlage für

zukünftige Projekte der Applikationsintegration geschaffen.

(5) Jede Applikation ist einer bestimmten Applikationsdomäne (Gruppierung mehrerer Ap-

plikationen) zugeordnet, die der Unterstützung eines Geschäftsprozesses dient. Eine Ap-

plikationsdomäne fasst mehrere Applikationen, die für die Durchführung eines Prozesses

notwendig sind, logisch zusammen.606 Applikationsdomänen dienen vor allem der Kom-

plexitätsreduktion. Jeder Applikationsdomäne ist zudem ein Owner (Verantwortlicher)

auf Organisationsebene zugeordnet. Dabei kann es sich um eine Organisationseinheit, ei-

ne Stelle oder eine einzelne Person handeln.

601 Vgl. hierzu z.B. Winter (2003a).


603 Bei einer geschäftsprozessorientierten Organisationsform können die Dimensionen Geschäftsprozesse,

Organisationseinheiten und Leistungen zu einer Dimension zusammengefasst werden. Vgl. Winter (2003a), S. 5.


605 Vgl. Schwinn (2005), S. 19.

606 Vgl. hierzu z.B. Schwinn (2005), S. 74., Lankes et al. (2005), S. 1445 und Jung (2004), S. 313. Synonym

werden oftmals die Begriffe „logische Einheit“ oder „Building Block“ verwendet.


Abbildung 64: Zusammenhänge zwischen

Organisations- und Informationssystemsebene

(6) Analog zur Unterscheidung zwischen einer Geschäftsfunktion auf Organisationsebene

und einer Applikationsfunktion auf Applikationsebene könnte auch zwischen einem Ge-

schäftsobjekt auf Organisationsebene und einem Informationsobjekt auf Applikations-

ebene unterschieden werden. Da Informationsobjekte allerdings über Funktionen ausge-

tauscht werden und in der Regel mit den Geschäftsobjekten auf Organisationsebene kor-

respondieren, wird diese Differenzierung nicht vorgenommen. Stattdessen wird der Me-

taentitätstyp „Informationsobjekt“ sowohl auf Organisations- als auch auf Applikations-

ebene verwendet. Auf Organisationsebene werden dann lediglich die von Prozessen er-


zeugten und verwendeten Informationsobjekte erfasst. Auf Applikationsebene können zu-

sätzlich Informationsobjekte, die beispielsweise in den Beschreibungen von Organisati-

onseinheiten oder Stellen vorkommen, erfasst werden. Zudem besteht eine Beziehung

zwischen Informationsobjekt und Prozessleistung, da ein oder mehrere Informationsob-

jekt(e) Teil einer Prozessleistung sein können, sofern es sich dabei um eine Informations-

dienstleistung handelt.607

(7) Die Verbindung zur Softwarekomponenten- und Datenstrukturebene besteht über die

Metaentitätstypen „Softwarekomponente“ und „Datenobjekt“. Jede Applikation wird

durch Softwarekomponenten implementiert, die auf Datenobjekten operieren und diese

verwalten. Die in einer Softwarekomponente enthaltene Funktionalität wird in Form von

Methoden bereitgestellt.608 Im Konzept der Softwarekomponenten ist zudem berücksich-

tigt, dass die Entwicklung von Applikationen zunehmend durch vorgefertigte, vertikale

und horizontale (Standard-)Komponenten bewerkstelligt wird.609 Die Applikationsent-

wicklung wird in Zukunft nach Ansicht einiger Autoren zum Grossteil aus der Zusam-

menstellung von sofort einsatzfertigen Komponenten sowie deren Anpassung und Erwei-

terung bestehen.610 Neue Funktionalitäten werden demzufolge vor allem durch vorgefer-

tigte, sofort einsatzbereite Komponenten von unterschiedlichen Lieferanten zur Verfü-

gung gestellt werden. Im Hinblick auf die ideale Implementierung von Applikationen und

die dafür optimale Wiederverwendung von Softwarekomponenten spielt folglich die Do-

kumentation der Applikationen und Softwarekomponenten sowie von deren Lieferanten

und Herstellern eine wichtige Rolle innerhalb der gesamten Unternehmensarchitektur.

(8) Analog zu der zuvor beschriebenen Beziehung zwischen Applikation und Softwarekom-

ponente ist jedes Informationsobjekt auf der Softwarekomponenten- und Datenstruktur-

ebene als Datenobjekt implementiert, welches einem bestimmten Datenspeicher zugeord-

net ist.611

(9) Ausserdem wird entsprechend der Unterscheidung zwischen Informationsobjekt auf Ap-

plikationsebene und Datenobjekt auf Softwarekomponenten- und Datenstrukturebene ei-

ne Applikationsfunktion als Methode realisiert.612

(10) Damit die organisatorischen (menschlichen) Rollenträger die informationstechnisch un-

terstützten Aktivitäten eines Geschäftsprozesses durchführen können, müssen sie über

entsprechende Systemberechtigungen verfügen.613 Diese Berechtigungen werden auf der

607 Vgl. hierzu z.B. Vgl. Scheer (2001), S. 93 und Vgl. Scheer (2001), S. 67.

608 Vgl. Schwinn (2005), S. 22 und Vogler (2003), S. 31.

609 Vgl. Greenfield/Short (2003), S. 18.

610 Vgl. z.B. Cheesman/Daniels (2000).

611 Vgl. hierzu z.B. Schelp/Schwinn (2005), S. 1335.

612 Vgl. hierzu z.B. Schelp/Schwinn (2005), S. 1335.

613 Vgl. Wortmann (2005), S. 123.


Softwarekomponenten- und Datenstrukturebene über Benutzerkonten den Rollenträgern

auf Organisationsebene zugeordnet. Dadurch erhalten diese Zugriff auf die Methoden und

Datenobjekte der vorhandenen Softwarekomponenten.

(11) Jedem informationstechnisch unterstützten Prozess auf Organisationsebene kann ein ent-

sprechendes Messsystem zugeordnet werden, das dessen Führungsgrössen misst und dar-

aus in regelmässigen Abständen einen elektronischen Bericht erstellt.614 Realisiert wird

dieses Messsystem auf Applikationsebene durch eine oder mehrere Applikation(en).

(12) Ein Anknüpfungspunkt zur Infrastruktur- und Technologieebene besteht über den Meta-

entitätstyp „Infrastrukturelement“. Jede Plattform sowie jede Softwarekomponente ist auf

einem bestimmten Infrastrukturelement (z.B. Server) installiert.

Aus Gründen der Übersichtlichkeit ist der Metaentitätstyp „Organisationseinheit“ in

Abbildung 64 nicht auf der Applikations- sowie auf der Softwarekomponenten- und Daten-

strukturebene eingezeichnet. Organisationseinheiten sowie deren Stellen und Personen kön-

nen auf diesen beiden Ebenen Verantwortlichkeiten (Ownership) für Applikationsdomänen,

einzelne Applikationen oder Softwarekomponenten, Informationsobjekte sowie Datenspeicher

und Plattformen zugeordnet werden.

4.8 Detaillierungsgrad und Schnittstellen zu domänenspezifi-

schen Architekturmodellen und Modellierungssprachen

Im Verständnis der vorliegenden Arbeit umfasst die Unternehmensarchitektur alle

Schlüsselelemente des Unternehmens in aggregierter Form. Für die Durchführung von

Impact-Analysen und die Beantwortung von Fragestellungen des IT-Business-Alignment ist

eine umfassende Abbildung aller Schlüsselelemente in aggregierter Form sowie ihrer

Beziehungen nützlicher als eine detaillierte Spezifizierung weniger Elemente einer

bestimmten Anwendungsdomäne.

Gerade bei der Abbildung der Gesamtzusammenhänge würde die Verwendung einer

detaillierten Modellierungssprache, wie beispielsweise der UML, zahlreiche „kreative“

Hilfskonstruktionen erfordern, um die einzelnen auf unterschiedlichen Ebenen definierten

Modelle miteinander integrieren zu können. Zudem würden die auf diese Weise erstellten

Modelle einen höheren Detaillierungsgrad aufweisen und wären für Mitarbeiter aus anderen

Fachabteilungen nur schwer verständlich. Die detaillierte Abbildung bestimmter Aspekte

sollte deshalb nicht im Rahmen der Unternehmensarchitektur, sondern weiterhin in

domänenspezifischen Architekturmodellen und mit entspechenden Modellierungssprachen

(und Werkzeugen) erfolgen. Folglich sind die wesentlichen Schnittstellen zu diesen

Detailmodellen zu identifizieren. Abbildung 65 zeigt exemplarisch für jede Architekturebene



einige ausgewählte Elemente, die Schnittstellen zu domänenspezifischen Detailmodellen und

Werkzeugen bieten. Anhaltspunkte für mögliche Schnittstellen bieten in der Regel

Metaentitätstypen, die eine rekursive Beziehung (Dekomposition oder Spezialisierung)

besitzen.

(1) Auf Strategieebene bietet beispielsweise der Metaentitätstyp „Marktleistung“ eine

mögliche Schnittstelle zu Detailmodellen der strategischen Unternehmensplanung. Die

Leistungen/Produkte eines Unternehmens bzw. einer Geschäftseinheit sind oftmals in

Form von Produkthierarchiemodellen (Produktbäumen) in speziellen Produktsystemen615

detailliert erfasst. Der Ansatz der vorliegenden Arbeit bildet lediglich ab, welche

Leistungen (bzw. Leistungspakete) das Unternehmen bzw. die Geschäftseinheit anbietet,

sowie den Austausch der Leistungen zwischen unterschiedlichen Partnern im

Geschäftsnetzwerk. Die detaillierte Dokumentation der Einzelkomponenten und

Eigenschaften eines Produktes bzw. einer Leistung sowie deren Analyse sollte dagegen in

den operativen Produktsystemen erfolgen.

(2) Eine weitere Schnittstelle auf Strategieebene zu entsprechenden Detailmodellen besteht

über den Metaentitätstyp „Ziel“. Jedes Ziel und jede Kennzahl des Zielmodells sollte

entsprechend dem Konzept der BSC Teil einer Ursache-Wirkungs-Kette oder eines

Zielmodells sein. Diese Ursache-Wirkungs-Ketten und Zielmodelle sind in der Regel in

speziellen BSC616- oder Performance-Management-Werkzeugen617 detailliert erfasst.

(3) Auf Organisationsebene sind beispielsweise die Prozesse und deren Aktivitäten in

detaillierten, meist hierarchisch geschachtelten Modellen (z.B UML-Aktivitätsdiagramm,

BPMN618 oder EPK) der Prozessablaufplanung erfasst. Dafür kommen entsprechende

Werkzeuge des Prozess- und Workflowmanagements zum Einsatz.619 Das in dieser Arbeit

definierte Metamodell der Ablaufplanung ermöglicht im Prinzip auch eine beliebig

detaillierte Abbildung der Prozessabläufe, da es auf dem Metamodell der EPK basiert. Es

erscheint allerdings sinnvoll, diese lediglich mit dem geringsten Detaillierungsgrad

(entsprechend dem Detaillierungsgrad der in dem Prozessmanagement-Werkzeug

erfassten Modelle) abzubilden und mit dem/den entsprechenden Detailmodell(en) im

Prozessmangement-Werkzeug in Beziehung zu setzen.

(4) Die auf Informationssystemebene identifizierten Applikationen und Softwarekomponen-

ten können mit Hilfe von speziellen Modellierungssprachen und Werkzeugen des

615 Zu Produktmodellen und -systemen im Versicherungsbereich vgl. z.B. Coldewey (2000) und

Schönsleben/Leuzinger (1996). 616

Für eine Beschreibung und Bewertung von BSC-Werkzeugen vgl. z.B. Marr/Neely (2001). 617

Vgl. z.B. Dinter/Bucher (2006). 618

Vgl. BPMI (2002). 619

Für einen Überblick über Prozessmanagement-Werkzeuge vgl. z.B. Blechar/Sinur (2006).


Softwaredesigns verfeinert werden.620 Im Unterschied zur Modellierung von

Organisationsstrukturen und Prozessabläufen hat sich die UML im Bereich des

Softwaredesigns als Industriestandard durchgesetzt.621 Im Verständnis der UML 2.0

kapselt eine Komponente Zustand und Verhalten der in ihr enthaltenen Elemente und

bietet nach aussen Funktionen über definierte Schnittstellen an.622 Damit entspricht der

Komponentenbegriff der UML 2.0 weitgehend dem allgemeinen Verständnis sowie dem

Verständnis dieser Arbeit. Jede in der Unternehmensarchitektur erfasste (Software-)Kom-

ponente kann somit durch eine korrespondierende Komponente in einem UML-

Komponentendiagramm repräsentiert und dort detaillierter spezifiziert werden.

Abbildung 65: Schnittstellen zu domänenspezifischen Architekturen

(5) Im Bereich der Datenmodellierung und des Datenbankentwurfs hat sich die UML

ebenfalls als Standard etabliert. Für die Modellierung der Datenstruktur eines fachlichen

Anwendungsbereichs werden in der Regel UML-Klassendiagramme verwendet. Jedes Da-

tenobjekt der Softwarekomponenten- und Datenstrukturebene kann durch eine korrespon-

dierende Klasse in einem UML-Klassendiagramm repräsentiert und in einem Datenmodel-

lierungs-Werkzeug spezialisiert werden (vgl. hierzu auch Abschnitt 4.3.2.5).

(6) Für die Abbildung der Elemente der Infrastrukturebene definiert der Ansatz der

vorliegenden Arbeit ein vereinfachtes Infrastrukturmodell (vgl. Abbildung 52). Dadurch

620 Für einen Überblick über objektorientierte Softwaredesign-Werkzeuge vgl. z.B. Blechar (2005).


622 Vgl. OMG (2005), S. 139.


kann für jede Softwarekomponente, Plattform sowie Entwicklungs- und

Betriebskomponente erfasst werden, auf welchem Infrastrukturelement diese installiert ist.

Die Infrastrukturelemente lassen sich mit entsprechenden Elementen in einem detaillierten

IT-Infrastrukturmodell in Beziehung setzen. Für die Modellierung der IT-Infrastruktur

kommen in der Regel IT-Portfolio- oder Systemmanagement-Werkzeuge zum Einsatz.623

Eine weitere mögliche Schnittstelle, die nicht in Abbildung 65 dargestellt wird, besteht zu

einer oder mehreren Autorisierungskomponente(n), die zur Verwaltung der Zugriffsbe-

rechtigungen verwendet wird/werden (vgl. hierzu Abschnitt 4.3.2.6).

4.9 Zusammenfassung

Zusammenfassend lässt sich festhalten, dass der Ansatz dieser Arbeit sich von bereits

existierenden Unternehmensarchitektur-Ansätzen vor allem durch sein klar definiertes

Metamodell, die verwendeten Konzepte und insbesondere deren Zusammenhänge

unterscheidet. Im Gegensatz zu vielen anderen Unternehmensarchitektur-Ansätzen fordert er

explizit, dass keines der definierten Schlüsselelemente in vollem Detaillierungsgrad

abgebildet werden sollte, um sich dadurch insbesondere auf die Zusammenhänge zwischen

diesen Elementen konzentrieren zu können. Der entwickelte Ansatz adressiert somit vor allem

die im Grundlagenteil definierten Kriterien der Konsistenz, Formalisierung und

Ganzheitlichkeit (vgl. Abschnitt 2.6.1).

Obwohl das ebenenübergreifende Metamodell im Prinzip auch die detaillierte Modellierung

der meisten (Teil-)Bereiche (z.B. Prozessmodellierung oder Datenmodellierung) zulässt,

erleichtert es die Erstellung integrierter Modelle mit einem für die Unternehmensarchitektur

angemessenen Detaillierungsgrad. Es bildet somit einen Bezugsrahmen, der Elemente und

Konzepte aus domänenspezifischen Ansätzen miteinander in aggregierter Form integriert und

Schnittstellen zu entsprechenden Detailmodellen bietet. Die Detailmodelle können somit

zunächst nebenläufig gestaltet und weiterentwickelt werden. Die entwickelte

Unternehmensarchitektur liefert Vorgaben, aus denen entsprechende Anpassungen resultieren,

die die Konsistenz des Gesamtsystems bewahren.

623 Vgl. hierzu z.B. Adams (2005).

Konstruktion eines Prototyps mit Hilfe eines Metamodellierungswerkzeuges 182

5 Konstruktion eines Prototyps mit Hilfe eines

Metamodellierungswerkzeuges

Nachdem im vorhergehenden Kapitel ein Ansatz für die Modellierung von Unternehmens-

architekturen mit einem ebenenübergreifenden Metamodell definiert wurde, gilt es nun,

diesen softwaretechnisch zu unterstützen. Im nächsten Abschnitt wird zunächst ein geeignetes

(Meta-)Modellierungswerkzeug ausgewählt. Anschliessend folgt die Beschreibung der

Abbildung der einzelnen (Teil-)Metamodelle sowie ihrer Abhängigkeiten mit Hilfe des aus-

gewählten Werkzeuges. Der entwickelte Software-Prototyp wird daraufhin im Hinblick auf

dessen wesentliche Komponenten und Funktionalitäten vorgestellt.

Die folgende Tabelle 19 fasst nochmals die im Grundlagenteil abgeleiteten Anforderungen an

die Werkzeugunterstützung zusammen. Diese wurden bei der Wahl des Werkzeuges sowie

bei der Konstruktion des Prototyps berücksichtigt.

Kriterium Beschreibung Modellierung und Mechanismen

Anpassbarkeit/

Erweiterbarkeit

Eine Anpassung oder Erweiterung des zugrunde liegenden Metamodells sowie der ver-wendeten Darstellungsformen sollte weitgehend ohne Programmieraufwand möglich sein.

Integration Die Integration oder Verbindung von Metamodellen aus unterschiedlichen Anwen-dungsbereichen sollte möglichst ohne Programmieraufwand erfolgen können.

Konsistenz Es müssen entsprechende Mechanismen für die Überprüfung der Konsistenz zwischen den erstellten Modellen und deren Abhängigkeiten implementiert werden können.

Migration

Bei der Änderung bzw. Erweiterung des zugrunde liegenden Metamodells muss eine einfache Migration von Modellen, die noch auf einer alten Version des Metamodells basieren, möglich sein.

Wiederver-

wendung

Es müssen Mechanismen für die Klassifikation und Kategorisierung sowie Suchmuster für die Wiederverwendung von Modellen bereitgestellt werden.

Import/Export

Eine Datenbank (Repository) mit Import-/Export-Funktionalitäten für Metamodelle, Modelle und Methodenfragmente ist ein zentraler Bestandteil eines Metamodellie-rungswerkzeuges.

Analyse

Das Werkzeug muss Funktionen für die Generierung unterschiedlicher Sichten auf Mo-delle, Objekte und Attribute zur Verfügung stellen, um damit auch generelle Mechanis-men für die Modellanalyse bereitstellen zu können.

Automatisierung

Das Werkzeug sollte Funktionalitäten für die Automatisierung bestimmter Modellie-rungsaktivitäten bereitstellen, beispielsweise bei der Modellgenerierung basierend auf Referenzmodellen oder der Sichtengenerierung basierend auf importierten Modellinfor-mationen.

Organisation

Planung

Die Integration mit Projektmanagement-Werkzeugen ermöglicht die Einhaltung und Planung der von der verwendeten Methode definierten Vorgehensweisen und Ergebnis-se.

Versionierung

Unterschiedliche, vom jeweiligen Anwendungsbereich abhängige Versionierungskon-zepte (beispielsweise zeitliche Versionierung, modellbasierte Versionierung oder Check-In/Check-Out-Mechanismen), sind ein wichtiger Bestandteil.

Rechtekonzept

Anwendungskonzepte werden durch Rollenmodelle und Verantwortlichkeiten unter-stützt. Diese müssen auch in dem Rechtekonzept bzw. Autorisierungskonzept des Werk-zeuges implementiert sein.


Benutzer-

freundlichkeit

Eine intuitiv bedienbare Benutzeroberfläche erleichtert die Einarbeitung von Anwen-dern. Unterschiedliche Sichten, abhängig von den Kenntnissen der Anwender, sollten ohne Programmieraufwand flexibel generiert werden können.

Referenz-

modellierung

Wenn die Methode Best Practices beinhaltet, sollte das Werkzeug das Vorgehen zur Anwendung und Anpassung dieser Best Practices unterstützen.

Technologie

Verteilung

Es sollte eine verteilte Modellierung und Ergebnisdokumentation möglich sein. Die Ergebnisdokumentation könnte beispielsweise in Form von HTML-Seiten, auf die zen-tral im Intranet zugegriffen werden kann, erfolgen.

Schnittstellen

Das Werkzeug muss Schnittstellen zu den operativen Systemen anbieten, um die aggre-gierten Informationen der Unternehmensarchitektur mit den Detailinformationen der operativen Systeme verknüpfen zu können.

Architektur

Das Werkzeug sollte für unterschiedliche Architekturen, wie Stand-alone, Client-Server und Application Hosting, konfigurierbar sein. Eine offene, serviceorientierte Architektur ermöglicht die Integration zusätzlicher Modellierungswerkzeuge, Standard-Interfaces sowie wieder verwendbare Komponenten.

Plattform-

unabhängigkeit Das Werkzeug sollte plattformunabhängig einsetzbar sein.

Tabelle 19: Wesentliche Anforderungen an die Werkzeugunterstützung624

5.1 Auswahl eines geeigneten Werkzeuges für die Abbildung

des Ansatzes

Der Markt für Werkzeuge zur Modellierung der Unternehmensarchitektur befindet sich zur-

zeit noch in einer Entwicklungsphase (vgl. Abschnitt 2.4), wodurch die Auswahl geeigneter

Werkzeuge erschwert wird. Die Auswahl der betrachteten Werkzeuge richtet sich nach dem

so genannten „Magic Quadrant for Enterprise Architecture Tools“ von Gartner.625

Es wurden Anbieter ausgewählt, die unterschiedliche Positionen („Nischenanbieter“, „Markt-

führer“ und „Visionär“) in der Matrix einnehmen. Popkin Software und IDS Scheer werden

von Gartner als Marktführer, Casewise als Visionär und Adaptive als Nischenanbieter einge-

stuft. Zusätzlich wurden Alfabet und Adonis ausgewählt, da diese vor allem im deutschspra-

chigen Raum weit verbreitet sind.

Die Analyse wurde im Mai 2005 abgeschlossen. Sie umfasst die in Tabelle 20 aufgeführten

Werkzeuge. Die Untersuchung basiert auf Anbieterhomepages sowie Produktbroschüren,

Whitepapers, Präsentationen oder Evaluierungsversionen der Lösungen, die im Internet frei

zugänglich sind oder auf Anfrage zur Verfügung gestellt wurden. Darüber hinaus wurden von

Gartner veröffentlichte Berichte für die Auswahl und Bewertung der Werkzeuge herangezo-

gen. Eine detaillierte Darstellung der ausgewählten Werkzeuge anhand eines qualitativen Be-

zugsrahmens findet sich im Anhang dieser Arbeit (vgl. Anhang B).

624 Vgl. Abschnitt 2.6.2.

625 Vgl. James (2005a).


Kommerziell verfügbare Werkzeuge (2005) Anbieter Produkt Domäne

626 Marktposition

627 Frameworks

Adaptive Enterprise Architec-ture Manager

Enterprise Architectu-re, IT-Management

Nischenanbieter Zachman, FEAF

Alfabet Strategic IT Mana-gement

IT-Management Nischenanbieter SITM Framework

BOC ADONIS Geschäftsprozessma-nagement

(nicht eingeordnet) ADONIS-Methode

Casewise Casewise Corporate Modeler

Enterprise Architecture Visionär Zachman, FEAF,TEAF, Do-DAF

IDS

Scheer

ARIS Design Plat-form

Geschäftsprozess-management

Marktführer ARIS Framework

Popkin Enterprise Architect Enterprise Architecture Marktführer Zachman, TOGAF, DoDAF

Tabelle 20: Übersicht über kommerziell verfügbare Werkzeuge

Die betrachteten Werkzeuge haben gemeinsam, dass sie alle einen oder mehrere Bezugsrah-

men zur Strukturierung der Artefakte eines Unternehmens unterstützen. Die am häufigsten

unterstützten Bezugsrahmen sind das Zachman Framework, FEAF und TOGAF (vgl. Ab-

schnitt 3.3). In den meisten Fällen werden die Bezugsrahmen als Grafik mit Verweisen zu den

entsprechenden Modellen umgesetzt. Einige Werkzeuge unterstützen auch die integrierte

Verwendung mehrerer Bezugsrahmen, die Anpassung eines mitgelieferten Bezugsrahmens

oder die Implementierung eines neuen, unternehmensspezifischen Bezugsrahmens. Werkzeu-

ge, die primär aus dem Bereich der Repositorys stammen, wie beispielsweise der Enterprise

Architecture Manager von Adaptive, bieten in der Regel umfangreichere Importfunktionen.

Dagegen bieten Werkzeuge, die eher aus dem Bereich der Modellierung stammen, bessere

Visualisierungsfunktionen. Die Modelle, Objekte, Eigenschaften, Beziehungen und weitere

Entitäten können in allen Werkzeugen zumindest bis zu einem gewissen Grad individuell an-

gepasst werden. Komplexere Anpassungen müssen aber in der Regel von den Anbietern

durchgeführt werden. Die Artefakte werden üblicherweise in Repositorys abgelegt, denen

eine gängige relationale Datenbank zugrunde liegt, welche auf einem zentralen Server in einer

Multi-User-Umgebung läuft.

Da sich die betrachteten Werkzeuge hinsichtlich der Modellierungsoberfläche, der unterstütz-

ten Bezugsrahmen/Methoden, des Repositorys und der Systemarchitektur (vgl. Anhang B)

sowie hinsichtlich der Erfüllung der wichtigsten im Grundlagenteil abgeleiteten Kriterien

(vgl. Tabelle 21) nicht wesentlich voneinander unterscheiden, ist in der vorliegenden Arbeit

das entscheidende Kriterium für die Wahl eines bestimmten Werkzeuges die Erweiterbar-

keit/Anpassbarkeit. Zudem ist dieses Kriterium wichtig für die Abbildung des Metamodells

mit einem möglichst geringen Programmieraufwand.

626 Dieses Kriterium gibt an, für welche Anwendungsdomäne das Werkzeug ursprünglich entwickelt wurde.

Vgl. hierzu auch Abbildung 13. 627

Vgl. James (2005a).


Überblick über die Ergebnisse der Bewertung

Lösung/Kriterium

An

aly

se u

nd

Sim

ula

tion

An

pass

bark

eit/

Erw

eite

rbark

eit

Arc

hit

ektu

r

Ben

utz

erfr

eun

dli

chk

eit

Imp

ort

/Exp

ort

(R

eposi

tory

)

Inte

gra

tion

Kon

sist

enz

Rec

hte

kon

zep

t

Ver

sion

ieru

ng

Ver

teil

un

g

Adaptive

Enterprise Architecture Manager X X X X628 X X X X X X

Alfabet

SITM 2.0 X -629 X X X X X X X X

BOC

ADONIS 3.81 X X X X X X X X X X

Casewise

Corporate Modeler 10 X X X X X X X X X X

IDS Scheer

ARIS Design Platform 6.23 X -630 X X X X X X X X

Popkin

System Architect 10.1 X X X X X X -631 X - X

Tabelle 21: Erfüllung der wichtigsten Kriterien632

Die Entscheidung fiel daher zugunsten von ADONIS aus. Das Werkzeug deckt bereits ohne

anwendungsspezifische Anpassungen alle Hauptkriterien ab (vgl. Tabelle 21). Durch sein

methodenunabhängiges Metamodellierungskonzept ermöglicht ADONIS eine flexible und

einfache Umsetzung sowie Anpassung der Metamodelle des in dieser Arbeit präsentierten

Ansatzes mit wenig Programmieraufwand. Sogar komplexere Anpassungen bzw. Erweiterun-

gen können nach relativ geringer Einarbeitungszeit vom Anwender selbst durchgeführt wer-

den.

628 Der Adaptive Enterprise Architecture Manager ist ein reines Repository, das keine eigene

Modellierungsoberfläche besitzt. Das Werkzeug unterstützt aber die Interaktion mit zahlreichen anderen Modellierungswerkzeugen, wie z.B. Microsoft Visio.

629 Alfabet ermöglicht dem Anwender lediglich die Erweiterung des Metamodells um zusätzliche Attribute.

Entitäten und Beziehungstypen müssen durch Serviceleistungen von Alfabet hinzugefügt werden. 630

Komplexe Anpassungen müssen in der Regel durch Serviceleistungen von IDS Scheer oder dessen Partnern vorgenommen werden.

631 Modellübergreifende Konsistenzprüfungen müssen vom Anwender selbst programmiert werden.

632 Für eine Erläuterung der einzelnen Kriterien vgl. Tabelle 19 zu Beginn des Abschnitts 5.1.


5.2 Beschreibung der Abbildung in ADONIS

Nachdem im vorhergehenden Kapitel ein Lösungsansatz für das ebenenübergreifende Meta-

modell präsentiert wurde, wird nachfolgend beschrieben, wie die einzelnen (Teil-)Metamo-

delle sowie deren Abhängigkeiten mit Hilfe der zuvor ausgewählten Metamodellierungsplatt-

form abgebildet werden können.

5.2.1 Metamodellierungskonzept

Die ADONIS-Plattform basiert auf einem methodenunabhängigen Metamodellierungskon-

zept, das unterschiedliche Funktionalitäten und Mechanismen für die Anpassung an eine be-

stimmte Methode bzw. ein bestimmtes Metamodell zur Verfügung stellt.

Die Plattform besitzt eine komponentenbasierte, verteilte und skalierbare Systemarchitektur

(vgl. Abbildung 66). Die Speicherung aller Modell- und Metamodellinformationen erfolgt

durch so genannte Persistenzdienste. Persistenzdienste bieten eine Schnittstelle zu einer Da-

tenbank, in der die Daten gespeichert werden, und verbergen somit die zugrunde liegenden

Speicherformen, wie beispielsweise spezifische Datenbanksysteme oder Dateisysteme. Zu-

dem ermöglichen Speicherdienste die Verteilung und Wiederverwendung von Komponenten

der gespeicherten Modelle und Metamodelle.

Das Meta-Metamodell ist der zentrale Bestandteil der Architektur der ADONIS-Plattform, da

es die konzeptionelle Grundlage bildet und mit allen anderen Bestandteilen in Verbindung

steht.633 Es stellt die grundlegenden Konzepte für die Generierung von Metamodellen und

Mechanismen zur Verfügung, wie beispielsweise Klassen, Relationen, Attribute, Modelltypen

oder Skripte.

Die „Metamodel Base“ umfasst alle Informationen über die aktuell von der Modellierungs-

plattform verwalteten Metamodelle. Änderungen an den zugrunde liegenden Metamodellen

werden automatisch an die „Model Base“ delegiert, um die Modelle und deren zugrunde lie-

genden Metamodelle konsistent zu halten.

Die „Mechanism Base“ umfasst Informationen zu den Funktionalitäten und Mechanismen

(z.B. Analyseabfragen), die auf Modelle und Metamodelle angewendet werden können. Diese

Funktionalitäten können entweder direkt in der „Mechanism Base“ oder ausserhalb der Me-

tamodellierungsplattform gespeichert werden.

In der „Model Base“ werden alle auf den Metamodellen basierenden Modelle verwaltet. Die

„Model Base“ kommuniziert in regelmässigen Abständen mit der „Metamodel Base“, um

Informationen über mögliche Änderungen der Metamodelle zu erhalten und diese an die ent-

sprechenden Modelle weiterzuleiten.



Zugriffsdienste bieten dateibasierte (z.B. XML, XMI) sowie online-basierte (z.B. Java, IDL)

Schnittstellen zu den unterschiedlichen Datenbanken. Entsprechend den Zugriffsrechten kön-

nen die in den Datenbanken gespeicherten Informationen abgefragt und geändert werden.

Auf Grundlage der Zugriffsdienste unterstützen verschiedene Komponenten die Verwendung

und Verwaltung der Metamodellierungsplattform, wie beispielsweise Modell- und Metamo-

dell-Editor, Mechanismen-Editor etc.634

API

File

Abbildung 66: Architektur der ADONIS-Plattform635

5.2.2 Basiskonzepte in ADONIS

Um die Abbildung des Metamodells in ADONIS beschreiben zu können, ist es zunächst not-

wendig, einige grundlegende in ADONIS verwendete Konzepte darzustellen.

Jeder Methode liegt in ADONIS eine Anwendungsbibliothek zugrunde (vgl. Abbildung 67).

Diese kann mit Hilfe des ADONIS-Administrations-Toolkits erstellt und angepasst werden.

In der Anwendungsbibliothek sind alle Informationen für die individuelle, angepasste Ver-

wendung von ADONIS enthalten. Sie besteht immer aus einer Geschäftsprozessbibliothek

(GP-Bibliothek) mit den Informationen für Ablaufmodelle (z.B. Geschäftsprozessmodell)

sowie einer Arbeitsumgebungsbibliothek (AU-Bibliothek) mit den Informationen für Auf-

baumodelle (z.B. Organigramm). GP- und AU-Bibliotheken enthalten die Definitionen für

Modelltypen und Klassen (inklusive Beziehungsklassen).




Abbildung 67: Basiskonzepte in ADONIS

Ein Modelltyp ist eine Gruppierung von Klassen. Klassen stellen die Schablone für die durch

einen Modellierer angelegten Objekte dar. Klassen besitzen Klassenattribute, welche bei-

spielsweise die grafische Darstellung eines Objekts oder die Anordnung der Objektattribute

steuern. Darüber hinaus werden in den Klassen auch die (Objekt-)Attribute definiert. Jedem

(Objekt-)Attribut werden bei der Definition ein Attributtyp und ein Standardwert zugewiesen.

In der Modellierungskomponente von ADONIS werden auf einem Modelltyp basierende Mo-

delle (z.B. Geschäftsprozessmodelle) angelegt. Modelle besitzen Modellattribute, welche all-

gemeine Informationen zum Modell (z.B. Erstellungsdatum, Status) enthalten. Ein Modell

besteht aus Objekten, welche von Klassen abgeleitet (= instanziert) sind. Objekte besitzen

(Objekt-)Attribute, in welchen die Informationen für die Beschreibung des Modellinhalts hin-

terlegt werden.

5.2.3 Das ADONIS-Administrations-Toolkit

Die Anpassung der ADONIS-Plattform für die Abbildung der Metamodelle und Analyseaus-

wertungen einer bestimmten Methode erfolgt mit dem Administrations-Toolkit. Jeder Metho-

de liegt, wie bereits zuvor beschrieben, eine Anwendungsbibliothek (AB) zugrunde, die eine

methodenspezifische Konfiguration der ADONIS-Plattform definiert. Jedem Benutzer wird

eine AB zugewiesen, und umgekehrt können einer AB mehrere Benutzer zugeordnet sein

(vgl. Abbildung 68). Jede AB ist sowohl durch die Definition der Methode und deren Meta-

modelle als auch durch die Definition der Auswertungsmechanismen definiert.

Das Administrations-Toolkit umfasst die folgenden Komponenten:636

• In der Benutzerverwaltung werden Benutzer und Benutzergruppen für die Arbeit mit der

ADONIS-Plattform eingerichtet. Jedem Benutzer wird eine Anwendungsbibliothek zuge-

wiesen. Zudem wird jeder Benutzer einer (oder mehreren) Benutzergruppe(n) zugeordnet.

636 Vgl. im Folgenden auch das ADONIS-Benutzerhandbuch.


• In der Bibliothekenverwaltung können Anwendungsbibliotheken importiert, exportiert,

umbenannt oder gelöscht werden. Durch die Konfiguration der Bibliotheken können

Bibliotheks- und Klassenattribute bearbeitet und überprüft werden.

• Benutzer können später in der Modellierungskomponente des erstellten Werkzeuges Mo-

delle des in dieser Arbeit beschriebenen Ansatzes erstellen und bearbeiten (z.B. Ge-

schäftsnetzwerkmodelle, Leistungsmodelle, Prozesslandkarten etc). Jedes dieser Modelle

ist entweder einer GP- oder einer AU-Bibliothek zugeordnet.

• In der Modellverwaltung werden Modellgruppen angelegt, bearbeitet und gelöscht. Ferner

wird definiert, welche der bestehenden Benutzergruppen Lese- oder Schreibrechte bzw.

keinen Zugriff auf diese Modellgruppen haben. Zudem können Modelle importiert, expor-

tiert und gelöscht sowie Anwendungsmodelle und Attributprofile importiert und exportiert

werden.

• In der Attributprofilverwaltung werden Attributprofile angelegt, bearbeitet oder gelöscht.

Attributprofile werden in der Modellierungskomponente des Geschäftsprozessmanage-

ment-Toolkits referenziert und stellen somit das Repository-Konzept in ADONIS dar.

Die methodenspezifischen Klassen, Beziehungen und Attribute werden in enger Zusammen-

arbeit zwischen dem Werkzeugentwickler und dem Metamodellierer bzw. Methodenkonstruk-

teur in der Anwendungsbibliothek unter Verwendung des Administrations-Toolkits angelegt,

um eine möglichst vollständige Abbildung der Metamodelle der Methode zu gewährleisten. In

der Anfangsphase sollten daher Werkzeugentwickler und Methodenkonstrukteur gemeinsam

vor Ort die Anpassung vornehmen. Zusätzliche Erweiterungen (z.B. bestimmte Analyseme-

chanismen) oder Anpassungen können dann später auch (nach Absprache mit dem Methoden-

konstrukteur) von dem Werkzeugentwickler selbst vorgenommen werden.

Konzepte des ADONIS-Administrations-Toolkits

Anwendungs-

bibliothekBenutzer

Modell-

gruppe

Attributprofil-

gruppe

Attribut-

profilModell

Benutzer-

gruppe

Datenbankist gespeichert inist gespeichert in

ist

gespeichert in

ist zugeordnet

ist

zugeordnet

ist

zugeordnet

ist

zugewiesen

sind definiert für eine

basieren

auf einer

ist definiert für eine

ist definiert

für eine

ist

referenziert in

hat keinen Zugriff auf

hat Lesezugriff auf

hat Schreib-/Lesezugriff auf

Abbildung 68: Konzepte des ADONIS-Administrations-Toolkits


5.2.4 Abbildung der Metamodelle

Die Abbildung des Metamodells des in Kapitel 4 beschriebenen Ansatzes mit Hilfe der

ADONIS-Metamodellierungsplattform erfolgte in mehreren Schritten (vgl. Abbildung 69).

Ableitung des Metamodells

(Metaentitätstypen und Attribute)

Umsetzung der Metamodellkonsistenz

(Beziehungstypen und Kardinalitäten)

Implementierung von Konsistenzprüfungen

Anpassung von Modellierungsmechanismen

für die Referenzmodellierung

Anpassung von Analysemechanismen

für spezifische Modellauswertungen

Anpassung von Simulationsmechanismen

für spezifische Modellauswertungen

Abbildung 69: Schritte bei der Implementierung

des Metamodells in ADONIS

Als Erstes wurde damit begonnen, die einzelnen (Teil-)Metamodelle des Ansatzes der vorlie-

genden Arbeit von dem Meta-Metamodell der ADONIS-Plattform (vgl. Abbildung 12) abzu-

leiten und entsprechend anzupassen. Die spezifischen Metaentitätstypen und Beziehungstypen

des Ansatzes wurden in der Metamodelldatenbank der Plattform gespeichert. Im nächsten

Schritt musste die Konsistenz der einzelnen Metamodelle sichergestellt werden, indem die

Kardinalitäten der Beziehungen zwischen Metaentitätstypen sowie zusätzliche Funktionalitä-

ten für die Konsistenzprüfung implementiert wurden.

Da gerade auf Strategieebene einige branchenspezifische Referenzmodelle zur Verfügung

stehen, wie beispielsweise für das Leistungsmodell637, war es notwendig, entsprechende

Funktionen für die Referenzmodellierung zu implementieren. Diese wurden mit Hilfe von

Skripten umgesetzt. Dadurch ist es möglich, die benötigten Komponenten eines Referenzmo-

dells auszuwählen und daraus neue Modelle zu generieren und diese anschliessend an das

unternehmensindividuelle Umfeld anzupassen. Um die mit dem Werkzeug erstellten Modelle

analysieren zu können, beispielsweise im Hinblick auf ihre Konsistenz und auf die Zusam-

menhänge zwischen bestimmten Objekten, wurden einige bereits durch die

Metamodellierungsplattform vordefinierte Abfragen und Berichte angepasst.

637 Vgl. Heinrich/Winter (2004).


Weitere Analysefunktionen wurden in nachfolgenden Implementierungsschritten und im

Rahmen des Testeinsatzes umgesetzt.

Um die in Kapitel 4 beschriebenen Metamodelle in ADONIS abzubilden, musste zuerst eine

neue Anwendungsbibliothek angelegt und anschliessend angepasst werden. Diese besteht aus

einer GP- und einer AU-Bibliothek. In der GP-Bibliothek wurden alle Metamodelle der Stra-

tegie-, Organisations- und Systemebene abgebildet. Die AU-Bibliothek wurde lediglich für

die Abbildung des Metamodells der Aufbauorganisation verwendet.

Für jeden Objekttyp des Metamodells (z.B. der Objekttyp „Service Integrator“ im Metamodell

des Geschäftsnetzwerks) wurde eine eigene instanzierbare Klasse in ADONIS angelegt. Jede

Klasse besitzt Klassenattribute, welche beispielsweise die grafische Darstellung auf der Zei-

chenfläche, die Anordnung der Attribute in den ADONIS-Notebooks638 und die Verknüpfung

mit anderen Modellen steuern. Für Beziehungstypen, die zwei Objekttypen eines Metamo-

dells verbinden, wie z.B. „bezieht Leistung“, kann eine Beziehungsklasse definiert werden.

Modellübergreifende Beziehungen bzw. Abhängigkeiten zwischen Modellen oder Objekten

können mit Hilfe von Klassenattributen des Typs „Referenz“ abgebildet werden. So steht bei-

spielsweise eine Instanz des Objekttyps „Service Integrator“ immer in Beziehung mit einer

Instanz des Objekttyps Organisationseinheit (Unternehmen oder Geschäftseinheit, welche(s)

die Rolle des Service Integrator im Geschäftsnetzwerk einnimmt). Durch die Definition einer

Referenz kann von dem Objekt des Typs „Service Integrator“ im Geschäftsnetzwerkmodell

direkt zu dem entsprechenden Objekt des Typs „Organisationseinheit“ im Modell der Auf-

bauorganisation navigiert werden.

Nach der Definition der einzelnen Klassen sowie ihrer Attribute, konnte für jedes Metamodell

bzw. jeden Ergebnisdokumenttyp ein eigener Modelltyp in ADONIS definiert werden. Ein

Modelltyp legt eine Teilmenge aller instanzierbaren Klassen und Beziehungen fest. Jedes

Modell, welches mit der Modellierungskomponente erstellt wird, gehört zu einem bestimmten

Modelltyp, der nach Anlegen des Modells nicht mehr geändert werden kann.

Bei der Abbildung der einzelnen Metamodellelemente in ADONIS mussten zunächst folgen-

de grundlegenden Fragen beantwortet werden:

• Für welche Metaentitätstypen sollen instanzierbare Klassen angelegt werden?

• Soll ein Metaentitätstyp als eigene Klasse oder als Attribut implementiert werden?

• Welche Attribute soll eine bestimmte Klasse besitzen?

• Welcher Attributtyp soll einem bestimmten Attribut zugewiesen werden?

• Soll eine Beziehung mit Hilfe eines Klassenattributs des Typs „Referenz“ oder als eigene

Beziehungsklasse abgebildet werden?



• Welche Navigationsrichtungen sollen zwischen Modellen und Objekten möglich sein?

• Welche grafischen Repräsentationen sollen für die Klassen und die Beziehungsklassen

verwendet werden?

• Welche Modelltypen sollen definiert werden und welche Klassen sind in diesen enthalten?

Tabelle 22 zeigt beispielhaft einige für den Modelltyp „Geschäftsnetzwerk“ definierten Klas-

sen, Beziehungsklassen, Referenzen, Attribute und Attributtypen (vgl. dazu Abbildung 34).

Modelltyp „Geschäftsnetzwerk“

(Beziehungs-)Klasse Attribut Attributtyp

Organisationseinheit Referenz auf Organisationseinheit in Aufbauorganisation Name Text Beschreibung Text, mehrzeilig Kommentar Text, mehrzeilig Leistungsmodell Referenz auf Leistungsmodell

Service Integrator

… Kundenprozess Referenz auf Kundenprozess in Kundenprozessmodell Name Text Beschreibung Text, mehrzeilig

Kundenprozess

… Name Text Beschreibung Text, mehrzeilig Endkunde

… Name Text Beschreibung Text, mehrzeilig Kundengruppe

… Art Enumeration (standardisiert, individualisiert)

bezieht Leistung Farbe kontextabhängig

Tabelle 22: Modelltyp Geschäftsnetzwerk

Im Wesentlichen sind alle in Abschnitt 4 beschriebenen (Teil-)Metamodelle und deren Bezie-

hungen in ADONIS als Modelltypen und Referenzen abgebildet. Eine detaillierte Dokumenta-

tion der Abbildung der einzelnen Metamodelle in ADONIS findet sich im Anhang dieser Ar-

beit (vgl. Anhang A).

5.3 Überblick über den Aufbau und die generellen Funktiona-

litäten

Der Prototyp besteht aus vier wesentlichen Komponenten.639 Den Kern des Prototyps bildet

die Modellierungskomponente. Diese stellt Werkzeuge für die Abbildung der einzelnen Mo-

delle einer Unternehmensarchitektur (z.B. Geschäftsnetzwerkmodell, Prozesslandkarte, Auf-

bauorganisation) zur Verfügung. Die Modelle können mit Hilfe des grafischen Editors (Mo-

delleditor) entworfen und verändert werden. Zusätzlich besteht auch die Möglichkeit einer

tabellarischen Modellierung, die vor allem bei der Eingabe von Attributwerten hilfreich ist.

639 Vgl. im Folgenden auch die Dokumentation der ADONIS-Metamodellierungsplattform.


In der Analysekomponente können Abfragen auf den mit der Modellierungskomponente er-

stellten Modellen durchgeführt und Beziehungstabellen sowie vordefinierte Pläne erzeugt

werden. Die Komponente bietet einerseits standardisierte Abfragen an, welche durch Vervoll-

ständigen eines Lückentextes ausgeführt werden können. Darüber hinaus können benutzerde-

finierte Abfragen durch Verknüpfung von standardisierten Abfragen erstellt oder vom An-

wender selbst definiert werden. Die vordefinierten Abfragen werden vom Administrator im

Administrations-Toolkit definiert und dem Anwender bzw. Modellierer zur Verfügung ge-

stellt. Die Darstellung der Ergebnisse der Abfragen kann als Text oder in einem Diagramm

erfolgen. Zudem können die Ergebnisse in Text-Dateien exportiert und in anderen Applikati-

onen (z.B. Tabellenkalkulation, Textverarbeitung etc.) weiterverarbeitet werden.

In der Simulationskomponente können Simulationen von Geschäftsprozessen bzw. der Ab-

lauforganisation und der Aufbauorganisation durchgeführt werden. Dafür stehen unterschied-

liche Simulationsalgorithmen zur Verfügung, mit deren Hilfe beispielsweise Pfadanalysen

von Geschäftsprozessmodellen erstellt sowie Belastungsanalysen von Geschäftsprozessmo-

dellen in Verbindung mit Modellen der Aufbauorganisation durchgeführt werden können.

Die Import/Export-Komponente ermöglicht es, bestehende Modelle und Modellgruppen in ein

von der Metamodellierungsplattform abhängiges Dateiformat (ADL-Format) zu exportieren

bzw. Dateien in das Werkzeug zu importieren. Der Datei-Export kann zusätzlich zur Datensi-

cherung der erstellten Modelle und Modellgruppen dienen. Darüber hinaus bietet die Im-

port/Export-Komponente die Möglichkeit zur Dokumentation der Modelle. Die Modelle kön-

nen in eine elektronische Modelldokumentation (z.B. HTML-, XML-Dateien) oder in eine

Papierdokumentation (z.B. RTF-Dateien für MS Word) überführt werden. Dadurch können

beliebig definierbare Modellinhalte in Dokumente eingebunden und beispielsweise unterneh-

mensweit publiziert werden. Die folgende Tabelle gibt einen Überblick über die wichtigsten

Komponenten des Werkzeuges sowie deren Funktionalitäten.

Komponente Beschreibung Funktionalitäten

Modelleditor

Grafischer sowie textueller Editor für die Erstellung von Modellen, der unter-schiedliche Ansichtoptionen sowie Navigationsmöglichkeiten zwischen den Modellen bietet

• Erstellen/Bearbeiten von Modellen • Grafische/tabellarische Darstellung • Modellnavigation • Modellverwaltung • Prüfung von Modellierungsrichtlinien

Analyse

Durchführung von Abfragen auf den mit der Modellierungskomponente erstellten Modellen sowie Generierung von Beziehungstabellen

• Vordefinierte Abfragen • Benutzerdefinierte Abfragen • Beziehungstabellen • Impact-Analysen • Vordefinierte Pläne

Simulation

Durchführung von Simulationsalgo-rithmen auf Modellen der Ablauf- und Aufbauorganisation

• Pfadanalyse • Belastungsanalyse • Berechnung von Kosten und Zeit


Import/Export Import/Export von Modellen in unter-schiedliche Datei-Formate

• ADL-Import/Export • Export/Import in HTML und XML • Export/Import in RTF- und Word-

Dateien

Dokumentation Dokumentation der erstellten Modelle und Veröffentlichung im Intranet

• MS Word • HTML-Seiten • Intranet

Abbildung 70: Komponenten und Funktionalitäten des Prototyps

5.4 Erstellen von Modellen im Modelleditor

Der Modelleditor enthält alle Funktionen, um Modelle zu erstellen und zu bearbeiten. Für die

Eingabe von Daten steht zusätzlich die tabellarische Modelldarstellung zur Verfügung. Jedes

Modell wird in einem eigenen Modellfenster dargestellt und enthält Objekte und Konnektoren

(Beziehungen).

Beim Anlegen eines neuen Modells erscheint zunächst ein Dialog, welcher die einzelnen Mo-

delltypen entsprechend der Ebenen Geschäftsstrategie, Organisation, Informationssystem und

IT-Infrastruktur gruppiert anzeigt (siehe Abbildung 71). Nachdem ein bestimmter neu zu er-

stellender Modelltyp ausgewählt wurde, wechselt die Ansicht zur Modellierungsoberfläche.

Auf der linken Seite der Modellierungsoberfläche werden die für den entsprechenden Modell-

typ verfügbaren Klassen und Beziehungsklassen (bzw. deren Notationselemente) angezeigt.

Für den Modelltyp „Geschäftsnetzwerk“ werden dort beispielsweise die Klassen „Service

Integrator“, „Shared Service Provider“, „bezieht Leistung“ etc. angezeigt. Durch Anklicken

einer Klasse können mehrere Objekte dieser Klasse auf dem Arbeitsbereich platziert werden.

Die Attributwerte eines Objektes werden über das so genannte Notebook festgelegt. Durch

einen Doppelklick auf ein bestimmtes Objekt wird dessen Notebook angezeigt. Dieses enthält

die für die Klasse dieses Objektes definierten Attribute. Dort können nun die für dieses Objekt

geltenden Attributwerte entsprechend den definierten Attributtypen eingetragen werden. Häu-

fig vorkommende Attributtypen sind beispielsweise Text, Zahl, Aufzählung und Referenz.

Um die Attributwerte der Objekte einer bestimmten Klasse bzw. der Konnektoren eines be-

stimmten Beziehungstyps von bestehenden Modellen systematisch bearbeiten zu können,

kann die tabellarische Modellierung verwendet werden.

Nach der Erstellung eines neuen Modells können dessen Kardinalitäten überprüft werden.

Diese sind durch das dem Modell zugrunde liegende Metamodell definiert. Die Kardinalitäten

geben an, wie viele Objekte einer Klasse in einem Modell enthalten sind, wie viele Konnekto-

ren einer Beziehung von einem Objekt wegführen und wie viele Konnektoren einer Bezie-

hung zu einem Objekt hinführen. Der Bereich der Kardinalitäten wurde bei der Abbildung des

Metamodells des Ansatzes in der Anwendungsbibliothek begrenzt (Kardinalitätsregeln), um

beispielsweise Modellierungsrichtlinien überprüfen zu können. Da die Kardinalitätsregeln

nicht automatisch während der Modellierung geprüft werden, muss die Prüfung der Kardinali-


täten eines Modells manuell über den entsprechenden Menüeintrag gestartet werden. Sollten

dabei die definierten Kardinalitätsregeln verletzt werden, wird eine entsprechende Fehlermel-

dung angezeigt. Die Prüfung kann daraufhin abgebrochen und die angezeigte Verletzung kor-

rigiert werden, oder es kann mit der Prüfung fortgefahren werden.

Abbildung 71: Anlage eines neuen Modells

In einer Multi-User-Umgebung können die Benutzer auf die erstellten Modelle und Objekte

gemeinsam zugreifen. Diese ermöglicht das kollaborative Arbeiten mehrerer Benutzer an

zentral gespeicherten Modellen von unterschiedlichen Standorten aus. Offline-Arbeiten an

Modellen können mit dem Repository synchronisiert werden. Ein Zugriffs- und Rechtesystem

sowie eine Reihe von Sicherheitsoptionen verhindern den unbefugten Zugriff auf die in der

zentralen Datenbank gespeicherten Modelle. So können beispielsweise Benutzergruppen einer

Modellgruppe zugeordnet werden und die Zugriffsrechte dieser Benutzergruppen auf die Mo-

dellgruppe definiert werden. Die Zugriffsrechte werden dabei nach „kein Zugriff“, „Lese-

zugriff“ und „Schreib-/Lesezugriff“ eingestuft. Des Weiteren lässt sich der Zugriff auf Kom-

ponenten für bestimmte Benutzer einschränken, so dass diesen nicht alle Funktionalitäten und

Mechanismen des Werkzeuges zur Verfügung stehen.

5.5 Durchgängigkeit und Abbildung der Gesamtzusammen-

hänge

Die Abhängigkeiten zwischen den Modellen auf einer Ebene sowie denen auf unterschiedli-

chen Ebenen werden durch modellübergreifende Referenzen abgebildet. Diese bieten die

Möglichkeit, von einem Objekt eines Modells auf andere Modelle (Modellreferenz) oder Ob-

jekte in anderen Modellen (modellübergreifende Objektreferenz) zu verweisen. Da die Abbil-

dung der Zusammenhänge zwischen den einzelnen Modellen von besonderer Bedeutung ist,

werden nachfolgend zur besseren Veranschaulichung einige Referenzen zwischen Modellen


des in dieser Arbeit vorgestellten Ansatzes zur Modellierung der Unternehmensarchitektur

beispielhaft beschrieben.

• Eine Rolle im Geschäftsnetzwerk ist immer mit einer Organisationseinheit (Unternehmen

bzw. Geschäftseinheit) assoziiert (vgl. Abbildung 63). Durch Anklicken einer Rolle im

Geschäftsnetzwerkmodell kann der Modellierer direkt zur entsprechenden Organisations-

einheit im Modell der Aufbauorganisation navigieren (siehe Abbildung 72).

• Eine weitere Referenz besteht beispielsweise jeweils zwischen einem bestimmten

Kundenprozess im Geschäftsnetzwerkmodell und dessen detaillierter Darstellung mit

seinen Teilaktivitäten und Teilleistungen im entsprechenden Kundenprozessmodell.

Durch Anklicken des Kundenprozessobjekts im Geschäftsnetzwerkmodell wird das

entsprechende Kundenprozessmodell im Arbeitsbereich geöffnet (siehe Abbildung 72).

Abbildung 72: Modellübergreifende Referenzen

Geschäftsnetzwerk Aufbauorganisation

Kundenprozess


Abbildung 73: Prozesshierarchie

PL Level 1

PL Level 2PL Level 3

Prozessablauf


• Die auf Prozessebene erzeugten Prozessleistungen werden in einem Pool hierarchisch

strukturiert verwaltet. Sie können bei der Modellierung der Prozesslandkarte sowie des

Prozessablaufs verwendet werden. Darüber hinaus können für jede Prozessleistung eine

oder mehrere Referenzen auf eine Leistungsspezifikation definiert werden (vgl. Bezie-

hung 5 in Abbildung 63).

• Ein Prozess innerhalb einer Prozesslandkarte kann entweder auf eine weitere Prozessland-

karte oder auf den entsprechenden Prozessablauf verweisen (siehe Abbildung 73). Inner-

halb des Prozessablaufs kann von einer Aktivität auf einen detaillierteren Prozessablauf

referenziert werden. Dadurch ist eine hierarchische Prozessmodellierung mit unterschied-

lichen Detaillierungsgraden möglich.

• Die kritischen Erfolgsfaktoren und Kennzahlen der Prozessführung (vgl. Abbildung 74)

korrespondieren mit den auf Strategieebene aus der Balanced Scorecard abgeleiteten kriti-

schen Erfolgsfaktoren und Kennzahlen (vgl. Beziehung 3 in Abbildung 63). Diese Kor-

respondenz wird ebenfalls durch eine modellübergreifende (Objekt-)Referenz abgebildet.

Darüber hinaus können die Kennzahlen auf Prozessebene auch als Referenz auf die Pro-

zessführung innerhalb eines Prozessablaufs dargestellt werden.

Abbildung 74: Beispiel Prozessführung

• Die Geschäftsfunktionen und Informationsobjekte der auf Prozessebene modellierten Pro-

zessabläufe besitzen jeweils eine Referenz auf die entsprechende Geschäftsfunktion bzw.

das entsprechende Informationsobjekt im Geschäftsfunktionen- bzw. Informationsobjek-

temodell. Ausserdem besitzen die im Geschäftsfunktionen- bzw. Informationsobjektemo-

dell dokumentierten Geschäftsfunktionen bzw. Informationsobjekte Referenzen auf die


zugrunde liegenden Erhebungsquellen (Prozesse der Prozesslandkarte, Organisationsein-

heiten der Aufbauorganisation oder Applikationen der Applikationsbestandsführung)

• Die aus den harmonisierten Geschäftsfunktionen, Informationsobjekten und Organisati-

onseinheiten abgeleiteten Applikationen werden in der Applikationsbestandsführung ver-

waltet. Dort können sie bei der Modellierung der Prozessabläufe referenziert werden, um

die informationstechnische Unterstützung der Aktivitäten von Prozessen abzubilden (vgl.

Beziehung 4 in Abbildung 64).

Die Arbeit mit mehreren, eventuell aufeinander referenzierenden Modellen wird durch die

Modellnavigation des Werkzeuges vereinfacht. Eine praktische Funktion der Modellnavigati-

on ist der Modell-Explorer. Der Explorer ist ein Sichtfenster, in dem die erstellten Modelle

und Modellgruppen sowie deren Statusinformation angezeigt werden. Er ermöglicht einen

Überblick über alle vorhandenen Modelle in Form einer Baumstruktur und einen direkten

Zugriff auf einzelne Modelle zur Bearbeitung. Zudem bietet er eine eigene Symbolleiste, die

Zugriff auf die Funktionen und Sichten ermöglicht. Weitere wichtige Funktionen der Modell-

navigation, die dem Modellierer die Arbeit erleichtern, sind die Modellumlauffunktion für das

Navigieren zwischen mehreren Modellfenstern und die Funktion für das automatische Öffnen

von referenzierten Modellen.

Das Werkzeug bietet darüber hinaus die Möglichkeit, die modellübergreifenden Referenzen

zu klassifizieren. Dies ist in allen Modellauswahllisten von Bedeutung, in welchen die Option

„Inklusive referenzierter Modelle" verfügbar ist (z.B. „Modell öffnen", „Abfragen", „Ex-

port"), da für die in diesen Listen selektierten Modelle alle referenzierten Modelle gemäss

ihren Einstellungen ermittelt und weiterverarbeitet werden. Dabei wird ein „Referenzbaum"

mit allen erreichbaren bzw. aufgrund der Einstellungen referenzierten Modellen gebildet.

Durch die Einstellungen zu den modellübergreifenden Referenzen kann festgelegt werden, bis

in welche Tiefe (Level) die Referenzen verfolgt werden und ob es sich um Haupt- oder Ne-

benreferenzen handelt. Die Tiefe gibt an, bis zu welchem Level – ausgehend vom selektierten

Modell – die Referenzen verfolgt und die referenzierten Modelle berücksichtigt werden.

Durch die Klassifikation in Hauptreferenz oder Nebenreferenz kann festgelegt werden, wie

nach dem Verfolgen einer Referenz weiter vorgegangen werden soll. Hauptreferenzierte Mo-

delle werden behandelt wie das (selektierte) Ausgangsmodell, d.h. alle in diesen Modellen

enthaltenen Referenzen werden verfolgt, wenn die Beschränkung der Tiefe dies zulässt. Bei

nebenreferenzierten Modellen werden die in diesen Modellen enthaltenen Referenzen nur

dann weiter verfolgt, wenn die enthaltenen Referenzen vom gleichen Attribut eines Objekts

der gleichen Klasse ausgehen und die Beschränkung der Tiefe dies zulässt. Im Gegensatz zu

Hauptreferenzen wird die Beschränkung der Tiefe bei Nebenreferenzen pro Ebene im Refe-

renzbaum erneut ausgewertet. Bei Hauptreferenzen wird die Tiefe global über alle Ebenen

hinweg überprüft. Die nachfolgende Abbildung 75 zeigt beispielhaft einen einfachen Refe-

renzbaum.


Das "Modell A" ist das Ursprungsmodell, von dem aus der Referenzbaum gebildet wird. Die

Modelle "Modell B", "Modell C" und "Modell D" werden über eine Hauptreferenz (z.B.

Subprozesse des Prozesses, der in „Modell A“ abgebildet ist) von "Modell A" referenziert und

bilden gemeinsam den Referenzbaum der Hauptreferenzen (Hauptbaum). Eine Tiefe von "2"

dieser Hauptreferenz bedeutet daher, dass im zu bildenden Referenzbaum das "Modell D"

unberücksichtigt bleibt und damit nicht angezeigt wird.

Tiefe

Abbildung 75: Referenzbaum

Die Nebenreferenzen werden pro Level betrachtet, d.h. die Tiefenauswertung erfolgt immer

von einem Modell des Hauptbaumes ausgehend, wobei die Zählung wieder bei 0 beginnt.

Eine Tiefe von "1" bei den Nebenreferenzen bedeutet bezogen auf Abbildung 75 daher, dass

im zu bildenden Referenzbaum die Modelle "Modell M" und „Modell N“ unberücksichtigt

bleiben.

5.6 Analyse der erstellten Modelle

Mit der Analysekomponente können die erstellten Modelle sowie deren Beziehungen statisch

ausgewertet werden. Die Funktionalität „Abfragen/Reports" ermöglicht die Auswertung be-

liebiger Modellinhalte (Objekte bzw. Konnektoren und deren Attribute), die den in der Abfra-

ge definierten Kriterien genügen. Die Ergebnisse dieser Abfragen können grafisch und tabel-

larisch dargestellt sowie in unterschiedlichen Datei-Formaten gesichert werden.

Zudem können die in der Anwendungsbibliothek vordefinierten Abfragen durchgeführt und

so genannte Beziehungstabellen erstellt werden. Die Beziehungstabellen stellen existierende

Beziehungen zwischen zwei Klassen beliebiger Modelltypen dar. Die Ergebnisse der vordefi-

nierten Abfragen und die Beziehungstabellen können ebenfalls gesichert werden.


Das Werkzeug bietet zwei Arten von Abfragen. Bei einer standardisierten Abfrage wird die

Abfrage mit Hilfe eines Lückentextes durchgeführt, ohne einen AQL-Ausdruck640 angeben zu

müssen (vgl. Abbildung 76). In den Lückentext müssen die für die Abfrage notwendigen In-

formationen eingegeben und aus der Liste der Klassen, Attribute oder Vergleichsoperatoren

die gewünschten Werte ausgewählt werden. Typische standardisierte Abfragen sind bei-

spielsweise:

• Ermittle alle Objekte, die mit dem Objekt [Objektname] der Klasse [Auswahl] über die

Beziehung [Auswahl] verbunden sind.

Mit dieser standardisierten Abfrage können alle Objekte ermittelt werden, die mit dem defi-

nierten Objekt in Beziehung stehen. Die Wahl des Objekts „Handel abwickeln" der Klasse

"Prozess" und der Beziehung „bezieht Leistung" ermittelt z.B. alle Prozesse in den ausge-

wählten Modellen, die von diesem Prozess eine Leistung beziehen.

• Ermittle alle Objekte der Klasse [Auswahl] mit Attribut [Auswahl] [Vergleichsoperator]

[Eingabe].

Durch diese Abfrage werden alle Objekte der gewählten Klasse mit einem bestimmten Attri-

butwert ausgegeben. So liefert z.B. die Auswahl der Klasse „Aktivität" mit dem Attribut

„Kosten", dem Vergleichsoperator „>" und der Eingabe des Wertes „1000" alle Objekte der

Klasse „Aktivität", deren Kosten größer als 1000 sind.

Abbildung 76: Standardisierte und benutzerdefinierte Abfragen

Bei einer benutzerdefinierten Abfrage definiert der Anwender die Abfrage durch Verknüpfen

von standardisierten Abfragen oder durch AQL-Ausdrücke, welche vom Anwender direkt

640 AQL (ADONIS Query Language) ist die Abfragesprache der ADONIS-Plattform, mit der Abfragen auf

allen Modellen durchgeführt werden können. Eine Definition der Syntax dieser Abfragesprache findet sich im Benutzerhandbuch von ADONIS.


eingegeben werden. Das Ergebnis eines AQL-Ausdrucks ist eine Menge von Objekten bzw.

Konnektoren, die dem gewünschten Suchkriterium genügt.

Eine weitere Funktionalität der Analysekomponente sind die so genannten Beziehungstabel-

len. Diese stellen die Existenz von Beziehungen dar, wobei in diesem Fall unter Beziehung

sowohl Konnektoren (innerhalb eines Modells) als auch modellübergreifende Referenzen zu

verstehen sind. In einer Beziehungstabelle wird angezeigt, welche Von-Objekte (z.B. Person)

mit welchen Nach-Objekten (z.B. Rollen) verbunden sind (vgl. Abbildung 77). Aufgrund der

Möglichkeit, auch die Beziehungen von modellübergreifenden Referenzen auszuwerten, kön-

nen die dargestellten Von- und Nach-Objekte in unterschiedlichen Modellen, auf unterschied-

lichen Ebenen und auch in Modellen unterschiedlicher Typen enthalten sein.

Abbildung 77: Beziehungstabelle

Für die Analyse der Ablauf- und Aufbauorganisation stehen unterschiedliche Simulationsal-

gorithmen zur Verfügung. Dadurch können beispielsweise Restrukturierungsmassnahmen

vorweggenommen und deren Auswirkungen aus verschiedenen Blickwinkeln betrachtet wer-

den.

Die Pfadanalyse ermöglicht eine Bewertung der erstellten Modelle der Ablauforganisation

(Prozessmodelle) ohne Betrachtung der Aufbauorganisation. Für ein Prozessmodell (inklusive

eventuell aufgerufener Subprozesse) liefert die Pfadanalyse prozess- und pfadbezogene Er-

gebnisse. Die prozessbezogenen Ergebnisse beschreiben durchschnittliche Zeiten und Kosten

des Prozessmodells. Die durchlaufenen Pfade können anhand ihrer Auftrittswahrscheinlich-

keiten und den von ihnen definierten Zeit- und Kostenkriterien bewertet werden. Zusätzlich

werden die einzelnen Pfade im Hinblick auf die Zeit- und Kostenkriterien grafisch und tex-

tuell dargestellt. Ausgangsbasis für die Pfadanalyse ist ein Prozessmodell mit allen zugehöri-

gen Subprozessen. Dieser Prozess sowie die von ihm aufgerufenen Subprozesse müssen kor-

rekt modelliert sein, d.h. sie müssen den Modellierungsrichtlinien (z.B. Kardinalitäten) ent-

sprechen. Des Weiteren müssen für die einzelnen Aktivitäten des Prozesses die durchschnitt-

lichen Zeiten und Kosten ermittelt und im Prozessmodell dokumentiert sein (vgl. Abbildung


78). Bei der Durchführung der Pfadanalyse werden anschliessend die Pfade des Prozessmo-

dells durchlaufen und die dabei entstehenden Zeiten und Kosten ermittelt.

Abbildung 78: Pfadanalyse und Simulation

Die Belastungsanalyse simuliert Prozesse unter Berücksichtigung der zugehörigen Aufbauor-

ganisation. Dabei werden die Aktivitäten der simulierten Prozesse von den ihnen zugeordne-

ten Rollenträgern ausgeführt. Gegebenenfalls werden für die Bearbeitung Ressourcen benutzt.

Dadurch können prozess- und periodenbezogene Aussagen bezüglich prozess- und stellenbe-

zogener Belastungen gemacht werden. Auf Basis der Ergebnisse der Belastungsanalyse kann

beispielsweise eine Personalbedarfsplanung durchgeführt werden. Ausgangsbasis für die Be-

lastungsanalyse ist ein Anwendungsmodell, bestehend aus genau einem Aufbauorganisati-

onsmodell und mindestens einem Prozessmodell. Zusätzlich zur korrekten Modellierung des

Ablaufes, analog zur Pfadanalyse, ist bei der Belastungsanalyse die Definition der Bearbeiter

(Rollen bzw. Rollenträger) der einzelnen Aktivitäten erforderlich. Wenn in den Prozessmo-

dellen Ressourcen (z.B. Applikationen, die die Durchführung einer Aktivität unterstützen)

modelliert wurden, ist auch eine Ressourcenzuordnung erforderlich.

Neben den zuvor genannten Analyse- und Simulations-Mechanismen lassen sich auch

sogenannte Impact-Analysen durchführen. Die Impact-Analyse ist zur Erkennung der

Auswirkungen von Veränderungen an der Unternehmensarchitektur und damit für ein

proaktives Management von zentraler Bedeutung. Grundlage dieser Analyseform sind die im

Metamodell definierten Beziehungen zwischen unterschiedlichen Modellen bzw. Sichten, die

sich gegebenenfalls auf unterschiedlichen Ebenen befinden. Die Ausführung einer Impact-

Analyse erfordert das Durchlaufen unterschiedlicher Sichten und Ebenen der

Unternehmensarchitektur und die Auswertung der entsprechenden Beziehungen, um

festzustellen, ob die Änderung eines Objektes sich über diese Beziehungen auf andere

Objekte auswirkt. Dadurch können Auswirkungen von Änderungen an Objekten bzw.


Elementen der Informationssystemebene (z.B. Ausfall einer Plattform oder

Softwarekomponente) auf die Organisations- und Strategieebene vorhergesagt werden

(Bottom-Up). Umgekehrt lassen sich aber auch die Auswirkungen von Veränderungen an der

Geschäftsstrategie (z.B. Änderung des Kundenprozesses oder Einführung einer neuen

Leistung) auf die Organisations- und Informationssystemebene abschätzen (Top-Down). Ein

Beispiel für das Ergebnis einer Impact-Analyse findet sich in Abschnitt 6.1.6.

5.7 Export/Import und Dokumentation

Da die Unternehmensarchitektur vor allem als Kommunikationsbasis für Mitarbeitende aus

unterschiedlichen Unternehmensbereichen dient, stellt der Export bzw. Import sowie die Do-

kumentation und Veröffentlichung der erstellten Modelle eine wichtige Funktionalität des

Werkzeuges dar.

Die Import/Export-Komponente ermöglicht es, bestehende Modelle in ein von der Metamo-

dellierungsplattform abhängiges Dateiformat (ADL-Format) zu exportieren bzw. Dateien in

das Werkzeug zu importieren. Der Datei-Export kann zusätzlich zur Datensicherung dienen.

Darüber hinaus bietet die Import/Export-Komponente die Möglichkeit zur Dokumentation der

Modelle. Die Modelle können in unterschiedliche Dateiformate (z.B. HTML-, XML-Dateien,

RTF-Dateien für MS Word) überführt werden. Dadurch können beliebig definierbare

Modellinhalte in Dokumente eingebunden und beispielsweise unternehmensweit im Intranet

publiziert werden (vgl. Abbildung 79).

Das Erstellen von Dokumentationsdateien wird durch die Auswahl des entsprechenden

Menüpunktes im Menü "Dokumentation" (z.B. "HTML-Generierung") gestartet. Nach

Anklicken des Menüpunktes öffnet sich das Modellauswahlfenster, in welchem alle in der

ADONIS-Datenbank gespeicherten Modelle aufgelistet werden. Darin können die zu

dokumentierenden Modelle ausgewählt werden. Durch die Aktivierung der Option "Inklusive

referenzierter Modelle" werden alle selektierten Modelle und die aus diesen Modellen

referenzierten Modelle in die Dokumentation überführt. Durch Anklicken des Buttons

"Referenzen" können die Einstellungen hierzu angepasst werden.

Bei der HTML-Generierung werden für die Referenzen zwischen den Modellen und Objekten

entsprechende Links in den HTML-Seiten erzeugt, so dass eine einfache Navigation zwischen

den einzelnen Dokumenten möglich ist.


Abbildung 79: Dokumentation und Veröffentlichung im Intranet

Multiperspektivische Evaluation 206

6 Multiperspektivische Evaluation

Nachdem im vorherigen Kapitel die prototypische Realisierung des in Kapitel 4 präsentierten

Ansatzes zur Modellierung der Unternehmensarchitektur beschrieben wurde, gilt es nun, den

Ansatz im Hinblick auf seine Zweckmässigkeit, Vollständigkeit und Konsistenz zu überprü-

fen.

Da jede bisher in der Wirtschaftsinformatik verwendete Evaluierungsmethode bestimmte

Stärken und Limitationen aufweist sowie auf unterschiedlichen Prämissen und Vorstellungen

beruht, sollten Artefakte der Wirtschaftsinformatik-Forschung (z.B. Referenzmodelle, Meta-

modelle und Modelle) aus unterschiedlichen Perspektiven evaluiert werden.641 FETTKE/LOOS

schlagen hierfür einen Bezugsrahmen vor, der nach empirischen, deskriptiven, eigendis-

ziplinären und fremddisziplinären Perspektiven unterscheidet (vgl. Abbildung 80).

Abbildung 80: Multiperspektivische Evaluation642

641 Vgl. Fettke/Loos (2004a), S. 1.

642 Vgl. Fettke/Loos (2003), S. 2946.


Dieser Bezugsrahmen bezieht sich zwar auf die Evaluierung von Referenzmodellen, kann

aber auch für die Evaluierung anderer Artefakte, wie beispielsweise Methoden und Metamo-

delle, herangezogen werden. Zudem kann das in dieser Arbeit konstruierte Metamodell als

eine Art Referenz-Metamodell (Empfehlung) betrachtet werden, da es wesentliche Metaenti-

tätstypen für die Abbildung von Unternehmensarchitekturen beinhaltet und für den Einsatz in

einem unternehmensindividuellen Umfeld gegebenenfalls modifiziert werden muss.643

Im Folgenden wird der Versuch unternommen, zumindest ansatzweise eine multiperspektivi-

sche Evaluierung vorzunehmen. Die Evaluierung des in dieser Arbeit vorgestellten Ansatzes

sowie dessen Metamodells erfolgt primär anhand einer Fallstudie (empirische Perspektive)

sowie anhand von vordefinierten Kriterien (deskriptive Perspektive). Darüber hinaus wird

versucht, die Metaentitätstypen und deren Beziehungen mit den Metamodellelementen der in

Kapitel 3 betrachteten Ansätze zu vergleichen, um mögliche Lücken oder Redundanzen zu

identifizieren (eigendisziplinäre Perspektive). Auf die Evaluierung aus Sicht einer fremddis-

ziplinären Perspektive wird in dieser Arbeit verzichtet.

Die Abbildung des Metamodells in einem Metamodellierungswerkzeug hat bereits gezeigt,

dass dessen Elemente und Beziehungen ausreichend formal spezifiziert und konsistent sind.

Der daraus entstandene Software-Prototyp wurde anschliessend anhand einer Fallstudie getes-

tet. Die Zielstellung einer Fallstudie ist im Allgemeinen, eine konkrete Modellierungssituation

in einer Organisation bzw. einem Unternehmen zu einem bestimmten Zeitpunkt zu erfassen

und zu dokumentieren.644 Dabei wird eine bestimmte Problemstellung der (Referenz-)Model-

lierung praktisch gelöst. Der Inhalt der Fallstudie ist die umfassende Dokumentation der

Problemstellung, des Lösungswegs sowie der resultierenden Ergebnisse. Die Fallstudie dieser

Arbeit soll zudem zeigen, dass der Ansatz dieser Arbeit in der Praxis gegebene Sachverhalte

widerspiegelt, existierende Probleme adressiert und somit Praxisrelevanz besitzt.

Die Ergebnisse von Fallstudien sind zwar nicht objektiv nachvollziehbar und nur bedingt ge-

neralisierbar, da der betrachtete Anwendungsfall meist nicht repräsentativ ist und die Ergeb-

nisse der subjektiven Interpretation des einzelnen Forschers unterliegen.645 Trotz dieser

Nachteile ermöglicht die Evaluierung mittels Fallstudien aber die Gewinnung einer Vielzahl

verschiedener subjektiver Eindrücke und Informationen. So ist es beispielsweise möglich,

643 Die Anwendung eines Referenzmodells, einer Methode oder eines Metamodells erfolgt im Anschluss an

den Konstruktionsprozess im jeweiligen unternehmensspezifischen Kontext. Sie umfasst die Modifikationen aufgrund unternehmensspezifischer Anforderungen, die durch manuelle Modifikationen durch den Anwender vorgenommen werden. Vgl. Schütte (1998), S. 318 und Wortmann (2005), S. 100. Vgl. hierzu auch Abschnitt 2.2.2.




bestimmte Modellierungskonzepte im Hinblick auf ihre Konsistenz zu untersuchen bzw. ihre

Realisierbarkeit und Nützlichkeit zu demonstrieren.646

Die Dokumentation der Fallstudie orientiert sich in dieser Arbeit an der Methode Promet Bu-

siness Engineering Case Studies (BECS). Die wesentlichen Bestandteile einer Fallstudie sind

demnach:647

• Unternehmen: allgemeine Eckdaten des betrachteten Unternehmens,

• Ausgangssituation und Problemstellung: Beschreibung der bisherigen Lösung/des bisheri-

gen Vorgehens der generellen Problemstellung sowie der daraus resultierende Leidens-

druck,

• Projekt und neue Lösung: Beschreibung des Projekts (Vorgehen, Ziele usw.) sowie der

wesentlichen Ergebnisse,

• Einordnung in den Kontext und Fazit: Beschreibung, in welchem Kontext die Fallstudie in

Bezug auf den in dieser Arbeit präsentierten Ansatz steht.

Die Informationen zu der Fallstudie basieren primär auf Interviews mit Architektur-

Verantwortlichen des betrachteten Unternehmens (vgl. Anhang C) sowie zur Verfügung ge-

stellten Dokumenten.

Neben der Fallstudie wird eine metamodellbasierte Evaluierung vorgenommen. Dabei werden

die Metaentitätstypen und Beziehungen mit einem so genannten Master-Metamodell vergli-

chen. Eine derartige Analyse erlaubt die Überprüfung der Vollständigkeit und Redundanzfrei-

heit der verwendeten Konzepte sowie die Identifikation möglicher Spezialisierungen bzw.

Generalisierungen.648

Ergänzend zu den beiden zuvor genannten Evaluierungsmethoden erfolgt eine natürlich-

sprachliche und merkmalbasierte Evaluierung des in dieser Arbeit präsentierten Metamodells.

Bei einer natürlichsprachlichen Evaluierung werden die Charakteristika, Stärken und Schwä-

chen eines Modells ermittelt und ausschliesslich verbal beschrieben.649 Die Evaluierung kann

mehr oder weniger strukturiert erfolgen. Diese Art der Evaluierung ist ebenfalls stark subjek-

tiv geprägt, es können dadurch aber spezielle qualitative Aspekte leichter zum Ausdruck ge-

bracht werden. Eine merkmalsbasierte Evaluierung definiert zudem eine Menge von Merkma-

len, anhand derer Modelle charakterisiert werden können. Die verwendeten Evaluierungs-

merkmale werden nicht theoretisch abgeleitet, sondern ad hoc eingeführt.650 Da bisher keine

646 Für die Anwendung von Fallstudien zur Evaluation von Methoden und entsprechenden Werkzeugen vgl.

z.B. auch Kitchenham et al. (1995). 647

Vgl. Senger/Österle (2004). 648

Vgl. hierzu Fettke/Loos (2004a), S. 10-11. 649

Vgl. Fettke/Loos (2004a), S. 7. 650

Vgl. Fettke/Loos (2004a), S. 8.


allgemeingültigen Merkmale vorhanden sind, wird auf die in Abschnitt 2.6 genannten Krite-

rien zurückgegriffen. Da diese auf Basis der genannten Ziele und treibenden Kräfte der Un-

ternehmensarchitektur hergeleitet wurden, sollte deren Bedeutung weitgehend nachvollzieh-

bar sein.

6.1 Fallstudie bei der Winterthur Group

Die Winterthur verfügt über langjährige Erfahrungen bei der Entwicklung und der Pflege von

Architekturen in unterschiedlichen Bereichen, wie beispielsweise Informationssystem-, Pro-

zess- und Sicherheitsarchitekturen. Diese Fallstudie untersucht das von der Winterthur entwi-

ckelte Metamodell für die Abbildung der Unternehmensarchitektur. Dabei wird zunächst das

Unternehmen anhand einiger Eckdaten charakterisiert. Anschliessend wird darauf eingegan-

gen, welche Ausgangssituation bzw. Problemstellung die Winterthur dazu veranlasst hat, ein

Metamodell zu entwickeln, und welchen Nutzen und Zweck sie sich dadurch erwartet. Dar-

aufhin wird das Metamodell der WGR überblicksartig beschrieben und mit dem Metamodell

des in dieser Arbeit präsentierten Ansatzes verglichen. Dabei werden die Metaentitätstypen

der beiden Metamodelle einander gegenübergestellt und zugeordnet, um Übereinstimmungen

sowie mögliche Redundanzen oder Lücken zu identifizieren. Ausserdem wird anhand eines

Pilot-Projektes gezeigt, wie die Informationen über die Unternehmensarchitektur der Winter-

thur mit Hilfe des in dieser Arbeit entwickelten Prototyps erfasst und analysiert werden kön-

nen. Zuletzt folgt eine kurze Zusammenfassung der Ergebnisse dieser Fallstudie.

6.1.1 Allgemeine Informationen zur Winterthur Group

Die Winterthur Group (WGR) ist eine Schweizer Versicherungsgesellschaft mit Hauptsitz in

Winterthur.651 Das Angebot der international tätigen Gruppe umfasst eine breite Palette von

Personen-, Sach- und Haftpflichtversicherungslösungen sowie Lebensversicherungs- und

Pensionskassenlösungen für Privat- und Unternehmenskunden. Rund 19000 Mitarbeiterinnen

und Mitarbeiter arbeiten weltweit bei der Winterthur Group, davon sind über 70% ausserhalb

der Schweiz beschäftigt.

Die Winterthur Group gliedert sich in die zwei Segmente Life & Pensions und Non-Life. Das

Segment Life & Pensions bietet Versicherungsprodukte für Firmenkunden sowie Lebensver-

sicherungs- und Rentenprodukte für Privatkunden an. Das Segment Non-Life deckt die Versi-

cherungsbedürfnisse von Privaten sowie kleineren und mittleren Unternehmen ab. Es bietet

eine umfangreiche Palette von Versicherungsprodukten wie Motorfahrzeug-, Feuer-, Sach-

und allgemeine Haftpflichtversicherung sowie Unfall- und Krankenversicherungslösungen an.

In den beiden Segmenten Life & Pensions und Non-Life setzt die Winterthur Group je nach

Markt Agenten, Broker, Banken oder Direktvertriebskanäle ein.

651 Vgl. im Folgenden Winterthur (2005).


Die Winterthur Group ist in die vier regionalen Einheiten Schweiz, Deutschland, Market

Group 1 und Market Group 2 aufgeteilt. Die Market Group 1 umfasst Grossbritannien, Spa-

nien, Belgien, Tschechische Republik, Polen, Ungarn und die Slowakische Republik. Die

Market Group 2 umfasst die USA, Japan, Hong Kong, Niederlande, Kanada, Taiwan und In-

donesien.

Seit 1997 ist die Winterthur Group eine hundertprozentige Tochtergesellschaft der Credit

Suisse Group. Ende 2004 hat sich die Credit Suisse Group dafür entschieden, die Winterthur

Group auf den Börsengang vorzubereiten.

Die folgenden Ausführungen beziehen sich im Wesentlichen auf den IT-Bereich der Winter-

thur Schweiz. Dieser erbringt jedoch auch Dienstleistungen an die ausländischen Markteinhei-

ten.

WINTERTHUR GROUP (WGR)

Gründung

1875 Gründung der «Schweizerischen Unfallversicherungs Aktiengesell-schaft» in Winterthur. Im gleichen Jahr Expansion nach Deutschland, Elsass-Lothringen, Belgien, Niederlande, Österreich-Ungarn und Dänemark.

Firmensitz Winterthur, Schweiz

Branche Versicherungen

Geschäftsfelder Personen-, Sach- und Haftpflichtversicherungen, Lebensversicherungen und Pensionsvorsorge

Firmenstruktur Seit 1997 ist das Unternehmen ein Teil der Credit Suisse Group Regional gegliedert in die Gebiete Europa, Nordamerika und Asien

Homepage http://www.winterthur.com

Geschäftsvolumen 27.3 Mrd. CHF

Bruttoprämien 21.4 Mrd. CHF

Reingewinn 699 Mio. CHF

Mitarbeiter 19020

Kunden Privat- und Firmenkunden

Tabelle 23: Fakten zur Winterthur Group652

6.1.2 Ausgangssituation und Problembeschreibung

Die IT-Organisation und Applikationslandschaft der WGR sind durch die langjährige Selb-

ständigkeit der einzelnen Unternehmensbereiche sehr dezentral geprägt und weisen heute da-

her folgende Eigenschaften auf:653

• Die Applikationslandschaft der WGR umfasst eine Vielzahl heterogener Applikationen,

die in der Vergangenheit grösstenteils selbst entwickelt wurden. Die heutigen Architek-

652 Vgl. Winterthur (2005).

653 Vgl. hierzu auch Wortmann (2005), S. 65.


turprinzipien betonen dagegen vor allem den Einkauf von Applikationen. Der Entwick-

lungsprozess ist entsprechend darauf ausgerichtet und sieht einen Subprozess „Solution

Evaluation“ (SOP) vor. Gerade in den Bereichen Finanzen, Human Ressources und Asset

Management kommt in Zukunft Standardsoftware zum Einsatz.

• Die Applikationslandschaft weist eine hohe Komplexität auf. Eine Vielzahl unterschiedli-

cher Applikationen und verteilter, mehrschichtiger Softwaresysteme erschweren die Iden-

tifikation von Konfigurationsproblemen und von Abhängigkeiten zwischen einzelnen

Softwarekomponenten.

Im Rahmen einer Restrukturierung im Jahre 2003 wurde die stark dezentrale Organisation der

IT durch eine zentrale Entscheidungsfindung und -kontrolle abgelöst. Zentrale Einheiten wie

„Architektur“ oder „Engineering“ können nun Standards IT-übergreifend durchsetzen. Aus-

serdem wurden die IT-Prozesse mit der Einführung der IT Infrastructure Library (ITIL) klar

definiert und standardisiert. Im Bereich der Softwareentwicklung wird mit der Definition des

„Solution Evaluation Process“ (SOP) die Entwicklung und Überführung von Software in die

Produktion standardisiert. Das Projekt wurde im März 2006 erfolgreich abgeschlossen und

alle Betroffenen werden seitdem mit grossem Aufwand geschult. Wesentliche Treiber dieser

Entwicklungen waren vor allem regulatorische Anforderungen, wie beispielsweise der Sarba-

nes-Oxley Act.

Innerhalb der WGR werden jeden Tag im Rahmen der Durchführung verschiedenster IT-

Prozesse654 durch den IT-Bereich sowie teilweise durch die Fachbereiche Ergebnisse produ-

ziert und bearbeitet. Verteilt über das ganze Unternehmen geschieht dies oftmals unkoordi-

niert, das heisst einzelne Organisationseinheiten und Projekte pflegen oft individuelle Ver-

ständnisse, wie ihre Ergebnisse aufgebaut sind. Bestenfalls sind solche Ad-hoc-Verständnisse

dokumentiert (Glossar, Richtlinien, Templates etc.), oft befinden sie sich aber lediglich in den

Köpfen der Mitarbeiter. Dies kann lokal und zeitlich begrenzt gut funktionieren. Es liegt aber

auf der Hand, dass ein solcher Umgang mit dem im Unternehmen verfügbaren Know-how

höhere Kosten verursacht. Es können folgende Probleme im Unternehmen identifiziert wer-

den:

• Eine grosse Vielfalt von Ausprägungen ähnlicher Ergebnisse wird gepflegt.

• Diskussionen um dieselben Themen wiederholen sich laufend.

• Zusammenhänge zwischen Ergebnissen werden nicht erkannt.

• Inkonsistenzen und Redundanzen treten auf.

654 Mittlerweile ist der „Solution Evaluation Process“ (SOP) für den IT-Bereich verbindlich. Für die

Fachbereiche ist der Projekt Management Prozess, der Teil des SOP ist, verbindlich.


Um diesen offensichtlichen Mängeln in der IT entgegenzuwirken, ist es nach Meinung des IT-

Bereichs der WGR daher notwendig, alle Ergebnisse

• als Output von Prozessen zu definieren (Welche Ergebnisse werden produziert?),

• mit einer gemeinsamen Struktur als Basis abzubilden (Wie sehen die Ergebnisse aus?),

• in einem Repository, das nach dieser vorgegebenen Struktur konfiguriert worden ist, zu

speichern (Wo werden die Ergebnisse abgelegt?).

Die derart gesammelten Informationen beschreiben in ihrer Gesamtheit, wie das Unternehmen

aufgebaut ist und funktioniert. Sie beschreiben somit dessen Architektur. Die Struktur, welche

den gesammelten Informationen über das Unternehmen zugrunde liegt, soll durch das WGR

Enterprise Architecture Metamodel definiert (nachfolgend kurz Metamodell genannt) werden.

In Zukunft soll folglich für das Erfassen und Verwalten von Informationen über das Unter-

nehmen folgendes gelten:

• Das Metamodell dient als einzige Referenz, um die Strukturen für das Erfassen der Infor-

mationen festzulegen.

• Wenn das entsprechende Repository nicht verfügbar ist, kann das Verwalten der Informa-

tionen auch mit Dokumenten erfolgen. Dies sollte langfristig gesehen eine Überganglö-

sung sein, denn auf diese Weise gesammelte Informationen sind nicht im selben Masse im

Unternehmen integriert und verfügbar wie Informationen in einem Repository. Wichtig

ist, dass für solche Dokumente Vorlagen (Templates) verwendet werden, die vom Meta-

modell abgeleitet worden sind. So wird wenigstens die gemeinsame Syntax und Semantik

gewährleistet.

• Die Strukturen des Repository sowie der Dokumentenvorlagen (Templates) müssen mit

dem Metamodell übereinstimmen. Die Verantwortlichen für das Werkzeug und die Vorla-

gen haben also dafür zu sorgen, dass sie entweder einen vorhandenen Ausschnitt des Me-

tamodells für die entsprechende Konfiguration verwenden oder ihre Bedürfnisse mit den

Metamodell-Verantwortlichen absprechen, damit das Metamodell entsprechend erweitert

werden kann.

6.1.3 Ein zentral gepflegtes Metamodell als Lösungsansatz

Durch die Verwendung eines gemeinsamen Metamodells sowie eines entsprechenden Reposi-

torys soll in Zukunft die Beantwortung von Fragen der folgenden Art möglich sein:

• Welche Applikationen unterstützen welche Geschäftsfunktionen/Prozesse?

• Welche Rollendefinitionen gibt es?

• Welche Datenobjekte werden wo verwendet?


• Welche Prozesse funktionieren nicht mehr durchgängig, wenn eine Komponen-

te/Applikation ausfällt?

• Welche Softwarekomponenten sind davon betroffen, wenn ein Infrastrukturelement (z.B.

Server) ersetzt werden muss.

Zudem können Datenbestände aus verschiedenen nach dem gleichen Metamodell strukturier-

ten Repositorys einfacher zusammengeführt werden. Um eine professionelle IT zu betreiben,

ist es essenziell, solche Fragen zuverlässig und effizient beantworten zu können. Nur so kön-

nen die Informationen kontrolliert bewirtschaftet werden.

Aus der zuvor dargelegten Positionierung des Metamodells und des entsprechenden Reposito-

ry lässt sich deren Zweck ableiten. Das Metamodell soll die Strukturen der Fachbereiche so-

wie des IT-Bereichs übergreifend darstellen. Das Ziel ist die Erstellung einer zentralen, stan-

dardisierten und zusammenhängenden Sichtweise über das Unternehmen als Ganzes – zumin-

dest über jenen Teil der Fachbereiche, der mit der IT in direktem Zusammenhang steht, sowie

die IT selbst. Folglich werden die Elemente, welche die IT-Unterstützung der Fachbereiche

betreffen, systematisch erfasst, vereinheitlicht und zu einer konsistenten Einheit zusammenge-

führt.

Das Metamodell beschreibt demnach die aus Sicht der Fachbereiche und der IT relevanten

• Elemente, Beziehungen, Attribute,

• deren Semantik,

• Qualitätsmerkmale / Mindestanforderungen.

Des Weiteren sollen die IT-Prozesse zielgerichtet unterstützt werden. Das Metamodell reprä-

sentiert die statische Sicht auf die Elemente der Fachbereiche und der IT. Es dient als Basis,

um Repositorys zu strukturieren. Die derart strukturierten Repositorys werden durch Prozesse

verwaltet und genutzt. Über die gesamte WGR-IT-Prozesslandschaft sorgt ein zentrales Me-

tamodell somit für eine einheitliche, konsistente Pflege der IT-relevanten Daten.

Das Metamodell ist somit eine Basis für

• Qualitätssicherung und Konsistenz zwischen verschiedensten Initiativen,

• integriertes Denken und Handeln (in den verschiedensten Kontexten)

• und verteilte Unternehmens-Repositorys.

Das Metamodell dient als Kommunikationsmittel. Mit dem Metamodell als Bauplan können

Kontexte aufgezeigt werden (Wie hängen einzelne Metamodell-Elemente zusammen?), Land-

karten oder Repositorys positioniert werden (Prozesslandkarte, Subdomänen-Beschreibungen,

Service-Repository) sowie Checklisten, Templates und Strukturen für Repositorys abgeleitet

werden.


Das Metamodell ist folglich ein integraler Bestandteil der Unternehmensarchitektur und dient

dazu, eine gemeinsame Terminologie herbeizuführen und eine Basis für die Strukturierung

von Repositorys zu bilden.

6.1.4 Metamodell der Winterthur Group

Das Metamodell der WGR soll die Schlüsselelemente der Fachbereiche und des IT-Bereichs

sowie deren Beziehungen übergreifend darstellen.655 Die folgende Abbildung 81 gibt eine

Übersicht über die wesentlichen Elemente des Metamodells sowie deren Zusammenhänge.

Abbildung 81: Vereinfachtes Metamodell der Winterthur Group

Ein Geschäftsprozess kann in detailliertere Geschäftsprozesse aufgeteilt werden und wird

durch Geschäftsaktivitäten realisiert. Eine Geschäftsaktivität repräsentiert eine abgeschlosse-

ne Bearbeitungseinheit (logische Transaktion) und kann sowohl ausführend (operativ) als

auch führend (dispositiv) sein. Eine Geschäftsaktivität existiert nur im Kontext eines Ge-

schäftsprozesses. Sie enthält Geschäftsfunktionen als elementare Verarbeitungseinheiten. Eine

Geschäftsfunktion ist einer (Sub-)Domäne zugeordnet. Sie kann Funktionalitäten für mehrere

Geschäftsaktivitäten erfüllen (z.B. Partner suchen) und kann IT-unterstützt sein (durch Soft-

warekomponenten und Applikationen). Eine Applikation besteht aus mehreren Softwarekom-

ponenten und stellt selbst eine Softwarekomponente dar. Eine Softwarekomponente bietet

Services an (zur Unterstützung von Geschäftsfunktionen). Sie kann auf mehreren technischen

Plattformen installiert sein und ist als technische Komponente ein Bestandteil einer techni-

schen Plattform. Eine technische Komponente ist eine speziell für die Wiederverwendung

entwickelte Softwarekomponente, die technische (von der reinen Geschäftsfunktionalität los-

655 Vgl. im Folgenden Bernet (2005).


gelöste) Dienste implementiert. Eine technische Plattform besteht aus technischen Kompo-

nenten und den dazugehörenden Infrastrukturservices. Sie bietet eine technische Infrastruktur

(Hardware, Operating System Builds) mit den Services an, die benötigt werden, um die Soft-

warekomponenten lauffähig zu machen.

Das Metamodell ist in die Bereiche Business-Landkarte, System-Landkarte und Technologie-

Landkarte untergliedert. Abbildung 81 gibt einen Überblick über die Inhalte der einzelnen

Metamodell-Bereiche sowie bisher definierte thematische Metamodell-Sichten.

• Übersicht: Vereinfachte, selektive Sicht auf die Kernelemente des Metamodells im Kon-

text der Metamodell-Bereiche. Diese Sicht soll den wesentlichen Inhalt und Aufbau des

Metamodells auf einen Blick erkennbar machen.

Thematische Sichten

Prozesse

• Geschäftsprozess-Sicht • Aufbauorganisations-Sicht • Prozess-Rollen-Sicht • Servicevertrag-Sicht

Informationssysteme

• IT-Servicesicht • Applikationsportfolio-Sicht • Plattform-Sicht

Inhalt dient unter anderem zur Beschreibung von

Business-Landkarte

• Geschäftsprozessen • Geschäftsregeln • Geschäftsfunktionen • Organisationsstrukturen

System-Landkarte

• Business-Komponenten • Business-Applikationen • Applikationslandkarten • Datenelementen

Technologie-

Landkarte

• Technischen Komponenten • Technischen Applikationen • Laufzeitumgebungen des Betriebs • Technischen Applikationsplattformen

Abbildung 82: Sichten und Inhalte des Metamodells der WGR

• Übersicht – erweitert: Bereichsübergreifende Sicht der Kernelemente. Diese Sicht ent-

hält zwar nur die Kernelemente des Metamodells, ist aber schon zu komplex, um das Me-

tamodell auf einen Blick zu erfassen. Der Zweck dieser Sicht ist es, auf einem hohen Le-

vel eine detailliertere Sicht zu bieten.

• Thematische Detailsichten: Sichten, welche einen bestimmten Aspekt darstellen (z.B.

Geschäftsprozesse, Services, Aufbauorganisation, Domänen, Servicevertrag)


Da das Metamodell ein zentraler Bestandteil der Unternehmensarchitektur ist und, ebenso wie

die später darauf basierenden Modelle, als Kommunikationsmittel dienen soll, wird dessen

Dokumentation im Intranet veröffentlicht (vgl. Abbildung 83). Damit ist es für den IT-

Bereich und für die unterschiedlichen Fachbereiche an einem zentralen Ort zugänglich.

WGR Enterprise Architecture Metamodel

Einführungstext (gemäss Kap. 1 Management Summary )

Einführung (pdf, = Kap. 3 Einführung)

Einführung (ppt)

Was ist ein Metamodell? (Inhalt der bisherigen Seite)

Aufbau und Inhalt

(gemäss Kap. 1 Management Summary )

Gesamtübersicht

Elementbeschreibungen (pdf, = Kap. 7)

Sichten

(Tabelle gemäss Kap. 1 Management Summary )

Thematische Sichten

Erklärung Erklärung Erklärung Erklärung Erklärung Erklärung Erklärung

Erklärung Geschäftsprozess (Kap. 4, Subseite mit Grafik und PDF)

Domäne (= Kap. 5, Subseite mit Grafik und PDF)

Servicevertrag (= Kap. 6, Subseite mit Grafik und PDF)

BusinessBusiness--LandkarteLandkarte

Geschäfts-

prozess

Geschäfts-

prozess

0..n

1..n

0..n

0..n

Domäne &

Subdomäne

Domäne &

Subdomäne

0..n

Software-

Komponente

Software-

Komponente

ServiceService

0..n

ApplikationApplikation

0..n

0..n

1..n

1

Geschäfts-funktion

Geschäfts-funktion

0..n

0..n

Geschäfts-aktivität

Geschäfts-aktivität

1

SystemSystem--LandkarteLandkarte

(IS(IS--LandkarteLandkarte))TechnologieTechnologie--LandkarteLandkarte

(IT(IT--Landkarte)Landkarte)

Technische Applikations-

plattform

Technische Applikations-

plattform

Laufzeit-umgebungLaufzeit-

umgebung

1

0..n

0..n

0..1

0..n

• WGR Enterprise

Architecture

Metamodel (Ganze

Metamodell-Dolu als

pdf)

• Anhang

Prozessdenition in

SOP (ppt, Kap. 11.3)

Abbildung 83: Dokumentation des WGR-Metamodells im Intranet

6.1.5 Vergleich der Metamodelle

Die thematischen Sichten sowie die Inhalte der Bereiche Business-, System- und Technolo-

gie-Landkarte des WGR-Metamodells überschneiden sich grösstenteils mit den Sichten und

Inhalten der Ebenen „Organisationsebene“, „Applikationsebene“ und „Softwarekomponenten-

und Datenstrukturebene“ des in dieser Arbeit präsentierten Metamodells (vgl. dazu Abbildung

32). Im Vergleich zum Metamodell des in dieser Arbeit präsentierten Ansatzes definiert das

Metamodell der WGR keine Metaentitätstypen zur Abbildung der Geschäftsstrategie, wie

beispielsweise Geschäftsnetzwerkrollen, Unternehmensziele und Erfolgsfaktoren, Marktleis-

tungen, Kundengruppen etc. Auf der Organisationsebene bzw. im Bereich der Business-

Landkarte bieten beide Metamodelle weitestgehend die gleichen Sichten und Metaentitätsty-

pen. Dem Metamodell der WGR fehlen lediglich Elemente zur Beschreibung der Informati-

onslandkarte sowie der Prozessvision.

Im Folgenden werden die Metaentitätstypen der einzelnen Sichten des WGR-Metamodells

detaillierter betrachtet und den Metaentitätstypen des in dieser Arbeit definierten Metamodells


gegenübergestellt, um dadurch Übereinstimmungen sowie Redundanzen oder Lücken identi-

fizieren zu können.

Geschäftsprozess-Sicht

Die folgende Tabelle 24 zeigt einen Vergleich zwischen den wesentlichen Metaentitätstypen

der Geschäftsprozess-Sicht des WGR-Metamodells sowie korrespondierenden Metaentitäts-

typen des in dieser Arbeit vorgestellten Ansatzes (vgl. dazu die Metamodelle in Ab-

schnitt 4.2.2).

Korrespondierende Metaentitätstypen dieser Arbeit

Metaentitätstypen

Metamodell WGR/

Ansatz dieser Arbeit

Ak

tiv

ität

Ap

pli

ka

tio

nsd

om

än

e

Ere

ign

is

Erf

olg

sfa

kto

r

Fü

hru

ng

spro

zess

Ges

chä

ftsf

un

kti

on

Ges

chä

ftso

bje

kt

Ken

nza

hl

Lei

stu

ng

spro

zess

OE

des

PM

Pro

zess

Pro

zess

leis

tun

g

Pro

zess

roll

e

Tec

hn

. R

oll

entr

äg

er

Un

ters

tütz

un

gsp

roze

ss

(Sub-)Domäne X

Erfolgsfaktor X

Geschäftsaktivität X

Geschäftsereignis X

Geschäftsfunktion X

Geschäftsobjekt X

Geschäftsprozess X

Kerngeschäftsprozess X

KPI X

Owner X

Prozessleistung X

Prozessrolle X

Sachmittel X

Steuernder GP X Met

aen

titä

tsty

pen

der

G

esch

äft

spro

zess

-Sic

ht

Unterstützender GP X

Tabelle 24: Vergleich Metaentitätstypen Ablauforganisation

Daraus ist ersichtlich, dass sich jeder Metaentitätstyp der Geschäftsprozess-Sicht des WGR-

Metamodells auf einen Metaentitätstyp des Metamodells dieser Arbeit abbilden lässt. Auch

die Beziehungstypen zwischen den einzelnen Metaentitätstypen sind weitgehend deckungs-

gleich oder lassen sich indirekt über mehrere Beziehungstypen herstellen. So existiert bei-

spielsweise im Metamodell dieser Arbeit kein Beziehungstyp „ist zugeordnet“ zwischen den

Metaentitätstypen „Geschäftsobjekt“ und „Domäne“. Entsprechend dem Metamodell dieser

Arbeit korrespondiert aber jedes Geschäftsobjekt mit einem Informationsobjekt, welches von

einer Applikation verwaltet wird, welche wiederum einer bestimmten Domäne zugeordnet ist

(vgl. Abbildung 64). Somit ist letztlich auch das Geschäftsobjekt einer Domäne zugeordnet.


Aufbauorganisations-Sicht

Tabelle 25 zeigt die wesentlichen Metaentitätstypen der Aufbauorganisations-Sicht sowie

korrespondierende Metaentitätstypen des Metamodells dieser Arbeit. Auch hier stimmen die

Metaentitätstypen der beiden Metamodelle fast vollständig überein (vgl. hierzu auch

Abbildung 42). Die Beziehungstypen sind ebenfalls direkt oder indirekt in beiden Metamodel-

len vorhanden. Die Verbindung zwischen Aufbau- und Ablauforganisation wird in beiden

Metamodellen über den Metaentitätstyp „Prozessrolle“ hergestellt.

Organisationsebene

Metaentitätstypen

Metamodell WGR/


Org

an

isa

tio

nse

inh

eit

Org

. R

oll

entr

äg

er

Qu

ali

fik

ati

on

Per

son

Pri

mä

re O

E

Pro

zess

roll

e

Ro

llen

trä

ger

Sek

un

dä

re O

E

Sta

nd

ort

Ste

lle

Ste

llen

typ

Tec

hn

. R

oll

entr

äg

er

Organisationseinheit X

Org. Rollenträger X

Person X

Primäre OE X

Prozessrolle X

Rollenträger X

Sekundäre OE X

Skill X

Standort X

Stelle X

Stellentyp X

Au

fba

uo

rgan

isa

tio

ns-

Sic

ht

Techn. Rollenträger X

Tabelle 25: Vergleich Metaentitätstypen Aufbauorganisation

IT-Service- und IT-Servicevertrag-Sicht

Korrespondierende Metamodellelemente der IT-Servicesicht sind im Metamodell dieser Ar-

beit nicht enthalten. Dies ist darauf zurückzuführen, dass die Gestaltung der Informationssys-

temebene, entsprechend dem in dieser Arbeit vorgeschlagenen Ansatz, sich nach der optima-

len Strukturierung von Applikationen richtet.

Die Bewirtschaftung der Applikationslandschaft in einem langfristigen Sinne steht bei Stan-

dards, die eine serviceorientierte Perspektive verfolgen, wie beispielsweise ITIL, eher im Hin-

tergrund. Fraglich ist deshalb, welche Ansatzpunkte solche Standards bieten, um auch den

langfristigen Betrieb zu unterstützen.656 Die Definition der IT-Service- und IT-Servicevertrag-

Sicht hat sich zum Zeitpunkt dieser Fallstudie auch bei der WGR noch in einer Konsolidie-

rungsphase befunden. Deshalb wurden diese Sichten nicht in das Metamodell dieser Arbeit

656 Vgl. Schelp et al. (2004).


integriert und im Prototyp abgebildet. Da aber in der Praxis in letzter Zeit verstärkt Konzepte

zum Einsatz kommen, welche die Serviceorientierung betonen und mit ITIL ein De-facto-

Standard zur Verfügung steht, der eine serviceorientierte Perspektive verfolgt, wurde in Ab-

schnitt 4.4 darauf eingegangen, wie sich eine solche Perspektive in das hier präsentierte Me-

tamodell integrieren lässt.

Application Portfolio und Technical Platform View

Die Informationssystemebene als die der Organisationsebene logisch nachfolgende Gestal-

tungsebene wird in dieser Arbeit in die zwei Unterebenen „Applikationsebene“ sowie „Soft-

warekomponenten und Datenstrukturen“ unterschieden. Die Metaentitätstypen dieser beiden

Ebenen stimmen weitgehend mit den Metaentitätstypen der im WGR-Metamodell definierten

Sichten „Application Portfolio“ und „Technical Platform View“ überein (vgl. hierzu die fol-

gende Tabelle 26 und Abschnitt 4.3.2).

Applikationen/Softwarekomponenten

Metaentitätstypen

Metamodell WGR/


Ap

pli

ka

tio

n

Bet

rieb

sko

mp

on

ente

En

twic

klu

ng

stec

hn

olo

gie

Infr

ast

ruk

ture

lem

ent

Pla

ttfo

rm

Sch

nit

tste

lle

So

ftw

are

kom

po

nen

te

Application X

Application Platform X

Business Component X

Development Environment X

Runtime Environment X

Software Component X

Technical Component X Ap

pli

cati

on

Po

rtfo

lio

Technical Platform X

Tabelle 26: Vergleich Metaentitätstypen Softwarekomponenten

Auf der Ebene der Softwarekomponenten differenziert das WGR-Metamodell zwischen ver-

schiedenen Softwarekomponenten und Plattformen. Der Metaentitätstyp „Softwarekomponen-

te“ wird weiter in die Metaentitätstypen „Geschäftskomponente“ und „technische Komponen-

te“ spezialisiert. Eine Geschäftskomponente wird als eine Softwarekomponente definiert, die

geschäftsbezogene SOA-Services (Service Oriented Architecture) anbietet. Eine technische

Komponente stellt dagegen eine speziell für die Wiederverwendung entwickelte Software-

komponente dar, die technische (von der reinen Geschäftsfunktionalität losgelöste) Dienste

implementiert. Zusätzlich werden Applikations- und technische Plattformen unterschieden.

Eine technische Plattform bietet eine technische Infrastruktur (Hardware, Operating System


Builds) mit den Services an, die benötigt werden, um die Softwarekomponenten einer Appli-

kations-Plattform lauffähig zu machen.

Da es sich bei den zusätzlichen Metaentitätstypen lediglich um Spezialisierungen handelt,

können diese durch das Vererbungskonzept in das Metamodell dieser Arbeit einfach integriert

und im Prototyp abgebildet werden.

6.1.6 Abbildung mit Hilfe des Prototyps

Im Rahmen eines Pilotprojektes wurde der Prototyp zur Abbildung der

Unternehmensstrukturen in der zentralen Architekturabteilung der WGR eingesetzt. Wie der

vorhergehende Vergleich der Metamodelle gezeigt hat, existieren im Metamodell des in die-

ser Arbeit präsentierten Ansatzes bereits Metaentitäts- und Beziehungstypen, die weitestge-

hend mit den Metaentitäts- und Beziehungstypen des von der WGR erarbeiteten Metamodells

korrespondieren. Es waren daher für den Einsatz des Prototyps bei der WGR nur geringe An-

passungen oder Erweiterungen notwendig. Überwiegend handelt es sich dabei um Attribute,

die bestimmten Metaentitätstypen hinzugefügt werden mussten. Um bestimmte Fragestellun-

gen beantworten zu können, mussten zudem spezielle Analyseabfragen und Beziehungstabel-

len definiert werden. Zusätzlich zu den Informationen auf Organisations- und Informations-

systemebene, die auch im Metamodell der WGR definiert sind, wurden Informationen über

die Geschäftsstrategie entsprechend dem in dieser Arbeit definierten Metamodell erhoben und

mit den Modellen auf Organisationsebene in Beziehung gesetzt. In diesem Abschnitt werden

exemplarisch einige Modelle vorgestellt, die mit Hilfe des Prototyps abgebildet wurden und

Teile der Unternehmensarchitektur der WGR repräsentieren.

Geschäftsnetzwerk

Das Geschäftsnetzwerk bildet das Zusammenwirken von Unternehmen bzw. Geschäftseinhei-

ten zur gemeinsamen Abdeckung eines bestimmten Kundenprozesses ab. Dabei wird jedem

Unternehmen bzw. jeder Geschäftseinheit eine bestimmte Rolle zugeordnet und deren Leis-

tungsbeziehungen spezifiziert. Abbildung 84 zeigt exemplarisch einen Ausschnitt des Ge-

schäftsnetzwerks, in dem die WGR die Rolle eines Exclusive Service Provider (ESP) ein-

nimmt.657 In diesem Geschäftsnetzwerk produziert die WGR die Leistung „Auto versichern“

für den Service Integrator „AutoScout24“. Dieser unterstützt ganzheitlich den Kundenprozess

„Auto kaufen“, indem er Leistungen von unterschiedlichen Service Providern integriert. Die

WGR trägt folglich mit ihrer Leistung dazu bei, dass ein Teil dieses Kundenprozesses abge-

deckt werden kann. Ausserdem bietet die WGR ihre Leistung nicht nur über die Plattform von

AutoScout24 an, sondern auch dem Endkunden direkt über unterschiedliche Vertriebskanäle

(z.B. Internet, Telefon etc.).

657 Es können weitere Geschäftsnetzwerke identifiziert werden, in denen die WGR eine andere Rolle

wahrnimmt oder mit anderen Geschäftspartnern in Beziehung steht und andere Kundenprozesse abgedeckt werden.


AutoScout24 ist ein elektronischer Marktplatz für Neu- und Gebrauchtwagen in der Schweiz.

Auf der Internetseite des Marktplatzes sind gegenwärtig rund 93'000 Angebote online verfüg-

bar. Darüber hinaus bietet AutoScout24 Informationen und Links zu Themen rund um das

Auto und Unterstützung beim Autokauf an, wie beispielsweise Autobewertung, Finanzierung,

Versicherung etc. AutoScout24 hat somit die Rolle eines Service Integrator und unterstützt

den Kundenprozess des Autokaufs ganzheitlich.

Abbildung 84: Geschäftsnetzwerk

Die WGR bietet auf der Plattform von AutoScout24 ihre KFZ-Versicherung und ihren KFZ-

Rechtsschutz an. Andere Kooperationen hat AutoScout24 beispielsweise mit der GE Money

Bank für die Finanzierung und das Leasing, mit Eurotax für die Autobewertung sowie mit

Geschäftsnetzwerk

Kundenprozess Aufbauorganisation


Gate 24 für die Suche in Kleinanzeigen. Der KFZ-Rechtsschutz ist eine Leistung der Winter-

thur-ARAG, einer selbständigen und unabhängigen Tochterfirma der Winterthur. Sie entstand

1998 durch den Zusammenschluss des deutschen Rechtsschutzversicherers ARAG (Schweiz)

und der Winterthur-Rechtsschutz. Der Vertrieb der Rechtsschutzversicherungen erfolgt so-

wohl über die Verkaufsorganisation der Winterthur als auch über sieben regionale Geschäfts-

stellen der Winterthur-ARAG.

Ausgehend vom Geschäftsnetzwerkmodell können weitere Modelle referenziert werden. Der

Teil des Kundenprozesses, der aus Sicht der WGR relevant ist, wird in einem eigenen Kun-

denprozessmodell detaillierter spezifiziert, in dem die einzelnen Aktivitäten des Kunden so-

wie die entsprechenden Serviceaktivitäten der WGR festgelegt werden. Des Weiteren verwei-

sen die Rollen im Geschäftsnetzwerk auf Organisationseinheiten in der Aufbauorganisation,

sofern diese vom Unternehmen selbst (Winterthur Group) bzw. von Geschäftseinheiten des

eigenen Unternehmens (Geschäftseinheit „Motor“) wahrgenommen werden.

Kundenprozess

Abbildung 85 zeigt den Teil des Kundenprozesses „KFZ-Versicherung abschliessen“, der aus

Sicht der Winterthur relevant ist, sowie die von der WGR für die Unterstützung der Kunden-

aktivitäten durchzuführenden Serviceaktivitäten. Das Kundenprozessmodell veranschaulicht

einerseits, welche Ziele der Prozess beim Kunden verfolgt und wie der Prozess beim Kunden

abläuft. Auf der anderen Seite veranschaulicht es, wie der Prozess im eigenen Unternehmen

am Kundenbedarf ausgerichtet werden kann.

Die Kontaktanbahnung findet in diesem Fall über den elektronischen Marktplatz von Auto-

Scout24 statt. Nachdem der Kunde dort auf das Angebot der WGR gestossen ist, wird er sich

zunächst auf der Internetseite der WGR Informationen über das Unternehmen und allgemeine

Informationen zum Angebot besorgen. Nach der Kontaktanbahnung folgt die Evaluationsun-

terstützung und Erstberatung. Der Kunde wird in der Regel eine detailliertere Leistungsbe-

schreibung anfordern, das Berechnungstool verwenden, eventuell einen Berater suchen und

per Telefon oder E-Mail kontaktieren. Möchte der Kunde daraufhin einen Vertrag abschlies-

sen, muss ein entsprechendes Angebot erstellt, der Antrag verarbeitet und der Vertrag abge-

schlossen werden. Der Kundenprozess und damit die Beziehung zum Kunden ist aber mit

dem Vertragsabschluss nicht beendet. Während der Vertragslaufzeit ist eine laufende Betreu-

ung des Kunden durch die Verwaltung seiner Daten, Detailberatungen, das Zur-Verfügung-

Stellen spezieller Unterlagen und die Entgegennahme von Beschwerden durchzuführen. Tritt

der Schadenfall ein, muss die Schadenmeldung entgegengenommen und bearbeitet werden.

Bei der Vertragsbeendigung wird die Kündigung entgegengenommen und der Vertrag been-

det. Der Kundenprozess und damit die Beziehung zum Kunden endet somit aus Sicht der

WGR, und es sind keine weiteren Serviceaktivitäten mehr notwendig.

Das Kundenprozessmodell enthält zwei wesentliche Arten von Referenzen. Zum einen muss

jeder Serviceaktivität eine für deren Durchführung verantwortliche Organisationseinheit zu-


geordnet werden. Dabei kann es sich um interne sowie externe Einheiten handeln. Damit ist

im Kundenprozessmodell ersichtlich, welche Serviceaktivitäten selbst (von der Winterthur

bzw. einer ihrer Geschäftseinheiten) und welche von Partnern durchgeführt werden. Die Ser-

viceaktivitäten „Schadenfall entgegennehmen“ und „Schadenfall bearbeiten“ werden bei-

spielsweise von der Organisationseinheit „Claims Management“ verantwortet. Zum anderen

wird jeder Serviceaktivität ein entsprechender zugrunde liegender Geschäftsprozess der Pro-

zesslandkarte auf Organisationsebene zugeordnet. Der Serviceaktivität „Schadenmeldung

bearbeiten“ liegt in diesem Fall der Geschäftsprozess „Schadenbearbeitung“ der Prozessland-

karte „Schaden“ zugrunde.

Abbildung 85: Kundenprozessmodell

Aufbauorganisation

Prozesslandkarte

Kundenprozess


Prozesslandkarte

Abbildung 86 zeigt die Abbildung der WGR Prozesslandkarte mit Level-1-Geschäfts-

prozessen in dem entwickelten Prototyp. Die Geschäftsprozesse werden gruppiert nach Steu-

erungs-, Leistungs- und Unterstützungsprozessen dargestellt.658

Abbildung 86: Prozesslandkarte der WGR

Zusätzlich sind jedem Geschäftsprozess bestimmte Attribute und Referenzen auf Elemente in

anderen Modellen zugeordnet. So können einem Prozess beispielsweise Leistungen im Leis-

tungsmodell zugeordnet werden, die von diesem Prozess erzeugt werden, oder es kann eine

Organisationseinheit aus dem Aufbauorganisationsmodell referenziert werden, die für den

Prozess verantwortlich ist. Zudem kann ein Prozess auf eine weitere Prozesslandkarte oder

658 Seit April 2006 besitzt die Winterthur eine internationalweit gültige „Value Stream Landscape“. Der

Treiber dafür war Lean Sigma. Die Landkarte gruppiert die Prozesse neu in "Customer Relationship Processes" und "Business Enablers". Zum Zeitpunkt der Modellierung der Prozesslandkarte mit dem Prototyp war diese Landkarte noch nicht definiert, weshalb noch die Gruppierung nach Steuerungs-, Leistungs- und Unterstützungsprozessen abgebildet ist.

Prozesslandkarte (Level I) Prozesslandkarte (Level II)

Prozessablauf


auf einen detaillierten Prozessablauf verweisen. Innerhalb der Prozesslandkarte können zu-

sätzlich Leistungs- und Informationsbeziehungen zwischen den einzelnen Prozessen abgebil-

det werden.

In dem zuvor geschilderten Beispiel verweist die Serviceaktivität „Schadenmeldung bearbei-

ten“ auf den Prozess „Schadenbearbeitung“ in der Prozesslandkarte „Schaden“ (Level 2).

Durch Anklicken dieses Prozesses wird der detaillierte Prozessablauf dargestellt.

Prozessablauf

Abbildung 87 zeigt die Ablaufplanung der Schadenbearbeitung in vereinfachter Form. Der

Zweck dieses Prozesses (festgehalten in der Prozessvision) besteht unter anderem darin, alle

für die Bearbeitung notwendigen Informationen inklusive Beweissicherung zu beschaffen,

einen möglichen Versicherungsmissbrauch zu erkennen und zu beurteilen, die Entscheidung

über die Leistung sowie das Vorgehen an die Schadenbeteiligten zu kommunizieren, Leistun-

gen zu erbringen bzw. ungerechtfertigte Leistungen abzuwehren und den Schadenabschluss

mit allen notwendigen Abschlussarbeiten durchzuführen.

Der Prozess beginnt mit dem Abschluss der Schadenfalltriage659, welche ein entsprechendes

Ereignis auslöst und damit den Prozess der Schadenbearbeitung anstösst. Der für die Scha-

denbearbeitung verantwortliche Sachbearbeiter muss die benötigten Informationen mit Hilfe

der Applikation „Schaden Core“ beschaffen. Dabei handelt es sich um das Schadenverwal-

tungssystem für den Kernbereich der Schadenerledigung. Liegt der Verdacht eines Versiche-

rungsbetrugs vor, muss der Fall mit dem BMV-Spezialisten der Region besprochen werden.

Wird der Verdacht bestätigt, übernimmt der BMV-Spezialist die BMV-Verarbeitung unter

Verwendung des BMV-Systems, ein regelbasiertes System zur Bekämpfung von Versiche-

rungsbetrug. Anschliessend folgt die Prüfung des Anspruchs und der Haftung. Diese umfasst

sämtliche Aktivitäten der Fallbearbeitung, die zur Vorbereitung des Deckungs-

/Haftungsentscheides bzw. des Entscheides, ob eine Leistungspflicht besteht, notwendig sind.

Die Entscheide sind zu dokumentieren und stellen somit den Output dieser Aktivität dar. Sind

der Anspruch und die Haftung geprüft, wird im nächsten Schritt dem Anspruchsteller

und/oder Versicherungsnehmer der getroffene Deckungs-/Haftungsentscheid bzw. die „Leis-

tung“ in geeigneter Form kommuniziert (mündlich/schriftlich) und das weitere Vorgehen ver-

einbart. Hat dieser den Entscheid akzeptiert, werden die eingehenden Rechnungen durch den

Sachbearbeiter auf ihre Vereinbarkeit mit den getroffenen Vereinbarungen geprüft. Entspre-

chen die Rechnungen den Vereinbarungen, kann die Leistung an die/den Begünstigten ent-

richtet werden. Besteht keine Regresschance, kann der Schadenfall mit der Durchführung

aller notwendigen administrativen Abschlussarbeiten beendet werden.

659 Bei der Schadenfalltriage werden die eingehenden Schadenmeldungen nach Hauptbranchen sowie teilweise

auch nach Schadenbranchen vorsortiert.


Abbildung 87: Ablaufplanung Schadenbearbeitung

Das Modell der Ablaufplanung der Schadenbearbeitung enthält entsprechend dem zugrunde

liegenden Metamodell Referenzen auf Objekte in anderen Modellen. Jeder Aktivität der Ab-

laufplanung ist über die Prozessrolle ein für die Durchführung verantwortlicher Rollenträger

der Aufbauorganisation zugewiesen. So ist beispielsweise bei der Schadenbearbeitung die

Prozessrolle „BMV-Spezialist“ für die Durchführung der Aktivität „BMV-Verdacht“ zustän-

dig und in der Aufbauorganisation der Organisationseinheit „Claims Management“ zugeord-

net. Die informationstechnische Unterstützung der Durchführung einer Aktivität wird durch

eine Referenz auf die entsprechende Applikation in der Applikationsbestandsführung darge-

stellt. Das Schadenverwaltungssystem „Schaden Core“ wird für die meisten Aktivitäten der

Prozessablauf Applikationsbestandsführung

Geschäftsfunktionen/

Informationsobjekte

Aufbauorganisation


Schadenbearbeitung eingesetzt. In der Applikationsbestandsführung ist sie dementsprechend

der Applikationsdomäne „Schaden/Leistung bearbeiten“ zugeordnet. Weitere Referenzen be-

stehen zum Informationsobjekte- und Geschäftsfunktionenmodell. Die Aktivität „Anspruch

und Haftung prüfen“ produziert beispielsweise ein Informationsobjekt, das die Entscheide

dokumentiert. Dieses ist im Informationsobjektemodell abgebildet und wird dort referenziert.

Des Weiteren wird eine informationstechnisch unterstützte Aktivität von mehreren Geschäfts-

funktionen ausgeführt, die in Form von Applikationsfunktionen realisiert sind, welche wie-

derum Bestandteil der entsprechenden Applikation sind (vgl. Abbildung 46). Jeder Aktivität

der Ablaufplanung können daher mehrere Geschäftsfunktionen zugewiesen werden, die im

Geschäftsfunktionenmodell abgebildet sind. So wird die Aktivität „Informationen beschaffen“

unter anderem durch die Geschäftsfunktion „Suche Schadenbericht“ unterstützt, welche durch

die Applikationsfunktionen „Einfache Suche“, „Erweiterte Suche“ und „Anzeige der Sucher-

gebnisse“ der Applikation „Schaden Core“ realisiert wird.

Aufbauorganisation

Die folgende Abbildung 88 zeigt einen Ausschnitt der Aufbauorganisation der Winterthur, der

die für die Schadenbearbeitung relevanten Organisationseinheiten enthält. Das Modell der

Aufbauorganisation wird von allen Ebenen der Unternehmensarchitektur referenziert.

Abbildung 88: Aufbauorganisation

Die Modelle der Strategieebene verweisen lediglich auf das gesamte Unternehmen bzw. auf

Geschäftseinheiten (Winterthur Group, Geschäftseinheit „Motor“). Modelle der Organisati-

ons- und Informationssystemebene verweisen dagegen auf einzelne Organisationseinheiten,

Stellen und Personen. Der Geschäftseinheit „Motor“ ist beispielsweise die Rolle „Exclusive

Service Provider“ im Geschäftsnetzwerk zugeordnet. Die Prozessrolle „Sachbearbeiter Scha-


denbearbeitung“ steht in Beziehung mit einzelnen Aktivitäten der Ablaufplanung „Schaden-

bearbeitung“. Ferner ist auf Applikationsebene die Applikationsdomäne „Schaden/Leistung

bearbeiten“ der Organisationseinheit „Claims Management“ zugeordnet.

Geschäftsfunktionen- und Informationsobjektemodell

Die Erhebung der Informationsobjekte und Geschäftsfunktionen erfolgte anhand der Doku-

mentation der Prozessabläufe und der Organisationsstruktur. Abbildung 89 zeigt einen Aus-

schnitt der für den Prozessablauf der Schadenbearbeitung ermittelten Informationsobjekte und

Geschäftsfunktionen.

Abbildung 89: Geschäftsfunktionen- und Informationsobjektemodell

Analog zu den Applikationen sind auch die Geschäftsfunktionen und Informationsobjekte

bestimmten Domänen und Subdomänen zugeordnet. Für jede Geschäftsfunktion und jedes

Informationsobjekt sind die Erhebungsquelle sowie Homonyme und Synonyme dokumentiert.

Zudem können für jedes Informationsobjekt die entsprechenden Datenobjekte und analog für

jede Geschäftsfunktion die entsprechenden Applikationsfunktionen erfasst werden.

Applikationen

Die in Abbildung 90 dargestellten Applikationen und Domänen zeigen einen Teil des Ge-

samtbestandes aktuell bei der WGR existierender und geplanter Applikationen. Diese sind

entsprechenden Domänen und Subdomänen zugeordnet, die bestimmte Geschäftsprozesse

unterstützen. Es wird zwischen IST-Applikationen, die im SOLL-Zustand unverändert blei-

ben, SOLL-Applikationen, die neu zu entwickeln sind, und zu ersetzenden bzw. entsorgenden

Applikationen unterschieden. Daneben ist jede Applikation einer der drei Geschäftsbereiche

„Non-Life“, „Life&Pensions“ oder „Corporate Center“ zugeordnet. Jede Applikation besitzt


Referenzen auf die von ihr manipulierten Informationsobjekte, auf die von ihr realisierten

Geschäftsfunktionen sowie auf die entsprechenden Softwarekomponenten.

Abbildung 90: Applikationsbestandsführung

Softwarekomponenten und Plattformen

Die folgende Abbildung 91 zeigt exemplarisch einen Teil der Softwarekomponenten der Ap-

plikation „Claims Core“, die der Schadenbearbeitung dient.

Abbildung 91: Softwarekomponenten

Die Softwarekomponenten laufen auf einer J2EE-Plattform. Als Entwicklungstechnologien

kommen J2EE und Eclipse zum Einsatz. Für jede Softwarekomponente können entsprechend


dem Metamodell in Abbildung 49 die verwendete Entwicklungstechnologie, Betriebskompo-

nente und Plattform erfasst werden. Darüber hinaus lassen sich die Schnittstellen und die ver-

antwortliche Organisationseinheit dokumentieren.

Analyse der erstellten Modelle

Die erstellten Modelle der Unternehmensarchitektur gewinnen an Wert, wenn sie nicht nur als

gemeinsame Kommunikationsbasis dienen, sondern auch die strategische Entscheidungsfin-

dung durch modellbasierte Analysen unterstützen.660 Die modellbasierte Analyse spielt eine

zentrale Rolle, wenn es um Veränderungen an Elementen der Unternehmensarchitektur geht

und deren Auswirkungen auf andere Bereiche der Unternehmensarchitektur abgeschätzt bzw.

antizipiert werden müssen. Aufgrund der Komplexität der Unternehmensstrukturen kann die

Analyse der Modelle nicht mehr manuell erfolgen, sondern erfordert eine entsprechende

Werkzeugunterstützung in Form bestimmter Abfragen und Mechanismen.

Nach der Informationsaufnahme und der Erstellung der zuvor beschriebenen Modelle konn-

ten, darauf aufbauend, unterschiedliche Analysen definiert und durchgeführt werden. Dadurch

war die Beantwortung der in Abschnitt 7.2.3 genannten Fragen möglich. So lässt sich bei-

spielsweise die Frage beantworten, welche Geschäftsprozesse durch welche Applikationsdo-

mänen unterstützt werden, indem die entsprechenden Referenzen ausgewertet und die Objekte

in einer Beziehungsmatrix einander gegenübergestellt werden (vgl. Abbildung 92).

Abbildung 92: Beziehungstabellen (Applikationsdomäne zu Prozess)

Ebenso lässt sich die Frage beantworten, welche Prozessrollen es gibt und welche Aktivitäten

diese durchführen. Ob eine bestimmte Frage beantwortet werden kann, lässt sich sehr einfach

nachvollziehen, indem man die entsprechenden im Metamodell definierten Beziehungen be-

trachtet. Das Werkzeug ermöglicht sowohl die Auswertung von Beziehungen innerhalb eines

Modells, als auch solcher mit modellübergreifenden Referenzen. Dadurch können auch Ob-

jekte in einer Beziehungsmatrix einander gegenübergestellt werden, deren Metaentitätstypen

aus unterschiedlichen Ebenen und Sichten stammen. In dem Beispiel in Abbildung 92 sind

660 Vgl. Lankhorst (2005), S. 191.


dies Applikationsdomänen der Applikationsbestandsführung auf Applikationsebene, die Pro-

zessen der Prozesslandkarte auf Organisationsebene gegenübergestellt werden.

Neben den Beziehungstabellen lassen sich auch so genannte Impact-Analysen durchführen.

Grundlage dieser Analysen sind die im Metamodell definierten Beziehungen zwischen unter-

schiedlichen Modellen und Ebenen. Die Ausführung einer Impact-Analyse erfordert das

Durchlaufen unterschiedlicher Sichten und Ebenen der Unternehmensarchitektur und die

Auswertung der entsprechenden Beziehungen, um festzustellen, ob die Änderung eines Ob-

jektes sich über diese Beziehungen auf andere Objekte auswirkt. Dadurch können Auswir-

kungen von Änderungen an Elementen der Informationssystemebene (z.B. Ausfall eines Inf-

rastrukturelements) auf die Organisations- und Strategieebene vorhergesagt werden (Bottom-

Up). Umgekehrt lassen sich aber auch die Auswirkungen von Veränderungen an der Ge-

schäftsstrategie (z.B. Änderung des Kundenprozesses oder Einführung einer neuen Leistung)

auf die Organisations- und Informationssystemebene abschätzen.

Das folgende Beispiel illustriert, wie sich eine Änderung an einem Element auf die gesamte

Unternehmensarchitektur auswirken kann. Wenn beispielsweise ein Infrastrukturelement aus-

fällt, sind folglich auch die darauf installierten Plattformen und die auf den Plattformen lau-

fenden Softwarekomponenten nicht verfügbar. Davon sind bestimmte Applikationen betrof-

fen, die mit diesen Softwarekomponenten implementiert sind. Dies hat wiederum Auswirkun-

gen auf die Geschäftsprozesse, die von diesen Applikationen unterstützt werden. Die betrof-

fenen Geschäftsprozesse enthalten Serviceaktivitäten, die bestimmte Kundenaktivitäten und

damit Kundenprozesse unterstützen. Darüber hinaus produzieren diese Prozesse Leistungen,

die Teil bestimmter Marktleistungen sein können, die an den Kunden gehen. Folgende Bezie-

hungen werden für diese Impact-Analyse ausgewertet (vgl. Abbildung 93):

• Welche Plattformen sind auf dem ausgefallenen Server (Infrastrukturelement) installiert?

• Welche Softwarekomponenten laufen auf diesen Plattformen?

• Welche Applikationen werden mit diesen Softwarekomponenten implementiert?

• Zu welchen Applikationsdomänen gehören diese Applikationen, und welche Geschäfts-

prozesse werden durch diese Applikationsdomänen unterstützt?

• Welche Serviceaktivitäten werden in diesen Geschäftsprozessen durchgeführt, die wieder-

um welche Kundenaktivitäten und damit Kundenprozesse unterstützen?

• Welche Prozessleistungen produzieren diese Prozesse, die Teil bestimmter Marktleistun-

gen sind, die an den Kunden bzw. an Partner gehen?


Organisations-

ebene

Strategie-

ebene

System-

ebene

Applikationen

KomponentenSoftware-

komponente

ApplikationApplikations-

domäne

Prozess

Service-

aktivität

Kunden-

aktivität

Plattform

Prozess-

leistung

(End-)KundeKunden-

prozess

Marktleistung

Rolle

hat

ist Teil von

ist zugeordnet

unterstützt

erzeugt

unterstützt

ist Teil von

geht anunterstütztist Teil von

ist zugeordnet

Abbildung 93: Auswertung Metamodellbeziehungen

Die folgende Abbildung 94 zeigt exemplarisch das Ergebnis einer Impact-Analyse. Dieses

visualisiert die Auswirkungen des Ausfalls einer bestimmten Plattform auf unterschiedliche

Bereiche der Unternehmensarchitektur.


Inform

ationssystemebene

Org

anisationsebene

Strategieebene

Abbildung 94: Impact-Analyse (Szenario „Plattform fällt aus“)


6.1.7 Fazit

Folgende Erkenntnisse können aus der Fallstudie bei der Winterthur Group abgeleitet werden:

• Die in der Einführung sowie in Abschnitt 2.5 genannten Aspekte stellen ein in der Praxis

existierendes und relevantes Problem dar.

• Auch in der Praxis wird ein zentral entwickeltes und gepflegtes Metamodell der Unter-

nehmensstrukturen als Lösungsansatz für diese Problemstellung gesehen.

• Der Ansatz der vorliegenden Arbeit stellt für die Praxis relevante Metaentitäts- und Be-

ziehungstypen auf der Strategie-, Organisations- und Informationssystemebene zur Verfü-

gung.

• Die Modelle der Geschäftsstrategie bilden Sachverhalte in der Realität ab und können mit

den Modellen auf Organisationsebene in Beziehung gesetzt werden.

Anhand des Pilot-Projektes im Rahmen der Fallstudie konnten folgende Erkenntnisse gewon-

nen werden:

• Der entwickelte Ansatz und Prototyp kann mit geringfügigen, einfach durchführbaren

unternehmensspezifischen Anpassungen in der Praxis für die Abbildung der Unterneh-

mensstrukturen eingesetzt werden.

• Mit Hilfe des Werkzeuges können unterschiedliche Analysen auf den erstellten Modellen

durchgeführt und wichtige Abhängigkeiten erkannt sowie praxisrelevante Fragen beant-

wortet werden. Damit ist nicht nur eine Kommunikationsbasis geschaffen, sondern die

Auswirkungen von bestimmten Änderungen an der Unternehmensstruktur können von

den verantwortlichen Personen besser antizipiert werden.

• Das in dieser Arbeit präsentierte Metamodell und der entwickelte Prototyp stellen einen

Ansatz dar, der als Ausgangsbasis für andere Projekte in der Praxis verwendet werden

kann.

Insgesamt hat die Fallstudie die Anwendbarkeit und den praktischen Nutzen des Ansatzes

sowie des Werkzeuges für die Abbildung und Analyse komplexer Unternehmensstrukturen

deutlich gemacht.

Darüber hinaus hat die Fallstudie Anregungen und Ideen für mögliche Erweiterungen bzw.

die Integration weiterer Konzepte, wie beispielsweise ITIL und SOA, geliefert.


6.2 Metamodellbasierter Vergleich mit bestehenden Ansätzen

Eine metamodellbasierte Evaluierung untersucht und vergleicht die Metaentitätstypen und

Beziehungen anhand eines so genannten Master-Metamodells. Eine derartige Analyse erlaubt

die Überprüfung der Vollständigkeit und Redundanzfreiheit der verwendeten Konzepte sowie

die Identifikation möglicher Spezialisierungen bzw. Generalisierungen.661

Unter einem Master-Metamodell wird in dieser Arbeit analog zur Definition eines Master-

Referenzmodells in Anlehnung an ROSEMANN eine Komposition von verschiedenen Metamo-

dellen verstanden.662 Bei dieser Art der Evaluierung wird untersucht, ob das Metamodell des

in dieser Arbeit präsentierten Ansatzes die im Master-Metamodell repräsentierten Sachverhal-

te berücksichtigt. Grundproblem dieser Art der Evaluierung ist, dass zurzeit keine Master-

Metamodelle bekannt sind663 und die Definition eines solchen den Rahmen dieser Arbeit

sprengen würde. Deshalb wird die Komposition der Metamodelle der in Abschnitt 3.2 erläu-

terten verwandten Ansätze (ARIS, MEMO und SOM) als Master-Metamodell deklariert und

als Grundlage für die Evaluierung verwendet.

Wird ein Metaentitätstyp des Master-Metamodells, also von ARIS, MEMO oder SOM, durch

mehrere Metaentitätstypen dieses Ansatzes repräsentiert, so liegt das Problem der (ontologi-

schen) Redundanz vor. Wird dagegen ein Metaentitätstyp des Master-Metamodells durch kei-

nen entsprechenden Metaentitätstyp repräsentiert, so ist der Ansatz unvollständig.

Es ist zu vermuten, dass solche Defizite des zugrunde liegenden Metamodells sich auf die

Qualität der Abbildung von Sachverhalten in der Praxis und somit auf die Qualität von Mo-

dellen und Referenzmodellen auswirken, die basierend auf diesem Metamodell erstellt wur-

den. Sie sollten folglich durch eine Gegenüberstellung der Metaentitätstypen bzw. Konzepte

identifiziert und behoben werden.

6.2.1 Metamodellbasierter Vergleich mit ARIS

Die von ARIS häufig als Ebenen bezeichneten Phasen der Softwareentwicklung (Fachkon-

zept, DV-Konzept, Implementierung) lassen sich im Verständnis der vorliegenden Arbeit

nicht als Architekturebenen interpretieren, da sie die Sicht auf das Unternehmen zu stark auf

für die Softwareentwicklung relevante Sachverhalte eingrenzen. Dennoch können die wesent-

lichen Metaentitätstypen von ARIS den Architekturebenen des Ansatzes dieser Arbeit zuge-

ordnet werden.

Die folgende Tabelle 27 zeigt eine Gegenüberstellung der wesentlichen Metaentitätstypen des

Ansatzes der vorliegenden Arbeit mit den Metaentitätstypen bzw. Konzepten von ARIS. Dar-

661 Vgl. hierzu Fettke/Loos (2004a), S. 10-11.

662 Vgl. Rosemann (1995), S. 35.



in ist einerseits ersichtlich, dass das Metamodell dieser Arbeit in Bezug auf die Konzepte von

ARIS weitgehend vollständig ist. Andererseits ist zu erkennen, dass zwar zusätzliche Spezia-

lisierungen bzw. Generalisierungen von bestimmten Metaentitätstypen, aber keine redundan-

ten Metaentitätstypen vorhanden sind.

Organisationsebene Ansatz dieser

Arbeit ARIS

Applikation Anwendungssystem

Ereignis Ereignis

Aktivität

Funktion

manuelle Funktion

Systemfunktion

Informationsobjekt

Datenobjekt

Makrodatenobjekt

elektr.-alphanum. Datenobjekt

elektronisches Datenobjekt

konventionelles Datenobjekt

Operator Operator

Organisationseinheit

Primäre OE

Sekundäre OE


Organisationsstruktur

Organisationstyp

Rollenträger

Organisat. Rollenträger

Technischer Rollenträger

Primär menschl. Leistungsträ-

ger

Primär techn. Leistungsträger

Prozess Geschäftsprozess

Prozessleistung

Sachleistung/Dienstleistung

InfoDL/sonstige DL

Kostenart

Leistung (Produkt)

Sachleistung/Dienstleistung

InfoDL/sonstige DL

Kostenart

Lieferung

Prozessziel Ziel

Qualifikation Qualifikation

Prozessrolle

Benutzerkonto

Rolle

Benutzerklasse

Standort Standort

Stelle

Stellentyp Stelle

Tabelle 27: Metamodellbasierter Vergleich mit ARIS

So wird bei ARIS beispielsweise eine Funktion weiter nach manueller Funktion und System-

funktion differenziert. Zudem unterscheidet ARIS bei Leistungen zwischen Sach- und Dienst-

leistungen sowie weiter zwischen Informations- und sonstige Dienstleistung. Bei einem

Makrodatenobjekt, welches im Ansatz dieser Arbeit mit einem Informationsobjekt korrespon-

diert, kann es sich um ein elektronisch-alphanumerisches, elektronisches oder konventionelles

Datenobjekt handeln. Da es sich bei diesen Metaentitätstypen lediglich um Spezialisierungen

handelt, könnten diese bzw. entsprechende Metaentitätstypen durch Vererbung einfach in das

Metamodell des in dieser Arbeit präsentierten Ansatzes integriert werden.

Weitere Metaentitätstypen dieses Ansatzes, die in ARIS nicht enthalten sind, wurden aus

Gründen der Übersichtlichkeit nicht in die Tabelle aufgenommen.

Anzumerken ist, dass das strategische Geschäftsprozessmodell und das strategische Vor-

gangskettendiagramm von ARIS eher der Organisationsebene zuzuordnen sind. Das strategi-

Strategieebene Ansatz dieser

Arbeit ARIS

Erfolgsfaktor (BSC) Kritischer Erfolgsfaktor

Unternehmen

Geschäftseinheit Organisationssegment

Geschäftsnetzwerk Wertschöpfungskette

Geschäftsnetzwerk-Rolle Wertschöpfungsfunktion

Kundenprozess

Serviceprozess

Geschäftsprozess

Leistungsprozess


Funktionssegment

Geschäftsprozesssegment

Kernprozessvariante

Kernprozess


Kundengruppe Kundengruppe

Marktleistung

Leistungsspezifikation Leistungsfeld

Ziel (BSC) Unternehmensziel

Informationssystemebene Ansatz dieser

Arbeit ARIS


Informationsobjekt Makrodatenobjekt

Datenobjekt

Klasse

Mikrodatenobjekt

Entitytyp

Assoziation Beziehungstyp

Attribut Attribut


sche Geschäftsprozessmodell beschreibt Organisationssegmente und Geschäftsprozessseg-

mente, die später lediglich detailliert werden. Ebenso bildet das strategische Vorgangsketten-

diagramm den Prozessablauf in grober, aggregierter Form ab und wird später durch eine EPK

detailliert. Im Wertschöpfungskettendiagramm wird der Zusammenhang von Funktionen

(primäre Aktivitäten) der Unternehmung zur Leistungserstellung betrachtet. Daraus ergibt

sich eine grobe Prozessstruktur, die als Grundlage für die Prozessgestaltung dient. Somit die-

nen diese Modelle lediglich zur Identifikation und Vorstrukturierung der Geschäftsprozesse.

Andere strategische Aspekte können allerdings nicht abgebildet werden.

Die Metaentitätstypen zur Beschreibung der Ablaufplanung von Prozessen stimmen weitge-

hend überein, da das Metamodell der Ablaufplanung der vorliegenden Arbeit in Teilen auf der

EPK von ARIS basiert. Für die Abbildung der Datenstrukturen wird bei ARIS das ER-

Diagramm vorgeschlagen. Dessen zugrunde liegende Metaentitätstypen lassen sich in korres-

pondierende Metaentitätstypen des in dieser Arbeit verwendeten vereinfachten UML-

Klassendiagramms überführen.

6.2.2 Metamodellbasierter Vergleich mit MEMO

Das Metamodell von MEMO ist im Vergleich zu dem in dieser Arbeit dargestellten Ansatz

sehr abstrakt angesetzt. Daher ist eine Gegenüberstellung der einzelnen Metaentitätstypen der

beiden Ansätze nur teilweise möglich. Dennoch finden sich die wesentlichen Konzepte von

MEMO auch im Metamodell dieser Arbeit (vgl. Tabelle 28).

In Bezug auf MEMO ist das hier vorgestellte Metamodell somit ebenfalls vollständig. Dar-

über hinaus konnten auch keine wesentlichen Redundanzen identifiziert werden. Lediglich

der Metaentitätstyp „Ressource“, welcher Technologien, Personen und finanzielle Ressourcen

beschreibt, ist nicht auf Strategieebene im Ansatz dieser Arbeit vorhanden. Allerdings stellt

sich die Frage, ob Ressourcen überhaupt bei der Strategiegestaltung betrachtet werden sollten.

Diese sollten eher Teil der nachfolgenden Gestaltung der Organisationsstrukturen und Pro-

zessabläufe sein.

Auf Strategieebene verwendet MEMO analog zu ARIS das Konzept der Wertschöpfungsket-

te, welches eine Alternative zu den Konzepten des Geschäftsnetzwerks und des Kundenpro-

zesses darstellt und eine andere strategische Ausrichtung des Unternehmens definiert.

Im Wesentlichen wird dabei auf den Ansatz von PORTER zurückgegriffen, der im Bereich der

strategischen Unternehmensplanung eine erhebliche Bedeutung erlangt hat.664 Danach wird

ein Unternehmen als ein System von Aktivitätsgruppen dargestellt, die in ihrer Abfolge die

Wertkette bilden. Primäraktivitäten sind unmittelbar auf die Erstellung der Güter oder Leis-

tungen gerichtet, die den Kunden des Unternehmens angeboten werden. Eine Aktivität be-

664 Vgl. hierzu Porter (1999).


schreibt eine wesentliche Funktion, die in einem Unternehmen durchzuführen ist. Sie stellt

damit eine Abstraktion konkreter Geschäftsprozesse dar, die zur Erfüllung dieser Funktion

benötigt werden.


Arbeit MEMO

Ereignis Ereignistyp

Informationsobjekt

Prozessleistung

Input/Output Spezifikation

Input/Output Verwendung

Organisationseinheit Organisationseinheit

Prozess

Führungsprozess

Leistungsprozess


Prozesstyp

Einfacher Prozesstyp

Komplexer Prozesstyp

Prozesseinsatz

Stelle Stelle

Organisatorischer Rollenträger

Technischer Rollenträger Operative Ressource

Tabelle 28: Metamodellbasierter Vergleich mit MEMO

Wie bereits zu Beginn von Abschnitt 4.1 ausgeführt, orientieren sich die Modelle zur Strate-

giegestaltung der vorliegenden Arbeit aufgrund der Positionierung im BE an der Kundenpro-

zessorientierung und der Bildung von Geschäftsnetzwerken. Die lineare vertikale Wertschöp-

fungskette hat sich in vielen Branchen zu einem verzweigten Wertschöpfungsnetzwerk ge-

wandelt, in dem unterschiedliche Unternehmen und Geschäftseinheiten Teilaufgaben in der

Wertschöpfungskette übernehmen. Eine traditionelle Betrachtung und Abbildung der Wert-

schöpfungskette erscheint somit auch im Rahmen der Unternehmensarchitektur nicht mehr

adäquat zu sein.

Auf Informationssystemebene verwendet MEMO eine Modellierungssprache zur Abbildung

der Datenstrukturen, die den UML-Klassendiagrammen sehr ähnlich ist. MEMO definiert

lediglich für den Metaentitätstyp „Klasse“ zusätzliche Eigenschaften wie „Trigger“ und

Strategieebene Ansatz dieser

Arbeit MEMO

Erfolgsfaktor (BSC) Erfolgsfaktor

Geschäftseinheit Geschäftseinheit

Geschäftsnetzwerk Wertschöpfungskette

Kennzahl (BSC) Kennzahl

Kunde

Marktleistung

Kundenprozess

Kundensegment

Geschäftsnetzwerk-Rolle

Markt

Marktsegment

Teilmarkt

Marktposition

Wettbewerber

Serviceaktivität

Aktivität

Primäre Aktivität

Unterstützungsaktivität

Serviceprozess Aktivitätsgruppe

Strategie (BSC) Strategie

Unternehmen Unternehmen

Ziel (BSC) Unternehmensziel

X Ressource


Arbeit MEMO

Klasse Klasse

Assoziation

Aggregation

Komposition

Interaktion

Beziehung

Interaktion

Aggregation

Attribut

Attribut

Guard

Trigger

Service


„Guard“. Mit Hilfe von Triggers können beispielsweise bestimmten Ereignissen im Lebens-

zyklus von Objekten Aktionen zugeordnet werden (z.B.: Wenn ein Mitarbeiter 50 Jahre alt

wird, ist sein Jahresurlaub um zwei Tage zu erhöhen).665 Guards erlauben es, Bedingungen

anzugeben, die während der Lebenszeit eines Objekts immer erfüllt sein müssen, mittels der

Spezifikation einzelner Attribute allein aber nicht artikuliert werden können (z.B.: Der Ver-

kaufspreis eines Artikels soll niemals geringer sein als der Einkaufspreis). Da allerdings der

Ansatz der vorliegenden Arbeit nicht auf softwareentwicklungsrelevante Sachverhalte fokus-

siert, wird auf eine entsprechende Erweiterung des Metamodells verzichtet.

6.2.3 Metamodellbasierter Vergleich mit SOM

SOM definiert keine Metaentitätstypen für die Strategieebene. Ein Vergleich ist auf dieser

Ebene daher nicht möglich.

Die von SOM auf der Organisations- und Informationssystemebene verwendeten Konzepte

werden auch im Ansatz der vorliegenden Arbeit weitgehend abgedeckt (vgl. Tabelle 29). Auf

Organisationsebene bietet SOM zusätzlich die Metaentitätstypen „Nachricht“ und „Vorbedin-

gung“. Eine Nachricht kann allerdings auch als eine Art Informationsobjekt aufgefasst wer-

den. Analog lässt sich eine Vorbedingung als ein Ereignis interpretieren. Damit würde es sich

lediglich um weitere Spezialisierungen bereits im Ansatz dieser Arbeit vorhandener Metaenti-

tätstypen handeln.

SOM differenziert auf Informationssystemebene die konzeptuellen Objekttypen weiter nach

objektspezifischen, leistungsspezifischen und transaktionsspezifischen Objekttypen. Die Ob-

jekttypen werden entsprechend aus Diskurs-/Umweltobjekten, Leistungsspezifikationen und

den Transaktionen des Geschäftsprozessmodells abgeleitet. Analog werden auch im Ansatz

dieser Arbeit die Informationsobjekte aus den Modellen der Aufbau- und Ablauforganisation

abgeleitet. Durch die Dokumentation der Erhebungsquelle der einzelnen Informationsobjekte

werden diese folglich auch entsprechend weiter differenziert.

Da auf Informationssystemebene lediglich automatisierbare Aufgaben bzw. Aktivitäten be-

trachtet werden, dient die Automatisierbarkeit als ein wichtiges Kriterium zur weiteren Ver-

feinerung der auf Organisationsebene erstellten Modelle. Ein entsprechendes Konzept sollte

deshalb auch im Ansatz dieser Arbeit integriert werden. Dies liesse sich beispielsweise recht

einfach durch die Definition zusätzlicher Attribute, wie „Automatisierungsgrad“ und „Auto-

matisierbarkeit“, für den Metaentitätstyp „Aktivität“ umsetzen. Eine Aktivität wird dann ana-

log zu SOM als automatisierbar betrachtet, wenn ein Lösungsverfahren angegeben werden

kann, für das ein Informationssystem zur Verfügung steht oder eines konstruierbar ist.

665 Vgl. hierzu Frank (1995), S. 6.



Arbeit SOM


Geschäftsfunktion

Applikationsfunktion

Automatisierbare Aufgabe

Automatisierbare Transaktion

Automatisierte Aufgabe

Automatisierte Transaktion

X Grad der Automatisierung

Organisationseinheit Betriebliches Objekt

Informationsobjekt

Datenobjekt

Klasse

Objekttyp

objektspezifisch

leistungsspezifisch

transaktionsspezifisch

aufgabenspezifisch

Beziehung

Aggregation

Komposition

Generalisierung

Beziehung

is-a-Beziehung

interacts-with-Beziehung

is-part-of-Beziehung

Attribut Attribut

Tabelle 29: Metamodellbasierter Vergleich mit SOM

6.2.4 Fazit

Der in diesem Abschnitt durchgeführte metamodellbasierte Vergleich mit bestehenden

Methoden zur Unternehmensmodellierung hat gezeigt, dass deren grundlegende Konzepte

auch in dem Ansatz der vorliegenden Arbeit zu finden sind und dieser folglich keine

wesentlichen Lücken aufweist bzw. unvollständig ist. Ferner hat der Vergleich gezeigt, dass

kein Metaentitätstyp des Master-Metamodells, also von ARIS, MEMO oder SOM, durch

mehrere Metaentitätstypen dieses Ansatzes repräsentiert wird. Der entwickelte Ansatz enthält

somit auch keine (ontologischen) Redundanzen.

6.3 Natürlichsprachliche und merkmalbasierte Evaluation

In Abschnitt 2.6 wurden sowohl strukturelle als auch inhaltliche Kriterien zur Beurteilung der

verwandten Ansätze definiert. Der in der vorliegenden Arbeit entwickelte Ansatz zur Model-

lierung der Unternehmensarchitektur wird nun im Folgenden ebenfalls anhand dieser

Kriterien beurteilt. Diese Kriterien können zudem im Hinblick auf die im zuvor beschriebenen

praktischen Einsatz gewonnenen Erfahrungswerte beurteilt werden.

• Aggregation/Ganzheitlichkeit: Um einen möglichst umfassenden Ansatz im Sinne der

Unternehmensarchitektur zu entwickeln, wurde auf einer bestehenden Methode (BAI-

Methode) aufgebaut und diese um Konzepte aus anderen Methoden zur Unternehmens-

modellierung (ARIS, MEMO, SOM) sowie aus domänenspezifischen Ansätzen (Strate-

giegestaltung, Prozessmanagement, Applikationsintegration, IT-Service-Management,

Autorisierung) ergänzt. Dadurch konnten die Schlüsselelemente, die für strategische Fra-

gestellungen im Schnittbereich zwischen Fachbereich und IT-Bereich relevant sind, iden-


Arbeit SOM

Aktivität

Aufgabe

Entscheidungsaufgabe

Lösungsverfahren

Transformationsaufgabe

Ereignis Ereignis

Informationsobjekt Aufgabenobjekt

Informationsbeziehung

Leistungsbeziehung Betriebliche Transaktion

Prozessleistung Leistungspaket

Prozessziel Sach-/Formalziel

Rollenträger Aufgabenträgertyp


Prozessrolle

Stelle

Stellentyp

Betriebliches Objekt

X Nachricht

X Vorbedingung


tifiziert und integriert werden. Der im vorhergehenden Abschnitt durchgeführte metamo-

dellbasierte Vergleich mit existierenden Methoden hat zudem gezeigt, dass deren Konzep-

te im Wesentlichen alle berücksichtigt wurden.

• Strukturierung: Es wurden zahlreiche existierende Ansätze im Hinblick auf die Einteilung

in Architekturebenen und Sichten untersucht (vgl. Kapitel 3). Dabei konnten vier wesent-

liche Architekturebenen sowie 18 relevante Sichten (inklusive der IT-Servicesicht) identi-

fiziert werden, die in dem Ansatz der vorliegenden Arbeit Berücksichtigung gefunden ha-

ben (vgl. Abbildung 32).

• Konsistenz und Formalisierung: Für die Gewährleistung der Konsistenz wurde einerseits

eine klare Einteilung in Ebenen und Sichten (vgl. Abbildung 32) vorgenommen. Anderer-

seits wurden die Schlüsselelemente sowie deren ebeneninterne und ebenenübergreifende

Abhängigkeiten durch ein zugrunde liegendes Metamodell (semi-)formal spezifiziert,

welches mit Hilfe einer Metamodellierungssprache (UML-Klassendiagramme) dargestellt

wurde. Auf jeder Ebene konnten zentrale Metaentitätstypen identifiziert werden, die die

unterschiedlichen Sichten miteinander verknüpfen. Zudem wurden die Metaentitätstypen

und deren Beziehungen verbal beschrieben, um mögliche Missverständnisse zu vermei-

den. Die Abbildung in einer Metamodellierungsplattform hat gezeigt, dass das Metamo-

dell ausreichend formal und konsistent sowie nicht zu abstrakt definiert ist. Ausserdem

bietet der Ansatz neben dem Metamodell eine systematische Vorgehensweise für die kon-

sistente Entwicklung der auf dem Metamodell basierenden Modelle. Die (semi-)formale

Spezifikation der verwendeten Konzepte und deren Beziehungen ermöglicht darüber hin-

aus die Analyse der Auswirkungen von Veränderungen an bestimmten Elementen der Un-

ternehmensarchitektur.

• Verständlichkeit: Die für die Abbildung der unterschiedlichen Ebenen und Sichten ver-

wendeten Symbole und Konzepte stammen aus den jeweiligen Anwendungsdomänen, wie

beispielsweise Geschäftsnetzwerk und BSC für die Modellierung der strategischen Aus-

richtung, EPK für die Prozessmodellierung, UML für die Datenmodellierung. Sie sollten

den Anspruchsgruppen daher ausreichend vertraut sein und ihnen das Verständnis der

Modelle erleichtern. Die Modelle sollten beispielsweise sowohl von Managern, die einen

groben Überblick benötigen, als auch von Softwareentwicklern, die eine Softwarekompo-

nente implementieren und deren Einsatz bzw. Kontext kennen müssen, interpretiert wer-

den können. Innerhalb einer Anwendungsdomäne können die Modelle und aggregierten

Elemente der Unternehmensarchitektur als Ausgangsbasis für detailliertere Spezifikatio-

nen dienen. Des Weiteren sind die Metaentitätstypen und deren grafische Repräsentatio-

nen getrennt voneinander definiert, so dass gegebenenfalls für den Einsatz in einem spezi-

fischen Unternehmensumfeld andere Symbole verwendet werden könnten.

• Angemessenheit: Im Sinne der Unternehmensarchitektur wurden für diesen Ansatz ledig-

lich die Schlüsselelemente im Schnittbereich zwischen Fachbereich und IT ausgewählt.


Detailinformationen sollten mit Modellierungssprachen und Werkzeugen der jeweiligen

Anwendungsdomäne modelliert werden. In Abschnitt 4.8 wurden entsprechende

Schnittstellen zu diesen domänenspezifischen Detailmodellen identifiziert.

• Flexibilität: Aus den gesammelten Erfahrungen lässt sich vermuten, dass zwischen dem

Kriterium der Flexibilität und der Formalisierung/Konsistenz immer ein gewisser Aus-

gleich zu finden ist, da diese Kriterien in der Regel nicht zusammen vollständig erfüllt

werden können. Ein hoher Formalisierungsgrad bedingt erfahrungsgemäss meist auch eine

gewisse Einschränkung bei der Flexibilität. Umgekehrt bedeutet eine hohe Flexibilität

meist eine geringere Formalisierung und damit weniger Gewährleistung der Konsistenz.

Dennoch ist der vorliegende Ansatz trotz der relativ hohen Formalisierung aufgrund des

verwendeten Metamodellierungs- und Vererbungskonzepts bis zu einem gewissen Grad

flexibel einsetzbar. Zusätzliche Metaentitätstypen, Beziehungstypen und Attribute können

mit geringem Aufwand in den bestehenden Ansatz integriert werden.

• Methodenelemente: Im Sinne des Methoden-Engineering (vgl. Abschnitt 2.1) enthält der

in der vorliegenden Arbeit entwickelte Ansatz ein Vorgehensmodell (hier aufgrund der

Fokussierung auf das Metamodell nur auf Level 1 beschrieben666) und Ergebnisdokumen-

te mit einem zugrunde liegenden Metamodell. Bisher wurden allerdings für die Durchfüh-

rung der Aktivitäten des Vorgehensmodells noch keine entsprechenden Rollen und keine

detaillierten Techniken zur Erstellung der Ergebnisdokumente definiert.

Die folgende Tabelle 30 zeigt nochmals zusammenfassend die Erfüllung der inhaltlichen und

strukturellen Charakteristika im Vergleich zu den bestehenden Ansätzen. Im Vergleich zu

letzteren konnten im Hinblick auf die an einen Ansatz für die Abbildung der Unternehmens-

architektur gestellten Anforderungen wesentliche Verbesserungen erzielt werden. Dabei wur-

den vor allem die Kriterien der Ganzheitlichkeit, Strukturierung, Formalisierung und Konsis-

tenz adressiert. Dennoch bestehen Verbesserungspotentiale und Erweiterungsmöglichkeiten,

z.B. bei der Entwicklung eines Rollenmodells, der detaillierteren Spezifizierung von Techni-

ken zur Erstellung der Ergebnisdokumente und der Integration weiterer Konzepte (z.B. SOA,

Sicherheitsarchitektur) im Sinne des Anspruchs der Ganzheitlichkeit an einen Ansatz zur Mo-

dellierung der Unternehmensarchitektur.

666 Für eine detaillierte Beschreibung des Vorgehens und der einzelnen Techniken zur Abbildung der

Unternehmensarchitektur vgl. Choinowski et al. (2003) und Leist (2004).


Inhaltliche Charakteristika Strukturelle Charakteristika

Ansatz

Gan

zhei

tlic

hk

eit

Str

uk

turi

eru

ng

Kon

sist

enz

Ver

stän

dli

chk

eit

An

gem

esse

nh

eit

Fle

xib

ilit

ät

Form

ali

sier

un

g

Vorg

ehen

Roll

en

Erg

ebn

isse

Tec

hn

iken

Met

am

od

ell

ARIS MEMO

SOM

FEAF TOGAF

Zachman

Eigener

Ansatz

Tabelle 30: Merkmalbasierte Evaluierung

Legende: erfüllt/vorhanden teilweise

erfüllt/vorhanden nicht

erfüllt/vorhanden

Zusammenfassung und Ausblick 244

7 Zusammenfassung und Ausblick

Das letzte Kapitel dient der kritischen Reflexion der erarbeiteten Ergebnisse. Hierzu werden

in Abschnitt 7.1 zunächst die wesentlichen Ergebnisse der Arbeit zusammengefasst und diese

danach in Abschnitt 7.2 gewürdigt. Abschliessend erfolgt in Abschnitt 7.3 ein Ausblick auf

weitere Forschungsthemen und Entwicklungsmöglichkeiten, die in unmittelbarem

Zusammenhang mit den Ergebnissen der Arbeit stehen.

7.1 Zusammenfassung der Arbeit

Die Entwicklung einer Unternehmensarchitektur ist eine fundamentale Voraussetzung für die

Bereitstellung von Informationssystemen, die mit den organisatorischen und strategischen

Richtlinien des Unternehmens konsistent sind. Sowohl in der Praxis als auch in der Wissen-

schaft fehlt bisher ein allgemein akzeptiertes Verständnis der wesentlichen Ebenen, Elemente

und Beziehungen einer Unternehmensarchitektur. Insbesondere existiert für diese Elemente

und Beziehungen keine umfassende, (semi-)formale Spezifikation.

Das primäre Gestaltungsziel der vorliegenden Arbeit ist die Entwicklung eines Ansatzes zur

Modellierung der Unternehmensarchitektur und dessen Abbildung in einem kommerziellen

Metamodellierungswerkzeug. Im Mittelpunkt steht dabei zum einen die Definition eines ebe-

nen- und sichtenübergreifenden Metamodells, das die grundlegenden Elemente eines Unter-

nehmens sowie deren Beziehungen festlegt. Zum anderen wird ein Software-Prototyp mit

Hilfe des Metamodellierungswerkzeuges erstellt. Damit sollen die Konsistenz und Umsetz-

barkeit des entwickelten Ansatzes gezeigt werden.

Die Erhebung und Analyse aktueller Grundlagen und Ansätze der Unternehmensmodellierung

in Praxis und Forschung stellt das primäre Erkenntnisziel der Arbeit dar. Diese bildet zusam-

men mit einer bereits bestehenden Methode die Grundlage für die Entwicklung des Metamo-

dells. Ein weiteres Erkenntnisziel ist die Analyse kommerziell verfügbarer Modellierungs-

werkzeuge zur softwaretechnischen Abbildung der Unternehmensarchitektur.

Die Entwicklung des Ansatzes beginnt mit der Aufarbeitung konzeptioneller Grundlagen der

Unternehmensmodellierung (Kapitel 2). Zunächst wird das Methoden- und Modellverständnis

der vorliegenden Arbeit erläutert. Darauf aufbauend wird der Begriff Unternehmensarchitek-

tur eingeführt und genauer eingegrenzt. Die Architektur eines Unternehmens besteht im Ver-

ständnis dieser Arbeit aus verschiedenen Ebenen sowie ebeneninternen und ebenenübergrei-

fenden Sichten auf dieses Unternehmen. Jede Sicht repräsentiert einen Ausschnitt des Unter-

nehmens für einen bestimmten Zweck und wird durch ein zugrunde liegendes Metamodell

definiert. Für die Gewährleistung der Konsistenz zwischen den einzelnen Sichten sind die

Identifikation der Gesamtzusammenhänge sowie deren komplexitätsreduzierende Darstellung

wesentlich. Ein systematischer, methoden- und modellbasierter Ansatz kann hierbei


Unterstützung leisten. Das Business Engineering (BE) bildet aus diesem Grunde den

Forschungsrahmen des Dissertationsvorhabens. Im Grundlagenteil werden daher die

grundlegende Ausrichtung, die Gestaltungsebenen und Inhalte sowie das vereinfachte

Metamodell des Business Engineering vorgestellt. Entsprechend dem BE-Ansatz sind in den

letzten Jahren zahlreiche Methoden entwickelt worden. Darunter auch die BAI-Methode,

welche den Ausgangspunkt der Arbeit darstellt und daher ebenfalls im Grundlagenteil kurz

eingeführt wird. Anschliessend wird auf die Bedeutung der Werkzeugkonstruktion und -unter-

stützung für die Unternehmensmodellierung eingegangen sowie deren aktueller

Entwicklungsstand beschrieben. Nach Einführung der relevanten Begrifflichkeiten und der

Eingrenzung des Themengebiets erfolgt eine Diskussion der Ziele und treibenden Kräfte der

Unternehmensarchitektur. Darauf aufbauend werden abschliessend im Grundlagenteil die

Anforderungen an den zu entwickelnden Ansatz sowie die Werkzeugunterstützung abgeleitet.

Im Anschluss an die Aufarbeitung der Grundlagen erfolgt die Untersuchung methodischer

Ansätze, die sich mit dem Thema Unternehmensarchitektur befassen (Kapitel 3). Dabei wer-

den im Hinblick auf die Entwicklung eines eigenen Ansatzes insbesondere solche Ansätze

berücksichtigt, die weitestgehend die im Grundlagenteil formulierten Anforderungen erfüllen.

Zum einen erfolgt eine detaillierte Beschreibung und Bewertung existierender Methoden zur

Unternehmensmodellierung, die primär aus der Wissenschaft stammen. Zum anderen werden

aktuelle Bezugsrahmen (Frameworks) vorgestellt und bewertet, die in der Praxis am häufigs-

ten zum Einsatz kommen und die von den meisten aktuell am Markt verfügbaren Werkzeugen

unterstützt werden. Aus der Analyse geht hervor, dass keiner der bestehenden Ansätze die

Anforderungen vollständig erfüllt. Auffallend ist, dass gerade die in der Praxis weit verbreite-

ten Bezugsrahmen die Anforderungen am wenigsten erfüllen, insbesondere die Kriterien der

Ganzheitlichkeit, Konsistenz und Formalisierung.

Aufgrund dieser Schwächen wird ein eigener Ansatz vorgeschlagen, der die Stärken der be-

werteten Ansätze berücksichtigt und vor allem die Kriterien der Ganzheitlichkeit, Konsistenz

und Formalisierung adressiert (Kapitel 4). Der Fokus des eigenen Ansatzes liegt deshalb auf

der Entwicklung eines möglichst ganzheitlichen, (semi-)formal definierten Metamodells, das

insbesondere die ebenen- und sichtenübergreifenden Abhängigkeiten zwischen den grundle-

genden Elementen der Unternehmensarchitektur berücksichtigt. Der Ansatz zur Modellierung

der Unternehmensarchitektur umfasst die Methodenelemente Vorgehensmodell, Metamodell

und Ergebnisdokument auf Strategie-, Organisations-, Applikations-, Softwarekomponenten

und Datenstruktur- sowie Infrastrukturebene. Wegen der zunehmenden Bedeutung serviceori-

entierter Konzepte wird darüber hinaus zum einen ein Metamodell für eine IT-Servicesicht

basierend auf der IT Infrastructure Library (ITIL) vorgeschlagen und mit den anderen in die-

ser Arbeit definierten Sichten auf die Unternehmensarchitektur integriert. Zum anderen wird

die Integration einer serviceorientierten Architektur als weitere mögliche Erweiterung der

Unternehmensarchitektur betrachtet. Da die detaillierte Abbildung der einzelnen Sichten nicht


im Rahmen der Unternehmensarchitektur, sondern weiterhin in domänenspezifischen Archi-

tekturmodellen und mit entsprechenden Modellierungssprachen (und Werkzeugen) erfolgen

sollte, werden schliesslich die wesentlichen Schnittstellen zu diesen Detailmodellen identifi-

ziert. Der entwickelte Ansatz bildet somit einen Bezugsrahmen, der Elemente und Konzepte

aus domänenspezifischen Ansätzen miteinander in aggregierter Form integriert und Schnitt-

stellen zu entsprechenden Detailmodellen bietet. Die Detailmodelle können somit zunächst

nebenläufig gestaltet und weiterentwickelt werden. Die entwickelte Unternehmensarchitektur

liefert Vorgaben, aus denen entsprechende Anpassungen resultieren, die die Konsistenz des

Gesamtsystems bewahren.

Um die Konsistenz und Umsetzbarkeit des entwickelten Metamodells überprüfen zu können,

wird dieses mit Hilfe einer Metamodellierungsplattform abgebildet (Kapitel 5). Dazu werden

zunächst ausgewählte, kommerziell verfügbare (Meta-)Modellierungswerkzeuge dargestellt

und anhand der im Grundlagenteil abgeleiteten Anforderungen bewertet. Die Entscheidung

fiel zu Gunsten von ADONIS der Firma BOC Business Objects Consulting aus. Das Werk-

zeug deckt bereits ohne anwendungsspezifische Anpassungen alle Hauptkriterien ab. Durch

sein methodenunabhängiges Metamodellierungskonzept ermöglicht ADONIS eine flexible

und einfache Umsetzung sowie Anpassung der Metamodelle des in dieser Arbeit präsentierten

Ansatzes. Der aus der Implementierung mit dem Metamodellierungswerkzeug entstandene

Software-Prototyp wird anschliessend im Hinblick auf dessen wesentliche Komponenten und

Funktionalitäten vorgestellt. Der Prototyp besteht aus einem Modelleditor für die Erstellung

und Bearbeitung von Modellen, einer Analysekomponente für die Durchführung von Abfra-

gen auf den erstellten Modellen, einer Simulationskomponente für die Durchführung von Si-

mulationsalgorithmen sowie einer Import/Export- und Dokumentationskomponente.

Schliesslich wird darüber hinaus eine multiperspektivische Evaluation des Prototyps und des

zugrunde liegenden Metamodells in Form einer Fallstudie sowie einer natürlichsprachlichen,

merkmalbasierten und metamodellbasierten Evaluierung durchgeführt (Kapitel 6). Die Fall-

studie der Winterthur Group bestätigt die Praxistauglichkeit. Mit geringfügigen unterneh-

mensspezifischen Anpassungen können der Prototyp und das Metamodell in der Praxis für die

Abbildung der Unternehmensstrukturen eingesetzt werden. Die natürlichsprachliche und

merkmalbasierte Evaluierung macht deutlich, dass der entwickelte Ansatz im Vergleich zu

den bereits bestehenden Ansätzen wesentliche Verbesserungen bringt und die im Grundlagen-

teil formulierten Anforderungen weitgehend erfüllt. Die metamodellbasierte Evaluierung un-

tersucht und vergleicht die Metaentitätstypen und Beziehungen des entwickelten Metamodells

anhand eines so genannten Master-Metamodells. Eine derartige Analyse ermöglicht die Über-

prüfung der Vollständigkeit und Redundanzfreiheit der verwendeten Konzepte sowie die

Identifikation möglicher Spezialisierungen bzw. Generalisierungen. Als Ergebnis dieser Ana-

lyse geht hervor, dass das entwickelte Metamodell in Bezug auf das Master-Metamodell voll-

ständig ist und keine Redundanzen aufweist.


7.2 Kritische Würdigung

Im Rahmen der multiperspektivischen Evaluierung wurde bereits eine ausführliche und kriti-

sche Diskussion der erarbeiteten Ergebnisse geführt (vgl. Kapitel 6). Da dem Dissertations-

vorhaben das Design-Science-Paradigma zugrunde liegt (vgl. Abschnitt 1.3), erfolgt die Wür-

digung zudem anhand der Design-Science-Richtlinien, die wesentliche Anforderungen an

eine Forschungsarbeit formulieren.

Das Ergebnis einer DS-Forschungsarbeit ist ein anwendbares Artefakt in Form einer Metho-

de, eines Modells oder einer Instanz:667 Die Ergebnisse der vorliegenden Arbeit sind zum ei-

nen der Ansatz und das Metamodell für die Modellierung von Unternehmensarchitekturen

und zum anderen der entwickelte (Software-)Prototyp. Da der Ansatz auf einer bestehenden

Methode aufbaut, die gemeinsam mit Partnerunternehmen entwickelt wurde, ist das entwi-

ckelte Artefakt anwendbar. Die Fallstudie hat darüber hinaus die potenzielle Praxistauglich-

keit des Prototyps und des Metamodells demonstriert.

Das Ziel der DS-Forschung ist die Entwicklung technologiebasierter Lösungen für wichtige

und relevante Probleme:668 Die Relevanz der vorliegenden Arbeit ergibt sich aus den Zielen

und treibenden Kräften der Unternehmensarchitektur (vgl. Abschnitt 2.5) sowie den Defiziten

bestehender Ansätze (vgl. Kapitel 3). Bisher existiert kein Ansatz, der alle relevanten Berei-

che und Elemente der Unternehmensarchitektur konsistent abbildet. Die Arbeit adressiert die-

ses Problem durch die Entwicklung eines ebenen- und sichtenübergreifenden Metamodells

sowie eines geeigneten (Software-)Werkzeuges.

Die Anwendung, Effektivität und Qualität des Artefakts müssen stringent und nachvollzieh-

bar dargelegt werden:669 Die Qualität des entwickelten Ansatzes wird durch die Ableitung und

Berücksichtigung von Anforderungen sichergestellt (vgl. Abschnitt 2.6), die auf Basis der

Grundlagen und Herausforderungen sowie der Ziele und treibenden Kräfte der Unterneh-

mensarchitektur ermittelt werden. Die Konstruktion eines Prototyps zeigt die Konsistenz und

ausreichende Formalisierung des Metamodells. Das Fallbeispiel demonstriert dessen Praxis-

tauglichkeit. Darüber hinaus erfolgen eine metamodellbasierte sowie natürlichsprachliche und

merkmalbasierte Evaluation.

Die DS-Forschung muss klar nachvollziehbare und nachprüfbare Ergebnisse in Form von

Artefakten oder Beiträgen zur Wissensbasis liefern:670 Der Forschungsbeitrag ist sicherge-

stellt, wenn die Defizite bestehender Ansätze und Werkzeuge adressiert werden konnten. Die

vorliegende Arbeit entwickelt zum einen ein Artefakt in Form eines Metamodells und eines

Prototyps. Darüber hinaus liefert die Arbeit einen detaillierten Vergleich bestehender Ansätze

667 Vgl. Hevner et al. (2004), S. 82.

668 Hevner et al. (2004), S. 84.

669 Hevner et al. (2004), S. 85.

670 Hevner et al. (2004), S. 87.


und eine Bewertung aktuell verfügbarer Modellierungswerkzeuge. Die multiperspektivische

Evaluation zeigt zudem, wie Artefakte der DS-Forschung evaluiert werden können.

Die DS-Forschung verlangt bei der Konstruktion und Bewertung des Artefakts die Einhaltung

stringenter, forschungsmethodischer Grundsätze:671 Die Stringenz der Forschung wird durch

die Anwendung der in der Wirtschaftsinformatik allgemein akzeptierten Forschungsmethoden

Deduktion, Modellierung sowie Entwicklung und Test eines Prototyps sichergestellt. Dabei

wird auf die existierende Wissensbasis zurückgegriffen, insbesondere im Rahmen der Grund-

lagen und der Diskussion bereits existierender Ansätze. Darüber hinaus wird bei der Entwick-

lung des Ansatzes auf Literaturquellen zurückgegriffen, die bestimmte Teilbereiche der Un-

ternehmensarchitektur abdecken, wie z.B. Strategiegestaltung, Prozessmanagement, Service-

management und Applikationsintegration.

Die DS-Forschung ist ein Suchprozess. Die endgültige Problemlösung wird durch einen itera-

tiven Prozess erreicht:672 Die Erkenntnisse aus dem Praxistest und der multiperspektivischen

Evaluation sowie das Feedback von Vertretern der Partnerunternehmen im Rahmen von

Workshops fliessen in einem iterativen Prozess in die Verbesserung des Prototyps und Meta-

modells ein. Eine optimale Lösung kann in der DS-Forschung nicht bestimmt werden. Durch

den iterativen Prozess kann aber zumindest von einer guten Lösung ausgegangen werden.

Die Ergebnisse der DS-Forschung müssen sowohl einem technologieorientierten als auch

einem managementorientierten Publikum vermittelt werden:673 Das Metamodell wird detail-

liert spezifiziert und in einem Prototyp abgebildet, so dass es von Fachkräften in der Praxis

eingesetzt werden kann. Die Beschreibung der Ziele und treibenden Kräfte der Unterneh-

mensarchitektur vermitteln auch Führungskräften die Bedeutung der erzielten Ergebnisse. Die

Ergebnisse werden zudem in der Forschungsgemeinschaft veröffentlicht und zur Diskussion

gestellt.

Neben der Erfüllung der zuvor beschriebenen DS-Richtlinien ist auch das Kriterium der „All-

gemeingültigkeit“ kritisch zu diskutieren. Die als Grundlage verwendete BAI-Methode wurde

ursprünglich für die Finanzdienstleistungsbranche entwickelt. Es lassen sich deren Konzepte

aber auch weitgehend auf andere Branchen übertragen. Zudem wurde sie in dieser Arbeit um

Konzepte aus bestehenden (branchenunabhängigen) Ansätzen erweitert. Es wird daher an den

in dieser Arbeit entwickelten Ansatz ein branchenübergreifender Allgemeingültigkeitsan-

spruch gestellt. Da der Allgemeingültigkeitsanspruch einer Methode, eines Referenzmodells

oder eines Metamodells nur eingeschränkt erzielt und überprüft werden kann,674 muss dieser

671 Hevner et al. (2004), S. 87.

672 Hevner et al. (2004), S. 88.

673 Hevner et al. (2004), S. 90.

674 Vgl. hierzu z.B. vom Brocke (2003b), S. 31f. und Wortmann (2005), S. 100.


durch den Einsatz des Prototyps und des Metamodells in zahlreichen weiteren Unternehmen

verschiedener Branchen überprüft werden.

Ein weiterer Aspekt, den es zu diskutieren und überprüfen gilt, sind die im Grundlagenteil

formulierten Ziele und treibenden Kräfte einer Unternehmensarchitektur. Als eines der we-

sentlichen Ziele der Unternehmensarchitektur wurde insbesondere das IT-Business-Alignment

herausgestellt. Die vorliegende Arbeit stellt nicht den Anspruch, das Problem des IT-

Business-Alignment gelöst zu haben. Dennoch können Fragestellungen des IT-Business-

Alignment auf Basis des entwickelten Ansatzes besser untersucht und beurteilt werden. Der

Ansatz bietet zum einen eine nützliche und wichtige Grundlage für die modellbasierte Analy-

se von Abhängigkeiten und Wechselwirkungen zwischen der strategischen Ausrichtung, den

Prozessen und Organisationsstrukturen sowie den Informationssystemen und der zugrunde

liegenden Infrastruktur eines Unternehmens. Zudem bietet er eine gemeinsame Kommunika-

tionsbasis für Mitarbeiter aus unterschiedlichen Unternehmensbereichen.

7.3 Zukünftiger Forschungs- und Entwicklungsbedarf

Die vorliegende Arbeit bildet eine Grundlage für zahlreiche weitere wissenschaftliche Aktivi-

täten sowie für die Weiterentwicklung des in dieser Arbeit präsentierten Ansatzes und Proto-

typs. Die folgenden Ansatzpunkte fassen den zukünftigen Forschungs- und Entwicklungsbe-

darf zusammen:

• Quantitative Analyse: Bisher wurde die quantitative Analyse der Unternehmensarchitektur

sowohl in der Praxis als auch in der Wissenschaft nicht in Betracht gezogen, da davon

ausgegangen wurde, dass diese Detailinformationen erfordert, die bei der Dokumentation

der Unternehmensarchitektur nicht oder lediglich in aggregierter Form erfasst werden.

LANKHORST ist aber beispielsweise der Meinung, dass auch auf einem eher globalen, ag-

gregierten Niveau die Unternehmensarchitektur quantitativ analysiert werden kann und

sollte, insbesondere im Hinblick auf die Abhängigkeiten zwischen den unterschiedlichen

Architekturebenen.675 So erfordern beispielsweise die Geschäftsprozesse eine bestimmte

Performance der unterstützenden Informationssysteme. Umgekehrt beeinflusst die Per-

formance der Informationssysteme die Durchführung der Geschäftsprozesse und damit die

Reaktionszeit auf die Kundenprozesse. Analog zur Entwicklung von der Softwarearchi-

tektur hin zur Unternehmensarchitektur könnten folglich auch Konzepte für die Analyse

von Software (Software Testing, Simulation) daraufhin untersucht werden, inwieweit sie

auf die Analyse der Unternehmensarchitektur übertragen werden können. Dabei spielen

auch die Schnittstellen zu den operativen Systemen eine wichtige Rolle. Die quantitative

Analyse liesse sich beispielsweise auf Basis bestimmter Kennzahlen durchführen. Diese

könnten zunächst operativ gesammelt (z. B. Antwortzeiten der Applikationen, Ausfallzei-

675 Vgl. z.B. Lankhorst (2005), S. 193-194.


ten, Userbeschwerden, Service-Anfragen etc.) und anschliessend mit Hilfe der durch die

Unternehmensarchitektur vorgegebenen Struktur aggregiert und aufbereitet werden. Die

Unternehmensarchitektur würde somit als eine Art Analysestruktur dienen.

• Kostenanalyse: Aus der Fallstudie mit der Winterthur Group ging unter anderem hervor,

dass in der Praxis die Beantwortung der Frage nach den Kosten der IT für einen bestimm-

ten Geschäftsprozess eine grosse Bedeutung hat. Weitere Arbeiten könnten untersuchen,

inwieweit sich diese Fragestellung auf Basis des in dieser Arbeit präsentierten Unterneh-

mensarchitektur-Ansatzes beantworten lässt.

• Evaluierung und Weiterentwicklung: Wünschenswert wären darüber hinaus weitere An-

wendungen des Ansatzes und des entwickelten Prototyps in der Praxis, um diese auf eine

breitere Fallstudienbasis zu stellen. Die dabei gesammelten Erfahrungen könnten im Sinne

eines iterativen Forschungs- und Entwicklungsprozesses in die Weiterentwicklung des

Prototyps und des zugrunde liegenden Metamodells einfliessen. Um die in dieser Arbeit

ansatzweise durchgeführte multiperspektivische Evaluierung zu ergänzen, könnte zusätz-

lich eine Evaluierungsmethode der fremddisziplinären Perspektive angewendet werden.

FETTKE/LOOS schlagen dafür beispielsweise eine Evaluierung auf Basis der Bunge-

Methode vor.676

• Architekturprozesse: Um das im Grundlagenteil angesprochene IT-Business-Alignment zu

erreichen, sind neben einem ebenenübergreifenden Metamodell auch entsprechende Pro-

zesse zur Bewirtschaftung und Kommunikation der erstellten Modelle und ihrer Elemente

notwendig. Ziel dieser Prozesse ist es, die auf Basis des Metamodells entwickelten Model-

le dauerhaft effizient und effektiv miteinander zu koordinieren. HAFNER hat in seiner Ar-

beit eine Methode für das Management der IS-Architektur entwickelt.677 Ein zukünftiger

Forschungsbedarf besteht in der systematischen Überprüfung dieser Methode im Hinblick

auf ihre Übertragung auf gesamte Unternehmensarchitekturen und deren Integration mit

dem in dieser Arbeit präsentierten Ansatz bzw. dessen Metamodell. Mit zunehmender

Reife könnte anschliessend die Werkzeugunterstützung der Architekturprozesse mit dem

in dieser Arbeit entwickelten Prototyp betrachtet werden.

• IT-Servicesicht: Eine konsistent entwickelte und dokumentierte Unternehmensarchitektur

bildet eine wertvolle Grundlage für das IT-Service-Management. IT-Verantwortliche kön-

nen mit ihrer Hilfe einen klaren Blick auf die Infrastruktur und Applikationen, die unter-

stützten Geschäftsprozesse sowie auf die unterschiedlichen Abhängigkeiten zwischen die-

sen Elementen erhalten. Davon profitieren nahezu alle in ITIL definierten Kernprozesse.

In Abschnitt 4.4 wurde bereits ein erster Vorschlag zur Integration einer IT-Servicesicht

präsentiert, der in nachfolgenden Arbeiten verfeinert werden könnte.

676 Vgl. hierzu z.B. Fettke/Loos (2003) und Rosemann/Green (2002).

677 Vgl. Hafner (2005).


• Methodenbestandteile: Der Fokus der vorliegenden Arbeit lag primär auf der Definition

eines ebenenübergreifenden Metamodells. Um diesen Methoden-Ansatz im Sinne des Me-

thoden-Engineering zu einer kompletten Methode auszubauen, sind die Entwicklung eines

Rollenmodells sowie die detaillierte Spezifizierung von Techniken erforderlich. Als

Grundlage für die Entwicklung des Rollenmodells könnten beispielsweise die in dem

Framework der IEEE678 definierten Stakeholder und Viewpoints dienen. Darüber hinaus

liesse sich die Integration weiterer Konzepte (z.B. SOA, Sicherheitsarchitektur) betrach-

ten, um dem Anspruch der Ganzheitlichkeit noch besser gerecht zu werden.

• Schnittstellen: Die Entwicklung und Pflege der Unternehmensarchitektur wird auch in

Zukunft nicht durch ein einziges Werkzeug unterstützt werden. Stattdessen werden wei-

terhin verschiedene, domänenspezifische Modellierungssprachen, -techniken und -werk-

zeuge in einem Unternehmen zum Einsatz kommen. Spezielle Werkzeuge für die Unter-

nehmensmodellierung, wie der in dieser Arbeit entwickelte Prototyp, bilden lediglich die

Beziehungen zwischen den aggregierten Elementen der domänenspezifischen Modelle ab

und bieten darauf aufbauend spezifische Analysemechanismen. Die Integration mit domä-

nenspezifischen Werkzeugen ist folglich von entscheidender Bedeutung für den Erfolg

und die Akzeptanz des entwickelten Werkzeuges in der Praxis. In Abschnitt 4.8 wurden

bereits einige Schnittstellen zu domänenspezifischen Modellierungssprachen und Werk-

zeugen identifiziert und konzeptionell spezifiziert. Diese könnten durch die Implementie-

rung entsprechender Import/Export-Funktionalitäten und/oder die Definition von Referen-

zen auf die korrespondierenden Modelle und Objekte in den operativen Systemen tech-

nisch umgesetzt werden.

Wie die obigen Ausführungen zeigen, besteht im Bereich der Unternehmensmodellierung und

Werkzeugunterstützung noch erheblicher Forschungs- und Entwicklungsbedarf. Die vorlie-

gende Arbeit kann als Grundlage für weitere Forschungsarbeiten genutzt werden. Da die Ak-

zeptanz und Bedeutung der Unternehmensarchitektur in der Praxis weiterhin wächst,679 wird

sie auch in Zukunft ein relevantes Themengebiet der angewandten Forschung sein.

678 Vgl. IEEE (2000), S. 5 und Hafner (2005), S. 29.

679 Vgl. IFEAD (2005), S. 33.

Anhang A: Dokumentation der Abbildung der Metamodelle in ADONIS 252

Anhang A: Dokumentation der Abbildung der Meta-

modelle in ADONIS

A.1. Strategieebene

Modelltyp „Geschäftsnetzwerk“


Name Text

Beschreibung Text, mehrzeilig

Kommentar Text, mehrzeilig

Bezugseinheit 1:1-Referenz auf Organisationseinheit in Auf-bauorganisation

Service Integrator

Leistungsmodell 1:1-Referenz auf Leistungsmodell

Name Text




Shared Service Provider


Name Text




Exclusive Service Provider


Name Text




Public Service


Name Text


Business Bus (BCI)


Name Text



Kundenprozess

Kundenprozess 1:1-Referenz auf Kundenprozessmodell

Name Text



Endkunde

Kontaktpräferenz Enumeration (Internet, Telefon, Filiale, etc.)

Name Text



Kundensegment (Aggregation)

Art Enumeration (standardisiert, individualisiert)

Farbe Kontextabhängig

bezieht Leistung

(von Rolle zu Rolle)

Linie Kontextabhängig (direkt, indirekt)

Modelltyp „Kundenprozessmodell“

(Beziehungs-)Klasse Attribut Attributtyp Name Text



Kundenbedürfnis Text

Kundentyp Text

(End-)Kunde 1:1-Referenz auf Kunde in Geschäftsnetzwerk-modell

Kundenprozess

(Schwimmbahn)

Kontaktpräferenz Enumeration (Internet, Telefon, Filiale, etc.)

Name Text



Vertriebsweg Enumeration (Internet, Telefon, Filiale, etc.)

Reputation Text

Problemlösung Text, mehrzeilig

Serviceprozess

(Schwimmbahn)

Marktleistungen 1:n-Referenz auf eine oder mehrere Ausprä-gung/en des Leistungsmodells


Name Text




Serviceaktivität

Referenzierte Prozesse 1:n-Referenz auf Prozesse in Prozesslandkarte

Name Text



Kundenaktivität

bedarf

(von Kundenaktivität zu Serviceaktivität)

Modelltyp „Leistungsmodell“




Dimension

(Aggregation)

Name Text


Ausprägung

Modelltyp „Zielmodell (BSC)“




Strategie


Name Text



Kritischer Erfolgsfaktor

Externe Dokumentation 1:1-Referenz auf Word- oder Excel-Dokument


Name Text




Massnahme

(in Poolmodell)

Name Text



Ziel

Massnahmen 1:n-Referenz auf eine oder mehrere Massnah-me/n im Massnahmenmodell (Pool)

Name Text


Kennzahl


Name Text


Perspektive

…

beeinflusst (von Erfolgsfaktor zu Strate-

gie)

hat

(von Ziel zu Erfolgsfaktor)

Modelltyp „Massnahmen“ (Pool)


Name Text



Bezugseinheit 1:1-Referenz auf OE in Aufbauorganisation

(Prozess-)Leistung

Ziele

1:n-Referenz auf ein oder mehrere Ziel/e der BSC


Name Text



Aggregation

ist Vorgänger von

(von Massnahme zu Mass-nahme)

A.2. Organisationsebene

Modelltyp „Prozesslandkarte“


Name Text



Typ Enumeration (Leistungs-, Unterstützungs-, Füh-rungsprozess)

(Prozess-)Leistungen 1:n-Referenz auf eine oder mehrere Prozessleis-tung/en im (Prozess-)Leistungsmodell (Pool)


Prozessführung 1:1-Referenz auf Modell der Prozessführung

Subprozess 1:1-Referenz auf Prozess der Prozesslandkarte oder EPK

Leistungen (Prozessvision) Text, mehrzeilig

Ablauf (Prozessvision) Text, mehrzeilig

Erfolgsfaktoren (Prozess-vision)

Text, mehrzeilig

Prozess

IT-Unterstützung (Pro-zessvision)

Text, mehrzeilig

Name Text




Bezugseinheit

(Aggregation)


erbringt/bezieht Leistung


erbringt/bezieht Infor-

mation


Modelltyp „Leistungen“ (Pool)


Name Text



Typ Enumeration (Sach-, Informationsdienstleistung, sonstige Dienstleistung)

Leistungsspezifikation 1:n-Referenz auf eine oder mehrere Ausprä-gung/en im (Markt-)Leistungsmodell auf Strate-gieebene

Externe Leistungs-spezifikation

1:1-Referenz auf Word- oder Excel-Dokument

Informationsobjekte 1:n-Referenz auf eines oder mehrere Informati-onsobjekte

(Prozess-)Leistung

Kostenart Enumeration (Kostenarten)

ist übergeordnet

(von Leistung zu Leistung)

Modelltyp „Prozessführung“


Name Text



Kritischer Erfolgsfaktor

(Aggregation)

Erfolgsfaktor 1:1-Referenz auf Erfolgsfaktor in BSC

Name Text



Prozessziel


Name Text



Kennzahl 1:1-Referenz auf Kennzahl in BSC

Führungsgrösse

Messsystem 1:1-Referenz auf externe Anwendung

bestimmt

(von Prozessziel zu Füh-

rungsgrösse)

Modelltyp „Aufbauorganisation“


Name Text



Standort Text

Typ Enumeration (Unternehmen, externe oder interne Geschäftseinheit)


Prozesse 1:n-Referenz auf einen oder mehrere Prozess/e der Prozesslandkarte

Name Text



Stellentyp Enumeration

Person 1:1-Referenz auf Person in Aufbauorganisation

E-Mail Text

Telefon Text

Standort Text

Stelle

Qualifikationen Tabelle

Name Text


Standort Text


Prozessrolle

Kompetenzen Tabelle


Name Text


Person

Stellvertreter 1:n-Referenz auf eine oder mehrere Stelle/n in

der Aufbauorganisation

ist übergeordnet

(von OE zu OE)

gehört zu

(von Stelle zu OE)

nimmt wahr

(von Rollenträger zu Rolle)

kommuniziert mit

(von OE zu OE)

Modelltyp „Ablauforganisation“


Name Text



Aktivität

Prozessablauf 1:1-Referenz auf Subprozess

Name Text



Auslöser Text, mehrzeilig

Prozessstart

Ergebnis Text, mehrzeilig

Name Text



Ereignis


Name Text


Referenzierte Applikation 1:1-Referenz auf Applikation in App.-Bestandsführung

Datensicht 1:1-Referenz auf UML-Klassendiagramm

Applikation

(Referenz)

Steuerungssicht 1:1-Referenz auf EPK

Name Text



Prozessrolle

(Referenz)

Referenzierter Rollenträger 1:1-Referenz auf Rolle, Stelle oder Organi-sationseinheit in Aufbauorganisation

Name Text

Beschreibung Text, mehrzeilig Operator

Name Text



Prozessleistung

(Referenz)

Referenzierte Leistung

1:1-Referenz auf eine Leistung in Leistun-gen (Pool)

Name Text



Informationsobjekt

(Referenz)

Referenziertes Informations-objekt

1:1-Referenz auf Informationsobjekt in In-formationsobjektmodell

Name Text



Prozesswegweiser

Referenzierter Prozess 1:1-Referenz auf EPK

Name Text


Referenzierte Kennzahl 1:1-Referenz auf Kennzahl in Prozessfüh-rung

Kennzahl

(Referenz)


Übergangsbedingung Text, mehrzeilig

Übergangswahrscheinlichkeit Text

ist Nachfolger/Vorgänger

von

(von Ereignis zu Aktivi-

tät/Operator) Kommentar Text, mehrzeilig

führt aus

(von Rollenträger zu Aktivität)

ist Input für


ist Output von


unterstützt

(von Applikation zu Aktivität)

ist zugeordnet

(von Führungsgrösse zu Aktivi-

tät)

Modelltyp „Informationslandkarte“


Name Text



Informationsobjekte 1:n-Referenz auf ein oder mehrere Informa-tionsobjekt/e

Bericht

Messsystem 1:1-Referenz auf externe Anwendung

Name Text



Stelle

Referenzierte Stelle 1:1-Referenz auf Stelle in Aufbauorganisati-on


Name Text



konsumiert/produziert

(von Stelle zu Bericht)

A.3. Applikationsebene

Modelltyp „Applikationsbestandsführung“


Name Text

Applikationsbezeichnung Text

Applikations-ID Text

Informationsobjekte 1-n-Referenz auf ein oder mehrere Informations-objekt/e im Informationsobjektmodell

Geschäftsfunktionen 1-n-Referenz auf eine oder mehrere Geschäfts-funktion/en im Geschäftsfunktionenmodell

Life-Cycle-Status Enumeration (in Betrieb, in Planung, …)

Owner 1:1-Referenz auf OE in Aufbauorganisation

unterstützt 1:n-Referenz auf einen oder mehrere Prozess/e in Prozesslandkarte

Anzahl User Text

Applikation

Softwarekomponenten 1:n-Referenz auf eine oder mehrere Software-komponent/en in Komponenten und Plattformen

Name Text


Unterstützte Prozesse 1:n-Referenz auf einen oder mehrere Prozess/e in Prozesslandkarte

Applikationsdomäne

(Aggregation)

Owner 1:1-Referenz auf Organisationseinheit in Auf-bauorganisation

Modelltyp „Informationsobjektmodell“


Name Text


Datenobjekte 1:n-Referenz auf ein oder mehrere Datenobjekt/e

Begrifflichkeiten Tabelle

Informationsobjekt

Erhebungsquellen

1:1-Referenz auf Prozess oder Organisationsein-heit


Name Text



Applikationsdomäne

(Aggregation)

Owner 1:1-Referenz auf Organisationseinheit in Auf-bauorganisation

Modelltyp „Geschäftsfunktionenmodell“


Organisationseinheit Referenz auf Org.einheit in Aufbauorganisation

Name Text


Geschäftsfunktion

Name Text



Applikationsdomäne

(Aggregation)

Owner 1:1-Referenz auf Organisationseinheit in Auf-

bauorganisation

Modelltyp „Integrationsarchitektur“


Name Text


Beziehungsstruktur

Name Text


Anwendungsfeld Text, mehrzeilig

Anwendungsschnittstellen Text, mehrzeilig

Integrationsbereich

Name Text


Referenzierte Applikation 1:1-Referenz auf Applikation in App.-Bestandsführung

Datensicht 1:1-Referenz auf UML-Klassendiagramm

Applikation

(Referenz)

Steuerungssicht 1:1-Referenz auf EPK


Name Text


Referenziertes IO 1:1-Referenz auf IO in Informationsobjektmo-dell

Informationsobjekt

(Referenz)

Name Text


Referenzierte Geschäfts-funktion

1:1-Referenz auf Geschäftsfunktion in Ge-schäftsfunktionenmodell

Geschäftsfunktion

(Referenz)

Name Text


Referenz 1:1-Referenz auf Leistung, Organisationseinheit oder Prozess

Leistung/Organisations-

einheit/Prozess

(Referenz)

wird abgeleitet aus

(von Integrationsbereich zu Beziehungsstruktur)

ist zugeordnet

(von Integrationsbereich zu

Applikation)

Art Enumeration (Leistungs-, Informations-, Daten-, Controllingbeziehung)

hat Beziehung mit

(zw. Informationsobjekt,

Geschäftsfunktion oder LOP )


A.4. Softwarekomponenten- und Datenstrukturebene

Modelltyp „Komponenten und Plattformen“


Name Text


Entwicklungstechnologie Text, mehrzeilig

Betriebskomponente Text, mehrzeilig

Infrastrukturelement 1:1-Referenz auf Infrastrukturelement

Applikationen 1:n-Referenz auf eine oder mehrere Applikati-on/en der Bestandsführung

Datenobjekte 1:n-Referenz auf eines oder mehrere Datenob-jekt/e des Datenobjektmodells


Lieferant Text, mehrzeilig

Softwarekomponente

Hersteller Text, mehrzeilig

Name Text


Infrastrukturelement 1:1-Referenz auf Infrastrukturelement


Plattform

(Aggregation)

Name Text


Tabellen 1:1-Referenz auf externe Anwendung (z.B. Excel)

Datenobjekte 1:n-Referenz auf ein oder mehrere Datenob-jekt/e

Datenspeicher


Name Text


Datenobjekte 1:n-Referenz auf ein oder mehrere Datenob-jekt/e

Schnittstelle


Name Text




Betriebskomponente

(Aggregation)


Name Text



Entwicklungstechnologie

Name Text



Kennzahl

(Referenz)

Referenzierte Führungs-grössen

1:n-Referenz auf eine oder mehrere Führungs-grösse/n der Prozessführung

Datenfluss

(zw. SW-Komponente/ Daten-

speicher und Schnittstelle)

wird erstellt mit

(zw. SW-Komponente und Ent-

wicklungstechnologie)

Modelltyp „Datenobjekte“


Name Text


Datenspeicher 1:1-Referenz auf Datenspeicher in Komponen-ten und Plattformen

Softwarekomponenten 1:n-Referenz auf eine oder mehrere SW-Komponent/en in Komponenten und Plattfor-men

Datenobjekt

Detaillierung 1:1-Referenz auf Datenstrukturmodell (UML-Klassendiagramm)

Name Text


Referenzierter Datenspei-cher

1:1-Referenz auf Datenspeicher in Komponen-ten und Plattformen

Datenspeicher

(Referenz)


ist zugeordnet

(von Datenobjekt zu Daten-objekt)

Modelltyp „Datenstrukturmodell“ (UML-Klassendiagramm)


Name Text



Attribute Text, mehrzeilig

Operationen Text, mehrzeilig

Klasse

Source Code (Doku) 1:1-Referenz auf externe Anwendung

Name Text

Beschreibung Text, mehrzeilig Aggregation


Kardinalität Text

Name Text

Beschreibung Text, mehrzeilig Komposition

Kardinalität Text

Name Text Generalisierung



Name Text


Richtung Enumeration

Assoziation


Kardinalität Text

A.5. Infrastrukturebene

Modelltyp „Infrastrukturmodell“ (Produktionsarchitektur)


Name Text



Typ Enumeration (Desktop, Server, Peripherie, …)

Softwarekomponenten 1:n-Referenz auf eine oder mehrere SW-Komponent/en


Plattformen 1:n-Referenz auf eine oder mehrere Plattform/en


Systemeigenschaften Tabelle

Hardwarekomponenten Tabelle


Standort Text

Name Text



Typ Enumeration (Switch, Router, Multiplexer, …)

Systemeigenschaften Tabelle


Standort Text

Name Text


ist verbunden mit

(von I/K-Element zu I/K-Element)

Kardinalität Text

A.6. IT-Services

Modelltyp „IT-Servicemodell“


Name Text



Service Level Requirements Tabelle

Infrastrukturelemente 1:n-Referenz auf ein oder mehrere Infrastruk-turelement/e

Softwarekomponenten 1:n-Referenz auf eine oder mehrere SW-Komponent/en

IT-Service-Prozesse 1:n-Referenz auf einen oder mehrere IT-Service-Prozess/e in (IT-)Prozesslandkarte

Dienstleister Tabelle


Servicekatalog 1:1-Referenz auf externe Anwendung

IT-Service (Aggregation)

(Prozess-)Leistung 1:1-Referenz auf Leistung in Leistungen (Pool) auf Organisationsebene

Name Text



Referenziertes Kommunika-tionselement

1:1-Referenz auf K-Element in Infrastruktur-modell


(Referenz)


Name Text




(Referenz)

Referenziertes Infrastruktur-element

1:1-Referenz auf I-Element in Infrastrukturmo-dell

Name Text



Softwarekomponente

Referenzierte Komponente 1:1-Referenz auf SW-Komponente in Kompo-nenten und Plattformen

Name Text



Referenzierter Prozess 1:1-Referenz auf Prozess in Prozesslandkarte auf Organisationsebene

Input Text, mehrzeilig

Output Text, mehrzeilig


IT-Service-Prozess

(Referenz)

IT-Dienstleister Text

Name Text


Service Levels Tabelle (Service-Zeiten, Verfügbarkeit, Per-formance, Support-Zeiten, …)

Name Text

Beschreibung Text, mehrzeilig definiert

(von SLA zu IT-Service)

Name Text


erzeugt/verwendet

(von IT-Service-Prozess zu IT-Service)

Anhang B: Darstellung einer Auswahl kommerziell verfügbarer Modellierungswerkzeuge 270

Anhang B: Darstellung einer Auswahl kommerziell

verfügbarer Modellierungswerkzeuge

Die Darstellung des jeweiligen Werkzeugs beinhaltet eine tabellarische Kurzcharakteristik des

Anbieters sowie eine Beschreibung des Funktionsumfangs und der Systemarchitektur. Die

Untersuchung basiert auf Anbieterhomepages sowie Produktbroschüren, Whitepaper, Präsen-

tationen oder Evaluierungsversionen der Lösungen, die im Internet frei zugänglich sind oder

auf Anfrage zur Verfügung gestellt wurden. Darüber hinaus wurden von Gartner veröffent-

lichte Berichte für die Auswahl und Bewertung der Werkzeuge herangezogen. Die Analyse

wurde im Mai 2005 abgeschlossen.

Um die einzelnen Werkzeuge einheitlich und konsistent beschreiben zu können, wird ein qua-

litativer Bezugsrahmen verwendet. Die Darstellung der Werkzeuge erfolgt anhand der folgen-

den Charakteristika:680

• Anbieter: Charakterisiert den Anbieter des Werkzeugs anhand von Eckdaten und be-

schreibt dessen Position im Markt.

• Unterstützte Methoden und Bezugsrahmen (Frameworks): Ein wichtiges Kriterium

für die Beurteilung eines Werkzeuges stellen die unterstützten (Modellierungs-)Methoden

(z.B. UML 2.0 oder BPMN 1.0) und/oder Bezugsrahmen dar. Diese legen fest, welche

Bereiche der Unternehmensarchitektur mit Hilfe des Werkzeuges abgebildet und welche

Analysen und Operationen auf den erstellten Modellen durchgeführt werden können.

• Modellierungsoberfläche: Die Modellierungsoberfläche dient dem Entwurf, der Ent-

wicklung, der Pflege sowie der Verarbeitung von Modellen der Unternehmensarchitektur.

In der Regel werden die Modelle in graphischer Form repräsentiert. Zusätzliche Informa-

tionen zu den Modellen können meist in textueller Form den graphischen Repräsentatio-

nen beigefügt werden. Die Qualität der Modellierungsoberfläche (z.B. Benutzerfreund-

lichkeit, Strukturierung, Übersichtlichkeit) ist ein wichtiges Kriterium für die Beurteilung

eines Werkzeugs.

• Erweiterbarkeit und Anpassbarkeit: Dieses Kriterium beurteilt, inwieweit das Werk-

zeug an die individuellen Anforderungen eines bestimmten Unternehmens angepasst wer-

den kann. Ein Werkzeug kann beispielsweise an ein unternehmensindividuelles Umfeld

angepasst werden, indem neue Methoden/Bezugsrahmen hinzugefügt oder bereits unter-

stützte Methoden/Bezugsrahmen modifiziert werden. Einige Werkzeuge verfügen zudem

über eine vereinfachte Programmieroberfläche, um die Funktionen und Mechanismen des

680 Vgl. Schekkerman (2004), S. 202-206.


Werkzeugs zu erweitern. Einige wenige ermöglichen darüber hinaus die Anpassung oder

Erweiterung der zugrunde liegenden Metamodelle.

• Repository und Systemarchitektur: Die meisten auf dem Markt verfügbaren Werkzeuge

verwenden ein Repository in Form einer relationalen Datenbank zur Speicherung der

entworfenen Modelle. Die Funktionen des Repositorys haben einen grossen Einfluss auf

die gesamte Funktionalität des Werkzeugs. Die Systemarchitektur eines Werkzeugs

beschreibt dessen softwaretechnische Struktur und Implementierung. In der Regel kann

zwischen einer „single user/single client“ oder einer „simple two-tier client/server“

Struktur unterschieden werden.

Casewise Corporate Modeler

Anbieter

Das Unternehmen Casewise wurde 1989 gegründet und hat ihren Firmensitz in Mount Laurel

(USA) sowie in London (UK). Ihr Werkzeug Corporate Modeler681 stammt ursprünglich aus

dem Bereich der Geschäftsprozessmodellierung und -analyse. Neuere Versionen des Tools

erfassen nicht mehr nur die Geschäftsprozesse, sondern auch andere Sachverhalte, wie Perso-

nen, welche die Geschäftsprozesse durchführen, Standorte, an denen die Prozesse auftreten,

sowie die verwendeten Applikationen, Daten und die eingesetzte Hardware. Laut Gartner liegt

die Stärke des Werkzeugs in seinen graphischen Fähigkeiten und seinen Möglichkeiten, die

IT-Architektur eines Unternehmens mit Artefakten der Geschäftsarchitektur zu verknüpfen.

Es bietet die Möglichkeit, Daten mit einer Reihe unterschiedlicher führender Design-

Werkzeuge auszutauschen. Um seine Position am Markt verbessern zu können, müsse Case-

wise vor allem die Administrationsfunktionalitäten sowie die Metamodellunterstützung erwei-

tern.682

Unterstützte Methoden/Bezugsrahmen

Der Corporate Modeler verwendet standardmässig ein proprietäres Framework, das auf dem

Zachman Framework basiert. Es bildet einen Ausgangspunkt für die Modellierung, indem es

dem Benutzer Vorlagen und erprobte Beispiele zur Verfügung stellt.

Modellierungsoberfläche

Der Corporate Modeler bietet eine weitgehend intuitive, individuell anpassbare Modellie-

rungsoberfläche. Die Objekte werden gut dargestellt und können beliebig in Grösse und Posi-

tion verändert und ausgerichtet werden. Semi-transparente Objekte ermöglichen die Modellie-

rung mehrerer Ebenen in Prozess- und Beziehungslandkarten. Eine Baumstruktur ermöglicht

die einfache Navigation entsprechend den unterschiedlichen Detaillierungsebenen. Ein Status-

fenster macht den Benutzer auf mögliche Konsistenzprobleme während der Modellierung

aufmerksam.

681 Vgl. im Folgenden Casewise (2005b), Casewise (2005a) und Casewise (2005c).

682 Vgl. James (2005b).


Erweiterbarkeit und Anpassbarkeit

Die Modellierungsobjekte, deren Eigenschaften sowie deren Beziehungen untereinander kön-

nen individuell angepasst werden. Dadurch ist das Repository leicht erweiterbar und es kann

ein angepasster Bezugsrahmen als Grundlage für die Modellierung mit dem Werkzeug ver-

wendet werden.

Repository und Systemarchitektur

Das Repository des Corporate Modeler wird durch eine skalierbare relationale Datenbank

realisiert. Diese speichert Diagrammobjekte mit zugeordneten Informationen sowie Modelle.

Einmal erstellte Diagrammobjekte (Ressourcen, Prozesse, Daten-Entitäten etc.) werden auto-

matisch im Repository gespeichert und können in jedem beliebigen Diagramm wieder ver-

wendet werden. Dadurch lassen sich Redundanzen vermeiden. In einer Multi-User-Umgebung

können die Benutzer auf die Objekte gemeinsam zugreifen. Das Repository ermöglicht das

kollaborative Arbeiten mehrerer Benutzer an zentral gespeicherten Modellen von unterschied-

lichen Standorten aus. Offline-Arbeiten an Modellen können mit dem Repository synchroni-

siert werden. Ein Zugriffs- und Rechtesystem sowie eine Reihe von Sicherheitsoptionen ver-

hindern den unbefugten Zugriff auf die in der zentralen Datenbank gespeicherten Modelle.

ARIS Design Platform

Anbieter

Die IDS Scheer AG wurde 1984 gegründet und hat ihren Hauptsitz in Saarbrücken. Weltweit

beschäftigt das Unternehmen 2200 Mitarbeitende. IDS Scheer ist ein Marktführer im Bereich

der Geschäftsprozessmodellierung und -analyse. Das von IDS Scheer angebotene Werkzeug

ARIS Process Platform683 ist sehr mächtig und bietet umfangreiche Funktionalitäten. Dadurch

ist es in der Anwendung sehr komplex. Aufgrund seiner Herkunft ist ARIS vor allem für die

Unternehmensmodellierung geeignet, bei der die Geschäftsprozesse im Mittelpunkt stehen.

Um seine Marktführerschaft im Bereich Unternehmensmodellierung ausbauen zu können,

müsse IDS Scheer laut Gartner die Komplexität seines Werkzeuges für weniger erfahrene

Unternehmen reduzieren, um diesen einen leichteren Einstieg zu ermöglichen.684

Unterstützte Ansätze

Die ARIS Design Platform bietet Unterstützung für das Zachman Framework sowie für die

Bezugsrahmen FEAF, TEAF und TOGAF (vgl. Abschnitt 3.3). Des Weiteren können ver-

schiedene Bezugsrahmen integriert verwendet werden.


Der ARIS Designer dient der Modellierung von Geschäftsprozessen. Das Werkzeug bietet

zahlreiche Navigationsmöglichkeiten, wodurch komplexe Sachverhalte in übersichtliche Teil-

bereiche gegliedert und grosse Modelle vollständig überblickt werden können. Die Organisa-

683 Vgl. Im Folgenden IDS-Scheer (2005a), IDS-Scheer (2005c) und IDS-Scheer (2005b).

684 Vgl. James (2005b).


tions-, Daten- und Funktionssicht ermöglichen unterschiedliche Blickwinkel auf die Ge-

schäftsprozesse. Der Modellierer erhält zudem Unterstützung durch Modellierungsfunktionen,

wie beispielsweise Mehrfachplatzierung von Objekten, benutzerdefinierte Objektdarstellung,

automatische Layoutgenerierung, mehrstufige Undo-Funktion, etc. Der Explorer bietet Funk-

tionen zum einfachen Erzeugen, Umbenennen, Verschieben und Löschen von Gruppen, Mo-

dellen und Objekten.


ARIS kann bis zu einem gewissen Grad individuell angepasst werden. Komplexere Anpas-

sungen müssen aber in der Regel durch Serviceleistungen von IDS Scheer oder dessen Part-

nern vorgenommen werden. Unternehmen können Modelltypen, Objekttypen, Symbole, Att-

ributtypen und Attributtypengruppen umbenennen. Für Objekttypen können eigene Symbole

angelegt werden. Ausserdem können bestimmte Attribute individuell konfiguriert und belie-

bigen Attributtypgruppen zugeordnet werden. Konfigurationsfilter dienen der Anpassung der

ARIS-Methode an die Anforderungen bestimmter Benutzer.


Der ARIS Web Designer ermöglicht den standort- und plattformunabhängigen Einsatz des

Designers. Die Drei-Ebenen-Architektur besteht aus einem browserfähigen Front-End, einem

Applikations- und einem Datenbankserver. Dadurch können die Unternehmensabläufe verteilt

und unter Zugriff auf ein zentrales Repository gestaltet werden. In einer Multi-User-

Umgebung können die Benutzer auf die Objekte gemeinsam zugreifen und diese bearbeiten.

Alfabet SITM

Anbieter

Die Alfabet Meta-Modeling AG mit Sitz in Berlin wurde im Jahre 1995 gegründet. Sie entwi-

ckelt und vertreibt Software-Lösungen und Services für das strategische Informationsmana-

gement über komplexe Geschäftsarchitekturen. Im August 2004 wurde Alfabet von Forrester

als Anbieter von Change-Management-Lösungen der dritten Generation identifiziert. Das von

der Firma Alfabet vertriebene Produkt SITM (Strategic IT Management)685 ist ein strategi-

sches Planungs-Werkzeug für das IT-Management, mit welchem sich die IT-Architektur einer

Unternehmung detailliert beschreiben lässt.


Alfabet verwendet in seiner Standardlösung das proprietäre Framework SITM (Strategic IT

Management). Dieses unterscheidet eine Geschäftsebene (Business Layer), Applikationsebene

(Application Layer) sowie eine physische Ebene (Physical Layer).

685 Vgl. im Folgenden Alfabet (2005b) und Alfabet (2005a).



Die Informationen im Repository können über ein Web-Interface visualisiert und bearbeitet

werden. Unterschiedliche Baumstrukturen ermöglichen die datenzentrierte, hierarchische Na-

vigation innerhalb des Repositorys. Rollenspezifische Darstellungen erleichtern den Benut-

zern die Suche nach den für sie wichtigen Informationen. Zusätzlich werden einfache und

erweiterte Funktionen für die Suche nach Objekten angeboten. Für die einzelnen Objekte des

Repositorys werden automatisch benutzerdefinierte Berichte generiert.


Grundsätzlich können die wesentlichen Elemente eines Unternehmens modelliert und inventa-

risiert werden. Das zugrunde liegende Datenmodell bietet zudem eine gewisse eingeschränkte

Flexibilität, wenn zusätzliche Attribute oder Elemente hinzugefügt werden sollen. Eine spe-

zielle Anpassung an das unternehmensindividuelle Umfeld muss in der Regel in Zusammen-

arbeit mit Alfabet erfolgen.


Das Repository (Logical IT Inventory) stellt die zentrale Komponente von Alfabets Lösung

dar. Es erfasst die aktuelle IT-Landschaft des Unternehmens und liefert Informationen, auf

deren Grundlage zukünftige IT-Projekte und Planungsaufgaben durchgeführt werden können.

In dem Repository können Informationen über Organisationsstrukturen, Prozesse, Applikatio-

nen, Infrastrukturkomponenten sowie Standorte einheitlich und konsistent inventarisiert wer-

den. Darüber hinaus ermöglicht es die Abbildung logischer Zusammenhänge und Abhängig-

keiten zwischen den IT-relevanten Objekten der Geschäftsarchitektur. Das Repository erlaubt

den Zugriff von mehreren Personen über das Internet. Änderungen können nur von Benutzern

mit entsprechenden Schreib- und Leserechten durchgeführt werden. Die Rechte können für

jedes Objekt separat vergeben werden.

Alfabet bietet, aufbauend auf dem Repository, weitere Module an, wie z.B. die Module „Ap-

plication Architecture Management“, „Business Demand Management“ und „Enterprise Ar-

chitecture Management“. Diese leisten Unterstützung bei der Planung von Projekten, indem

zukünftige Änderungen in der Applikations-, Technologie- und Prozesslandschaft mit Projek-

ten assoziiert werden können. Dadurch können Strategien entwickelt und deren Umsetzung

vorangetrieben und überwacht werden.

Das Werkzeug verwendet für die Umsetzung des Repository eine relationale Datenbank (MS

SQL-Server oder Oracle). Die Bewirtschaftung der Daten und Informationen kann über ein

Web-Interface oder einen Windows-Client erfolgen. Es bietet eine Rechte- und Zugriffsver-

waltung, durch die die Applikations- und Technologieverantwortlichen die Möglichkeit ha-

ben, die Daten dezentral zu pflegen und auf einem aktuellen Stand zu halten.


Adaptive Enterprise Architecture Manager

Anbieter

Adaptive ist ein vor allem in Nordamerika und Europa tätiger Software-Hersteller, dessen

Produkte das IT-Management bei der Verwaltung der architektur-relevanten Objekte und der

Planung und Koordination von Veränderungen unterstützen. Die von Adaptive angebotene

Produktpalette besteht aus den drei Modulen „Enterprise Architecture Manager“, „Business

Process Manager“ und „IT Portfolio Manager“.686 Diese können entweder einzeln oder zu-

sammen in einem Unternehmen eingesetzt werden.

Des Weiteren können Informationen mit einer Reihe von Modellierungswerkzeugen ausge-

tauscht werden. Das Werkzeug bietet allerdings nur einfache grafische Darstellungsmöglich-

keiten für Diagramme, z.B. basierend auf Microsoft Visio.687


Adaptive war an der Spezifikation des Federal Enterprise Architecture Framework (FEAF)

(vgl. Abschnitt 3.3.2) aktiv beteiligt. Folglich unterstützt auch der Enterprise Architecture

Manager dieses Framework. Das Referenzmodell von Adaptive, welches die Struktur der In-

formationen über eine Organisation beschreibt, gilt damit als Industriestandard für die Model-

lierung von Organisationsstrukturen bei US-amerikanischen Regierungsbehörden. FEAF kann

aber auch für die Abbildung anderer komplexer Organisationen verwendet werden.


Da es sich bei dem Produkt um ein reines Repository zur Speicherung von Unternehmensin-

formationen handelt, besitzt es keine eigene Modellierungsoberfläche. Stattdessen verwendet

es aber aktuelle Modellierungsstandards, um mit zahlreichen anderen Modellierungswerkzeu-

gen interagieren zu können, wie z.B. Microsoft Visio, IBM Rational Rose, Popkin System

Architect oder Sybase Power Designer. Daten können somit importiert, transformiert und in-

tegriert sowie letztendlich auch wieder exportiert werden.


Der Adaptive Designer bietet eine Reihe von Werkzeugen, die Adaptive für die Entwicklung

und Anpassung ihrer Produkte verwendet. Mit einer Lizenz für den Designer können aber

auch Unternehmen selbst die Produkte von Adaptive auf ihre individuellen Bedürfnisse an-

passen. Mit Hilfe des Designers ist es möglich, Adaptive anzupassen und zu erweitern, indem

Klassen, Attribute und Beziehungen im Metamodell hinzugefügt oder geändert werden. Da-

durch können weitere, für das Unternehmen wichtige Informationen in dem Repository ge-

speichert werden. Zusätzlich können neue oder alternative Sichten erstellt werden, um festzu-

legen, wie Informationen über das Unternehmen dargestellt werden sollen und wie zwischen

diesen navigiert werden kann.

686 Vgl. im Folgenden Adaptive (2005b), Adaptive (2005a), Adaptive (2005c) und Adaptive (2005d).

687 Vgl. James (2005b).



Die Stärke des Enterprise Architecture Manager ist das Repository, welches ursprünglich von

Unisys entwickelt wurde und von vielen Anwendern verwendet wird. Das Repository bietet

zahlreiche Administrationsfunktionen, wie beispielsweise die Möglichkeit, Diskussionsbei-

träge und Definitionen mit den Diagrammen abzuspeichern. Es unterstützt aktuelle Standards,

wie beispielsweise UML oder CWM. Diese können auch erweitert oder miteinander integriert

werden. Daneben ermöglicht es den Austausch von Modellen mit anderen Werkzeugen, die

den XML-basierten XMI-Standard unterstützen. Für die Speicherung der Daten verwendet

das Repository gängige relationale Datenbanken. Bei unterschiedlichen Versionen eines Ob-

jektes müssen lediglich die Änderungen gespeichert werden, wodurch sich die Zugriffszeit

auf die Datenbank verringert.

EAM ist ein rein web-basiertes Tool, welches lediglich einen Browser voraussetzt. Der Be-

nutzer kann über den Web-Browser alle wichtigen Funktionen nutzen, wie z.B. Modelle an-

zeigen und ändern. Die Modelle werden im Repository gespeichert. Mit Hilfe des Designers

können Sichten auf die Metamodelle verändert oder neu definiert werden.

Popkin Enterprise Architect

Anbieter

Die Firma Popkin wurde 1988 gegründet und hat ihren Firmensitz in New York.688 Popkin

bietet für die Unternehmensmodellierung das Werkzeug System Architect an.689 Das Werk-

zeug bietet eine grosse Palette an unterschiedlichen Diagrammtypen und ist damit vor allem

für Anwender interessant, die Wert auf gute Visualisierungsfähigkeiten legen. Diese werden

ergänzt durch umfangreiche, aber damit auch komplexe Funktionalitäten für die Erstellung

von Berichten und Präsentationen. System Architect bietet Im- und Exportfunktionen für

zahlreiche Design-Tools und kann Informationen in unterschiedlichen Formaten austauschen,

wie z.B. XML und CSV. Gartner prognostiziert, dass Popkin mit seinem Produkt mittelfristig

in einer Marktführerposition bleiben wird.690


Der Enterprise Architect von Popkin unterstützt bereits vordefinierte und von der Industrie

akzeptierte Frameworks, wie beispielsweise das Zachman Framework oder The Open Group

Architecture Framework (TOGAF). Unternehmen können aber auch ein auf ihre Anforderun-

gen angepasstes Framework verwenden. Das Werkzeug bietet zudem Unterstützung für die

objekt- und komponentenbasierte Modellierung mit UML sowie für die relationale Datenmo-

dellierung mit Entity-Relationship-Diagrammen.

688 Die Firma Popkin wurde am 18. April 2005 durch die Firma Telelogic aufgekauft.

689 Vgl. im Folgenden Popkin (2003) und Popkin (2004).

690 Vgl. James (2005b).



Die graphische Oberfläche bietet viele Möglichkeiten für das Zeichnen und Anzeigen von

Diagrammen, welche die Geschäftsarchitektur, die Applikationen oder das Datenbankdesign

repräsentieren. Der Browser des System Architect zeigt dem Benutzer die gespeicherten Dia-

gramme und Definitionen in einer Baumstruktur an. Diese können von dort aus direkt geöff-

net und editiert werden. Filterfunktionen erleichtern die Suche nach bestimmten Diagrammen

und Definitionen. Ein weiteres Hilfsmittel zur einfachen Navigation bietet der Framework-

Browser. Dieser ermöglicht die Visualisierung der erstellten und im Repository gespeicherten

Modelle und Artefakte entsprechend dem verwendeten Framework. Beim Anklicken einer

bestimmten Zelle des Frameworks wird eine Liste mit Diagrammen angezeigt, die dieser Zel-

le zugeordnet sind. Jeder Diagrammtyp besitzt eine eigene Toolbox, in der die methodenspe-

zifischen Symbole angezeigt werden.


Das zugrunde liegende Metamodell des System Architect kann für die Abbildung unterneh-

mensspezifischer Informationen angepasst werden. Das Metamodell kann um neue Dia-

grammtypen, Symbole, Definitionen sowie neue Attribute erweitert werden. Zusätzlich ist es

möglich, die Darstellung der in den Diagrammen abgebildeten Informationen anzupassen.


Alle Modelle, Diagramme und Definitionen, die mit dem System Architect erzeugt werden,

werden in einem zentralen, mehrbenutzerfähigen Repository, genannt Encyclopedia, abgelegt.

Das Repository basiert auf einer relationalen Datenbank (MS SQL Server). Der System Ar-

chitect wird in der Regel in einem Multiuser-Umfeld eingesetzt, kann aber auch als Stand-

alone-Installation auf einem Client verwendet werden.

BOC ADONIS

Anbieter

Die BOC Information Technologies Consulting GmbH wurde 1995 in Wien als Spin-off der

BPMS- (Business Process Management Systems-) Gruppe der Abteilung Knowledge Engi-

neering der Universität Wien gegründet. Ausgehend vom Stammsitz in Wien entstanden wei-

tere Landesgesellschaften in Berlin, Madrid, Dublin, Athen und Warschau. Die BOC ist ein

Beratungs- und Softwarehaus, welches sich auf Strategie-, Geschäftsprozess- und IT-

Management spezialisiert hat. Derzeit beschäftigt die BOC über 100 Mitarbeiter. Das Ge-

schäftsprozessmanagement-Werkzeug ADONIS unterstützt die Modellierung, Analyse, Simu-

lation und Evaluation von Geschäftsprozessen.


ADONIS stellt standardmässig die ADONIS-Standard-Methode zur Verfügung. Diese ist eine

universelle Modellierungstechnik zur Abbildung von Abläufen und Organisationsstrukturen.

Die Methode ist branchenunabhängig für die Modellierung, Analyse, Dokumentation und


Optimierung einsetzbar. Die zur Verfügung stehenden Modelltypen ermöglichen eine inte-

grierte und konsistente Darstellung von strategischen bis hin zu umsetzungsrelevanten Infor-

mationen. ADONIS bietet eine Vielzahl weiterer fertig ausgearbeiteter Methoden, wie z.B.

LOVEM, EPK, UML 2.0 und BPMN.


Die in ADONIS erstellten Modelle und Objekte besitzen Attribute, in denen qualitative und

quantitative Informationen wie Beschreibungen, Kommentare, Zeiten, Kosten, Referenzen auf

andere Modelle oder externe Dokumente gespeichert werden. Der Modelleditor ist intuitiv zu

bedienen und bietet umfangreiche Funktionalitäten. Er bietet beispielsweise die Möglichkeit

schnell und einfach zwischen den einzelnen Modellen zu navigieren, externe Grafiken einzu-

fügen, unterschiedliche Ansichtsmodi auszuwählen und Grafiken in einer Vielzahl von Datei-

formaten zu exportieren. Der Explorer ist ein Sichtfenster, in dem die ADONIS-Modelle und

deren Statusinformation in einer Baumstruktur angezeigt werden. Er ermöglicht den Zugriff

auf einzelne Funktionen und Sichten.


ADONIS basiert auf einem methodenunabhängigen Metamodellierungsansatz. Dieser ermög-

licht eine leichte Anpassung ohne Programmieraufwand sowohl im Bereich Modellierungs-

techniken als auch bei den Modell auswertenden Funktionen. Aufgrund der Offenheit und

Methodenunabhängigkeit lassen sich unterschiedliche Aspekte eines Unternehmens abbilden,

wie z.B. Geschäftsprozesse, Organisationsstrukturen, IT-Systeme und Qualitätssicherungs-

massnahmen.


Für das Repository kann ein gängiges relationales Datenbanksystem verwendet werden.

ADONIS kann entweder als Stand-alone-Installation oder in einer Client/Server-Architektur

verwendet werden.

Anhang C: Ansprechpartner bei der Winterthur Group 279

Anhang C: Ansprechpartner bei der Winterthur Group

Die Fallstudie wurde auf Basis von Interviews und Dokumentenanalysen zusammengestellt.

Vertiefende Nachbesprechungen der Interviews wurden telefonisch oder per E-Mail

durchgeführt. Folgende Ansprechpartner waren an der Erhebung der Fallstudie beteiligt:

Dario Bee

MBA, Head Business Analysis Claims

Winterthur Versicherungen

General Guisan-Str. 40

CH-8401 Winterthur

[email protected]

www.winterthur.ch

Urs Bernet

IT-Architekt



CH-8401 Winterthur

[email protected]

www.winterthur.ch

Fiorenzo Maletta

IT Architect, Head Architecture Coaching & Information Architecture



CH-8401 Winterthur

[email protected]

www.winterthur.ch

Literatur 281

Literatur

Adams (2005) Adams, P.: Poll Shows Integration Increasing Among IT Asset Management Tools,

http://www.gartner.com (Zugriff: 02.05.2006). Adaptive (2005a) Adaptive: Business Process Manager, http://www.adaptive.com/links/papers.html

(Zugriff: 04.05.2005). Adaptive (2005b) Adaptive: Enterprise Architecture Manager,

http://www.adaptive.com/links/papers.html (Zugriff: 04.05.2005). Adaptive (2005c) Adaptive: IT Portfolio Manager, http://www.adaptive.com/links/papers.html (Zugriff:

04.05.2005). Adaptive (2005d) Adaptive: White Paper – The Road to Enterprise Architecture,

http://www.adaptive.com/links/papers.html (Zugriff: 04.05.2005). Alfabet (2005a) Alfabet: White Paper – Alfabet`s Logical IT Inventory,

http://www.alfabet.de/alfabet_e/whitepapers.html (Zugriff: 04.05.2005). Alfabet (2005b) Alfabet: White Paper – Planning IT from demand to budget,

http://www.alfabet.de/alfabet_e/whitepapers.html (Zugriff: 04.05.2005). Alpar et al. (2005) Alpar, P., Grob, H.-L., Weimann, P., Winter, R.: Anwendungsorientierte Wirtschafts-

informatik, 4. Aufl., Vieweg, Braunschweig/Wiesbaden, 2005. Anaya/Ortiz (2005) Anaya, V., Ortiz, A.: How enterprise architectures can support integration, in: Proceed-

ings of the First International Workshop on Interoperability of Heterogeneous Infor-mation Systems (IHIS), Oldenburg, 2005, S. 25-30.

Arsanjani (2004) Arsanjani, A.: Service-oriented modeling and architecture – How to identify, specify,

and realize services for your SOA, http://www-128.ibm.com/developerworks/webservices/library/ws-soa-design1/ (Zugriff: 21.04.2006).

Aziz et al. (2005) Aziz, S., Obitz, T., Modi, R., Sarkar, S.: Enterprise Architecture – A Governance

Framework – Part I – Embedding Architecture into the Organization, Infosys, 2005.

Literatur 282

Balzert (2000) Balzert, H.: Lehrbuch der Software-Technik, Software-Entwicklung, 2. Aufl., Spekt-

rum Akademischer Verlag, Heidelberg/Berlin, 2000. Baumöl et al. (2005) Baumöl, U., Österle, H., Winter, R.: Business Engineering in der Praxis, in: Österle,

H., Winter, R. (Hrsg.): Business Engineering in der Praxis, Springer, Heidelberg, 2005, S. 1-13.

Becker (2004a) Becker, J.: Referenzmodellierung - Aktuelle Methoden und Modelle, in: Wirtschafts-

informatik, 46(2004)5, S. 325-326. Becker (2004b) Becker, J.: Referenzmodellierung – Aktuelle Methoden und Modelle, in: Wirtschafts-

informatik, 46(2004)5, S. 325-326. Becker et al. (2002a) Becker, J., Algermissen, L., Delfmann, P., Knackstedt, R.: Referenzmodellierung, in:

Das Wirtschaftsstudium, 30(2002)11, S. 1294-1298. Becker/Delfmann (2004) Becker, J., Delfmann, P.: Referenzmodellierung – Grundlagen, Techniken und domä-

nenbezogene Anwendungen, Physica, Heidelberg, 2004. Becker et al. (2002b) Becker, J., Delfmann, P., Knackstedt, R., Kuropka, D.: Konfigurative Referenzmodel-

lierung, in: Becker, J., Knackstedt, R. (Hrsg.): Wissensmanagement mit Referenzmo-dellen. Konzepte für die Anwendungssystem- und Organisationsgestaltung, Physica, Heidelberg, 2002, S. 25-144.

Becker et al. (2001) Becker, J., Holten, R., Knackstedt, R., Neumann, S.: Konstruktion von Methodiken –

Vorschläge für eine begriffliche Grundlegung und domänenspezifische Anwendungs-beispiele, Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität Münster, Münster, 2001.

Becker et al. (2003) Becker, J., Holten, R., Knackstedt, R., Niehaves, B.: Forschungsmethodische Positio-

nierung in der Wirtschaftsinformatik – Epistemologische, ontologische und linguisti-sche Leitfragen, Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität Müns-ter, Münster, 2003.

Bernet (2005) Bernet, U.: WGR Enterprise Architecture Metamodel, Winterthur Group, Winterthur,

2005. Blechar (2005) Blechar, M.: Magic Quadrant for OOA&D Tools, http://www.gartner.com (Zugriff:

28.04.2006).

Literatur 283

Blechar/Sinur (2006) Blechar, M., Sinur, J.: Magic Quadrant for Business Process Analysis Tools,

http://www.gartner.com (Zugriff: 28.04.2006). Böh/Meyer (2004) Böh, A., Meyer, M.: IT-Balanced Scorecard – Ein Ansatz zur strategischen Ausrich-

tung der IT, in: Zarnekow, R., Brenner, W., Grohmann, H. (Hrsg.): Informationsma-nagement – Konzepte und Strategien für die Praxis, 2004, S. 105-124.

Böhmann et al. (2002) Böhmann, T., Junginger, M., Krcmar, H.: Modular Service Architectures: A Concept

and Method for Engineering IT Services, in: Proceedings of 36th Hawaii International Conference on System Sciences (HICSS'03), 2002.

BPMI (2002) BPMI: Business Process Management Notation (BPMN) 1.0 Specification, (Zugriff:

18.07.2005). Braun et al. (2004) Braun, C., Hafner, M., Wortmann, F.: Methodenkonstruktion als wissenschaftlicher

Erkenntnisansatz, Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen, 2004.

Braun/Winter (2005a) Braun, C., Winter, R.: Classification of Outsourcing Phenomena in Financial Services,

in: Proceedings of the 13th European Conference on Information Systems, Regens-burg, 2005.

Braun/Winter (2005b) Braun, C., Winter, R.: A Comprehensive Enterprise Architecture Metamodel and Its

Implementation Using a Metamodeling Platform, in: Proceedings of the Workshop on Enterprise Modelling and Information Systems Architectures, Klagenfurt, 2005, S. 64-79.

Braun et al. (2005) Braun, C., Wortmann, F., Hafner, M., Winter, R.: Method Construction – A Core Ap-

proach to Organizational Engineering, in: Proceedings of the 2005 ACM Symposium on Applied Computing (SAC), Santa Fe, 2005, S. 1295-1299.

Brecht (2002) Brecht, L.: Process Leadership – Methode des informationssystemgestützten Prozess-

management, Verlag Dr. Kovac, Hamburg, 2002. Brenner (1995) Brenner, C.: Techniken und Metamodell des Business Engineering, Dissertation der

Universität St. Gallen, St. Gallen, 1995. Brenner (1994) Brenner, W.: Grundzüge des Informationsmanagements, Springer, Berlin, 1994.

Literatur 284

Brinkkemper (1996) Brinkkemper, S.: Method engineering – engineering of information systems develop-

ment methods and tools, in: Information and Software Technology, 38(1996)4, S. 275-280.

Buhl et al. (1999) Buhl, H. U., Visser, V., Will, A.: Virtualisierung des Bankgeschäfts, in: Wirtschaftsin-

formatik, 41(1999)2, S. 116-123. Bundesbank (2004) Bundesbank: Internationale Konvergenz der Kapitalmessung und Eigenkapitalanfor-

derungen, http://www.bundesbank.de/download/bankenaufsicht/pdf/eigenkapital-empfehlung_de.pdf (Zugriff: 04.04.2006).

Casewise (2005a) Casewise: Casewise Modeler Suite Brochure,

http://www.casewise.com/downloads/presentations/ (Zugriff: 04.06.2005). Casewise (2005b) Casewise: Corporate Modeler, http://www.casewise.com/products/corporate-

modeler/index.php (Zugriff: 04.06.2005). Casewise (2005c) Casewise: Corporate Modeler 10 Datasheet,

http://www.casewise.com/downloads/presentations/ (Zugriff: 04.06.2005). Cheesman/Daniels (2000) Cheesman, J., Daniels, J.: UML Components – A Simple Process for Specifying

Component-Based Software, Addison-Wesley, 2000. Chen (1976) Chen, P. P.-S.: The Entity-Relationship Model – Toward a Unified View of Data, in:

ACM Transactions on Database Systems, 1(1976)1, S. 9-36. Choinowski et al. (2003) Choinowski, S., Leist, S., Winter, R., Zellner, G.: BAI Methode, Arbeitsbericht, Institut

für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen, 2003. CIO-Council (1996) CIO-Council: Clinger-Cohen-Act, http://www.defenselink.mil/nii/org/cio/doc/CCA-

Book-Final.pdf (Zugriff: 04.04.2006). Coldewey (2000) Coldewey, J.: Produktsysteme im Versicherungsbereich, in: Proceedings of the Object

Oriented Programming Conference (OOP2000), München, 2000. Commerce (2000) Commerce, O. o. G.: IT Infrastructure Library, The Stationary Office, London, 2000.

Literatur 285

Dan et al. (2004) Dan, A., Davis, D., Kearney, R., Keller, A., King, R., Kuebler, D., Ludwig, H., Polan,

M., Spreitzer, M., Youssef, A.: Web services on demand – WSLA-driven automated management, in: IBM Systems Journal, Special Issue on Utility Computing, 43(2004)1, S. 136-158.

Dinner/Kolber (2005) Dinner, W., Kolber, A.: Zachman, Basel II and Sarbanes-Oxley, in: DM Review, Ok-

tober, 2005, S. 43-47. Dinter/Bucher (2006) Dinter, B., Bucher, T.: Business Performance Management, in: Chamoni, P., Glu-

chowski, P. (Hrsg.): Analytische Informationssysteme – Business Intelligence-Technologien und -Anwendungen, Springer, Berlin et al., 2006, S. 23-50.

FEA (1999) FEA: Federal Enterprise Architecture Framework,

https://secure.cio.noaa.gov/hpcc/docita/files/federal_enterprise_arch_framework.pdf (Zugriff: 04.06.2005).

FEA (2001) FEA: A Guide to Federal Enterprise Architecture,

http://www.eaframeworks.com/FEAF/a_practical_guide_to_federal_enterprise_archi-tecture.pdf (Zugriff: 04.06.2005).

Ferraiolo et al. (2001) Ferraiolo, D., Sandhu, R., Gavrila, S., Kuhn, R. D., Chandramouli, R.: Proposed

NIST Standard for Role-Based Access Control, in: ACM Transactions on Information and System Security (TISSEC), 4(2001)3, S. 224-274.

Ferstl/Sinz (1995) Ferstl, O. K., Sinz, E. J.: Der Ansatz des Semantischen Objektmodells (SOM) zur

Modellierung von Geschäftsprozessen, in: Wirtschaftsinformatik, 37(1995)3, S. 209-220.

Ferstl/Sinz (1998) Ferstl, O. K., Sinz, E. J.: Grundlagen der Wirtschaftsinformatik, 3. Aufl., Oldenbourg,

München, 1998. Ferstl/Sinz (2001) Ferstl, O. K., Sinz, E. J.: Grundlagen der Wirtschaftsinformatik, Oldenbourg, Mün-

chen, 2001. Fettke/Loos (2002) Fettke, P., Loos, P.: Methoden zur Wiederverwendung von Referenzmodellen – Über-

sicht und Taxonomie, in: Tagungsband zur 6. Fachtagung Referenzmodellierung 2002 (RefMod 2002), Nürnberg, 2002, S. 9-33.

Literatur 286

Fettke/Loos (2003) Fettke, P., Loos, P.: Ontological evaluation of reference models using the bunge-

wand-weber model, in: Proceedings of the Ninth Americas Conference on Information Systems, Atlanta, 2003, S. 2944-2955.

Fettke/Loos (2004a) Fettke, P., Loos, P.: Entwicklung eines Bezugsrahmens zur Evaluierung von Refe-

renzmodellen – Langfassung eines Beitrages, Arbeitsbericht, Information Systems & Management, Universität Mainz, Mainz, 2004.

Fettke/Loos (2004b) Fettke, P., Loos, P.: Referenzmodellierungsforschung, in: Wirtschaftsinformatik,

46(2004)5, S. 331-340. Firesmith et al. (1998) Firesmith, D., Henderson-Sellers, B., Graham, I.: Open Modeling Language Refer-

ence Manual, SIGS Books, 1998. Frank (1994) Frank, U.: Multiperspektivische Unternehmensmodellierung – Theoretischer Hinter-

grund und Entwurf einer objektorientierten Entwicklungsumgebung, Oldenbourg, München, 1994.

Frank (1995) Frank, U.: MEMO – Objektorientierte Unternehmensmodellierung zum gemeinsamen

Entwurf optimierter Geschäftsprozesse und hochintegrierter Anwendungssysteme, in: Objekt-Spektrum, Nr. 6, 1995, S. 43-47.

Frank (1998a) Frank, U.: The MEMO Meta-Metamodel, Arbeitsbericht, Institut für Wirtschaftsin-

formatik, Universität Koblenz-Landau, Koblenz, 1998. Frank (1998b) Frank, U.: The MEMO Object Modeling Language (MEMO-OML), Arbeitsbericht,

Institut für Wirtschaftsinformatik, Universität Koblenz-Landau, Koblenz, 1998. Frank (1999a) Frank, U.: Applying the MEMO-OML – Guidelines and Examples, Arbeitsbericht,

Institut für Wirtschaftsinformatik, Universität Koblenz-Landau, Koblenz, 1999. Frank (1999b) Frank, U.: Eine Architektur zur Spezifikation von Sprachen und Werkzeugen für die

Unternehmensmodellierung, in: Proceedings der Fachtagung Modellierung betriebli-cher Informationssysteme (MobIS), Bamberg, 1999, S. 154-169.

Frank (2002) Frank, U.: Multi-Perspective Enterprise Modeling (MEMO) – Conceptual Framework

and Modeling Languages, in: Proceedings of the 35th Hawaii International Conference on System Sciences (HICSS-35), Honolulu, 2002, S. 72.

Literatur 287

Frank/Van Laak (2003) Frank, U., Van Laak, B.: Anforderungen an Sprachen zur Modellierung von Ge-

schäftsprozessen, Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität Ko-blenz-Landau, Koblenz, 2003.

Frese (1995) Frese, E.: Grundlagen der Organisation. Konzept – Prinzipien – Strukturen, 6. Aufl.,

Gabler, Wiesbaden, 1995. Frie/Auth (2001) Frie, T., Auth, G.: Kopplung operativer (horizontaler) Applikationen mit dem Data

Warehouse, Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen, 2001.

Geissler (2004) Geissler, C.: Compliance Management?, in: Harvard Business Manager, Nr. 2, 2004,

S. 17. Grant (1998) Grant, R. M.: Contemporary strategy analysis – Concepts, techniques, applications. A

guide for instructors, Blackwell Publishers, 1998. Greenfield/Short (2003) Greenfield, J., Short, K.: Software factories – Assembling applications with patterns,

models, frameworks and tools, in: Companion of the 18th annual ACM SIGPLAN conference on object-oriented programming, systems, languages, and applications, Anaheim, 2003, S. 16-27.

Greiffenberg (2003) Greiffenberg, S.: Methoden als Theorien der Wirtschaftsinformatik, in: Uhr, W., Ess-

wein, W., Schoop, E. (Hrsg.): Wirtschaftsinformatik 2003 Band II, Physica-Verlag, Heidelberg, 2003, S. 947-968.

Gutzwiller (1994) Gutzwiller, T.: Das CC RIM-Referenzmodell für den Entwurf von betrieblichen,

transaktionsorientierten Informationssystemen, Physica, Heidelberg, 1994. Hafner (2005) Hafner, M.: Entwicklung einer Methode für das Management der Informationssys-

temarchitektur im Unternehmen, Dissertation der Universität St. Gallen, St. Gallen, 2005.

Hafner et al. (2006) Hafner, M., Schelp, J., Winter, R.: Berücksichtigung des Architekturmanagements in

serviceorientierten IT-Managementkonzepten am Beispiel von ITIL, in: Schelp, J., Winter, R. (Hrsg.): Integrationsmanagement, Springer, Berlin et al., 2006, S. 99-121.

Literatur 288

Hahn (1997) Hahn, D.: US-amerikanische Konzepte strategischer Unternehmensführung, in: Hahn,

D., Taylor, B. (Hrsg.): Strategische Unternehmensplanung – strategische Unterneh-mensführung – Stand und Entwicklungstendenzen, Physica, Heidelberg, 1997, S. 144-164.

Hammer/Champy (1993) Hammer, M., Champy, J.: Reengineering the Corporation – A Manifest for Business

Revolution, Allen & Unwin, 1993. Harengel (2000) Harengel, J.: Die Balanced Scorecard als Instrument des Banken-Controlling, Disser-

tation der Universität Konstanz, Konstanz, 2000. Hegering et al. (1999) Hegering, H.-G., Abeck, S., Neumair, B.: Integrated Management of Networked Sys-

tems – Concepts, Architectures, and Their Operational Application, Morgan Kauf-mann, 1999.

Heinrich (2000) Heinrich, B.: Dimensionen zur Beschreibung eines Geschäftsmodells für Kreditinsti-

tute im Bereich Privatkunden, Arbeitsbericht, Institut für Wirtschaftsinformatik, Uni-versität St. Gallen, St. Gallen, 2000.

Heinrich (2002a) Heinrich, B.: Das Geschäftsmodell als Instrument zur Positionierung des Unterneh-

mens, in: Leist, S., Winter, R. (Hrsg.): Retail Banking im Informationszeitalter – In-tegrierte Gestaltung der Geschäfts-, Prozess- und Applikationsebene, Springer, Berlin et al., 2002, S. 53-72.

Heinrich (2002b) Heinrich, B.: Die konzeptionelle Gestaltung des Multichannel-Vertriebs anhand von

Kundenbedürfnissen, in: Leist, S., Winter, R. (Hrsg.): Retail Banking im Informati-onszeitalter – Integrierte Gestaltung der Geschäfts-, Prozess- und Applikationsebene, Springer, Berlin et al., 2002, S. 73-92.

Heinrich/Winter (2004) Heinrich, B., Winter, R.: A Strategy Modelling Technique for Financial Services, in:

Proceedings of the 12th European Conference on Information Systems, Turku, 2004. Heinrich (1993) Heinrich, L. J.: Wirtschaftsinformatik – Einführung und Grundlegung, Oldenbourg,

München, 1993. Heinrich (2002c) Heinrich, L. J.: Informationsmanagement – Planung, Überwachung und Steuerung der

Informationsinfrastruktur, 7. Aufl., Oldenbourg, München, 2002.

Literatur 289

Henderson/Thomas (1992) Henderson, J. C., Thomas, J.: Aligning Business and Information Technology Do-

mains – Strategic Planning in Hospitals, in: Hospital and Health Services Administra-tive, 37(1992)1, S. 71-87.

Henderson/Venkatraman (1993) Henderson, J. C., Venkatraman, N.: Strategic alignment – Leveraging information

technology for transforming organizations, in: IBM Systems Journal, 32(1993)1, S. 4-16.

Hess (1996) Hess, T.: Entwurf betrieblicher Prozesse, Dissertation der Universität St. Gallen, St.

Gallen, 1996. Hess/Brecht (1996) Hess, T., Brecht, L.: State of the Art des Business Process Redesign – Darstellung und

Vergleich bestehender Methoden, 2. Aufl., Gabler, Wiesbaden, 1996. Hesse et al. (1992) Hesse, W., Merbeth, G., Frölich, R.: Software-Entwicklung, Vorgehensmodelle, Pro-

jektführung, Produktverwaltung, in: Handbuch der Informatik, Oldenbourg-Verlag, München, 1992.

Hevner et al. (2004) Hevner, A. R., March, S. T., Park, J.: Design Science in Information Systems Re-

search, in: MIS Quarterly, 28(2004)1, S. 75-105. Heym (1993) Heym, M.: Methoden-Engineering – Spezifikation und Integration von Entwicklungs-

methoden für Informationssysteme, Rosch-Buch, Hallstadt, 1993. Hochstein/Hunziker (2003) Hochstein, A., Hunziker, A.: Serviceorientierte Referenzmodelle des IT-Managements,

in: HMD – Praxis der Wirtschaftsinformatik, 40(2003)232, S. 46-56. Hochstein et al. (2004) Hochstein, A., Zarnekow, R., Brenner, W.: Serviceorientiertes IT-Management nach

ITIL – Möglichkeiten und Grenzen, in: HMD – Praxis Der Wirtschaftsinformatik, 41(2004)239, S. 68-76.

Holten et al. (1997) Holten, R., Striemer, R., Weske, M.: Ansätze zur Entwicklung von Workflow-basierten

Anwendungssystemen, Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität Münster, Münster, 1997.

Horváth&Partners (2005) Horváth&Partners: Balanced-Scorecard-Studie 2005, http://www.horvath-

partners.com/hp3/1709153/2336048.html (Zugriff: 24.02.2006).

Literatur 290

IBM-Corporation (1984) IBM-Corporation: Business Systems Planning – Information Systems Planning Guide,

IBM-Form GE20-0527-4, 4. Aufl., Atlanta, 1984. IDS-Scheer (2005a) IDS-Scheer: ARIS Process Platform, http://www.ids-

scheer.com/germany/products/23019 (Zugriff: 04.06.2005). IDS-Scheer (2005b) IDS-Scheer: Präsentation ARIS Design Platform, http://www.ids-

scheer.com/germany/products/aris_design_platform/25646 (Zugriff: 04.05.2005). IDS-Scheer (2005c) IDS-Scheer: White Paper ARIS Design Platform, http://www.ids-

scheer.com/germany/products/aris_design_platform/29482 (Zugriff: 04.06.2005). IEEE (2000) IEEE: IEEE Recommended Practice for Architectural Description of Software Inten-

sive Systems, IEEE Std 1471-2000, 2000. IFEAD (2004) IFEAD: Trends in Enterprise Architecture 2004: How are Organisations Progressing?,

http://www.enterprise-architecture.info/Images/EA%20Survey/EA%20Survey%202004%20IFEAD.PDF (Zugriff: 04.05.2005).

IFEAD (2005) IFEAD: Trends in Enterprise Architecture 2005 – How are Organisations Progress-

ing?, http://www.enterprise-architec-ture.info/Images/EA%20Survey/Enterprise%20Architecture%20Survey%202005%20IFEAD%20v10.pdf (Zugriff: 20.02.2006).

IFEAD (2006) IFEAD: Enterprise Architecture Tools Overview 2006, http://www.enterprise-

architecture.info/EA_Tools.htm (Zugriff: 08.06.2006). IMG (1997) IMG: PROMET BPR – Methodenhandbuch für den Entwurf von Geschäftsprozessen,

Version 2.0, Information Management Group, St. Gallen, 1997. IMG (1999) IMG: PROMET STP – Methodenhandbuch für die System- und Technologieplanung,

Release 1.0, Information Management Group, St. Gallen, 1999. Infosys (2005) Infosys: Infosys Enterprise Architecture Survey,

http://www.infosys.com/services/systemintegration/ea-survey/ea-survey-executive-summary.pdf (Zugriff: 05.05.2006).

Literatur 291

Jacobson et al. (1994) Jacobson, I., Ericsson, M., Jacobson, A.: The Object Advantage – Business Process

Reengineering With Object Technology, Addison-Wesley, Wokingham, 1994. James (2004a) James, G.: Architecture Frameworks – Tool Support, www.gartner.com (Zugriff:

19.04.2005). James (2004b) James, G.: Market Scope – Enterprise Architecture Tool Market, www.gartner.com

(Zugriff: 19.04.2005). James (2005a) James, G.: Magic Quadrant for Enterprise Architecture Tools, www.gartner.com

(Zugriff: 19.04.2005). James (2005b) James, G.: Vendor Details for the 4Q04 Enterprise Architecture Tool Magic Quadrant,

www.gartner.com (Zugriff: 19.04.2005). Jeckle et al. (2004a) Jeckle, M., Rupp, C., Hahn, J., Zenger, B., Queins, S.: UML 2.0 – Evolution oder De-

generation?, in: Objekt Spektrum, Nr. 3, 2004, S. 12-19. Jeckle et al. (2004b) Jeckle, M., Rupp, C., Hahn, J., Zengler, B., Queins, S.: UML 2 glasklar, Hanser, Mün-

chen, 2004. Jonkers et al. (2004) Jonkers, H., Lankhorst, M., van Buuren, R., Hoppenbrouwers, S., Bonsangue, M., van

der Torre, L.: Concepts for Modelling Enterprise Architectures, in: International Jour-nal of Cooperative Information Systems, 13(2004)3, S. 257-287.

Jonscher/Dittrich (1994) Jonscher, D., Dittrich, K.: Realisierung von Sicherheitsstrategien mit Hilfe flexibler

Zugriffskontrollmechanismen, in: Bauknecht, K., Dittrich, K. (Hrsg.): Sicherheit in In-formationssystemen, vdf, Zürich, 1994, S. 23-52.

Jung (2004) Jung, E.: Ein unternehmensweites IT-Architekturmodell als erfolgreiches Bindeglied

zwischen der Unternehmensstrategie und dem operativen Bankgeschäft, in: Wirt-schaftsinformatik, 46(2004)4, S. 313-314.

Junginger et al. (2000) Junginger, S., Kühn, H., Strobl, R., Karagiannis, D.: Ein Geschäftsprozessmanage-

ment-Werkzeug der nächsten Generation, in: Wirtschaftsinformatik, 42(2000)5, S. 392-401.

Kaiser (2000) Kaiser, T. M.: Methode zur Konzeption von Intranets, Dissertation der Universität St.

Gallen, St. Gallen, 2000.

Literatur 292

Kalakota/Robinson (2001) Kalakota, R., Robinson, M.: e-Business 2.0 – Roadmap for success, 2. Aufl., Addison

Wesley, Boston et al., 2001. Kaplan/Norton (1996) Kaplan, R. S., Norton, D. P.: Using the Balanced Scorecard as a Strategic Manage-

ment System, in: Harvard Business Review, January, 1996, S. 75-85. Kaplan/Norton (1997) Kaplan, R. S., Norton, D. P.: Balanced Scorecard, Schäffer-Poeschel, Stuttgart, 1997. Karagiannis/Kühn (2002) Karagiannis, D., Kühn, H.: Metamodelling Platforms, in: Proceedings of the Third

International Conference on Electronic Commerce and Web Technologies (EC-Web), Aix-en-Provence, 2002, S. 182-196.

Keller et al. (1992) Keller, G., Nüttgens, M., Scheer, A.-W.: Semantische Prozessmodellierung auf der

Grundlage „Ereignisgesteuerter Prozessketten (EPK)“, Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität des Saarlandes, Saarbrücken, 1992.

Kelly/Smolander (1996) Kelly, S., Smolander, K.: Evolution and issues in metaCASE, in: Information and

Software Technology, 38(1996)4, S. 161-266. Kern et al. (2002) Kern, A., Kuhlmann, M., Schaad, A., Moffett, J. D.: Observations on the role life-cycle

in the context of enterprise security management, in: Proceedings of the Seventh ACM Symposium on Access Control Models and Technologies, New York, 2002, S. 43-51.

Kitchenham et al. (1995) Kitchenham, B., Pickard, L., Pfleeger, S. L.: Case Studies for Method and Tool

Evaluation, in: IEEE Software, 12(1995)4, S. 52-62. König et al. (1996) König, W., Heinzl, A., Rumpf, M., von Poblotzki, A.: Zur Entwicklung der For-

schungsmethoden und Theoriekerne der Wirtschaftsinformatik in den nächsten zehn Jahren – Eine kombinierte Delphi- und AHP-Untersuchung, in: Heilmann, H., Hein-rich, L. J., Roithmayer, F. (Hrsg.): Information Engineering, München et al., 1996, S. 36-65.

Krcmar (1990) Krcmar, H.: Bedeutung und Ziele von Informationssystemarchitekturen, in: Wirt-

schaftsinformatik, 32(1990)5, S. 395-402. Krcmar (2003) Krcmar, H.: Informationsmanagement, 3. Aufl., Springer, Berlin, 2003. Kremer (2004) Kremer, S.: Information Retrieval in Portalen – Gestaltungselemente, Praxisbeispiele

und Methodenvorschlag, Dissertation der Universität St. Gallen, St. Gallen, 2004.

Literatur 293

Kühn/Bayer (2004) Kühn, H., Bayer, F.: Integration Approaches for Metamodelling Platforms, in: Pro-

ceedings of the Workshop on "Enterprise Modeling and Ontology – Ingredients for In-teroperability", in Conjunction with the Fifth International Conference on Practical Aspects of Knowledge Management (PAKM 2004), Vienna, 2004, S. 51-59.

Kühn et al. (2003) Kühn, H., Bayer, F., Junginger, S., Karagiannis, D.: Enterprise Model Integration, in:

Proceedings of the Fourth International Conference on Electronic Commerce and Web Technologies (EC-Web), Prague, 2003, S. 379-392.

Kühn et al. (1999) Kühn, H., Junginger, S., Petersen, C.: Re-Use in Business Process Management based

on Metamodeling and Model Views, in: Proceedings of the Eighth International Con-ference on Human-Computer Interaction, Munich, 1999, S. 173-174.

Kühn/Karagiannis (2005) Kühn, H., Karagiannis, D.: Strategie-, Prozess- und IT-Management – Ein Pattern-

orientierter Integrationsansatz, in: Ferstl, O. K., Sinz, E. J., Eckert, S., Isselhorts, T. (Hrsg.): Wirtschaftsinformatik 2005, Physica, Heidelberg, 2005, S. 1483-1502.

Kühn et al. (2004) Kühn, H., Murzek, M., Bayer, F.: Horizontal Business Process Model Interoperability

using Model Transformation, in: Proceedings of the Workshop on Interoperability of Enterprise Systems at ECOOP 2004, Oslo, 2004.

Lankes et al. (2005) Lankes, J., Matthes, F., Wittenburg, A.: Softwarekartographie – Systematische Dar-

stellung von Anwendungslandschaften, in: Ferstl, O. K., Sinz, E. J., Eckert, S., Issel-horts, T. (Hrsg.): Wirtschaftsinformatik 2005, Physica Verlag, Heidelberg, 2005, S. 1443-1462.

Lankhorst (2005) Lankhorst, M.: Enterprise Architecture at Work, Springer, Berlin/Heidelberg, 2005. Legner (1999) Legner, C.: Benchmarking informationssystemgestützter Geschäftsprozesse, Disserta-

tion der Universität St. Gallen, St. Gallen, 1999. Lehner (1995) Lehner, F.: Grundfragen und Positionierung der Wirtschaftsinformatik, in: Lehner, F.,

Hildebrand, K., Maier, R. (Hrsg.): Wirtschaftsinformatik, Hanser, München/Wien, 1995, S. 1-72.

Leidecker/Bruno (1984) Leidecker, J., Bruno, A.: Identifying and Using Critical Success Factors, in: Long

Range Planning, 17(1984)1, S. 23-32.

Literatur 294

Leist (2002) Leist, S.: Bankenarchitektur des Informationszeitalters - Zielsetzung und Gestaltungs-

ebenen, in: Leist, S., Winter, R. (Hrsg.): Retail Banking im Informationszeitalter, Springer, Berlin, 2002, S. 4-28.

Leist (2004) Leist, S.: Methoden zur Unternehmensmodellierung – Vergleich, Anwendungen und

Diskussionen der Integrationspotenziale, Habilitation der Univeristät St. Gallen, St. Gallen, 2004.

Leist/Winter (2000) Leist, S., Winter, R.: Finanzdienstleistungen im Informationszeitalter – Vision, Refe-

renzmodell und Transformation, in: Belz, C., Bieger, T. (Hrsg.): Dienstleistungskom-petenz und innovative Geschäftsmodelle, Thexis, St.Gallen, 2000, S. 150-166.

Leist/Winter (2002) Leist, S., Winter, R.: Retail Banking im Informationszeitalter, Springer, Berlin et al.,

2002. Lorenz (1995) Lorenz, K.: Methode, in: Mittelstrass, J. (Hrsg.): Enzyklopädie Philosophie und Wis-

senschaftstheorie, Stuttgart, 1995, S. 876-879. Luftman et al. (1993) Luftman, J. N., Lewis, P. R., Oldach, S. H.: Transforming the enterprise – The align-

ment of business and information technology strategies, in: IBM Systems Journal, 32(1993)1, S. 198-221.

Luftman et al. (1999) Luftman, J. N., Papp, R., Brier, T.: Enablers and inhibitors of business-IT alignment,

in: Communications of the Association for Information Systems (AIS), 1(1999)3, S. 2-32.

Lührs (2001) Lührs, J.-C.: Strategische Unternehmensführung im Kontext hoher Marktturbulenz –

Entwicklung eines Systematisierungsmodells am Beispiel von Netzwerkbranchen, Deutscher Universitäts Verlag, Wiesbaden, 2001.

Marr/Neely (2001) Marr, B., Neely, A.: Balanced Scorecard Software Report, Infoedge Inc., 2001. Masak (2005) Masak, D.: Moderne Enterprise Architekturen, Springer, Berlin/Heidelberg, 2005. Mayerl et al. (2005) Mayerl, C., Link, S., Racke, M., Popescu, S., Vogel, T., Mehl, O., Abeck, S.: Methode

für das Design von SLA-fähigen IT-Services, in: Proceedings der GI/ITG-Fachtagung Kommunikation in verteilten Systemen (KiVS), Kaiserslautern, 2005, S. 271-282.

Literatur 295

Mesarovic et al. (1970) Mesarovic, M. D., Macko, D., Takahara, Y.: Theory of Hierarchical, Multilevel Sys-

tems, Academic Press, New York/London, 1970. Mintzberg (1987) Mintzberg, H.: The strategy concept I: five p`s for strategy, in: California Manage-

ment Review, Herbst, 1987, S. 11-24. Müller-Stewens/Lechner (2003) Müller-Stewens, G., Lechner, C.: Strategisches Management – Wie strategische Initia-

tiven zum Wandel führen, 2. Aufl., Schäffer-Poeschel, Stuttgart, 2003. Nadler et al. (1992) Nadler, D. A., Gerstein, M. S., Shaw, R. B.: Organizational Architecture – Designs for

Changing Organizations, Jossey-Bass, San Francisco, 1992. Nieschlag et al. (1994) Nieschlag, R., Dichtl, E., Hörschgen, H.: Marketing, Duncker&Humblot, Berlin,

1994. NIST (1993) NIST: Integration Definition For Function Modeling (IDEF0),

http://www.idef.com/pdf/idef0.pdf (Zugriff: 11.05.2006). Nuseibeh et al. (1996) Nuseibeh, B., Finkelstein, A., Kramer, S.: Method engineering for multi-perspective

software development, in: Information and Software Technology, 38(1996)4, S. 267-274.

Nüttgens/Rump (2002) Nüttgens, M., Rump, F. J.: Syntax und Semantik Ereignisgesteuerter Prozessketten

(EPK), in: Proceedings des GI-Workshops Prozessorientierte Methoden und Werk-zeuge für die Entwicklung von Informationssystemen (Promise 2002), Bonn, 2002, S. 64-77.

Oestereich et al. (2004) Oestereich, B., Weiss, C., Schröder, C., Weilkiens, T., Lenhard, A.: Objektorientierte

Geschäftsprozessmodellierung mit der UML, Dpunkt-Verlag, Heidelberg, 2004. OMG (2003a) OMG: Model Driven Architecture (MDA) FAQ,

http://www.omg.org/mda/faq_mda.htm (Zugriff: 04.05.2005). OMG (2003b) OMG: UML 2.0 Superstructure Specification, http://www.omg.org/docs/ptc/03-08-

02.pdf (Zugriff: 06.06.2005). OMG (2005) OMG: UML 2.0 Superstructure Specification, http://www.omg.org/docs/formal/05-

07-04.pdf (Zugriff: 24.03.2006).

Literatur 296

Opengroup (2002) Opengroup: The Open Group Architecture Framework "Enterprise Edition" Version

8.1, http://www.opengroup.org/architecture/togaf8-doc/arch/ (Zugriff: 05.06.2005). Orlikowski/Barley (2001) Orlikowski, W. J., Barley, S. R.: Technology and Institutions – What Can Research on

Information Technology and Research on Organizations Learn From Each Other?, in: MIS Quarterly, 25(2001)2, S. 145-165.

Österle (1995) Österle, H.: Business Engineering – Prozess- und Systementwicklung, 2. Aufl., Sprin-

ger, Berlin et al., 1995. Österle (2003) Österle, H.: Geschäftsmodell des Informationszeitalters, in: Österle, H., Winter, R.

(Hrsg.): Business Engineering – Auf dem Weg zum Unternehmen des Informations-zeitalters, Springer, Berlin et al., 2003, S. 22-43.

Österle/Blessing (2003) Österle, H., Blessing, D.: Business Engineering Modell, in: Österle, H., Winter, R.

(Hrsg.): Business Engineering – Auf dem Weg zum Unternehmen des Informations-zeitalters, Springer, Berlin et al., 2003, S. 65-86.

Österle et al. (2001) Österle, H., Fleisch, E., Alt, R.: Business Networking – Shaping Collaboration Be-

tween Enterprises, 2. Aufl., Springer, Heidelberg, 2001. Österle/Winter (2003) Österle, H., Winter, R.: Business Engineering, in: Österle, H., Winter, R. (Hrsg.): Bu-

siness Engineering – Auf dem Weg zum Unternehmen des Informationszeitalters, Springer, Berlin et al., 2003, S. 3-20.

Popkin (2003) Popkin: Working with System Architect V9 Repository,

http://www.popkin.com/customers/customer_service_center/downloads/documentation.htm (Zugriff: 04.05.2005).

Popkin (2004) Popkin: User Guide,

http://www.popkin.com/customers/customer_service_center/downloads/documentation.htm (Zugriff: 04.05.2005).

Porter (1999) Porter, M. E.: Wettbewerbsvorteile – Spitzenleistungen erreichen und behaupten,

Campus Verlag, Frankfurt a.M., 1999. Rechenberg/Pomberger (1999) Rechenberg, P., Pomberger, G.: Informatik-Handbuch, 2. Aufl., Hanser, Mün-

chen/Wien, 1999.

Literatur 297

Reichmann (1997) Reichmann, T.: Controlling mit Kennzahlen und Managementberichten – Grundlagen

einer systemgestützten Controlling-Konzeption, 5. Aufl., Vahlen, München, 1997. Rockart (1979) Rockart, J.: Chief executives define their own data needs, in: Harvard Business Re-

view, 57(1979)2, S. 81-93. Rosemann (1995) Rosemann, M.: Erstellung und Integration von Prozessmodellen – Methodenspezifi-

sche Gestaltungsempfehlungen für die Informationsmodellierung, Dissertation der Universität Münster, Münster, 1995.

Rosemann (1996) Rosemann, M.: Komplexitätsmanagement in Prozessmodellen – Methodenspezifische

Gestaltungsempfehlungen für die Informationsmodellierung, Gabler, Wiesbaden, 1996.

Rosemann/Green (2002) Rosemann, M., Green, P.: Developing a meta model for the Bunge-Wand-Weber on-

tological constructs, in: Information Systems, 27(2002)2, S. 75-91. Rosemann/zur Mühlen (1997) Rosemann, M., zur Mühlen, M.: Modellierung der Aufbauorganisation in Workflow-

Management-Systemen – Kritische Bestandsaufnahme und Gestaltungsvorschläge, in: Proceedings des EMISA-Fachgruppentreffens, Aachen, 1997, S. 78-84.

Rupprecht (2002) Rupprecht, J.: Datensicherheit im Data Warehousing – Grundlagen, Zugriffskontrolle,

Fallbeispiele, Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen, 2002.

Samarati/de Capitani di Vimercati (2002) Samarati, P., de Capitani di Vimercati, S.: Access Control – Policies, Models and

Mechanisms, in: Focardi, R., Gorrieri, R. (Hrsg.): Foundations of Security Analysis and Design – Tutorial Lectures, Springer, Berlin, 2002.

Sarbanes-Oxley (2002) Sarbanes-Oxley: Sarbanes-Oxley Act of 2002,

http://www.law.uc.edu/CCL/SOact/soact.pdf (Zugriff: 04.04.2006). Scheer (1998) Scheer, A.-W.: ARIS – Vom Geschäftsprozess zum Anwendungssystem, Springer,

Berlin et al., 1998. Scheer (2001) Scheer, A.-W.: ARIS – Modellierungsmethoden, Metamodelle, Anwendungen, 4.

Aufl., Springer, Berlin/Heidelberg, 2001.

Literatur 298

Scheer/Jost (2002) Scheer, A.-W., Jost, W.: ARIS in der Praxis – Gestaltung, Implementierung und Opti-

mierung von Geschäftsprozessen, Springer, Berlin/Heidelberg, 2002. Scheer/Thomas (2005) Scheer, A.-W., Thomas, O.: Geschäftsprozessmodellierung mit der ereignisgesteuerten

Prozesskette, in: Das Wirtschaftsstudium, 34(2005)8-9, S. 1069-1078. Schekkerman (2004) Schekkerman, J.: How to Survive in the Jungle of Enterprise Architecture Frameworks

– Creating or Choosing an Enterprise Architecture Framework, 2. Aufl., Trafford Publishing, Victoria, 2004.

Schelp (2000) Schelp, J.: Konzeptionelle Modellierung mehrdimensionaler Datenstrukturen analyse-

orientierter Informationssysteme, Dissertation der Ruhr-Universität Bochum, Bochum, 2000.

Schelp et al. (2004) Schelp, J., Hafner, M., Winter, R.: Architekturmanagement als Basis effizienter und

effektiver Produktion von IT-Services, in: Hmd – Praxis der Wirtschaftsinformatik, 41(2004)237, S. 54-66.

Schelp/Schwinn (2005) Schelp, J., Schwinn, A.: Extending the Business Engineering Framework for Applica-

tion Integration Purposes, in: Proceedings of the 2005 ACM Symposium on Applied Computing (SAC), New York, 2005, S. 1333-1337.

Schemm et al. (2006) Schemm, J., Heutschi, R., Vogel, T., Wende, K., Legner, C.: Serviceorientierte Archi-

tekturen – Einordnung im Business Engineering, Arbeitsbericht, Institut für Wirt-schaftsinformatik, Universität St. Gallen, St. Gallen, 2006.

Schlitt (2003) Schlitt, M.: Grundlagen und Methoden für Interpretation und Konstruktion von Infor-

mationssystemmodellen, Dissertation der Universität Bamberg, Bamberg, 2003. Scholz (1998) Scholz, C.: Von der Netzwerkkooperation zur Virtualisierung, in: Winand, U., Nathu-

sius, K. (Hrsg.): Unternehmensnetzwerke und virtuelle Organisationen, Schaeffel-Poeschel, Stuttgart, 1998, S. 95-108.

Schönsleben/Leuzinger (1996) Schönsleben, P., Leuzinger, R.: Innovative Gestaltung von Versicherungsprodukten –

Flexible Industriekonzepte in der Assekuranz, Gabler Verlag, Wiesbaden, 1996. Schütte (1998) Schütte, R.: Grundsätze ordnungsmässiger Referenzmodellierung, Gabler, Wiesbaden,

1998.

Literatur 299

Schütte et al. (1999) Schütte, R., Siedentopf, J., Zelewski, S.: Wirtschaftsinformatik und Wissenschaftstheo-

rie – Grundpositionen und Theoriekerne, Arbeitsbericht, Institut für Produktion und industrielles Informationsmanagement, Universität Essen, Essen, 1999.

Schwinn (2005) Schwinn, A.: Entwicklung einer Methode zur Applikationsintegration in heterogenen

Informationssystemen, Dissertation der Universität St. Gallen, St. Gallen, 2005. Schwinn/Winter (2005) Schwinn, A., Winter, R.: Entwicklung von Zielen und Messgrössen zur Steuerung der

Applikationsintegration, in: Ferstl, O. K., Sinz, E. J., Eckert, S., Isselhorts, T. (Hrsg.): Wirtschaftsinformatik 2005, Physica, Bamberg, 2005, S. 587-606.

Senger/Österle (2004) Senger, E., Österle, H.: PROMET Business Engineering Case Studies (BECS) Versi-

on 2.0, Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen, 2004.

Seufert (2001) Seufert, S.: Die Zugriffskontrolle, Dissertation der Universität Bamberg, Bamberg,

2001. Siegenthaler/Schwinn (2005) Siegenthaler, A., Schwinn, A.: Modellierung von Integrationsaspekten in Applikations-

landschaften, in: Schelp, J., Winter, R. H. (Hrsg.): Integrationsmanagement – Planung, Bewertung und Steuerung von Applikationslandschaften, Springer, Berlin et al., 2005, S. 203-230.

Sinz (1999a) Sinz, E. J.: Architektur von Informationssystemen, in: Rechenberg, P., Pomberger, G.

(Hrsg.): Informatik-Handbuch, Hanser, München/Wien, 1999, S. 1035-1046. Sinz (1999b) Sinz, E. J.: Architektur von Informationssystemen, in: Rechenberg, P., Pomberger, G.

(Hrsg.): Informatik-Handbuch, Hanser, München, Wien, 1999, S. 1035-1046. Sledgianowski/Luftman (2005) Sledgianowski, D., Luftman, J. N.: IT-Business Strategic Alignment Maturity – A

Case Study, in: Journal of Cases on Information Technology, 7(2005)2, S. 102-120. Spewak/Hill (1993) Spewak, S. H., Hill, S. C.: Enterprise Architecture Planning – Developing a Blueprint

for Data, Applications and Technology, John Wiley & Sons, New York, 1993. Stachowiak (1973) Stachowiak, H.: Allgemeine Modelltheorie, Springer, New York, Wien, 1973. Stahlknecht/Hasenkamp (1999) Stahlknecht, P., Hasenkamp, U.: Einführung in die Wirtschaftsinformatik, Springer,

Berlin, 1999.

Literatur 300

Stojanovic (2005) Stojanovic, Z.: A Method for Component-Based and Service-Oriented Software Sys-

tems Engineering, Dissertation der Delft University of Technology, Delft, 2005. Strahringer (1998) Strahringer, S.: Ein sprachbasierter Metamodellbegriff und seine Verallgemeinerung

durch das Konzept des Metaisierungsprinzips, in: Modellierung 98, Proceedings; Be-richt Nr. 6/98-I, Angewandte Mathematik und Informatik, Münster, 1998, S. 15-20.

Strauch (2002) Strauch, B.: Entwicklung einer Methode für die Informationsbedarfsanalyse im Data

Warehousing, Dissertation der Universität St. Gallen, St. Gallen, 2002. Strauch/Winter (2002) Strauch, B., Winter, R.: Vorgehensmodell für die Informationsbedarfsanalyse im Data

Warehousing, in: von Maur, E., Winter, R. (Hrsg.): Vom Data Warehouse zum Corpo-rate Knowledge Center, Physica, Heidelberg, 2002, S. 359-378.

ter Doest/Lankhorst (2004) ter Doest, H., Lankhorst, M.: Tool Support for Enterprise Architecture, Telematica

Instituut, Enschede, 2004. Teubner (1999) Teubner, R. A.: Organisations- und Informationssystemgestaltung – Theoretische

Grundlagen und integrierte Methoden, DUV, Wiesbaden, 1999. Ulrich (2001) Ulrich, H.: Systemorientiertes Management – Das Werk von Hans Ulrich, Haupt,

Bern et al., 2001. van Hee (1994) van Hee, K. M.: Information Systems Engineering – A Formal Approach, Cambridge

University Press, Cambridge, 1994. Varveris/Harrison (2005) Varveris, L., Harrison, D.: Building Enterprise Architectures with TOGAF, Telelogic,

2005. Vogler (2003) Vogler, P.: Prozess- und Systemintegration – Umsetzung des organisatorischen Wan-

dels in Prozessen und Informationssystemen, Habilitation der Universität St. Gallen, St. Gallen, 2003.

Völter (2003) Völter, M. W., E.: Model Driven Architecture – Ein neuer Ansatz für Wiederverwen-

dung?, http://www.voelter.de/data/articles/mda.pdf (Zugriff: 04.05.2005). vom Brocke (2003a) vom Brocke, J.: Referenzmodellierung - Gestaltung und Verteilung von Konstrukti-

onsprozessen, Logos Verlag, Berlin, 2003.

Literatur 301

vom Brocke (2003b) vom Brocke, J.: Referenzmodellierung – Gestaltung und Verteilung von Konstrukti-

onsprozessen, Logos Verlag, Berlin, 2003. W3C (2004a) W3C: Web Services Architecture, W3C Working Group Note 11 February 2004,

http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ (Zugriff: 20.02.2006). W3C (2004b) W3C: Web Services Glossary, W3C Working Group Note 11 February 2004,

http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/ (Zugriff: 20.02.2006). Weber et al. (1997) Weber, J., Kummer, S., Grossklaus, A., Nippel, H., Warnke, D.: Methodik und Gene-

rierung von Logistik-Kennzahlen, in: Betriebswirtschaftliche Forschung und Praxis, Nr. 4, 1997, S. 438-454.

Winter (2003a) Winter, R.: An Architecture Model for Supporting Application Integration Decisions,

in: Proceedings of the 11th European Conference on Information Systems (ECIS), Naples, 2003.

Winter (2003b) Winter, R.: Conceptual Modeling of Business Networks and Business Strategies, in:

Proceedings of the 16th Bled eCommerce Conference on eTransformation, Bled, 2003, S. 551-568.

Winter (2003c) Winter, R.: Methodische Unterstützung der Strategiebildung im Retail Banking, in:

BIT – Banking and Information Technology, 4(2003)2, S. 49-58. Winter (2003d) Winter, R.: Modelle, Techniken und Werkzeuge im Business Engineering, in: Österle,

H., Winter, R. (Hrsg.): Business Engineering – Auf dem Weg zum Unternehmen des Informationszeitalters, Springer, Berlin et al., 2003, S. 87-118.

Winter (2004a) Winter, R.: Modellierung auf Prozessebene, Executive MBA in Business Engineering,

St. Gallen, 2004. Winter (2004b) Winter, R.: Modellierung auf Strategieebene, Executive MBA in Business Engineer-

ing, St. Gallen, 2004. Winter (2004c) Winter, R.: Modellierung auf Systemebene, Executive MBA in Business Engineering,

St. Gallen, 2004.

Literatur 302

Winter (2005) Winter, R.: Unternehmensarchitektur und Integrationsmanagement für Finanz-

dienstleister, in: Sokolovsky, Z., Löschenkohl, S. (Hrsg.): Handbuch Industrialisierung der Finanzwirtschaft, Gabler, Wiesbaden, 2005, S. 575-599.

Winter (2006) Winter, R.: Ein Modell zur Visualisierung der Anwendungslandschaft als Grundlage

der Informationssystem-Architekturplanung, in: Schelp, J., Winter, R. (Hrsg.): Integ-rationsmanagement, Springer, Berlin et al., 2006, S. 1-29.

Winter/Fischer (2006) Winter, R., Fischer, R.: Essential Layers, Artifacts, and Dependencies of Enterprise

Architecture, Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen, 2006.

Winter/Schelp (2005) Winter, R., Schelp, J.: Dienst-Orientierung im Business Engineering, in: Hmd – Praxis

der Wirtschaftsinformatik, 42(2005)241, S. 45-54. Winter/Strauch (2004) Winter, R., Strauch, B.: Information Requirements Engineering for Data Warehouse

Systems, in: Proceedings of the 2004 ACM Symposium on Applied Computing (SAC), Zypern, 2004, S. 1359-1365.

Winterthur (2005) Winterthur: Geschäftsbericht 2005, Winterthur Group, Winterthur, 2005. WKWI (1994) WKWI: Profil der Wirtschaftsinformatik, in: Wirtschaftsinformatik, 34(1994)1,

S. 80-81. Wortmann (2005) Wortmann, F.: Entwicklung einer Methode für die unternehmensweite Autorisierung,

Dissertation der Universität St. Gallen, St. Gallen, 2005. Yin (2002) Yin, R. K.: Case Study Research – Design and Methods, 3. Aufl., Sage Publications,

London, 2002. Zachman (1987) Zachman, J. A.: A Framework for Information Systems Architecture, in: IBM Systems

Journal, 26(1987)3, S. 276-292. Zachman/Sowa (1992) Zachman, J. A., Sowa, J. F.: Extending and formalizing the framework for informa-

tion systems architecture, in: IBM Systems Journal, 31(1992)3, S. 590-616. Zarnekow et al. (2005) Zarnekow, R., Brenner, W., Pilgram, U.: Integriertes Informationsmanagement – Stra-

tegien und Lösungen für das Management von IT-Dienstleistungen, Springer, Heidel-berg, 2005.

Literatur 303

Zarnekow et al. (2004) Zarnekow, R., Hochstein, A., Brenner, W.: ITIL als de-facto Standard für IT Service

Management, in: Hirzel, M. (Hrsg.): Prozessmanagement in der Praxis, HLP, Frank-furt am Main, 2004.

Zelewski (1999) Zelewski, S.: Grundlagen, in: Corsten, H., Reiss, M. (Hrsg.): Betriebswirtschaftslehre,

München/Wien, 1999, S. 1-125. Zellner (2003) Zellner, G.: Leistungsprozesse im Kundenbeziehungsmanagement, Dissertation der

Universität St. Gallen, St. Gallen, 2003.

Lebenslauf

Persönliche Daten

Name, Vorname Braun, Christian

Geboren am 10. Juni 1977

Geburtsort München, Deutschland

Familienstand ledig

Staatsangehörigkeit Deutsch

Ausbildung und Wehrdienst

1983 – 1987 Grundschule in München

1987 – 1996 Erasmus-Grasser-Gymnasium München

1996 – 1997 Grundwehrdienst bei der Deutschen Bundeswehr

1997 – 2002 Studium der Informatik an der Ludwig-Maximilians-

Universität München

2002 – 2005 Doktorandenstudium an der Universität St. Gallen,

Institut für Wirtschaftsinformatik

2006 – 2007 Forschungsaufenthalt an der Santa Clara University

(Kalifornien, USA) finanziert durch ein Nachwuchs-

stipendium des Schweizerischen Nationalfonds

Berufliche Tätigkeiten

1998 – 2002 Studentische Hilfskraft und Kursleiter in der Abteilung

für Informations- und Kommunikationstechnologie der

Ludwig-Maximilians-Universität München

2002 – 2006 Wissenschaftlicher Mitarbeiter am Institut für Wirt-

schaftsinformatik der Universität St. Gallen, Lehrstuhl

Prof. Dr. Robert Winter

Documents

Modellierung der Unternehmensarchitektur - unisg.chFILE/dis3285.pdf · Vorwort iii Vorwort Die vorliegende Arbeit entstand im Rahmen meiner mehrjährigen Forschungstätigkeit als