Prozess- und Systemintegration : evolutionäre Weiterentwicklung bestehender Informationssysteme mit Hilfe von enterprise application integration 383500333X, 9783835003330 [PDF]

Zitiervorschau

Petra Vogler Prozess- und Systemintegration

Prozess- und Systemintegration

m

0

z

m m m

mM

I

C~

~J ml

m

Petra Vogler

!

C

CD

e-

CD

CD

=

CD

m

7-

CD

--,

r.c:~ 3

~

==~

~.

n=l CD :~ ~ CD CD

0

c.c~

~

*--~

~_~. 0

0

m |

e~

~-b

N

CD -=~

0

==~

~*D

Petra Vogler

Prozess- und Systemintegration

Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet ~iber abrufbar.

Habilitationsschrift Universit~it St. Gallen, 2004

1. Auflage MiJrz 2006 Alle Rechte vorbehalten 9 Deutscher Universit~its-Verlag I GWV Fachverlage GmbH, Wiesbaden 2006 Lektorat: Ute Wrasmann / Britta GShrisch-Radmacher Der Deutsche Universit~its-Verlag ist ein Unternehmen von Springer Science+Business Media. www.duv.de Das Werk einschliel~lich aller seiner Teile ist urheberrechtlich gesch(Jtzt. Jede Verwertung aul~erhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verla.gs unzul~issig und strafbar. Das gilt insbesondere f(Jr Vervielf~iltigungen, Ubersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe yon Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten w~iren und daher von jedermann benutzt werden d~irften. Umschlaggestaltung: Regine Zimmer, Dipl.-Designerin, Frankfurt/Main Druck und Buchbinder: Rosch-Buch, Schel~litz Gedruckt auf s~iurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN 3-8350-0333-X

Vorwort 1994 schlossen sich im Rahmen des Forschungsprogramms "Informationsmanagement Universit~it St. Gallen" (IM HSG) acht schweizerische Unternehmen und das Institut fiir Wirtschaftsinformatik der Universit~it St. Gallen im Kompetenzzentrum "Prozess- und Systemintegration" (CC PSI) zusammen, um gemeinsam an der Entwicklung yon Methoden zur evolution~iren Weiterentwicklung bestehender Informationssysteme zu arbeiten. Im Rahmen dieses Forschungsprojektes ist die vorliegende Arbeit entstanden. Mein aufrichtiger Dank gilt Prof. Dr. H. Osterle, der mit dem Forschungsprogramm IM HSG eine ideale Forschungsumgebung flit diese Arbeit geschaffen und in Diskussionen mit mir wertvolle Ideen eingebracht hat. Zu grossem Dank bin ich meinen Kollegen im CC PSI-Team verpflichtet, die mit ihren Beitdigen wesentlich zum Erfolg des Kompetenzzentrums beigetragen haben. Zu ihnen z~ihlen Dr. M. Becket, Dr. M. Derungs, Dr. C. Gassner, Dr. T. Huber, Dr. T. Kaiser und Dr. R. Riehm. Die zahlreichen Diskussionen und Reviews an diversen Workshops mit der Arbeitsgruppe des CC PSI sowie der Einsatz der Ergebnisse in ausgew~ihlten Pilotprojekten in den Partnerunternehmen haben die Qualit[it der in der Arbeit beschriebenen Methoden entscheidend mitbestimmt. Ich bin davon tiberzeugt, dass ohne diese wertvollen Interaktionen mit den Mitgliedern der Partneruntemehmen des CC PSI, mit denen ich in den Jahren 1994 bis 1998 intensiv zusammen arbeiten durfte, das Integrationsmodell nie den heutigen Stand erreicht h~itte. Deshalb bin ich den Vertretern der Partnerfirmen in Dankbarkeit verbunden:

Unternehmen AGI, Aktiengesellschaft fGr Informatik der Kantonalbanken (jetzt Swisscom IT Services AG) Bi.ihler AG Ciba-Geigy AG (jetzt Novartis AG) Informatikdienste PTT (ERZ) (jetzt Swisscom IT Services AG) Schweizerische Bankgesellschaft (jetzt UBS) Schweizerische Kreditanstalt (jetzt CS Group) Schweizerischer Bankverein (jetzt UBS) Winterthur-Versicherungen

Vertreter in der Arbeitsgruppe R. BrechbGhl, U. Halter, U. Ziegler

Vertreter im Beirat

R. Gehring Dr. U. B0chler

E. Schmid F. Schmitter

H. Gadient, K. Jost, J. Stadelmann, H.-U. Straub

J. Calcio-Gandino, H. Schlatter,

R. Ami, Dr. P. Gloor, R.E. Patzke, W. Sch~irli, K. Siegrist

H. Fuchs*, Dr. P. Gisel

H. S0ess, M. Waber

B. Aschwanden

G. Rimbach, C. Santarossa

B. Meier

M. Achermann, Ph. Berni, B. H5sli, U. Joseph, A. L~ingerich, M. Manhart, P. Petrinec, M. Rudolf, A. Schlegel

P. HOhn, H. Schwarz

H. Franzstack

vi

Vorwort

Mein Dank gilt auch PD Dr. T. Gutzwiller, der mir zu Beginn des Kompetenzzentrums tatkr~iftig zur Seite stand. Von ganzem Herzen danke ich meinen Eltem, deren Untersttitzung mir den notwendigen Rtickhalt Dr eine solche Arbeit gab.

Dr. Petra Vogler

Inhaltsiibersicht V o r w o r t ..................................................................................................................................... v I n h a l t s i i b e r s i c h t ...................................................................................................................... Inhaltsverzeichnis

....................................................................................................................

Abbildungsverzeichnis

...........................................................................................................

Abkiirzungsverzeichnis

.......................................................................................................

1

E i n l e i t u n g ..........................................................................................................................

4

ix xv xxiii 1

1.1

Problemstellung .......................................................................................................... 1

1.2

Ziele und Adressaten der Arbeit ................................................................................. 2

1.3

Einordnung der Arbeit ................................................................................................ 4

1.4

Vorgehen und Forschungsmethodik ........................................................................... 4

1.5

Aufbau der Arbeit ....................................................................................................... 6

2

3

vii

Problemabgrenzung

.........................................................................................................

9

2.1

Case-Sammlung ....................................................................................................... 10

2.2

Ausl6ser von Integration .......................................................................................... 19

2.3

Potentieller Nutzen der Integration .......................................................................... 23

2.4

Probleme der Integration .......................................................................................... 24

2.5

Zusammenfassung .................................................................................................... 30

G r u n d l a g e n ..................................................................................................................... 33 3.1

Bezugsrahmen und Begriffsverst~indnis der Arbeit ................................................. 33

3.2

Integration in Wissenschaft und Praxis .................................................................... 58

I n t e g r a t i o n s m o d e l l .......................................................................................................... 79 4.1

Integration im Business Engineering Modell ........................................................... 79

4.2

Metamodell der Integration ...................................................................................... 81

4.3

Prozessumsetzung als Anwendung des Integrationsmodells ................................. 101

4.4

Prozessintegration .................................................................................................. 127

4.5

Systemintegration ................................................................................................... 135

4.6

Zusammenh~inge der unterschiedlichen Formen .................................................... 144

viii

5

6

7

Inhaltstibersicht

4.7

Bedeutung von Standards und Architekturen ~ r die Integration .......................... 145

4.8

Zusammenfassung .................................................................................................. 151

P r o z e s s i n t e g r a t i o n ........................................................................................................ 155 5.1

Ausl6ser von Prozessintegration ............................................................................ 155

5.2

Voraussetzungen flir die Prozessintegration .......................................................... 158

5.3

Framework: Varianten der Prozessintegration ....................................................... 168

5.4

Methode ~ r die Prozessintegration ........................................................................ 189

S y s t e m i n t e g r a t i o n ......................................................................................................... 225 6.1

Ausl6ser von Systemintegration ............................................................................. 225

6.2

Voraussetzungen flir die Systemintegration ........................................................... 230

6.3

Framework: Varianten der Systemintegration ....................................................... 253

6.4

Methode fiar die Systemintegration ........................................................................ 264

Z u s a m m e n f a s s u n g u n d A u s b l i e k ................................................................................ 295 7.1

Ergebnisse der Arbeit ............................................................................................. 295

7.2

Trends im EAI-Bereich .......................................................................................... 296

L i t e r a t u r v e r z e i c h n i s ............................................................................................................. 301 A

A n h a n g .......................................................................................................................... 341 A. 1

Metamodell ............................................................................................................. 342

A.2

Beschreibung der Entit~itstypen .............................................................................. 342

Inhaltsverzeichnis 1

2

E i n l e i t u n g .......................................................................................................................... 1.1

Problemstellung .......................................................................................................... 1

1.2

Ziele und Adressaten der Arbeit ................................................................................. 2

1.3

Einordnung der Arbeit ................................................................................................ 4

1.4

Vorgehen und Forschungsmethodik ........................................................................... 4

1.5

Aufbau der Arbeit ....................................................................................................... 6

P r o b l e m a b g r e n z u n g ......................................................................................................... 2.1

3

1

9

C a s e - S a m m l u n g ....................................................................................................... 10

2.1.1

Bank Austria ..................................................................................................... 10

2.1.2

S E C U R A Versicherungsgesellschaften ........................................................... 12

2.1.3

Kontron embedded computer A G .................................................................... 13

2.1.4

A G I Gruppe ...................................................................................................... 15

2.1.5

Z u s a m m e n f a s s u n g der Cases ........................................................................... 18

2.2

Ausl6ser von Integration .......................................................................................... 19

2.3

Potentieller Nutzen der Integration .......................................................................... 23

2.4

Probleme der Integration .......................................................................................... 24

2.5

Z u s a m m e n f a s s u n g .................................................................................................... 30

G r u n d l a g e n ..................................................................................................................... 3.1

33

B e z u g s r a h m e n und Begriffsverst~ndnis der Arbeit ................................................. 33

3.1.1

Business Engineering als Betrachtungsrahmen ................................................ 33

3.1.2

Definitionen ...................................................................................................... 36

3.1.2.1

Betrieblicher Prozess .................................................................................... 36

3.1.2.2

Prozessumsetzung ........................................................................................ 38

3.1.2.3

Workflow ..................................................................................................... 40

3.1.2.4

Informationssystem und Informationstechnologie ....................................... 41

3.1.2.5

Heterogenit/~t von A n w e n d u n g e n ................................................................. 44

3.1.2.5.1

Logische Heterogenit/~t .......................................................................... 45

3.1.2.5.2

Physische Heterogenit/it ......................................................................... 51

x

Inhaltsverzeichnis

3.1.2.6

3.2

Integration und EAI ......................................................................................52

3.1.2.6.1

Prozessintegration .................................................................................. 54

3.1.2.6.2

Desktopintegration ................................................................................. 55

3.1.2.6.3

Systemintegration ................................................................................... 56

Integration in Wissenschaft und Praxis .................................................................... 58

3.2.1

Organisationslehre ............................................................................................59

3.2.2

Wirtschaftsinformatik .......................................................................................60

3.2.3

Informatik .........................................................................................................61

3.2.4

Standardisierungsvereinigungen ...................................................................... 63

3.2.4.1

Standardisierungsebenen im Informationssystem ........................................ 63

3.2.4.2

OSF und DCE ...............................................................................................65

3.2.4.3

OMG und CORBA .......................................................................................66

3.2.4.4

Microsoft und OLE/DCOM sowie DNA 2000 ............................................ 69

3.2.4.5

OAG und OAGIS .........................................................................................71

3.2.4.6

SAP ALE ......................................................................................................74

3.2.4.7 3.2.5

XML .............................................................................................................76 Zusammenfassung ............................................................................................77

I n t e g r a t i o n s m o d e l l ......................................................................................................... 79 4.1

Integration im Business Engineering Modell ........................................................... 79

4.2

Metamodell der Integration ...................................................................................... 81

4.2.1

Die vier Sichten des Integrationsmodells ......................................................... 83

4.2.1.1

Sicht Prozessintegration ............................................................................... 84

4.2.1.2

Sicht Desktopintegration .............................................................................. 85

4.2.1.3

Sicht Systemintegration ................................................................................ 87

4.2.1.4

Sicht Informationssystem ............................................................................. 89

4.2.2 4.3

Beschreibung der Metaentit~itstypen ................................................................ 90 Prozessumsetzung als Anwendung des Integrationsmodells ................................. 101

4.3.1

Problembereiche der Prozessumsetzung ........................................................ 102

4.3.2

Rahmenbedingungen mr die Planung der Prozessumsetzung ........................ 106

4.3.2.1

Ableitung der Anforderungen aus dem Prozessentwurf ............................ 107

Inhaltsverzeichnis

xi

4.3.2.1.1

Methoden ~ r den Prozessentwurf. ....................................................... 107

4.3.2.1.2

Methoden for die Informationssystementwicklung .............................. 109

4.3.2.2

Kenntnis des Ist-Informationssystems ....................................................... 112 Architekturvarianten der Prozessumsetzung .................................................. 113

4.3.3 4.3.3.1

Variante eins: Eine integrierte Anwendung ............................................... 114

4.3.3.2

Variante zwei: Isolierte Anwendungen ...................................................... 116

4.3.3.3

Variante drei: Systemintegration zwischen vereinzelten Anwendungen... 117

4.3.3.4

Variante vier: Taskflowsteuerung .............................................................. 119

4.3.3.5

Variante ~ n f : Workflowsteuerung ............................................................ 120

4.3.3.6

Variante sechs: Task- und Workflowsteuerung ......................................... 121

4.3.4

Technologische Implementierungsvarianten .................................................. 123

4.3.5

Vorgehen bei der Prozessumsetzung .............................................................. 126

4.4

Prozessintegration .................................................................................................. 127

4.4.1

Prozessintegration und Desktopintegration als Zustand ................................ 129

4.4.2

Prozessintegration als Vorgang ...................................................................... 132

4.5

Systemintegration ...................................................................................................135 Systemintegration als Zustand ....................................................................... 136

4.5.1 4.5.1.1

Manuelle Systemintegration ....................................................................... 137

4.5.1.2

Frontend-Integration ................................................................................... 137

4.5.1.3

Anwendungserweiterung ............................................................................ 138

4.5.1.4

Datenintegration ......................................................................................... 139

4.5.1.5

Methodenaufruf .......................................................................................... 140

4.5.1.6

Eigenst~indige Integrationsanwendung ....................................................... 140

4.5.2

Systemintegration als Vorgang ...................................................................... 141

4.6

Zusammenh~inge der unterschiedlichen Formen .................................................... 144

4.7

Bedeutung von Standards und Architekturen fiir die Integration .......................... 145

4.8

Zusammenfassung .................................................................................................. 151

Prozessintegration ........................................................................................................ 155 5.1 5.1.1

Ausl6ser von Prozessintegration ............................................................................ 155 Prozessintegration als Folge der Prozessentwicklung .................................... 156

xii

Inhaltsverzeichnis

5.1.2 5.2

Prozessintegration als Folge technologischen Fortschritts ............................. 157 Voraussetzungen Rir die Prozessintegration .......................................................... 158

5.2.1

Prozessbeschreibung ...................................................................................... 159

5.2.2

Ist-Informationssystembeschreibung ............................................................. 163

5.2.3

Architektur der Anwendungen und der Aktivit~iten ....................................... 167

5.3

Framework: Varianten der Prozessintegration ....................................................... 168

5.3.1

Konzeptionelle Varianten der Prozessintegration .......................................... 168

5.3.2

Implementieruogsvarianten der Prozessintegration ....................................... 173

5.3.2.1

Anforderungen an Steuerungskomponenten .............................................. 174

5.3.2.2

Autonome Steuerungssotiware .................................................................. 178

5.3.2.3

Integrierte Steuerungskomponente ............................................................. 184

5.3.2.4

GegeniJberstellung der Implementierungsvarianten ................................... 188

5.4

Methode Rir die Prozessintegration ........................................................................ 189

5.4.1

Dokumentationsmodell .................................................................................. 190

5.4.2

Techniken ........................................................................................................ 194

5.4.2.1

Workflowabgrenzung ................................................................................. 194

5.4.2.2

Desktopintegration ..................................................................................... 203

5.4.2.3

Workflowplanung ....................................................................................... 213

5.4.3

Vorgehensmodell ........................................................................................... 221

Systemintegration ......................................................................................................... 225 6.1

Ausltiser von Systemintegration ............................................................................. 225

6.1.1

Systemintegration als F olge der Strategieentwicklung .................................. 226

6.1.2

Systemintegration als Folge der Prozessentwicklung .................................... 226

6.1.3

Systemintegration als Folge technologischen Fortschritts ............................. 228

6.2

Voraussetzungen Rir die Systemintegration ........................................................... 230

6.2.1

Prozessbeschreibung ...................................................................................... 231

6.2.2

Ist-Informationssystembeschreibung ............................................................. 232

6.2.3

Architektur der Anwendungen und des Informationssystems ....................... 236

6.2.4

Kenntnis der Integrationstechnologie (Middleware) ...................................... 237

6.2.4.1

Pr~isentationsdienste ................................................................................... 239

Inhaltsverzeichnis

6.2.4.2

xiii

Daten- und D o k u m e n t e n m a n a g e m e n t d i e n s t e ............................................. 239

6.2.4.2.1

D a t e n m a n a g e m e n t d i e n s t e ..................................................................... 240

6.2.4.2.2

D o k u m e n t e n m a n a g e m e n t d i e n s t e ......................................................... 241

6.2.4.3

Applikations- und Koordinationsdienste .................................................... 242

6.2.4.4

K o m m u n i k a t i o n s d i e n s t e ............................................................................. 243

6.2.4.4.1

K o m m u n i k a t i o n s k o n z e p t e .................................................................... 244

6.2.4.4.2

M i d d l e w a r e d i e n s t e zur K o m m u n i k a t i o n .............................................. 244

6.2.4.5

Verteilungsdienste ...................................................................................... 248

6.2.4.6

E A I - P l a t t f o r m e n ......................................................................................... 251

6.3

Framework: Varianten der Systemintegration ....................................................... 253

6.3.1

K o n z e p t i o n e l l e Varianten der Systemintegration .......................................... 253

6.3.2

Implementierungsvarianten der Systemintegration ........................................ 264

6.4

M e t h o d e fiir die Systemintegration ........................................................................ 264

6.4.1

D o k u m e n t a t i o n s m o d e l l .................................................................................. 265

6.4.2

Techniken .......................................................................................................

268

6.4.2.1

Interaktionsanalyse ..................................................................................... 269

6.4.2.2

M a c r o e n t w u r f einer Integrationsbeziehung ............................................... 277

6.4.2.3

Integrationsdesign: M i d d l e w a r e A s s e s s m e n t und Integrationsvariante ..... 282

6.4.2.4

Integrationsspezifikation ............................................................................ 288

6.4.3

V o r g e h e n s m o d e l l ........................................................................................... 292

Zusammenfassung

u n d A u s b l i c k ................................................................................ 2 9 5

7.1

Ergebnisse der Arbeit ............................................................................................. 295

7.2

Trends im E A I - B e r e i c h .......................................................................................... 296

L i t e r a t u r v e r z e i c h n i s .............................................................................................................

301

A n h a n g ..........................................................................................................................

341

A. 1

M e t a m o d e l l .............................................................................................................

342

A.2

Beschreibung der Entit~itstypen .............................................................................. 342

A.2.1

Aktivit~it ..........................................................................................................

342

A.2.2

Aktivit~it im W o r k f l o w ................................................................................... 343

xiv

Inhaltsverzeichnis

A.2.3

A n w e n d u n g .................................................................................................... 345

A.2.4

A p p l i k a t i o n ..................................................................................................... 346

A.2.5

A p p l i k a t i o n s s c h n i t t s t e l l e ................................................................................ 347

A.2.6

A u s ~ h r u n g s b e d i n g u n g .................................................................................. 348

A.2.7

A u s f f i h r u n g s b e r e c h t i g u n g .............................................................................. 348

A.2.8

D a t e n a n f o r d e r u n g ........................................................................................... 349

A.2.9

D a t e n e l e m e n t .................................................................................................. 349

A.2.10

D a t e n f l u s s z w i s c h e n T a s k s ............................................................................. 350

A.2.11

D a t e n s a m m l u n g .............................................................................................. 351

A.2.12

D a t e n s a m m l u n g s schnittstelle ......................................................................... 352

A.2.13

D a t e n s t r u k t u r .................................................................................................. 352

A.2.14

D a t e n t r a n s f e r .................................................................................................. 354

A.2.15

D i a l o g e l e m e n t ................................................................................................ 355

A.2.16

E f f e k t .............................................................................................................. 356

A.2.17

F u n k t i o n s a n f o r d e r u n g .................................................................................... 356

A.2.18

M e t h o d e .......................................................................................................... 357

A.2.19

M i d d l e w a r e ..................................................................................................... 357

A.2.20

O E an Standort ............................................................................................... 358

A.2.21

O r g a n i s a t i o n s e i n h e i t ....................................................................................... 358

A.2.22

P r o z e s s ............................................................................................................ 359

A.2.23

Schnittstelle .................................................................................................... 360

A.2.24

Standort .......................................................................................................... 361

A.2.25

Stelle ............................................................................................................... 361

A.2.26

Stelle zu O E .................................................................................................... 362

A.2.27

S t e u e r d a t e n der Aktivit~it ................................................................................ 363

A.2.28

S y s t e m ............................................................................................................ 363

A.2.29

T a s k ................................................................................................................ 364

A.2.30

W o r k f l o w ....................................................................................................... 366

A.2.31

Z u s t a n d ........................................................................................................... 368

A.2.32

Z u s t a n d s t i b e r g a n g ........................................................................................... 369

Abbildungsverzeichnis Abb. 1.1:

Aufbau der Arbeit im Oberblick ............................................................................. 7

Abb. 2.1:

Problemstellung der Integration .............................................................................. 9

Abb. 2.2:

Informationssystem der Kontron vor der SAP R/3 Einfahrung ............................ 14

Abb. 2.3:

Grobkonzept des AGI Datenmanagements ........................................................... 16

Abb. 2.4:

Architektur der Integration bei der AGI ................................................................ 18

Abb. 2.5:

Beispiel eines Wirkungsnetzes von m6glichen Integrationsausl6sem und deren Auswirkungen ..................................................................................... 22

Abb. 2.6:

Zuordnung der Integrationsprobleme zu Problembereichen ................................. 24

Abb. 2.7:

Punkt-zu-Punkt Integration ................................................................................... 26

Abb. 3.1 :

Ebenen und Dimensionen des Business Engineering ............................................ 34

Abb. 3.2:

Integrationsobjekte der Ebenen des Business Engineering ................................... 35

Abb. 3.3:

Bezugsrahmen und Schwerpunkt der Arbeit ......................................................... 36

Abb. 3.4:

Komponenten des Prozessmodells ........................................................................ 37

Abb. 3.5:

Ebenen und Ergebnisse (Beispiele) des Business Engineerings ........................... 39

Abb. 3.6:

Komponenten der Prozessentwicklung ................................................................. 40

Abb. 3.7:

Zusammenhang: Anwendungen, Middleware und Systemsoftware ..................... 42

Abb. 3.8:

Anwendung, Applikation und Datensammlung .................................................... 42

Abb. 3.9:

Metamodell: Schnittstellen im Kontext yon Anwendungen ................................. 43

Abb. 3.10: IS und IT mit ihren Unterebenen ........................................................................... 44 Abb. 3.11: Heterogenitgtsformen ............................................................................................ 45 Abb. 3.12: Abstraktion des Anwendungsbereichs in Modellen .............................................. 46 Abb. 3.13: Modelle einer Anwendung .................................................................................... 47 Abb. 3.14: Ausgangssituation: logisch homogene Modelle .................................................... 48 Abb. 3.15: Heterogene Applikationsmodelle, homogenes Datenmodell ................................ 49 Abb. 3.16: Homogenes Applikationsmodell, heterogene Datenmodelle ................................ 50 Abb. 3.17: Heterogene Applikationsmodelle, heterogene Datenmodelle ............................... 50 Abb. 3.18: Prozess-, Desktop- und Systemintegration im Business Engineering ................... 54 Abb. 3.19: Unterschiede Aufgabe - Aktivitgt- Task .............................................................. 56 Abb. 3.20: Systemintegration in einem heterogenen Informationssystem .............................. 57

xvi

Abbildungsverzeichnis

Abb. 3.21: Integration in der Wissenschaft ............................................................................. 63 Abb. 3.22: OSF DCE Architektur ........................................................................................... 65 Abb. 3.23: OMA und OMG Standardisierung ........................................................................ 67 Abb. 3.24: Architektur OLE/COM .......................................................................................... 69 Abb. 3.25: Microsoft DNA 2000 ............................................................................................. 70 Abb. 3.26: Modell der OAG .................................................................................................... 72 Abb. 3.27: Integrationsszenario "Project Accounting Synchronisation". ............................... 73 Abb. 3.28: Architektur eines BOD .......................................................................................... 73 Abb. 3.29: ALE Architektur .................................................................................................... 75 Abb. 4.1:

Integration im Business Engineering .................................................................... 80

Abb. 4.2:

Beispiel fiar die Notation des Datenmodells .......................................................... 81

Abb. 4.3:

Exklusive Beziehung ............................................................................................. 82

Abb. 4.4:

Metamodell der Integration ................................................................................... 82

Abb. 4.5:

Sichten der Integration .......................................................................................... 83

Abb. 4.6:

Sicht 1: Prozessintegration .................................................................................... 85

Abb. 4.7:

W o r k f l o w - Aktivit/~t- Task .................................................................................. 86

Abb. 4.8:

Sicht 2: Desktopintegration ................................................................................... 86

Abb. 4.9:

Integrationsbeziehung bestehend aus Datentransfers und Schnittstellen .............. 87

Abb. 4.10: Sicht 3: Systemintegration ..................................................................................... 88 Abb. 4.11: Sicht 4: Informationssystem .................................................................................. 90 Abb. 4.12: Prozessumsetzung im Referenzmodell der Integration ....................................... 102 Abb. 4.13: Ableiten von Problembereichen .......................................................................... 103 Abb. 4.14: Spannungsfeld der Prozessumsetzung ................................................................. 106 Abb. 4.15: Abzudeckende Komponenten des Prozessmodells ............................................. 109 Abb. 4.16: Methoden fiJr die Anpassung von Altanwendungen ........................................... 111 Abb. 4.17: Notwendige Dokumentationen mr die Prozessumsetzung .................................. 113 Abb. 4.18: Variante 1: Eine Anwendung .............................................................................. 114 Abb. 4.19: Charakteristika der Variante Eine Anwendung ................................................... 115 Abb. 4.20: Variante 2: Isolierte Anwendungen ..................................................................... 116 Abb. 4.21: Charakteristika der Variante Isolierte Anwendungen ......................................... 116

Abbildungsverzeichnis

xvii

Abb. 4.22: Variante 3: Systemintegration zwischen Anwendungen ..................................... 117 Abb. 4.23: Charakteristika der Variante Systemintegration einzelner Anwendungen .......... 118 Abb. 4.24: Variante 4: Taskflowsteuerung ...........................................................................

119

Abb. 4.25: Charakteristika der Variante Taskflowsteuerung ................................................ 119 Abb. 4.26: Workflowsteuerung .............................................................................................

120

Abb. 4.27: Charakteristika der Variante Workflowsteuerung ............................................... 120 Abb. 4.28: Task- und Workflowsteuerung ............................................................................

121

Abb. 4.29: Charakteristika der Variante Task- und Workflowsteuerung .............................. 122 Abb. 4.30: Varianten der Prozessumsetzung und deren notwendige Integrationsarten ........ 123 Abb. 4.31: Elementare Verfahren fiir das Technology Assessment ...................................... 126 Abb. 4.32: Vorgehensweise bei der Prozessumsetzung ........................................................ 127 Abb. 4.33: Workflow - Taskflow ..........................................................................................

128

Abb. 4.34: Varianten der Ablaufsteuerung ...........................................................................

131

Abb. 4.35: Vorgehensweise bei der Prozessintegration ........................................................ 133 Abb. 4.36: Gestaltungsbereiche der Prozess- und Desktopintegration ................................. 134 Abb. 4.37: Kontroll-/Steuerfluss und Daten-/Informationsfluss eines Workflows ............... 135 Abb. 4.38: Client/Server-Architekturmodell einer Anwendung ........................................... 136 Abb. 4.39: Manuelle Systemintegration ................................................................................

137

Abb. 4.40: Frontend-Integration ............................................................................................

138

Abb. 4.41: Anwendungserweiterung .....................................................................................

138

Abb. 4.42: Varianten der Integration der Daten ....................................................................

139

Abb. 4.43: Integration fiber Replikation ................................................................................

140

Abb. 4.44: Integration fiber Methodenaufruf ........................................................................

140

Abb. 4.45: Eigenst~indige Integrationsanwendung ................................................................

141

Abb. 4.46: Vorgehensweise bei der Systemintegration ........................................................ 143 Abb. 4.47: Sichten einer IS-Architektur ................................................................................

147

Abb. 4.48: Integrationsfragen ................................................................................................

153

Abb. 5.1:

Prozessintegration im Business Engineering ...................................................... 155

Abb. 5.2:

Zusammenhang Prozessentwicklung und Prozessintegration ............................. 156

Abb. 5.3:

Driver der Prozessintegration ..............................................................................

158

.~176 XVlll

Abbildungsverzeichnis

Abb. 5.4:

Voraussetzungen Rir die Prozessintegration ....................................................... 158

Abb. 5.5:

Beispiel eines Aufgabenkettendiagramms (Prozess Auftragserfassung) ............ 160

Abb. 5.6:

Beispiel einer Prozesszerlegungsmatrix .............................................................. 162

Abb. 5.7:

Beispiel Applikationsszenario ............................................................................. 164

Abb. 5.8:

Beispiel Datentransferbeschreibung .................................................................... 165

Abb. 5.9:

Beispiel IT-Szenario ............................................................................................ 167

Abb. 5.10: Notwendige Dokumentationen flar die Prozessintegration .................................. 168 Abb. 5.11: Charakteristika der Prozessintegrationsvarianten ............................................... 169 Abb. 5.12: Vor- und Nachteile Ad hoc Workflow (bzw. Taskflow) ..................................... 170 Abb. 5.13: Vor- und Nachteile Flexibler Workflow (bzw. Taskflow) .................................. 171 Abb. 5.14: Vor- und Nachteile Transaktionsorientierter Workflow (bzw. Taskflow) .......... 172 Abb. 5.15: Kombinationsm(Jglichkeiten der Prozess- und Desktopintegration .................... 173 Abb. 5.16: Autonome vs. integrierte Steuerungskomponente ............................................... 174 Abb. 5.17: Anforderungen an Steuerungskomponenten ....................................................... 178 Abb. 5.18: Klassifikation von Groupware ............................................................................. 179 Abb. 5.19: Komponenten eines Workflow-Managementsystems ......................................... 181 Abb. 5.20: Referenzmodell der WfMC ................................................................................. 182 Abb. 5.21: Vorgehensweise bei der Prozessintegration ........................................................ 189 Abb. 5.22: Komponenten der Methodenbeschreibung .......................................................... 190 Abb. 5.23: Phasen der Prozessintegration ............................................................................. 191 Abb. 5.24: Phasen der Prozessintegration mit ihren Dokumenten ........................................ 193 Abb. 5.25: Dokumentationsmodell der Prozessintegration ................................................... 193 Abb. 5.26: 13bersicht Workflowabgrenzung ......................................................................... 195 Abb. 5.27: Beispiel Klassen- und Komplexprinzip ............................................................... 197 Abb. 5.28: Ausschnitt einer strukturierten Taskliste ............................................................. 198 Abb. 5.29: Workflowabgrenzung des Prozesses "Service". .................................................. 199 Abb. 5.30: Workflowverzeichnis des Prozesses "Service". .................................................. 201 Abb. 5.31: Workflowkontextdiagramm ................................................................................ 202 Abb. 5.32: 13bersicht Desktopintegration .............................................................................. 204 Abb. 5.33: Gruppierung von Tasks zu Aktivit~iten ............................................................... 205

Abbildungsverzeichnis

xix

Abb. 5.34: Ausschnitt eines Aktivit~itenverzeichnisses ......................................................... 207 Abb. 5.35: Beispiel Steuerdatenfluss .................................................................................... 208 Abb. 5.36: Beispiel einer Aktivit~itenbeschreibung ............................................................... 210 Abb. 5.37: Steuerdatenfluss und Datenfluss ......................................................................... 211 Abb. 5.38: Beispiel einer Taskbeschreibung ......................................................................... 213 Abb. 5.39: Ubersicht Workflowplanung ............................................................................... 214 Abb. 5.40: Beispiel eines Workflows .................................................................................... 216 Abb. 5.41: Zust~inde und Aktivit~iten (Beispiel) .................................................................... 217 Abb. 5.42: Beispiel ZustandsiJbergangsdiagramm ................................................................ 218 Abb. 5.43: AusfiJhrungsbedingungen im Zustand "konfiguriert". ........................................ 219 Abb. 5.44: Beispiel eines Berechtigungskonzepts ................................................................ 220 Abb. 5.45: Vorgehensweise bei der Prozessintegration ........................................................ 222 Abb. 5.46: Techniken und Ergebnisdokumente im Vorgehensmodell ................................. 223 Abb. 6.1:

Systemintegration im Business Engineering ....................................................... 225

Abb. 6.2:

Zusammenhang Prozessumsetzung - Prozessintegration - Systemintegration .... 227

Abb. 6.3:

InformationsfliJsse in einem Prozess ................................................................... 227

Abb. 6.4:

Ausl0ser mr die Integration ................................................................................. 230

Abb. 6.5:

Voraussetzungen fi~r die Systemintegration ........................................................ 230

Abb. 6.6:

Beispiel Logische Transaktion ............................................................................ 233

Abb. 6.7:

Beispiel Serviceprogramm .................................................................................. 234

Abb. 6.8:

Beispiel einer Datenstruktur ................................................................................ 235

Abb. 6.9:

Beispiel einer Schnittstellenbeschreibung (Ausschnitt) ...................................... 236

Abb. 6.10: Notwendige Dokumentationen t'dr die Systemintegration .................................. 237 Abb. 6.11: Kategorien der Middleware ................................................................................. 238 Abb. 6.12: Architektur des CORBA Object Request Brokers .............................................. 248 Abb. 6.13: Architektur mr Systemmanagement .................................................................... 249 Abb. 6.14: Open Group Distributed Transaction Processing Model .................................... 251 Abb. 6.15: Ausgew~ihlte EAI-Produkte ................................................................................. 252 Abb. 6.16: Manuelle Systemintegration ................................................................................ 254 Abb. 6.17: Vor- und Nachteile der manuellen Systemintegration ........................................ 254

xx

Abbildungsverzeichnis

Abb. 6.18: Frontend-Integration ............................................................................................ 255 Abb. 6.19: Vor- und Nachteile der Frontend-Integration ...................................................... 255 Abb. 6.20: Integration als Weiterentwicklung einer Anwendung ......................................... 256 Abb. 6.21: Vor- und Nachteile der Anwendungserweiterung ............................................... 257 Abb. 6.22: Varianten der Integration der Daten .................................................................... 257 Abb. 6.23: Vor- und Nachteile der Datenintegration ............................................................ 259 Abb. 6.24: Integration tiber Methodenaufruf ........................................................................ 260 Abb. 6.25: Vor- und Nachteile des Methodenaufrufs ........................................................... 261 Abb. 6.26: Eigenst~ndige Integrationsanwendung ................................................................ 262 Abb. 6.27: Charakteristika der eigenst~indigen Integrationsanwendung ............................... 262 Abb. 6.28: Kriterien zur Beurteilung der Ausgangssituation ................................................ 263 Abb. 6.29: Vorgehensweise bei der Systemintegration ........................................................ 264 Abb. 6.30: Phasen der Systemintegration ............................................................................. 265 Abb. 6.31: Phasen der Systemintegration mit ihren Dokumenten ........................................ 267 Abb. 6.32: Dokumentationsmodell der Systemintegration ................................................... 268 Abb. 6.33: Ubersicht Interaktionsanalyse ............................................................................. 270 Abb. 6.34: Beispiel von Datenanforderungen ....................................................................... 271 Abb. 6.35: Beispiel von Funktionsanforderungen ................................................................. 272 Abb. 6.36: Ausschnitt eines Informationsbedarfs ................................................................. 272 Abb. 6.37: Ausschnitt des Integrationsbedarfs des Prozesses "Neuanschluss". .................... 273 Abb. 6.38: Integrationsszenario des Prozesses ...................................................................... 274 Abb. 6.39: Integrationsbeziehung ......................................................................................... 274 Abb. 6.40: Ausschnitt eines Verzeichnisses der Integrationsbeziehungen ........................... 275 Abb. 6.41: Beispiel einer Beschreibung einer Integrationsbeziehung .................................. 276 Abb. 6.42: l]bersicht Macroentwurf der Integrationsbeziehung ........................................... 278 Abb. 6.43: Beispiel Datentransfer ......................................................................................... 279 Abb. 6.44: Ausschnitt aus einem Datenabgleich ................................................................... 281 Abb. 6.45: l]bersicht Integrationsdesign ............................................................................... 282 Abb. 6.46: Dokument ftir eine Variantenpriorisierung ......................................................... 284 Abb. 6.47: Ausschnitt eines Middlewareverzeichnisses ....................................................... 286

Abbildungsverzeichnis

Abb. 6.48: Beispiel eines Integrationskonzeptes ...................................................................

xxi

288

Abb. 6.49: 15bersicht Integrationsspezifikation ..................................................................... 289 Abb. 6.50: Phasen eines Datenaustausches ...........................................................................

290

Abb. 6.51: lJberarbeiteter Datentransfer ...............................................................................

291

Abb. 6.52: Vorgehen der Systemintegration .........................................................................

293

Abb. 6.53: Vorgehensmodell der Systemintegration ............................................................ 294 Abb. 7.1:

Integrationsarchitektur .........................................................................................

295

Abkiirzungsverzeichnis AGI

Aktiengesellschaff ffir Informatik

AIIM

Association for Information and Image Management

API

Application Programming Interface

BAPI

Business Application Programming Interface

BOD

Business Object Document

BOMSIG

Business Object Management Special Interest Group

BPR

Business Process Reengineering

CC PRO

Kompetenzzentrum Prozessentwicklung

CC PSI

Kompetenzzentrum Prozess- und Systemintegration

CDS

Cell Directory Service

CMC API

Common Messaging Call API

CMIP

Common Management Information Protocol

CMISE

Common Management Information Service Element

COM

Component Object Model

CORBA

Common Object Request Broker Architecture

CRM

Customer Relationship Management

CSCW

Computer Supported Cooperative Work

CUI

Character-based User Interface

DCE

Distributed Computer Environment

DCOM

Distributed Component Object Model

DMA

Document Management Alliance

DME

Distributed Management Environment

DNA

Distributed iNternet Architecture

DS

Datensammlung

DTD

Document Type Definition

DTP

Distributed Transaction Processing

EAI

Enterprise Application Integration

ER-Diagramm

Entity-Relationship-Diagramm

GSSAPI

Generic Security-Service API

IDL

Interface Definition Language

IDOC

Intermediate Document

IIS

Internet Information Server

IM HSG

Informationsmanagement HSG

xxiv

JIT

Abkttrzungsverzeichnis

Just in Time

MAPI

Messaging Application Programming Interface

MOM

Message-Oriented Middleware

MOMA

Message Oriented Middleware Association

MTS

Microsoft Transaction Server

OAG

Open Applications Group

OAGIS

Open Applications Group Integration Specifications

OBI

Open Buying on the Internet

ODBC

Open Database Connectivity

OE

Organisationseinheit

OFX

Open Financial Exchange

OLE

Object Linking and Embedding

OMA

Object Management Architecture

OMG

Object Management Group

ORB

Object Request Broker

OSF

Open Software Foundation

RFC

Remote Function Call

RPC

Remote Procedure Call

SAA

System Application Architecture

SGML

Standard Generalized Markup Language

SMTP

Simple Mail Transfer Protocol

SNMP

Simple Network Management Protocol

UDM

Unternehmensweites Datenmodell

WAPI

Workflow Application Programming Interface

WfMC

Workflow Management Coalition

XAPIA

X.400 Application Programming Interface Association

XML

Extensible Markup Language

XSL

Extensible Stylesheet Language

1 Einleitung 1.1 Problemstellung Die Wirtschaft befindet sich in einem permanenten Wandel. Die zahlreichen Mergers und Akquisitionen von Unternehmen ~hren zu intemen Restmkturierungen von Unternehmen sowie zu neuen Formen der Kooperationen von Marktpartnern. Viele Untemehmen wenden seit Mitte der 90er Jahre das Konzept des Business Process Reengineering (BPR) an, das die Prozesse kundenorientiert neu gestaltet [s. Davenport 1993; Hammer/Champy 1993]. Verbunden mit den Anderungen der Organisationsstruktur, die sich in Form von Anderungen der Gesch/~ftsprozesse durch Aufgabenintegration sowie von Neuzuweisungen der Aufgaben zu Aufgabentr~igem niederschl/igt, ist die Forderung nach einer schnellen Umsetzung der Prozesse in das Informationssystem. BPR-Projekte verfolgen die Untersttitzung der Prozesse durch beste Informationstechnologie und definieren somit Anforderungen an das Informationssystem. Ftir die Erffillung dieser Anforderungen sollen die Potentiale des vorhandenen Informationssystems wie auch neuer Anwendungen ausgesch6pft werden. Die Umsetzung der neu definierten Prozesse sowie der Anforderungen aus der Wirtschaft in das Informationssystem kann selten mit Hilfe eines Top-Down Vorgehens vollzogen werden, das in eine komplette Neuentwicklung oder den Zukauf einer ProzesslSsung mtindet. Das bestehende Informationssystem bindet erhebliche Ressourcen, beinhaltet ein tiber Jahre hinweg gewachsenes Know-how und zwingt somit ein Unternehmen, die bestehenden Anwendungen bei der Umsetzung einzubeziehen [vgl. Inmon 2000; Morin 1999]. Das Informationssystem muss sich deshalb evolution~ir an das sich ver~indemde Unternehmensumfeld anpassen, d.h. bestehende Komponenten sind weitgehend wiederzuverwenden und durch Integration gem~iss den neuen Abl~iufen miteinander zu verbinden. Die Berticksichtigung der Altanwendungen bringt jedoch eine Reihe von Problemen mit sich [vgl. Gileadi 2000]. So sind diese h~iufig funktional ausgerichtet, d.h. sie decken betriebliche Funktionsbereiche ab, und untersttitzen eher vertikale als horizontale Informationsfltisse. Die im Kern sauberen Architekturen der Anwendungen wurden durch Weiterentwicklung und Integration zugekaufter LOsungen h~iufig intransparent und es entstanden oftmals Redundanzen in der Datenhaltung und Funktionalit~it. Als Folge davon ist die exakte Wirkungsweise der Komponenten von Informationssystemen nicht mehr ersichtlich [vgl. Hughes 2001, S. 3].

2

1 Einleitung

Die Integration von Anwendungen 1 - seien es alte oder neue, Standardsoftware oder Eigenentwicklungen, vorgefertigte Komponenten verschiedener Hersteller oder ganze Informationssysteme zuvor konkurrierender Unternehmen - stellt einen Erfolgsfaktor ftir die Anpassung der Untemehmensabl~iufe an Gesch~iftsanforderungen dar [vgl. Moynihan 1990, S. 17ff; Osterle 1996b, S. 20; Ruh et al. 2001, S.1; Stokes 2001, S.1; Trino 1990]. Demgegeniiber steht die in vielen Unternehmen verbreitete Integrationspraxis, geschickte "ad hoc" L~sungen mit schnellen, aber sp~iter nur noch schwer nachvollziehbaren Realisierungen umzusetzen [Gartner Group 1999, S. 4f; Mowbray/Zahavi 1995, S. 8f]. Diese fiihrt zu einem hohen Mass an Verflechtungen, inkonsistenten Daten, Doppeleingaben, umst/indlichen und fehleranf~illigen Datentransfers. Derartige stark verkntipfte Informationssysteme lassen eine ,~mderung der Abl~iufe in den Gesch~iftsprozessen in zunehmenden Masse schwerer werden und nur mit erheblichem Wartungsaufwand zu [vgl. Morin 1999]. Fiir die Entwicklung neuer Anwendungen oder Informationssysteme existiert heute eine Vielzahl von Methoden. Die Umsetzung von Gesch~iftsprozessen, die Weiterentwicklung von bestehenden Informationssystemen, die unterschiedlichen Varianten der Integration werden jedoch zu wenig in derartigen Methoden berticksichtigt. Insgesamt steht der strategischen Bedeutung der evolution~iren Weiterentwicklung eines Informationssystems mit Hilfe der Integration eine unstrukturierte Vorgehensweise in der Praxis und eine einseitige Betrachtung des Problemfelds gegeniiber.

1.2 Ziele und Adressaten der Arbeit

Ziele

Die Arbeit strebt einen umfassenden Ansatz fiir die evolution~ire Anpassung eines Informationssystems an ge~inderte Anforderungen aus dem Untemehmensumfeld mit Hilfe von Enterprise Application Integration (EAI) an. EAI umfasst die Planung und Durchfiihrung der Integration von heterogenen Anwendungen in und zwischen Untemehmen und beinhaltet die Prozess- und Systemintegration. Im Vordergrund steht dabei die Integration von TeillSsungen, statt einer umfassenden Soll-Informationssystemarchitektur wird eine Architektur der Schnittstellen angestrebt. Voraussetzung ftir einen solchen Ansatz ist ein Vers~ndnis der Ver~inderungen im Unternehmensumfeld, welche eine Weiterentwicklung und somit Integration von Komponenten des Informationssystems in der Weise bewirken, dass sie nicht mit bekannten Methoden der Informationssystementwicklung erftillt werden k~nnen.

1 Integrationvon Anwendungen,Anwendungsintegrationund EnterpriseApplicationIntegration(EAI) werden synonymverwendet.

1.2 Zieleund Adressaten der Arbeit

3

Weiterhin miissen die verschiedenen Konzepte der Integration und deren Abh~ingigkeiten sowohl auf technologischer als auch applikatorischer Ebene bekannt sein. Im Einzelnen verfolgt die Arbeit die folgenden Ziele: 9

Die Einflussfaktoren und Anforderungen for die Prozess- und Systemintegration identifizieren.

9

Die Heterogenit~it yon Anwendungen als Problembereich der Integration darstellen.

9

Die Auswirkungen unterschiedlicher Integrationsarten auf die Situation im Informationssystem aufzeigen.

9

Ein Integrationsmodell erarbeiten, das 9 die Objekte der Anwendungsintegration identifiziert, 9 for Prozess- und Systemintegration die unterschiedlichen konzeptionellen und technologischen Varianten gegeneinander abgrenzt, 9 die jeweiligen Rahmenbedingungen und Voraussetzungen for die Integration erkl~irt und 9 fOr die Prozess- und Systemintegration ein methodisches Vorgehen anbietet.

9

Am Beispiel der Prozessumsetzung das Zusammenspiel der Prozess- und Systemintegration aufzeigen.

9

Die Durchg~ingigkeit vom Prozessentwurf bis hin zur Prozessumsetzung aufzeigen.

Adressaten

Vor dem Hintergrund dieser Zielsetzung richtet sich die vorliegende Arbeit an Adressaten in Wissenschaft und Praxis, welche sich mit der prozessbasierten Transformation von Organisationen und insbesondere des Informationssystems besch~iftigen. Wissenschaftlern liefert die Arbeit prim~ir Beitr~ige zu einer anderen Strukturierung des Problemfelds Integration sowie zur Systementwicklung. Im Mittelpunkt der Integrationsabhandlungen stehen nicht die tiblichen Kategorisierungen wie Daten- und Funktionsintegration, sondem die Problematik wird aus dem Blickfeld der evolution~iren Weiterentwicklung eines Informationssystems mit Hilfe der Integration beleuchtet. Das umfassende Modell der Prozess- und Systemintegration soll als Ordnungsrahmen for das komplexe Themenfeld der Integration dienen. Der L6sungsansatz for das methodische Vorgehen bei der Prozess- und Systemintegration schliesst die Lticke g~ingiger Entwicklungsmethoden in Bezug auf die Integration und tr~igt damit zur Weiterentwicklung des zentralen Forschungsgebiets der Wirtschaftsinformatik bei. Den Praktiker in Organisation und Informatik der Untemehmen unterstiitzt die Arbeit bei der Umsetzung neu entworfener Gesch~iftsprozesse in einem heterogenen Informationssystem. Sie zeigt ihm auf, welche Varianten for Prozess- und Systemintegration m6glich sind, wann

4

1 Einleitung

diese einzusetzen und wie sie allenfalls miteinander zu kombinieren sind. Der Beitrag, den ver~gbare Technologien im Bereich der Prozessintegration und der Systemintegration leisten, wird ebenfalls erkl~irt. Projektverantwortlichen gibt die Arbeit durch die methodischen Vorgehensmodelle das erforderliche Werkzeug, um entsprechende Vorhaben konkret zu planen und zu realisieren.

1.3 Einordnung der Arbeit Zur L6sung der Integrationsproblematik sind Erkennmisse und Ans~itze mehrere Wissenschaftsdisziplinen notwendig. Methoden der Betriebswirtschattslehre sind for Strategieentscheidungen sowie die Gestaltung der ad~iquaten Gesch~iRsprozesse notwendig. Die anschliessende Umsetzung der Gesch~iftsprozesse erfordert Methoden und Techniken aus der Informatik. Die Methoden und Vorgehensweisen sind miteinander in Einklang zu bringen Aufgrund ihrer Zielsetzung ist die Arbeit der Wirtschaffsinformatik zuzuordnen. Die Wirtschaffsinformatik befasst sich mit der Konzeption, Entwicklung, Wartung und Nutzung von Informations- und Kommunikationssystemen, welche sich aus menschlichen und maschinellen Komponenten zusammensetzen. Die Komponenten sind voneinander abh~ingig, greifen ineinander und wirken zusammen [s. Lehner 1997]. Im Mittelpunkt steht die UnterstOtzung der Er~llung betrieblicher Aufgaben. Wirtschaftsinformatiker wenden Methoden und Werkzeuge aus den Real-, Formal- und Ingenieurwissenschaften an und entwickeln diese weiter. Es sind dabei nicht nur technologische Fragen von Interesse, sondern auch die 6konomische und soziale Einsetzbarkeit. Die vorliegende Arbeit befasst sich mit dem Gestaltungsaspekt von Informationssystemen und Integrationsbeziehungen sowie der Entwicklung von Methoden fi~r die Prozess- und Systemintegration und zeigt die Umsetzung von Gesch~iftsanforderungen in Informationssystemen. Aufgabe einer solchen konzeptionellen Integration sind die Ermittlung des Integrationsbedarfs in Abh~ingigkeit von den Anforderungen der Gesch~ittsprozesse, die Untersuchung der Integrationsvarianten, die Spezifikation der Integrationsbeziehungen zwischen den Anwendungen und die Definition von Vorgaben ~ r die Realisierung der erforderlichen Schnittstellen und Anpassungen des Informationssystems [Frank/Klein 1992].

1.4 Vorgehen und Forschungsmethodik Wirtschaftsinformatik wird in dieser Arbeit als angewandte Wissenschaft verstanden. Sie bezieht ihre zu 18senden Probleme aus der Praxis, ist interdisziplin~ir, bezieht die Forschung auf das Gestalten der betrieblichen Wirklichkeit und entwickelt Handlungsanweisungen for die Praxis. Ihre Aussagen sind wertend und normativ und ihr Forschungskriterium ist die praktische Probleml/Ssungskraft ihrer Modelle und Handlungsanweisungen [vgl. Ulrich 1984, S.202f].

1.4 Vorgehenund Forschungsmethodik

5

Auf Grundlage dieser Charakteristika ist der dieser Arbeit zugrunde liegende Forschungsprozess definiert. Er ist der Methode des Action Research bzw. der Aktionsforschung entnommen [vgl. Checkland/Holwell 1998; Frank et al. 1998; Horn 1979] und differenziert fiinf zentrale Schritte: 9

Praxis und Wissenschaft definieren gemeinsam die Problemstellungen

9

Die Wissenschaft strukturiert die Probleme und entwickelt Vorschl~ige zur Gestaltung der betrieblichen Wirklichkeit.

9

Die Vorschl~ige werden gemeinsam mit der Praxis tiberprtift und weiter detailliert.

9

Die Praxis gestaltet die betriebliche Wirklichkeit entsprechend den erarbeiteten Vorschl~igen.

9

Praxis und Wissenschaft tiberprtifen gemeinsam die Ergebnisse und entwickeln die Vorschl~ige weiter.

Das Forschungsprogramm Informationsmanagement HSG (IM HSG) am Institut fiir Wirtschaftsinformatik der Universit~it St. Gallen basiert auf einem derartigen Forschungsprozess. Das Programm umfasst eine Reihe von Kompetenzzentren, die sich tiber einen l~ingeren Zeitraum mit strategischen Themen des Business Engineering und angrenzenden Gebieten der Wirtschaftsinformatik in enger Kooperation zwischen dem Institut fiir Wirtschaftsinformatik und fiihrenden Unternehmen aus der Schweiz und Deutschland besch~iftigen. Die vorliegende Arbeit entstand im Rahmen des Kompetenzzentrums "Prozess- und Systemintegration" (CC PSI) des Forschungsprogramms IM HSG. Schwerpunkt der Forschung des CC PSI war der Entwurf einer umfassenden Methode zur Weiterentwicklung des Informationssystems, welche die Planung und Durchfiihmng der Integration heterogener Anwendungen im Unternehmen umfasst. Im CC PSI besch~iftigten sich ftihrende Schweizer Unternehmen (vgl. Vorwort) und das Institut fiir Wirtschaftsinformatik mit den Themen Workflow-Management, Prozessintegration und-umsetzung sowie Systemintegration von Anwendungen. Als Teilergebnisse entstanden 9

Eine Methode zur Beschreibung des Ist-Informationssystems. Im Mittelpunkt dieser Methode steht die Dokumentation der Schnittstellen zwischen den Teilsystemen des Informationssystems [Gassner 1996].

9

Eine Methode zur Entwicklung von Workflow-Anwendungen [Derungs 1997a].

9

Eine Abhandlung der m6glichen Integrationstechnologien und ein Methodenvorschlag for die Integration heterogener Anwendungen [Riehm 1997].

9

Ein methodischer L6sungsansatz fiir die Planung der Prozessumsetzung [Becker 1998].

6

1 Einleitung

Die vorliegende Arbeit verbindet die Teilergebnisse zu einem ganzheitlichen L6sungsansatz fOr die Weiterentwicklung von Informationssystemen. Den oben genannten Forschungsprozess hat sie wie folgt umgesetzt: 9

Die Partneruntemehmen des CC PSI und das Institut fOr Wirtschaftsinformatik definierten die Anforderungen an die jeweiligen Teilergebnisse.

9

Das Institut erhob einerseits die vorhandenen Integrationsans~itze und andererseits bestehende Methoden.

9

Partnemntemehmen und das Institut verglichen die Ergebnisse, identifizierten grundlegende Defizite und tiberarbeiteten die Anforderungen an eine Methode zur Weiterentwicklung eines Informationssystems mit Hilfe der Integration.

9

Das Institut entwickelte erste Versionen fOr methodische Vorgehensweisen in den Teilbereichen des CC PSI.

9

Die Untemehmen setzten die Vorschl~ige in Pilotprojekten ein.

9

Die Unternehmen und das Institut diskutierten die daraus resultierenden Ergebnisse und Erfahrungen.

9

Die gesammelten Erfahrungen und Anregungen fOhrten jeweils zu einer neuen Version der Methodenvorschl~ige.

Dartiber hinaus flossen die Methoden fOr Workflow-Management sowie fOr die Systemintegration in Praxisprojekte der beteiligten Partnerunternehmen ein. Die dort gesammelten Erfahrungen sind ebenfalls in die vorliegende Arbeit eingegangen. Nach Abschluss der Forschungsarbeiten wechselte die Autorin yon der Universit~it in die Praxis und konnte w~ihrend ihrer T~itigkeit die Ergebnisse nochmals verifizieren.

1.5 Aufbau der Arbeit Anhand einiger Fallbeispiele aus der Praxis leitet das Kapitel 2 die wesentlichen Integrationsausl6ser, -potentiale und insbesondere -probleme ab. Es zeigt, dass trotz strategischer Bedeutung der Integration sowohl der Integrationsprozess als auch die Auswirkungen von Integrationsentscheidungen nicht hinreichend beherrscht werden. Kapitel 3 legt die Grundlagen fOr die weitere Arbeit, grenzt den Bezugsrahmen der Arbeit sowie zentrale Begriffe ab und zeigt die Forschungsbemtihungen im Rahmen der Integration auf. Das zentrale Integrationsmodell ist Gegenstand des Kapitels 4. Es ordnet die Integration in das Business Engineering, zeigt die zu gestaltenden Objekte der Integration, gibt mit der Prozessumsetzung ein Anwendungsbeispiel fOr das Integrationsmodell, fOhrt die Prozess- und Systemintegration im Oberblick ein und geht auf die Bedeutung yon Architekturen und Standards fOr die Integration ein.

1.5 Aufbauder Arbeit

7

Kapitel 5 befasst sich ausfahrlich mit der Prozessintegration. Es zeigt, welche Entscheidungen zu einem Bedarf an Prozessintegration fahren, welche Voraussetzungen zu erfallen sind und welche Varianten zur Verfagung stehen, bevor es ein methodisches Vorgehen far die Prozessintegration vorstellt. Kapitel 6 geht analog mit der Systemintegration vor. Kapitel 7 fasst die Ergebnisse der Arbeit zusammen und gibt einen Ausblick. Die folgende Abbildung zeigt den Aufbau der Arbeit schematisch auf.

2 Problemabgrenzung Im Informationszeitalter nimmt die Integration von Anwendungen (Synonym fiir Enterprise Application Integration (EAI)) eines Informationssystems eine Schl~isselstellung ein. Dabei spielt es keine Rolle, ob es sich um innerbetriebliche, d.h. die Anwendungen sind Bestandteil des Informationssystems eines Unternehmens, oder um zwischenbetriebliche Integration handelt, d.h. die Anwendungen sind jeweils Komponenten von Informationssystemen zweier oder mehrerer Unternehmen. Fusionen und Kooperationen von Unternehmen setzen eine Integration der vorher unabh~ingigen Gesch~iftsstrategien voraus und k6nnen in der Regel nur dann erfolgreich umgesetzt werden, wenn es gelingt die unterschiedlichen Informationssysteme entsprechend den neuen Zielsetzungen miteinander zu integrieren [vgl. Lutz 2000; Von Stengel 2000]. Die Managementtrends Business-to-Business Integration und Ausdehnung des Business auf das Internet k6nnen ebenfalls nicht ohne Integration der internen Prozesse sowie deren unterstfitzenden Anwendungen erfolgreich umgesetzt werden [vgl. Lublinsky 2001; Murray/Trefts 2000].

Enterprise Application Integration ist von strategischer Bedeutung und spielt sich haupts~ichlich auf der techniknahen Ebene des Business Engineering, der Informationssystemebene, ab.

10

2 Problemabgrenzung

Dennoch gibt es eine Vielzahl von Problemen im Zusammenhang mit der Integration. Zur Verdeutlichung dieser Aussage beschreiben die folgenden Abschnitte einRihrend anhand einiger ausgew~ihlter Beispiele unterschiedliche Integrationssituationen und -projekte (Abschnitt 2.1), um daraus ableitend die verschiedenen Ausl6ser von Integrationsbemtihungen zu erkl~iren (Abschnitt 2.2), auf die Potentiale der Integration einzugehen (Abschnitt 2.3) und abschliessend die Probleme der Integration zu beleuchten (Abschnitt 2.4) (Abb. 2.1).

2.1 C a s e - S a m m l u n g Die folgenden Beispiele aus der Praxis sollen den Leser in verst~indlicher Weise in die Integrationsproblematik ein~hren. Sie geben bereits einen Einblick auf die Vielfalt und Komplexit~it der Fragestellungen im Zusammenhang mit der Integration. Dartiber hinaus konnten durch die aktive Mitarbeit in den Projekten Erfahrungen gesammelt werden, welche fiir die Behandlung der Integrationsproblematik in der vorliegenden Arbeit von grosser Bedeutung waren. Die Praxisbeispiele zeigen exemplarisch unterschiedliche Ausl6ser fiir eine Integration auf Informationssystemebene, sowie mSgliche Wechselwirkungen zwischen den unterschiedlichen Ebenen des Business Engineering. So zeigen die Beispiele der Bank Austria (Abschnitt 2.1.1) und der SECURA (Abschnitt 2.1.2), wie strategische Entscheide und Prozessreengineering zu Integrationsprojekten ~hren k6nnen. Das Kontron Beispiel (Abschnitt 2.1.3) zeigt die Auswirkungen einer Anderung im Bereich des Informationssystems auf die Integration. Weiterhin lassen sich aus den Beispielen die wesentlichen Fragen im Rahmen der Integration ableiten sowie einzelne Problemfelder der Integration identifizieren. Insbesondere das AGI Beispiel (Abschnitt 2.1.4) zeigt, welche Probleme innerhalb von Integrationsprojekten anzugehen sind.

2.1.1 Bank Austria

Die Bank Austria ist die fiihrende Finanzdienstleistungsgruppe ()sterreichs und nimmt auch im europ/~ischen Ranking einen Platz im Vorderfeld ein [Bank Austria 2001]. Seit Februar 2001 ist die Bank Austria eine knapp 100%ige Tochter der HypoVereinsbank [Bank Austria 2002]. Vor einigen Jahren hat die Bank Austria ihre Gesch/fftsstrategie modifiziert [s. Osterle 1996b, S. 3ff]. Sie entschloss sich, den Vertrieb, wie andere Banken auch, nach Kundensegmenten zu organisieren und somit die Organisation nach Produkten (Sparten) abzul6sen. Mit der Kundenorientierung verfolgen die Banken das Ziel einer erh6hten Kundenzufriedenheit. Heute kann die Differenzierung der einzelnen Marktteilnehmer angesichts der Fi~lle von Produktangeboten und der zunehmenden Austauschbarkeit der einzelnen Produkte fast nur noch fiber den Service geschehen [vgl. Kaiser et al. 1998, S. 7; Schmid 1995, S. 72-77]. Zukiinftig sollte sich der Bank Austria Kunde darauf verlassen k6nnen, dass sein Kundenberater seine pers6nliche Situation kennt und ihm alle Produkte aus einer Hand zuverl/issig und kompetent anbieten kann.

2.1 Case-Sammlung

11

Dieser strategische Entscheid und die damit verbundene Neuorganisation der Bank fahrten zu neuen Anforderungen an die Qualifikation der Mitarbeiter und die Untersttitzung des Vertriebsprozesses durch das Informationssystem [vgl. Price Waterhouse 1996, S. 31 ]. Ein Mitarbeiter darf nicht mehr nur ein Spezialist far ein einzelnes Produkt sein, sondem muss die gesamte Palette von Produkten und Dienstleistungen der Bank dem Kunden kompetent anbieten k6nnen. FOr Detailfragen zu einzelnen Produkten kann er Spezialisten hinzuziehen. Somit werden alte Schnittstellen (zwischen den Produkten) durch neue (zwischen dem Kundenberater und dem Produktspezialisten) ersetzt. Die Integrationsdimension hat sich ge~indert, wodurch auch neue Ftihmngsmittel notwendig wurden. Neue Koordinationsmechanismen far die Schnittstellen mussten geschaffen werden, um die Weitergabe neuester Produktinformationen von Produktspezialisten zu den Kundenberatern zu gew~ihrleisten. Mit Hilfe eines Prozessentwurfs setzte die Bank die Entscheidungen der Strategie in den Prozess Privatkundenbetreuung um. Das Projektteam ermittelte zusammen mit Kundenbetreuem die Aufgaben des Prozesses, fasste sie zu Abl~iufen zusammen, definierte erste Anforderungen far die Untersttitzung durch das Informationssystem und legte Ftihrungsgr6ssen fest. Um alle Schritte bei der Kundenberatung ausfahren zu k6nnen, muss ein Kundenberater Zugriff auf alle far das Kundengespr~ich notwendigen Informationen haben. Die Bank Austria verfagte bereits tiber einige erforderlichen Anwendungen wie ein Kundeninformationssystem, ein Kreditsystem, ein Zahlungssystem und ein Kalendersystem und hatte Btirosoftware im Einsatz. Ftir die spezifische Beratungsfunktionalit~it kaufte sie eine Standardanwendungssoftware zu. Somit war die vom Prozess Privatkundenbetreuung geforderte Funktionalit~it beinahe vollst~indig vorhanden, jedoch nicht mit den entsprechenden Verkntipfungen. Da die Anwendungen far die frahere Spartenorganisation entwickelt worden sind, spiegeln sie deren Logik wieder. Das Projektteam musste deshalb die vorhandene Funktionalit~t gem~iss dem neu deftnierten Prozess anders miteinander verkntipfen, das heisst, die Anwendungen entsprechend integrieren. Dabei war nicht nur die Integration gem~iss dem logischen Ablauf die Herausforderung, sondern auch die Oberwindung von technologischen Hemmnissen, denn es lag eine heterogene Landschaft der Systemsoftware vor, die es zu tiberbrticken galt. Der notwendige Aufwand far die Realisierung der Anforderungen war aus diesen Grtinden gr6sser als ursprtinglich erwartet.

Zusammenfassung Ausl6ser far die Integrationsanstrengungen im Rahmen des Informationssystems war bei der Bank Austria ein Entscheid auf der Strategieebene. Dieser Entscheid fahrte zu der Notwendigkeit, die Prozesse neu zu gestalten, was wiederum Modifikationen im Informationssystem veranlasste. Integration von Anwendungen wurde nicht zum Selbstzweck, sondern zur effizienten Untersttitzung von Prozessen betrieben.

12

2 Problemabgrenzung

2.1.2 SECURA Versicherungsgesellschaften Die SECURA Versicherung aus Zfirich bietet ein breites Spektrum an Versicherungsdienstleistungen vorwiegend ~ r den Marktsektor der Privatkunden an [SECURA 1998] 2. Bereits 1993 besch~iftigten sich einzelne Verantwortungstr~iger der Gesellschaff intensiv mit den Themen Business Process Reengineering und Workflow-Management. Marktgegebenheiten und Probleme im Bereich der Informationssysteme Rihrten zur Neuausrichtung einzelner strategischer lJberlegungen [s. Blaser/Meiler 1996, S. 20f]. Ausgehend von den strategischen Vorgaben, 9

die Qualit/~t der Marktleistungen zu verbessem,

9

das Kemgesch~ift nach wirtschaftlich optimierten Gesichtspunkten neu abzuwickeln und

9

Grundlagen fiir eine schnelle und flexible verwaltungstechnische Handlungsf~ihigkeit zu schaffen,

startete die SECURA ein BPR-Projekt zur Identifikation der neu zu gestaltenden Prozesse. Im Jahre 1995 Rihrte das Untemehmen eine Reorganisation des Gesch~iftsbereichs Motorfahrzeuge durch. Nach der Neuformulierung der Gesch~iftsstrategie erfolgte eine Oberarbeitung der Kemprozesse Neugesch~ift und Mutationen [s. Becker et al. 1998, S. 18]. Die Untersttitzung der hoch integrierten Prozesse durch die Informatik war eine entscheidende Voraussetzung bei der Gestaltung der Prozesse. Deshalb definierte die SECURA bereits w~ihrend des Prozessentwurfs unter Berficksichtigung der IT-Strategie Richtlinien Rir die Entwicklung der technologischen Plattform zur Umsetzung der Prozesse. Folgende Zielvorgaben sollte die Prozessumsetzung erreichen [s. Becker et al. 1998; Blaser/Meiler 1996]: 9

EinRihrung einer Client/Server Architektur Rir den Office Bereich

9

Umstellung des Dokumentenmanagements aufeine optische Archivierung

9

Prozesssteuerung mit einem zugekauften Workflow-Managementsystem

9

Ausbau der Hardware-Infrastruktur und der Netzwerk-Kapazit~iten

9

Integration der dezentralen Office-Umgebung mit den vorhandenen zentralen Host-Systemen.

Die potentiellen L6sungen fiJr die Prozessumsetzungen sollten zudem die vorhandenen und die neu zu entwickelnden betriebswirtschaftlichen Anwendungen in die Workflows einbinden. Eine substantielle ,~nderung der vorhandenen Host-Applikationen kam nicht in Frage. Diese Konstellation erforderte deshalb vor allem eine Integration der Host- und OfficeAnwendungen mit dem Workflow-Managementsystem.

2 Die SECURAVersicherungensind 2000 mit der GeneraliVersicherungfusioniert.

2.1 Case-Sammlung

13

Zusammenfassung Ebenso wie bei der Bank Austria waren bei der SECURA strategische Uberlegungen der Ausgangspunkt fiir eine lSIberarbeitung der Prozesse. Die Zielvorstellungen gestalteten sich hier jedoch etwas anderes, denn das Untemehmen legte grossen Wert auf eine Rationalisierung des Prozessablaufs und nicht auf die Neugestaltung der Gesch~iftsstrategie und Prozesse. Eine Steuerungskomponente in Form eines Workflow-Managementsystems sollte als tibergeordnetes organisatorisches Ftihrungssystem den Arbeitsfluss zwischen den beteiligten Stellen regeln und Ftihrungsgr6ssen fiir den Prozess liefem. Informationstechnisch hatte das Workflow-Managementsystem zudem die Rolle einer Integrationsplattform wahrzunehmen. Parallel dazu entwickelte die Informatik Anforderungen fiir die Weiterentwicklung des Informationssystems. Entscheidungen auf allen Ebenen des Business Engineering beeinflussten in diesem Fall die Gestaltung der Integration.

2.1.3 Kontron embedded computer AG Kontron embedded computer AG entstand 1998/99 aus einem Zusammenschluss der vier Untemehmen Teknor Inc., Boards AG, Teknor GmbH sowie Kontron Elektronik GmbH. Das Untemehmen entwickelt und vermarktet weltweit anspruchsvolle Elektronikprodukte sowie computerbasierte L6sungen und Dienstleistungen fiir professionelle Anwender in Industrie und Forschung [Kontron 2001 ]. Zur St/irkung der Wettbewerbsflihigkeit hat Kontron Elektronik GmbH 1992 mit einer Restrukturierung und Neuorganisation des Untemehmens und seiner Prozesse begonnen. Das bestehende Informationssystem (vgl. Abb. 2.2) gentigte den daraus resultierenden Anforderungen nicht [Becker et al. 1997]: 9

Eine durchg/~ngige Untersttitzung selbst einfacher Gesch~iftsprozesse war nicht m6glich, da das Informationssystem die funktionalen Anforderungen der Prozesse nur unzureichend abdeckte. Die betriebswirtschaftlichen Funktionen waren auf nicht integrierten Applikationen und unterschiedlichen IT-Plattformen verteilt. Teilweise waren sie auch nicht informatisiert.

9

Daten waren redundant in verschiedenen Systemen vorhanden, da zwischen den beiden zentralen Administrationssytemen lediglich eine Batch-Schnittstelle fiir einen t~iglichen Abgleich bestand.

9

Die Datenverteilung erforderte in vielen F~illen eine manuelle und damit zeitintensive Aggregation und Konsolidierung fiir die Aufbereitung an das Management.

9

Das Reporting war aufgrund unzureichender Standardisierung und Konsolidierung der Anforderungen uneffizient.

9

Das Entwicklungspotential der zentralen Applikationen war gering.

14

2 Problemabgrenzung

Kontron Elektronik definierte deshalb im Folgenden die Anforderungen an eine neue L6sung: 9

Es sollte eine integrierte Standardsoftware mit einheitlicher Systemumgebung und hoher Verfiigbarkeit sein.

9

Das neue Informationssystem sollte auf zukunftssicherer Technologie beruhen.

9

Die L6sung musste eine hohe Oberdeckung mit den betriebswirtschaftlichen Anforderungen und eine hohe Flexibilit/~t aufweisen.

9

Eine Client-Server-Architektur war Voraussetzung, welche eine Anbindung der PC-Arbeitspl~tze und die Integration mit den Office-Anwendungen sicherstellte.

9

Die L6sung musste eine Integration mit anderen betriebswirtschaftlichen Anwendungen erm6glichen.

9

Ein flexibles Reportingsystem musste m6glich sein.

Die durchge~hrte Ausschreibung und die anschliessende Analyse der Software auf Basis zweier Gesch/fftsprozesse fiihrten zur Auswahl der Standardsoftware SAP/R3. Kontron Elektronik 16ste mit SAP/R3 eine Reihe von isolierten PC-Applikationen sowie die bisherigen betriebswirtschaftlichen Applikationen und deren Systemplattformen vollst~ndig ab. SAP/R3 bildete fortan die zentrale Softwareplattform mr die betriebliche Administration.

2.1 Case-Sammlung

15

Diese Abl6sung erforderte im EinfiJhrungsprojekt einen erheblichen Aufwand (ca. 150 Tage) Rir die Datentibernahme aus den Altsystemen. Es entstand eine Reihe von tempor~iren Schnittstellen. Das produktive R/3-System ben6tigte zudem weitere Schnittstellen zu anderen Applikationen im Unternehmen, wie z.B. ~ r die Obemahme von Fertigungsinformationen aus einer PCApplikation.

Zusammenfassung Am Beispiel Kontron Elektronik l~isst sich der Integrationsbedarf bei der Einfiihrung einer Standardsoftware zeigen. Die Ein~hrung einer Standardsoftware 16st in Bezug auf Integration zwei Arten von Schnittstellen-Bedarfen aus: 1. Das Unternehmen muss bei der Abl6sung der Altsysteme die Daten in das neue System tibemehmen. Ftir diese Migration stehen unterschiedliche Vorgehensvarianten zur Ver~gung. Jede der Varianten ~hrt jedoch zu der Konzeption und Implementierung einer Reihe von tempor~iren Schnittstellen. 2. Deckt die Standardsoftware nicht alle betriebswirtschaftlichen Funktionen ab und sind ~ r diese weitere Applikationen im Unternehmen vorhanden, so werden permanente Schnittstellen zwischen den Applikationen notwendig. Alle notwendigen Schnittstellen werden durch diejenigen Prozesse definiert, welche die Software zur AufgabenerRillung ben6tigen. Auch die Ein~hrung neuer Anwendungen kann nicht losgel6st von den Geschaftsprozessen vorgenommen werden. Die zu schaffenden Schnittstellen definieren sich aus den Gesch~iftsabl~iufen in Verbindung mit den bereits vorhandenen Anwendungen des Informationssystems.

2.1.4 AGI Gruppe Anfang 1996 haben die AGI (Aktiengesellschaft Rir Informatik) Partner-Banken ihre gesamten Informatik-Abteilungen inklusive Rechenzentren in die AGI Holding AG 3 (mit den Tochtergesellschaften AGI Service AG und AGI Software AG) zusammenge~hrt. Die entstandene AGI-Gruppe evaluiert, entwickelt, integriert, wartet und betreibt Bankinformatik-Anwendungen auf allen Stufen, d.h. vonder Host-Anwendung tiber Abteilungsserver bis zur sogenannten Client-Stufe, dem Endbenutzer. Die AGI bietet zudem in ihrem Rechenzentrum Kapazit~its-Outsourcing und L6sungen f'tir die Katastrophenvorsorge an und tibernimmt ~ r die Partnerbanken vor Ort auch untersttitzende Funktionen im Information-Center und EDVBereich bis hin zur informatikgesttitzten Telefonie [AGI I-Net Solution 1999].

3 Laut Pressemitteilung vom 07.09.2001 fusionierendie AGI IT Services AG mit der Swisscom IT Anfang 2002 zur Swisscom IT Services AG.

16

2 Problemabgrenzung

Die AGI Partner-Banken setzen neben gemeinsamen Bankanwendungen auch noch eine gr6ssere Zahl von bankindividuellen Anwendungen ein. Mit dem Projekt TEMPO wurden flar alle Bankgesch~ifte und -produkte die unterschiedlichen Bankplattformen und damit auch organisatorischen Abl/iufe bzw. Prozesse zu einer einheitlichen Plattform vereinigt. Innerhalb des Projekts wurden verschiedene Teilprojekte mit den folgenden Schwerpunkten bearbeitet [AGI I-Net Solution 1999]: 9

Aufbau und Betrieb eines neuen Rechenzentrums

9

Entwicklung einer Bankanwendung nach einem objektbasierten Ansatz

9

Integration von Eigenentwicklungen und Standardanwendungen (z.B. SAP)

9

Einfiihrung des EURO

9

Migration der Daten auf die neue Plattform

9

Organisation und Durch~hrung der Schulung fiir die neue Plattform.

Spezifische Bankanwendungen und einzusetzende Standardsottware verwenden zum Teil die gleichen Daten. So ben6tigen mehrere Anwendungen Personendaten, Kontoinformationen, Depotinformationen usw., welche gr6sstenteils auf dem Host gepflegt werden. Um diese Daten allen Programmen konsistent zur VerRigung zu stellen und effizient zu verwalten, wurde eine zentrale Anwendung l'tir die Bereitstellung der gemeinsamen Daten flir alle Applikationen geschaffen. Das Grobkonzept sah eine Anwendung vor, die ~ r den Datenzugriff der Frontapplikationen z.B. auf die Hostdaten, fiir die tempor/~re Datenhaltung der ben6tigten Daten sowie ftir den Datenaustausch zwischen Host- und Standardanwendungen verantwortlich sein sollte (vgl. Abb. 2.3).

2.1 Case-Sammlung

17

Ftir die Integration der beteiligten Anwendungen identifizierte die AGI unterschiedliche Integrationsvarianten sowie die zur Auswahl stehenden Architekturvarianten fiir die Integration. Dabei spielten auch die Architekturen der beteiligten Anwendungen selbst eine wesentliche Rolle. Die detaillierte Analyse der ersten einzufiihrenden Standardsoftware zeigte jedoch sehr schnell, dass sich der Ansatz einer zentralen Anwendung nicht in der vorgesehenen Weise realisieren liess. Die Architektur der zugekauften L6sung liess keine Trennung der gemeinsamen und der anwendungsindividuellen Daten zu. Eine Modifikation der Informationssystemarchitektur war notwendig. Ziel der Modifikation war es, die Datenhaltung der gemeinsamen Daten den Anforderungen der Anwendungen anzupassen, so stellen z.B. auswertungsorientierte Anwendungen weniger Ansprtiche an die Performance der Datenhaltung als transaktionsorientierte, operationelle Frontanwendungen. Um den Integrationsaufwand ftir die weiteren geplanten Anwendungen (sei es zugekauft oder eigenentwickelt) m6glichst niedrig zu halten und ein standardisiertes Vorgehen fiir die Handhabung der gemeinsamen Daten zu erhalten, definierte die AGI eine Integrationsarchitektur mit drei wesentlichen Merkmalen: 9

Eine Middlewareschicht ist im wesentlichen ~ r den Datenaustausch verantwortlich.

9

Ein Redundanzmanager ist fiir die Sicherstellung der konsistenten Datenhaltung vorgesehen.

9

Die auswertungsorientierten Anwendungen greifen mittels SQL auf die entsprechenden Datensammlungen zu (vgl. Abb. 2.4).

Die Middlewareschicht stellt eine gewisse Standardisierung der Schnittstellen sicher, da jede Frontanwendung nur noch eine Schnittstelle zu dieser Schicht anbieten muss, welche dann den Datenaustausch zur gewtinschten Anwendung regelt. Damit erreichte die AGI eine kostengtinstige und schnelle Anbindung verschiedener Anwendungen sowie einfachere Integrationsprojekte. W~ihrend der Analyse der zugekauften Anwendung zeigten sich folgende Probleme der Integration: 9

Das Datenmodell der zugekauften L6sung musste erst beschafft werden, es ist nicht im Lieferumfang enthalten.

9

Das Datenmodell liess sich nicht mit CASE-Tools auswerten, da technologische Hemmnisse einen zu hohen Aufwand erfordert h~itten.

9

Die zu betrachtenden Datenmodelle basierten auf unterschiedlichen Notationen. Deshalb wurde ein eigenes Datenmodell notwendig.

9

In den Datenmodellen wurde keine einheitliche "Sprache" verwendet. Selbst bei der Verwendung gleicher Begriffe war kein einheitliches Begriffsverst~indnis automatisch gegeben.

18

2 Problemabgrenzung

Zusammenfassung Die AGI machte die Erfahrung, dass die Integration von zugekauffen Anwendungen auch trotz einer gewissen Standardisierung der Schnittstellen und der Anwendungsarchitekturen sowie einer Vielzahl von Middlewarediensten noch mit sehr viel "Handarbeit" verbunden sein kann. Ein L6sungskonzept auf logischer Ebene kann h~iufig durch technologische Rahmenbedingungen behindert oder verhindert werden. Deshalb muss eine Integrationsarchitektur die m/Sglichen Architekturen der Anwendungen sowie die heterogenen Plattformen und die zur Verfiigung stehenden Integrationsmuster (-varianten) beriJcksichtigen und nicht nur auf den Zustand yon heute sondern auch vorausschauend geplant sein.

2.1.5 Zusammenfassung der Cases Der Erfolg der Integration tragt wesentlich zum Erfolg der Neugestaltung der Prozesse bei und ist damit letztendlich auch ftir die Realisierung der ge~inderten Gesch~iftsstrategie eine wesentliche Voraussetzung (s. Bank Austria und Secura). Optimierungsbestrebungen auf der Prozessebene kOnnen zu Integrationsanstrengungen filhren (s. Secura). Eine ablaufkonforme Verbindung der Anwendungen und eine effiziente Steuerung des Prozesses durch entsprechende Steuerungskomponenten helfen Rationalisierungspotentiale auszuschtipfen. Verhindern technologische Hemmnisse eine fiir die Prozessumset-

2.2 AuslOseryon Integration

19

zung notwendige Integration, stellt dies den Prozess und allenfalls auch die zugrunde liegende strategische Entscheidung in Frage. Deshalb kann die Integration von Anwendungen nicht erst auf Ebene des Informationssysterns betrachtet werden, sondern muss bereits bei der Gestaltung von Prozessen und Strategien mit berticksichtigt werden (s. Kontron). Auf Ebene des Informationssystems kann ein logisches L6sungskonzept h~iufig durch technologische Rahmenbedingungen behindert oder verhindert werden. Deshalb muss eine Integrationsarchitektur die m6glichen Architekturen der Anwendungen sowie die heterogenen Plattformen und die zur Verfiigung stehenden Integrationsvarianten berficksichtigen. Dabei darf nicht nur auf den Zustand von heute eingegangen werden, sondern es muss vorausschauend geplant werden (s. AGI). Die Einfiihrung neuer Anwendungen oder Technologien kann nicht losgel6st von den Gesch~iftsprozessen erfolgen, denn die zu schaffenden Schnittstellen definieren sich aus den Gesch~iftsabl~iufen in Verbindung mit den bereits vorhandenen Anwendungen des Informationssystems (s. Kontron).

2.2 Ausl0ser von Integration Die kurzen Beispiele aus der Praxis zeigen, dass unterschiedliche Projektsituationen Integrationsanstrengungen im Rahmen der Informationssysteme initiieren. Nicht nur Anforderungen aus den Informatikabteilungen selbst fiihren zur Notwendigkeit der Verbindung verschiedener Anwendungen, vor allem strategische Entscheidungen oder das Reengineering von Gesch~iftsprozessen erfordern eine Integration bestehender und oder neuer Anwendungen des Informationssystems. Wichtige Trends in der Wirtschafl- Globalisierung, Prozessorientierung, Business Networking, Customer Relationship Management (CRM) und Knowledgemanagement [vgl. Riempp 1998, S. 1f] - basieren auf Anwendungen der Informationstechnologie. In der Regel besitzt jedes Unternehmen bereits ein Informationssystem bestehend aus einer Vielzahl von Anwendungen, die zudem noch auf heterogenen Plattformen realisiert sein k6nnen. Diese Anwendungen enthalten in ihrer Verarbeitungslogik und in den Daten meist ein fiber Jahre hinweg gewachsenes implizites Know-how, das zu schfitzen ist [vgl. Bennett 1995; Eicker et al. 1992]. Zudem sind die einzelnen Anwendungen vielfach miteinander fiber Datentransfers verkntipfl und eine Dokumentation oder der Oberblick fiber alle Integrationsbeziehungen fehlen h/aufig. Diese Tatbest~inde verhindern in der Regel eine Abl6sung des gesamten Informationssystems aufgrund von neuen Anforderungen aus den Prozessen. Vielmehr muss eine Weiterentwicklung des Informationssystems stattfinden, das heisst, bestehende Anwendungen sind zu nutzen, im Bedarfsfall neu miteinander zu integrieren und fehlende Funktionalit~it und Daten durch die Einftihrung und Integration neuer Anwendungen abzudecken. Somit sind die genannten strategischen Trends auch Verursacher von Integrationsbemfihungen auf der Informationssystemebene.

20

2 Problemabgrenzung

Orientiert man sich an den Ebenen des Business Engineering "Strategie- Prozess- Informationssystem" (Abschnitt 3.1), k6nnen die folgenden Projektsituationen zur Integration von Anwendungen im Informationssystem fiihren. Es handelt sich dabei um keine vollst/andige Auflistung, vielmehr sollen die wesentlichen Ausl6ser und deren Auswirkungen auf die anderen Ebenen gezeigt werden.

Ausl6ser auf der Strategieebene Auf Ebene der Strategie erfordem die Entscheidungen zu innovativen Managementans/itzen wie eCommerce eine Intensivierung der bereichs- und untemehmenstibergreifenden Zusammenarbeit. Zudem basieren Produktionsstrategien wie Just in Time (JIT), Lean Supply usw. auf der Koordination komplexer logistischer Ketten tiber die Organisationseinheiten hinweg [vgl. Osterloh/Frost 1996; Scheckenbach 1997]. Diese zunehmende Kooperation autonomer Einheiten spiegelt sich durch einen erh6hten Integrationsbedarf auf der Prozess- und letztendlich der Informationssystemebene wider. 9 Kooperation von Untemehmen Untemehmen sind in ihrer Grundeigenschaft Gebilde, die zur Erflillung ihres Ziels Verbindungen mit anderen Untemehmen eingehen [Milgrom/Roberts 1992, S. 20f]. Arbeiten selbst/indige Untemehmen zur Steigerung ihrer gemeinsamen Wettbewerbsflihigkeit zusammen, so spricht man von Untemehmenskooperation [s. Gabler 1997, S. 2245; Schierenbeck 1993, S. 49]. Die strategische Entscheidung zu solch einer Zusammenarbeit bedingt eine Abstimmung der entsprechenden Gesch/iftsprozesse. Eine effiziente Koordination von Prozessen zwischen Untemehmen setzt auf Ebene des Informationssystems eine Integration der beteiligten Anwendungen voraus. Somit flihrt der strategische Entscheid fiber Projekte auf der Prozessebene zu Integrationsanforderungen auf der Informationssystemebene. Die zunehmende Relevanz der Kooperation von Untemehmen fiihrt damit zu einer Zunahme der Integration [vgl. Lutz 2000]. 9 Merger von Untemehmen Ein Untemehmenszusammenschluss (Merger) ist die freiwillige Vereinigung von Unternehmungen auf dem Vertragswege durch Verschmelzung (Vollfusion) oder Konzemierung (kann zu einem Gleichordnungs- oder Unterordnungskonzem ~hren). Bei Konzernen bleibt die rechtliche Selbst/~ndigkeit der Untemehmungen (AG oder GmbH) erhalten [vgl. Thommen 1996, S. 48]. Dieser strategische Entscheid 16st nicht nur auf der technologischen Seite Integrationsbemtihungen aus [vgl. Connelly 1999, S. 498]. So muss das neu entstandene Untemehmen eine Strategie entwickeln, die durch Integration der beiden bisherigen Strategien entstehen k6nnte. Organisationseinheiten und Untemehmenskulturen mtissen zusammengebracht werden, Prozesse sind zu vereinheitlichen usw. Auf Informationssystemebene sind die unterschiedlichen Plattformen und Anwendungen Integrationsobjekte [vgl. Lutz 2000; Von Stenge12000].

2.2 Ausl0seryon Integration 9

21

Strategische Neuausrichtung eines Unternehmens Die strategische Ausrichtung des Gesch~ifts auf den Kunden sowie die Einmhrung eines Customer Relationship Managements ffihren zu einer Umgestaltung der Prozesse. Die "Integration" von mehreren Leistungen in ein Leistungspaket mr den Kunden kann nur durch Zusammenschluss der entsprechenden Prozesse erfolgen. Eine Zusammenmhrung von bisher getrennten Prozessen erfordert ebenso eine Integration der untersti~tzenden Anwendungen (s. Bank Austria und Secura Case).

AuslOser auf der Prozessebene

Bereits beim Prozessentwurf sind die M6glichkeiten der Integration auf Informationssystemebene entscheidende Einflussfaktoren. Jede Modifikation eines Prozesses, sei es ein radikaler Neuentwurf oder eine kleine Modifikation des Ablaufs, kann sich im untersttitzenden Informationssystem widerspiegeln. Der Prozess legt die Anforderungen an das Informationssystem fest, d.h. er bestimmt den Informationsbedarf und die ben6tigte Funktionalit~it zur Informationsverarbeitung. Betrifft die Anderung des Prozesses mehr als eine untersttitzende Anwendung, sind die notwendigen Integrationsbeziehungen zwischen den beteiligten Anwendungen zu iJberprfifen und im Bedarfsfall neu zu konzipieren [vgl. Schli~ter 1999]. Die an der Prozessgestaltung anschliessende Prozessumsetzung befasst sich somit mit Integrationsfragen entlang des Prozessablaufs (s. Kontron Case). Definiert der Prozess Anforderungen, die sich nicht oder nur mit sehr hohem Aufwand ins Informationssystem umsetzen lassen, kann eine ,~nderung des Gesch~ftsprozesses notwendig sein. Somit setzen das Informationssystem und die Informationstechnologie Rahmenbedingungen for den Prozessentwurf. Sie k0nnen die Entwurfsm0glichkeiten mr Gesch~iftsprozesse eingrenzen und definieren damit die Rahmenbedingungen mr "machbare" Prozesse. Da~ber hinaus k6nnen neue Technologien oder Entwicklungen bei der Middleware die Voraussetzungen mr neue oder besser gestaltete Prozesse schaffen. Die erm0glichte Integration zweier Applikationen mhrt zu neuen Prozessabl~ufen, das bedeutet, die Technologie wird zum Enabler neuer Abl~iufe [vgl. Schlfiter 1999, S. 3].

AuslOser auf der Informationssystemebene

Innerhalb der Informationssystemebene mhren beispielsweise die Einmhrung neuer Anwendungen, die Abl6sung von Anwendungen sowie auch die Migration von Technologieplattformen zu Integrationsanforderungen (s. Kontron oder AGI Case sowie [Frank 2001, S. 283]). Die Einmhrung einer neuen Anwendung muss den relevanten Ausschnitt des Informationssystems definieren, anhand der Prozesse die Anforderungen an die Integration festlegen und letztendlich die einzelnen Integrationsbeziehungen konzipieren und realisieren [vgl. Desmond/Acly 1999].

22

2 Problemabgrenzung

Die Abl0sung einer Anwendung muss sicherstellen, dass alle mit der Anwendung bestehenden Integrationsbeziehungen modifiziert werden und somit die bisher integrierten Anwendungen auch weiterhin die erforderlichen Daten und Funktionen zur Verfligung haben. Durch die Migration von Plattformen k0nnen sich neue MSglichkeiten flir die Integration bisher getrennter Anwendungen ergeben oder aber neue Hemmnisse auftreten.

Wechselwirkungen zwischen den Ebenen Die bisherigen Beschreibungen zeigen eine Top-Down-Betrachtung der Auswirkungen zwischen den Ebenen. In der Praxis mtissen jedoch Einschriinkungen aber auch M0glichkeiten auf unteren Ebenen des Business Engineering Modells berticksichtigt werden, die sich auf die niichst h0heren Ebenen auswirken (vgl. Abschnitt 2.1.5). Ein Prozessdesign, das die technologische Machbarkeit ausser Acht l~isst, kann zu grossen Aufwiinden und Verz0gerungen bis hin zum Projektstop bei der Prozessumsetzung fiihren. Rticksprtinge zum Prozessdesign werden erforderlich und falls sich die Probleme nicht mit kleineren Modifikationen des Prozesses beheben lassen, mtissen eventuell auch die strategischen Entscheide tiberdacht werden. Somit nimmt die Integration von Anwendungen eine Schltisselstellung im Business Engineering ein. Ein Unternehmen, das die Integration nicht ausreichend beherrscht und die Anwendungen als Insell0sungen mit all den dazugeh0rigen Nachteilen realisiert, kann keine effiziente Prozessabwicklung gewahrleisten [vgl. Taviz Technology 2000, S. 3]. Die grafische Darstellung der beschriebenen Ausl0ser von Integrationsanstrengungen zusammen mit ihren Auswirkungen zeigt Abb. 2.5 in Form eines Wirkungsnetzes.

2.3 PotentiellerNutzen der Integration

23

2.3 Potentieller Nutzen der Integration Eine n~ihere Untersuchung der Integrationspotentiale erfordert eine differenzierte Betrachtung gem~iss den unterschiedlichen Integrationsformen 4. Die vorliegende Arbeit konzentriert sich auf die Prozess- und Systemintegration, weshalb die folgende Abhandlung der Potentiale nur die fiJr die Arbeit relevanten Integrationsformen bedicksichtigt. Die gemachten Aussagen und Erkenntnisse gelten sowohl ftir eine inner- wie auch zwischenbetriebliche Betrachtung der Integration. Die Prozessintegration stellt sicher, dass alle Aufgaben eines Prozesses gem~iss der Ablaufdefinition durchgef'tihrt werden und somit nichts in Vergessenheit ger~it [s. Mertens 1995, S. 9; Vogler 1996, S. 348]. Weiterhin ermtiglicht die Prozessintegration mittels einer zentralen Steuerungskomponente ein Monitoring und Reporting von Prozessen. Im Rahmen der Prozessintegration sollen mit Hilfe der Funktionsintegration (Synonym: Vorgangsintegration) die mehr oder weniger ktinstlichen Funktions-, Prozess- und Abteilungsgrenzen und deren negative Auswirkungen vermieden werden [s. Mertens et al. 1996, S. 44]. Die Funktionsintegration er6ffnet somit das Potential, den manuellen Aufwand mr Dateneingaben auf ein Minimum zu beschdinken und in gewissem Masse auch die Arbeitsteilung im Unternehmen zu reduzieren. Mit der Systemintegration er6ffnet sich die M6glichkeit des Investitionsschutzes [vgl. Noffsinger et al. 1998; Sanchez/Fenner 2001]. Bereits bestehende Anwendungen k6nnen durch eine Integration entsprechend den neuen Prozessabl~iufen weiterhin verwendet werden. Im Rahmen der Systemintegration spielt die Datenintegration eine wesentliche Rolle. Die Integration von Datenbest~inden kann zu einer verbesserten Informationsversorgung der Entscheidungstr~iger, zu einer Rationalisierung von Arbeitsabl~iufen, zu einer Verringerung von Datenredundanzen und damit zur Vermeidung von Inkonsistenzen der Daten und Senkung der Speicherkosten, zu einer Erh6hung der Datenintegrit~it, zu einer Reduktion des Erfassungsaufwandes sowie zur Schaffung der Voraussetzung mr eine Funktions- bzw. Prozessintegration fiihren [vgl. z.B. Mertens 1995, S. 8f]. Die zwischenbetriebliche Integration zielt darauf ab, den Datenaustausch zwischen kooperierenden Unternehmen zu vereinfachen. Damit werden neben den Potentialen der innerbetrieblichen Integration noch weitere Potentiale geschaffen, wie z.B. die Verbesserung von Serviceleistungen, die Sicherung von langfristigen Ertragswirkungen, positive Wettbewerbsver~inderungen oder die Schaffung neuer Leistungen an den Kunden (fiir eine detaillierte Betrachtung der zwischenbetrieblichen Integration siehe [Schumann 1990]).

4 Detaillierte Abhandlung zu m6glichen Integrationsformen und -typen sind zu finden in [vgl. z.B. Krcmar 1991, S.3ff; Lehner 1994; Mertens 1995, S. lff; Mertens et al. 1996, S. 44ff; Zahavi 2000, S. 17ff].

24

2 Problemabgrenzung

2.4 Probleme der Integration Obwohl die Integration eine Reihe von Potentialen erfffnet und einen Kembereich der Informationsverarbeitung darstellt, gibt es einige Probleme. Die nachfolgenden Abschnitte beschreiben die aus der Literatur und aus Praxisprojekten bekannten Probleme im Rahmen der Integration (Abb. 2.6). Problem bereich

Probleme

Know-how

Fehlende Kenntnis der potentiellen L6sungsvarianten Unbekannte Konsequenzen der Integrationsentscheidungen Suboptimaler Grad an Integration Fehlende Kenntnis der Integrationsbeziehungen Zu hoher Zeitdruck auf das Integrationsprojekt Kein methodisches Vorgehen Unbekannte Komplexit~it des Projekts Fehlende Standards Heterogenit~it der Anwendungen Fehlende Flexibilit~t der Altsysteme Unkontrollierte Redundanz

Management

Informationssystem

Abb. 2. 6: Zuordnung der Integrationsprobleme zu Problembereichen

[Goodhue 1992] zeigt sehr deutlich, dass die Bedeutung der Integration nicht generalisiert werden kann, sondem stark von der Situation des Untemehmens abh~ingt. Deshalb treffen auch nicht alle oben aufgefiihrten Probleme auf jedes Untemehmen gesamthaft zu. Je nach Projektsituation und gegebenen technologischen Rahmenbedingungen treten eine Auswahl der aufgeftihrten Probleme auf.

Fehlende Kenntnis der potentiellen LOsungsvarianten Die Vielzahl von m6glichen Integrationssituationen in den Untemehmen erschwert die Konzeption der besten L6sung. Auf der einen Seite stehen die unterschiedlichen Integrationsprobleme, die sich aus einer Kombination mehrerer Faktoren zusammensetzen (technische, logisch konzeptionelle Probleme usw.), und auf der anderen Seite gibt es eine Reihe von potentiellen L6sungsvarianten. Wie bereits erw~ihnt, wird das Integrationsproblem meist nur als technisches Problem angesehen, wodurch ein gesamtheitlicher Oberblick aller m6glichen Entscheidungssituationen bis heute fehlt. Eine Konzeption der L6sung erfordert jedoch die Kenntnis der konkret vorliegenden Integrationssituation und die daftir in Frage kommenden Lfisungsvarianten. Heute ist jedoch zum einen nicht bekannt, welche Auswahl von m6glichen Entscheidungen existiert und zum ande-

2.4 Problemeder Integration

25

ren sind die Vor- und Nachteile der Varianten nur exemplarisch bekannt [vgl. Ruh et al. 2001, S. 13]. So verhindert beispielsweise die Wahl eines asynchronen Datenaustausches zwischen Geldautomat und Bank-Informationssystem eine aktuelle Auskunftsbereitschaft gegenfiber dem Kunden. Zudem verffigen die Unternehmen h~ufig nicht fiber das notwendige Know-how zur Erstellung von Gesamtkonzeptionen und ihnen fehlt die Transparenz fiber die am Markt verfi3gbaren Informations- und Kommunikationstechnologien [s. Gierhake 1998, S. 3].

Unbekannte Konsequenzen der Integrationsentscheidungen Da Integration sich auf allen Ebenen des Business Engineering finden l~sst und diese nicht unabh~ngig voneinander sind, ist es entscheidend, das Modell zu kennen und somit auch die Interdependenzen der Integrationsentscheidungen. Beispielsweise kann eine kleine Anderung im Prozessablauf zu einem erheblichen Anderungsaufwand auf Seiten des Informationssystems ~hren. Die zu unterstfitzenden Anwendungen mfissen modifiziert werden oder neu miteinander interagieren, was zur Entwicklung neuer Schnittstellen ~hrt. Auch in umgekehrter Richtung bestehen Abh~ngigkeiten zwischen den Ebenen. L~sst sich eine Anforderung des Prozesses aus technischen Gr~nden nicht oder nur mit nicht vertretbarem Aufwand im Informationssystem realisieren, hat das Rt~ckwirkungen auf den Prozess. Er muss unter Umst~nden neu gestaltet werden. Positive Wirkungen von Seiten des Informationssystems sind z.B. neue technologische Entwicklungen, die eine Integration erleichtern oder erst erm6glichen und dadurch das Potential mr neuartige Prozesse schaffen wie das Beispiel der Internet-Technologie eindrficklich beweist. Aber nicht nur zwischen den Ebenen des Business Engineering k6nnen Anderungen ausgel6st werden, auch innerhalb der einzelnen Ebenen sind Integrationsentscheidungen in einem gr6sseren Rahmen zu beachten. So kOnnen kleine Anderungen in einzelnen Applikationen eines heterogenen Informationssystems mit grosser Vernetzung eine Reihe von Schnittstellenanpassungen nach sich ziehen. Das Jahrtausendproblem belegte diese Aussage. Die an sich minimale Anderung des Datumsformats in einigen Anwendungen ~hrte in mittleren Unternehmen zu Aufw~nden in der Gr6ssenordnung von Personenjahren. Grfinde da~r waren zum einen die unzureichende Dokumentation der Verknfipfungen der Anwendungen (d.h. fehlende Kenntnis bestehender Integrationsbeziehungen), wodurch eine Analyse erforderlich wurde. Diese ergab vielfach, dass durch die bestehenden Datentransfers mehr Anwendungen betroffen waren als ursprfinglich angenommen. Zum anderen erforderten unt~berbrfickbare Hindernisse bei der Anderung des Datenformats (beispielsweise bei Altanwendungen) eine Anderung der bisherigen Abl~ufe, d.h. Prozesse mussten fiberdacht werden.

26

2 Problemabgrenzung

Suboptimaler Grad an Integration Betrachtet man die Informationssysteme mehrerer Untemehmen, so lassen sich meist zwei Extremf~ille beziiglich des Integrationsgrades feststellen. Es liegen entweder Insell/3sungen vor, die fiir jeweils spezifische Aufgabengebiete entwickelt wurden und meist die Verbindung bisher getrennter Aufgabengebiete erschweren oder verhindem, oder die Anwendungen des Informationssystems sind sehr stark miteinander verflochten, so dass beispielsweise ein Releasewechsel oder ein Ersatz einzelner Anwendungen Auswirkungen auf die verbundenen Anwendungen nach sich zieht. In der Vergangenheit war es g~ingige Praxis, zwei Anwendungen jeweils individuell mit einer sogenannten Punkt-zu-Punkt Verbindung zu integrieren [vgl. Walter 2001]. Vorteile dieser Vorgehensweise sind ein rasches Vorgehen, da jeweils nur zwei Daten- und Funktionsmodelle aufeinander abgestimmt werden mtissen, sowie die leichtere Wahl eines geeigneten Integrationsmechanismus. Nachteil dieser Integrationspraxis ist die rasch steigende Zahl der zu wartenden Integrationsbeziehungen (bei n zu integrierenden Anwendungen entstehen bis zu n*(n-1) Integrationsbeziehungen; Abb. 2.7). Es entsteht ein hoher Grad an Verflechtung, der selbst bei einer Ver~inderung einzelner Anwendungen auch Modifikationen in anderen Anwendungen notwendig macht [vgl. Canopy 2000, S. 3; Connelly 1999; Gray 2001, S. 5; Kleinau 1990; Sanchez/Fenner 2001 ]. Demzufolge kann ein stark integriertes Informationssystem eine schnelle Ausrichtung des Untemehmens an neuen Anforderungen des Marktes verhindem.

Das Bestreben eines Unternehmens nach einer integrierten Informationsverarbeitung nach [Mertens 1995] birgt weitere Gefahren. So stellt deren Konzeption und die Realisierung ein grosses und lang andauemdes Projekt dar, weshalb die Nutzeffekte einer integrierten Informationsverarbeitung h~iufig erst nach einigen Jahren auftreten. Dieser Umstand verhindert in

2.4 Problemeder Integration

27

einem sich dem steten Wandel unterzuordnenden Unternehmen ein derartiges Unterfangen. Vielfach mtissen Anwendungen ohne grosse Beachtung von Integrationsnutzen rasch fertiggestellt und im Bedarfsfall ohne ein tibergeordnetes Integrationskonzept miteinander verbunden werden. Daher muss jedes Unternehmen fi~r sich entscheiden, welchen Grad an Integration und somit welche Komplexit~it des gesamten Informationssystems es erreichen m6chte [s. Lehner 1994, S. 14]. Die Entscheidung kann meist nur eine Abw~gung sein, in die vor allem die Anzahl der zu integrierenden Komponenten und die Reichweite der Integration eingehen [s. Krcmar 1991, S. 9].

Fehlende Kenntnis der bestehenden Integrationsbeziehungen

Entstehen die einzelnen Integrationsbeziehungen ad hoc aus den gegebenen Anforderungen heraus, so fehlen hiiufig Dokumentationen oder sie sind nicht nachgeffihrt [vgl. Brodie/Stonebraker 1995, S. 10; Gartner Group 1999, S. 3; Gray 2001, S. 5; Kurt 1999]. Ein Oberblick tiber alle Integrationsbeziehungen fehlt, wodurch immer wieder redundante Entwicklungsarbeiten entstehen k6nnen. Die mangelnde Transparenz tiber die Integrationsbeziehungen verhindert eine Kontrolle der Vollst~indigkeit und Konsistenz der Schnittstellen. Ausserdem ist dadurch keine zuverliissige Planung des Integrationsaufwands mOglich. Sie wtirde ffir die Identifikation der im vorherigen Punkt erliiuterten Auswirkungen einen Oberblick tiber die Verflechtungen der betrachteten Anwendung benOtigen.

Zu hoher Zeitdruck auf das Integrationsprojekt

Kein Unternehmen kann es sich leisten, Jahre ffir die Integration von Anwendungen zu verwenden [vgl. Gartner Group 1999, S. 2]. Fehlende Dokumentationen der beteiligten Systeme, fehlende Kenntnis der technologischen M6glichkeiten und fehlendes methodisches Vorgehen stehen jedoch im Widerspruch zu dieser Forderung. Vielfach wird der Aufwand mr die Integration bereits zu Beginn des Projekts zu eng eingeplant. Auftretende ungeplante und ungeahnte Konsequenzen im Projekt erh6hen dann den Zeitdruck auf die Integration. Ist die mr Integration eingeplante Zeit zu kurz, fehlt die Zeit mr das Design und die Dokumentation der Schnittstellen und des Datentransfers. Daraus leitet sich eine Abh~ingigkeit des Unternehmens von den Designern und Programmierern der Schnittstellen ab [vgl. csk 1998]. Auch die Einfi~hrung von Anwendungen sieht mehr Zeit mr das Customizing als mr die Integration der Anwendung in das Informationssystem vor. Verz6gert sich das Customizing, fehlt wiederum die Zeit mr die Integration.

Kein methodisches Vorgehen der Integration

Die Komplexit~it der Integrationsprojekte erfordert ein methodisches Vorgehen [s. Taviz Technology 2000]. Die Informatikabteilungen der Unternehmen betreiben Integration seit

28

2 Problemabgrenzung

Jahren. Jedoch lassen sich hier keine allgemein anerkannten Methoden oder Vorgehensweisen finden. Die Integration gilt h~iufig als ein rein technisches Problem, weshalb sie auch erst im Rahmen der Implementierung Beachtung findet. Aus diesem Grunde fehlt eine ausreichende Beriicksichtigung der Integrationst~itigkeiten in den einzelnen Vorgehensmodellen der Systementwicklung [s. Gassner 1996, S. 32]. Die Projekte zeichnen sich in der Regel durch einen ad hoc Charakter aus und die Integration resultiert gew0hnlich in einer Software, die nur ftir eine einzige Schnittstelle geschrieben wurde [Gartner Group 1999, S. 4f; Mowbray/Zahavi 1995, S. 8f]. Zudem fiihren ad hoc Projekte auch zu dem bereits erw~ihnten Problem der fehlenden Dokumentation.

Ungeplante Komplexitiit des Projekts Da vielfach vorher nicht bekannt ist, wie viele Schnittstellen notwendig sind (s.o.), kann sich die Komplexit~it des Projekts in ungeplanter Weise ausweiten, die Kosten steigen, Folgeprojekte verz6gem sich usw. Je mehr Verflechtungen zwischen den einzelnen Anwendungen eines Informationssystems bestehen, desto komplexer gestaltet sich die Integration zweier Komponenten [vgl. csk 1998].

Fehlende Standards ffir die Integration Die Heterogenit~it der zu integrierenden Anwendungen verhindert die Entwicklung von Standards fiir die Integration. Auch ist in vielen Informationssystemen bei der Entwicklung den bestehenden Standards fiir die Rechner- und Prozesskommunikation zu wenig Beachtung geschenkt worden. Eine Integrationsarchitektur im Sinne einer Standardisierung der Integrationsm6glichkeiten innerhalb eines Informationssystems kennen die wenigsten Unternehmen.

Heterogenitiit der Anwendungen Die Heterogenit~it yon Anwendungen wird als das Kernproblem der Integration angesehen [s. Longo 2001; Riehm 1997, S. 29ff; Ruh et al. 2001, S.12f; Stickel 2001, S. 143]. Anwendungen k0nnen sich nicht nur technologisch (verwendete Programmiersprachen, zugrunde liegendes Betriebssystem usw.), sondern auch auf logisch konzeptioneller Ebene (verwendetes Daten- und Applikationsmodell) unterscheiden. Somit gibt es eine Reihe von m6glichen Heterogenit~itsformen zweier Anwendungen, deren Kenntnis zwingend erforderlich ist, um die ad~iquate Integrationsform ausw~ihlen zu k6nnen. Beide Dimensionen der Heterogenit~it mtissen fiir eine erfolgreiche Integration jeweils aufeinander abgestimmt werden. Auf die unterschiedlichen Heterogenit~itsformen geht der Abschnitt 3.1.2.5 n~iher ein.

2.4 Problemeder Integration

29

Fehlende Flexibilit~it der Altsysteme

Nicht nur die Vielzahl yon unterschiedlichen Anwendungen und deren Heterogenitiit erschweren hiiufig die Integration, sondern auch die nicht vorhandene Flexibilitiit der Altsysteme. Sie bedingt hiiufig eine aufwendige Anpassung der bestehenden Anwendungen an die Anforderungen [vgl. Brodie/Stonebraker 1995; Fobes 2000; Ganti/Brayman 1995; Noffsinger et al. 1998]. Folgende Merkmale yon Altsystemen verhindern oder erschweren ihre Integration erheblich: 9

Unzureichende Wiederverwendbarkeit Die in den Unternehmen eingesetzten Anwendungen sind mitunter 10-15 Jahre alt. Ihre Entwicklung erfolgte hiiufig zu einem speziellen Zweck und rein projektbezogen. Eine spiitere Wiederverwendung wurde selten beriicksichtigt [vgl. Grundner 1993, S. 1]. Aus diesem Grund sind sie meistens zentralistisch, monolithisch, sehr komplex und selten modular aufgebaut und es fehlen Schnittstellen. Die Ablaufsteuerung solcher Anwendungen wurde auf Gesch~iftsaufgaben ausgelegt, die eine vordefinierte Folge von Aktionen ausl0ste. Diese Folge konnte yon den Benutzern nicht veriindert werden. Solche Ablauffolgen sind jedoch Gegenstand der Umgestaltung in einem Prozessentwurf und mtissen umge~indert werden.

9

Veraltete Datenhaltung In den Informationssystemen finden sich zuweilen technologisch veraltete Datensysteme wieder, deren Strukturen inflexibel sind, wie z.B. im Bereich der nichtrelationalen Datenbanken [vgl. Winsberg 1994]. Probleme bei derartigen Datenbanken bereiten oft deren Schnittstellen, die einen leichten Zugang zu den Daten verhindern [vgl. Fischer Lent 1994, S. 64; Meier et al. 1993, S. 331 ]

9

Veraltete Benutzeroberfliichen In der Regel besitzen die Altsysteme eine veraltete Character-based User Interface (CUI), die auf sog. "dummen" nicht programmierbaren Terminals aufsetzen [vgl. Winsberg 1994, S. 23]. Diese Oberfliichen gentigen vielfach nicht mehr den heutigen Qualitiitsansprtichen und sollten abgel6st werden.

9

Unzureichende Verteilbarkeit yon Daten und Funktionen Altsysteme sind in der Regel zentralistische Anwendungen. Die Daten und Applikationen stehen meist auf einem Grossrechner zur Verfiigung, eine Client/Server-Architektur liegt nicht vor [vgl. WRQ 2000]. Zudem gestaltet sich die Portabilitiit sehr schwierig [vgl. Percy 1993].

9

Unzureichende Wartbarkeit Die fehlende oder unzureichende Dokumentation der Applikationen erschwert die Wartung. Im Laufe der Zeit vorgenommene Anderungen kOnnen nicht selten nur yon den

30

2 Problemabgrenzung Entwicklern selbst verstanden werden und lassen sich nicht mehr nachvollziehen [vgl. Alderson/Shah 1999; Gassner 1996, S. 1f].

Unkontrollierte Redundanz und Bedeutung der Daten Problematisch bei einer unkontrollierten Redundanz ist z.B. die Frage nach den aktuellen Daten [vgl. Lublinsky 2001, S. 26; Peterson 2000]. Sind Datenbest~inde mehrfach im Informationssystem vorhanden und findet zwischen ihnen kein automatischer Abgleich (im Sinne eines Redundanzmanagements) statt, muss bei dem Datenzugriff sichergestellt werden, dass die Anwendung nur die aktuellen Daten benutzt. Im Bereich der Redundanzen stellen Synonyme und Homonyme weitere Probleme dar, z.B. muss sichergestellt sein, dass die Begriffe St. Gallen, Sankt Gallen und SG alle die selbe Bedeutung besitzen. Will man dezentrale Datenbest~inde miteinander integrieren, reicht es nicht, die Syntax aufeinander abzustimmen. Ist z.B. das Attribut Kundennummer in beiden Datenbest~inden gleich aufgebaut (gleiche L~inge etc.) und die erste Ziffer gibt einen Hinweis auf die Kundengruppe, so kann eine Null jedoch in beiden Datenbest~nden jeweils eine unterschiedliche Kundengruppe repr~isentieren.

2.5 Zusammenfassung Die aufgefiihrten Beispiele, die Ausl6ser, Potentiale und Probleme der Integration belegen folgende Kernaussagen:

Die Wirtschaft befindet sich in einer permanenten Umstrukturierung. Auf der einen Seite befinden sich die Unternehmen in einem Deconstruction-Prozess, d.h. grosse Unternehmen brechen in kleinere, flexiblere Einheiten auf, und auf der anderen Seite gehen Untemehmen Kooperationen oder Fusionen ein, um die gestiegenen, komplexeren Kundenbedtirfnisse befriedigen zu k6nnen und die notwendige kritische Masse zu erreichen. eCommerce, Globalisierung, Business Networking und Customer Relationship Management sind die zu beobachtenden strategischen Trends.

Die geiinderten strategischen Ziele erfordern neue Geschgifisprozesse. Alle genannten Entwicklungen auf der strategischen Ebene lassen sich selten mit den bisherigen Prozessen erreichen. Deshalb weicht die Funktionsorientierung in der Gesch~iftsabwicklung einer Prozessorientierung, die den Kunden und seine Bedtirfnisse in den Mittelpunkt stellt. Auch diese Prozesse sind st~indigen Ver~inderungen unterworfen. Daneben steigt der

2.5 Zusammenfassung

31

Informationsbedarf bei der Prozessabwicklung permanent an, der sich nur mit Hilfe von IV bew~ltigen l~sst.

Der Erfolg der Prozessorientierung hdngt vonder Umsetzung in das Informationssystem ab. Eine Umsetzung der Prozessorientierung in das Informationssystem erfordert eine Neuintegration der bislang funktional ausgerichteten Applikationen. Dabei mt~ssen die mr das bestehende Informationssystem get~tigten Investitionen und das implizit enthaltene Know-how geschfitzt werden, weshalb eine Wiederverwendung und Weiterentwicklung der einzelnen Komponenten Voraussetzungen for die Prozessumsetzung sind. Somit lassen sich das Management und die Gesch~ftsstrategien des Informationszeitalters nur mit ausreichender Anwendungsintegration (Enterprise Application Integration, EAI) auf der Informationssystemebene verwirklichen.

Die FlexibilitZit sowie die Integrationsf~ihigkeit des Informationssystems bestimmen die Reaktionsgeschwindigkeit des Unternehmens auf ge~inderte Marktanforderungen und damit dessen Erfolg. Kann das Informationssystem die Anforderungen aus den Prozessen nicht ermllen oder verhindern technologische Probleme eine notwendige Integration von Anwendungen, muss der Prozess unter Umst~nden modifiziert werden, eine suboptimale L6sung entsteht.

Diese Aussagen belegen sehr deutlich, dass die Integration ein Schlfisselfaktor erfolgreicher Unternehmen im Informationszeitalter ist. Die dennoch vorherrschenden Probleme im Bereich der Integration erfordern deshalb ein Modell, das die Planung und Durchmhrung von Integrationsvorhaben erleichtert. Dieses soll mr unterschiedliche Integrationssituationen die zu treffenden Entscheidungen aufzeigen und einen Leitfaden mr die Projektdurchmhrung umfassen, d.h. es soll die Integrationsproblematik konzeptionell bew~ltigen.

3 Grundlagen 3.1 Bezugsrahmen und Begriffsverstfindnis der Arbeit Der Begriff Integration ist im heutigen Sprachgebrauch mit den unterschiedlichsten Inhalten verbunden [vgl. Mische 2000]. Im sozialen Bereich findet z.B. eine Integration von Ausl~indern in einer Gesellschaft statt, die Organisationslehre dagegen integriert z.B. Aufgaben im Sinne einer Zusammenfiihrung einzelner Arbeitsschritte. Wurden in der ersten H~ilfte des Jahrhunderts m6glichst kleine, spezialisierte Aufgabenpakete einzelnen Mitarbeitern zugewiesen, geht die heutige Erkenntnis zurtick zu integrierten Aufgaben und vermeidet einen zu weit getriebenen Taylorismus. Auch selbst innerhalb einer einzigen Forschungsdisziplin besteht kein einheitliches Begriffsverst~indnis. So finden sich z.B. in der Informatik unterschiedliche Auspr~igungen in Bezug auf die Integration (n~ihere Ausfiihrungen im Abschnitt 3.2.3). Vor diesem Hintergrund erfordert eine Arbeit fiber das Thema Integration zwei vorausgehende Schritte: 1. Schaffen eines Bezugsrahmens, der die Reichweite und Bedeutung der Integration fiir die Arbeit abgrenzt (Abschnitt 3.1.1). 2. Exakte Definition des der Arbeit zugrunde liegenden Begriffsverst~indnisses (Abschnitt 0).

3.1.1 Business Engineering als Betrachtungsrahmen Ziel der vorliegenden Arbeit ist keine Abhandlung des Themas Integration tiber alle Forschungsrichtungen hinweg. Vielmehr bezieht sie sich auf die Einordnung und Bedeutung der Integration im Rahmen des Business Engineering. Business Engineering ist ein Ansatz, der die Managementlehre, die Organisationsmethodik, das Total Quality Management, das Controlling sowie das Systems- und Software Engineering miteinander verbindet. Mit Hilfe der Managementdisziplin Business Engineering findet der Wandel von der Industriegesellschaft in die Informationsgesellschaft unter Nutzung der informationstechnischen Potentiale statt. Deshalb befasst sich das Business Engineering mit Entscheidungen auf allen Ebenen (Strategie - Prozess - Informationssystem) der Unternehmensgestaltung [vgl. t)sterle/Blessing 2000]. Weiterhin lassen sich unterschiedliche Dimensionen des Business Engineering unterscheiden wie z.B. Organisation, Funktionen, Daten, Personal, Marketing, Recht usw. (Abb. 3.1).

34

3 Grundlagen

Das Business Engineering untersttitzt die Untemehmen bei ihrem Wandel zur Informationsgesellschaft durch die Bereitstellung von Methoden zur Prozess- und Systementwicklung. Wesentliches Merkmal dabei ist die Zielsetzung, die Ebenen Strategie, Prozess und Informationssystem durchg~ingig und aufeinander abgestimmt zu entwickeln. Im Zentrum steht der Gesch~iftsprozess [vgl. Osterle 1995, Kap. 1; Taylor 1995, S. 105ff]. Auf Strategieebene definiert und dokumentiert ein Untemehmen seine Marktposition und die daraus resultierenden Entscheidungen fiir das Untemehmen und seine Gesch~iftsfelder[vgl. 0sterle et al. 1996, S. 3]. Die Prozessebene bestimmt die organisatorischen Einheiten, die Prozessleistungen, die Teilprozesse und organisatorischen Aufgaben sowie die wesentlichen Untersttitzungen durch das Informationssystem (siehe hierzu auch Abschnitt 3.1.2.1). Auf der lnformationssystemebene spezifiziert das Untemehmen die Organisation und die computeruntersttitzte Informationsverarbeitung im Detail (siehe auch Abschnitt 3.1.2.4).

Integrationsobjekte Auf allen Ebenen des Business Engineering kommen Integrationsbemiihungen vor, die sich mit unterschiedlichen Inhalten oder Objekten befassen (Abb. 3.2).

3.1 Bezugsrahmenund Begriffsverst~indnisder Arbeit

35

Kapitel 2 belegt deutlich, dass ein Business Engineer das Thema Integration nicht isoliert auf einer der Ebenen betrachten kann. Er ben6tigt vielmehr je Business Engineering Ebene Kenntnis fiber die zur Auswahl stehenden Gestaltungsvarianten der Integration sowie ihre m6glichen Wirkungen auf die anderen Ebenen, will er das Business ad~iquat gestalten. Der Schwerpunkt der vorliegenden Arbeit liegt auf der Betrachtung der konzeptionellen, technologischen Integration, der sogenannten Enterprise Application Integration (EAI). EAI befasst sich mit der Integration von Applikationen, Datensammlungen und Plattformen mit dem Ziel der Umsetzung und Steuerung von Gesch~iftsprozessen [vgl. Ruh et al. 2001; Stokes 2001 ]. Somit ist sie Teil der Informationssystemebene mit der Verbindung zur Prozessebene (Abb. 3.3). Im weiteren Sprachgebrauch bezieht sich deshalb, sofern nicht anders erw~ihnt, der Begriff Integration auf die Verbindung von Anwendungen der Informationssystemebene. Ffir die Strategieebene sind nur beispielhaft im Abschnitt 2.2 m6gliche Ausl6ser fiir Integrationsprojekte auf den anderen Ebenen des Business Engineering angegeben. Die Wechselwirkungen zwischen der Prozess- und der Informationssystemebene werden im Referenzmodell dagegen ausf'tihrlich betrachtet. Durch diesen Bezugsrahmen wird eine gesch~iftsorientierte Betrachtung der Integration sichergestellt. Alle konzeptionellen IntegrationsmSglichkeiten leiten sich aus den Vorgaben der Gesch~iftsprozesse ab. S~imtliche Integrationsarten gehen vonder Annahme aus, dass ein Informationssystem weiterentwickelt wird. Das bedeutet, dass die Prozessumsetzung nicht den Ansatz der "granen Wiese" verfolgt, sondern die m6gliche Heterogenit~it der Anwendungen be~cksichtigt und eine evolution~ire Weiterentwicklung des Informationssystems anstrebt.

36

3 Grundlagen

3.1.2 Definitionen

Um ein intuitives Verst~indnis fiir die Problemstellung aufzubauen, wurden in den vorangehenden Kapiteln die meisten Begriffe ohne exakte Erkl~irung oder Definition verwendet. Ftir die weitere Arbeit ist jedoch eine klare Begriffsdefinition erforderlich. Zentrale Begriffe der vorliegenden Abhandlung sind der betriebliche Prozess, Prozessumsetzung, Workflow, Informationssystem, Anwendung, Enterprise Application Integration sowie Prozess- und Systemintegration. Der Zusammenhang dieser Begriffe wird nach deren Abgrenzungen und Definitionen anhand eines Metamodells im Abschnitt 4.2 n~iher erl~iutert.

3.1.2.1 Betrieblicher Prozess

Die Arbeit baut auf dem Prozess-Begriffsverst~indnis des Kompetenzzentrums ,,Prozessentwicklung" (CC PRO) des Forschungsprogramms IM HSG am Institut fiir Wirtschaf~sinformatik der Universit~t St. Gallen auf [Institut Rir Wirtschaftsinformatik 1996]. Auf die Ableitung des Begriffes aus der Literatur wird an dieser Stelle verzichtet, es sei auf die aus~hrliche Arbeit von [Hess 1996] verwiesen. Ein Prozess konkretisiert die Gesch~iftsstrategie des Unternehmens und erzeugt durch Wertsch/Spfung Leistungen Rir seine Kunden. Diese WertschSpfung wird durch die Abwicklung

3.1 Bezugsrahmenund Begriffsverst~indnisder Arbeit

37

von einzelnen Aufgaben in einer vorgegebenen Ablauffolge erzielt, wobei jede der Aufgaben durch Anwendungen des Informationssystems untersttitzt werden kann [vgl. Yang/Papazoglou 2000]. Die Prozessffihrung lenkt und gestaltet den Prozess anhand der aus der Gesch~iftsstrategie abgeleiteten Ftihrungsgr6ssen. Ein Untemehmen soll sich auf diejenigen Prozesse (Kernprozesse) konzentrieren, die tiber die Wettbewerbsf'~ihigkeit entscheiden.

Das in Abb. 3.4 dargestellte Prozessmodell nach [Osterle 1995, S. 48ff] zeigt eine detailliertere Betrachtung der einzelnen Komponenten eines Prozesses. 9

Leistungen sind die Ergebnisse eines Prozesses und gehen an interne oder externe Kunden. Ein Prozess erzeugt somit nicht nur Leistungen, sondern konsumiert auch Leistungen

anderer Prozesse. Der Wert der Leistung ~ r den Prozesskunden bestimmt den Umfang der Gegenleistung. Eine Leistung kann eine Marktleistung sein, konkret ein Produkt oder eine Dienstleistung, die am Markt angeboten wird. Es kann sich aber auch um eine unterstfitzende Leistung handeln, die notwendig ~ r die Erstellung der eigentlichen Marktleistung ist. 9

Eine Aufgabe ist eine betriebliche T~itigkeit mit einem definierten Ergebnis, die von Menschen oder Maschinen ausgeffihrt wird. Die Aufgabenkette umfasst die einzelnen Aufgaben eines Prozesses, deren Ablauffolge und deren Zuordnung zu Aufgabentr~igern (Stellen). Die Aufgabenkette spezifiziert somit die Leistungserbringung.

38

3 Grundlagen

9 Die Prozessj~hrung kontrolliert den Prozess. Sie bestimmt Ftihrungsgr6ssen (z.B. Durchlaufzeit je Auftrag, Anzahl Neukunden), plant Soll-Werte, erhebt Ist-Werte und gibt Anst6sse ftir Verbesserungsmassnahmen (Fiihrungskreislauf). Fiihrungsgr6ssen sind operationalisierte Merkmale eines Prozesses und dienen der Planung und Beurteilung der Prozessqualit/~t im Sinne der kritischen Erfolgsfaktoren, insbesondere Zeit, Qualit~t, Kosten und Flexibilit/it. Neben Kennzahlen definiert die Prozessfiihrung auch Stellen, Gremien (z.B. Prozessmanager, Prozesszirkel, Prozessausschuss) und Dokumente der Fiihrung. 9 Das Prozessmodell bezeichnet die einmalige und gnmds/itzliche Neugestaltung des Prozesses in Form eines Projekts (Prozessentwurf), die anschliessende Prozessumsetzung sowie die permanente Weiterentwicklung eines Prozesses (Prozessfiihmng) durch die Prozessbeteiligten als Prozessentwicklung. Ziel eines Prozessentwurfs - Synonym fiir den Begriff Business Process Redesign (BPR) -ist der einmalige, projektartige "Total-Review" eines Prozesses, der radikale Innovationen mit sich bringt [vgl. Hammer/Champy 1993, S. 32ff]. Darauf aufbauend, konzentriert sich die Prozessfiihrung auf die kontinuierliche lSrberwachung und Weiterentwicklung des Prozesses [s. Davenport 1993, S. 11; t)sterle 1995, S. 23 und S. 56]. Im Rahmen der Prozessentwicklung 10sen Massnahmen Auftr/~ge zur Prozessver/inderung aus. Dabei kann es sich um kleinere Aktivit/~ten einzelner Mitarbeiter oder um gr6ssere Projekte handeln. 9 Das Informationssystem ist die Gesamtheit der (computerisierten) Informationsverarbeitung eines Untemehmens. Es besteht aus Applikationen, d.h. Zusammenfassungen computerisierter Arbeitsg/~nge eines Arbeitsgebiets, und Datensammlungen, d.h. computerisierte dauemde Ablage von Daten, zur Unterstiitzung der Aufgabenausfiihnmg (vgl. auch Abschnitt 3.1.2.4). Die Anforderungen an die informationstechnische Untersttitzung deftnieren die Prozessentwiarfe.

3.1.2.2 Prozessumsetzung Im Rahmen des Business Engineerings ist die Prozessumsetzung in die Ebene Informationssystem einzuordnen, in einzelnen Bereichen hat sie jedoch auch l]berschneidungen mit der Prozessebene. Sie setzt in jedem Fall den Prozessentwurf voraus (vgl. Abb. 3.5 nach [Osterle 1996a, S. 3]). Die von ihr gestalteten Dimensionen des Business Engineerings betreffen vor allem Daten und Funktionen. Die Dimension Organisation wird von ihr nur am Rande entworfen, diesbeziiglich steht hier die l]bemahme und Implementierung der Vorgaben aus der Ebene Prozess im Zentrum des Interesses [vgl. Osterle 1995, S. 28-30].

3.1 Bezugsrahmenund Begriffsverst~indnisder Arbeit

39

Die Prozessumsetzung ist Teil der Prozessentwicklung, welche den Prozessentwurf in Projekten sowie die kontinuierliche, fiihrungsgr6ssenbasierte Prozessfiihrung beinhaltet (s. Abschnitt 3.1.2.1 .). Sie befasst sich mit der Implementierung neu gestalteter Prozesse im computeruntersttitzten Informationssystem. Dazu setzt sie die Anforderungen aus dem BPR an die Computeruntersttitzung in Anwendungen urn. Die Implementierung ist demnach die Realisierung einer oder mehrerer Anwendungen sowie die Integration bestehender Anwendungen nach Vorgaben des Prozessentwurfs [vgl. Gutzwiller 1994, S. 52-54; Osterle 1981, S. 20]. Abbildung 3.6 beschreibt den Zusammenhang zwischen Prozessentwurf, Prozessumsetzung und Prozessfiihrung [vgl. Derungs 1997b, S. 24f; Mende 1995, S. 8]. Ist ein "Total-Review" erforderlich, so startet ein Prozessentwurfsprojekt. Die anschliessende Implementierung des neu definierten Prozesses tibemimmt die Prozessumsetzung. Der Anstoss fiir ein Prozessentwurfsprojekt erfolgt vonder Prozessfiihrung sp~itestens dann, wenn die Abweichungen der Ftihrungsgr6ssen so fundamental sind, dass sie sich nicht mehr durch kurzfristige Massnahmen 16sen lassen. Grunds~itzlich sind mehrere Altemativen for die Implementierung eines neugestalteten Prozesses denkbar, wie beispielsweise die Einfiihrung yon betrieblicher Standardanwendungssoftware 5, die Eigenentwicklung einer Anwendung ~ r den Prozess oder der Einsatz der Workflowtechnologie zur Verbindung der ben6tigten Anwendungen. Die vorliegende Arbeit geht auf die m6glichen Varianten der Prozessumsetzung ein (vgl. Abschnitt 4.3). Dabei sind jeweils die im Unternehmen vorhandenen (heterogenen) Anwendungen im Sinne einer evolution~iren Weiterentwicklung des Informationssystems zu berticksichtigen und in den Prozess

5 Standardanwendungssoftware ist ein fertiges Softwarepaket, das fiir seinen Anwendungsbereich eine weitgehend allgemeingfiltigeFunktionalit~itaufweist und auf eine mehrfacheNutzung ausgelegt ist [s. Amberg 1999, S. 12; Steinbock 1993, S. 58].

40

3 Grundlagen

zu integrieren. Somit nimmt die Integration von Anwendungen, Applikationen und Datensammlungen eine zentrale Stellung in der Prozessumsetzung ein.

Die Arbeit zeigt im Abschnitt 4.3.2 sowohl fiir die Planung der Prozessumsetzung als auch ftir deren Durchffihrung in konkreten Projekten konkrete Handlungsanweisungen auf. Vor dem Hintergrund der in Abschnitt 2.4 skizzierten Probleme der Integration stehen hierzu vor allem sachliche bzw. inhaltliche Aspekte im Mittelpunkt. Der Fokus richtet sich deshalb im Folgenden auf die sach-rationale Dimension [s. Krfiger 1994, S. 364f], weshalb die Arbeit politisch-verhaltensorientierte und wertm~issig-kulturelle Dimensionen nicht beriicksichtigt, wie z.B. allgemeine Grundlagen des Projektmanagements und Change Managements.

3.1.2.3 Workflow Ein zentrales Ergebnis der Prozessumsetzung ist der Workflow. Ein Workflow ist die detaillierte Spezifikation eines Prozesses aus Sicht des Informationssystems [s. Hales 1997, S. 28; van Leeuwen 1997, S. 77; Vogler 1996, S. 345; Weise et al. 1999, S. 83; Weske et al. 1999, S. 1; WfMC 1997b, S. 244]. Er besteht aus mehreren Aktivit~iten, die in einer bestimmten Reihenfolge miteinander verbunden sind und von Aufgabentragem nach definierten Regeln ausgefiihrt werden. Eine Aktivitdt ist eine in sich geschlossene Verrichtungseinheit im Workflow, die logisch und fachlich zusammengeh6rende Arbeitsschritte in einem aus Sicht des Benutzers sinnvollen Arbeitspaket zusammenfasst. Arbeitsschritte (Tasks) sind die elementaren Verrichtungen im Rahmen eines Workflows, d.h. sie lassen sich nicht weiter zerle-

3.1 Bezugsrahmenund Begriffsverst~indnisder Arbeit

41

gen. Sie sind entweder manuell oder IT-unterstiitzt. Letztere rufen Anwendungen auf und k6nnen automatisch im Hintergrund oder mit Benutzerinteraktionen ablaufen. Die Unterscheidung der Begriffe Workflow, Aktivitat und Task kann das Beispiel einer Reklamationsbearbeitung veranschaulichen. Der Workflow beschreibt den Prozess vom Eingang der Reklamation fiber die interne Prtifungen und Abwicklungen bis hin zur Antwort an den Kunden. Nach Eingang einer Reklamation ist die erste Aktivit~it das "Priifen & Empfang best~itigen" durch einen Sachbearbeiter. Diese Aktivit~it besteht aus der Task Prtifen, welche die Reklamation in entsprechende Kategorien einteilt und den entsprechenden Sachbearbeiter zur weiteren Bearbeitung bestimmt, und der Task Empfang best~itigen, welche eine Empfangsbest~itigung an den Kunden erstellt [vgl. Hastedt-Marckwardt 1999, S. 100].

3.1.2.4 Informationssystem und Informationstechnologie Das Informationssystem umfasst alle Anwendungen (bestehend aus Applikationen und Datensammlungen) sowie die Informationstechnologie eines Unternehmens, d.h. es stellt die Gesamtheit der computerunterstiJtzten Informationsverarbeitung innerhalb eines Unternehmens dar [vgl. Fischer 1999, S. 8; Heinrich 1997, S. 861; Schwarze 1994, S. 209; Stickel et al. 1997, S. 336]. Zwischen den Elementen des Informationssystems eines Unternehmens bestehen Beziehungen. Diese basieren auf den Anforderungen aus den Gesch~iftsprozessen, die eine Verflechtung der einzelnen Anwendungen notwendig machen. Informationssysteme unterscheiden sich in der Art und der Zusammensetzung der einzelnen Elemente sowie dem Grad ihrer vorliegenden Vernetzung. Sie weisen demnach unterschiedliche Struktur- und Verhaltensmuster auf. In der Literatur existiert eine Reihe von Klassifikationen ftir die Ordnung der unterschiedlichen Elemente eines Informationssystems. Beispielhaft seien hier einige aufgefahrt. [Steinbock 1994] unterteilt die Anwendungen eines Informationssystems in die Kategorien Administration, Office, Ftihrung, Entwurf, Know-how und Steuerung technischer Prozesse. [Mertens 1995] kategorisiert Anwendungen in Administrations-, Dispositions-, Planungs- und Kontrollsysteme, w~ihrend [Heinrich et al. 1993] die Anwendungen anhand der Repr~isentationsformen der Information in Datenverarbeitung, graphische Datenverarbeitung, Bildverarbeitung, Textverarbeitung, Sprachverarbeitung und Wissensverarbeitung unterscheidet. Im Rahmen dieser Arbeit ist die Kategorisierung der Anwendungen kein zentraler Faktor. Bedeutender ist die Unterscheidung in Anwendungen, Middleware und Systemsoftware. Diese l~isst sich anhand der folgenden Abbildung 3.7 erl~iutern.

42

3 Grundlagen

Anwendungen setzen die Anforderungen aus den Gesch~iftsprozessen um. Sie stellen somit betriebswirtschaftliche Funktionalit/~t und Geschaftsdaten zur Verffigung, die vonder Prozessumsetzung ben6tigt werden [vgl. Reinwald 1993, S. 155]. Anwendungen setzen sich aus Applikationen und Datensammlungen zusammen (s. Abb. 3.8).

In der Regel sind Applikationen als Transaktionssysteme realisiert, deren Grundeinheit eine logische Transaktion ist. Eine logische Transaktion ist ein funktionaler, in sich geschlossener Arbeitsschritt auf einem Rechnersystem [Gutzwiller 1994, S. 236]. Ein Transaktionssystem fasst eine Menge von logischen Transaktionen eines Arbeitsgebietes zusammen, die im wesentlichen auf die gleichen Daten zugreifen. Analog umfasst eine Datensammlung- z.B. eine Datenbank oder eine Datei - Daten, die unter Berticksichtigung ihrer Speicherung, Verarbeitung und Verwendung durch Applikationen zusammengefasst worden sind. Die Applikation oder das Transaktionssystem ist ~ r die Verwaltung der zugeh6rigen Datensammlungen verantwortlich [Gutzwiller 1994, S. 235] und bildet zusammen mit ihnen eine Anwendung.

3.1 Bezugsrahmenund Begriffsverstandnisder Arbeit

43

Die Anwendungen stellen im Rahmen der vorliegenden Arbeit die Integrationsobjekte dar, die tiber Schnittstellen interagieren. Eine Schnittstelle fasst von aussen ben6tigte (Importschnittstelle) oder von aussen aufrufbare Gr6ssen (Exportschnittstelle), sowie allgemeine Informationen zur Verwendung der Anwendung zusammen. Zugleich umfasst sie Vereinbarungen, sog. Protokolle, tiber die Art und Weise der Datentibertragung [vgl. Breing 1990; Grabowski/Schilli 1991; Ruf 1988]. Somit beinhaltet eine Applikationsschnittstelle Methoden, welche von aussen auf gleiche Art aufgerufen werden k6nnen, w~ihrend die Datenschnittstelle Daten umfasst, die mit einer Datenzugriffssprache (beispielsweise SQL) abrufbar sind. Die Abbildung 3.9 stellt den beschriebenen Sachverhalt als Metamodell dar [vgl. Riehm 1997, S. 23]. Die Notation entspricht der des Abschnitts 4.2 und ist ein Ausschnitt aus der Sicht Systemintegration des Metamodells im Abschnitt 4.2.1.3. Integrationsbeziehung

cI verwendet

n~ cn

Schnittstelle ist e i n c ~ l

I

I1 / , f

ist eine

n bietet an n~

c ApplikationsSchnittstelle

Methode/ Funktion n Lbesteht aus

1

DS-Schnittstelle

besitzt

besitzt

Applikation

Oa,eosam lung (DS)

ist Ownervo

Datenstruktur

tn cn

ha

Abb. 3.9. Metamodell: Schnittstellen im Kontext von Anwendungen

Middlewareprodukte bilden eine Softwareschicht zwischen den betrieblichen Anwendungen und der Systemsoftware zum Zwecke der vereinfachten Anwendungsintegration [Elbert/ Martyna 1994, S. 13]. Die Systemsoftware umfasst dabei Betriebssysteme, Datenbankmanagementsysteme und Netzwerksoftware. Die Informationstechnologiebestimmt die Infrastruktur fiir die Entwicklung, den Betrieb und die Integration von Applikationen und Datensammlungen. Sie umfasst alle verfiigbaren Verfahren und Werkzeuge zur Bereitstellung und Verarbeitung von Informationen [s. Krickl 1995, S. 29]. Zur Infrastruktur geh6ren die Middleware, die Systemsoftware und letztendlich die Hardware (s. Abb. 3.10). Da die verfiJgbare Informationstechnologie die Rahmenbedingungen ~ r die M6glichkeiten des Informationssystems setzt, hat sie auch mittelbar Einfluss auf die Gesch~iftsprozesse.

44

3 Grundlagen

Die Informationssystementwicklung ist fiir die Umsetzung aller Anforderungen an die Computemntersttitzung eines Untemehmens in Eigenschaften des Informationssystems verantwortlich [vgl. Schumann et al. 1994, S.1 ]. Heute stehen den Untemehmen fiir die Neuentwicklung von Anwendungen oder fiir das Informationssystem eine Reihe von unterschiedlichen Varianten oder Methoden zur Verfiigung (s. Abschnitt 3.2.2). Daneben existieren auch Verfahren, um bestehende Anwendungen und Informationssysteme durch Modifikationen auf unterschiedlicher Ebene an die neuen Anforderungen anzupassen [s. Becker 1998, S. 10]. Nachdem alle l]berlegungen von einer evolution~iren Weiterentwicklung des Informationssystems ausgehen, betrachten die Prozess- und Systemintegration sowie die Prozessumsetzung prim/Jr das bestehende Informationssystem als Basis mr die Konzeption unterschiedlicher Umsetzungsvarianten. Eine Systementwicklung im Sinne einer Neuentwicklung kommt nur selten als eine Variante in Frage. Grund ftir diese Annahme ist die Tatsache, dass die Informationssysteme in den Untemehmen tiber die Jahre hinweg gewachsen sind und bedeutendes betriebliches Know-how beinhalten. Investitionsschutz zwingt die Untemehmen, auf diesen Anwendungen aufzusetzen. Ausserdem sind die existierenden Anwendungen h/iufig eng und vielfach miteinander verkntipft sowie nur unzureichend dokumentiert, so dass eine Abl6sung mit hohen Risiken verbunden ist (vgl. Kapitel 2).

3.1.2.5 Heterogenitiit von Anwendungen Der Aufwand fiir die Integration yon Anwendungen hiingt vonder Heterogenitiit dieser ab. So kOnnen sich Anwendungen in den verwendeten Programmiersprachen, in den Datenformaten und-modellen, den Zugriffsmethoden, den Kommunikationsprotokollen, den verschiedenen Dateninhalten, den zugrundeliegenden Technologien wie z.B. das Betriebssystem usw. unterscheiden. Diese Kriterien fiihren zu mehreren Dimensionen der Heterogenitiit von Anwendungen [vgl. Hasselbring 2000; Liel3mann et al. 1999]. Die Heterogenit~it im Informationssystem eines Unternehmens ist im Laufe der Zeit aus unterschiedlichen Griinden entstanden. Zum einen verursacht die rasante Entwicklung der informationsverarbeitenden Technologie Unterschiede in den Systemen. Hiiufig werden am Markt verfiigbare leistungsflihigere Systeme in ein Informationssystem eingefiihrt, die noch auf keine Standards basieren und so inkompatibel zu den bestehenden Systemen sind. Ein weite-

3.1 Bezugsrahmenund Begriffsverst~indnisder Arbeit

45

rer Grund sind die Untemehmenszusammenschltisse und -tibemahmen in den letzten Jahren. Untiberwindbare Integrationsprobleme fiihren in diesen F~illen h~iufig zu einem Nebeneinander der heterogenen Anwendungen [Schreiber 1995]. [Johnson 1993] und [Garretson 1992] differenzieren die Anwendungen nach der verwendeten Hard- und Software. Eine andere Unterscheidung bezieht sich auf die logische und physische Betrachtungsebene, die im Rahmen dieser Arbeit Verwendung findet (Abb. 3.11). W~ihrend sich die logische Ebene mit der Struktur (dem formalen Aufbau) von Anwendungen und Informationssystemen befasst (vgl. Abschnitt 3.1.2.5.1), betrachtet die physische Sicht die konkrete Realisierung der Anwendungen und Informationssysteme mittels der Informationstechnologie (vgl. Abschnitt 3.1.2.5.2).

3.1.2.5.1 Logische Heterogenit~it Aus logischer Sicht entsteht Heterogenit~it aufgrund der den Anwendungen zugrunde liegenden Modelle 6. Eine Anwendung, bestehend aus Applikation(en) und Datensammlung(en), stellt eine Abbildung eines Ausschnitts der Realit~it (der Anwendungswelt) dar (vgl. Abb. 3.12).

6 Ein Modell ist die Abbildung eines realen Systems oder Systemausschnitts,die besonders die in dem gegebenen Zusammenhang als wichtig erachteten Aspekte unter Vernachl~issigunganderer weniger wichtiger Gesichtspunkte darstellt [s. Gierhake 1998, S. 12].

46

3 Grundlagen

Die folgenden Ausffihrungen basieren auf der vereinfachenden Annahme, dass zwei Anwendungen interagieren miissen, d.h. ein Datenaustausch zwischen beiden ist erforderlich. Bei der Integration zweier Anwendungen ist jeweils sicherzustellen, dass beide in Bezug auf den gemeinsamen Ausschnitt der Realit~it das gleiche Abbild der Realit~it haben, das bedeutet ein identisches Modell. Nur ein gemeinsames Modell gew~ihrleistet den Austausch der "richtigen" Daten. Sind die Modelle nicht identisch, ist ein Mapping der relevanten Ausschnitte notwendig, das letztendlich zu einem gemeinsamen Verst~indnis der relevanten Daten und Methoden fiJhrt. Demzufolge ist bei der Analyse der Ausgangssituation zun~ichst die vorliegende Heterogenit~itsform zu identifizieren, um anschliessend die entsprechenden Massnahmen ableiten zu k6nnen (zum Vorgehen vgl. Abschnitt 6.4). Ftir das weitere Verst~ndnis folgt anschliessend eine kurze Erkl~irung der relevanten Komponenten und Modelle, die bei der Integration von Anwendungen eines Informationssystems eine Rolle spielen. Die Methoden und Daten einer Anwendung stellen das Abbild des Anwendungsausschnitts dar, weshalb man von einem Applikationsmodell und einem Datenmodell sprechen kann. Beide zusammen bilden das Anwendungsmodell. Heterogenitat entsteht dann, wenn Anwendungen zeitlich und r~iumlich getrennt entstehen und die Entwickler in der Folge ein unterschiedliches Abbild der Anwendungsrealit~it modellieren. Ein drittes Modell, das Prozessmodell, spielt bei der Betrachtung der Heterogenit~it ebenfalls eine Rolle. Die Anwendung modelliert die Sicht des Entwicklers, w~ihrend der Benutzer durch seine Sichtweise auf die Anwendungsrealit~it die Verwendung der angebotenen Methoden und Daten bestimmt. Diese Abbildung der Welt stellt das Prozessmodell dar. Das Prozessmodell bestimmt, welche Anwendungen zu integrieren sind und muss demzufolge mit den betroffenen Anwendungsmodellen abgestimmt sein. Die Abbildung 3.13 zeigt die wesentlichen Aspekte einer Anwendung auf. Die Anwendung enth~ilt alle relevanten Daten, denen ein konzeptionelles Modell des Anwendungsbereiches

3.1 Bezugsrahmenund Begriffsverst~indnisder Arbeit

47

zugrunde liegt (Datenmodell). Auf diesen Daten arbeiten die Methoden, denen ebenfalls ein konzeptionelles Modell des Anwendungsbereichs zugrunde liegt (Applikationsmodell). Beide Modelle k6nnen aus verschiedenen Sichten (z.B. durch unterschiedliche Entwickler) entstanden sein und bilden zusammen das Anwendungsmodell, das ein einheitliches, zusammengeh6rendes Bild der modellierten Realit~it wiedergeben muss. Der Prozess bestimmt, welche Daten und Methoden der Anwendung zu verwenden sind und in welcher Reihenfolge. Auch ihm liegt eine Abbildung der Realit~it, das sog. Prozessmodell zugrunde, das mit dem Anwendungsmodell harmonieren muss.

Aus den verschiedenen Modellen, die im Rahmen einer Anwendung eine Rolle spielen, ergeben sich unterschiedliche Formen der logischen Heterogenit~it von Anwendungen, welche im Folgenden beschrieben werden.

Homogene Modelle In diesem Fall bildete ein einziges Entwicklerteam ein einheitliches Modell des Anwendungsbereiches in einer einzigen Anwendung ab. Diese kann aus unterschiedlichen Applikationen (Modulen) bestehen, die auf eine einzige oder mehrere logische Datensammlungen zugreifen (Abb. 3.14). Es handelt sich hierbei um den theoretischen Idealfall, der sich in der Realit~it aus mehreren Griinden nicht erreichen l~isst. Beispielhaft seien hier einige der Grtinde aufgez~ihlt. Die Abbildung der betrieblichen Realit~it eines Unternehmens in einem einzigen Anwendungsmodell ist aus Komplexit~itsgriinden meist nicht machbar [vgl. Ferstl/Sinz 1993, S. 100; Sinz 1995]. Es ist in einem umfassenden Informationssystem eines gr6sseren

48

3 Grundlagen

Untemehmens organisatorisch nicht zu bew~iltigen, alle Querschnittsfunktionen zu erkennen und diese in einem gemeinsamen Modell allen Entwicklem bekannt zu machen. Ausserdem verliert ein einzelner Entwickler ab einer bestimmten Komplexit~itsstufe des Gesamtmodells den Oberblick und realisiert in der Regel eigene Modelle gem~iss seinen Vorgaben.

Eine weitgehende Ann~iherung an diese Form ist eine integrierte Anwendung wie beispielsweise die am Markt verftigbare betriebswirtschaftliche Standardanwendungssoftware von SAP, Baan, oder Peoplesoft. Kann ein Untemehmen mit einer einzigen Anwendung alle notwendigen Unterstiitzungen der Prozessaufgaben erfiillen, ist gew~ihrleistet, dass alle Aufgaben auf die benStigten Daten und Methoden zugreifen kSnnen, und dass keinerlei Koordinationsoder Integrationsprobleme zwischen den Methoden auftreten. Probleme der redundanten Datenhaltung und der zeitlichen VerzSgerung des Datenaustausches kommen ebenso nicht vor, die Bedeutung der Daten ist ftir alle Methoden identisch. Jedoch weisen derartige Anwendungen h~iufig Probleme grosser Datenhaltungen auf, wie z.B. schlechte Performance.

Homogene Anwendungsmodelle und physische Heterogenitgit Eine Variante dieser Heterogenit~itsform liegt in der Kombination mit der physischen Heterogenit~it wie z.B. dem Installieren von mehreren Instanzen (vgl. Abschnitt 3.1.2.5.2) oder der Verteilung der Applikationen auf mehreren Rechnem. Die Integration ist in derartigen F~illen konzeptionell sehr einfach, da die Modelle aufeinander abgestimmt sind. Der Koordinationsaufwand ergibt sich aus dem Management der Verteilung.

Homogene Anwendungsmodelle und unterschiedliche Anwendermodelle Nicht nur im Bereich der Anwendungsmodelle weicht die Realit~it vonder Idealvorstellung ab, sondem auch ein homogenes Prozessmodell ist in der Praxis selten anzutreffen. Sobald Prozesse mit divergenten Abbildungen ihrer Anwendungswelt dieselbe Applikation mit derselben Datenbank verwenden, liegt kein homogener Fall mehr vor. Ohne Koordination dieser

3.1 Bezugsrahmenund Begriffsverst~indnisder Arbeit

49

Prozessmodelle kOnnen durch die andersartige Verwendung der Anwendung unterschiedliche Bedeutungen der Daten entstehen. Die vielf~iltigen Anstrengungen bei der Integration von mehreren SAP R/3 Installationen belegen diesen Sachverhalt.

Heterogene Anwendungsmodelle Die h/aufigste Variante in der Praxis sind logisch heterogene Anwendungsmodelle. Da sich ein Anwendungsmodell aus dem Daten- und dem Applikationsmodell zusammensetzt, gibt es mehrere Untervarianten von heterogenen Anwendungsmodellen. 9

Homogenes Datenmodell Die erste Untervariante zeichnet sich durch zwei heterogene Applikationsmodelle aber einem homogenen Datenmodell aus (Abb. 3.15). Diese Situation kommt zustande bei der Entwicklung mehrerer Applikationen, welche alle das gleiche Datenmodell verwenden. Beispiele Rir diesen Fall sind betriebswirtschaftliche Standardanwendungssoftware wie z.B. SAP R/3, auf deren Daten mittels Integration auch andere Applikationen zugreifen sollen. Die Applikationen hatten bisher eine eigene Datensammlung, die jedoch eine exakte Spiegelung der Datensammlung von SAP R/3 war und somit das gleiche Datenmodell verwendet.

Der entstehende Koordinationsbedarf besteht haupts~ichlich im Redundanzmanagement, in der Sicherstellung der Datenkonsistenz und dem Abgleich der Applikationsmodelle. 9

Homogenes Applikationsmodell Die zweite Untervariante ist gekennzeichnet durch ein homogenes Applikationsmodell und heterogene Datenmodelle (Abb. 3.16). Diese Situation entsteht, wenn ein Entwickler eine Applikation erstellt, die auf zwei unterschiedliche Datensammlungen zweier Anwendungen zugreift.

50

3 Grundlagen

Der Koordinationsaufwand im Rahmen der Integration entsteht hier bei der Harmonisierung der Datenmodelle mit dem Applikationsmodell. Andert sich das Applikationsmodell der Anwendung 2 aus der Grafik und zieht dies eine Modifikation des Datenmodells nach sich, muss auch das erste Applikationsmodell auf eventuell notwendige ,~ndemngen hin untersucht werden. 9 Heterogene Applikations- und Datenmodelle Bei der dritten Untervariante sind alle beteiligten Modelle heterogen (Abb. 3.17).

Sie stellt den komplexesten und aufwendigsten Fall flir die Integration dar, der dennoch die h/iufigste und nattirlichste Form der Zusammenarbeit in der Praxis ist. In dieser Situation herrscht h~iufig das Problem der unterschiedlichen Semantik der auszutauschenden Daten vor. Sollen beispielsweise die Produktionsmodule der betriebswirtschaftlichen Standardanwendungssoftware Triton und SAP R/3 miteinander verbunden werden, ist bei einem Austausch des reservierten Materialbestandes bei weitem nicht gew/ihrleistet, dass beide Anwendungen diesen Bestand gleich ermitteln. Der Koordinationsbedarf bei der Integration derartig heterogener Anwendungen besteht im Abgleich der einzelnen Modelle. Die Daten mtissen entsprechend dem zugrunde liegenden Anwendungsmodell verwendet werden.

3.1 Bezugsrahmenund Begriffsverst~indnisder Arbeit

51

3.1.2.5.2 Physische Heterogenit~it Die bisher beschriebenen Formen der Heterogenit~it beziehen sich auf die logische Ebene eines Informationssystems. Betrachtet man auch die physische Ebene, kommen weitere Formen hinzu, wie die Verwendung mehrerer Instanzen einer Anwendung oder die Verteilung von Anwendungen sowie die Implementierung auf unterschiedlichen technologischen Plattformen. Verwendet ein Unternehmen eine Anwendung mehrfach, indem sie diese auf unterschiedlichen Rechnern installiert und von unterschiedlichen organisatorischen Einheiten benutzen l~isst, so kann Heterogenit~it in den Datenbest~inden entstehen. Eine solche Verteilung entsteht neben rein technischen Grtinden wie z.B. der Optimierung von Antwortzeiten oder der Verbesserung der Verftigbarkeit, vor allem aus organisatorischen Gegebenheiten. Beispiele ~ r mehrere homogene Instanzen sind die Implementierung der gleichen Standardsoftware mit der gleichen Parametrisierung und eigenen Datenbest~inden an mehreren Standorten. Die zugrundeliegenden homogenen Modelle der Applikationen und Datensammlungen erleichtern die Abbildung von Gesch~iftsprozessen fiber mehrere Unternehmenseinheiten hinweg. Jedoch erschweren mehrere Instanzen die Pflege und Wartbarkeit des Gesamtsystems. Es muss sichergestellt werden, dass die Dateninhalte konsistent sind. Ffir das notwendige Management dieser Aufgabe sind u.a. Integrationsbeziehungen zwischen den Instanzen notwendig. Eine andere physische Heterogenit~it entsteht durch die Bildung von mehreren Varianten einer Anwendung. Unter einer solchen Variante versteht man alternative Auspr~igungen einer Anwendung ~ r unterschiedliche Umgebungen. Die Varianten unterscheiden sich durch minimale Modifikationen der ursprtinglichen Anwendung [s. Brodie/Stonebraker 1995, S. 249f]. Griinde ffir die Entwicklung solcher Varianten sind beispielsweise gesetzliche Bestimmungen (ein internationaler Konzern muss in jedem Land den gesetzlichen Anforderungen genfigen), unterschiedliche Sprachen der Benutzeroberfl~ichen usw. Die Verwendung einer betriebswirtschaftlichen Standardanwendungssoftware mit unterschiedlichen Parametrisierungen stellt ein weiteres Beispiel dar. Mfissen zwischen diesen Varianten Daten ausgetauscht werden, muss ein gemeinsames Verst~indnis der Daten sichergestellt sein. Weiterhin k6nnen Konvertierungender Daten ~ r die unterschiedlichen Plattformen notwendig werden.

Zusammenfassung Je nach vorliegender Heterogenit~it in den Modellen der beteiligten Anwendungen steigt der zu leistende Koordinationsaufwand bei der Integration. Homogene Modelle stellen den einfachsten Fall der Integration dar, einzig Redundanzmanagement und das Verwalten einer Verteilung sind zu berficksichtigen. Heterogene Modelle dagegen mt~ssen exakt aufeinander abgestimmt werden, um eine ad~iquate Verwendung der Daten und Methoden gew~ihrleisten zu k6nnen. Wie viele Modelle aufeinander abzustimmen sind, h~ingt ebenfalls vonder vorliegenden Form der Heterogenit~it

52

3 Grundlagen

ab. Im komplexesten Fall, heterogene Daten- und Applikationsmodelle, miassen vier Modelle gemappt werden. Somit steigt der Integrationsaufwand mit Zunahme der Heterogenit~it der beteiligten Anwendungsmodelle.

3.1.2.6 Integration und EAI Durch einen konstruktiven Vorgang wird aus vorhandenen Objekten ein neues Objekt geschaffen, das neben der Funktionalit~it der Ausgangsobjekte neue "Mehrwert-Funktionalit~iten" enth~ilt, welche sich aus dem Zusammenspiel der Ausgangsobjekte ergeben. Dies zielt auch auf eine mSglichst medienbruchfreie Abwicklung von Aufgaben und Prozessen ab. In diesem Sinne bringt die Integration Daten und Methoden verschiedener Anwendungen zur Umsetzung von Prozessen auf der Ebene Informationssystem zusammen. Integration kann sowohl als der Forgang zur Herstellung einer Einheit aus Teilen sowie der Einbeziehung eines Teils in ein grSsseres Ganzes als auch als ein Zustand von etwas nach Abschluss des Integrationsvorgangs verstanden werden.

Integration als Zustand definiert Kategorien der Integration und deren Auspr~igungen, anhand welcher verschiedene Grade der Integration unterschieden werden kSnnen. Integration als Vorgang betrachtet, wie ein Informationssystem von einem Integrationsgrad in einen hfheren tiberfiihrt werden kann [s. Riehm 1997, S. 10]. Bei der Integration als Forgang geht es um den Prozess des Zusammenftihrens von einzelnen Teilen zu einem Ganzen bzw. um die Eingliederung einer (neuen) Komponente in ein vorhandenes System [vgl. Fischer 1999, S. 86] 7. Die Informationstechnologie erlaubt eine zunehmende Integration zwischen bisher getrennten Medien (Daten, Text, Sprache, Bild), zwischen bisher getrennten Bereichen des Unternehmens (z.B. Verkauf, Kundendienst, Telefonzentrale) und zwischen rechtlich getrennten Unternehmen. Diese Verkniipfung unterschiedlicher Bereiche durch Integration von Anwendungen er6ffnet Potentiale ftir die Neugestaltung von Prozessen [vgl. Davenport 1993, S. 51; Hammer/Champy 1993, S. 91 ff; Jacobson et al. 1994, S. 290ff; Joosten et al. 1994, S. 113f; Osterle et al. 1992, S. 64; Riehm/Vogler 1995; Schltiter 1999, S. 1] und wird unter dem Begriff Enterprise Application Integration (EAI) zusammengefasst. Somit bildet die Integration auf Informationssystemebene einen wesentlichen Kernbereich im Business Engineering. Bei der Realisierung eines neugestalteten Prozesses in Form eines Workflows soil dieser durch die unterschiedlichen betroffenen Bereiche hindurch gesteuert werden, sollen die zur AufgabenausRihrung ben6tigten Anwendungen aus den unter-

7 Ein Systemist eine abgegrenzte,geordnete Gesamtheitvon Elementen,zwischen denen Beziehungenbestehen [s. Gierhake 1998, S.1 If; Schwarze 1994, S. 208; Ulrich 1970, S. 100ff]. Jedes Systemkann in untergeordnete Systeme (Subsysteme) zerlegt werden, ist zugleich aber auch Bestandteil eines umfassenden Systems (des Supersystems). Ein offenes Systeminteragiertmit anderen Systemendes Unternehmens.

3.1 Bezugsrahmenund Begriffsverst~indnisder Arbeit

53

schiedlichen Bereichen am Arbeitsplatz der Benutzer eingebunden sein und es soil ein konsistentes Informationssystem auf Basis der vorhandenen Anwendungen sichergestellt sein. Es herrscht jedoch noch keine Einigkeit t~ber die Verwendung des Begriffs EAI. So bezeichnen Hersteller von bislang unter dem Begriff Middleware bekannter Produkte (s. Abschnitt 6.2.3) heute ihre Produktpaletten neu als EAI-Tools. Darunter k6nnen dann unterschiedlich weitreichende Funktionalit~iten fallen, wie z.B. vom Message Broker bis hin zu integrierten Plattformen, welche auch Workflow-Funktionalit~iten anbieten. In den zahlreichen Ver6ffentlichungen zum Thema EAI lassen sich folgende Unterschiede erkennen: 9

Zum einen setzen Autoren implizit EAI mit der bislang bekannten Middleware-Integration gleich [vgl. Kloppmann et al. 2000].

9

Zum anderen wird EAI im Gegensatz zur klassischen Systemintegration mit Middleware als eine hOhere Integration bezeichnet, welche neben der syntaktischen vor allem auch die semantische Ebene der Integration betrachtet [vgl. Hasselbring 2000]

9

Andere Autoren verstehen EAI als Architektur zur Integration [vgl. Andersen Consulting 2000; Kurt 1999; Longo 2001 ].

9

Verschiedene Autoren gehen noch einen Schritt weiter und bezeichnen mit EAI sowohl die technologische Integration als auch das Vorgehen zur Umsetzung. EAI wird hier als Mechanismus verstanden, der eine Umsetzung von Gesch~iftsprozessen in das Informationssystem zum Ziele hat und dabei auf spezielle Integrationstools zurtickgreift [vgl. Lublinsky 2001; Mann 1999; Mathur et al. 2000; Ruh et al. 2001; Schlt~ter 1999; Stokes 2001 ]. Sie beziehen neben der Integration von Anwendungen vor allem auch die Integration von Prozessen in die Betrachtungen mit ein [vgl. Linthicum 2000; Ring/War-Dutton 1999].

Die vorliegende Arbeit schliesst sich dem Begriffsverst~indnis von EAI der letzten aufgeffihrten Gruppe an. EAI wird als ein Ansatz verstanden, welcher die Umsetzung von Gesch~iftsprozessen in Informationssystemen (sei es inner- oder zwischenbetrieblich) zum Ziel hat und sich dabei unterschiedlicher Integrationstypen bedient. EAI generiert Business L6sungen durch die Kombination von Applikationen und benutzt hierzu Middleware L6sungen. Die Verknt~pfung dieser Bestandteile zu einer reibungslosen Zusammenarbeit innerhalb von Workflows setzt eine Integration in drei Teilbereichen voraus: 9

die Prozessintegration,

9

die Desktopintegration und

9

die Systemintegration (vgl. Abb. 3.18).

54

3 Grundlagen

W~ihrend bei der Prozessintegration die UnterstiJtzung der aktiven Ablaufsteuerung im Vordergrund steht (vgl. Abschnitt 0), beschaftigt sich die Systemintegration vorwiegend mit der Integration von Anwendungen mit dem Ziel einer konsistenten Datenhaltung (vgl. Abschnitt 3.1.2.6.3). Die Desktopintegration hat die Verkntipfung der ~ r die Aufgabenausfftihrung relevanten Anwendungen am Arbeitsplatz zum Ziel und ist eine Spezialform der Prozessintegration unter Voraussetzung der Systemintegration (vgl. Abschnitt 3.1.2.6.2). Die Systemintegration 1/~uftgrunds~itzlich im Hintergrund ab. Der Benutzer tibt keinen direkten Einfluss auf sie aus. Demgegentiber ist er direkt sowohl mit der Desktopintegration als auch mit der Prozessintegration konfrontiert.

3.1.2.6.1 Prozessintegration Im Rahmen dieser Arbeit umfasst der Begriff Prozessintegration alle Massnahmen zur Steuerung einzelner Prozesse und der Zusammenarbeit zwischen Prozessen. Darunter fallen alle organisations- und funktionsiibergreifenden Untersttitzungen von Prozessen [vgl. Krcmar 1991, S. 7; Scheckenbach 1997]. Die wesentlichen Zielsetzungen sind die Durchg/ingigkeit bei der Aufgabenbearbeitung, d.h. die Vermeidung von Medienbriichen bei der Prozessabwicklung sowie die aktive Steuerung der Arbeitsabl/iufe im Sinne der Koordination von meh-

3.1 Bezugsrahmenund Begriffsverst~indnisder Arbeit

55

reren Benutzern mr die Zusammenarbeit in einem Prozess [vgl. Elgass/Krcmar 1994, S. 68f; Jablonski 1995a]. Vor allem im innerbetrieblichen Bereich findet seit den 90er Jahren eine intensive Betrachtung der aktiven und elektronisch unterst~itzten Prozesssteuerung (Prozessintegration) statt, Workflow-Managementsysteme und Groupware haben dazu wesentlich beigetragen. Die zwischenbetriebliche Untersti~tzung der Gesch~iftsprozesse fand lange Zeit trotz EDI- oder Online-Systemen nur wenig Beachtung. Der Durchbruch des Internets und die neueren Managementstrategien- wie z.B. die fraktale Fabrik [vgl. Scholl/Niemann 1994; Warnke 1993], das virtuelle Unternehmen [vgl. Mertens 1994], eCommerce oder Business Networking [vgl. Alt et al. 2002] - erfordern jedoch auch eine intensivere Beachtung der zwischenbetrieblichen Prozessintegration. Neben der Prozessintegration findet sich in der Literatur auch der Begriff Prozesskoordination. Sie besch~iftigt sich mit der Abstimmung von Prozessen [s. Gierhake 1998, S. 19q. Prozesse sollen gem~iss der Prozessarchitektur eines Unternehmens aufeinander abgestimmt ablaufen. Der Informations- und Datenfluss zwischen den Prozessen sowie die Abstimmung der Aufgaben an den Prozessschnittstellen steht bei diesen Betrachtungen im Mittelpunkt. Somit finden sich die Aktivit~iten der Prozesskoordination auf der Prozessebene des Business Engineering Modells wieder, w~ihrend die Aktivit~iten der Prozessintegration der Informationssystemebene zuzuordnen sind. Innerbetrieblich l~isst sich eine st~irkere Abstimmung und somit im weiteren Sinne eine Integration der Prozesse erreichen, zwischenbetrieblich dagegen kann vielfach- vor allem bei autonomen Partnern - nur eine schwache Koordination der Prozesse erzielt werden. Die Integration bis auf IS/IT-Ebene ist in diesen F~illen mit einem sehr hohen Koordinationsaufwand verbunden. Da sich konzeptionell keine wesentlichen Unterschiede zwischen der Prozesskoordination und der Prozessintegration ergeben, wird im Weiteren auf eine explizite Behandlung der Prozesskoordination verzichtet. Eine spezielle Form der Prozessintegration stellt die Desktopintegration dar.

3.1.2.6.2 Desktopintegration Jeder Benutzer verwendet an seinem Arbeitsplatz zur Aus~hrung seiner Prozessaufgaben verschiedene Anwendungen. Diese k6nnen in Bezug auf mehrere Aspekte heterogen sein (s. Abschnitt 3.1.2.5). So kOnnen sich die Hard- und Softwareplattformen unterscheiden wie auch die Benutzeroberfl~ichen. FOr eine durchg~ingige Unters~tzung der Aufgaben ist es notwendig, die relevanten Anwendungen am elektronischen Arbeitsplatz zu integrieren. Die Desktopintegration bindet die Anwendungen am Arbeitsplatz derart ein, dass diese an der entsprechenden Stelle im Ablauf aufgerufen, die erforderlichen Informationen (in einer einheitlichen Benutzeroberfl~iche) dargestellt und bei Bedarf Daten zwischen den Anwendungen am Arbeitsplatz ausgetauscht werden [vgl. Derungs et al. 1995b, S. 16]. Sie ist ftir die Ent-

56

3 Grundlagen

wicklung von Portalen notwendig und bedient sich mr die Interaktionen der relevanten Applikationen und Datensammlungen der Systemintegration. Die Zielsetzung der aktiven Steuerung des reibungslosen Ablaufs der einzelnen Tasks (Arbeitsschritte) ist identisch mit der Zielsetzung der Prozessintegration. Die Desktopintegration stellt jedoch eine andere Sichtweise als die Prozessintegration dar. W[ihrend die Prozessintegration den Steuerfluss zwischen den Aktivit~iten (den Workflow) in den Mittelpunkt der Betrachtung stellt, betrachtet die Desktopintegration den Datenfluss zwischen den involvierten Anwendungen (den Taskflow) n~iher. Abbildung. 3.19 zeigt zusammenfassend die Unterschiede zwischen Aufgabe, Aktivit~it und Task.

Detaillierungsgrad Sicht Aufgabentdiger BQndelung von Bezeichnung des Ablaufs Verbindung zum Informationssystem

Zusammenhang

Aufgabe Grob

Aktivitlit Mittel

Task Hoch

Prozess Leistungen Organisationseinheit/ Computer Weiter zerlegbaren Unteraufgaben Prozess

Benutzer Informationssystem Benutzer/Computer

Benutzer Anwendungen Benutzer/Computer

Gibt nur die Anwendungen an, die zur Unterst0tzung herangezogen werden.

Besteht aus einzelnen Tasks und wird als Aktivit~t implementiert Abb. 3.19:

Elementaren Tasks Workflow

Taskflow

Desktopintegrierte Aktivit~it entspricht einem ausf0hrbaren Programm, das mehrere Aufrufe von Anwendungen enthalten kann. Integriert die Tasks einer Aufgabe am Arbeitsplatz.

Ruft eine Anwendung auf [s. Systems & Computer Technology 2000].

Elementarer Arbeitsschritt einer Aufgabe/Aktivit~it.

Unterschiede Aufgabe - Aktivitgit - Task

3.1.2.6.3 Systemintegration Die S y s t e m i n t e g r a t i o n verbindet Anwendungen (bestehend aus Pr~isentationen, Applikationen und Datensammlungen) auf den Ebenen Informationssystem und Informationstechnologie, damit diese miteinander kommunizieren und gemeinsam Informationen nutzen k6nnen [s. Gray 2001, S. 3]. Sie befasst sich mit der Interaktion von Applikationen und Datensammlungen.

3.1 Bezugsrahmenund Begriffsverst~indnisder Arbeit

57

Ein Informationssystem setzt sich aus mehreren Anwendungen zusammen, bestehend aus Applikationen, die ihre eigenen Datensammlungen verwalten. Sowohl die Funktionalit~it als auch die Datenbest~inde der einzelnen Anwendungen k6nnen sich teilweise fiberlappen. Neu einzu~hrende Anwendungen verursachen ebenfalls Uberschneidungen mit alten L6sungen. Somit entstehen h~iufig unvermeidbare Doppelspurigkeiten und redundante Daten [Jacobson et al. 1994]. Ffir die Gew~ihrleistung eines in Bezug auf die Daten konsistenten Informationssystems sind Mechanismen erforderlich, die den Datenhaushalt zwischen den Anwendungen kontrollieren. Ftir diese Kontrolle ist ein gegenseitiges Verstehen der Anwendungen, d.h. eine Standardisierung der auszutauschenden Daten, notwendig. Die Systemintegration definiert, 9

welche Applikationen auf Daten anderer Applikationen zugreifen,

9

wie dieser Zugriffzu gestalten ist,

9

welche Daten in mehreren Datensammlungen redundant gehalten werden und

9

wie der Redundanzabgleich zu erfolgen hat.

Die Systemintegration verfolgt somit eine Architektur der Schnittstellen (d.h. Integration von eigenst~indigen Anwendungen durch Datenaustausch) [s. Gassner 1996, S. 14]. Abb. 3.20 zeigt die Systemintegration im Rahmen eines heterogenen Informationssystems.

58

3 Grundlagen

3.2 Integration in Wissenschaft und Praxis Mit dem Thema Integration setzen sich Wissenschaft und Praxis schon seit langem auseinander. Bereits Ende der 50er Jahre erkl~irten [Leavitt/Whisler 1958], dass ein Untemehmen der Zukunft erheblich v o n d e r Integration mit Hilfe der Informationstechnologie beeinflusst werde, was sp/~ter [Galbraith 1968] best~itigte. Die nachfolgenden Ausflihrungen zeigen einen Oberblick tiber die unterschiedlichen Ans/itze, ordnen diese soweit m6glich den beiden Integrationstypen der Arbeit zu und zeigen Standardisierungsbemtihungen diverser Gremien im Bereich der technologischen Integration. Die Wissenschaft - im speziellen die Informatik und die Wirtschaftsinformatik - besch/fftigen sich seit vielen Jahren mit dem Thema der Integration auf der Informationssystem- und Informationstechnologieebene (siehe Abschnitt 3.2.2). So gilt die Integration der Informationsverarbeitung als Kemthema der Wirtschaftsinformatik [vgl. Kurbel/Rautenstrauch 1996; Mertens 1995]. [Heinrich 1993, S. 73] geht weiter und bezeichnet die Wirtschaftsinformatik als Integrationswissenschaft. Die Informatik betrachtet das Problemfeld Integration vor allem im Umfeld der Datenbankforschung und bei der Weiterentwicklung verteilter, oftener Systeme. Im Vordergrund der Betrachtungen und Forschungen stehen hierbei meist die Formen der Integration sowie der Entwurf eines integrierten Informationssystems [Scheer 1993; Scheer 1994]. Ein Vorgehen ~ r die Zusammenfiihrung von Insell6sungen ist bisher noch nicht im geforderten Umfang zu finden, h~iufig beziehen sich die Betrachtungen auf das Zusammenflihren von neu entwickelten Subsystemen zu einem Gesamtsystem [vgl. Mowbray/Zahavi 1995, S. 5f] und lassen dabei die Altsysteme ausser Acht. Diesen fehlenden Einbezug der bestehenden Anwendungen ~hrt z.B. [Konstantas 1995] als entscheidendes Hemmnis flir die Realisierung objektorientierter Systeme an. Auch innerhalb der Untemehmen ist die Bedeutung der Integration seit langem erkannt. Der Einsatz der Informations- und Integrationstechnologie kann zum entscheidenden Wettbewerbsvorteil ~hren, wenn neben der lokalen Datenverarbeitung und Automatisierung einzelner Prozesse auch die Gesch/fftsaktivit/iten miteinander verbunden werden. [Meffert 1994, S. 1Off] erkl/irt diese Sachverhalte an Beispielen und zeigt, dass trotz der hohen Bedeutung der Integration und der doch langen Auseinandersetzung mit ihr, sie immer noch eines der zentralen Ftihrungsprobleme darstellt. Die drei eingefiJhrten Teilbereiche der Integration (Prozess-, Desktop- und Systemintegration) lassen sich mit bekannten Beschreibungsm6glichkeiten von Integrationsformen Is. Linl3 1995, S. 130] nur beschr/~nkt vergleichen. [Gassner 1996, S. 13ff] stellt der Ablaufsteuerung die Integration von Prozessen, der Desktopintegration die Funktionsintegration und der Systemintegration die Datenintegration gegentiber. In Anlehnung an [Scheer 1990] oder [Becker 1991, S. 167] untersttitzt die Systemintegration die Prozessintegration. Es handelt sich aber beim hier gew~ihlten Ansatz um problemorientierte Sichten. Sie k6nnen jeweils gleichzeitig die verschiedensten Integrationsobjekte (Daten, Funktionen, Programme), Integrationsrichtungen (horizontal, vertikal) und Integrationsreichweiten (innerbetrieblich, zwischenbetrieb-

3.2 Integrationin Wissenschaftund Praxis

59

lich) betreffen. Zudem verfolgen die drei hier gew~ihlten Sichten auf die Integration nicht die Beschreibung von verschiedenen Integrationsstufen - im Gegensatz zu anderen Klassifikationen [s. z.B. Mertens/Morschheuser 1994, S. 447ff; Scheer 1990, S. 162ff] - und den damit verkntipflen Integrationszust~nden eines Informationssystems. Vielmehr bilden sie den Ausgangspunkt und Rahmen fiir Integrationsprojekte. Die folgenden Ausfiihrungen zeigen, wie sich andere Disziplinen der Wissenschaft mit dem Thema Integration auseinandersetzen.

3.2.10rganisationslehre Die Organisationslehre spricht vonder Aufgabenintegration. Darunter ist die Zusammenfassung durch Arbeitsteilung getrennter Vorg~inge zu verstehen [vgl. Gais 1994, S. 5 l f; Stietz 1994]. Die verst~irkte Zusammenfiihmng yon Aufgaben sieht [Gais 1994] als Folge der Integrations- und Vernetzungstendenzen yon Soft- und Hardware, welche zur Bildung neuer integrativer Organisationskonzepte fiihren. Die Organisationskonzepte differenzieren nach der Richtung in eine vertikale und horizontale Integration. W~ihrend sich die vertikale Aufgabenintegration mit der Verbindung yon Aufgaben unterschiedlichen Niveaus (z.B. durch Riickdelegation oder Reintegration) befasst, legt die horizontale Integration den Schwerpunkt auf die Zusammenfiihrung sachverwandter Aufgaben im Sinne einer ganzheitlichen Sachbearbeitung. Bei der Bildung der entsprechenden Arbeitspakete findet die verfiigbare Informationstechnologie zu wenig Beachtung. Somit miissen die Erkenntnisse der Organisationslehre um die M6glichkeiten der Informationstechnologie im Rahmen der Prozessintegration angereichert werden. Die Zusammenarbeit zwischen unterschiedlichen Organisationseinheiten bedarf der Abstimmung zwischen den beteiligten Kommunikationspartnern sowohl auf technischer als auch auf organisatorischer Ebene. Organisatorische Fragestellungen sind die Koordination der Abl~iufe in beiden Organisationseinheiten und damit zusammenh~ingend die Verwendung der Daten im richtigen Kontext [Scheckenbach 1997, S. 69]. Mit der zwischenbetrieblichen Integration auf der Prozessebene setzt sich z.B. ausfiihrlich [Scheckenbach 1997] auseinander. Er entwirft eine Architektur fiir die Integration externer Gesch~iftsprozesse in betriebswirtschaftlichen Anwendungssystemen. Die Fragestellungen der zwischenbetrieblichen Integration unterscheiden sich von denen der innerbetrieblichen dabei nicht. In beiden F~illen untersttitzen verschiedene Applikationen/Anwendungssysteme die Funktionen und Aufgaben der Prozesse. Jedes der involvierten Systeme besitzt dabei seine eigene systemimmanente Vorgangssteuerung. Eine Prozessintegration erfordert in beiden F~illen (innerbetrieblich und zwischenbetrieblich) eine Abstimmung der Schnittstellen und Koordination des Informationsflusses. [Scheckenbach 1997] legt das Problem der fehlenden L6sungen fiir die Validierung der Daten sowie fiir die Steuerung und Uberwachung der zwischenbetrieblichen Gesch~iftsprozesse often.

60

3 Grundlagen

Die Prozessebene weitet die reine Informationsflussbetrachtung aus. Der Begriff Prozessintegration umfasst alle Massnahmen zur Koordination einzelner Prozesse. Darunter fallen alle organisations- und funktionstibergreifenden Untersttitzungen von Prozessen [vgl. Mertens 1995, S. 3]. Vor allem im innerbetrieblichen Bereich findet eine intensive Betrachtung der aktiven und elektronisch untersttitzten Prozesssteuerung (Prozessintegration) seit den 90er Jahren statt. Workflow-Managementsysteme und Groupware finden in diesem Bereich ihren Einsatz. Die zwischenbetriebliche Untersttitzung der Gesch~iftsprozesse konnte sich lange Zeit trotz EDIoder Online-Systemen nicht durchsetzen. Der Durchbruch des Internet, XML als Standard Beschreibungssprache ftir den Datenaustausch und die neueren Managementstrategien- wie z.B. die virtuelle Fabrik, Business-to-Business oder eCommerce - erfordern jedoch auch eine intensivere Beachtung der zwischenbetrieblichen Prozessintegration.

3.2.2 Wirtschaftsinformatik

Das Vorgehen bei der Integration im Rahmen von Methoden zur Neuentwicklung von Applikationen ist ein wesentliches Arbeitsgebiet der Wirtschaf~sinformatik und wird dort in verschiedenen Zusammenh~ingen und Zielsetzungen betrachtet. Der Schwerpunkt der Forschungsarbeiten hat sich in der Vergangenheit mehrfach verlagert. Waren zu Beginn der 70er Jahre die Bemtihungen vor allem im Bereich der Integration konzeptioneller Modelle sehr hoch, so hat sich in der ersten H~ilfte der 90er Jahre der Schwerpunkt auf die Datenintegration verlagert [vgl. Kurbel/Rautenstrauch 1996]. Heute haben sich die Forschungsanstrengungen- vor allem auch nach dem Fehlschlagen der unternehmensweiten Datenmodelle (UDM) [Sinz 1995] - auf weitere Objekte ausgedehnt. Hinzugekommen ist z.B. die Erforschung der Integration von Objekten und Methoden [vgl. Griffel 1998]. Ftir eine detaillierte Ausftihrung der unterschiedlichen Integrationsans~itze der Wirtschaftsinformatik sei hier auf die entsprechenden Arbeiten in der Literatur verwiesen. Zum Beispiel geben [Lehner 1994; Mertens/Holzner 1992; Stickel 2001] einen (]-berblick tiber die diversen Integrationsformen,-bereiche und-modelle oder [Meffert 1994] behandelt die Integration aus unterschiedlichen Dimensionen heraus. Alle Bemtihungen zur Integration verfolgen mehr oder weniger das Ziel eines integrierten Informationssystems, das nach [Hansen 1997] folgende Merkmale vorweisen muss: 9

Die Prozesse und die sie untersttitzenden Informationsverarbeitungsprozesse sind umfassend aufeinander abgestimmt.

9 Die Verbindungen zwischen den einzelnen Programmen sind weitestgehend automatisiert. 9

Die Daten werden so frtih wie m6glich erfasst und ftir alle nutzenden Programme gemeinsam unter zentraler Verwaltung gespeichert.

Somit stellt Hansen den Zusammenhang zwischen den Ebenen Prozess und Informationssystem des Business Engineering im Rahmen der Integration her.

3.2 Integrationin Wissenschaftund Praxis

61

[Kurbel/Rautenstrauch 1996; Ruh et al. 2001, S. 133f] beschreiben drei unterschiedliche M6glichkeiten, wie ein integriertes Informationssystem entwickelt werden kann: 9 Neuentwicklung eines umfassenden integrierten Informationssystems Die Konzepte und Instrumente zur Entwicklung solcher komplexer bereichsfibergreifender Informationssysteme sind z.B. aus dem Information Engineering nach [Hilbers 1992; Krcmar 1990; Martin 1989] bekannt. 9 Nachtr~igliche Integration bestehender Anwendungen oder Informationssysteme Das integrationsorientierte Reengineering nach [Eicker et al. 1993; Eicker et al. 1992] besch~iftigt sich mit der Aufbereitung vorhandener Informationssysteme. 9

Entwicklung integrationsf~ihiger Einzelsysteme und schrittweise Zusammenfiihrung Diese Ans~itze berticksichtigen in der Regel die Integration einer Anwendung in eine IstSystemumgebung nicht in dem notwendigen Masse. Integration bezieht sich hierbei vielmehr auf die Zusammensetzung von neu entwickelten Subsystemen zu einem Gesamtsystem [Mowbray/Zahavi 1995; Turowski 2001].

Ein relativ breit angelegtes Forschungsfeld, das all diese Aspekte einbezieht, ist das von Kurbel eingetiihrte Integration Engineering [Kurbel/Rautenstrauch 1996]. Es umfasst die Analyse, Entwicklung und Anwendung von Prinzipien, Modellen, Methoden und Werkzeugen ftir die Erstellung von integrierten Informationssystemen. Bisherige Arbeiten dieses Forschungsfeldes betrachten prim/ar die Realisierung von sogenannten Applikations-Servern, welche globale Daten und Funktionen verwalten, sowie die Integration von Datenmodellen, wobei auch die Datenschemata von Altsystemen ex post einbezogen werden [Eicker et al. 1992]. Alle Forschungsanstrengungen der Wirtschaftsinformatik haben gemeinsam, dass sie im wesentlichen von neuen Systemumgebungen ausgehen und evolution/are Entwicklungen, wie sie in der Praxis die Regel sind, nicht oder nur ungeni~gend berticksichtigen.

3.2.3 Informatik

Auch die Informatik besitzt keine einheitliche Sichtweise auf die Integration. In der Welt der Datenbanken bedeutet Integration vor allem den konsistenten Zugriff verschiedener Rechnerprozesse auf gemeinsame Daten. Im Bereich des Software Engineering besch~iftigen sich die Forscher mit dem Zugriff auf andere Applikationen oder Informationssysteme. Im Forschungsumfeld der Systemintegration steht die Verbindung von Rechnern, Netzwerken und der darauf installierten Software im Vordergrund. Die Forschungsbemtihungen im Bereich der Netzwerke befassen sich mit dem Zugriff auf in einem Netzwerk verteilte Ressourcen [vgl. Umar 1993, S. 455] Die Informationssysteme der Unternehmen zeichnen sich in der Regel durch mehr oder weniger koordiniert gewachsene Datenbest~inde aus, die jeweils ein eigenes konzeptionelles Schema besitzen. Unterschiedliche Datenmodelle sowie semantische Abweichungen der glei-

62

3 Grundlagen

chen oder miteinander in Beziehung stehenden Daten in verschiedenen Datenbanken ftihren zur Heterogenit~it der Daten [vgl. Sheth/Larson 1990, S. 18617. Hinzu kommen noch redundante und h~iufig in der Folge auch inkonsistente Daten, welche die Integrationsaufgabe erschweren. Die Integration der Datenbankschemata stellt einen Ansatz zur 0berwindung dieser Probleme dar. Es existieren in der Literatur eine Reihe von vorgeschlagenen Methoden und Algorithmen fiir die Schemaintegration [s. z.B. Batini et al. 1986; Geller et al. 1992; Hunstock/Stickel 1994], die ftir das Problem des Erkennens und AuflSsens semantischer Konflikte aber noch keine generelle LSsung gefunden haben [vgl. Naiman/Ouksel 1995; Thieme/Siebes 1995]. Allen Anstrengungen gemeinsam ist die Bereitstellung einer Infrastruktur, die einen Datenaustausch in einer verteilten, heterogenen Systemwelt ermSglichen soil. Umfassende Methoden fiir die Prozess- und Systemintegration, welche neben den technologischen auch organisatorische Aspekte berticksichtigen, fehlen bisher. Auch die Entwicklung von EAI- und Middlewareprodukten zielt nur auf technologische LSsungen ab. Dem Vorgehen in den Integrationsprojekten wird in der Informatik zu wenig Beachtung geschenkt.

Die folgende Tabelle (Abb. 3.21) zeigt zusammenfassend die Forschungsschwerpunkte der drei vorgestellten Disziplinen sowie die fehlenden Aspekte zur Behandlung der Integration im Sinne einer evolution~iren Weiterentwicklung des gesamten Informationssystems.

3.2 Integrationin Wissenschaftund Praxis

63

3.2.4 Standardisierungsvereinigungen Nicht nur die Wissenschaft, auch Anwender und Hersteller von Integrationsprodukten versuchen die Integrationsproblematik zu bew~iltigen. Sie versuchen durch Entwicklung und Bereitstellung yon Standards die Integration zu erleichtern. Die folgenden Abschnitte gehen auf die wesentlichen Standardisierungsgremien, deren Zielsetzungen sowie den aktuellen Stand ihrer Arbeiten ein und zeigen die Entwicklungen von bedeutenden Herstellern im Bereich der Untersttitzung von Integration. Der Abschnitt 4.7 erl~iutert die Bedeutung von Standards ~ r die Integration.

3.2.4.1 Standardisierungsebenen im Informationssystem Standardisierung handelt im Allgemeinen yon der Vereinheitlichung yon Objekten [Meffert 1994; Wiese 1990], indem die Auspr~igungen der Struktur und des Verhaltens der Objekte spezifiziert wird. Die gemeinsame Verwendung dieser Objekte schafft Kompatibilit~it. Betrachtet man das Informationssystem als eine Menge von Objekten, so ist eine Klassifizierung dieser f'tir die weitere Betrachtung sinnvoll, um die Frage "Welche Objekte lassen sich im Bereich der Informationssysteme standardisieren?" hinreichend beantworten zu k6nnen. Ein Informationssystem besteht aus unterschiedlichen Elementen wie Hard- und Software, Menschen usw. Die Software lgsst sich in unterschiedlichen Ebenen einordnen. Eine m6gliche Einteilung stellt die Abbildung 3.7 dar, sie unterteilt die Softwareelemente eines Informationssystems in die Ebenen Systemsoftware, Middleware sowie betriebliche Anwendungen. Somit stellt diese Einteilung eine Abstraktion und Erweiterung des ISO/OSI Modells dar. Die erwghnten Ebenen benutzen die Hardware des Informationssystems. Standards k6nnen auf all diesen Ebenen vorkommen. Im Bereich der Hardware ~hren Standards zur Vereinheitlichung der Rechnerarchitekturen, welche wiederum eine problemlose Obertragung ohne Portierungsaufwand von Middleware oder Anwendungen auf unterschiedliche Hardwaresysteme erlauben wi~rde. Jedoch verhin-

64

3 Grundlagen

dem die Eigeninteressen der Anbieter h~iufig eine weitgehende Durchdringung dieses Bereiches mit Standards [vgl. Meffert 1994, S. 87f]. Die Ebene Systemsoftware umfasst Betriebssysteme und Software zum Austausch von Daten tiber Rechnemetze [Elbert/Martyna 1994, S. 13]. Heute kann zumindest teilweise von einer Standardisierung der Systemsoftware gesprochen werden. So entwickelt sich auf der einen Seite das Microsoft Betriebssystem Windows NT bzw. Windows 2000 zum de facto Standard, auf der anderen Seite sind Unix Systeme anzutreffen.

Middleware ist eine Softwareschicht zwischen den betrieblichen Anwendungen und der Systemsoftware, welche auf Basis einheitlicher Schnittstellen und Protokolle Dienste mr eine transparente Kommunikation verteilter Anwendungen bereitstellt. Sie stellt somit eine Infrastruktur fiir die Integration von Applikationen und Daten in einem heterogenen und verteilten Umfeld zur Ver~gung [s. Astley et al. 2001, S. 101; Riehm 1997, S. 97f]. Im Bereich der Middleware kann nicht von einem allgemein akzeptierten Standard gesprochen werden, da eine Vielzahl unterschiedlicher Produkte auf dem Markt existieren. Eine Vormachtstellung einzelner Anbieter ist nicht zu erkennen (s. Abschnitt 6.2.4). Im Rahmen der betrieblichen Anwendungen sind zwei unterschiedliche Standardisierungsrichtungen m/Sglich. Die Standardisierung der eigentlichen Anwendung und die der Schnittstellen. Im ersten Fall entstehen StandardsoftwarelSsungen wie z.B. SAP R/3 oder Baan IV. Die Verwendung solcher Lfsungen untersttitzt die Interaktion zwischen den unterschiedlichen Akteuren, indem sie neben Regeln fiir den Austausch von Informationen zwischen den einzelnen Modulen auch die Verwendung und Verarbeitung der Informationen und somit den Inhalt spezifizieren. Standardsoftwarel6sungen sind jedoch fiir ein spezielles Einsatzgebiet wie z.B. einer Branche konzipiert und lassen sich demzufolge nicht branchentibergreifend einsetzen. Verwenden zwei Untemehmen unterschiedliche StandardsoftwarelSsungen gestaltet sich eine zwischenbetriebliche Integration trotz der Standardsoftware nicht einfacher. Der zweite Fall - die Standardisierung von Schnittstellen - ist Gegenstand vieler Forschungsanstrengungen. In diesem Bereich existieren heute jedoch nur vereinzelt generelle Standards wie z.B. die Spezifikationen der WAPI [WfMC 1997b]. Die Grenzen fiir die Spezifikation von standardisierten Schnittstellen liegen in den untemehmensspezifischen Anwendungen. Deren Systemgrenzen sowie ihre bereitgestellten Funktionalit~iten variieren sehr stark, wodurch die Definition von generellen Schnittstellen ftir den innerbetrieblichen Datenaustausch erheblich erschwert wird. H~iufig herrschen deshalb Individuall/Ssungen vor [vgl. M~innel 1994; ScholzReiter 1991]. Verschiedene Anbieter von Standardsoftwareltisungen tibertragen daher standardisierte Obertragungsdateien in Anlehnung an den zwischenbetrieblichen Standard EDIFACT auf den innerbetrieblichen Bereich. Ein Beispiel fiil" derartige Anstrengungen ist die Architektur des SAP R/3 Systems (s. Abschnitt 3.2.4.5). Die Integration der SAP-Applikationen soil hierbei tiber den Austausch von standardisierten Dokumenten (sogenannten IDOCs, Intermediate Document) erfolgen. Jedoch handelt es sich hier um keinen national oder international sanktionierten Standard, die Verbreitung der Standardsoftwarel/Ssung l~isstjedoch auf einen zuktinftigen de facto Standard schliessen.

3.2 Integrationin Wissenschaftund Praxis

65

Im Rahmen der Datenkommunikation existiert heute schon eine Reihe von Standards wie z.B. SQL als Datenbanksprache, Protokolle wie TCP/IP sowie EDI-Standards zur Obertragung von Handelsdokumenten. Die Verwendung dieser untersttitzt die Interaktion innerhalb des Informationssystems auf unterschiedlichen Ebenen. XML erlaubt die Spezifikation der auszutauschenden Information auf Basis einer allgemeingtiltigen Beschreibungssprache. Verschiedene Initiativen verwenden den XML-Standard, um ftir das jeweilige Anwendungsgebiet weitreichendere Standards ftir den Datenaustausch vor allem im zwischenbetrieblichen Bereich zu entwickeln (s. Abschnitt 3.2.4.7)

3 . 2 . 4 . 2 0 S F und DCE

Die Open Software Foundation (OSF) formierte sich Ende der achtziger Jahre, war ursprtinglich eine von HP, DEC und IBM finanziell getragene Gruppierung und ging gemeinsam mit der X/Open Vereinigung in die Open Group tiber. Ihr Ziel bestand in der Entwicklung eines Middlewarestandards fiir verteilte Client/Server Systeme. Das Distributed Computer Environment (DCE) ist eine Sammlung von integrierten Diensten, welche die Entwicklung von verteilten Anwendungen tiber heterogene Systeme hinweg erm6glicht [Bond et al. 1998a, S. 765f; Geihs 1995, S. 51ff; Langenohl 1994, S. 227ff; Lockhart 1994; Open Group 1996] (s. Abb. 3.22).

Die sogenannte DCE Executive setzt sich aus einer Sammlung von integrierten Middlewarediensten der Kategorien Kommunikationsdienst und Verteilungsdienst (s. Abschnitt 6.2.4) zusammen, wobei ein RPC-Mechanismus die zentrale Komponente ist. Neben dem RPC

66

3 Grundlagen

(Remote Procedure Call, s. Abschnitt 6.2.4.4) zur transparenten Kommunikation zwischen Clients und Server stehen im DCE noch die Komponenten Directory Services (zur Unterstiitzung der Administration), Distributed Time Service (zur Synchronisation mehreren Uhren), Security Services (zur Untersttitzung der Authentifizierung, Autorisierung, Integrit~it und Privacy) und Threads Service (zum Management von multiplen Threads) zur Ver~gung. Dartiber hinaus sollen die DCE Extended Services ein verteiltes Filesystem unterstiJtzen. Mit DME (Distributed Management Environment) soil noch ein integrierter Dienst flar das Netzund Systemmanagement entstehen [s. Geihs 1995, S. 62ff]. DCE legt den Schwerpunkt auf die Entwicklung von verteilten Anwendungen. Die evolution~ire Weiterentwicklung bestehender Informationssysteme und insbesondere die Berticksichtigung von alten Hostsystemen, welche nicht der Client/Server Architektur entsprechen, werden nicht abgedeckt. Somit hilft der Einsatz des DCE nur beschr~inkt bei der Bewaltigung der Integrationsprobleme in heterogenen Informationssystemen.

3 . 2 . 4 . 3 0 M G und CORBA

Das breit angelegte Standardisierungsgremium OMG (Object Management Group) verfolgt mit CORBA das Ziel, einen Standard ftir die Systemintegration auf Basis verteilter Objektorientierung zu etablieren. Die OMG grtindete sich 1989 als ein Konsortium von Herstellem von Objekttechnologie. Mittlerweile umfasst dieses Gremium mehr als 800 Mitglieder [OMG 2001]. Hinter dieser Vereinigung von Herstellem steht die Vision, flexible Client/Server L6sungen durch Integration kommerziell beziehbarer Komponenten im Sinne eines ,,plug and play" entwickeln zu k6nnen. Zur Verwirklichung dieser Vision sollte eine Infrastruktur ftir die verteilte Objektorientierung geschaffen werden. Diese Infrastruktur soil eine transparente Interaktion verteilter Objekte bzw. Komponenten nach dem Client/Server Modell erlauben, d.h. fiber verschiedene Netzwerke, Programmiersprachen, Betriebssysteme und Applikationen hinweg. Ergebnis der OMG-Arbeiten ist die Common Object Request Broker Architecture (CORBA). Diese hat die OMG mit den Arbeiten der Object Management Architecture (OMA) abgesteckt [Soley 1992]. Neben einem Objektmodell, das die verwendeten Konzepte und Terminologien der Objektorientierung abgrenzt, beinhaltet die OMA ein Referenzmodell mit den Komponenten Object Request Broker, Object Services, Facility Objects, Domain Objects und Application Objects (siehe Abbildung 3.23) [vgl. Bond et al. 1998b; Brando 1996; Mowbray/Zahavi 1995; OMG 1997].

3.2 Integrationin Wissenschaftund Praxis

67

Der Kem der Standardisierung im Rahmen der OMG-Anstrengungen ist die Beschr/~nkung auf die Spezifikation der Schnittstellen der einzelnen Komponenten, die Produktentwicklung liegt allein bei der Softwareindustrie [vgl. OMG 1998]. Die Schnittstellen werden in der CORBA Interface Definition Language (CORBA IDL) spezifiziert. Im Folgenden werden die wesentlichen Komponenten der Architektur kurz erl/iutert. 9

Objekt Request Broker Der Object Request Broker (ORB) ist der Kem von CORBA, der es Objekten erm6glicht, Methoden in anderen Objekten aufzurufen und die da~r erforderliche Kommunikation zwischen Client- und Serverobjekten t~bemimmt (s. Abschnitt 6.2.4).

9

Object Services Die Common Object Services stellen verschiedene, grundlegende Dienste zum Bau verteilter Applikationen zur Verfiigung und bilden zusammen mit dem ORB die eigentliche CORBA Middleware fiir die Integration. Sie k6nnen von allen CORBA-Anwendungen genutzt werden und unterstt~tzten unter anderem die persistente Speicherung von Objekten, die Verwaltung der Beziehungen zwischen Objekten, die Verwaltung von Ereignissen von Objekten, die Identifikation von Objekten auf Grund des Namens oder bestimmter Eigenschaften sowie die Kontrolle des Zugriffs auf Objekte [vgl. Emmerich 2000, S. 89; Mowbray et al. 1997; Weske 1999]. Durch die Bereitstellung dieser grundlegenden Dienste k6nnen die CORBA-Anwendungen effektiver entwickelt werden, da sie auf die Programmierung dieser Funktionalit/~ten verzichten k6nnen.

9

Facility Objects W/~hrend die Common Object Services lediglich fiir die Interoperabilit/~t von verteilten Komponenten sorgen, sollen die Common Facilities die Zusammenarbeit der Komponenten auf einer applikatorischen Ebene regeln. Horizontale Common Facilities decken die

68

3 Grundlagen anwendungsunabh~ingigen Bereiche einer Applikation ab. Auf dieser Ebene existieren mit OpenDoc des OMG Partnerkonsortiums CI Labs und der OMG Workflow Management Facility bereits Spezifikationen [Miller et al. 1996]. Weitere Dienste sollen z.B. ftir das Drucken oder die Kalenderfunktionalit~it bereitgestellt werden [s. Ruh et al. 2001, S. 91].

9 Domain Objects Ursprtinglich wurden die Dienste ftir ausgew~ihlte Applikationsdom~inen, z. B. ftir Anwendungen der Finanzdienstleistungen, des Gesundheitswesens (CORBAmed), des eCommerce, oder der Telekommunikation, als vertikale Common Facilities bezeichnet. Die steigende Bedeutung in diesem Bereich fiihrte zu einer Ausgliederung in eine separate Gruppe, den CORBA domains [vgl. Zahavi 2000, S. 106]. In diesen Bereichen gibt es derzeit noch keine fertigen Standards. 9 Application Objects (Jber CORBA zu integrierende Applikationen mtissen nicht zwingend objektorientiert entwickelt sein. Dementsprechend k6nnen die Applikationsobjekte Eigenentwicklungen, Standardsoftware und auch Altsysteme umfassen. Einzige Voraussetzung ist, dass die Applikationen fiber eine CORBA kompatible Schnittstelle ansprechbar sind. Somit kann ein Altsystem als ein Objekt gelten, das tiber eine in CORBA IDL spezifizierte Schnittstelle Zugriff auf ihre Transaktionen und einzelne Funktionen zul~isst [vgl. Macko/Parodi 1995]. Vor diesem Hintergrund gibt es keine Standards fiir Applikationsobjekte selbst, sondern nur ftir deren Schnittstellen. Die Standardisierung auf Ebene der Common Object Services ist vergleichsweise weit fortgeschritten und es sind in diesem Bereich bereits CORBA Implementierungen am Markt erh~iltlich. Die OMG hat zur Gew~ihrleistung der Interoperabilit~it der Produkte Ende 1996 die Version 2 der CORBA Spezifikation verabschiedet. Die darin enthaltenen Protokolle betreffen den Austausch zwischen ORB Implementierungen allgemein und speziell bei Einbezug des Internet sowie den Austausch eines ORB mit weiteren verteilten Umgebungen wie DCE (GIOP, IIOP, ESIOP - General, Internet, Environment Specific Inter-ORB Protocol). Die Standardisierung auf h6herer, applikatorischer Ebene dagegen ist noch nicht sehr weit fortgeschritten [vgl. Frank 2001, S. 284]. Hier spielt neben der Syntax die Semantik der Begriffe eine wesentliche Bedeutung. Diese muss in die Standardisierung aufgenommen werden, um Komponenten verschiedener Hersteller miteinander kooperieren zu lassen. Eine Standardisierung der Begriffe ist in der Regel ein langwieriger Prozess, sind doch exakte Abstimmungen und Abgrenzungen zwischen den beteiligten Partnern notwendig. Innerhalb der OMG besch~iftigt sich die Business Object Management Special Interest Group (BOMSIG) mit der Definition von Business Objects, die einen Gegenstand der Realwelt sowie dessen Verhalten modellieren [Maamar/Sutherland 2000; Orfali et al. 1996; Taylor 1995]. Konkrete Business Object Spezifikationen durch die OMG bestehen jedoch nicht. Die Spezifikationen der OMG haben sich in einer Reihe von Produkten niedergeschlagen wie z.B. dem Component Broker vonder Firma IBM [IBM 2001; Ruh et al. 2001 ]. [Linnhoff-Po-

3.2 Integrationin Wissenschaftund Praxis

69

pien 1998, S. 41 ] zeigt einen ausftihrlichen Vergleich der am Markt existierenden CORBA Implementierungen sowie die Defizite dieser auf. Leider fehlen im Rahmen der CORBA Spezifikationen Angaben tiber das erforderliche Vorgehen. Es bleibt den Unternehmen tiberlassen, aus den monolithischen Altsystemen entsprechende Services zu identifizieren, welche in Zukunft mittels CORBA zur Verfiigung stehen sollen.

3.2.4.4 Microsoft und OLE/DCOM sowie DNA 2000

Ebenso wie die OMG verfolgt auch Microsoft mit Network OLE, auch DCOM (Distributed COM) genannt, die Vision verteilter Komponenten. Den Kern des OLE Konzepts bilden Schnittstellen, welche durchschnittlich sechs Funktionen anbieten. Eine OLE Komponente wird durch eine Gruppe von Schnittstellen definiert. Im Gegensatz zu CORBA untersttitzt COM keine Vererbung und erlaubt somit nur die Bildung einer flachen Klassenhierarchie durch Aggregation von bestehenden Komponenten. Abbildung 3.24 zeigt eine vereinfachte Darstellung der relativ komplexen OLE Technologie und ordnet die Konzepte den bei CORBA verwendeten Ebenen zu [Microsoft 1995; Orfali et al. 1996]. OLE basiert auf dem Component Object Model (COM), das die Funktion eines Object Request Brokers (ORB) (siehe Abschnitt 3.2.4.3) tibernimmt. Dariiber hinaus wird COM durch eine Reihe von Diensten erg~inzt, die eine Zusammenarbeit von Komponenten erm6glichen.

Auf COM setzen die Konzepte der Compound Documents und der OLE Automation auf. Das Management zusammengesetzter Dokumente (Compound Documents) war ursprtingliches Ziel von OLE (Object Linking and Embedding). Dem Benutzer sollte es m6glich sein, z.B. ein Textdokument als Container mr Tabellen- oder Grafikobjekte zu verwenden. Ein Doppelklick mit der Maus auf das entsprechend eingebundene Objekt stellt dem Benutzer innerhalb der Textverarbeitung dann die zugeh6rige Funktionalit~it, z. B. des Grafikprogramms, zur Verftigung (engl.: in-place-activation).

70

3 Grundlagen

Mit der 1993 eingeffihrten Version 2 von OLE auf Basis von COM erweitert Microsoft OLE mit dem Konzept OLE Automation zu einer allgemeineren Architektur mr objektorientierte Applikationen. Ein Automation Server, z.B. eine Tabellenverarbeitung, stellt dabei fiber Schnittstellen seine Funktionalit~it einer weiteren Applikation, dem Automation Controller, zur VerRigung. Die Benutzerschnittstelle ist davon nicht betroffen, weshalb dem Benutzer die Verwendung der Funktionalit~it der Tabellenverarbeitung verborgen bleibt. Mit den ActiveX Controls hat Microsoft die OLE Custom Controls, auch OCX genannt, Rir das Internet technologisch weiterentwickelt. Ein OCX ist eine vorgefertigte Komponente mit definierten Schnittstellen und kann als Automation Server in eine Applikation eingebunden werden. Mit Hilfe eines OCX ist es z. B. mSglich, den Mausklick auf eine Stelle im Dokument als ein Ereignis weiterzuleiten und nach vorgegebenen Regeln zu behandeln. ActiveX Controls k6nnen tiber die Verwendung durch eine Applikation hinaus auch in eine WWWSeite eingebunden werden. Im Gegensatz zu CORBA Produkten k6nnen mit OLE 2.0 Komponenten nicht tiber ein Netzwerk interagieren, sie mtissen lokal verRigbar sein. Zuktinftige Versionen von OLE sollen jedoch die Verteilung tiber ein Netzwerk untersttitzen (Network OLE). Eine ausfiahrliche Beschreibung der OLE Technologie geben [Brockschmidt 1994] und [Orfali et al. 1996]. Aufbauend auf COM hat Microsoft ein Architektur-Framework Rir die verteilte Objekttechnologie entwickelt, das Microsoft Windows DNA (Distributed iNternet Architecture). Dieses Framework soil die Anwendungsintegration untersttitzen sowie das eBusiness tibers Internet erleichtern und setzt sich aus einer Reihe von Microsoft-Produkten zusammen (Abb. 3.25).

3.2 Integrationin Wissenschafiund Praxis

71

Bei Microsoft DNA handelt es sich um eine 3-Ebenen Architektur, sie unterscheidet die Pr/~sentations-, die Applikations- sowie die Datenebene. Windows DNA erlaubt dem Entwickler Anwendungen zu entwickeln, die Informationen sowohl auf Windowsplattformen als auch auf Internet-Clients verteilen k/~nnen. Die Applikationsebene beinhaltet COM+ mr verteilte Dienste wie MTS (Microsoft Transaction Server), MSMQ ffir Messagedienste sowie IIS (Internet Information Server) mr Webdienste. Die dritte Ebene bietet einen universellen Datenzugriffbasierend auf OLE DB [vgl. Zahavi 2000, S. 61 ]. Die evolution~ire Weiterentwicklung bestehender, heterogener Informationssysteme wird auch von Microsoft zu wenig beachtet. Angaben, wie man alte Hostsysteme entsprechend in die verteilte Umgebung einbindet, wie dabei vorzugehen ist usw., fehlen auch hier.

3 . 2 . 4 . 5 0 A G und OAGIS

Das Bestreben, eine Standardisierung der Integration von betriebswirtschaftlichen Anwendungen zu f'6rdem, fiihrte 1995 zur Griindung der Open Applications Group (OAG). Diese Non-Profit-Organisation entwickelt Spezifikationen zur Beschreibung von oftener, d.h. standardisierter, Applikationsintegration [OAG 1998]. Grtindungsmitglieder dieser Organisation waren namhafte Softwareanbieter wie SAP, Peoplesoft, Oracle, Marcam, IBM Manufacturing Solutions und Siemens Nixdorf Informationssysteme. Die von der OAG definierten Spezifikationen heissen OAGIS (Open Applications Group Integration Specifications) und beschreiben die gemeinsame Nutzung von Daten und Methoden sowie den Datenaustausch zwischen zwei unterschiedlichen Business Applikationen [Connelly 1999, S. 500; OAG 1999a]. Der starke Drang nach einer Interoperabilit~it der Gesch~iftsprozesse und das gleichzeitig verborgene Potential in der Nutzung unterschiedlicher Module verschiedener Anbieter von betriebswirtschaftlicher Anwendungssoftware sind die Treiber der Standardisierungsbemtihungen (vgl. Abb. 3.26). Mit den OAGIS sind die Anwender in der Lage, entsprechend ihren Anforderungen die jeweils am besten geeigneten Module auszuw~ihlen und einzusetzen und dennoch nicht auf die Vorteile einer integrierten Gesamtl6sung verzichten zu mtissen. Die OAGIS setzt sich aus den fiJnf Teilen 9

abstrakte Referenzarchitektur fiir betriebliche Informationssysteme,

9

Beschreibung typischer Business Software Components,

9

Beschreibung von Scenario Diagrams,

9

Verzeichnis der Application Programming Interfaces sowie

9

zugeh6rigem Data Dictionary

zusammen [vgl. OAG 1999b].

72

3 Grundlagen

Die Integration erfolgt in diesem Modell nicht wie tiblich fiber die Daten, sondem fiber sogenannte BODs (Business Object Document). Ein BOD ist eine Architektur, welche fiJr die Integration betriebswirtschaftlicher Funktionen geschaffen wurde. Sie baut auf einer technischen Integration auf, die Kommunikationsdienste fi~r die Applikationen auf Systemebene bereitstellt. Alle zur Verfi~gung stehenden BODs sind fiber ein zentrales Repository ver~gbar. Die OAG verbindet mit ihrem Ansatz die Prozess- mit der IS-Ebene, d.h. sie 16st sich vonder reinen Systemintegration. Ein Business Object Document kann jeweils nur mit Einbezug des zugeh6rigen Gesch~iftsprozesses betrachtet werden. Die Verkntipfung der beiden Ebenen erfolgt mit Hilfe sogenannter Integrationsszenarien [OAG 1999a]. Ein solches Szenario zeigt dem Anwender sowie dem Anbieter einer betriebswirtschaftlichen Standardanwendtmgssoftware den Kontext mr einen OAGIS/BOD-Einsatz. Somit stellt der Ansatz einen erstrebenswerten Versuch dar, bei der Integration neben der Syntax der Daten auch deren Semantik in Form der Gesch~iftsfunktionen, die auf diesen Daten ausge~hrt werden, ausreichend zu beriicksichtigen. Nachfolgende Abbildung 3.27 zeigt ein derartiges Integrationsszenario im Kontext betriebswirtschaftlicher Anwendungssoftware. Da sich die OAG nicht mit der Integration eines konkreten Anwendungssystems befasst, sondem die Standardisierung der Integration von betriebswirtschaftlicher Standardanwendungssoftware in den Vordergrund stellt, besch~iftigt sie sich mit einem komplexen Themengebiet. Ftir die Handhabung dieses Problemkomplexes hat die OAG ein Vorgehensmodell mr die Integration erstellt, das die wesentlichen Fragestellungen wie Datenaustauschstandard, Datenmapping, Datensynchronisation, Sicherheit usw. behandelt.

3.2 Integrationin Wissenschaftund Praxis

73

Project Accounting Synchronization

Order Purchasing Accounts TiLabor me& Mgmt. Payable SyncProjin~ ISync Pr~176SyncPr~ Projinfo Acc~ wSyncPrOjinfO F - " Receivable/" J

/

y

ETrxaZ:~s& e

Project-Accounting SyncProjinfo

I

Budget I SyncProjinfo I

Capital ] Expense] Billable AssetMgmt II~"~176 Billing[

Abb. 3.27."

Integrationsszenario"Project Accounting Synchron&ation"

Die Standardisierungsbemghungen im Rahmen der OAG haben bereits zu einer Sammlung von insgesamt 35 Integrationsszenarien ge~hrt. Daneben ist der generelle Aufbau von Business Object Documents festgelegt (vgl. Abb. 3.28).

Ein BOD besteht aus einem Steuerungsabschnitt (Control Area) sowie einem Bereich fiir die eigentlichen Gesch/~ftsdaten (Business Data Area). Der Kontrollbereich weist neben den

74

3 Grundlagen

Adressen des Senders und der Empf~inger auch den zum BOD geh6renden Methodenaufruf im Empf~ingersystem (Business Service Request) aus. Dass sich die Arbeiten und Ergebnisse der OAG auch in der Praxis umsetzen lassen, zeigen z.B. die vonder Firma SAP im Softwarepakte R/3 mitgelieferten BAPIs. Diese Kapseln von Transaktionen im betriebswirtschaftlichen Prozesskontext entwickelte SAP aufbauend auf den Spezifikationen der OAG. Auch weitere Anbieter von betriebswirtschaftlicher Standardanwendungssoftware wie Marcom und CODA k6nnen erste Implementierungen der OAGIS aufweisen [Engelhardt/LieBmann 1998]. Darfiber hinaus beeinflussten die OAG-Spezifikationen die Entwicklung der Processware von CrossWorlds. Die Produkte von CrossWorlds erm6glichen einem Untemehmen die Integration von ERP-Systemen untereinander oder mit anderen Anwendungen. Hierzu bietet CrossWorlds mit Hilfe eines Integrationsservers vorgefertigte Connectors und Business Objects ftir die out-of-the-box Integration. Den eigentlichen Integrationsbedarf leitet CrossWorlds aus betriebswirtschaftlichen Szenarien ab [CrossWorlds 1998]. Leider bietet die OAG kein untemehmensweites Referenzmodell, das die Komponenten eines Informationssystems und deren Beziehungen zueinander vorschreibt. Ein solches Modell wiirde alle notwendigen Integrationsbeziehungen zwischen den Komponenten ausweisen und somit eine l]bersicht fiber den erforderlichen Integrationsgrad in einem Informationssystem zeigen. Somit lassen sich die OAG-Spezifikationen auch nur unter bestimmten Rahmenbedingungen einsetzen und 16sen nicht alle Probleme der Integration (s. Abschnitt 2.4). Die Integration beruht in diesem Ansatz allein auf Schnittstellen und bezieht ein gemeinsames Verwalten von Daten nicht ein. Die somit entstehende unkontrollierte Redundanz gef~ihrdet die Datenkonsistenz [vgl. Frank 2001 ].

3.2.4.6 SAP ALE

Auch Hersteller betriebswirtschaftlicher Anwendungssoftware befassen sich mit der Entwicklung von Diensten zur Verbesserung und/oder Vereinfachung der Integration in heterogenen Informationssystemen. Der Softwarehersteller SAP ist mit seinen Produkten SAP R/2 und SAP R/3 marktftihrender Anbieter betriebswirtschaftlicher Standardanwendungssoftware. SAP stand ebenso wie zahlreiche grosse, global agierende Untemehmen vor dem Problem, dass sich ihre monolithische und zentralistische L6sung als zu wenig flexibel fiir die rasch durchzuftihrenden Anderungen bedingt durch neue Prozessanforderungen erwies. Immer mehr Anwender von SAP R/3 gingen dazu fiber, die Soiiware mehrfach an unterschiedlichen Stellen zu installieren. Mit dieser Installation von verteilten R/3-Systemen entstand das Problem der Koordination und Integration. SAP musste die Verbindung der R/3 Welt mit den R/2-Welten sowie einen Verbund dezentral installierter R/3-Modulen erm6glichen [Wendel/Briiggemann 1998]. Vor diesem Hintergmnd entstand SAP ALE als Bestandteil des integrierten Anwendungspakets SAP R/3. ALE soll die Umsetzung von Gesch~iftsprozessen auf verteilte, lose integrierte

3.2 Integrationin Wissenschaflund Praxis

75

Anwendungen unterstt~tzen und dabei die Integrit~it des Gesamtsystems hinreichend wahren sowie den Benutzer v o n d e r Komplexit~it abschirmen. ALE soll helfen, verschiedene R/3Applikationen mit den zugeh6rigen Daten auf unterschiedliche Unternehmenseinheiten zu verteilen und ebenso das host-orientierte R/2 System sowie Drittanwendungen in einem Verbund lose integrierter Anwendungen einzubinden. Zu dieser Aufgabenerfallung liefert ALE ein Rahmenkonzept far eine Integration mittels Nachrichtenaustausch. Die ALE Architektur besteht aus drei Ebenen: Applikation, Steuerung und Kommunikation [vgl. Linthicum 2000, S. 250]. W~ihrend die Anwendungsschicht Syntax und Semantik der auszutauschenden Nachrichten und das Verhalten der Applikation festlegt, steuert die ALESchicht den Nachrichtenaustausch zwischen Systemen und die Kommunikationsschicht fahrt letztendlich die eigentliche Nachrichtentibertragung t~ber das Netzwerk durch (vgl. Abb. 3.29). Die auszutauschende Nachricht wird auf der Anwendungsschicht gem~iss einer an die EDIFACT Standard angelehnte Datenstruktur in ein sogenanntes Master-IDOC verpackt. SAP hat far eine Reihe von unterschiedlichen Szenarien die erforderlichen Nachrichtentypen definiert und zugleich festgelegt, zu welchen Ereignissen und Zeitpunkten IDOCs zu erzeugen sind. Die anschliessende ALE-Schicht generiert aus dem Master-IDOC mindestens ein Communication-IDOC, ermittelt die Empf~inger, filtert empf'~ingerabh~ingige Datensegmente aus dem IDOC heraus, fahrt notwendige Konversionen durch und versendet die entstandenen Communication-IDOCs. Die Kommunikationsschicht t~bertr~igt diese dann mittels asynchronem Nachrichtenaustausch oder Remote Function Call (RFC).

76

3 Grundlagen

SAP ALE in Verbindung mit den von SAP angebotenen Referenzmodellen und den R/3 Applikationen bildet eine verteilte Umgebung. ALE hilft bei der Integration von SAP- Applikationen, setzt aber auch hier einen hinreichenden Konsens tiber deren Konfigurationen voraus. SAP bietet hierzu sog. ALE-Szenarien an, welche vordefinierte Verteilungsszenarien darstellen. In Informationssystemen mit starker SAP-Dominanz kann dieses Konzept zu einer gewissen Standardisierung der Nachrichtentypen und damit der Integration helfen. Sind jedoch neben SAP weitere, heterogene Anwendungen mr die Prozessabwicklungen notwendig, kann das Konzept keinen entscheidenden Beitrag zur Integration liefern.

3.2.4.7 XML Die Beschreibungssprache XML (Extensible Markup Language) wurde vonder W3C XMLArbeitsgruppe 1997 verabschiedet. Sie ist eine Untermenge der SGML (Standard Generalized Markup Language), basiert auf ISO 8879 und ist herstellerunabhangig, benutzerdefinierbar und erweiterbar [vgl. Lobin 2000; W3C 1997]. XML bietet ein allgemeines Datenaustauschformat an, das Daten sowie Metadaten verbindet, wodurch Applikationen und Datensammlungen Informationen austauschen k6nnen, ohne von der Funktionalit~it des Partners etwas zu wissen [vgl. Hughes 2001 ]. Zu dem XML Standard geh/Sren die beiden Sprachelemente DTD (Document Type Definition) und XSL (Extensible Stylesheet Language) [vgl. Linthicum 2000, S. 279ff]. 9 Die Dokument Type Definition bestimmt die Struktur und die Elemente eines XMLDokuments. Damit k6nnen komplexe Datenstrukturen wie beispielsweise EDI-Dokumentenformate abgebildet werden. Die DTDs k/Snnen entweder komplett im Header eines XML-Dokuments enthalten sein oder tiber einen Hyperlink referenziert werden. 9 Mit der Extensible Stylesheet Language werden sogenannte Style Sheets definiert, die Regeln oder Methoden einem XML zufiagen kSnnen. Reine XML-Dokumente kSnnen keine Formatierungsanweisungen ihrer enthaltenen Daten definieren, wodurch h6her strukturierte Daten und Konvertierungsregeln nicht abgebildet werden kSnnen, weshalb XSL notwendig wurde. XSL kann ein XML-Dokument reformatieren und dabei sowohl das Schema als auch den Inhalt verandem. Mit XML k/Snnen Untemehmen leichter kooperieren, indem sie Informationen gegenseitig nutzen und austauschen. Im Gegensatz zu EDI ist XML weniger komplex und kostenintensiv [vgl. Finkelstein 1999; Linthicum 2001a]. Aus diesem Grund haben sich unterschiedliche Vereine gegrtindet, welche sich mit der XML-basierten Spezifikation ihrer dem jeweiligen Anwendungsgebiet entsprechenden Gesch~iftsdaten befassen [vgl. Glushko et al. 1999]. Beispiele solcher Vereine und Spezifikationen sind 9

das Open Trading Protokoll, das sich mit dem Informationsaustausch im Zusammenhang mit Zahlungen befasst (www.otp.org),

3.2 Integrationin Wissenschaftund Praxis

77

9

RosettaNet, ein Verein, der sich der Entwicklung von eBusiness Standards wie z.B. einer gemeinsamen Sprache und offenen eBusiness Gesch~iftsprozessen widmet (www.rosettanet.org),

9

XML/EDI, eine Gruppe, die bestehende EDI-Formate in XML Dokumente umsetzt (www.xmledi.com),

9

Open Buying on the Internet (OBI), eine Initiative zur F6rderung des elektronischen Gesch~iftsverkehrs (www.openbuy.org),

9

Open Financial Exchange (OFX), ein Protokoll zum elektronischen Austausch von Finanzdaten zwischen Kunden und ihren Finanzinstituten (WWW.Ofx.net).

Mit XML l~isst sich der Datenaustausch vereinfachen, indem beide Parteien zur Beschreibung der Formate und Inhalte die gemeinsame Sprache verwenden. XML findet somit im Bereich der Systemintegration ihren Einsatz. Sie hilft bei der Realisierung der Datenintegration. Uber Vorgehensweisen in konkreten Integrationsprojekten gibt der Standard keine Auskunft. Ausserdem bedarf es einiger Anstrengungen, um Altsysteme in einem bestehenden Informationssystem XML-f~ihig zu machen.

3.2.5 Zusammenfassung Ftihren die Arbeiten der diversen Gremien zum gewiinschten Erfolg, so w~ire ein Zusammenarbeiten und Integrieren heterogener Applikationen in der Zukunft leichter und flexibel umsetzbar. Jedoch gibt es bis heute nur sehr wenige Produkte und Anbieter von Softwarepaketen, die sich an diese Standards anlehnen. Ausserdem finden Altsysteme nur in wenigen F~illen bzw. unter signifikanten Einschr~inkungen Berticksichtigung. Es werden noch Jahre vergehen, bis sich die Arbeiten weltweit durchgesetzt haben. Ein weiteres Problem besteht in der fehlenden oder ungentigenden Behandlung der Semantik. Es reicht nicht aus, Schnittstellen, Datenmodelle sowie Datenformate zu standardisieren. Fiir die ad~iquate Verwendung der Daten, d.h. der Interpretation ihrer Inhalte, muss bei beiden Integrationspartnem ein gemeinsames Verst~indnis zu Grunde liegen. Ein Business Engineer ben/Stigt jedoch bereits heute ein Rahmenwerk mr die Integration. Dabei sind sowohl m6gliche Integrationsformen als auch insbesondere das koordinierte Vorgehen bei der Integration von Bedeutung. Die vorliegende Arbeit zeigt im Weiteren ein solches Rahmenwerk auf.

4 Integrationsmodell Das Integrationsmodell soil die wesentlichen Fragen der Anwendungsintegration identifizieren helfen. Es zeigt die Integrationsobjekte und -komponenten, die unterschiedlichen Integrationsvarianten sowie die Abh~ingigkeiten zwischen diesen auf. Der Abschnitt 4.3 beschreibt die Prozessumsetzung als Anwendung des vorgestellten Integrationsmodells und geht dabei sowohl auf die mOglichen Architekturvarianten als auch auf das Vorgehen im Rahmen von Projekten ein. Ftir die zentralen Integrationstypen dieser Arbeit, die Prozess- und Systemintegration, beschreibt dieses Kapitel auch tiberblicksweise das in Projekten anzustrebende methodische Vorgehen, das jeweils in einem separaten Kapitel (Kapitel 5 und 6) vertieft wird. Weiterhin behandelt das Modell die wesentlichen Einflussfaktoren der Anwendungsintegration wie beispielsweise die Bedeutung von Standards.

4.1 Integration im Business Engineering Modell Die Ausfahrungen der Kapitel zwei und drei zeigen den Nutzen und die Bedeutung der Anwendungsintegration im Umfeld des Business Engineering, weisen auf die m6glichen Probleme hin und erklgren in diesem Zusammenhang auch die Notwendigkeit far eine Einordnung der Integration im Business Engineering Modell. Strategie und die Prozesse eines Unternehmens definieren die Anforderungen an die Untersttitzung durch das Informationssystem und an die technologische Integration. Andererseits erm6glicht der Fortschritt der Technologie immer wieder neue Potentiale far die Anwendungsintegration und erlaubt dadurch verbesserte oder neue Ablgufe im Rahmen der Prozessabwicklung. Implizit nimmt die Integrationsfghigkeit eines Informationssystems und seiner Bestandteile somit Einfluss auf die Geschgftsstrategie. Der Business Engineer muss die unterschiedlichen Konzepte der Anwendungsintegration auf Informationssystemebene kennen, um adgquate Entscheidungen bei der Gestaltung der Prozesse und Strategien treffen zu k6nnen. Die vorliegende Arbeit zeigt diese Konzepte auf und berficksichtigt dabei insbesondere auch den Obergang zur und von der Prozessebene. Im Konkreten bedeutet dies, dass sie die Prozessumsetzung mit Hilfe von Enterprise Application Integration beschreibt. Vor diesem Hintergrund werden die drei Integrationstypen Prozessintegration, Desktopintegration und Systemintegration unterschieden. Eine Unterstfitzung eines Geschgftsprozesses durch die Informationstechnologie nimmt den beteiligten Personen alle automatisierbaren T~itigkeiten ab, stellt ihnen zum richtigen Zeitpunkt die erforderlichen Informationen in aufbereiteter Form am Arbeitsplatz zur Verfagung

80

4 Integrationsmodell

und bietet die zur Aufgabenerffillung notwendigen Funktionalitiiten ffir die Informationsbearbeitung an. In diesem Aufgabenumfeld muss die Prozessintegration Massnahmen zur Steuerung der T~itigkeiten und Prozesse definieren. Sie bestimmt die Art der Steuerung zur durchgiingigen Aufgabenabwicklung. Bezugspunkt der Prozessintegration sind Aufgaben, welche ein zugewiesener Aufgabentriiger ausffihrt. Die Steuerung der Abwicklung der einzelnen Aufgaben behandelt nicht mehr die Prozessintegration, sondem die Desktopintegration. Die Prozessintegration setzt somit auf der Desktopintegration auf, die in gewisser Weise eine Betrachtung auf gr6sserer Detaillierungsebene darstellt. Nicht der gesamte Prozess, sondern eine einzelne Aufgabe ist Bezugspunkt der Desktopintegration. Aus Sicht des Aufgabentriigers bildet die Desktopintegration sinnvolle Arbeitspakete, sogenannte Aktivitiiten, und legt innerhalb dieser die gewiinschte Abarbeitungsfolge fest. Ausserdem definiert sie konkrete Anforderungen an die Systemintegration. Prozess- und Desktopintegration bilden somit die Schnittstelle zwischen Prozess- und Informationssystemebene. Die Systemintegration befasst sich mit der Verbindung von Anwendungen und der Sicherstellung eines konsistenten Datenhaushaltes. Sie erfolgt auf Basis der Anforderungen aus der Prozess- und Desktopintegration, kann jedoch auch durch technologische Weiterentwicklungen und deren Folgen ffir das Informationssystem ausgel~ist werden. Die Abbildung 4.1 stellt die drei Integrationstypen, ihre Einordnung und ihre Beziehungen untereinander im l]berblick dar.

4.2 Metamodellder Integration

81

4.2 Metamodell der Integration Wie die bisherigen Ausfohrungen in den Abschnitten 3.1 und 3.2 deutlich belegen, ist der Begriff Integration mit den unterschiedlichsten Bedeutungen verbunden. Mit Hilfe eines Metamodells werden nun die Gestaltungsbereiche der Anwendungsintegration, die zu integrierenden Objekte sowie eine detaillierte Abgrenzung des Betrachtungsrahmens beschrieben. Im Rahmen des Kompetenzzentrums "Prozess- und Systemintegration (CC PSI)" (vgl. Abschnitt 1.4) entwickelten 9

[Gassner 1996] ein Metamodell for die Beschreibung des Ist-Informationssystems,

9

[Derungs 1997b] ein Metamodell for Workflow und

9

[Riehm 1997] ein Metamodell for Schnittstellen.

Das folgende Metamodell konsolidiert diese Teilergebnisse zu einem Gesamtmodell der Integration. Die Darstellung des Metamodells basiert auf vereinfachten ER-Diagrammen (Entity-Relationship-Diagramm) [s. Chen 1976]. Die gew~ihlte Notation unterscheidet Komponenten (Knoten; synonym: Metaentit~itstypen, Metamodell-Objekte) und Beziehungen (Kanten) [s. Gutzwiller 1994, S. 24ff; 0sterle 1995, S. 187ff]. Die Komponenten beschreiben die Gestaltungsbereiche und Integrationsobjekte der Prozess-, Desktop- und Systemintegration, w~ihrend die Beziehungen die logischen Verkntipfungen der Komponenten beschreiben. Der Aggregationsgrad der Komponenten richtet sich nach dem jeweiligen Aggregationsgrad der Betrachtung. Die Beziehung zwischen zwei Komponenten wird im Datenmodell exakt mit Kardinalit~iten an den beiden Enden jeder Kante dargestellt. Dabei steht die Kardinalit~it "1" for genau eine, "c" for keine oder eine, "cn" for keine, eine oder mehrere und "n" for eine oder mehrere. Der Pfeil der Kante im Datenmodell gibt die Leserichtung der Beziehung an. Im Beispiel der Abbildung 4.2 bedeutet die 1:n-Beziehung: eine Aktivit~it btindelt einen oder mehrere Tasks, ein Task wird in genau einer Aktivit~it verwendet.

Aktivit~it I 1

n'--I Aktivit~it bOndelt '7 Task

Task

Abb. 4.2. Beispiel fiir die Notation des Datenmodells

Die folgenden Darstellungen verzichten auf eine detaillierte Normalisierung. Multiple Beziehungen (n:n-Beziehungen) werden nur aufgel6st, wenn dadurch das Metamodell wesentliche Merkmale der Integration hervorheben kann. Der Bogen in Abbildung 4.3 stellt ein exklusives ODER zwischen Metaentit~itstypen dar [vgl. Lindtner 1992, S. 22; Robinson/Berrisford 1994, S. 198].

82

4 Integrationsmodell

Task

I

Task 1"~'/'~~ ist%// manuel" ~

Task ~ ~SctUtzt ist IT,-

I manEe"er Task I

I 'm-unterst0tzter Task 1

Abb. 4.3: Exklusive Beziehung

Ein Metamodell kann in problemorientierte Sichten aufgeteilt werden, um die Obersichtlichkeit zu verbessern. Jede Sicht stellt dann einen Ausschnitt von thematisch zusammengeh6renden Metaentit~itstypen aus dem Gesamtmodell dar. Somit k#nnen einzelne Metaentit~itstypen in mehreren Sichten vorkommen.

Das Metamodell enth~ilt neben der grafischen Darstellung eine Definition der Metaentit~itstypen. Im Anhang A ist zudem eine detaillierte Beschreibung der Metaentit~tstypen enthalten, die unter anderem auch die Attribute jeder einzelnen Komponente enth~ilt, d.h. die Eigenschaften der Metaentit~itstypen.

beste~)taus Daten! struktur "

Daten-J-'----besitzt~

Middleware ~--unterst0tzt--~ transfer

T

ist Plattform

se!detl eml~~besitzt

ist

Standort ~--umfal~t--~ Sy em ~-istPlattforn~ Anwendung I

1'

realisiert

Schnittstelle bietet an

istreaisiertauf I (istTeilvon

~

l

Datensammlung besitzt ~ ~k istOwnerwenae( ver.. besitzt

~esi,tL_~__ I I

__ Applikation raftauf i i?tV~.~

Prozess ~--istrealisiert~ Workflow F)bestehtaus-~ Aktivit~it ~bestehtau~ istverant"~" ~ worlich istverantwortlichj geh.Ortzu._lOtsaus

Oroanisa-I

'

tionseinheit

I

Zustand

~ ~ Inputvon Outputvon

,euerOa,en der Aktivit~it

'l

Abb. 4.4." Metamodell der Integration

Task

~ "~ Inputvon Outputvon zw. Tasks'l J'Daton.uss I

als

4.2 Metamodellder Integration

83

Die Abbildung 4.4 zeigt im l]berblick das Metamodell der Integration, w~ihrend die weiteren Abschnitte jeweils im Detail auf einzelne problemorientierte Sichten des Metamodells eingehen und dort auch teilweise den Aggregationsgrad verfeinern.

4.2.1 Die vier Sichten des Integrationsmodells

Grundlage ffir die Ableitung der zentralen Sichten der Integration ist die Problemabgrenzung des Abschnitts 2.4. Neben den beiden bereits aus der Themenstellung der Arbeit ersichtlichen zentralen Sichten der Integration - der Prozessintegration und der Systemintegration - spielt im Rahmen der Prozessumsetzung auch die Sicht der Desktopintegration eine zentrale Rolle. Die Sicht des Informationssystems bildet die Grundlage ffir die drei anderen Sichten (vgl. Abb. 4.5).

Prozessintegration konzipiert und realisiert die Ablaufsteuerung eines Prozesses.

9

Die

9

Die Desktopintegration bringt die zur Erfiillung von Aufgaben notwendigen (heterogenen) betrieblichen Anwendungen an einem Arbeitsplatz zusammen. Sie stellt die Sichtweise des Benutzers und nicht so sehr die des gesamten Prozesses in den Vordergrund.

9

Die Systemintegration konzipiert und realisiert Integrationsbeziehungen zwischen jeweils zwei Anwendungen. Diese Sicht ist vor allem bei der Einffihrung neuer sowie bei der Weiterentwicklung alter Anwendung relevant.

9

Das Informationssystem mit seinen Anwendungen bietet in einem Unternehmen s~imtliche betriebliche Funktionen und Daten in Form von Applikationen und Datensammlungen an. Diese mtissen mr die Untersttitzung von Prozessen mittels Prozess- und Systemintegration ad~iquat miteinander verbunden werden.

Die folgenden Abschnitte beschreiben die vier genannten problemorientierten Sichten der Integration und detaillieren damit das Gesamtmodell der Integration.

84

4 Integrationsmodell

4.2.1.1 Sicht Prozessintegration Die Prozessintegration befasst sich mit der Steuerung von Prozessen sowie der Steuerung des Ablaufs zwischen Prozessen. In diesem Rahmen implementiert eine Steuerungskomponente einen Prozess in einem oder mehreren Workflows (Synonym: Aktivit~itenketten), die (hierarchisch) strukturierbar sind. Workflows setzen sich aus einer Reihe von Aktivit~ten zusammen, deren Ablaufsteuerung vonder Steuerungskomponente iibemommen wird. Die gebildeten Aktivit~iten stellen Bausteine dar, die sich in mehreren Workflows verwenden lassen [s. Doblaski 1995]. Fiar die Spezifikation der Ablauffolge hat sich auf konzeptioneller Ebene eine zustandsorientierte Betrachtung als sinnvoll erwiesen [vgl. Versteegen 1996]. Ein Workflow kennt bestimmte Zust~inde, wobei sich in jedem dieser Zust~inde nur eine Menge erlaubter Aktivit~iten aus~hren l~isst. Jede durchge~hrte Aktivit~it 18st einen Zustandsiabergang aus. Die Aus~hrung von Aktivitaten h~ingtjedoch nicht nur von dem Zustand des Workflows ab, sondem auch von vorab definierten Aus~hrungsbedingungen. Die Variablen dieser Bedingungen zusammen mit den zul~issigen Werten basieren auf den Steuerdaten von Aktivit~ten, die sowohl den In- als auch Output von Aktivit~iten bestimmen. Die Steuerdaten der Aktivitaten bilden die Grundlage ~ r die Ablaufsteuerung durch eine Steuerungskomponente. Um die Verantwortungen ~ r die Ausftihnang von Aktivit~iten organisatorisch zu verankem, sind aufbauorganisatorische Komponenten notwendig. Die Aufbauorganisation eines Unternehmens ist in einem Organigramm abgebildet, das aus mehreren Organisationseinheiten besteht. Diese befinden sich an Standorten und umfassen Stellen. Stellen sind ~ r die Aus~hrung von Aktivit~iten in bestimmten Workflows verantwortlich und haben Regeln in Bezug auf ihre Stellvertretung definiert. Fiir jeden Workflow muss ausserdem jeweils eine Stelle als Prozessadministrator definiert sein. Der Prozessadministrator ist fiir die gesamte Steuerung des Workflows verantwortlich. Jeder Workflow ist auf einem oder mehreren Systemen realisiert, wobei sich jedes System an einem definierten Standort befindet. Die Abb. 4.6 zeigt die Sicht Prozessintegration in Form eines Metamodells.

4.2 Metamodellder Integration

85 cr~r-koordiniert

OE an i i s t Standort umfagt

ae~teil

Organisa-~)

i st

t-'~ tionseinheitI on

/

umfaBt

n~

Stelle

ist verteiltauf

1I

n

Cl~,

Stelle zu l~besitz t ,._ Ausf(~hrungsStandort OE c~ berechtigung abernimmt~ t cn l Stellver_c_6, 1I tretung ist verantbefindet wortlichfor ben.Otigt sich an | =stObergeuoergeist [1 cr~ c ordnetcn ,endet_.ffn Aktivit~tim LwirdverwenJ I~ Ll-?--istreali--~-nl Workflow ~lverwend Workflow ]'n det in 1[ System I. siertauf I

t

Aktivit~it

c~ gehOrtzu

implemen-~ kennt 11 Prozess

tiert als

Ion

4 Zustand ist Ursprungszustand

16staus

i on

empf~ingtsendet ver-

lAus,0hrun0 S , e-u e r O a t e n bedingung verwende d. Aktivit~t ~cn

ist Zielzustand

04

Zustands- I Obergang n

bestimmt Aufbau

I1 Datenstruktur

A b b .4 . 6 . "S i c h t1 . "P r o z e s s i n t e g r a t i o n

4 . 2 . 1 . 2S i c h tD e s k t o p i n t e g r a t i o n Eine Aktivitiit setzt sich aus mehreren Tasks zusammen, die jeweils eine Anwendung aufrufen k6nnen. Die Desktopintegration hat die Aufgabe, dem Benutzer alle die zur Ausfiihrung der Aktivit~it notwendigen Anwendungen am Arbeitsplatz zur Verfiigung zu stellen. In diesem Zusammenhang muss sie die entsprechenden Anwendungen aufrufen und fiir einen m6glichst automatisierten Datenaustausch zwischen ihnen sorgen [s. Bonaccorsi 1994; Hackathom 1993, S. 52ff; Rivizzigno 1994]. Tasks beschreiben jeweils im Detail eine Aktion als Teil yon einer Aktivitiit, somit auch den Aufruf yon Anwendungen. Sind Benutzerinteraktionen flit die Ausffihrung eines Tasks notwendig, so werden diese mit Hilfe yon Bildschirmmasken, Listen, Reports usw. in Form yon Dialogelementen realisiert, deren Aufbau eine Datenstruktur definiert. Die Reihenfolge yon Dialogelementen in einer Aktivitiit bestimmt ein Dialogfluss. Jeder Task kann manuell oder IT-untersttitzt sein. Im letzteren Fall greift er auf eine Anwendung zu, wofiir spezifische Integrationsansiitze notwendig sind. FOr den Datenaustausch zwi-

86

4 Integrationsmodell

schen den beteiligten Anwendungen einer Aktivit~it sind ebenfalls Integrationsans~itze notwendig. Der Datenfluss zwischen den Tasks definiert diesen Datenaustausch, sein Aufbau wird durch eine Datenstruktur definiert. Im Sinne der Desktopintegration handelt es sich bei einer Aktivit~it um ein ausftihrbares Programm, das je Task eine Anwendung einbindet und den Datenfluss zwischen den Tasks regelt. Die Steuerungskomponente (s. Sicht Prozessintegration) ruft jeweils ein Programm dieser Art ftir die Aktivit/iten auf (Abb. 4.7).

Die Abb. 4.8 zeigt das Metamodell fiir die Sicht Desktopintegration. ist Vorg~ingervon

cnl-'~ I

cn

Dialog-

element

/on 11 Daten- I I~bestimmtAufbau'-1 struktur

r

ist realisiert mit ist Vorg~nger von J / Icnl n

Aktivit~it

crl_=j , ,, 1 bOndeltn~i Task

bestimmt Aufbau | ~n

I cn empfangt Cl~'1 Datenfluss I I~-cnversendet c'J zw. Tasks

I~

ruff auf

I Anwendung Abb. 4.8: Sicht 2." Desktopintegration

4.2 Metamodellder Integration

87

4.2.1.3 Sicht Systemintegration Eine Integrationsbeziehung setzt sich aus der Summe der Datentransfers zwischen jeweils zwei Anwendungen zusammen (vgl. Abb. 4.9). Diese Sichtweise erweitert die bisherige prozessorientierte Betrachtungsweise. Bei der Einfiihrung von Softwarepaketen beispielsweise ist eine Obersicht tiber alle zu schaffenden Integrationsbeziehungen des Softwarepaketes zu bereits existierenden Anwendungen fiir die Absch~itzung des Projektaufwandes erforderlich. Auch bei der Abl6sung yon Altanwendungen bestimmt eine Analyse der einzelnen Datentransfers den Projektumfang. Die Systemintegration befasst sich mit der Ausgestaltung von Integrationsbeziehungen, d.h. mit der Konzeption und Realisierung von Schnittstellen und Datentransfers zwischen jeweils zwei Anwendungen. Sie w~ihlt fiir jeden umzusetzenden Datentransfer einer Integrationsbeziehung eine der m6glichen Integrationsvarianten (Abschnitt 4.5.1) und daran anschliessend die entsprechende Middleware zur Untersttitzung des Datentransfers aus.

Anwendungen tauschen zur Erffillung der Daten- und Funktionsanforderungen tiber Schnittstellen Daten aus. Datentransfers zwischen Schnittstellen finden dartiber hinaus auch zum Abgleich von redundanten Daten im Sinne einer konsistenten Datenhaltung statt. Ein Datentransfer besitzt einen formalen Aufbau, der durch Datenstrukturen definiert ist, welche sich wiederum selbst aus Datenstrukturen zusammensetzen k6nnen. Die kleinste Einheit von Datenstrukturen, die sich in einem gegebenen Zusammenhang nicht mehr sinnvoll unterteilen lgsst, bilden Datenelemente. Die Schnittstellen einer Anwendung lassen sich gem~ss ihrer Zugeh6rigkeit in Applikationsund Datensammlungsschnittstellen unterscheiden. Applikationsschnittstellen bieten eine deft-

88

4 Integrationsmodell

nierte Menge von Methoden oder Funktionen der Applikation an, auf die von ausserhalb der Applikation zugegriffen werden kann. Datensammlungsschnittstellen dagegen identifizieren diejenigen Daten der Datensammlung, welche anderen Applikationen und Datensammlungen zur Verftigung stehen oder welche sie von aussen beziehen. Diese Daten sowie die Datensammlung selbst besitzen jeweils einen formalen Aufbau, beschrieben durch Datenstrukturen. Middleware kann den Datentransfer zwischen Anwendungen unterstiitzen, sei es durch das Bereitstellen von reinen Transportdiensten oder durch Konvertierungsfunktionen usw. Die Auswahl eines geeigneten Middlewareprodukts, das ftir m6glichst viele unterschiedliche Datentransfers Verwendung finden kann, ist eine zentrale Aufgabe im Rahmen der Systemintegration. Applikationen, Datensammlungen und Middleware sind auf Systemen (Plattform, Rechner) installiert und k6nnen auf verschiedene Standorte verteilt sein. Die Abb. 4.10 zeigt das Metamodell ftir die Systemintegration.

cn._~Middleware ( 1

benOtigt

ni

hat

transferDaten-tcn

cnT

T cn

sendet

empf~tngt ,besitzt

I~iuftauf n~-----bietetan

I Methode/

Funktion I

c ApplikationsSchnittstelle I

I DS-$chnitt-stelle ]

~T

Ten

besitzt

besitzt

I1 Datennutz', ,~, sammlung cn n~_,st realisiertauf cnl n tbesteht aus~] Fbesteht aus_lkcn nLbesteht auo

11 ~n istOwnervo_r~ 1 I Applikation

~ System I cnI '~ n

!cn

Anwendung

istrealisiedauf

beflndetsichan

Standort I Abb. 4.10:

Sicht 3: Systemintegration

nln I iTine Cn hat I c

I element Daten- I

4.2 Metamodellder Integration

89

4.2.1.4 Sicht Informationssystem Prozesse stellen die Anforderungen (Funktions- als auch Datenanforderungen) an die Untersttitzung durch das Informationssystem. Jede Prozessumsetzung erfordert deshalb einen Abgleich dieser Anforderungen mit den bereits vorhandenen Anwendungen des Informationssystems eines Untemehmens. Anwendungen stellen Funktionalit~it sowie Daten tiber Schnittstellen zur Verftigung und bestehen aus Applikationen und Datensammlungen. Datensammlungen besitzen einen formalen Aufbau, definiert durch Datenstrukturen. Diese k6nnen sich wiederum selbst aus Datenstrukturen zusammensetzen. Die kleinste Einheit von Datenstrukturen, die sich in einem gegebenen Zusammenhang nicht mehr logisch sinnvoll unterteilen lassen, sind Datenelemente. Ober Schnittstellen, sog. Datensammlungsschnittstellen, stellen die Datensammlungen Daten zur Ver~gungen oder beziehen Daten von anderen Anwendungen. Applikationen sind fiir Datensammlungen verantwortlich und bieten betriebliche Funktionalit~it in Form von definierten Methoden tiber Schnittstellen (sog. Applikationsschnittstellen) an. Es lassen sich unterschiedliche Typen von Applikationen unterscheiden [vgl. Steinbock 1994] wie z.B. Btirosoftware, logische Transaktionen oder Serviceprogramme, deren Aus~hrung zu Effekten auf die zugeh6rigen Daten der Datensammlung ~hren. Da die Differenzierung von Applikationen im Rahmen dieser Arbeit nicht von Bedeutung ist, wird sie nicht n~iher betrachtet. Sowohl Applikationen als auch Datensammlungen sind auf Systemen (Plattform und Rechner) realisiert. Zwischen den Anwendungen bestehen Integrationsbeziehungen, d.h. sie tauschen tiber Schnittstellen Daten aus. Dieser Aspekt ist in der Sicht Systemintegration detailliert behandelt (s. Abschnitt. 4.2.1.3). Die Abb. 4.11 zeigt den Metamodellausschnitt mr die Sicht Informationssystem.

90

4 Integrationsmodell /

Prozess

stellt

stellt

n

Daten- ] anforderung n 1k ist realisiert erfOllt r

~

System

on] ,on au'

n"

ist einel

aU'cn I io n

istOwner VOnnutzt

cn T_ilsteht aua hat I / bestehtaus n~ cnI 1"-'= Daten- LI,)cn

struturn

]

S: n.steli

i

_~

/

bestehta~_T n

1 I ~'istve~nntw~ 1 bietetan Organisa/ tionseinheit cn,~

.

sendet

II |hat

In Applikati~

1 Anwendung/1

It

Abb. 4.11."

ist realisiert -left(Jilt

"n

I I''~Daten'nsammlung 1"1n2 Daten- I element c

-'

bewirkt

/

n

]

cn

empf~tngt

Jrcn cn~ Daten-

c~ tra~:lle~

,

Sicht 4: Informationssystem

4.2.2 Beschreibung der Metaentit~itstypen

Die folgende Tabelle enth~ilt die Beschreibungen der einzelnen Komponenten, d.h. der Metaentit~itstypen, zusammen mit dem Verweis auf den entsprechenden Abschnitt im Anhang mit der ausRihrlichen Beschreibung. Die Entitatstypen sind alphabetisch sortiert.

4.2 Metamodell der Integration

91

92

4 Integrationsmodell

4.2 Metamodell der Integration

93

94

4 Integrationsmodell

8 Die Verbindung Datenfluss zwischen Tasks mit Steuerdaten der Aktivit~it erfolgt an den Grenzen der Aktivit~it, d.h. bei den ersten bzw. letzten Tasks innerhalb einer Aktivit~it. Im Metamodell ist diese Verbindung tiber die Datenstruktur sichergestellt, die den Aufbau sowohl des Datenflusses zwischen Tasks als auch der Steuerdaten der Aktivit~it bestimmt (s. Abschnitt 5.4.2.2).

4.2 Metamodell der Integration

95

96

4 Integrationsmodell

4.2 Metamodell der Integration

97

98

4 Integrationsmodell

4.2 Metamodell der Integration

99

9 Die Begriffe Ablauf und Aktivitfitenkette sind Synonyme, weitere Autoren sprechen auch vom Kontrollfluss [s. beispielsweise Jablonski 1995b, S .34; Reinwald 1993, S. 27ff].

100

4 Integrationsmodell

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells

101

Der folgende Abschnitt 4.3 beschreibt, wie das vorgestellte Integrationsmodell im Rahmen der Prozessumsetzung Anwendung finden kann. Im Anschluss daran gehen die Abschnitte 4.4 und 4.5 n~iher auf die zentralen Integrationstypen der Informationssystemebene - die Prozessund die Systemintegration ein, die Desktopintegration als Detailsicht der Prozessintegration wird ebenfalls im Abschnitt 4.4 behandelt. Gegenstand der Untersuchung sind die unterschiedlichen Varianten des jeweiligen Integrationstyps und deren Unterscheidungsmerkmale. W~ihrend in diesen Abschnitten jeweils nur tiberblicksweise auf die Vorgehensweisen bei der Integration eingegangen wird, vertiefen die anschliessenden Kapitel 5 (Prozessintegration) und 6 (Systemintegration) diese Betrachtungen. Der Abschnitt 4.6 des vorliegenden Kapitels zeigt das Zusammenspiel der vorgestellten Integrationstypen.

4.3 Prozessumsetzung als Anwendung des Integrationsmodells Die Prozessumsetzung ist Teil der Prozessentwicklung, welche den Prozessentwurf in Projekten sowie die kontinuierliche, fi~hrungsgr6ssenbasierte Prozess~hrung beinhaltet (s. Abschnitt 3.1.2.2). Sie befasst sich mit der Implementierung von Prozessen in ein Informationssystem. Dazu setzt sie die Anforderungen des Prozesses (entstanden aus einem BPR-Projekt) an die Computerunterstt~tzung in Anwendungen um (Abb. 4.12). Dieses Kapitel besch~iftigt sich mit der Schnittstelle zwischen der Prozess- und der Informationssystemebene des Business Engineering und der Verbindung der Prozess- und Systemintegration. Es beschreibt die Problembereiche der Prozessumsetzung (Abschnitt 4.3.1), zeigt auf, welche Rahmenbedingungen zu beachten sind (Abschnitt 4.3.2), welche Architekturvarianten fiir eine Prozessumsetzung prinzipiell zur Ver~gung stehen und welche Kriterien ffir die jeweilige Variante sprechen (Abschnitt 4.3.3). Die technologischen Entwicklungen lassen noch weitere Spielarten bei der Implementierung der Architekturvarianten zu (Abschnitt 4.3.4). Das im Rahmen der Prozessumsetzung anzustrebende Vorgehen beschreibt der Abschnitt 4.3.5.

102

4 Integrationsmodell

4.3.1 Problembereiche der Prozessumsetzung Ein aus dem Prozessentwurf resultierender Prozess erstellt das jeweilige Anforderungsprofil an das Informationssystem. Das bedeutet, der Prozess definiert die erforderliche Computerunterstiitzung. Dabei entstehen zum Teil Bedtirfnisse nach neuen Applikationen oder Datensammlungen. Jedes Untemehmen besitzt aber in der Regel bereits ein Informationssystem. Eine Neuentwicklung des gesamten Informationssystems aufgrund des Prozessentwurfs, d.h. eine Implementiemng auf der ,,griinen Wiese", ist deshalb meist aus mehreren Griinden nicht realistisch. Nachfolgend werden beispielhaft einige Grfinde aufgefiihrt, n~ihere Ausfiihrungen sind zu finden in [Derungs 1997b, S. 14f; Gassner 1996, S. 2]. 9

Der Prozessentwurf betrachtet die Informationstechnologie vor allem als Enabler [vgl. Davenport 1993; Hammer/Champy 1993], um mit ihrer Hilfe das Business innovativ zu gestalten. Der Kern des Gesch~ifts des Unternehmens bleibt dabei in vielen F~illen unveriindert bestehen.

9

Die Untemehmen haben in ihre Informationssysteme in den vergangenen Jahren erhebliche Ressourcen investiert. K6nnen diese Investitionen weder abgeschrieben noch amorti-

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells

103

siert werden, sind die Unternehmen nicht bereit, die bisherigen Anwendungen abzul6sen [Fobes 2000, S. 439; Jacobson et al. 1994, S. 283f]. 9

Die Anwendungen des Informationssystems enthalten Know-how fiber das angestammte Gesch~ift. Dieses Wissen ist fiber Jahre hinweg gewachsen und weder in seiner Breite und Tiefe dokumentiert noch in den jeweiligen K6pfen der Mitarbeiter pr~isent Is. Bennett 1995, S. 20; Eicker et al. 1992, S. 138], sondern nur noch implizit in den Anwendungen vorhanden.

9

Die Anwendungen unterstfitzen in der Regel nicht nur einen Prozess im Unternehmen und zwischen den Anwendungen bestehen Beziehungen. Diese beiden Argumente zeigen, dass bei der Prozessumsetzung das vorhandene Informationssystem nicht isoliert aus Sicht eines Prozesses betrachtet werden darf, denn ein einziger Eingriff in das lnformationssystem verursacht unter Umst~inden viele Nebeneffekte.

9

Eine Neuentwicklung des Informationssystems w~ire in den meisten F~illen zu teuer, zu zeitaufwendig und projektm~issig schwer fiihrbar. Das damit verbundene Risiko l~isst sich deshalb nur selten vertreten [Jacobson et al. 1994, S. 283; Ulrich 1990, S. 16].

Diese und weitere Grfinde zeigen, dass eine vollst~indige Neuentwicklung des Informationssystems aufgrund des Prozessentwurfs nur in den seltensten F~illen realistisch ist. Vielmehr mfissen alle vorhandenen und geplanten Anwendungen bei der Prozessumsetzung beriicksichtigt werden. Daraus k6nnen dem Projektteam aber auch erhebliche Probleme entstehen, da sowohl das Altsystem als auch das technologische Umfeld enge Rahmenbedingungen setzen kOnnen. Diese k6nnen eine Umsetzung aller Optionen des neugestalteten Prozesses verhindern oder einen Rficksprung zum Prozessentwurf erforderlich machen.

Ausgehend von den Rahmenbedingungen lassen sich mehrere Problembereiche ~ r die Prozessumsetzung ableiten (Abb. 4.13). Eine vollst~ndige Aufz~hlung solcher Fragestellungen ist schwer m6glich, da sich zum einen die Fragen meist nur in den konkreten Problemstellungen

104

4 Integrationsmodell

des Projekts und zum anderen unendlich viele Kombinationsm/Sglichkeiten ergeben. Deshalb folgt anschliessend nur eine Auswahl von m/3glichen Fragestellungen Rir die Prozessumsetzung. 9

Die Angaben aus dem Prozessentwurf in Bezug auf die Computerunterstiitzung sind nicht detailliert genug. Sie stellen erste grobe Anforderungen an das Informationssystem dar. Das Projektteam muss in diesen F~illen eine Konkretisierung der Vorgaben vomehmen und dabei m6gliche Wechselwirkungen zwischen der Prozess- und Informationssystemebene beriicksichtigen. Eine grobe Vorgabe aus dem Prozessentwurf kann beispielsweise grosse Auswirkungen auf die notwendige Infrastruktur des Informationssystems haben. So kann die Anforderung nach einer umfassenden Information fiber eine bestehende Kundenbeziehung (CRM) die Integration diverser Anwendungen im Informationssystem nach sich ziehen.

9

Der Wunsch nach einer weitgehenden Wiederverwendung der Altsysteme erfordert einen exakten Abgleich der vorhandenen Daten und Funktionalit~iten mit den Prozessanforderungen. So k6nnen beispielsweise ben/3tigte Funktionalit~iten nicht hundertprozentig abgedeckt werden oder ben/3tigte Daten sind in keiner vorhandenen Datensammlung abgespeichert. Diese Fragen muss die Prozessumsetzung beantworten und im Bedarfsfalle einen Rticksprung zum Prozessentwurf bewirken.

9

Das Projektteam muss untersuchen, inwieweit Liicken zwischen der Soil-Definition des Prozessentwurfs und dem Ist-Informationssystem bestehen. Falls derartige Liicken bestehen, muss das Projektteam Massnahmen bzw. L~sungen erarbeiten und vorschlagen, welche in die vorhandene Informationssystem-Landschaft passen.

9

Die bestehenden Anwendungen in einem Unternehmen sind meist nur unzureichend dokumentiert. Dieser Umstand erschwert eine Wiederverwendung der Altsysteme. Die Anpassung der Altsysteme an die Anforderungen oder ihre Integration mit anderen Anwendungen erfordert eine Beschreibung- zumindest der wesentlichen Funktionalit~t und der angebotenen Schnittstellen.

9

Ein Gesch~iftsprozess kann die Verwendung von mehreren Anwendungen fordern. Die Form der Integration dieser Anwendungen (4.3.3) kann erst bei der Prozessumsetzung geplant werden und gegebenenfalls Rtickwirkungen auf den Prozessablauf haben.

9

Das Unternehmen muss bei der Prozessumsetzung entscheiden, inwieweit ein Prozess automatisch, z.B. mit Hilfe eines Workflow-Managementsystems, gesteuert werden soil. Es hat eine der m/~glichen Steuerungsvarianten auszuw~ihlen (Abschnitt 5.3).

Die angeftihrten Fragestellungen zeigen sehr deutlich, dass es sich bei der Implementierung eines Prozesses um ein komplexes Vorhaben handelt. Die unterschiedlichen Einflussfaktoren mtissen so kombiniert werden, dass sie erfolgreich zusammen spielen. Letztendlich geht es bei der Prozessumsetzung um die Verwendung und Integration von heterogenen Anwendungen (Systemintegration) [vgl. Hsu/Howard 1994; Muth 1995b; Rusinkiewicz/Sheth 1995] sowie um die Steuerung des Ablaufs (Prozessintegration). Die vorliegende Arbeit hilft diese

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells

105

komplexe Feld besser zu beherrschen. Sie zeigt methodische Vorgehensweisen ftir die Prozess- und Systemintegration und gibt Hinweise auf die ver~gbaren technologischen M6glichkeiten der Integration. Der Einsatz von Anwendungen gliedert sich in folgende Bereiche [Jacobson et al. 1994, S. 182fq: 9

Der Prozess verwendet die existierenden Anwendungen entweder unver~indert oder erfordert Erweiterungen dieser.

9

Die vorhandenen Anwendungen kOnnen nicht alle Anforderungen aus dem Prozess abdecken und eine Erweiterung w~ire mit einem nicht vertretbarem Aufwand verbunden. In diesen F~illen muss das Unternehmen neue Anwendungen auf dem Markt beschaffen oder selbst entwickeln, um die Anforderungen zu er~llen, sowie diese in die Systemlandschaft integrieren.

Beide Einflussfaktoren- das bestehende Informationssystem mit seinen Anwendungen und die am Markt ver~gbaren Technologien und Anwendungen- in Verbindung mit den mOglichen Varianten der Ablaufsteuerung ~hren in der Regel zu einer Menge von m6glichen Umsetzungsvarianten ~ r den Gesch~iftsprozess (Abschnitt 4.3.3). Die Planung solcher Szenarien obliegt der Prozessumsetzung. Sowohl bei der Bildung der m6glichen Umsetzungsvarianten als auch bei der sp~iteren Auswahl einer bestimmten Variante sind Rahmenbedingungen zu beachten. Beispielsweise grenzt die technologische Machbarkeit unter Berticksichtigung des bestehenden Informationssystems in der Regel eine Reihe von denkbar m6glichen Varianten von vornherein aus. Hat sich das Unternehmen fiir eine Variante der Prozessumsetzung entschieden, muss das Projektteam die Planung der Prozess- (Abschnitt 4.4.2) und Systemintegration (Abschnitt 4.5.2) vornehmen. Diese ergeben detaillierte Angaben fiir das Projektvorgehen und-management. Die Abbildung 4.14 stellt das Spannungsfeld der Prozessumsetzung grafisch dar. Aus den Problembereichen ergeben sich folgende Aufgaben ~ r die Prozessumsetzung: 9

Sie muss die Implementierung eines Prozesses, insbesondere seiner Aufgaben, spezifizieren. Dabei greift sie auf die Desktopintegration zuriick, welche einzelne Aufgaben zun~ichst isoliert als Softwarebausteine implementiert.

9

Sie muss die Implementierung des Prozessablaufs im Informationssystem entwerfen. Hierzu verwendet sie die Prozessintegration, deren Ziele eine aktive Steuerung und Kontrolle der Prozesse sind.

9

Sie muss die erforderliche Integration der Anwendungen definieren. Mit Hilfe der Systemintegration bestimmt sie den notwendigen Grad an Integration und spezifiziert die Schnittstellen.

106

4 Integrationsmodell

Die folgenden Abschnitte gehen n~iher auf die Rahmenbedingungen Rir die Bildung von m0glichen Umsetzungsvarianten ein. Weiterhin beschreiben die folgenden Ausftihrungen die potentiell m0glichen Architekturvarianten Rir eine Prozessumsetzung sowie die technologischen Implementierungsvarianten. Abschliessend zeigt der Abschnitt 4.3.5 das Vorgehen bei der Prozessumsetzung.

4.3.2 Rahmenbedingungen fiir die Planung der Prozessumsetzung Die Prozessumsetzung stellt sicher, dass die Anforderungen aus dem Prozessentwurf adiiquat in das Informationssystem umgesetzt werden. Ergebnis des Prozessentwurfs ist ein auf organisatorischer Ebene beschriebener Prozess. Das Aufgabenkettendiagramm zeigt den Prozessablauf und ordnet die einzelnen Aufgaben organisatorischen Einheiten, den Aufgabentriigem, zu. Aus den Ergebnissen des Prozessentwurfs muss das Projektteam die Anforderungen Rir das Informationssystem ableiten, sofem diese noch nicht in ausreichend detaillierter Form vorliegen (Abschnitt 4.3.2.1). Den Detaillierungsgrad der Anforderungen bestimmt die im Untemehmen eingesetzte Methode ftir die Informationssystementwicklung. Nachdem die Anforderungen vorliegen, sind unter Berticksichtigung des vorhandenen Informationssystems (Abschnitt 4.3.2.2), der m0glichen Architekturvarianten (siehe Abschnitt 4.3.3) und der technologischen Implementierungsm0glichkeiten (Abschnitt 4.3.4) unterschiedliche Szenarien Rir eine adaquate Realisierung der Anforderungen zu bilden. Anhand von vorgegebenen Kriterien ist aus der Anzahl m0glicher Szenarien die geeignetste auszuwiihlen.

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells

107

4.3.2.1 Ableitung der Anforderungen aus dem Prozessentwurf

Ftir die Ableitung der Anforderungen sind sowohl die verwendete Methode l~r den Prozessentwurf als auch far die Informationssystementwicklung relevant, weshalb auf beide im Folgenden tiberblicksweise eingegangen wird.

4.3.2.1.1 Methoden fiir den Prozessentwurf

Die Prozessumsetzung geht davon aus, dass sie Anforderungen an das Informationssystem aus dem Prozessentwurf enthNt, um diese dann zu implementieren [vgl. Jacobson et al. 1994, S. 285ff; Manganelli/Klein 1994, S. 33ff]. Somit kniipft die Prozessumsetzung unmittelbar an den Prozessentwurf an. Es stellt sich die Frage, inwieweit die heute existierenden Methoden fiir den Prozessentwurf (Synonym BPR) die Anforderungen an das Informationssystem bereits spezifizieren. Die aus dem BPR resultierenden Ergebnisse sind dann im gegebenen Fall weiter zu verfeinem und mit den Methoden der Informationssystementwicklung abzustimmen. Eine Vielzahl von Ans/~tzen verfolgt mit dem BPR die fundamentale Neugestaltung von Prozessen. Jedoch verbergen sich hinter diesem Begriff unterschiedliche Methoden bzw. Konstruktionsprinzipien fffir Prozesse [s. Hess/Brecht 1995]. Die Methoden unterscheiden sich in zwei zentralen Aspekten: dem Gestaltungsbereich und dem Umfang der methodischen Unterstfitzung. Die nachfolgenden Ausffihrungen und Aussagen sttitzen sich vorwiegend auf die Analyse bestehender BPR-Methoden von [Hess/Brecht 1995]: 9

Verschiedene Ans/~tze beschreiben ein systematisches Vorgehen mr den Prozessentwurf, das insbesondere Ergebnisse und teilweise auch Techniken bereitstellt. Das vollst/indige Spektrum einer Methode im Sinne des Method Engineerings nach [Gutzwiller 1994, S. 11 ff] k6nnen nur wenige Vertreter abdecken.

9

Alle Methoden konzentrieren sich auf den Prozessablauf. Sie gestalten ihn mittels spezieller Techniken und Tools und setzen fftir die Entscheidungsuntersttitzung unter anderem auch ausgew/~hlte Simulationstechniken ein [s. Bach et al. 1995]. Der resultierende Prozessablauf ist in der Regel sehr detailliert beschrieben und gibt klare Anweisungen mr die Ablaufsteuerung vor. Soll eine automatische Steuerung mit Hilfe eines WorkflowManagementsystems implementiert werden, sind die Ergebnisse (gering~gig) zu erg/~nzen.

9

Die meisten Autoren beziehen das Informationssystem in ihren Methoden mit ein, jedoch h/~ufig nur mit geringer Intensit/~t. Im Vordergrund stehen dabei die Innovationen der Informationstechnik, einerseits zur UnterstiJtzung von Prozessen und andererseits als ein wesentlicher Ausl6ser von radikalen Ver/~nderungen in Unternehmen und zwischen Untemehmen (vgl. z.B. Informationstechnik als Enabler in [Hammer/Champy 1993, S. 83ff; 0sterle 1995, S. 138ff]).

108

4 Integrationsmodell

9

Die Beschreibungen der Anforderungen an das Informationssystem beschr~inken sich meist auf eine grobe Umschreibung der gewiinschten Funktionalit~it von Anwendungen. Gem~iss einer Untersuchung von abgeschlossenen BPR-Projekten im deutschsprachigen Raum ist auch in der Praxis eine detaillierte Spezifikation des Informationssystems im Rahmen eines BPR-Projekts eher selten [s. Hess et al. 1995, S. 11f].

9

Die Methoden konzentrieren sich vorwiegend auf die Gestaltung neuer Prozesse, eine Dokumentation der Ist-Prozesse findet allenfalls am Rande statt. Somit befassen sie sich auch mit dem Informationssystem nicht im Detail (z.B. mit den vorhandenen Transaktionen) [s. Hess et al. 1995, S. 1Of].

Zusammenfassend liefem Methoden mr den Prozessentwurf Ergebnisse, auf denen die Prozessumsetzung aufbauen kann. W~ihrend die Planung der Ablaufsteuerung bereits im Prozessentwurf Beachtung findet und konkrete Ergebnisse mr die Realisierung liefert, reicht die Spezifikation des Informationssystems aus dem Prozessentwurf mr die Implementierung noch nicht aus. Fiir die Gew~ihrleistung einer Durchgangigkeit vom Prozess zum Informationssystem muss diese Spezifikation weiter verfeinert werden. [Manganelli/Klein 1994] zeigen auf, wie dieser l]-bergang bei einer Neuentwicklung der Applikationen aussehen kann (s. auch Abschnitt 4.3.2.1.2). Aber auch sie leisten keinen direkten Beitrag zur Planung und Gestaltung der evolutionaren Weiterentwicklung des Informationssystems auf Basis vorhandener Anwendungen. Eine Abstimmung aller vermgbaren BPR-Methoden mr die Prozessumsetzung ist an dieser Stelle nicht machbar und wenig sinnvoll. Deshalb wird die Durchg~ingigkeit zwischen dem Prozessentwurf und der Prozessumsetzung anhand einer ausgew~ihlten Methode beispielhatt aufgezeigt. Die vorliegende Arbeit orientiert sich an der Methode PROMET| [IMG 1997] mr den Prozessentwurf. Eine vollst~dige Durchg~ingigkeit zwischen dem Prozessentwurf nach PROMET| und der Prozessumsetzung kann nur erreicht werden, wenn die Prozessumsetzung das gesamte Prozessmodell (s. Abschnitt 3.1.2.1, Abb. 4.15) abdeckt und nicht nur einzelne Komponenten daraus. Im Detail bedeutet dies: 9

Die Prozessumsetzung muss die Realisierung von Leistungen mit Hilfe von Daten, Funktionen und Applikationen spezifizieren.

9

Die Prozessumsetzung muss die Realisierung von Aufgaben und deren computeruntersttitzte Steuerung aufgrund der Aufgabenketten spezifizieren.

9

Die Prozessumsetzung muss die Prozessmhrtmg aufgrund der Daten im Informationssystem spezifizieren. Die automatische Erhebung von FtihrungsgrSssen und die Erstellung eines Prozessstatusberichts sind Beispiele einer Realisierung.

9

Die Prozessumsetzung muss die konkrete Verwendung des Informationssystems mr einen Prozess spezifizieren.

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells

109

Die relevanten Ergebnisdokumente aus dem Prozessentwurf ergeben sich aus den erforderlichen Dokumenten ftir die Prozessintegration (Abschnitt 5.2.1) und den notwendigen Dokumenten mr die Systemintegration (Abschnitt 6.2.1). Im Einzelnen handelt es sich um die Dokumente: 9

Aufbauorganisation

9

Ffihrungsgr6ssen

9

Aufgabenkettendiagramm

9

Ffihrungsorganisation

9

Aufgabenverzeichnis

9

Prozessgmnds~tze

9

Berichtswesen Prozessffihrung

9

Prozesskontextdiagramm

9

Leistungsverzeichnis

9

Prozesszerlegungsmatrix

Ihre detaillierten Beschreibungen sind in den Kapiteln zur Prozess- und Systemintegration zu finden.

4.3.2.1.2 Methoden fiir die Informationssystementwicklung Die Informationssystementwicklung beschiiftigt sich mit der Umsetzung von Anforderungen an die Computeruntersttitzung eines Unternehmens in Eigenschaften des Informationssystems [vgl. Balzert 1998, S. 97ff; Kargl 2000, S. 74ff; Osterle 1981, S. 16t"; Schwarze 1995, S. 71 ]. Da viele Autoren der Informationssystementwicklung ein systematisches Vorgehen vorschlagen und den Entwicklungsprozess yon der Anforderungsspezifikation bis zum lauff'dhigen System intensiv begleiten, ist eine Untersuchung dieser Konzepte im Hinblick auf ihre

110

4 Integrationsmodell

Eignung zur Ableitung der Anforderungen aus den Ergebnissen des Prozessentwurfs unabdingbar. Die Informationssystementwicklung umfasst Ans~itze zur (groben) Gestaltung des gesamten Informationssystems [s. z.B. Hilbers 1992; Krcmar 1990; Schumann et al. 1994], zur Entwicklung von Anwendungen und Applikationen [s. z.B. Barker 1992; Booch 1994; Gutzwiller 1994; Heym 1993; Yourdon 1989], zur Einftihrung von Standardsoftware und fftir das Reverse Engineering und Reengineering [s. z.B. Chikofsky/Cross 1990; Eicker et al. 1992]. Die starke Ausrichtung der Untemehmen an ihren Gesch~iftsprozessen hat sich seit einiger Zeit auch in den Methoden der Systementwicklung niedergeschlagen. Die Methoden erweitern ihre Modelle prim/ar in den frtihen Phasen der Systementwicklung um den Prozessgedanken. Vor allem bei der Analyse oder der Anforderungsspezifikation spielt der Gesch~iftsprozess eine zentrale Rolle. Er bildet den Ausgangspunkt, der Ergebnisse fftir die Weiterbearbeitung liefert. Stellvertretend fiir Methoden mit einer Prozessorientierung seien hier die Methode Rapid Re von [Manganelli/Klein 1994], Oracle Designer/2000 [s. Barker 1992] und das Produkt LEU (LION Entwicklungsumgebung) der LION Gesellschaft flir Systementwicklung mbH [s. Gruhn 1993; Gruhn/Haak 1995; Slaghuis 1996] genannt. Sie untersttitzten den Ubergang vom Prozess zum Informationssystem mit einzelnen Techniken, indem sie aus dem Prozess konkrete Anforderungen ftir Daten und Funktionen ableiten. Jedoch beschr~tken sich die Methoden in der Regel auf die Entwicklung von neuen Anwendungen, die Einbindung des vorhandenen Informationssystems wird zu wenig oder gar nicht berticksichtigt. Da die vorliegende Arbeit von einer evolution~iren Weiterentwicklung des bestehenden Informationssystems ausgeht, sind nicht alle Methoden zur Informationssystementwicklung detailliert zu betrachten. Die vorhandenen Anwendungen sollen soweit m6glich an die Anforderungen aus dem Prozessentwurf angepasst werden. Ftir diese Modifikation der Altanwendungen steht eine Reihe von Methoden zur Ver~gung (Abb. 4.16), die im Folgenden im l~lberblick dargestellt werden. N/ihere Ausftihrungen zu den einzelnen Methoden sind zu finden bei [Hoch 1996, S. 139ff].

4.3 ProzessumsetzungalsAnwendungdesIntegrationsmodells

111

-m ReverseEngineering --Aufbereiten b Restructuring F DB-Schnittstelle--~ F Datenbank-1 [ > DatenMiddleware O Gateway _,J zugang

]

Elementare Methoden

Methodender

Integrieren

|Mechanismen

--

Altsysteman-

im Rahmenvon BPR

passung

.__Jlntegrierte Methoden

|--t- ZugangsschaffendeL ~ Screenscraper~ Wrapper

/Zugreifende E RPC MOM b Middleware O ORB [-- Standardsoftware Erweitern I-- ApplicationTemplates L Individualprogammierungmit ...

L/. Funktionen-

/

/.,,)

zugang

-t InternesAnpassen durchSW-Reengineering

~ Front-ending Externes Anpassen durch...

Wrap-around Hub-and-Spoke

Abb. 4.16..

Methoden f~r die Anpassung von Altanwendungen [s. Hoch 1996, S. 140]

Ftir die Anpassung des bestehenden Informationssystems, insbesondere der Altanwendung, stehen vier unterschiedliche Varianten zur Verfiigung: 9

Aufbereitung der Altanwendungen gemgss den neuen Anforderungen Methoden aus diesem Bereich konzentrieren sich auf die Wiedergewinnung und Aufbereitung von Softwarebausteinen aus bestehenden Anwendungen. Das Softwarerecycling zielt vor allem auf die Wiederverwendbarkeit ab. Innerhalb dieser Methoden sind die Techniken Reverse Engineering und Restrukturiemng zu unterscheiden. Integrieren der Altanwendungen Um bestehende Anwendungen weiter verwenden zu k6nnen, sind Zugriffe auf deren Funktionen und Daten notwendig. Deshalb z~ihlen die Methoden fiir die Anwendungsintegration ebenfalls zur Weiterentwicklung vom Informationssystem.

9

Erweitem des Informationssystems Um ein Informationssystem den neuen Anforderungen gerecht weiterzuentwickeln, kann eine Einfiihmng neuer Anwendungen erforderlich sein. In diesem Bereich unterscheidet

112

4 Integrationsmodell

man die Individualentwicklung neben der Einfiihnmg von Standardsoftware oder der Verwendung von Application Templates [vgl. Hoch 1996, S. 163ff]. 9

Integrierte Methoden fiir die Anpassung des Informationssystems Sie verkntipfen die eher technisch ausgerichteten elementaren Methoden von oben zu einem Vorgehen. W~ihrend das interne Anpassen das Informationssystem in seine Bestandteile zerlegt und diese im neuen System entsprechend wiederverwendet, werden die Anpassungen beim externen Vorgehen ausserhalb des Altsystems vorgenommen und dann in dieses integriert.

Die Prozessumsetzung muss entsprechend der im Unternehmen eingesetzten Methode fiir die Entwicklung des Informationssystems ausreichend genaue Informationen aus dem Prozess ableiten. Die vorliegende Arbeit konzentriert sich dabei auf die Methoden der Integration.

4.3.2.2 Kenntnis des Ist-Informationssystems Um das Informationssystem gem[iss den Anforderungen aus dem Prozessentwurf weiterentwickeln zu k6nnen, ist eine ausreichende Kenntnis der vorhandenen Anwendungen notwendig. Die folgenden Ausfiihrungen geben einen Uberblick tiber die wesentlichen Informationen tiber ein Informationssystem, welche fiir dessen Weiterentwicklung notwendig sind. Die Ergebnisdokumente werden in den Abschnitten 5.2.2 und 6.2.2 detailliert beschrieben. In der Regel verwendet ein Unternehmen nicht eine einzige integrierte Anwendung flit die Untersttitzung seiner Prozesse. Vielmehr ist eine Vielzahl von unterschiedlichen und zumeist heterogenen Anwendungen im Einsatz und vielfach fehlen flit die vorhandenen Anwendungen ausreichende Dokumentationen. In gr6sseren Unternehmen gibt es deshalb heute kaum jemanden, der die Wirkungsweise des gesamten Informationssystems tiberblicken kann. Ist eine unternehmenseigene Dokumentation der bestehenden Anwendungen nicht vorhanden, muss das Projektteam im Rahmen der Prozessumsetzung eine Beschreibung des Informationssystems erarbeiten. Das Ziel daft dabei nicht die Vollerhebung und Nachdokumentation des gesamten Informationssystems sein, nur der fiir den zu implementierenden Prozess relevante Ausschnitt des Informationssystems ist zu betrachten. Und auch dieser Ausschnitt muss nicht im Sinne einer vollstiindigen Dokumentation erfasst werden. Notwendig sind primiir eine Anwendungstibersicht und eine grobe Beschreibung der Anwendungen mit ihren wichtigsten Schnittstellen [Jacobson et al. 1994, S. 286]. Eine weitere Detaillierung der Beschreibung ist erst dann notwendig, wenn der konkrete Bedarf aus den Daten- und Funktionsanforderungen bekannt ist. Eine Ubersicht tiber das Informationssystem oder auch nut ein Ausschnitt aus diesem muss \ im Rahmen der Prozessumsetzung zwei Aspekte berticksichtigen. Es mtissen alle wesentlichen Anwendungen erfasst und beschrieben sein, sowie deren Beziehungen untereinander. Damit wird dem Umstand Rechnung getragen, dass ein Informationssystem aus einer Vielzahl

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells

113

von miteinander verflochtenen Anwendungen besteht. Demnach besteht die Ist-Informationssystembeschreibung zumindest aus 9

einem Applikationsszenario und

9

einer Datentransferbeschreibung.

Weiterhin sind notwendig: 9

ein IT-Szenario, das Angaben tiber die technologischen Gegebenheiten und deren Zustand in naher Zukunft enth~ilt, sowie

9

genauere Anwendungsbeschreibungen, welche auch deren Schnittstellen ausweisen und Angaben fiber die Plattform, das Alter, die Version etc. umfassen. Im Rahmen der Prozessumsetzung k6nnen n~ihere Angaben fiber die relevanten Anwendtmgen erforderlich werden, insbesondere der Transaktionen und Serviceprogramme sowie der Datenstrukturen, welche fiir die Prozessuntersttitzung in Frage kommen. Ftir den Abgleich der funktionalen Anforderungen aus dem Prozessentwurf reichen wenig zentrale Angaben tiber die betroffenen Komponenten aus.

Diese relativ groben Beschreibungen reichen mr die Planung der Prozessumsetzung aus, mtissen jedoch im konkreten Projekt weiter verfeinert werden. Abbildung 4.17 zeigt abschliessend die Dokumentationen, welche mr die Planung einer Prozessumsetzung vorliegen mtissen.

4.3.3 Architekturvarianten der Prozessumsetzung Die Prozessumsetzung hat aus einer Reihe yon m~glichen Architekturvarianten die fi~r den Prozess geeignete auszuw~ihlen. Als Entscheidungsgrundlage werden die Anforderungen aus dem Prozessentwurf und die m6gliche Integration in das vorhandene Informationssystem

114

4 Integrationsmodell

herangezogen. Die wesentlichen Unterscheidungsmerkmale der Varianten sind der Grad der automatischen Steuerung des Prozessablaufes (d.h. die Art der Prozessintegration), der Grad der computerisierten Aufgabenunterstiitzung, die Zahl der im Prozess involvierten Anwendungen sowie deren Integrationsgrad (d.h. die eingesetzte Systemintegration). Die nachfolgenden Ausfiihrungen beschreiben diese potentiellen Varianten im Einzelnen und setzen bei jeder Architektur voraus, dass alle Aufgaben des Prozesses mit Anwendungen untersttitzt werden (und somit das Kriterium der Aufgabenunterstiitzung ftir alle gleich ist). Jede Variante wird einleitend kurz verbal und mit einer Graphik beschrieben. Anschliessend erfolgen eine Auflistung der Charakteristika der Variante gem/iss den Unterscheidungskriterien sowie eine Beschreibung der Vor- und Nachteile der Variante.

4.3.3.1 Variante eins: Eine integrierte Anwendung Die einfachste Art und Weise, einen Prozess mit computerisierten Funktionen zu untersttitzen, ist es, alle Funktionen und Daten mittels einer einzigen, in sich integrierten Anwendung zur Verftigung zu stellen (Abb. 4.18, 4.19). In diesem Fall entfallen Bemiihungen zur Vereinheitlichung von Benutzeroberflachen, zur Bildung von Schnittstellen usw.

Unterscheidungskriterium Zahl der involvierten Anwendungen

Ausprigung

Bemerkung

Eine

Integrationsgrad der betroffenen Anwendungen

Hoch

In der Regel handelt es sich hier um ein Standardsoftwarepaket wie beispielsweise SAP R/3. Die Anwendung kann sich aus mehreren Modulen zusammensetzen. Der Integrationsgrad h~ngt vonder Anwendung selbst ab. Handelt es sich um eine modular aufgebaute Software, ist deren Integrationsgrad entscheidend.

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells Unterscheidungskriterium Automatische Prozesssteuerung

Ausprigung

Bemerkung

Keine

In diesem Fall bietet die Anwendung selbst keine Steuerung entlang des Prozesses an. Der oder die Benutzer m0ssen die jeweils erforderlichen Methoden aufrufen. In der Programmlogik der Anwendung ist eine Steuerung zumindest von Teilabltiufen enthalten. Sie gibt z.B. durch Men0f0hrung vor, welche Methoden als n~chstes aufzurufen sind. Die Anwendung umfasst auch ein Modul f~r die Steuerung von Abl~ufen. Dies 0bernimmt die Modellierung, Steuerung und Kontrolle der Workflows und ruff die entsprechenden Methoden auf.

Teilweise

Eigenes WorkflowModul der Anwendung

Abb. 4 . 1 9 :

115

Charakteristikader Variante Eine Anwendung

Vorteile

Die Vorteile dieser L6sung sind sehr deutlich. L/isst sich ein Prozess mit einer einzigen Anwendung umsetzen, entfallen ftir die Benutzer Schulungen unterschiedlicher Anwendungen. Die Benutzeroberfl~ichen und-~hrung sind einheitlich. Weiterhin liegt dem gesamten Prozess in diesem Fall auch nur ein einziges Datenmodell zugrunde. Inhaltliche Fehler, die bei einer Integration von mehreren Datenmodellen vorkommen k6nnen, entstehen hier nicht. Ein weiterer Vorteil mr die Prozessumsetzung ist, dass eine Integration von (heterogenen) Anwendungen entf~illt. Gew6hnlich mtissen keine neuen Schnittstellen implementiert werden. Die Pflege und Wartung dieser Variante gestalten sich relativ einfach.

Nachteile

Ein Untemehmen wickelt nicht nur einen Prozess ab, weshalb sich die Frage stellt, wie sich diese Architekturvariante im Hinblick auf das gesamte Untemehmensgeschehen verh~ilt. Sind ftir jeden Prozess jeweils eigene Anwendungen vorhanden, liegt u.U. ein komplexes Informationssystem mit heterogenen Anwendungen vor. Mtissen in diesem Fall die Prozesse interagieren, ist Integrationsaufwand notwendig. FOr alle Prozesse nur eine einzige Anwendung zur Untersttitzung einzusetzen ist unwahrscheinlich [vgl. Butler Group 1999; Gileadi 2000]. Die entstehende hohe Komplexit~it der Anwendung macht deren Wartung sehr schwierig. Ausserdem mtissen in solch komplexen Aufgabengebieten in der Regel einige Kompromisse geschlossen werden, die eine optimale Untersttitzung der Prozesse verhindem.

116

4 Integrationsmodell

Einsatz

Die vorgestellte Architekturvariante eignet sich vor allem bei Prozessen, deren Untersttitzung weitergehend durch eine einzige betriebswirtschaftliche Standardanwendungssot~are oder durch eine einzige Eigenentwicklung abgedeckt wird.

4.3.3.2 Variante zwei: Isolierte Anwendungen

Die Aufgaben des Prozesses werden durch eine Vielzahl von unterschiedlichen Anwendungen unterstiitzt. Dabei stehen die entsprechenden Anwendungen dem Benutzer ohne jede Form von Integration zur Verfiigung (Abb. 4.20, 4.21). Dieser Fall l~isst sich am einfachen Beispiel einer Serienbrieferstellung erl~iutem. Der Anwender ben6tigt aus der Adressverwaltung die relevanten Adressen, erstellt seinen Brief mit der Textverarbeitung und legt den Brief dann im Archivsystem ab. In der zweiten Architekturvariante stehen die drei Anwendungen lose nebeneinander. Das bedeutet, der Anwender muss selbst die unterschiedlichen Anwendungen gem~iss der Aufgabenerfiillung aufrufen und zudem den Datentransfer zwischen den Anwendungen (manuell) vornehmen.

Unterscheidungskriterium

Auspdigung

Bemerkung

Zahl der involvierten Anwendungen Integrationsgrad der betroffenen Anwendungen Automatische Prozesssteuerung

Mehrere

Alle Anwendungen stehen isoliert und autonom nebeneinander. Dem Benutzer selbst bleibt die Weitergabe der erforderlichen Daten 0berlassen. Sind mehrere Anwendung zur Unterst0tzung der Prozessaufgaben erforderlich, die auch nicht untereinander integriert sind, kommt keine automatische Steuerungskomponente in Frage. Eine Steuerung von Teilabl~iufen ist mOglich, wenn eine der involvierten Anwendungen for mehrere Arbeitsschritte in Folge verantwortlich ist. Diese k6nnen durch die Programmlogik der Anwendung gesteuert werden.

Keine Integration Keine

Teilweise

A bb. 4. 21:

Charakteristika der Variante Isolierte Anwendungen

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells

117

Vorteile

Die Prozessumsetzung auf Basis dieser Variante erfordert keinen Integrationsaufwand. Lediglich der Zugriff auf die entsprechenden Methoden und Daten durch den Benutzer muss gew/ihrleistet sein.

Nachteile

Die fehlende Integration der involvierten Anwendungen fftihrt zu manuellen Aufw/inden bei der Datenweitergabe. Doppelarbeiten, fehlerhafte Eingaben etc. sind die Folge. Weiterhin sind in dieser Variante keine Transparenz oder automatische Kontrolle eines Prozessverlaufs m6glich.

Einsatz

Die Architekturvariante ist insbesondere dann zu w/ihlen, wenn fiir die Untersttitzung des Prozesses eine Vielzahl heterogener Anwendungen in Frage kommt und deren Integrationsaufwand sehr hoch w/ire. Handelt es sich auch noch um einen Prozess mit relativ geringem Aufkommen, ist der Aufwand gegentiber dem geringen Nutzen einer automatischen Steuerung entscheidend mr die lose Kopplung.

4.3.3.3 Variante drei: Systemintegration zwischen vereinzelten Anwendungen

Auch bei der dritten Architekturvariante sind mehrere unterschiedliche Anwendungen fiir die Untersttitzung des Prozesses notwendig. Die einzelnen Anwendungen stehen hier jedoch nicht alle losgel6st nebeneinander, sondem sind gem/iss dem Informationsfluss stellenweise miteinander verbunden, d.h. integriert (Abb. 4.22, 4.23). Das Serienbrief-Beispiel aus dem vorhergehenden Abschnitt kann auch hier zur n/iheren Erl/iuterung dienen. Mittels Systemintegration werden die drei ben6tigten Anwendungen -Adressverwaltung, Textverarbeitung und Archiv- miteinander integriert, so dass nach Selektion der Adressen diese in die Serienbrief-Funktion der Textverarbeitung tibemommen werden k6nnen. Nach Fertigstellung des Briefes erfolgt die Ablage ins Archiv ebenfalls tiber eine implementierte Schnittstelle.

118

4 Integrationsmodell

Bei dieser Architekturvariante sind vor allem solche Anwendungen miteinander integriert, die tiber Standardschnittstellen verfiigen, oder die sehr h~iufig Informationen austauschen mtissen.

Unterscheidungskriterium

Ausprigung

Bemerkung

Zahl der involvierten Anwendungen Integrationsgrad der betroffenen Anwendungen

Mehrere

Automatische Prozesssteuerung

Keine

Einige Anwendungen des Workflows sind 0ber Schnittstellen miteinander verbunden. Die Integration einiger der involvierten Anwendungen ist mehr zuf~.illig erfolgt, ohne gesch~:ifUichen Hintergrund. Vorhandene komfortable SchnitIstellen oder ein h~ufig stattfindender Datenaustausch zwischen ihnen fQhrten zu der Integration. Weder der Workflow im Ganzen noch der Taskflow waren dabei das zentrale Kriterium. Durch die eher zuf~llige Verbindung einzelner Anwendungen ist in der Regel keine Steuerung des gesamten Workflows m0glich. Die Programmlogik einzelner Anwendungen kann eine Steuerung innerhalb dieser erm0glichen. Ebenso ist eine Steuerung 0bet die integrierten Anwendungen denkbar.

Mittel

Teilweise

Abb. 4 . 2 3 :

Charakteristikader Variante Systemintegration einzelner Anwendungen

IZorteile

Der Integrationsaufwand h~lt sich in Grenzen, da nur diejenigen Anwendungen miteinander verbunden werden, welche bereits Schnittstellen anbieten oder die ein hohes Aufkommen an Datentransfers haben. Der Informationsfluss ist besser untersttitzt als bei den beiden vorhergehenden Varianten.

Nachteile

Bei der Verbindung der Anwendungen steht der Aufwand im Vordergrund und weniger die betriebliche Aufgabe. Es herrschen immer noch Medienbrtiche vor und vielfach ist nur eine manuelle Steuerung des gesamten Workflows m6glich.

Einsatz

Die Architekturvariante eignet sich dann, wenn m6glichst wenig Integrationsaufwand betrieben werden soil. Die schwer zu integrierenden Anwendungen bleiben weiterhin ohne Verkntipfungen isoliert im Workflowablauf bestehen.

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells

119

4.3.3.4 Variante vier: Taskflowsteuerung Die vierte Architekturvariante stellt eine Weiterftihrung der dritten dar. Das Unterscheidungsmerkmal dieser beiden Architekturen liegt in dem gesteigerten Integrationsgrad. W~ihrend bei der dritten Variante nur vereinzelt Anwendungen miteinander integriert sind, verbindet die vierte Architekturvariante mittels Systemintegration alle ben6tigten Anwendungen innerhalb der einzelnen Aktivit~iten gem~iss des Informationsflusses miteinander (Abb. 4.24, 4.25). Dabei stehen nicht nur Schnittstellen mr den Informationsaustausch zur Ver~gung, auch die Aufgabenausfiihrung wird gesteuert. Relevant ist dieser Fall vor allem bei komplexeren Aufgaben, die mehrere Anwendungen zur Erftillung erfordern.

Unterscheidungskriterium

Auspr~gung

Bemerkung

Zahl der involvierten Anwendungen

Mehrere

Integrationsgrad der betroffenen Anwendungen

Hoch (Aktivit~t)

Alle Anwendungen einer Aktivit~t sind miteinander integriert. Sie bilden jeweils ein ausf0hrbares Programm. Innerhalb der Aktivit~ten sind alle notwendigen Anwendungen entlang dem Informationsfluss verbunden.

Beliebig (Workflow)

Automatische Prozesssteuerung

Ganzheitlich keine Teilweise

Abb. 4 . 2 5 :

Der gesamte Ablauf, d.h. die Verbindung der Aktivit~tenbausteine, ist beliebig zu gestalten. Der gesamte Workflow wird in dieser Architekturvariante von keiner Steuerungskomponente geregelt. Jedoch sind die Abl~iufe innerhalb der Aktivit~ten transaktionsorientiert oder flexibel gesteuert.

Charakteristika der Variante Taskflowsteuerung

Vorteile

Die Integration aller innerhalb einer Aktivit~it notwendigen Anwendungen erleichtem die AufgabenausfiJhrung bei den Benutzern. Der Informationsfluss erfolgt automatisch, keine MedienbriJche und manuelle Eingaben kommen mehr vor. Sind die Aktivit~iten unter Berticksichtigung der Wiederverwendung in anderen Prozessen gebildet worden, lassen sich mit Hilfe dieser Architektur schnell und flexibel neue Abl~iufe realisieren.

120

4 Integrationsmodell

Nachteile

Liegen heterogene Anwendungen zugrunde, ist ein hoher Aufwand ~ r die Integration dieser zu leisten. An den Schnittstellen der Aktivit~iten k~nnen immer noch Medienbrtiche vorkommen, manuelle Weitergaben und manuelle Dateneingaben sind die Folge.

Einsatz

Steht die UnterstiRzung der Aufgabenaus~hrung am Arbeitsplatz im Vordergrund, eignet sich diese Architekturvariante. Zu beachten ist die vorliegende Heterogenit~it der beteiligten Anwendungen, da sie den zu t~itigenden Aufwand beeinflussen.

4.3.3.5 Variante fiinf." Workflowsteuerung

Die fiinfte Variante stellt die automatische Steuerung des Prozessablaufs in den Vordergrund. Das prim[ire Ziel ist die zeit- und ablaufgerechte Weitergabe des Vorgangs nach einer Aufgabenerfiillung an den n~ichsten Aufgabentr~iger. Jede der involvierten Anwendungen ist mittels der Steuerungskomponente in den Ablauf integriert (Abb. 4.26, 4.27).

Unterscheidungskriterium Zahl der involvierten Anwendungen Integrationsgrad der betroffenen Anwendungen

Auspriigung

Bemerkung

Mehrere

Automatische Prozesssteuerung

FOr gesamten Workflow

Die involvierten Anwendungen interagieren alle 0ber die Steuerungskomponente. Alle ben(StigtenAnwendungen im Rahmen des Workflows sind mit der Steuerungskomponente integriert. Sie regelt auch die Datenweitergabe zwischen den Anwendungen. Die Workflowsteuerung regelt gem~iss der gew0nschten Steuerungsart (flexibel oder transaktionsorientiert) den Ablauf der Aktionen.

Hoch (Workflow)

Abb. 4 . 2 7 :

Charakteristikader Variante Workflowsteuerung

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells

121

Vorteile

Ein hohes Mass an Transparenz und Kontrolle der Abl~iufe wird erreicht, wenn die Workflowsteuerung alle ben/Stigten Anwendungen aufruft sowie die Datentransfers und den Ablauf der T~itigkeiten regelt. Zudem mtissen in diesem Fall die Anwendungen nur jeweils eine Schnittstelle zur Steuerungskomponente aufweisen. Eine Interaktion untereinander ist nicht notwendig.

Nachteile

Die Steuerungskomponente muss ausreichend flexibel sein. Sie sollte sowohl fexible als auch transaktionsorientierte Abl~iufe zulassen und den Arbeitsfluss an einem Arbeitsplatz nicht durch Steuerungsmassnahmen unterbrechen. Da alle Anwendungen tiber die Steuerungskomponente interagieren, sollte sie ausreichend viele Schnittstellen anbieten. Der Ausfall einer derartigen Steuerungsschicht bringt die Abwicklung der Workflows zum Erliegen.

Einsatz

Diese Architekturvariante kann vielfach auf Basis der nicht ausreichenden Flexibilit~it der Steuerungswerkzeuge und insbesondere deren Integrationsf~ihigkeit nicht in gr6sseren heterogenen Informationssystemen eingesetzt werden.

4.3.3.6 Variante sechs: Task- und Workflowsteuerung Die letzte Variante stellt sowohl den Ablauf innerhalb yon Aktivitiiten (Taskflow) als auch zwischen diesen (Workflow) in den Mittelpunkt der Betrachtung. Die Anwendungen einer Aktivit~it werden mittels Systemintegration zu einem ablauffiihigen Programmbaustein verbunden, der yon einer tibergeordneten Steuerungskomponente in einen Workflow eingebunden wird (Abb. 4.28, 4.29). Die Aus~hrungen der Prozessintegration im Kapitel 5 basieren auf der Annahme dieser Variante. Sie liisst in Bezug auf Flexibilitiit die meisten Freiheiten zu.

122

4 Integrationsmodell

Unterscheidungskriterium Zahl der involvierten

Anwendungen Integrationsgrad der betroffenen Anwendungen Automatische Prozesssteuerung

Abb. 4 . 2 9 :

Auspr~igung

Bemerkung

Mehrere

Die involvierten Anwendungen in desktopintegrierten Aktivit~ten geb0ndelt. Hoch Innerhalb der Aktivit~iten sind die Anwendungen mittels (Workflow) Systemintegration verbunden. Diese Programmbausteine sind 0ber die Workflowsteuerung integriert. FOr gesamten Die Workflowsteuerung regelt gem~ss der gew0nschWorkflow ten Steuerungsart (flexibel oder transaktionsorientiert) den Ablauf der Aktivit~ten. Charakteristika der Variante Task- und Workflowsteuerung

Vorteile

Die Integration aller innerhalb einer Aktivit~it notwendigen Anwendungen erleichtert die Aufgabenausfiihrung bei den Benutzem. Die Informationen fliessen automatisch, keine Medienbriiche und manuelle Eingaben kommen mehr vor. Sind die Aktivit~iten unter Beriicksichtigung der Wiederverwendung fiir andere Prozesse gebildet worden, lassen sich mit Hilfe dieser Architektur schnell und flexibel neue Abl~iufe realisieren. Die Steuerung dieser Aktivit~iten mittels einer eigenen Komponente 1/isst ein hohes Mass an Transparenz und Kontrolle zu. Die Trennung der beiden Abl~iufe Task- und Workflow ffihrt zu Flexibilit/~t. So k6nnen flexible Taskflows in einem transaktionsorientierten Workflow eingebunden werden. Die Trennung der Workflowsteuerung von der Taskflowsteuerung untersttitzt den Austausch oder die Weiterentwicklung der jeweiligen Steuerung.

Nachteile

Werden die Aktivit~iten nicht mit ausreichender Beriicksichtigung der Wiederverwendung gebildet, kann bei jedem neuen Ablauf eine neue Version entstehen. Da die Bildung von Aktivit~iten in heterogenen Informationssystemen mit hohem Aufwand verbunden ist, sollten sie nicht h~iufigen Anderungen unterliegen.

Einsatz

Die Architekturvariante hilft, das Informationssystem mehr in Richtung des Prozessgedankens zu strukturieren. Langfristig entstehen mit dieser Variante Module, welche sich leicht an ge~inderte Prozessanforderungen anpassen lassen. Diese Variante ist bei einem hohen Integrationsaufwand zu empfehlen, d.h. wenn der Prozess eine Vielzahl heterogener Anwendungen ben6tigt. Diesen Aufwand kann man auf Basis der Aktivit/atenbildung (s. Abschnitt 5.4.2.2) leicht in kleinere tiberschaubare Teilprojekte gliedern.

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells

123

Zusammenfassung Zusammenfassend fahrt die folgende Abbildung 4.30 die beschriebenen Architekturvarianten der Prozessumsetzung auf und zeigt je Variante die dafar notwendige(n) Integrationsart(en) (Prozess-, Desktop- und Systemintegration). Ein leeres Feld in der Matrix bedeutet, dass ftir die Variante der Prozessumsetzung die entsprechende Integrationsart nicht in Frage kommt. Die m6glichen Kombinationen yon Prozessumsetzungsvariante und Integrationsart enthalten in den entsprechenden Feldem jeweils einen Verweis auf die Abschnitte der Prozess-, Desktop- und Systemintegration der vorliegenden Arbeit, welche vertieft auf deren Umsetzungsvarianten sowie das methodische Vorgehen eingehen. Die dort vorgestellten Methoden gehen, soweit nicht explizit anders erw~ihnt, vom komplexesten Fall der Prozessumsetzung, der Variante Task- und Workflowsteuerung, aus.

4.3.4 Technologische Implementierungsvarianten Neben dem bestehendem Informationssystem sind die Entwicklungen auf dem Softwaremarkt eine weitere Einflussgr6sse auf die Prozessumsetzung. Eine neu ver~gbare Technologie wie beispielsweise die Intemet-Technologie bringt vielfach Verbesserungsm6glichkeiten mr die Prozessuntersttitzung mit sich. Somit muss die Prozessumsetzung nicht nur Kenntnis des bereits vorhandenen Informationssystems besitzen, sondern auch fiber den aktuellen Softwareund Technologiemarkt. Die immer ktirzeren Entwicklungszyklen und die Vielzahl an Produkten erschweren meist einen solchen Oberblick. Deshalb sollte ein Unternehmen periodisch ein Technology Assessment durchfahren.

124

4 Integrationsmodell

Das Technology Assessment zeigt auf, welche technologischen M6glichkeiten fftir die Umsetzung der gewiinschten Architekturvariante in Frage kommen. Fiir alle vorgestellten Architekturvarianten gibt es technologisch mehrere M6glichkeiten der Implementierung. So l~isst sich z.B. die Workflow-Variante mit Hilfe eines zugekauften Workflow-Managementsystems oder einer eigenentwickelten Softwarekomponente realisieren (s. Abschnitt 5.3.2). An dieser Stelle alle potentiellen Kombinationen von Architekturvarianten und technologischen Werkzeugen aufzufftihren, ist wenig sinnvoll. Der rasche Wandel im Bereich der Technologie l/isst die Aussagen sehr schnell veralten und stets neue Wahlm6glichkeiten zu. Deshalb gehen die folgenden Ausftihrungen nur auf die wesentlichen Merkmale eines Technology Assessments ein.

Technology Assessment Die Begriffe Technikbewertung, Technikfolgenabsch~itzung oder Technologie Assessment sind gebr~iuchliche Ubersetzungen des aus den USA stammenden Begriffs Technology Assessment [Peissl/Torgersen 1996]. Das Assessment zielt darauf ab, die m6glichen Folgen eines bestimmten Technologieeinsatzes systematisch und vollst~indig zu erfassen und zu bewerten [vgl. Paschen et al. 1978; Schuchardt/Wolf 1990; Wicher 1989]. Vollstandig bedeutet, dass auf alle relevanten Anspruchsgruppen und Wirkungsdimensionen (6konomisch, rechtlich, politisch, kulturell, 8kologisch) eingegangen wird [s. Becker 1998, S. 110]. Das Technology Assessment ist ~ r drei unterschiedliche Problembereiche anzuwenden: 9 Projektspezifischer Technologieeinsatz Im Rahmen eines Projekts sind die Folgen und Einsatzm6glichkeiten unterschiedlicher Technologien zu iiberprtifen. So k6nnen die Projektverantwortlichen mit Hilfe eines Technology Assessments iiberprtifen, ob sich ein Prozess mit der im Unternehmen verfiigbaren und zul~issigen Technologie umsetzen l~isst oder ob neue Technologien notwendig sind. 9 Bewertung einer spezifischen Technologie Die Folgen einer bestimmten Technologie werden global bewertet. 9 Problemspezifisches Assessment Ftir ein bestehendes oder zuktinftiges Problem werden unterschiedliche technologische L6sungsm6glichkeiten gesucht. Anschliessend erfolgt eine Bewertung der Altemativen. Im Rahmen des Business Engineering ist ein Technology Assessment sowohl fiir die regelm/issige Absch~itzung neuer Technologien Rir das Untemehmen als auch im Rahmen der Prozessumsetzung ftir die Einsatzbewertung im Hinblick auf die Erfordemisse des Prozesses notwendig. Im ersten Fall muss das Untemehmen neue Werkzeuge permanent im Hinblick auf ihren m6glichen Beitrag zum Untemehmenserfolg evaluieren und dabei auch die Integrationsflihigkeit in das vorhandene Informationssystem berticksichtigen [Becker et al. 1998, S.

4.3 Prozessumsetzungals Anwendungdes Integrationsmodells

125

112]. Dieses Assessment ist Teil der IS-Architekturentwicklung und definiert diejenigen Schltisseltechnologien, welche in Projekten eingesetzt werden k/3nnen. Im zweiten Fall darf die Bewertung nicht nur projektspezifisch erfolgen, sondern auch m~gliche Auswirkungen auf weitere Prozesse ausserhalb des Projektumfanges sind zu berticksichtigen. Jede identifizierte Schltisseltechnologie wird auf ihren m~glichen Einsatz im konkreten Projekt untersucht.

Bewertungsfaktoren im Technology Assessment Ftir das Technology Assessment gibt es verschiedene Techniken. An dieser Stelle werden nur die wesentlichen Bewertungsfaktoren aufgez~ihlt [Becker et al. 1998, S. 115], die entscheidenden Einfluss auf die Beurteilung einer Technologie hinsichtlich deren Einsatz im Informationssystem nehmen. Dabei mtissen nicht alle genannten Faktoren eine Rolle spielen. 9

Anforderungen der Prozesse an das Informationssystem.

9

Betriebswirtschaftliche Konzepte und Trends, deren Implementierung einen spezifischen Technologieeinsatz erfordern.

9

Technologische Trends und der State of the Art.

9

Einstufung der Technologie in Bezug auf Stabilit~it (Die Beurteilung erfolgt aufgrund des Reifegrads, Anzahl der Installationen, Marktanteil, Herstellerbeurteilung, Herstellerbindung usw.)

9

Strategische Ausrichtung der Informationsverarbeitung.

9

Komponenten der IS-Architektur, sowohl der bestehenden als auch der geplanten (IT-Szenario).

9

Erfahrungen mit der Technologie im Unternehmen.

9

Interne VerfOgbarkeit von Expertise: Wissensstand der Mitarbeiter in Bezug auf die Erkennung und Umsetzung von Trends.

9

Externe VerfOgbarkeit von Expertise: Sounding Boards, externe Berater.

9

Technologiestandards.

9

Konkurrenz- und Marktanalyse: Welche Leistungen kann die Konkurrenz aufgrund des Einsatzes anderer Technologien besser anbieten?

Verfahren des Technology Assessments Neben diversen Faktoren fOr die Beurteilung existiert eine Reihe von Techniken fOr das Technology Assessment. Eine umfassende Analyse bestehender Verfahren ist zu finden in [von Eiff 1992; Von Reibnitz 1992]. Im Rahmen der Prozessumsetzung empfiehlt sich in der

126

4 Integrationsmodell

Regel ein projektspezifischer Mix einzelner Techniken. Die Abbildung 4.31 Rihrt elementare Techniken nach ihrem Anwendungsbezug geordnet auf.

Verfahren zur Trenderkennung 9 Sounding Boards (externer Wissenstransfer) 9 Technology Management/Research: aufspOren und Verfolgen von Trends durch Analyse externer Informationsquellen (Literatur, Seminare, WWW, usw. . . .

Systemorientierte Entscheidungsverfahren 9 Brainstorming/Brainwriting mit Technologie- und Organisationsexperten 9 Delphi-Methode 9 Abbildungsverfahren 9 Morphologische Methode 9 Szenario Technik . . .

Bewertungsverfahren 9 Argumentenbilanz 9 Nutzwertanalyse 9 Segmentierungsverfahren 9 SWOT-Analyse: Bewertung des eigenen Technologieeinsatzes im Vergleich zum Hauptkonkurrenten l

. . .

Abb. 4 . 3 1 :

Elementare Verfahrenf~r das Technology Assessment

4.3.5 Vorgehen bei der Prozessumsetzung Die Umsetzung eines Prozesses in ein Informationssystem erfolgt nach dem Prozessentwurf und bedingt sowohl die Prozess- als auch Systemintegration. Der Prozessentwurf definiert die Anforderungen an die Anwendungsintegration. So erfordert die Implementierung eines Prozesses die Konzeption der gewtinschten Ablaufsteuerung und stellt somit Anforderungen an die Prozessintegration. Geht man von der Existenz eines Informationssystems aus, so sind dessen Anwendungen im Sinne einer evolution~iren Weiterentwicklung fiir die Prozessabwicklung weiter zu verwenden und allenfalls um neue Anwendungen zu ergiinzen. Anforderungen an die Systemintegration sind die Folge. Das Vorgehensmodell einer Prozessumsetzung setzt sich deshalb aus Techniken der Prozesssowie der Systemintegration zusammen. Die folgende Abbildung 4.32 zeigt das Vorgehen der Prozessumsetzung im l]berblick sowie die notwendigen Dokumentationen aus dem Prozessentwurf und der Ist-Systembeschreibung. Auf die einzelnen Techniken und Vorgehensweisen der Prozess- und Systemintegration gehen die spiiteren Kapitel 5 und 6 ein.

4.4 Prozessintegration

127

4.4 Prozessintegration Die Prozessintegration umfasst alle Massnahmen zur aktiven Steuerung einzelner Prozesse (s. auch Abschnitt 3.1.2.6.1) sowie zur Steuerung zwischenbetrieblicher Abl~iufe. Ein Prozess, bestehend aus mehreren Aufgaben, soll m6glichst reibungslos, ohne Medienbrtiche entsprechend seiner definierten Ablauffolge durch ein oder zwischen Untemehmen gesteuert werden. Prozessintegration als Zustand (s. Abschnitt 4.4.1) orientiert sich demzufolge an der Art der Ablaufsteuerung. Die Prozessintegration als Vorgang (s. Abschnitt 4.4.2) definiert auf Basis der Ergebnisse des Prozessentwurfs die zu steuemden Bausteine (Aktivit~iten oder Tasks), konzipiert deren Steuerung (fixe Reihenfolge, variable Reihenfolge etc.) und weist sie konkreten Aufgabentr~igem zu. Sie behandelt Gesichtspunkte der technischen, der organisatorischen und der personellen Integration [vgl. KNger 1994, S. 127; Stietz 1994]. Die vorliegende Arbeit befasst sich vor allem mit den Aspekten der technischen Integration, weshalb die Prozessintegration hier der Ebene des Informationssystems zuzuordnen ist. Oberschneidungen mit der Prozessebene des Business Engineering, insbesondere im Bereich der Bt~ndelung von Tasks zu Aktivit~ten und der Zuweisung der Aktivit~iten zu Stellen, fliessen jedoch mit ein.

128

4 Integrationsmodell

Bezugspunkt der Prozessintegration In der Regel identifiziert der Prozessentwurf nur die wertsch6pfenden Kemprozesse eines Untemehmens. Die resultierenden Prozesse sind h~iufig relativ umfangreiche und komplexe Gebilde Is. 0sterle 1995, S. 48-62]. Aufgrund des groben Detaillierungsgrads k6nnen mit Hilfe des Prozessentwurfs (BPR) nur Grundsatzentscheidungen in Bezug auf die Steuerung des Prozesses getroffen werden, wie z.B. die Verteilung der Aufgaben auf Organisationseinheiten, die Art der ComputerunterstiJtzung Rir Aufgaben und einzelne Aspekte der Prozessfiihrung. FiJr die Konzeption der Steuerung sind jedoch noch einige Detailentscheidungen nStig, die vor allem auch das Informationssystem st/irker einbeziehen miissen, als dies im Prozessentwurf geschieht. So spielen die Anzahl der abzuwickelnden Aufgaben, die vorliegende Computerunterstiitzung der einzelnen Aufgaben sowie die Heterogenit~it des Informationssystems eine bedeutende Rolle bei der Konzeption einer Prozesssteuerung. Aus diesem Grund ist mr die Untersuchung der Prozessintegration eine n~ihere Betrachtung des Prozesses als im Prozessentwurf notwendig. Nicht mehr der Prozess, sondem der Workflow ist der Bezugspunkt tiir die weiteren l]berlegungen. Wie die Sicht "Prozessintegration" des Metamodells aus Abschnitt 0 darstellt, implementiert der Workflow einen Prozess. Jede Aktivit~it des Workflows kann wiederum selbst aus mehreren Tasks bestehen, die ebenfalls entsprechend einer vordefinierten Ablauffolge abzuwickeln sind. Die sogenannte Desktopintegration [s. Derungs 1997a, S. 86] befasst sich mit der Ablaufsteuerung von Tasks innerhalb von Aktivit~iten und stellt damit eine Sonderform der Prozessintegration dar. Der Unterschied liegt im Detaillierungsgrad der Betrachtung. Zur besseren Differenzierung der beiden Betrachtungsebenen werden mr die jeweiligen Abl~iufe zwei unterschiedliche Begriffe verwendet: w~ihrend der Ablauf zwischen den Aktivit~iten Workflow genannt wird, handelt es sich innerhalb einer Aktivit~'t um den Taskflow(Abb. 4.33). Schwerpunkt der Desktopintegration sind neben der ad~iquaten BiJndelung der einzelnen Tasks zu Aktivit~iten aus Sicht des Benutzers die Identifikation sowie optimale Integration der benStigten Anwendungen des Informationssystems, d.h., sie legt die Anforderungen mr die notwendige Systemintegration fest.

4.4 Prozessintegration

129

Somit lassen sich folgende Unterschiede festhalten: Eine Aufgabe aus dem Prozessentwurf ist eine betriebliche Funktion mit einem bestimmbaren Ergebnis, die von Menschen und/oder Maschinen ausgemhrt wird [s. Osterle 1995, S. 50]. Die Aktivit~t in einem Workflow stellt aus Benutzersicht und aus Sicht der Ablaufsteuerung ein sinnvolles Arbeitspaket dar [vgl. Derungs 1997a, S. 174] und beachtet bei der Abgrenzung auch die notwendige Systemintegration der Anwendungen. Ein Task als elementarer Arbeitsschritt ruft eine Anwendung auf.

4.4.1 Prozessintegration und Desktopintegration als Zustand

Die Zust~inde sowohl der Prozess- als auch Desktopintegration differenzieren sich nach der Ablaufsteuerung. Diese bezieht sich in den beiden F~llen auf unterschiedliche Sichten des Ablaufs: im Falle der Prozessintegration auf den Workflow und im Falle der Desktopintegration auf den Taskflow. Da die m6glichen Varianten der Ablaufsteuerung jedoch mr beide Abl~ufe identisch sind, kann auf eine getrennte Untersuchung der Prozess- und Desktopintegration als Zustand verzichtet werden.

Varianten der Ablaufsteuerung

Die unterschiedlichen Varianten der Ablaufsteuerung unterscheiden sich nach zwei Dimensionen: nach der Art der Ablauffolge und nach dem mr die Steuerung Verantwortlichen. Aufgrund der Art der Ablauffolge der Aktivit~iten oder der Tasks k6nnen folgende Varianten der Ablaufsteuerung unterschieden werden: 9

Standardisierte Ablauffolge --) standardisierte Ablaufsteuerung In dieser Auspr~gungsform ist die Ablauffolge vordefiniert und hat bei jeder Ausmhrung einen identischen Verlauf. Man spricht deshalb auch von Routineprozessen oder stark strukturierten Prozessen [vgl. Becker 1996, S. 325ff; Picot/Rohrbach 1995]. Dementsprechend sollte auch die Ablaufsteuerung standardisiert sein. Sie schreibt den Ablauf fix vor, d.h. nach Abschluss einer Aktivit~t (bzw. Tasks) stehen die Folgeaktivit~t (bzw. Folgetask) sowie deren Aufgabentr~.ger fest.

9

Flexible Ablauffolge bekannter Aktivit~ten --)flexible Ablaufsteuerung Eine flexible Ablauffolge ist gekennzeichnet durch eine definierte Menge auszuffihrender Aktivit~ten (bzw. Tasks), deren Reihenfolge jedoch variabel ist. Einzig die vollst~ndige Ausmhrung aller Aktivit~ten (bzw. Tasks) ist die Bedingung mr den erfolgreichen Abschluss des Workflows (bzw. Taskflows). Zu dieser Form z~hlen auch Workflows (bzw. Taskflows), deren Ablauf teilweise flexibel und teilweise standardisiert ist. Die Steuerung des Ablaufes muss diesem Umstand Rechnung tragen. Sie dient weniger der Steuerung im engeren Sinne als vielmehr der Kontrolle einer vollst~ndigen Aufgabenermllung. Die Ablaufsteuerung unterstfitzt die Aufgabentr~ger bei der Weitergabe, indem

130

4 Integrationsmodell sie ihnen die noch ausstehenden Nachfolgeaktivit/iten (bzw. Nachfolgetasks) zur Auswahl anbietet.

9

Unbekannte Ablauffolge und T/itigkeiten --) ad hoc Ablaufsteuerung Sind weder die auszufiihrenden Aktivit/iten (bzw. Tasks) noch deren Ablauf bekannt, handelt es sich um einen sog. ad hoe Workflow (bzw. ad hoe Taskflow) [vgl. Barbian/Schmidt 2001, S. 243f; Leymann/Roller 2000, S. 11; Riempp 1998, S. 51; Sch~il 1996, S. 13]. Zu dieser Form z/ihlen auch Workflows (bzw. Taskflows), die durch ein unvorhergesehenes Ereignis nicht mehr gem/~ss der definierten Ablauffolge weiter auszuftihren sind, sondem einer neuen Abwicklung bediirfen. In diesem Falle kann eine Steuerung nicht vorab definiert werden. Es wird ebenfalls ad hoc gesteuert. Der Prozesssteuerung k6nnte beispielsweise in Form von Auswahllisten bereits definierter Aktivit/iten (bzw. Tasks) oder der Protokollierung des bisherigen Ablaufs unterstiitzt werden. Eine Protokollierung ist fiir ein eventuell notwendiges Riicksetzen des Vorganges oder fiir die Wiederholung des Ablaufes bei Wiederholung der gleichen Umst~inde hilfreich.

Betrachtet man die Verantwortung fiir die Ablaufsteuerung, so lassen sich drei Varianten unterscheiden: 9

Mensch ist verantwortlich -) Manuelle Ablaufsteuerung Sind die einzelnen Aufgabentr/iger der Aktivit/iten fiir die richtige Weitergabe des Prozesses an den folgenden Aufgabentr~iger verantwortlich, liegt eine manuelle Ablaufsteuerung vor. Eine Untervariante l~isst sich dabei bilden, wenn nicht jeder Aufgabentr~iger die Steuerungsfunktion tibemehmen muss, sondem eine zentrale Stelle fiir die Verteilung und Steuerung der Aktivit/iten verantwortlich zeichnet.

9

Mensch und Computer sind verantwortlich -)Computerunterstiitzte Ablaufsteuerung Der Prozessablauf wird nicht automatisch gesteuert, es handelt sich dabei vielmehr um eine computerbasierte Untersttitzung. Beispielsweise k6nnen alle in Frage kommenden Nachfolgeaktivit/iten angezeigt werden, der Aufgabentr~iger w~ihlt dann letztendlich selbst aus dieser Liste aus.

9

Computer ist verantwortlich --) Computerbasierte automatische Ablaufsteuerung Nachdem ein Aufgabentr~iger seine Aktivit~it abgeschlossen hat, iibemimmt eine Softwarekomponente die Steuerung des weiteren Ablaufes.

Nachfolgende Abbildung 4.34 stellt die unterschiedlichen Auspr~igungen der Ablaufsteuerung im l]berblick dar, zeigt deren realistische Kombinationsm6glichkeiten und die Varianten der Ablaufsteuerung. Die vorliegende Arbeit befasst sich in den weiteren Aus~hrungen nur mit denjenigen Varianten der Prozessintegration, welche computeruntersttitzt sind. Diese sind in der Abbildung grau hinterlegt.

4.4 Prozessintegration

131

Entsprechend diesen Varianten der Ablaufsteuerung sind die folgenden Zustgnde (oder Varianten) der Prozess- und Desktopintegration von weiterem Interesse [vgl. auch BornscheinGrass 1995, S. 63; Elgass/Krcmar 1994, S. 69]: 9

A d hoc Workflows, die sich durch eine manuelle Steuerung und einen unbekannten Work-

flowablauf auszeichnen, jedoch eine Computemnterstt~tzung in Form von Auswahllisten erhalten. 9

Flexible Workflows, bei denen nicht so sehr die Steuerung als vielmehr die automatische

Kontrolle einer vollstgndigen Aufgabenabwicklung im Mittelpunkt steht. 9

Transaktionsorientierte oder automatisierte Workflows, welche sich durch eine automatisierte Steuerungskomponente auszeichnen.

Konform zu dieser Differenzierung unterscheidet die Desktopintegration 9

A d hoc Taskflows

9

Flexible Taskflows

9

Transaktionsorientierte Taskflows

132

4 Integrationsmodell

Die sinnvollen Kombinationsm6glichkeiten und die jeweiligen Vor- und Nachteile der unterschiedlichen Integrationsvarianten sind im Abschnitt 5.3 n~iher beschrieben. Ebenfalls dort nachzulesen sind die Kriterien, welche fiJr die Wahl einer Variante sprechen.

4.4.2 Prozessintegration als Vorgang W~ihrend in dem vorhergehenden Abschnitt die unterschiedlichen Auspr~igungen der Prozessintegration im Vordergrund standen, besch~iffigen sich die folgenden Aus~hrungen mit der Prozessintegration als Vorgang (s. Abschnitt 4.3). Sie legt den Blickwinkel auf das Vorgehen bei der Zusammenfiihrung yon Arbeitsschritten, Anwendungen, Applikationen oder Informationssystemen. Fragestellungen bei der Prozessintegration als Vorgang lauten: 9 Wie ist vorzugehen, damit die Aktivit[iten konform zu den Vorgaben des Gesch~it~sprozesses und den technologischen Rahmenbedingungen gesteuert werden? 9 Wie ist vorzugehen, um elementare Arbeitsschritte ad~iquat zu Aktivit~ten zusammenzufassen? 9 Welche Varianten der Ablaufsteuerung sind mtiglich? 9 Wie k6nnen Technologien zur Prozessintegration eingesetzt werden? Mit Hilfe der Prozessintegration als Vorgang soil die entsprechende Variante der Ablaufsteuerung fiar den betrachteten Prozess gefunden, die da~r optimalen Arbeitspakete in Form von Aktivit~iten abgegrenzt und eine Entscheidung in Bezug auf die gewiinschte Realisierung der Steuerung des Task- und Workflows getroffen werden. Die Prozessintegration umfasst hierbei auch die Aktivit~iten der Desktopintegration. Nach der Wahl einer konzeptionellen Steuerungsvariante - sowohl fiar den Workflow als auch den Taskflow - steht den Projektverantwortlichen in der Regel eine Auswahl von Implementierungsm6glichkeiten zur Ver~gung. Auf diese geht der Abschnitt 5.3.2 n~iher ein. Die Prozessintegration muss sich an den Vorgaben des Prozessentwurfs orientieren. Gem~iss den dort getroffenen groben Entscheidungen beziiglich des Prozessablaufes wird eine detaillierte Workflowspezifikation vorgenommen. Diese grenzt den eigentlichen Workflow ab, definiert die zu steuemden Aktivit~iten (indem sie auf die Desktopintegration zurtickgreift), deren exakte Ablauffolge sowie die dafiJr verantwortlichen Aufgabentr~iger. Ziel der Prozessintegration ist es, den Workflow in Bezug auf den Ablauf weiter zu spezifizieren. Basis daffir sind die Aufgabenketten aus dem Prozessentwurf. Es kommen vor allem weitere Kriterien hinzu, die verst~irkt die Frage nach dem Wie verfolgen [s. Derungs 1996, S. 136]. Beispielsweise sind die Art der Ablaufsteuerung, die Benutzerergonomie oder die Technik zus/atzliche Aspekte ~ r die sinnvolle Abgrenzung von Arbeitspakten und Workflows. Die Prozessintegration besch/iftigt sich somit nicht mehr mit der Ableitung von Aufgaben z.B. aus den zu erzielenden Leistungen. Diese iibemimmt sie gr6sstenteils aus den Vorgaben des Prozessentwurfs. Sie stellt vielmehr die Komposition von sinnvollen Arbeitspaketen ~ r den Benutzer und die 0berprtifung auf Vollst~indigkeit in den Mittelpunkt.

4.4 Prozessintegration

133

Das Vorgehen der Prozessintegration unterteilt sich in drei B16cke: 9

Die Workflowabgrenzung(Abschnitt 5.4.2.1) geht von einem Prozess aus, der in der Regel ein komplexes und relativ umfangreiches Gebilde ist, und identifiziert die Workflows. Sie sind h~iufig kleinere, tiberschaubarere Einheiten, die das weitere Vorgehen besser planen lassen und die notwendige Detailspezifikation erst erm6glichen. Ausserdem wahlt die Workflowabgrenzung mr alle identifizierten Workflows und Taskflows die ad~iquate Steuerungsvariante.

9

Die Desktopintegration (Abschnitt 5.4.2.2) hat die Aufgabe, die Einbindung der Anwendungen am Arbeitsplatz einerseits aus Sicht des Benutzers und andererseits aus Sicht der Steuerungskomponente und des Informationssystems festzulegen. Sie grenzt die zu steuemden Aktivit~iten ab.

9

Die Workflowplanung (Abschnitt 5.4.2.3) definiert den Ablauf der Aktivit~iten im Workflow und legt die verantwortlichen Stellen fest. Sie basiert auf den Ergebnissen der Workflowabgrenzung und der Desktopintegration und verwendet zus~itzlich Ergebnisse aus dem Prozessentwurf, die ablauf- oder aufbauorganisatorischer Art sind.

Vorgehen in den drei Teilbereichen der Prozessintegration Abbildung 4.35 zeigt das Vorgehen der Prozessintegration.

134

4 Integrationsmodell

Die Workflowabgrenzung analysiert die Ergebnisse aus dem Prozessentwurf, insbesondere die Aufgabenkette und das Aufgabenverzeichnis, auf Vollst~indigkeit und zerlegt sie bei Bedarf anschliessend in die elementaren Arbeitsschritte. Darauf aufbauend werden ad~iquate Workflowkandidaten identifiziert, wobei die m6glichen Steuerungsvarianten Einfluss auf die Abgrenzungen nehmen. Ftir alle Kandidaten muss in einem weiteren Schritt die anzustrebende Steuerungsvariante gew~ihlt und sie miissen auf ihre Implementierbarkeit beurteilt werden. Zuletzt plant die Workflowabgrenzung die Umsetzung der resultierenden Workflowkandidaten. Reicht die Funktionalit~it des Informationssystems ~ r die erforderliche Unterstiatzung der Prozessabwicklung nicht aus, sind Teilprojekte zur Schaffung dieser Funktionalit~it erforderlich. Diese mtissen ebenfalls in die Planung einbezogen werden. Fragestellungen an dieser Stelle sind insbesondere die Projektkomplexit~it und der genaue Projektumfang (und somit die exakte Abgrenzung des Untersuchungsbereichs innerhalb des Informationssystems). Die Desktopintegration leitet aus den Ergebnissen der Workflowabgrenzung sinnvolle Arbeitspakete ab, die Aktivit~iten. Hierzu biJndelt sie die elementaren Arbeitsschritte nach speziellen Kriterien zu Aktivitaten. Diese Kriterien ~hren in der Regel zu einer etwas anderen Btindelung von Arbeitspaketen als im Prozessentwurf. Sie stellen vor allem die Sicht des Benutzers und technische Aspekte in den Vordergrund. Weiterhin spezifiziert die Desktopintegration die Einbindung der relevanten Anwendungen innerhalb einer Aktivit~it. Insbesondere analysiert sie die Datenaustauschbeziehungen zwischen den Tasks und legt die Systemintegration der Anwendungen fest. Die Workflowplanung spezifiziert nach der Abgrenzung des Workflows und der Definition der Aktivit~iten die Steuerung des Ablaufs. Sowohl die gewiinschte Steuerungsvariante als auch die Spezialit~iten der Implementierungsvariante nehmen Einfluss auf die Spezifikation der Workflowsteuerung. Abschliessend legt die Workflowplanung die Verantwortung fiir die Ausfiihrung von Aktivit~iten im Detail fest. Das hier nur relativ grob dargestellte Vorgehen bei der Prozessintegration wird in Abschnitt 5.4 im Detail dargestellt. Zusammenfassend stellt folgende Abbildung 4.36 die Gestaltungsbereiche der Prozessintegration denjenigen der Desktopintegration gegentiber.

Ablauf Zu steuernde Kom ponenten Informationsfluss Schnittstellen

Abb. 4.36:

Desktopintegration

Prozessintegration

Taskflow

Workflow Desktopintegrierte Aktivit~ten Kontroll-/Steuerdatenfluss

Tasks Datenflusssowie Kontroll/ Steuerdatenfluss Zur Systemintegration

Zur Desktopintegration

Gestaltungsbereiche der Prozess- und Desktopintegration

4.5 Systemintegration

135

Sowohl die Prozess- wie auch die Desktopintegration zielen vor allem auf die Umsetzung des Kontroll- und Steuerflusses eines Workflows ab. Sie sollen die entsprechenden SchRisseldaten zwischen den unterschiedlichen Aufgabentr~gem und Aktivit~ten sowie zwischen den Tasks weitergeben (vgl. Abb. 4.37). Der eigentliche Daten-/Informationsfluss spielt hierbei nur eine untergeordnete Rolle, er steht bei der Systemintegration (vgl. Abschnitt 4.3) im Vordergrund. Die Desktopintegration bildet den Obergang zwischen den beiden Sichtweisen, indem sie den Informationsfluss konzeptionell entwirft und damit die Vorgaben und Anforderungen an die Systemintegration festlegt.

Aus der Abbildung wird auch deutlich, dass eine IS-UnterstiJtzung der Ablaufsteuerung nur dann alle Potentiale aussch6pfen kann, wenn auch der notwendige Datenfluss ausreichend unterstfitzt ist und Medienbrfiche soweit wie m6glich vermieden werden. Die Prozessintegration und die Desktopintegration erfordern deshalb ein gewisses Mass an Systemintegration. Dies um so st~irker, je mehr Anwendungen ffir die Abwicklung des Prozesses notwendig sind.

4.5 Systemintegration Die Systemintegration befasst sich mit der Interaktion von Applikationen und Datensammlungen zum Zwecke des Datenaustausches (s. auch Abschnitt 3.1.2.6.3). Ubergeordnetes Ziel der Systemintegration ist die ad/~quate Bereitstellung von Informationen am Arbeitsplatz; Systemintegration bedeutet somit das Zusammen~hren von Informationen und die Sicherstellung eines in Bezug auf die Daten konsistenten Informationssystems [vgl. Hasselbring 2000].

136

4 Integrationsmodell

Systemintegration als Zustand (Abschnitt 4.5.1) beschreibt die unterschiedlichen Kategorien und Auspr~igungen der Interaktion zweier Anwendungen. Die Differenzierung der Kategorien orientiert sich an den Objekten oder "Gegenst~den" der Integration. Die Systemintegration als Vorgang (Abschnitt 4.5.2) befasst sich mit der Identifikation des Integrationsbedarfs sowie der Spezifikation von Integrationsbeziehungen und Schnittstellen unter Berticksichtigung m6glicher Integrationsvarianten und-mechanismen. Sie regelt die Interaktion zwischen verschiedenen Anwendungen mit dem Ziel einer ad~iquaten Informationsversorgung im Rahmen eines Workflows und eines konsistenten Datenhaushaltes des Informationssystems.

4.5.1 Systemintegration als Zustand

Ftir die Integration zweier Anwendungen steht dem Projektteam eine Reihe von konzeptionellen L6sungsm6glichkeiten zur VerfiJgung. Die folgenden Betrachtungen gehen von einer durch das Client/Server-Architekturmodell motivierten Unterscheidung von drei Ebenen einer Anwendung aus [vgl. z.B. Martin/Leben 1995, Kap. 7]. Demnach l~isst sich bei jeder Anwendung eine Pr~isentations-, Funktions- und Datenebene unterscheiden (s. Abb. 4.38).

Abb. 4.38:

Client/Server-Architekturmodelleiner Anwendung nach [Riehm 1997, S. 99]

Die Prasentationsebene ist fiir die Ein- und Ausgaben der Anwendung, z.B. auf einer graftschen Oberfl~iche oder einem Drucker, zust~indig. Die Logik der Anwendung ist in der Funktionsebene hinterlegt. Die Datenebene iibemimmt die Speicherung und Verwaltung von Informationen und deren Manipulationen [vgl. Hackathom 1993, S94ff; Martin/Leben 1995, S. 97]. Aufgrund dieser Einteilung in drei Ebenen ergeben sich entsprechend unterschiedliche Ansatzpunkte fiir die Integration von Anwendungen [vgl. auch Brodie/Stonebraker 1995, Kap. 1; Ruh et al. 2001, S. 19]. Die folgenden Abschnitte stellen die Varianten der Systemintegration

4.5 Systemintegration

137

kurz vor, die jeweiligen Vor- und Nachteile sowie die Kriterien, die mr die Wahl der jeweiligen Variante sprechen, sind Gegenstand des Abschnitts 6.3.1.

4.5.1.1 Manuelle Systemintegration Kommt eine technische Integration der beiden Anwendungen nicht in Frage, weil z.B. die technologischen Plattformen zu heterogen sind, bleibt die Integration tiber den Benutzer. In diesem Falle ruft er beide Anwendungen auf und t~bertr~igt manuell die auszutauschenden Daten (s. Abb. 4.39).

4.5.1.2 Frontend-Integration Sind die Pr~isentationsebenen der zu integrierenden Anwendungen die Ansatzpunkte fiir die Integration, spricht man yon einer Frontend-Integration [vgl. Ruh et al. 2001, S. 22ff]. Dabei lassen sich Untervarianten differenzieren, wie das Screen Scraping und die Bildschirmemulation. Screen Scraper erm6glichen den Zugriff auf zeichenorientierte Bildschirme, indem sie auf den Terminaldatenstrom zugreifen oder mit einem Terminalemulator kommunizieren. Eine komplexere Integrationsvariante ist die Simulation der Benutzerdialoge. Mit Hilfe einer neuen Oberfl~iche kann auch, falls es die Anwendungen erlauben, direkt auf die jeweiligen Funktions- oder Datenebenen zugegriffen werden. Durch die Frontend-Integration l~isst sich nicht nur die Oberfl~iche einer Altapplikation durch eine neuere, modernere ersetzen, es stehen damit auch einfache Integrationsmechanismen wie das "cut and paste" zur Verfiigung, die jedoch der Variante der manuellen Systemintegration zuzuordnen sind, da ohne manuelle Eingriffe kein Datenaustausch stattfindet. Abbildung 4.40 zeigt die Architektur der Frontend-Integration mit allen Untervarianten.

138

4 Integrationsmodell

Frontend-Integration bedeutet demnach, dass eine neue Benutzeroberfl~iche geschaffen wird, die entweder im Hintergrund Daten an die entsprechenden Pr~isentationsebenen der Anwendung weitergibt, oder auf die Funktionsebene zugreift, oder direkt auf die Datensammlungen schreibt, oder dass eine der involvierten Oberfl~ichen um diese Funktionalit~it erweitert wurde.

4.5.1.3 Anwendungserweiterung Die Datenanforderungen und die Methoden auf diese Daten sollen in Zukunft alle von einer einzigen Anwendung erftillt werden. Aus diesem Grund integriert man die zus~itzliche Funktionalit~it und die zus~itzlichen Datenfelder in die bestehende Anwendung mit dem gr6ssten l]berdeckungsgrad (s. Abb. 4.41). Die dadurch tiberfliissige zweite Anwendung kann abgel6st werden, sofern sie nicht ftir andere Aufgaben ben6tigt wird oder eng mit weiteren Anwendungen integriert ist. Als Untervariante l~isst sich hier der Einsatz einer neuen Software, die bereits alle Anforderungen abdeckt, auffiihren.

4.5 Systemintegration

139

4.5.1.4 Datenintegration Die Datenintegration verbindet Anwendungen fiber den Austausch von Daten [s. Osterle 1995, S. 242] und unterscheidet zwei Untervarianten, die Integration der Daten sowie die Integration fiber Replikation.

Integration der Daten Kennzeichen dieser Variante ist ein logisch zentraler, gemeinsamer Datenbestand der integrierten Anwendungen [vgl. Reinwald 1993, S. 156]. Dabei mfissen nicht beide Datenbest~inde der Applikation insgesamt zu einer einzigen Datensammlung integriert worden sein (Variante A in Abb. 4.42). Es ist ausreichend, wenn die gemeinsam ben6tigten Daten in einem zentralen Bestand vorgehalten werden (Variante B), oder wenn ein Direktzugriff auf die Daten der zweiten Anwendung erfolgt (Variante C). Liesse sich diese Form der Systemintegration fiber das gesamte Informationssystem hinweg realisieren, g~ibe es kein Redundanzproblem und alle Applikationen h~itten Zugriff auf die aktuellen Daten im Unternehmen. Dem Ziel hinderlich sind die Architekturen der einzelnen Anwendungen. So sind die meisten Applikationen fiir ihre eigenen Datenmodelle entworfen worden und besitzen dementsprechend auch unterschiedliche Semantik der Daten. Auch die Probleme der untemehmensweiten Datenmodellierung sprechen gegen diesen Idealzustand [Sinz 1995].

Integration iiber Replikation Scheidet die vorhergehende Integrationsvariante z.B. aus Performancegr0nden aus, bleiben weiterhin zwei Datensammlungen fiir die ErfOllung des Informationsbedarfes verantwortlich. Sind in beiden Quellen jedoch zumindest ein Teil der Daten redundant, kommt die Integrationsvariante "Integration fiber Replikation" in Frage (s. Abb. 4.43), die auch als "Integration fiber Daten" bezeichnet wird [vgl. I)sterle 1995, S. 245ff]. Die in beiden Datensammlungen redundanten Daten mfissen fiber einen Datenaustausch konsistent gehalten werden. Der Datenaustausch ist bei dieser Variante auch far eine eventuell notwendige Konvertierung der Daten verantwortlich.

140

4 Integrationsmodell

4.5.1.5 Methodenaufruf Bei dieser Variante der Systemintegration (stellenweise auch Funktionsintegration genannt [vgl. Ruh et al. 2001, S. 27ff]) ruft eine Applikation die Methoden der anderen Applikation auf (s. Abb. 4.44). Die Applikationen greifen somit nicht auf die Datensammlungen direkt zu, sondern verwenden im Sinne der Kapselung aus der Objektorientierung die dafiir ausgewiesenen Methoden in den Schnittstellen der Anwendungen [vgl. Bertino et al. 1989]. Die Kontrolle des Datenzugriffs verbleibt somit auf der Seite der verantwortlichen Anwendung.

4.5.1.6 Eigenstlindige Integrationsanwendung Ubernimrnt eine neue Anwendung die Zusammenfi3hrung und Verarbeitung der ben6tigten Informationen, spricht man von Integrationsanwendungen. Eine eigenst~indige Datensammlung, wie in der Abbildung 4.45 ausgewiesen, ist nicht zwingend notwendig. Sie ist eine optionale Einrichtung, die z.B. aus Performancegrtinden angebracht sein kann. Es lassen sich auch hier unterschiedliche Spielarten der Variante unterscheiden, die sich aus Kombinationen der bisher aufge~hrten Integrationsvarianten bilden lassen. Der Einsatz von Middleware oder EAI-Tools als Integrationsebene ist ein Beispiel flit diese Integrationsvariante.

4.5 Systemintegration

141

Spezielle Ausprggungen dieser Integrationsvariante sind z.B. Data Warehouse-L6sungen. Data Warehouse Konzepte gehen von einer zusgtzlichen gemeinsamen Datensammlung aus, welche die Anforderungen der auswertenden Applikationen erfallt und regelmgssig mit den Daten der "produktiven" Datensammlungen gefallt wird [vgl. Inmon 1992; Schreier 1996].

4.5.2 Systemintegration als Vorgang W~ihrend in den vorhergehenden Abschnitten die unterschiedlichen Auspr~igungen und Formen der Systemintegration im Vordergrund standen, besch~iftigen sich die folgenden Ausfahrungen mit der Systemintegration als Vorgang (s. Abschnitt 4.3). Sie legt den Blickwinkel auf das Vorgehen bei der Zusammenfahrung yon Informationen, Applikationen, Anwendungen oder Informationssystemen. Typische Fragestellungen bei der Systemintegration als Vorgang lauten: 9 Wie ist vorzugehen, um eine Applikation und die ihr zugeh6rigen Datensammlungen in ein bestehendes Informationssystem zu integrieren? 9 Wie ist vorzugehen, damit Anwendungen des Informationssystems konform zu den Vorgaben des Geschgftsprozesses interagieren? 9 Welche Varianten der Systemintegration sind bei der Gestaltung einer Integrationsbeziehung m6glich und wie k6nnen Technologien zur Unterstt~tzung der Integration eingesetzt werden? Aus diesen Fragestellungen lassen sich die Aufgaben der Systemintegration ableiten. Sie hat die Integrationspartner zu identifizieren, den notwendigen Datenaustausch zu definieren, die Funktionalitgten zwischen den Anwendungen zu verteilen, allenfalls notwendige Fremdanwendungen wie Middleware far die Integration zu planen, die adgquate Integrationsvariante zu bestimmen und im Rahmen der Realisierung die Dokumentation der Schnittstellen zu t~bemehmen.

142

4 Integrationsmodell

W~ihrend bei der Prozessintegration der Bezugspunkt jeweils ein gegebener Prozess ist (sei es ein neu entworfener als Ergebnis eines Prozessentwurfs oder ein bereits existierender, dessen Steuerung zu modifizieren ist), k6nnen bei der Systemintegration verschiedene Ausgangssituationen vorliegen. So fiihren unterschiedliche Gegebenheiten zu einem Integrationsbedarf zwischen Anwendungen wie z.B. die Einfiihrung eines neuen Softwarepaketes in das Informationssystem, ein ge/inderter Taskflow bis hin zur Fusion zweier Unternehmen. Die Ausfiihrungen im Kapitel 6 werden jedoch zeigen, dass sich alle Integrationsprojekte auf der Informationssystemebene (auch die vonder Informatik getriebenen, wie die Einfiihmng des neuen Softwarepaketes) mit dem oder den zugrunde liegenden Prozess(en) auseinandersetzen miissen. Dieser Abschnitt beschreibt tiberblicksweise das Vorgehen der Systemintegration ab dem Zeitpunkt, zu dem ein Informations- und Integrationsbedarf vorliegt. Der Informationsbedarf ftihrt zu der Frage, welche Applikationen und Datensammlungen die geforderten Funktionen und Daten bereitstellen. Ausgehend von einem Informationsbedarf sind die folgenden vier Aufgaben zu durchlaufen: 9 Die Interaktionsanalyse (Abschnitt 6.4.2.1) engt den zu betrachtenden Ausschnitt des Informationssystems gem~iss dem vorliegenden Informationsbedarf ein. Sie identifiziert die zu integrierenden Anwendungen sowie die daraus resultierenden Integrationsbeziehungen. Die Interaktionsanalyse ist im Falle einer vorgelagerten Desktopintegration weitgehend tiberfltissig. In einem solchen Falle sind die dort erstellten Dokumente nur noch auf Vollst~indigkeit zu tiberprtifen. Alle folgenden Tatigkeiten sind ftir jede identifizierte Integrationsbeziehung zu durchlaufen. 9 Der Macroentwurfeiner Integrationsbeziehung (Abschnitt 6.4.2.2) stimmt fiir die Datenaustauschbeziehung die zugrunde liegenden Modelle der beteiligten Anwendungen aufeinander ab. Er definiert die Selektionskriterien der auszutauschenden Daten, die Abbildungsregeln zwischen den Modellen, diejenigen Methoden der Anwendungen, welche fiir die Integration eine Rolle spielen, und regelt die Verteilung redundanter Methoden. 9 Das Integrationsdesign (Abschnitt 6.4.2.3) berticksichtigt die Anforderungen des Informationsbedarfs, wie z.B. zeitliche Restriktionen, und die Gegebenheiten des Informationssystems insbesondere der Architektur und leitet daraus die ad/iquate Integrationsvariante ab. Daran anschliessend werden ein eventueller Middlewareeinsatz und die Architektur der Integration geplant. 9 Abschliessend definiert die Integrationsspezifikation (Abschnitt 6.4.2.4) die betrachtete Integrationsbeziehung im Detail. Das bedeutet, die Schnittstellen, die Datentransfers und die Datenaufbereitung werden spezifiziert. Abschliessend kiimmert sich diese Technik noch um die Konfiguration der eingesetzten Integrationstechnologie.

4.5 Systemintegration

143

Vorgehen in den vier Teilbereichen der Systemintegration

Die Abbildung 4.46 zeigt das Vorgehen der Systemintegration.

Liegt ein Informationsbedarf vor, l~isst sich dieser unter Umst~inden durch mehrere Anwendungen erffillen. Die Interaktionsanalyse hat deshalb vorrangig die in Frage kommenden Quellen ffir die Abdeckung des Informationsbedarfs zu identifizieren (sofem dies nicht bereits durch eine Desktopintegration vorab geschehen ist). Schon bei der Sammlung dieser Anwendungen findet eine grobe Vorselektion statt. Wenn beispielsweise technische Voraussetzungen, wie eine ausreichende Ver~gbarkeit der Daten, und inhaltliche Bedingungen, wie eine unzureichende Qualit~it der Daten, nicht er~llt sind, flihrt dies zu einer Aussonderung der Anwendung, ohne dass eine Detailanalyse erforderlich ist. Die verbleibenden Anwendungen zur Erfiillung des Informationsbedarfs werden nun im Detail beschrieben und analysiert, d.h. die endgt~ltige Selektion wird vorgenommen. Der gesamte Integrationsbereich bestehend aus zwei oder mehreren zu verbindenden Anwendungen liegt in Form eines Integrationsszenarios

144

4 Integrationsmodell

vor. Damit sind auch die im Folgenden umzusetzenden Integrationsbeziehungen (zwischen genau zwei Anwendungen) festgelegt. Bei einer Vielzahl von Integrationsbeziehungen oder komplexen Abh~ingigkeiten empfiehlt sich eine Teilung des Projektes. Diese erfolgt in der Bildung von Integrationsbereichen aus unterschiedlichen Sichtweisen. Alle weiteren Schritte beziehen sich auf eine Integrationsbeziehung und sind ftir jede der definierten Integrationsbeziehung durchzufiahren. Bei einer Interaktion zweier Anwendungen sind deren Modelle vorrangig aufeinander abzustimmen. Dabei spielt nicht nur die Syntax eine Rolle, von zentraler Bedeutung ist auch die Koordination der Inhalte (vgl. Abschnitt 3.1.2.5). Es muss sichergestellt sein, dass beide Integrationspartner das gleiche Verst~indnis der auszutauschenden Daten und/oder Funktionen haben. Dieses notwendige Mapping der Anwendungsmodelle erfolgt im Bereich Macroentwurfder Integrationsbeziehung. Er beschreibt die auszutauschenden Daten und die beteiligten Anwendungen hinreichend genau und gleicht die Modelle aufeinander ab. Erst nach erfolgtem Mapping der Applikations- und Datenmodelle k6nnen die zu selektierenden Daten und gegebenenfalls notwendige Konvertierungsregeln festgelegt werden. Nachdem das "Was" einer Integrationsbeziehung definiert ist- die beteiligten Anwendungen und die auszutauschenden Daten - stellt sich die Frage nach dem "Wie". Das Integrationsdesign wird von der vorliegenden Architektur des Informationssystems, bereits eingesetzter sowie am Markt verftigbarer Middleware und sonstiger technischer Rahmenbedingungen beeinflusst. Es legt die Variante der Systemintegration sowie die einzusetzende Middleware fest. Neben den eher technischen Aspekten spielen bei der Auswahl der Integrationsvariante und des Enablers auch inhaltliche und organisatorische Kriterien, wie beispielsweise zeitliche Restriktionen, eine Rolle. Die Integrationsspezifikation definiert im Detail die Integrationsbeziehung. Das Projektteam berticksichtigt alle technischen und organisatorischen Aspekte von Integrationsbeziehungen und spezifiziert die zu implementierenden Schnittstellen sowie die allenfalls notwendigen Datenaufbereitungen. Verantwortungen werden geregelt, Projektpl~ine fiir die Realisierung erstellt und die Dokumentation vorgenommen. Das hier nur relativ grob dargestellte Vorgehen ftir die Systemintegration wird im Abschnitt 6.4 im Detail dargestellt.

4.6 Zusammenhiinge der unterschiedlichen Formen Die bisherigen Ausfiihrungen haben die einzelnen Integrationstypen getrennt voneinander betrachtet. Wie die einzelnen Untervarianten der jeweiligen Integrationstypen voneinander abhangen oder welche Auswirkungen sie aufeinander haben, blieb weitgehend unbeachtet. Wtinschenswert ware ein Art Wirkungsnetz, das alle Varianten umfasst und deren Beziehungen und Auswirkungen aufzeigt. Ein solches Netz l~isst sich jedoch nicht fiir den allgemeingiiltigen Fall erstellen. Jede konzeptionelle Variante kann unterschiedlich technologisch imp-

4.7 Bedeutungvon Standards und Architekturenfar die Integration

145

lementiert werden. Ausserdem bestehen zwischen den einzelnen Varianten der Prozessintegration nicht zwingende Abhgngigkeiten zu den einzelnen Arten der Systemintegration. Aus diesem Grund lassen sich nur die folgenden generellen Aussagen treffen, alle weiteren Beziehungen oder Abhgngigkeiten zwischen den einzelnen Formen der Integration ergeben sich erst in konkreten Projektsituationen. 9

Die Prozessintegration setzt mindestens den gleichen Grad an Desktopintegration voraus. Werden die einzelnen Tasks innerhalb von Aktivitgten manuell bearbeitet, ist eine automatische Steuerung zwischen den Aktivitgten wenig sinnvoll. Dies wt~rde bedeuten, dass an den Schnittstellen der Aktivitgten jeweils eine elektronische Erfassung der relevanten Steuer- und Kontrolldaten stattfindet, so dass ein flexibler oder transaktionsorientierter Workflow funktionieren k6nnte.

9

Die Desktopintegration ben6tigt hgufig die Systemintegration. Sind zur Ausfahrung einer Aktivitgt mehrere Anwendungen erforderlich, ist eine Integration dieser im Sinne des adgquaten Datenaustausches sinnvoll. Nur bei Verwendung einer einzigen Anwendung erfolgt keine Systemintegration.

9

Die Varianten der Systemintegration spielen im Rahmen der Desktopintegration eine untergeordnete Rolle. Die Desktopintegration definiert keine direkten Anforderungen an die Art und Weise der Integration von Anwendungen. Welche Variante zu verwenden ist, hgngt vielmehr von der Situation im Informationssystem ab, d.h. welche Architekturen und Schnittstellen besitzen die betroffenen Anwendungen.

9

Der Gesch~iftsprozess ist die Basis aller Integrationsanstrengungen Alle Entscheidungen bzgl. Integrationsvarianten und -infrastruktur von jedem Integrationsprojekt massen den Gesch~iftsprozess als Ausgangspunkt der Untersuchungen verwenden.

4.7 Bedeutung von Standards und Architekturen fiir die Integration Die vorangehenden Ausfiihrungen zeigen, dass sich sowohl die Prozess- als auch die Systemintegration in der Regel mit der Verbindung von heterogenen Anwendungen befassen mtissen. Je geringer die vorliegende Heterogenit~it der beteiligten Applikationen und Datensammlungen ist, desto leichter und einfacher gestalten sich die Integrationsfragen. Eine klar definierte Architektur des Informationssystems und dessen Infrastruktur, seiner Komponenten und insbesondere der Integration hilft, die Unterschiede in den Anwendungen gering zu halten und somit die Integrationsaufw~inde zu reduzieren [vgl. Feurer et al. 2000; Gierhake 1998, S. 27f]. Der Einsatz von Standards sowohl bei der Entwicklung von Anwendungen als auch bei deren Kommunikation tr~igt ebenfalls zur Vereinfachung der Integrationsproblematik bei.

146

4 Integrationsmodell

Architekturen im Rahmen der Integration

Eine IS-Architektur bildet die logisch-konzeptionelle Struktur des Informationssystems ab und grenzt den Rahmen fiir die Entwicklung und Integration von Anwendungen ab [vgl. Bernus/Schmidt 1998; Fingar et al. 2000; Laartz et al. 2000; Sinz 1997; Tjiok 1996; Wall 1996]. Sie zeigt die Organisation, die Daten- und die Funktionskonventionen eines Bereichs auf und identifiziert die notwendigen Applikationen und Datensammlungen sowie deren Beziehungen untereinander. Wissenschaff und die Praxis haben sich schon seit langem mit der Definition, dem Zweck und dem Nutzen von Architekturen 1~auseinandergesetzt. [13sterle et al. 1992] sowie [Andersen Consulting 2000] fiihren z.B. folgende Grtinde flit die Entwicklung einer Architektur des Informationssystems auf: 9

Sie ist die Integrationsbasis fiir Applikationen.

9

Sie erh6ht die Planbarkeit der Systeme.

9

Sie erhSht die Transparenz der Systeme vor und nach der Entwicklung.

9

Sie erh6ht die Datenkonsistenz (und Datensicherheit) im Unternehmen.

9

Sie erm6glicht eine effiziente Funktionsbtindelung im Untemehmen.

9

Sie kann dazu beitragen, Gesch~iftspotentiale zu erkennen.

9

Sie erh6ht die Wartbarkeit der Systeme.

[Krcmar 1990] begrtindet die Notwendigkeit eines Generalbebauungsplanes mit den steigenden Anforderungen an die Leistungen eines Informationssystems. Trotz Vorteilen und Nutzen sind Architekturen des Informationssystems nicht weit verbreitet. Ein Grund ist ein fehlendes gemeinsames Begriffsverst~indnis, ein anderer die tiber Jahre hinweg verteilte Entwicklung der bestehenden Anwendungen. Unter dem Begriff IT-Architektur z.B. verstehen die Unternehmen unterschiedliche Inhalte. So gelten beispielsweise eine Liste yon "erlaubten" IT-Produkten, eine Liste formaler Standards oftener Systeme, eine Spezifikation der Funktionen und Schnittstellen der Teilkomponenten des Informationssystems sowie eine Reihe anderer Richtlinien als Architekturen [s. Schulte 1997, S. 6f]. [Brenner/P6rtig 1998, S. 31 ] bezeichnen dagegen die Angabe der gesamten Infrastruktur fiir den Betrieb der Anwendungen als Architektur. Die Vielfalt der Begriffsverst~indnisse und die selten erfolgreichen "reinen" Architekturprojekte in der Vergangenheit fiihrten zu einer Vemachl~issigung der Architekturfrage. Dies wiederum resultierte in Informationssystemen, deren Entwicklungen zu viel kostete, die schwer zu warten sind, unn6tige Redundanzen in Programmlogik und Daten aufweisen, eine niedrige Datenqualit~it vorweisen und oft mehr Hardware- und Netzressourcen verbrauchen als notwendig. Die Verwendung einer Produktliste ist hilfreich bei der Vermeidung von unn5tiger Vielfalt der eingesetzten Technologie, Schnittstellen, Protokollen und Produkten, kann aber die Vorteile einer gut ge,o Zur Ableitungdes Architekturbegriffessiehez.B. [Krcmar 1990].

4.7 Bedeutungvon Standards und Architekturenftir die Integration

147

planten Architektur der logischen wie physischen Verteilung der Daten und Funktionalit~t nicht erreichen. Ffir die Integration reicht eine Betrachtung der Architektur aus applikatorischer Sicht nicht aus. Organisatorische Aspekte wie die Verantwortungen mr einzelne Anwendungen oder Standortangaben sind ebenso einzubeziehen wie die technische Infrastruktur. Deshalb sollte sich eine Architektur aus mehreren Sichten zusammensetzen: der technischen, der applikatorischen sowie der organisatorischen Architektursicht (vgl. [Stephan 1998], Abb. 4.47). 9

Die t e c h n i s c h eS i c h t beschreibt vor allem die Komponenten der Infrastruktur und deren Beziehungen zueinander und konzentriert sich auf Plattformkomponenten, deren Funktionen, deren LAN- und WAN-Anbindungen und den zugeordneten Middleware- und Anwendungsdiensten. Von Auspr~gungen der Komponenten wird abstrahiert, nur die einzelnen Typen sind Bestandteil der Architektur.

9

Die a p p l i k a t o r i s c hAer c h i t e k t u r s i c hstellt t die Applikationen und Datensammlungen des Informationssystems und deren Beziehungen untereinander dar. Die Architektur der Anwendungen interessiert hier nicht, sie ist Bestandteil einer Microarchitektur.

9

Die o r g a n i s a t o r i s c hArchitektursicht e gibt den relevanten Ausschnitt der Organisation mr die betrachteten Anwendungen wieder.

IS Organisatorische Sicht % Funktional % Geographisch

/ Technische Sicht

% Applikationsdienste % Middlewaredienste % Plattformkomponente % Netzwerkkomponente

Applikatorische Sicht % Applikationen % Datensammlungen

A b b .4 . 4 7 :

S i c h t eeni n eIrS - A r c h i t e k t u r

Die Kombination der drei erl~uterten Sichten lassen je nach Interesse eine Darstellung unterschiedlicher Aspekte wie die Verteilung von Anwendungen auf Organisationseinheiten oder Standorten oder die Nutzung bestimmter Anwendungen zu. Somit zeichnet sich eine gute Architektur durch Vorgaben far die Trennung der Programmlogik und der Daten in einzelne Segmente sowie mr die physische Verteilung dieser Module auf Systemen aus [Schulte 1997].

148

4 Integrationsmodell

Die anzustrebende Architektur sollte sowohl Richtlinien ffir den Entwurf einzelner Anwendungen aufweisen als auch ffir den "Bebauungsplan" des gesamten Informationssystems. Dieser kann nicht detaillierte Vorgaben enthalten, sondern muss sich auf die Kommunikationsinfrastruktur, die Schnittstellen der Anwendungen und der gemeinsam genutzten Ressourcen konzentrieren [s. Schulte 1997, S. 8]. In diesem Verst~indnis kann von einer Integrationsarchitektur gesprochen werden. Verfolgt ein Unternehmen eine derartige Integrationsarchitektur, so erleichtern sich das Integrationsvorgehen und die Wartung der zahlreichen Schnittstellen erheblich. Die Architektur engt z.B. die zul~issigen Zugriffsm~glichkeiten auf Datensammlungen ein. Ebenso vereinfacht sich die Wahl der Middleware. Mit Hilfe einer Architektur schafft sich das Unternehmen einen Integrationsstandard, der alle Vorteile eines Standards mit sich bringt. Diese Integrationsarchitektur muss Teil der Architektur des Informationssystems sein, die den konzeptionellen Rahmen ffir die Entwicklung von Organisation, Applikationen und Datenbanken eines Unternehmens darstellt. Sie beschreibt den Sollzustand des Informationssystems.

Zusammenfassung: Die Definition, Umsetzung und Pflege einer Architektur des Informationssystems, welche sowohl Vorgaben ~ r die Architektur einzelner Anwendungen als auch fiar den gesamten Bebauungsplan sowie Integrationsregeln umfasst, erleichtert den Integrationsprozess. Die Architektur muss zudem neben technischen auch organisatorische und applikatorische Aspekte beinhalten.

Standards fiir die Integration Im Abschnitt 3.2.4 sind bereits die am Markt verfiigbaren Standards eingeftihrt worden. Im Folgenden werden deren Einfltisse auf die Integration naher betrachtet. Auf eine Herleitung des Begriffs Standard wird an dieser Stelle verzichtet. Es sei auf die Arbeit von [Meffert 1994] verwiesen. Unter dem Begriff Standard versteht die vorliegende Arbeit alle Spezifikationen bestimmter Produkte, Produktmerkmale, Systeme oder Systemmerkmale, die von einer Vielzahl von Anbietern wie auch Nachfragem akzeptiert bzw. unterstiitzt werden [vgl. Hahn/Lal3mann 1990; Kleinaltenkamp 1990]. Eine gemeinsame Nutzung von Standards fiihrt in der Regel zur Vereinfachung von Handlungen zwischen Akteuren bzw. zu einem einfacheren Austausch von Informationen und somit zur einfacheren Kommunikation [vgl. Buxmann 1998]. In Informationssystemen, die sich durch eine Vielzahl von heterogenen Rechnernetzen, Betriebssystemen, Benutzeroberfl~ichen und Anwendungssystemen auszeichnen, hilft die Verwendung von Standards zur Senkung von Kosten, indem der Informationsfluss verbessert wird - beispielsweise durch die Vermeidung von Medienbrtichen. Weiterhin beschleunigen sie den Integrationsprozess. Die Verwen-

4.7 Bedeutungvon Standards und Architekturenfor die Integration

149

dung von Standards bringt zudem den weiteren Vorteil, dass die Innovationsgeschwindigkeit des Informationstechnologie-Marktes besser beherrschbar wird. Mit der Verwendung von Standards kann ein Untemehmen auf die sehr kurzen Entwicklungszyklen neuer Technologien besser eingehen, der Einbezug neuer Technologien in das bestehende Informationssystem wird unterstt~tzt bzw. erleichtert. Neue Anwendungen lassen sich so schneller in das Informationssystem einfahren und integrieren. Der Einsatz von Standards kann jedoch auch zu einem Verlust von Individualit~it fahren [vgl. Buxmann 1998]. Die Verwendung von betriebswirtschaftlicher Standardanwendungssoftware beschr~inkt ein Untemehmen beispielsweise in der Gestaltung seiner Prozesse. Die zugekaufte Anwendung schreibt durch ihre Funktionalit~it und allenfalls vorhandener Referenzprozesse die Abl~iufe vor, an denen sich das Unternehmen bei der Prozessgestaltung in der Regel stark anlehnt. Andemfalls wfirde ein zu hoher Anpassungsaufwand bei der Implementierung und der sp~iteren Einfahrung neuer Releases entstehen. An dieser Stelle stellt sich die Frage, welche Standards in Informationssystemen zur Verbesserung der Integration fahren k6nnen. In diesem Rahmen kommen vor allem folgende Bereiche far den Einsatz von Standards in Frage: 9

Anwendungen Kommen im Informationssystem vorwiegend zugekaufte Standardl6sungen zum Einsatz, entledigt sich das Untemehmen der steten Weiterentwicklung und Wartung der Anwendungen. Voraussetzung hierfar ist die Existenz derartiger L6sungen. Legt das Untemehmen Wert auf Flexibilit~it der L6sung und passt es die Anwendung den eigenen Bedt~rfnissen an, gehen Vorteile der Standardisierung verloren. Durch das sog. Customizing von zugekauften L6sungen kann die Anwendung den Standardcharakter verlieren. Jede Einfahrung neuer Releases muss die Fortfahrung dieses Customizings sicherstellen. Ftir die Integration sind derartige Standardl6sungen nur dann vorteilhaft, wenn diese auch in gewissem Sinne standardisierte Schnittstellen anbieten. Die Schnittstellen mt~ssen den Zugriff auf die wesentliche Funktionalit~it der L6sung gew~ihrleisten und ausreichend genau dokumentiert sein. Insbesondere auch die Bedeutung der in der Schnittstelle zur Verffigung stehenden Daten und die Regeln far deren Verarbeitung mt~ssen klar umrissen sein.

9

Middleware Der Einsatz von Middleware (Abschnitt 6.2.4) erleichtert die Integration in heterogenen Informationssystemen. Sie zielt auf eine Art Standardisierung der Integration zwischen Anwendungen ab, indem sie diverse Dienste far die Kommunikation zwischen Anwendungen und far den Zugriff auf Daten oder Methoden der Anwendungen anbietet. Steuerungskomponenten wie Workflow-Managementsysteme bieten keine betriebswirtschaftliche Funktionalit~t an, weshalb sie zur Middlewareschicht gez~ihlt werden. 9

Kommunikation Ft~r die Anwendungsintegration spielen vor allem Kommunikationsstandards eine Rolle, da sich die Integration vor allem mit dem Austausch von Informationen befasst.

150

4 Integrationsmodell Kommunikationsprotokolle definieren unabh/ingig von konkreten Inhalten allgemeine Regeln fiir den Austausch von Informationen. Da fiber den ausgetauschten Inhalt keine Angaben gemacht werden, helfen die Kommunikationsstandards bei der Integrationsproblematik nur bedingt weiter. Derartige Standards untersttitzen das Mapping der Daten- und Applikationsmodelle nicht. Sie erleichtern lediglich den technologischen Austausch von Daten tiber heterogene Infrastrukturen und Formate hinweg. 9

Steuerungskomponente Will ein Untemehmen mehrere Steuerungskomponenten einsetzen, z.B. ftir jede Variante der Prozessintegration eine andere, muss es auf die Kompatibilitat dieser achten. Trotz der Arbeiten der WfMC (Workflow Management Coalition, Abschnitt 5.3.2) fehlt heute eine ausreichende Standardisierung der am Markt verfiigbaren Werkzeuge zur Ablaufsteuerung. Grund daftir sind zum einen die unterschiedlichen Philosophien der Werkzeuge und deren unterschiedliche Deutungen der Inhalte von Aktivit/iten oder Tasks. Die Interaktion von Steuerungskomponenten setzt nicht nur eine Abstimmung der Formate voraus, vielmehr ist wesentlich, dass auch ein identisches Verst~indnis tiber die zu steuemden Bausteine besteht. Dies k6nnen nur strikte Regelungen bei der Modellierung der Abl/~ufe sicherstellen. Einige der Steuerungskomponenten haben in ihrem Lieferumfang auch sog. Templates. Dies sind vorgefertigte Workflowbeschreibungen, welche noch individuellen Bedtirfnissen angepasst werden mtissen. Derartige Templates k6nnen den Modellierungsaufwand der Prozessintegration minimieren, jedoch nicht den notwendigen Aufwand fiir die Systemintegration. Sind Anwendungen zur Untersttitzung einzelner Aktivit~iten erforderlich, mtissen diese mittels Desktopintegration in den Ablauf eingebunden werden. Die Probleme der Systemintegration 16sen derartige Templates nicht.

9

Schnittstellen Im Bereich der Schnittstellen sind Standards /ihnlich den BAPIs (Business Application Programming Interface) von SAP m6glich. Es handelt sich dabei nicht nur um Schnittstellen auf systemtechnischer Ebene, sie sind vielmehr im betriebswirtschaftlichen Kontext verankert [vgl. Perez et al. 1998, S. 119ff]. BAPIs kapseln einen logischen Teil der Anwendungsfunktionalit/it, gehen somit tiber formale Regelungen hinaus und standardisieren auch in gewisser Weise den tiber diese Schnittstelle angebotenen Inhalt. Eine derartige Standardisierung im gesamten Informationssystem setzt voraus, dass alle notwendigen Daten und Aktionen auf den Daten bekannt sind und damit auch Vorgaben getroffen werden k6nnen. Ein derartiges Unterfangen 1/isst sich kaum tiber ein gesamtes Informationssystem hinweg durchsetzen. Jedoch ist eine Standardisierung der wesentlichen Daten und der wichtigsten Methoden in Verbindung mit den Gesch~iftsprozessen durchaus sinnvoll. Die Bemtihungen der OAG (Abschnitt 3.2.4.5) verfolgen dieses Ziel.

9

Infrastruktur Im Bereich der Infrastruktur l~isst sich am einfachsten eine Standardisierung im Informationssystem erreichen. Liegt eine homogene, und in diesem Sinne eine standardisierte

4.8 Zusammenfassung

151

Infrastruktur vor, kann die Integration technologische Hindernisse weitgehend ausschliessen. Die Schwierigkeiten und Probleme der Integration liegen jedoch h~iufig nicht in der Technologie, sondern vielmehr in der Heterogenit~it der beteiligten Modelle (Abschnitt 3.1.2.5), d.h. der Begriffsverst~indnisse und Bedeutung der Daten. Standards untersttitzen die Integration, jedoch unterschiedlich weit. Die Regelung der technologischen Komponenten kann nicht bei der Verbindung zweier Datenmodelle helfen. Hier wtirde nur eine Standardisierung der Inhalte und somit ein einziges zugrunde liegendes Datenmodell Abhilfe schaffen.

Zusammenfassung." Standards existieren heute in diversen Bereichen eines Informationssystems. Hat das Unternehmen die Architektur seines Informationssystems gem~iss den Erl~iuterungen des vorherigen Abschnitts vorgenommen und dort dem Einsatz von Standards ausreichend Beachtung geschenkt, kann der Integrationsaufwand reduziert werden. Vermeiden l~isst er sich nie, da ein gewisses Mass an Heterogenit~it auch in Zukunft bestehen bleiben wird und im Rahmen des Semantikproblems keine L6sungen in Sicht sind.

4.8 Zusammenfassung Dieser Abschnitt fasst die wesentlichen Aussagen des Integrationsmodells zusammen und zeigt die im Rahmen der Anwendungsintegration zu stellenden Fragen auf.

Integration ist eine Folge von Anforderungen aus den Geschdfisprozessen. Prozesse fordern eine reibungslose Untersttitzung bei der Abwicklung durch Anwendungen des Informationssystem. Diese Anforderungen fiihren zur Forderung nach der Verbindung bisher unabh~ingiger Anwendungen.

Das Integrationsmodell zeigt die Objekte der Integration. Im Rahmen dieser Arbeit befasst sich die Integration mit der Verbindung von Anwendungen und damit mit der Interaktion zwischen Applikationen Und Datensammlungen. Sie gestaltet den Middlewareeinsatz und nimmt das Schnittstellendesign vor.

Das Informationssystem und seine Komponenten bestimmen die MOglichkeiten der Integration. Je heterogener ein Informationssystem ist, desto schwieriger gestaltet sich die Interaktion zwischen den Anwendungen.

152

4 Integrationsmodell

Innerhalb des Informationssystems sind die Integrationstypen Prozess- und Systemintegration relevant, die jeweils in unterschiedlichen Varianten vorkommen k6nnen: 9

Die Prozessintegration regelt die Form der Ablaufsteuerung von Workflows. Sie umfasst als Sonderform auch die Desktopintegration, welche sich mit der Ablaufsteuerung von Taskflows auseinandersetzt. Als Varianten 1/~sst sie ad hoc, flexible und transaktionsorientierte Workflows zu.

9

Die Systemintegration regelt die Interaktion zwischen Anwendungen und verfolgt das Ziel eines konsistenten Datenhaushalts. Varianten der Systemintegration sind die manuelle Integration, Frontend-Integration, Datenintegration, Anwendungserweiterung, Methodenaufruf und die eigenst~indige Integrationsanwendung.

Eine klar definierte Architektur des Informationssystems erleichtert die Systemintegration. Die Architektur des Informationssystems sollte Angaben fiber die verwendete Kommunikationsinfrastruktur, tiber die Anwendungen und deren Beziehungen untereinander sowie tiber die Schnittstellen flir die Integration der Anwendungen beinhalten. Eine derartige Architektur grenzt die Vielfalt der eingesetzten Integrationsvarianten ein und sichert einen 13berblick tiber das gesamte Informationssystem.

Der Einsatz von Standards im lnformationssystem reduziert den lntegrationsaufwand, vermeidet ihnjedoch nicht. Standards helfen heute vor allem die technologische Vielfalt und deren Probleme zu begrenzen. Um die Integration ausreichend zu untersttitzen, w/~ren Standards auch auf logischer Ebene notwendig.

Prozessintegration, Desktop- und Systemintegration beeinflussen die Gestaltungsm6glichkeiten von Prozessen. Ist das Informationssystem zu komplex und heterogen, 1/~sst es h/iufig diverse Interaktionen zwischen Anwendungen nicht oder nur mit erheblichem Integrationsaufwand zu. Sind diese Interaktionen jedoch fl~r die Untersttitzung eins Prozesses relevant, 1/~sst sich dieser nicht in der gewtinschten Form realisieren. Im umgekehrten Fall erm6glicht die Integration bisher getrennter Anwendungen neuartige Prozessabl~iufe und gestaltet in diesem Sinne das Business. Die folgende Abbildung 4.48 listet die Fragen auf, welche der Business Engineer im Rahmen der Anwendungsintegration beantworten muss.

4.8 Zusammenfassung

153

Die folgenden Kapitel gehen vertieft auf die Prozess- und Systemintegration ein und helfen die aufgeffihrten Fragen zu beantworten.

5 Prozessintegration Die nachfolgenden Ausfahrungen gehen ngher auf die m6glichen Initiatoren von Projekten zur Prozessintegration ein (Abschnitt 5.1), beschreiben die Voraussetzungen far eine erfolgreiche Prozessintegration (Abschnitt 5.2), grenzen die unterschiedlichen Integrationsvarianten genauer ab, zeigen die Kriterien zur Wahl der entsprechenden Variante auf (Abschnitt 5.3) und beschreiben ausfahrlich das methodische Vorgehen far die Prozessintegration (Abschnitt

5.4). Die Abbildung 5.1 zeigt die Einordnung der Prozessintegration im Business Engineering nochmals auf.

5.1 AuslOser von Prozessintegration Unterschiedliche Projektsituationen k6nnen Anstrengungen zur Prozessintegration anstossen. Diese werden im Folgenden Driver der Prozessintegration genannt.

156

5 Prozessintegration

5.1.1 Prozessintegration als Folge der Prozessentwicklung Die Prozessentwicklung umfasst den Prozessentwurf in Projekten, die Implementierung neu gestalteter Prozesse sowie die kontinuierliche, fiihrungsgr6ssenbasierte Prozessfiihrung (s. Abschnitt 3.1.2.1). Ein Prozessentwurfsprojekt nimmt gr6ssere Anderungen eines Prozesses vor, w[ihrend kleinere Abweichungen von den vorgegebenen Ftihrungsgr6ssen zu Massnahmen im Rahmen der Prozessfiihrung ~hren. Erfolgte ein Total-Review, muss die Prozessumsetzung die anschliessende Implementierung des neu definierten Prozesses tibernehmen. Im Rahmen solcher Umsetzungsprojekte sind sowohl die Prozess- als auch die Systemintegration zu spezifizieren und zu implementieren. Entdeckt die Prozessfiihrung Abweichungen von den definierten Fiihrungsgr6ssen, leitet sie Massnahmen zur Weiterentwicklung des Prozesses ab. Hierzu z~ihlen alle Auftr/ige zur Prozessver/indemng wie z.B. eine Amdemng der Ablaufsteuerung, die wiederum ein Prozessintegrationsprojekt ausl6st. Abbildung 5.2 zeigt den Zusammenhang zwischen Prozessentwicklung, Prozessentwurf, Prozessumsetzung, Prozessftihrung sowie der Prozess- und Systemintegration.

Zusammenfassend gibt es zwei Ausl6ser fiir die Prozessintegration: 9 Die Durchflihrung eines Prozessentwurfs ftihrt zur Prozessumsetzung, welche die Spezifikation der Prozess- und Systemintegration beinhaltet. 9 Die Prozessfiihrung kann aufgrund unzureichender Fiihrungsgr6ssen einen Auftrag zur ,~ndemng des Prozessablaufes oder zur Anderung der vorliegenden Ablaufsteuerung erteilen.

5.1 Ausl6seryon Prozessintegration

157

5.1.2 Prozessintegration als Folge technologischen Fortschritts Die Driver des vorangehenden Abschnitts sind der Prozessebene des Business Engineering Modells zuzuordnen. Anforderungen des Prozesses ~hren zu einer Andemng der Prozessintegration. Neben diesen Drivern der Prozessebene lassen sich auch Anst6sse aus der Informationssystemebene unterscheiden. Die Einfiihrung einer neuen Anwendung und die damit allenfalls verbundene Migration einer bestehenden Anwendung, eine neue Technologie am Markt sowie Verbessemngen yon bereits bestehenden Werkzeugen zur Prozessintegration k6nnen eine 0berprtifung der bereits implementierten Prozessintegration zur Folge haben. Die aufgefiihrten Driver mtissen nicht direkt zu einem Prozessintegrationsprojekt fiihren. So 16st beispielsweise die Einfiihrung einer betriebswirtschaftlichen Standardanwendungssofiware nicht direkt ein Oberdenken der Ablaufsteuemng des zugrundeliegenden Prozesses aus. Vielmehr st6sst dieser Fall in der Regel einen Prozessentwurf an, der den Prozess umgestaltet. Und erst im zweiten Schritt wird im Rahmen der Prozessumsetzung die Prozessintegration konzipiert und realisiert. Das gleiche triffl flit die Einfiihrung einer neuen Basistechnologie wie z.B. der Internet-Technologie zu. Eine neue Technologie erm6glicht unter Umst~inden neue oder anders gestaltete Prozesse im Untemehmen, die mit Hilfe eines Prozessentwurfs definiert und im Anschluss mit der Prozessumsetzung implementiert werden. Verbesserungen yon Werkzeugen zur Ablaufsteuerung oder ihre Einfiihrung in ein Unternehmen k6nnen dagegen direkt Bemtihungen im Rahmen der Prozessintegration ausl6sen. Ein Workflow-Managementsystem kann flit bereits bestehende Prozesse ohne lJberdenken deter Abl~iufe eingesetzt werden, wenngleich diese Variante nicht alle Verbessemngspotentiale aussch6pft. Empfohlen ist auch hier, den Prozess zu t~berdenken [vgl. Lehmann/Ortner 2000, S. 47]. Zusammenfassend zeigt die Abbildung 5.3 nochmals alle m6glichen Ausl6ser ~ r die Prozessintegration im Rahmen eines Wirkungsnetzes und ordnet sie im Business Engineering Modell ein. Die gestrichelten Kanten geben an, dass diese Vorgehensweisen m6glich, jedoch gem~ss den obigen Ausfiihrungen nicht empfehlenswert sind.

158

5 Prozessintegration

5.2 Voraussetzungen fiir die Prozessintegration Um Massnahmen flir die Steuerung eines Prozesses treffen zu k6nnen, mtissen gewisse Voraussetzungen erfi~llt sein (s. Abb. 5.4).

Der Prozess muss hinreichend bekannt und dokumentiert sein (Abschnitt 5.2.1). Das vorhandene Informationssystem kann Restriktionen fiir die Gestaltung der Prozessintegration stellen, weshalb auch eine Dokumentation des Informationssystems, zumindest des relevanten Teilbereichs, vorliegen muss (Abschnitt 5.2.2). Die Architektur des Informationssystems kann Einfluss auf die Gestaltung der Prozessintegration nehmen und muss deshalb vorab bekannt sein

5.2 Voraussetzungenfor die Prozessintegration

159

(Abschnitt 5.2.3). Zudem muss das Projektteam alle m6glichen Varianten der Prozessintegration und deren Auswirkungen im Detail kennen, um mr die gegebene Situation die richtige Variante auszuw~ihlen. Auf die Varianten geht Abschnitt 5.3 ein.

5.2.1 Prozessbeschreibung Die Aufgabe der Prozessintegration ist nicht der Entwurf eines Prozesses, sondern einzig der Entwurf und die Realisierung der Prozesssteuerung. Eine Beschreibung des zu betrachtenden Prozesses sollte deshalb in jedem Falle bereits vorliegen. Durch die breite Durchdringung der Unternehmen mit Business Process Reengineering (BPR) und der ISO 9000 Zertifizierung sind (zumindest) die Kemprozesse gut dokumentiert. Die Beschreibungen k6nnen sich jedoch je nach verwendeter Methode zum BPR unterscheiden. Hier sei auf die vorliegende Literatur verwiesen [Bach et al. 1995; Becker et al. 1999; Hagemeyer/Striemer 1998; Hess 1996; Schmidt 1998], der Abschnitt 4.3.2.1.1 zeigt die wesentlichen Unterschiede der Methoden mr den Prozessentwurf auf. Ftir die weiteren Ausmhrungen ist es ausreichend, nur die notwendigen Inhalte aus einer Prozessbeschreibung aufzuzeigen. Der vorliegende Beschreibungsansatz orientiert sich an der Methode PROMET| (s. Abschnitt 4.3.2.1.1). Aufgrund der Aufgabenstellung der Prozessintegration sind die Beschreibungen der Aufbauund insbesondere der Ablauforganisation mr den zu betrachtenden Prozess die zentralen Dokumente. Daneben k6nnen Angaben aus der Prozessmhrung, wie beispielsweise Prozessgrunds~itze und FtihrungsgrOssen, wichtige Hinweise fiir die Gestaltung der Prozessintegration liefern. In Anlehnung an PROMET| sollten folgende Dokumente mr den Prozess vorliegen: 9

Aufbauorganisation

9

Ftihrungsorganisation

9

Aufgabenkettendiagramm

9

Leistungsverzeichnis

9

Aufgabenverzeichnis

9

Prozessgrunds~itze

9

Berichtswesen Prozessmhrung

9

Prozesszerlegungsmatrix

9

Ftihrungsgr6ssen

Die folgenden Ausmhrungen beschreiben die wesentlichen Inhalte der aufgemhrten Dokumente.

Aufbauorganisation Die Realisierung der Prozessintegration ben6tigt neben der Beschreibung des Prozessablaufs auch eine stellenorientierte Sicht. Stellen sind die kleinsten organisatorischen Einheiten. Die

160

5 Prozessintegration

tiblichen Dokumente der Organisationslehre wie Funktionsdiagramm, Stellenbeschreibung und Organigramm sollten vorliegen.

Aufgabenkettendiagramm Das Aufgabenkettendiagramm dokumentiert den Prozessablauf (s. Abb. 5.5). Es gibt einen Uberblick tiber die Aufgaben und deren Ablauffolge, die Zuordnung der Aufgaben zu menschlichen und/oder maschinellen Aufgabentr~igem und den Umfang der Aufgabenuntersttitzung. Damit verbindet das Aufgabenkettendiagramm ablauf- und aufbauorganisatorische sowie informationssystemrelevante Aspekte eines Prozesses. Der Detaillierungsgrad kann sich je nach verwendeter Methode und nach Verwendungsgrad unterscheiden. Auf einer Makroebene verfolgt das Aufgabenkettendiagramm die Darstellung eines Gesamttiberblicks tiber den Prozess. Im Bereich der Mikromodellierung steht die Darstellung aller Aufgaben und ihrer personellen und technischen Untersttitzung im Mittelpunkt.

5.2 Voraussetzungenf'tirdie Prozessintegration

161

Ein Aufgabenkettendiagramm enth~ilt Knoten, Kanten und Spalten: 9

Knoten repr~isentieren Aufgaben des Prozesses. Ganz oder teilweise computerunterstiitzte Aufgaben sind hell unterlegt.

9

Kanten beschreiben die Ablauffolge der Aufgaben, d.h. deren zeitliche Abh~ingigkeiten. Eine gestrichelte Kante bedeutet, dass beide Aufgaben gemeinsam ausgefiihrt werden mt~ssen. Sind die Aufgaben mit einer gerichteten und gestrichelten Kante verbunden, kann die nachfolgende Aufgabe nur mit einem Zeitverzug nach Beendigung der ersten Aufgabe gestartet werden. Eine durchgezogene und gerichtete Kante bedeutet, dass nach Abschluss der ersten Aufgabe die zweite unverziiglich begonnen werden kann.

9

Spalten im Aufgabenkettendiagramm repr~isentieren Aufgabentr~iger.

Aufgabenverzeichnis Das Aufgabenverzeichnis erg~inzt das Aufgabenkettendiagramm um zus~tzliche Angaben zu den enthaltenen Aufgaben. Je Aufgabe enth~lt es die betroffenen Organisationseinheit, eine verbale Beschreibung der Anforderungen an das Informationssystem und Angaben zum Mengenger~st der Aufgabe (z.B. H~iufigkeit pro Jahr oder den Zeitbedarf der Aufgabe).

Berichtswesen Prozessfiihrung Das Berichtswesen stellt sicher, dass die Ftihrungsgr6ssen kontinuierlich t~berwacht werden. Es dient als Frtihwamsystem und beschreibt die periodisch zu erstellenden Berichte, deren Termine, die einbezogenen Ftihrungsgr6ssen und die Empf'~inger der Berichte.

Fiihrungsgr~Jssen Ffihrungsgr6ssen sind Indikatoren fiir Effektivit~it und Effizienz eines Prozesses. Sie konkretisieren die kritischen Erfolgsfaktoren und teilen sich in zwei Gruppen auf: 9

Finanzielle Ftihrungsgr6ssen aus dem finanziellen Rechnungswesen.

9

Direkte Fiihrungsgr6ssen, die direkt beobachtbare Merkmale von Prozesskomponenten beschreiben.

Das Ftihrungsgr6ssenverzeichnis enth~ilt je GrOsse eine verbale Beschreibung und das zugrunde liegende Messverfahren

Fiihrungsorganisation Die F~hrungsorganisation beschreibt die aufbauorganisatorische Regelung fiir die Prozessfiihrung. Sie enth~lt Informationen tiber die Besetzung der Stellen fiir die Prozessfiihrung (Pro-

162

5 Prozessintegration

zessmanager, Prozesszirkel, Prozessausschuss [vgl. t3sterle 1995, S. 123ff])und deren wichtigsten Aufgaben.

Leistungsverzeichnis Das Leistungsverzeichnis listet alle vom Prozess konsumierten und produzierten Leistungen auf und enth~iltje Leistung eine verbale Beschreibung.

Prozessgrundsiitze Die Prozessgrunds~itze bilden die Eckpunkte des Prozesses, die im Detailentwurf zu beachten sin& Sie entstehen durch einen Abgleich von Strategie und Prozessvision und beschreiben sowohl die Rahmenbedingungen sowie die Gestaltungsmerkmale des Prozesses. Den einzelnen Grunds~itzen kSnnen Priorit[iten zugeordnet werden, die fiir die Dringlichkeit der abgeleiteten Massnahmen bestimmend sind.

Prozesszerlegungsmatrix Prozesse sind in der Regel komplexe umfangreiche Gebilde, die ftir Detailentscheidungen weiter zerlegt werden miissen. Ein Prozess besteht nach der Zerlegung aus mehreren, unabh[ingig voneinander ausfiihrbaren und in sich geschlossenen Teilprozessen. Die Zerlegung orientiert sich dabei vorwiegend an Leistungen. Kunde Kommunikation

c L.

/ Beratung Firmenoder Privatkunden

i'=

t

Auftragserfassung (5 Varianten)

x,, Auftragsbearbeitung

Abb. 5. 6." Beispiel einer Prozesszerlegungsmatrix

5.2 Voraussetzungenfar die Prozessintegration

163

Die Prozesszerlegungsmatrix zeigt je Teilprozess die zugeh6rigen Leistungen auf (s. Abb. 5.6).

5.2.2 Ist-Informationssystembeschreibung Das bestehende Informationssystem spielt bei der Umsetzung von Prozessen aus Grfinden des Investitionsschutzes, aus Risikovermeidung einer Neuentwicklung etc. eine tragende Rolle [vgl. auch Gassner 1996, S. l f; Inmon 2000; Morin 1999]. Vorhandene Anwendungen und auch Technologien setzen for die Prozessintegration h~iufig gewisse Restriktionen lest und sind deshalb zu berficksichtigen. Neben der Beachtung yon betrieblichen Anwendungen und Technologien nehmen bereits im Einsatz befindliche Werkzeuge zur Ablaufsteuemng wesentlichen Einfluss auf die Gestaltung neuer Prozesse und deren Steuerung. [East 1994] stellt eine fundierte Kenntnis des existierenden Informationssystems allen anderen Anstrengungen bei der Integration voran. Die Planung der Prozessintegration erfordert somit eine ausreichende Dokumentation des IstInformationssystems. Gmnds~itzlich verwendet die Prozessintegration die untemehmenseigene Dokumentation der Systeme. Muss diese nachtr~iglich erstellt werden, steht nicht eine Nachdokumentation des gesamten Informationssystems und seiner Komponenten im Vordergrund, sondem die Schaffung eines Oberblicks fiber die vorhandenen L6sungen. Eine solche 12Ibersicht fiber das Informationssystem muss alle fOr den Prozess relevanten Anwendungen erfassen und beschreiben sowie die Beziehungen zwischen den Anwendungen, insbesondere die Datenaustauschbeziehungen, ausreichend dokumentieren. Neben diesem Oberblick sind fOr die Planung der Prozessintegration auch die eingesetzten Technologien und Plattformen, sowie die Schnittstellen der beteiligten Anwendungen von Interesse. Die im Unternehmen eingesetzte Informationstechnologie setzt klare technische Rahmenbedingungen, die in der IT-Strategie verankert sind. Alle Massnahmen im Rahmen der Weiterentwicklung eines Informationssystems mfissen mit diesen Rahmenbedingungen abgestimmt sein und ihnen weitgehend entsprechen. Nur in Ausnahmef'dllen k6nnen Abweichungen yon der IT-Strategie erlaubt sein. Folgende Dokumente und Informationen sind wesentlich: 9

Applikationsszenario

9

Datentransferbeschreibung

9

Anwendungsverzeichnis

9

IT-Szenario

Die folgenden Aus~hrungen geben den erforderlichen Detaillierungsgrad dieser Dokumente einer Ist-Informationssystembeschreibung far die Prozessintegration an.

Applikationsszenario Ein Applikationsszenario fohrt alle relevanten Anwendungen (Applikationen und zugeh6rige Datensammlungen) in Form eines Oberblicks fiber die Anwendungsarchitektur auf. Da die

164

5 Prozessintegration

Relevanz einer Anwendung nicht sofort erkennbar ist, ist der Ausgangspunkt eine grobe Anwendungsarchitektur, die dann schrittweise verfeinert wird. Ein Applikationsszenario enth~ilt die Elemente Applikation, Datensammlung und Datentransfer [vgl. Derungs et al. 1996b, S. 153f]. Applikationen werden als Rechteck zusammen mit ihren Bezeichnem dargestellt. Datensammlungen werden als Ellipsen gezeichnet und mit der fiir sie verantwortlichen Applikation durch eine Kante verbunden. Tauschen zwei Anwendungen nach vereinbarten Regeln Daten untereinander aus, so beschreibt das Applikationsszenario dies mit einer Kante zwischen den beteiligten Applikationen versehen mit einer Nummer (Datentransfemummer). Zus~itzlich kann die Kante mit den wesentlichen auszutauschenden Daten beschriftet werden. Abbildung 5.7 zeigt ein Beispiel eines Applikationsszenarios.

ETBE~ i Ivan01

Aiike'i IMteria'l I

Abb. 5.7: Beispiel Applikationsszenario

Das von der Prozessintegration zu verwendende Applikationsszenario darf nicht nur die Situation von heute beschreiben. Es muss auf die realistische Situation zum Zeitpunkt der Einfiihrung der Ablaufsteuerung eingehen. Demnach muss es den Zustand beschreiben, der voraussichtlich for die Umsetzung und insbesondere Implementierung zur Verf0gung stehen wird. Es bildet somit weder den Ist- noch den Idealzustand im Sinne einer Sollarchitektur ab, sondem einen Zustand in sechs bis acht Monaten.

Anwendungsverzeichnis Die graphische Darstellung der Anwendungslandschaft in Form des Applikationsszenarios bietet einen Uberblick, kann jedoch nur wenig Informationen enthalten. Deshalb miissen Detailinformationen zu den Anwendungen gesondert festgehalten werden, in Form des An-

5.2 Voraussetzungenftir die Prozessintegration

165

wendungsverzeichnisses. Es enth~lt je Anwendung die zugeh6rigen Applikationen und je Applikation eine verbale Beschreibung der Funktionalit~t, die Angaben der zugrunde liegenden Plattform (Hardware- und Softwarevoraussetzungen der Anwendung), die Auflistung der zugeh6rigen Datensammlungen, die Angabe der Schnittstellen, die Beschreibung der Verteilung (zentral, dezentral) sowie den Verantwortlichen der Anwendung, der damit Ansprechpartner ft~r das Projektteam ist.

Datentransferbeschreibung Die Datentransferbeschreibung dokumentiert den Datenaustausch zwischen zwei Anwendungen des Applikationsszenarios. Sie besitzt in heterogenen Informationssystemen einen hohen Stellenwert, da das Verst~ndnis des Datentransfers t~ber Schnittstellen zentral mr die Integration von Anwendungen ist. Ffir die Prozessintegration reicht ein geringer Detaillierungsgrad der Datentransferbeschreibung aus. Im Bereich der Systemintegration beschreibt dieses Dokument weitaus mehr Elemente einer Datentransferbeziehung (Abschnitt 6.2.2).

Datentransfer:

Nr. 2: Telefonbucheintrag yon Kundenverwaltung zu ETB

Beschreibung: Der Redaktor des ETB erstellt die Telefonbucheintr~ge in der Kundenverwaltung. Kunden haben keinen direkten Zugriff auf die Kundenverwaltung, sondern auf die Anwendung ETB mit eigener Datensammlung. Bei ~,nderungen der EintNige in der Kundenverwaltung werden die Angaben automatisch 0ber einen Datentransfer im ETB aktualisiert. Art des Datentransfers: Batch, asynchron Periodizit~it/Ausl@ser: T~iglich, zwischen 01:00 und 03:00 Uhr Betroffene Applikationen: Yon: Kundenverwaltung Nach: ETB

Obernahmedaten: ETB-Eintrag Name oder Firma Beruf Rufnummer Strasse mit Nr. PLZ Ort Datum

Abb. 5.8." Beispiel Datentransferbeschreibung

Die Datentransferbeschreibung ber~cksichtigt im Rahmen der Prozessintegration eine verbale Beschreibung, welche in kurzer Form Auskunft fiber wesentliche Merkmale, Grund und Ab-

166

5 Prozessintegration

lauf des Datenaustausches gibt. Weiterhin gibt sie die Art der Datenkommunikation an. Die Art des Datentransfers gibt Auskunft, ob es sich um eine Batch- oder Online-Kommunikation handelt, ob eine Zwischenspeicherung notwendig ist und welcher Integrationsmechanismus zugrunde liegt. Das Element Periodizit/it der Datentransferbeschreibung gibt an, in welcher H/iufigkeit der Datenaustausch stattfindet und zu welchem Zeitpunkt oder welches Ereignis ihn ausl6st. Daneben liefert die Beschreibung noch die Informationen tiber die betroffenen Applikationen und die 0bemahmedaten. An dieser Stelle reicht die Angabe der auszutauschenden Datenelemente zusammen mit einer groben formalen Datenstruktur aus. Weitergehende Angaben wie z.B. Datentyp etc. sind hier nicht relevant. Abbildung 5.8 zeigt ein Beispiel einer Datentransferbeschreibung im Rahmen der Prozessintegration.

IT-Szenario

Das IT-Szenario beinhaltet die im Unternehmen zur Ver~gung stehende Informationstechnologie sowie die gem/~ss der IT-Strategie geplanten Weiterentwicklungen. Es spiegelt die technischen Gegebenheiten wider und enth/~lt die wesentlichen technischen Entscheide tiber Hardware- und Softwareplattformen, Anwendungssoftware, Middleware, Kommunikationsinfrastruktur, Entwicklungsplattformen, Methoden und Standards. Das IT-Szenario hat unternehmensweite Gtiltigkeit. Es soil jedoch nicht nur den aktuellen Zustand im Unternehmen aufzeigen, sondern auch die Entwicklungspfade gem/iss der IT-Strategie skizzieren. Empfohlen wird dabei eine Betrachtung des heutigen Zustands, des Zustands in drei Jahren und danach. Abbildung 5.9 zeigt ein Beispiel eines IT-Szenarios. 1998

2001

danach

9 B0ro

MS-Office

MS-Office

MS-Office

9 Terminalemulation

Rumba

Rumba

Rumba

I nformationstechnik

PC-Standardsoftware

PC-Hardware 9 Prozessor

Inte1486

Pentium II

often

9 Monitor

14'

21'

21'

9 Client

DOS/Windows, DEC/Unix

Windows NT

Windows NT

9 Server

Novell, SUN/Unix

Windows NT, SUN/Unix

Windows NT, SUN/Unix

Grossrechner

MVS (IBM)

MVS (IBM)

MVS (IBM)

9 Technologie

Token Ring 16 MBit/s

ATM 155 MBit/s

ATM

9 Kapazit~it Workflow-Managementsystem

Staffware

Staffware

Staffware

Betriebssystem

Netzwerk often

5.2 Voraussetzungenfiir die Prozessintegration Informationstechnik

167

1998

2001

danach

9 Transaktionsmonitor

CICS

CICS

ClCS

9 Messaging

MQSeries

MQSeries

MQSeries

9

OLE

OLE/CORBA

OLE/CORBA

Middleware

Objektverteilung

Datenbank

Oracle

Oracle

Oracle

CASE

ADW

ADW

ADW

Visual Age

Visual Age

GUI-Tool

A b b .5 . 9 . B e i s p i eI lT - S z e n a r i o

5 . 2 . 3 A r c h i t e k t udre r A n w e n d u n g e un n d d e r A k t i v i t ~ i t e n

Die vom Prozess zur Aufgabenerfiillung ben0tigten Anwendungen bestimmen das Mass an erforderlicher Integration und den zu tiitigenden Aufwand. Insbesondere die Architektur der Anwendungen nimmt Einfluss auf die M0glichkeiten der Integration. Bietet eine Anwendung beispielsweise keine Schnittstellen an, ist deren Integration erheblich aufwendiger als die Integration einer Anwendung mit standardisierten Schnittstellen. Das dieser Arbeit zugrunde liegende Begriffsverstiindnis einer Anwendung stellt eine Kapselung der Funktionalitiit und Daten mr einen gewissen Anwendungsbereich dar. Ahnlich dem Applikationsobjekt der OMG (Object Management Group) [OMG 1992, S. 62f] stellt die Anwendung tiber Schnittstellen Methoden und Daten nach aussen hin zur Ver~gung (s. auch Abschnitt 3.2.4.3). Eine solche Kapselung der Komponenten eines Informationssystems in autonome, voneinander beztiglich der Gestaltung unabhiingige Anwendungen zielt auf die Autonomie sowie auf eine schnelle Anpassungsf'~ihigkeit des gesamten Informationssystems auf ge~nderte Anforderungen ab [vgl. Gassner 1996, S. 97ff]. Die Prozessintegration geht yon solchen autonomen gekapselten Anwendungen aus und deftniert wiederum neue Komponenten in Form der Aktivit~iten, welche als Softwarebausteine yon der Steuerungskomponente koordiniert werden. Die Steuerungskomponente tuft entsprer dem Prozessverlauf tiber definierte Schnittstellen diese Bausteine auf, welche gem~iss der zugrunde liegenden Systemintegration wiederum unterschiedliche Anwendungen tiber Schnittstellen miteinander verkntipfen. Somit setzt die Prozessintegration in gewissem Sinne eine Architektur der Schnittstellen voraus. H~iufig zeigt sich jedoch ein anderes Erscheinungsbild des Informationssystems. Die Applikationen sind entweder autonom und bieten keinerlei Schnittstellen zu anderen Applikationen an, d.h. erforderliche Datentransfers mtissen manuell vorgenommen bzw. durch Neuentwicklung von Schnittstellen erst erm6glicht werden. Oder die Applikationen sind so stark miteinander verflochten, dass sie insgesamt als eine einzige grosse Anwendung aufzufassen sind [vgl. Brodie/Stonebraker 1995, S. 2ff]. In diesen F~illen mtissen die Komponenten nachtdiglich gekapselt werden (auch als Object Wrappping bezeichnet, [Dietrich et al. 1989]). Die

168

5 Prozessintegration

Problematik der Weiterentwicklung oder des Reengineerings eines Informationssystems in diesem Sinne ist nicht Gegenstand der vorliegenden Arbeit [vgl. Riehm 1997, S. 192ff]. Beispielhaf~ seien hier [Graham 1995; Jacobson 1992; K16sch/Gall 1995; Mattison/Sipolt 1994] genannt. Folgende Abbildung 5.10 zeigt zusammenfassend die Dokumente, welche mr ein Projekt der Prozessintegration vorab vorliegen mtissen.

5.3 Framework: Varianten der Prozessintegration Wie bereits im Abschnitt 4.4.1 kurz beschrieben, steht der Prozessintegration eine Reihe von unterschiedlichen Varianten ~ die Ablaufsteuerung zur Vermgung. Gem~iss dem vorliegenden Prozess muss im Rahmen der Prozessintegration die entsprechende Steuerungsvariante anhand ausgew~ihlter Kriterien gefunden werden, die darer geeigneten Arbeitspakete in Form von Aktivit~iten abgegrenzt und eine Entscheidung in Bezug auf die gewfinschte Realisierung der Steuerung getroffen werden. Der Abschnitt 5.3.1 beschreibt in diesem Sinne die m6glichen konzeptionellen Varianten, zeigt deren Vor- und Nachteile und daraus ableitend die Kriterien mr die Wahl einer Variante. Die konzeptionellen Varianten lassen sich in der Regel mit unterschiedlichen technologischen L6sungen implementieren, auf die Abschnitt 5.3.2 n~iher eingeht.

5.3.1 KonzeptionelleVarianten der Prozessintegration Jede der beschriebenen Steuerungsvarianten aus Abschnitt 4.4.1 zeichnet sich durch bestimmte Merkmale aus (s. Abb. 5.11) und ist mit einer Reihe von Vor- und Nachteilen versehen, deren Analyse im konkreten Projektfall zur Wahl einer bestimmten Variante mhren. Im Folgenden beziehen sich die Ausmhrungen nur noch auf die computeruntersttitzten Varianten

5.3 Framework:Varianten der Prozessintegration

169

der Prozessintegration, d.h. die Merkmale, Vor- und Nachteile der Zust~inde "ad hoc Workflow", "flexibler Workflow" und "transaktionsorientierter Workflow" werden erl~iutert. Ftir die Desktopintegration gelten die Aussagen analog.

Variante Ad hoc Workflow (Taskflow)

Beispiele StOrungsmanagement z.B. der SBB: Nach einem Stromausfall auf einem Streckenabschnitt muss derZugverkehr neu organisiert werden. Die elektronischen Hilfsmittel stehen dem Fahrdienstleiter zur Verf0gung. Er muss ihren Einsatz je nach Situation ad hoc koordinieren.

Merkmale 9 Aufgaben sowie Aufgabentr~ger des Ablaufs sind nicht vordefiniert. 9 Reihenfolge der Aufgabenabwicklung ist unbekannt. L(Ssungsweg der gesamten Aufgabenstellung ist often. 9 Benutzer {3bernimmt nach Aufgabenabwicklung die Steuerung des Ablaufs, er definiert Folgeaktivit~it und Aufgabentr~iger. Computerbasiertes Verzeichnis aller mOglichen Aufgaben und deren zugehOrigen Aufgabentr~iger existiert.

Flexibler Workflow (Taskflow)

Erstellung eines Briefes mit Zugriff auf Adressverwaltung und Ablage im Dokumentenmanagementsystem: Adresssuche und das Editieren des Briefes sind beliebig in der Reihenfolge. Einzig die Ablage kann erst nach der Fertigstellung des Briefes, d.h. der beiden anderen Aufgaben erfolgen. Ein Programm zeigt die jeweils noch auszufehrenden Aufgaben an und Gberpr0ft Abh~ingigkeiten.

9 Die Aktivit~ten des Workflows sind vorab bekannt. 9 Die Reihenfolge ist zumindest nicht g~nzlich starr festgelegt. 9 Abh~ngigkeiten einzelner Aufgaben werden computerbasiert verwaltet. 9 Definitive Reihenfolge der Aufgaben legt der Benutzer erst w~hrend der Abwicklung fest. 9 Computerbasierte Kontrolle der Aktivit~tenausf0hrung. 9 Computerbasierte Erstellung einer Liste der noch abzuwickelnden Aufgaben.

Transaktionsorientierter Workflow (Taskflow)

Kauf einer Bahnkarte am Automaten: Alle durchzuf0hrenden Aufgaben sind bekannt und die Anwendung steuert den Benutzer durch die einzelnen Schritte.

A bb. 5.11:

9 Die Aktivit~ten des Workflows sind vorab bekannt. 9 Die Reihenfolge der Aktivit~ten ist bekannt und starr modelliert. 9 Computerbasierte Steuerungskomponente 0bernimmt die Steuerung der Reihenfolge.

Charakteristika der Prozessintegrationsvarianten

Vor- und Nachteile der unterschiedlichen Varianten der Prozessintegration Aus den Merkmalen und Eigenschaften der drei Varianten bzw. Zust~inde lassen sich jeweils die Vor- bzw. Nachteile ableiten. So ~hrt ein unbekannter Ablauf zu dem Nachteil, dass der

170

5 Prozessintegration

Ablauf weder kontrolliert noch automatisch gefiihrt werden kann. Je Variante der Prozessintegration geben die folgenden Tabellen die jeweiligen Vor- und Nachteile an.

A d hoc Workflow (bzw. Taskflow) Vorteile

Nachteile

Kein "Zementieren" von Abl~iufen: Die fehlende Dokumentation des Prozessablaufs bei dieser Variante kann in dem Sinne als Vorteil interpretiert werden, dass alle Freiheiten bei der Abwicklung bestehen. 9 Wenig Implementierungsaufwand: Die Computerunterst0tzung liegt "nut" in der Verwaltung eines Verzeichnisses aller Aufgaben und deren Aufgabentr~gern. 9 Nicht alle m6glichen Zust~nde des Ablaufs m0ssen von Anfang an bekannt sein. 9 Schnelle Realisierung m6glich

Kenntnis des Prozessablaufs beim Benutzer: Diese Variante der Steuerung setzt eine gute Kenntnis der Mitarbeiter 0ber Prozessabl~iufe im Untemehmen voraus. 9 Vergessen von Aufgaben: Da keine Dokumentation aller notwendigen Aufgaben vorliegt, und der Benutzer for die Definition des Was und Wann verantwortlich ist, k6nnen Aktivit~ten vergessen werden. 9 Doppelarbeiten: Die Gefahr von Doppelspurigkeiten bei der Abwicklung ist bei manueller Definition der Aufgaben und deren Abarbeitungsfolge gegeben. 9 Keine automatischen Statusmeldungen: Dutch den unbekannten Verlauf des Workflows k6nnen keine Aussagen 0ber die noch verbleibende Zeit gemacht werden. Ausserdem m0ssen die Aufgabentr~ger eine Protokollierung des tats~ichlichen Verlaufs und somit die M6glichkeit zur Statusmeldung explizit in einem gesonderten Programm durchf0hren. 9 Keine automatische Kontrolle m6glich: Eine Kontrolle 0ber termingerechte Abwicklung oder 0ber vollst~ndige Aufgabenausf0hrung ist nicht m6glich, da sowohl die Aufgaben als auch deren Reihenfolge nicht bekannt sind.

Abb. 5.12:

Vor- und Nachteile Ad hoc Workflow (bzw. Taskflow)

Aus den Merkmalen sowie den Vor- und Nachteilen (Abb. 5.12) des ad hoc Workflows (bzw. Taskflows) lassen sich die folgenden Kriterien ftir den Einsatz dieser Variante der Prozessintegration ableiten: 9

Unbekannter Ablauf des Prozesses.

9

Hohes Mass an Entscheidungen innerhalb des Ablaufes, welche den Workflow beeinflussen.

9

Geringes Vorkommen gleichartiger Vorfglle, wiederholte Abwicklungen des gleichen Ablaufs sind nicht zu erwarten.

9

Hoher Zeitdruck beim Eintreffen eines neuen Vorgangs.

5.3 Framework:Varianten der Prozessintegration

9

171

Geringe Untersttitzung der Erffillung einzelner Aktivit~ten durch das Informationssystem

Flexibler Workflow (bzw. Taskflow) Vorteile

Nachteile

Leichtere Steuerung durch den Benutzer: Die computerbasierte Anzeige der noch ausstehenden Aufgaben sowie das Management der allf~lligen Abh~ngigkeiten erleichtern dem Mitarbeiter die Auswahl der Nachfolgeaktivit~iten. 9 Freiheiten bei den Mitarbeitern: Die flexible Aufgabenabwicklung gibt den Mitarbeitern mehr Selbstverantwortung. Sie kSnnen ihren Arbeitsvorrat selbst organisieren und gestalten. Das Gef0hl, ein Ausfehrungsorgan eines Programms zu sein, ist weniger stark.

9 Implementierungsaufwand: Je mehr Flexibilit~t gew0nscht ist, desto h(Sher f~llt u.U. der Implementierungsaufwand aus, da derzeit eine flexible Steuerung gleichbedeutend mit sehr viel Eigenentwicklung ist (mangels verf0gbarer Produkte). 9 Ineffiziente Prozessabwicklung: Die Flexibilit~t kann u.U. zu einer ineffizienten Reihenfolge der Aufgabenabwicklung f0hren.

9 Vollst~ndige Aufgabenabwicklung: Die Computerunterst0tzung stellt sicher, dass alle notwendigen Aufgaben abgewickelt werden. 9 Statusverfolgung mSglich: Eine Verwaltung der noch ausstehenden Aufgaben fi3hrt gleichzeitig den Zustand des Workflows aktuell mit. Somit lassen sich jederzeit Aussagen (3ber den Status machen. 9 Terminkontrolle: Neben der Kontrolle einer vollst~ndigen Abwicklung kann die Computerunterst0tzung durch die Kenntnis der noch ausstehenden Aufgaben eine Kontrolle ~3berdie Termineinhaltung vornehmen. 9 Schnelleres Einlernen neuer Mitarbeiter: Stehen den Mitarbeitern "Arbeitslisten" zur Verf0gung, m(Jssen sie im Gegensatz zum ad hoc Workflow nicht sofort das Gesamtunternehmen oder den Prozessablauf kennen, um bereits produktiv arbeiten zu k5nnen.

Abb. 5.13:

Vor- und Nachteile Flexibler Workflow (bzw. Taskflow)

FUr die Wahl eines flexiblen Workflows (bzw. Taskflows) sprechen folgende Kriterien: 9

Die Aktivit~ten des Workflows sind bekannt.

9

Mittleres bis hohes Aufkommen gleichartiger Vorf'~lle.

9

Kontrolle der Aus~hrungen (wie z.B. auf Vollst~ndigkeit, Statusverfolgung, Terminkontrolle usw.) steht im Mittelpunkt des Interesses.

172

5 Prozessintegration

Die Eigenverantwortung der Mitarbeiter fiber ihre Arbeitsorganisation soil beibehalten werden. Das Informationssystem untersttitzt die Erftillung der einzelnen Aktivit~iten in hohem Masse. Manuelle Arbeitsschritte kdSnnen vorkommen.

Transaktionsorientierter Workflow (bzw. Taskflow) Vorteile

Nachteile

Vollst,~ndige Abwicklung: Die Steuerungskomponente stellt sicher, dass alle Aufgaben in der richtigen Reihenfolge abgewickelt werden. Nichts wird vergessen. 9 Statusverfolgung m5glich: Die Steuerungskomponente kennt durch Protokollierung aller Aufgaben zu jeder Zeit den Status des Workflows. Somit lassen sich jederzeit Informationen 0ber den Status liefern. 9 Terminkontrolle: Neben der Kontrolle einer vollst~ndigen Abwicklung kann die Steuerungskomponente durch die Kenntnis der noch ausstehenden Aufgaben eine Kontrolle 0ber die Termineinhaltung vornehmen. 9 Zuverl~issigkeit der Steuerung: Der modellierte Prozess wird immer identisch abgewickelt. 9 Kein Erlernen des Prozesses notwendig: Die Mitarbeiter mOssen keinerlei Kenntnis 0ber den gesamten Prozess besitzen, sie werden vonder Steuerung geleitet.

A bb. 5.14:

Wenig bis keine Flexibilit~t in der Abwicklung: Die Steuerung I~isst keine ge~nderten AbI~iufe zu, es sei denn diese sind ebenfalls modelliert und implementiert. 9 Hoher Implementierungsaufwand: Der Workflow muss im Detail spezifiziert und die Aktivit~ten als Programmbausteine verfQgbar sein. 9 Hohe Integrationsanforderungen an bestehende Anwendungen: Eine automatische Steuerung ist nur dann m(Sglich, wenn der Prozess weitgehend elektronisch unterstOtzt abl~uft. In der Regel sind dadurch mehrere Anwendungen des Informationssystems betroffen, die es zu integrieren gilt. 9 "Zementieren" der Abl~iufe: Die heute verf0gbaren Produkte zur automatischen Steuerung und der hohe Implementierungsaufwand lassen zu wenig Flexibilit~t f0r eine ,~,nderung eines definierten Ablaufs zu.

Vor- und Nachteile Transaktionsorientierter Workflow (bzw. Taskflow)

Folgende Kriterien sprechen demzufolge fiir einen transaktionsorientierten Workflow (bzw. Taskflow): 9

Die Aktivit~iten und der Verlauf des Workflows sind bekannt.

9

Hohes Aufkommen gleichartiger Vorf~ille.

9

Der Ablaufunterliegt seltenen ,~nderungen.

9

Steuerung der Ausfiihrungen steht im Mittelpunkt des Interesses.

9

Das Informationssystem untersttRzt die Erfiillung aller Aktivitaten in hohem Masse.

9

Hohe Integrationsf'~ihigkeit des Informationssystems.

5.3 Framework:Varianten der Prozessintegration

173

KombinationsmOglichkeiten zwischen den Zust~inden der Prozess- und der Desktopintegration Neben der isolierten Betrachtung der einzelnen Steuemngsvarianten ist zu untersuchen, inwieweit sich die einzelnen Varianten der Prozess- und Desktopintegration miteinander kombinieren lassen. So ist es wenig sinnvoll, einen transaktionsorientierten Workflow aus Aktivit~iten mit einem ad hoc Taskflow zusammenzusetzen. Sind die einzelnen Tasks innerhalb einer Aktivit~it weder bekannt noch computeruntersttitzt, so sind die Aktivit~iten an ihren Schnittstellen zur tibergeordneten Workflowsteuerung ebenfalls nicht bekannt. Die folgende Matrix zeigt die m6glichen Kombinationen der Desktop- und Prozessintegration (Abb. 5.15). Ein Eintrag bedeutet, dass die Kombination m6glich ist; die Gr6sse des Kreises gibt Auskunft tiber den Beitrag zur Steigemng der effizienten Workflowabwicklung.

Varianten der Prozessintegration Varianten der Desktopintegration

Ad hoc Workflow

Flexibler Workflow

Transaktionsorientierter Workflow

Ad hoc Taskflow

0

Flexibler Taskflow

0

0

O

Transaktionsorientierter Taskflow

0

0

O

Abb. 5.15:

Kombinationsm6glichkeiten der Prozess- und Desktopintegration

Auswahlkriterien fiir die Varianten Aus den Merkmalen der einzelnen Varianten sowie deren Vor- und Nachteile ergeben sich direkt die Kriterien mr die Wahl, weshalb auf eine AusRihrung an dieser Stelle verzichtet wird. Der zu untersttitzende Prozess wird auf die Eigenschaften Bekanntheitsgrad des Ablaufs, Regelm~issigkeit des Ablaufs etc. untersucht und den Merkmalen der einzelnen Varianten gegentiber gestellt. Darfiber hinaus sind allgemeine Kriterien wie die Wirtschaftlichkeit der L6sungen und die Anforderungen aus dem Prozessentwurf oder der Strategieebene in den Auswahlprozess mit einzubeziehen.

5.3.2 Implementierungsvarianten der Prozessintegration Nach der Wahl einer Steuemngsvariante - sowohl fiir den Workflow als auch den Taskflow stehen den Projektverantwortlichen in der Regel eine Auswahl yon Implementierungsm/3glichkeiten zur VerV0gung.

174

5 Prozessintegration

Nachfolgende Ausftihrungen beschreiben vorrangig die Anforderungen an Werkzeuge zur Ablaufsteuerung eines Workflows (s. Abschnitt 5.3.2.1), bevor sie auf die Implementierungsm6glichkeiten zur Steuerung eingehen und die jeweiligen Kriterien aufftihren, welche mr die eine oder andere Variante sprechen. Die Kriterien k6nnen nur Hilfestellung bei der Wahl der entsprechenden L6sungsvariante geben. Der Entscheid beruht nicht nur auf funktionalen und technologischen Anforderungen, sondem vor allem auch auf einer Wirtschaftlichkeitsrechnung. Auf aggregierter Ebene lassen sich zwei unterschiedliche L6sungsans~itze differenzieren: 9

Im autonomen Ansatz (auch Modular Approach [vgl. Marshak 1994, S. 18f]) stellt die Steuerungskomponente eine eigenst~indige Anwendung dar (s. Abschnitt 5.3.2.2).

9 Beim integrierten Ansatz (auch Embedded Workflow [vlg. Stark/Lachal 1995, S. 75f]) dagegen ist die Steuerungskomponente Teil einer tibergeordneten betrieblichen Anwendung (s. Abschnitt 5.3.2.3). Abbildung 5.16 zeigt die beiden unterschiedlichen Architekturen. Der abschliessende Abschnitt 5.3.2.4 stellt die beiden Ans~itze einander gegentiber.

5.3.2.1 Anforderungen an Steuerungskomponenten Die Computerunterstiitzung der Ablaufsteuerung hat einer Reihe von funktionalen Modellierungs- und Integrationsanforderungen zu gentigen. Die nachfolgend aufgeftihrten Anforderungen sind aus einer Auswahl von Anforderungskatalogen fftir Workflow-Managementsysteme und Groupwaresysteme sowie von Marktstudien fiber Workflow-Managementsysteme abgeleitet [vgl. z.B. Derungs et al. 1995b; Erdl/Sch6necker 1995; Krickl 1995; Lippold et al. 1993; Oberweis 1996; Vogler 1993; Wersch 1995]. Die entstandene Liste der Anforderungen kann nicht mit einem allgemein giiltigen Anforderungskatalog fftir die Ablaufsteuerung gleichgesetzt werden, da sie nicht den Anspruch auf Vollst~indigkeit erhebt, sondem vielmehr die wesentlichen Anforderungen nennt. Zum Beispiel sind in der Aufz~ihlung keinerlei Angaben fiber die Eigenschaften des Anbieters enthalten, die bei einer konkreten Evaluation von Softwareprodukten eine bedeutende Rolle spielen. Jedes Untemehmen muss sich aus den fol-

5.3 Framework:Variantender Prozessintegration

175

genden Angaben und der vertiefenden Literatur seinen unternehmens- bzw. projektspezifischen Anforderungskatalog erstellen. 9

Planung und Modellierung eines Workflows Aufgrund der unterschiedlichen Strukturierungsgrade von Prozessen und Workflows kann keine vollst~indige Repr~isentation aller denkbaren Prozesse eines Unternehmens in Form von Workflows gefordert werden. Die Steuerungskomponente soll jedoch die standardisierten und teilweise auch die flexiblen Abl~iufe modellieren und steuern k6nnen. Bereits bei der Spezifikation muss ein Workflow auf Fehler hinsichtlich eines konsistenten Ablaufs untersucht werden. Der Workflow muss in jedem Task eindeutig definiert sein, darf sich nicht verklemmen oder in Schleifen geraten. Weiterhin muss sichergestellt sein, dass jede Aktivit~it und jeder Task zumindest theoretisch ausffihrbar ist. Jeder Workflow muss zu einem definierten Ende kommen.

9

Adaptionsf~ihigkeit Der st~indige Wandel der Wirtschaft zwingt die Unternehmen, sich fortlaufenden Anderungen zu unterwerfen. Die Ablaufsteuerung muss in der Lage sein, diesen steten Wandel rasch in modifizierte Abl~ufe umzusetzen. Organisatorische Anderungen, sowohl der Aufbau- als auch der Ablauforganisation, mtissen leicht und schnell umsetzbar sein. Dabei mtissen sowohl permanente als auch tempor~ire Anderungen sowie Eingriffe in bereits laufende Workflows m6glich sein. In diesem Zusammenhang muss zur Vermeidung von Inkonsistenzen festgelegt werden, unter welchen Umst~inden eine Anderung einer Workflowspezifikation erlaubt ist, vonder sich bereits mehrere Workflows in Bearbeitung befinden.

9

Ausfiihrbarkeit, Initiieren von Workflows Die Steuerungskomponente muss sicherstellen, dass der Anstoss (die initiale Aktion) eines Workflows jederzeit ausffihrbar ist. Neben dem Initiieren durch einen Benutzer sollen Workflows auch mit Hilfe yon Ereignissen oder Triggern gestartet werden k6nnen.

9

Durchlaufsteuerung Hauptanforderung an eine Steuerungskomponente ist die ad~iquate Weitergabe eines Workflows innerhalb eines Unternehmens gem~iss der Ablaufspezifikation.

9

Flexibilit~it der Steuerung; Ausnahmebehandlung Die Ablaufsteuerung muss in der Lage sein, den einzelnen Bearbeitern einen gewissen Handlungsspielraum zu lassen. Ein solcher wird notwendig, wenn beispielsweise unvorhergesehene Ereignisse und Besonderheiten im Ablauf eintreten, die bei der Modellierung des Ablaufes noch nicht oder nut unzureichend berficksichtigt wurden. Der Handlungsspielraum muss sich auf die Kompetenz des Bearbeiters einstellen lassen, denn ein zu gross oder zu klein gew~ihlter Freiraum kann negativen Einfluss auf die Arbeitszufriedenheit aust~ben [vgl. Nippa 1988, S. 130ff].

176 9

5 Prozessintegration Wiedervorlage und Abbruch der Abwicklung Neben der Behandlung von Ausnahmesituationen, die ein 0berspringen oder Rticksetzen von Aktivit~iten erforderlich machen kSnnen, muss die Ablaufsteuerung auch eine Unterbrechung der Workflowbearbeitung erm5glichen. Neben einer kurzfristigen Unterbrechung sollten auch langfristige mit Wiedervorlageverwaltung mtiglich sein. Extremsituationen kSnnen auch einen Abbruch des gesamten Workflows notwendig machen. Die erforderlichen Massnahmen ~ r das Rticksetzen der bereits erfolgten Anderungen im Datenhaushalt des Informationssystems sollten von der Steuerungskomponente zumindest veranlasst, bestenfalls ausgeffihrt werden.

9

Integration von Anwendungen Ftir die AusRihrung der Aktivit~ten sind in der Regel mehrere betriebliche Anwendungen notwendig. Der Zugriff auf diese muss aus der Ablaufsteuerung heraus mfiglich sein, d.h. die Steuerungskomponente muss betriebliche Anwendungen integrieren k6nnen. Neben der Integration von betrieblichen Anwendungen kann auch die Integration von Spezialwerkzeugen oder Organisationswerkzeugen notwendig werden. Zum ersten Fall gehSren beispielsweise Werkzeuge Rir die Modellierung oder das Monitoring von Workflows. Die zweite Integration ist notwendig, wenn bereits die Aufbauorganisation zusammen mit allen Zugriffsberechtigungen in einem Organisationswerkzeug abgelegt ist.

9

Trennung des Datenflusses vom Kontroll- und Steuerfluss Der Informationsfluss entlang eines Workflows unterteilt sich in Kontroll- und Steuerdatenfluss sowie den eigentlichen Datenfluss. Die Kontroll- und Steuerdaten sind die zentralen Informationen der Ablaufsteuerung und werden deshalb auch von ihr verwaltet. Die Gesch~iftsdaten dagegen befinden sich in betrieblichen Anwendungen des Informationssystems und werden dort verwaltet. Das Anlegen einer Workflowakte, die alle anfallenden Daten innerhalb der Bearbeitung enth~ilt, Rihrt zu einer redundanten Datenhaltung und sollte deshalb vermieden werden. Die Steuerungskomponente soil nur die Kontroll- und Steuerdaten Rihren, welche sich aus Schltisselattributen zusammensetzen, wahrend die Gesch~iftsdaten in den betrieblichen Datensammlungen verbleiben und dort mit den jeweiligen Applikationen bearbeitet werden.

9

Zuordnung der Aktivit~iten zu konkreten Bearbeitem fiber ein Stellenkonzept Die Ablaufsteuerung weist die einzelnen Aktivit~iten eines Workflows nicht direkt konkreten Benutzern zu. Die Zuordnung erfolgt fiber ein sogenanntes Stellenkonzept (s. Abschnitt 4.2.1.1), um gr6ssere Flexibilit~it zu erreichen. Im Rahmen der Zuteilung einer Aktivit~it zu den ad~iquaten Arbeitsvorr~iten muss auch die Stellvertreterregelung beriicksichtigt werden. In den Fallen von l~ingerer Abwesenheit, z.B. Urlaub oder Konferenzteilnahme, muss ein Mitarbeiter seinen Arbeitsvorrat an seinen Stellvertreter weiterleiten k6nnen. Die Stellvertreterregelung muss deshalb im Stellenkonzept enthalten sein.

5.3 Framework:Varianten der Prozessintegration

9

177

Zugriffsberechtigung und Authentifikation Die Spezifikation von Workflows legt die Zugriffsberechtigungen far die Ausfahrung fest. So regelt sie die Berechtigungen far das Initiieren yon Workflows und far die Ausfahrung yon Aktivitgten. Die Ablaufsteuerung muss das Authentifikationsproblem adgquat behandeln. Zum einen miissen identitgtsbestimmende Merkmale eines Benutzerswie Unterschriften - durch ein Passwortsystem sicher und zuverlgssig ersetzt werden. Zum anderen sind Zugriffskontrollen notwendig, die den Arbeitsplatzwechsel, Stellvertreter- und Urlaubsregelungen berficksichtigen.

9

Arbeitsvorratverwaltung Unter Arbeitsvorratverwaltung ist die Verwaltung der anstehenden Aktivitgten eines Benutzers zu verstehen. Folgende Funktionen mfissen dem Benutzer zur Verfagung stehen: er kann Prioritgten vergeben, sich den gesamten Arbeitsvorrat nach unterschiedlichen Sortierkriterien anzeigen lassen, einzelne Aktivitgten weiterleiten, sich den Status jedes involvierten Workflow anzeigen lassen und aus der Liste beliebige Aktivitgten auswghlen. Die Arbeitsvorratverwaltung muss auch das Eintreffen neuer Aktivitgten oder das Eintreten eines Wiedervorlagetermins dem Benutzer signalisieren. Bei der Zuordnung der Aktivitgten zu Bearbeitern soll die Ablaufsteuerung nach den Richtlinien eines Ressourcenmanagements vorgehen. Eine kapazitgtsgerechte Belastung der einzelnen Stellen und Stelleninhaber ist das Ziel. Infolge von Krankheitsfgllen kann sich eine ungleichmgssige Verteilung der Arbeitslast ergeben. Deshalb mtissen berechtigte Person wie z.B. Vorgesetzte ebenfalls in die Arbeitslisten der Mitarbeiter einsehen und gewisse Funktionen austiben k6nnen.

9

Ablaufkontrolle Die Ablaufsteuerung sollte auch eine Ablaufkontrolle beinhalten. Diese fibemimmt wghrend der Workflowbearbeitung alle Kontrollaufgaben, wie die Unterrichtung des Benutzers t~ber den aktuellen Bearbeitungsstatus und den bisherigen Workflowverlauf sowie eine Terminkontrolle. Mit Hilfe der Terminfiberwachung soll die Einhaltung gegebener Fristen kontrolliert werden.

9

Monitoring Alle Handlungen innerhalb der Bearbeitung yon Workflows mfissen protokolliert werden, soll eine Statusverfolgung, ein Rticksetzen der Bearbeitung und eine Prozessfahrung im Sinne des Business Engineering erm6glicht werden.

Abbildung 5.17 zeigt zusammenfassend die angefahrten Anforderungen an Steuerungskomponenten. Ein vollstgndiger Kriterienkatalog far Workflow-Managementsysteme ist beispielsweise enthalten in [Derungs et al. 1995b].

178

5 Prozessintegration Funktionen von S t e u e r u n g s k o m p o n e n t e n

9 Planung und Modellierung von Workflows 9 Adaptionsf~higkeit 9 Ausf0hrbarkeit, Initiieren von Workflows 9 Durchlaufsteuerung 9 Ablaufkontrolle 9 Flexibilit~t

9 Wiedervorlage und Vorgangsabbruch 9 Integrationsf~ihigkeit von Anwendung 9 Trennung des Daten- vom Kontroll- und Steuerfluss 9 Zuordnung der Aktivit~iten zu konkreten Aufgabentr~igern 9 Zugriffsberechtigungen und Authentifikation 9 Arbeitsvorratverwaltung 9 Monitoring

Abb. 5 . 1 7 :

Anforderungen an Steuerungskomponenten

5.3.2.2 Autonome Steuerungssoftware Der Wunsch nach einer Untersttitzung der Ablaufsteuerung Rihrte schon in den 80er Jahren zur Entwicklung von eigenst~indiger Steuerungssoftware [vgl. z.B. Karcher 1989; Ruisinger 1989]. Heute stehen hierRir am Markt unterschiedliche Workflow-Managementsysteme und Groupware-Tools zur Verfi~gung. Neben den bereits vorgefertigten Steuerungskomponenten steht dem Unternehmen zudem noch die M6glichkeit einer Eigenentwicklung often. Das interdisziplin~ire Forschungsgebiet "Computer Supported Cooperative Work" (CSCW) untersucht die Kooperationen zwischen Menschen und deren UnterstOtzung durch computerbasierte Anwendungen. Es er6rtert unterschiedliche Kooperationsformen hinsichtlich der zeitlichen und r~iumlichen Verteilung der Zusammenarbeit (vgl. Raum-Zeit-Matrix nach [Johansen 1988, S. 13ffl) sowie die Zusammensetzung der Kooperationspartner und deren Zielsetzung [vgl. Grudin 1994, S. 24f; Palmer/Fields 1994; Spurr et al. 1994] Die Werkzeuge und Hilfsmittel zur Unterst0tzung der Kooperation innerhalb von Teams werden als Groupware bezeichnet [s. Burger 1997, S. 7]. Es handelt sich dabei in der Regel um verteilte Anwendungen, die entweder einzelne Aspekte oder den gesamten Verlauf von Kooperationen unterstiitzen. Um die Vielfalt der verRigbaren L6sungen klassifizieren zu k6nnen, wird h~iufig der Grad der Unterst0tzung der drei Nutzungsformen informations-, ablauf- oder strategieorientiert herangezogen. Es entstehen dabei die Kategorien der Kommunikations-, Koordinationsund KooperationsunterstiJtzung [s. Teufel et al. 1995, S. 27ffJ. Diese Einteilung ist konform mit der Aufteilung durch [Kirsche 1994], der unter Koordination reine Mechanismen zur Planung von kooperativen Aktivit~iten zusammenfasst und unter Kooperation Strategien zusammen~hrt, die den Einsatz der Koordinationsmechanismen steuern. Die folgende Abbildung

5.3 Framework:Variantender Prozessintegration

179

5.18 zeigt die Einordnung von Groupware nach diesen Kriterien. Eine detaillierte Erkl~irung ist in [Teufel et al. 1995] zu finden. Kommunikations-

\ /

/ / Workflowa k . , , / / verteilte / / ~ \ / / Managemenl/k~ Hypertext- / Gruppen---'~,," / / systeme//~ editoren \ Planungs- Entscheidungs~ ~ "~s.ysteme unierstotzungs-J ~ system~

KoordinationsunterstOtzung Abb. 5.18..

Kooperationsunterst~itzung Klassifikation von Groupware [nach Teufel et al. 1995, S. 27]

Workflow-Management, ein Teilbereich innerhalb der CSCW-Forschung, hilft haupts~ichlich bei der Koordination von Arbeitsgruppen [vgl. Teufel et al. 1995, S. 40f]. Workflow-Managementsysteme untersttitzen die zeitlich versetzte (asynchrone) Kommunikation zwischen r~umlich entfernten Bearbeitern und bilden vor allem dauerhafte, im Rahmen von organisatorischen Regelungen festgelegte Kommunikationsbeziehungen und Entscheidungskompetenzen ab [s. Galler/Scheer 1994, S. 4; Hasenkamp/Syring 1993, S. 407]. Somit sind WorkflowManagementsysteme die geeigneten Werkzeuge far die Steuerung von Abl~iufen. Aus diesem Grund beschr~inken sich die weiteren Ausfahrungen zur Untersttitzung der Ablaufsteuerung von Prozessen auf die Workflow-Managementsysteme. Die Aussagen lassen sich leicht auf die anderen Unterst0tzungswerkzeuge im Groupware-Bereich tibertragen.

Workflow-Managementsystem Ein Workflow-Managementsystem ist ein rechnergest0tztes System, das arbeitsteilige Workflows aktiv steuert [Hales/Lavery 1991, S. 24; Hasenkamp/Syring 1993, S. 407; Kurbel

180

5 Prozessintegration

et al. 1995, S. 407; Stark/Lachal 1995, S. 74]. Seine Aufgabe ist die Untersttitzung der Workfiowspezifikation und der Steuerung des Workflows zwischen den beteiligten Stellen (Organisationseinheiten, Personen) und Anwendungen nach den Vorgaben der Ablaufspezifikation [vgl. Klischewski/Wetzel 2000, S. 41; Weske/Vossen 1998, S. 361ff]. WorkflowManagementsysteme konzentrieren sich ausschliesslich auf die Ablaufsteuerung und integrieren die ftir die Ausfiihrung der Arbeit notwendigen Anwendungen. Sie trennen die Ablaufsteuerung von den betrieblichen Anwendungen. Ein Workflow-Managementsystem besteht aus einer Entwicklungs- und Laufzeitumgebung [s. Jablonski 1995b, S. 67ff; Sch/il 1996, S. 90; WfMC 1997b, S. 244ff]. 9

Innerhalb der Entwicklungsumgebung erfolgt die Modellierung eines Workflowtyps. Sie unterstiitzt den Entwurfsprozess eines Workflows interaktiv, simuliert Entwurfsergebnisse und generiert letztendlich ausfiihrbaren Code aus den fertiggestellten Entwiirfen. Ergebnisse der Modellierung sind die sog. Workflowtypen, wie beispielsweise Kommerz- oder Hypothekarkreditantrag [s. Derungs et al. 1995b, S. 4ff]. Diese verwaltet das WorkflowManagementsystem in einem Repository.

9 Konkrete Auspr/igungen dieser Workflowtypen werden Workflowinstanzen genannt, z.B. der Hypothekarkreditantrag des Kunden F. Meier vom 30.August 98. Die Laufzeitumgebung generiert solche Workflowinstanzen, steuert und kontrolliert deren Durchfiihrung auf Basis der spezifizierten Workflowtypen und erm6glicht die Interaktion mit dem Benutzer. Das Workflow-Managementsystem generiert zur Laufzeit auf Basis eines Workflowtyps aus dem Repository eine Workflowinstanz, indem sie die fallspezifischen Daten und die Historie der Instanz in einem eigenen Repository ablegt. Zu jedem Workflowtyp k6nnen gleichzeitig mehrere Instanzen (in unterschiedlichen Bearbeitungszust~inden) im System existieren [Erdl/Schfnecker 1995, S28ff; Leymann et al. 1995; Stark/Lachal 1995, S. 29t7. Nach Beendigung einer Aktivit/it ermittelt die Laufzeitumgebung die n/ichsten auszuftihrenden Aktivit/iten, informiert fiber Arbeitslisten oder sog. PostkSrbe die daftir Verantwortlichen und tiberwacht deren fristgerechte Ausftihnmg. Sobald ein Benutzer aus dem Postkorb eine Aktivit/it auswahlt, startet das Workflow-Managementsystem automatisch die erforderlichen Programme fiir die Aktivit~itenausftihnmg und stellt die notwendigen Informationen bereit. Ftir jede Workflowinstanz protokolliert die Laufzeitumgebung alle Aktionen mit. Mit Hilfe dieser Daten kann eine Prozessfiihrung (s. Abschnitt 3.1.2.1) die Weiterentwicklung des Prozesses unterstiitzen [vgl. Galler/Scheer 1994, S. 10; Heilmann 1994, S. 14]. Ein Benutzer kann sowohl mit dem Workflow-Managementsystem als auch mit den betrieblichen Anwendungen zur Untersttitzung der Aufgabenausfiihrung kommunizieren. Das Workflow-Managementsystem informiert ihn mittels des Postkorbs fiber die anstehenden Aktivit/iten, aus denen er ausw/ahlen kann. Ftir die Ausftihnmg der Aktivit/it kommuniziert der Benutzer dann mit denjenigen Anwendungen, die durch das Workflow-Managementsystem aufgerufen wurden [vgl. Hollingsworth/Wharton 1994, S. 39ff]. Die Abbildung 5.19 zeigt die erl/iuterten Merkmale von Workflow-Managementsystemen grafisch.

5.3 Framework:Variantender Prozessintegration

181

Somit muss ein Workflow-Managementsystem ausreichend flexible Schnittstellen ~ r die Interaktion mit den betrieblichen Anwendungen aufweisen. Die Workflow Management Coalition (WfMC), ein Interessenverband von Anbietern und Anwendern, hat ein Referenzmodell mr eine Workflow-Managementsystem Architektur entwickelt, auf das sich die vorliegende Arbeit bezieht. Die Zielsetzung der WfMC ist die Entwicklung von Standards mr die Workflowterminologie, Interoperabilit~it und Connectivity. Alle Workflow-relevanten Begriffe hat die WfMC in einem Glossar systematisiert [WfMC 1997a]. Das Workflow Reference Model (Abb. 5.20) definiert alle wesentlichen Komponenten und Schnittstellen einer Workflow-Managementsystem Architektur. Aktuell spezifiziert das Referenzmodell ftinf Schnittstellen, die eine Zusammenarbeit unterschiedlicher Workflow-Managementsysteme und betrieblicher Anwendungen erleichtem sollen. Der Standardisierungsprozess der WfMC ist derzeit jedoch noch nicht abgeschlossen, da ftir die identifizierten Schnittstellen teilweise nur Vorversionen der Spezifikationen vorliegen [vgl. Heinl/ Schuster 1997, S. 244].

182

5 Prozessintegration

Process Definitions Tools Interface 1

~qfv

WF API and Interchange Formats Administration & Monitoring Tools

iI

"a

WF Engine(s)

[ W F Engine(s)

(1)

WF Enactment Service Interface 2

WF Client Applications

Abb. 5.20:

Other WF Enactment Service(s)

Interface 3

Invoked Applications

Referenzmodell der WfMC [s. WfMC 1997b, S. 260]

Zentral in dieser Architektur ist der sogenannte Workflow Enactment Service zur Abwicklung und Koordination laufender Workflowinstanzen. Die interne Struktur dieser Komponente bleibt often [vgl. Leymann/Roller 2000, S. 117ff]. Ebenso gibt die Architektur keine Auskunft dartiber, ob der Workflow Enactment Service durch eine oder mehrere Workflow Engines realisiert ist. Die zentrale Komponente verfligt fiber fiJnf separate Schnittstellen. 0ber das Interface 1 (Workflow Definition Interface) werden BPR-Tools mr die Prozessdefinition sowie Workflow-Modellierungswerkzeuge mit dem Workflow-Managementsystem verbunden [WfMC 1995]. Die Verbindung eines Workflow-Managementsystems mit einer beliebigen Posteingangskorbanwendung (E-Mail oder Groupware-L6sungen) ist Gegenstand des Interface 2 (Workflow Client Application Interface) [WfMC 1995a; WfMC 1996]. Die Idee dabei ist, dem Benutzer nur einen einzigen Postkorb zur Verfligung zu stellen, der sowohl Mails als auch Messages der Workflowsteuerung usw. beinhaltet. Das Interface 3 (Invoked Applications Interface) soil den Aufruf von betrieblichen Anwendungen standardisieren. Die Kooperation zwischen Workflow-Managementsystemen unterschiedlicher Hersteller regelt das Interface 4 (WAPI Interoperability Functions) [WfMC 1996a; WfMC 1996b]. Um Informationen tiber die aktuellen Zust/~nde der Workflowinstanzen an die Administrations- und Monitoringwerkzeuge austauschen zu kSnnen, definiert das Interface 5 (Administration & Monitoring Interface) einen Standard. Neben den Spezifikationen der WfMC haben bereits einige Hersteller unabh/ingig von den Standardisierungsbemtihungen Schnittstellen definiert, wie z.B. Microsoft die MAPI-Spezifikation (Messaging Application Programming Interface) [s. Microsoft 1996].

5.3 Framework:Variantender Prozessintegration

183

Unterschiede von Workflow-Managementsystem Produkten

Trotz des Referenzmodells einer Workflow-Managementsystem Architektur von der WfMC existieren am Markt eine Vielfalt unterschiedlicher Produkte. Diese Vielfalt/~ussert sich vor allem in unterschiedlichen technischen L6sungskonzepten. Eine einheitliche Klassifizierung der L6sungskonzepte gibt es noch nicht. [Marshak 1994, S. 22ff] unterscheidet beispielsweise die drei Architekturmodelle Mail-Based Model, Shared Database Model und Client/Server Database Model [vgl. auch Medina-Mora 1992]. Die Black Forest Group, eine Vereinigung von Workflow-Anwendem, unterscheidet die drei Kategorien Production Based Systems, Control Based Systems und Coordination Based Systems [s. Black Forest Group 1996, S. 92]. [Khoshafian/Buckiewicz 1995, S. 220] unterteilen die L6sungskonzepte in nur zwei Kategorien: Message Based Workflow und Server Based Workflow. Dieselbe Klassifikation, jedoch mit anderer Benennung der Kategorien, schlagen [Stark/Lachal 1995, S. 35ff] vor. Sic sprechen von Form-Based und Engine-Based Workflows. [Muth 1995a] konzentriert sich bei seiner Unterteilung nur auf die Sicht des Client/Server Modells. Er unterteilt die vier Varianten: Connected, Remote, Store & Forward und Fault Tolerant. Alle genannten Konzepte zeichnen sich trotz unterschiedlicher Begriffe durch grosse Gemeinsamkeiten aus und sind in den angegebenen Literaturstellen aus~hrlich beschrieben. Die aufgefiihrten Konzepte charakterisieren vor allem die Laufzeitumgebung der Workflow-Managementsysteme. Sie unterscheiden die Systeme beispielsweise danach, auf welche Art und Weise ein Arbeitspaket von einer Stelle zur n/ichsten transportiert wird. Die jeweilige Entwicklungsumgebung wird nur am Rande betrachtet. Neben der Klassifizierung von L6sungskonzepten versuchen einige Autoren mit der Identifikation von Einsatzbereichen mr Workflow-Managementsysteme eine Struktur in die Vielfalt der technischen L6sungskonzepte zu bringen. Sie besch/iftigen sich mit der Fragestellung, welche Auspr/~gungen von Workflow-Managementsystemen in welchem Zusammenhang einzusetzen sind. [Picot/Rohrbach 1995] leiten aus der Typisierung von Bt~roaufgaben in Routineaufgaben, sachbezogene Aufgaben und Einzelfallaufgaben [vgl. Nippa 1988, S. 90ff; Rau 1991, S. 21ff; Vogler 1993, S. 4ff] drei Prozesstypen ab, die sie mit Hilfe von Variablen (wie Komplexit/it, Ver/inderlichkeit, Detaillierungsgrad, Arbeitsteilung und Prozessverflechtung) abgrenzen und beschreiben. Der Prozesstyp (einmaliger Prozess, Regelprozess oder Routineprozess) h/ingt yon dem im Prozess vorherrschenden Aufgabentyp ab. Nach Picot und Rohrbach sind Workflow-Managementsysteme uneingeschr/~nkt zur Unterstfitzung von Routineprozessen geeignet, die sich (weitgehend) aus Routineaufgaben zusammensetzen. Routineprozesse sind somit der typische Einsatzbereich ffir transaktionsorientierte Workflow-Managementsysteme [vgl. Koulopoulos 1994, S. 2]. Sobald ein Prozess oder ein Grossteil seiner Aufgaben nicht dem Routinetyp zuzurechnen ist, 1/isst sich ein Workflow-Managementsystem nicht mehr beliebig einsetzen. Ffir Regelprozesse eignet sich der Einsatz von ad-hoc-orientierten Workflow-Managementsystemen [vgl. Palermo/McCready 1992; Silver 1994]. Einmalige Prozesse lassen sich wegen der mangelnden Strukturierung von Prozess und Aufgaben nicht mehr sinnvoll mit einem Workflow-Managementsystem unterstfitzen. [Hasenkamp/Syring 1994; Nastansky 1993] verwenden/~hnliche Kriterien mr die Abgrenzung

184

5 Prozessintegration

zwischen Workflow-Management und Workgroup-Computing, wobei das letztere den Bereich des ad-hoc Workflow-Managementsystems abdeckt. Weitere Klassifikationen von Einsatzbereichen und Workflow-Managementsystemen sind zu finden in [Carlsen 1995; Lawrence 1996; May 1994; Wersch 1995]. (,Jber die Unterschiede und Inhalte konkreter Produkte geben zahlreiche Marktstudien aus der Praxis sowie Arbeiten aus der Forschung Auskunft. Sie vergleichen meistens die Produkte anhand von Anforderungen und fiihren so zu einer Bewertung der Systeme. Dabei unterscheiden sie sich in dem Umfang des Untersuchungsbereichs. Die Arbeiten fiihren entweder ausgedehnte Analysen durch [vgl. Fichter 2000; G6tzer 1995; Lippold et al. 1993; Stark/Lachal 1995] oder geben einen groben l~lberblick tiber eine Reihe von Produkten [vgl. Jablonski 1995b; Kim 1995; Kock et al. 1995], beschreiben und vergleichen die Funktionen von Workflow-Managementsystemen [vgl. Erdl/SchSnecker 1995; Riempp 1998, S. 73ff], erstellen Profile tiber technische Anforderungen [vgl. IMACO 1995], beschriinken sich auf einzelne Aspekte [vgl. Derungs et al. 1995a] oder geben Erfahrungen aus Laborstudien wieder [vgl. Damschik/H~intschel 1995; Heinrich et al. 1995].

Eigenentwicklung Es besteht die M6glichkeit, eine autonome Steuerungskomponente selbst zu entwickeln. Diese Lfsung ist selten empfehlenswert, da es sich um einen aufwendigen Weg handelt, vor allem dann, wenn die Steuerungskomponente nicht nur fiir einen einzigen Workflow im Unternehmen einzusetzen ist. In diesen F~illen sind vertiefte Oberlegungen und Analysen tiber die Wiederverwendbarkeit, die Standardisierung der Schnittstellen etc. durchzufiJhren. Ausserdem existiert heute eine ausreichend grosse Auswahl von Workflow-Managementsystemen und Groupware-L6sungen auf dem Markt, weshalb sich diese Implementierungsvariante nur in den seltensten F~illen lohnen dtirfte [s. Stark/Lachal 1995, S. 74f]. Die nachfolgenden Kriterien k6nnen dennoch fiir einen derartigen L6sungsansatz sprechen: 9

Verftigbare Workflow-Managementsysteme bieten in der Regel ein sehr breites Spektrum an Funktionalitat an, das weit tiber die gewtinschten Anforderungen hinausgehen kann. Gentigt ein sehr geringer Umfang der m6glichen funktionalen Anforderungen (vgl. Abschnitt 5.3.2.1) kann eine Eigenentwicklung durchaus kostengtinstiger sein.

9

Sind die Anforderungen bzgl. der Plattformen sehr heterogen und kein am Markt verfiigbares Produkt erfiillt diese, kann die Eigenentwicklung notwendig sein.

5.3.2.3 Integrierte Steuerungskomponente Der Fall einer integrierten Steuerungskomponente l~isst sich noch weiter in zwei Untervarianten unterteilen. Das Unterscheidungsmerkmal liegt darin, ob es sich um eine zugekaufte Anwendung in Form einer betriebswirtschaftlichen Standardanwendungssoftware handelt, oder

5.3 Framework:Variantender Prozessintegration

185

ob die betriebliche Anwendung und somit auch die Steuerungskomponente selbst entwickelt wurden.

Integrierte Steuerungskomponente innerhalb einer betriebswirtschaftlichen Standardanwendungssoftware Betriebswirtschaftliche Standardanwendungssoftware ist eine modulate Anwendung fiir die betriebliche Administration des Unternehmens. Sie ist in dem Sinne generisch, dass ein konkretes Anwendungssystem erst durch Parametrisierung (Customizing) entsteht [s. Hofman 1994, S. 11]. In der Regel bietet betriebswirtschaftliche Standardanwendungssoftware integrierte L6sungen for die Logistik (Beschaffung, Produktion, Vertrieb), das Finanz- und das Personalmanagement eines Unternehmens. Sie bieten dem Anwender damit Funktionalit~t fiir eine umfassende Unterst0tzung seiner Gesch~iftsprozesse [s. Becker et al. 1998, S. 318]. Die einzelnen Module k6nnen dabei Bestandteil eines Paketes (z.B. SAP R/3) oder auf mehrere Pakete eines Anbieters verteilt sein (z.B. Peoplesoft Distribution, Financials, Human Resource Management, Manufacturing). Viele der am Markt verfiigbaren Standardanwendungssoftware zeichnen sich durch funktionale Programmhierarchien aus, die das Ergebnis strukturierter Analyse und traditionellem Systementwurf sind. Sie spiegeln das Denken in Funktionen bzw. Funktionalbereichen eines Unternehmens wider, wodurch sie nicht dem Gedanken der Prozessorientierung entsprechen. Es entsteht eine Kluft zwischen prozessorientierten Organisationen und funktional aufgebauter betriebswirtschaftlicher Standardanwendungssoftware. Um diese Lficke zu schliessen, integrieren einige Anbieter betriebswirtschaftlicher Standardanwendungssoftware ein eigenes Workflow-Managementsystem in ihre Produkte. Solche integrierte L6sungen, die spezifisch mr die Verwendung mit der eigenen Standardanwendungssoftware entwickelt wurden, bieten eine Reihe von Vor- und Nachteilen [s. Becker/ Vogler 1997, S:55ff; Becker et al. 1998, S. 321]. Die hier getroffenen Aussagen gelten auch ffir die Integration einer Steuerungskomponente in einer eigenentwickelten Anwendung.

Vorteile einer integrierten LOsung." 9

Leichte Modifikation von Workflows Eine integrierte L6sung stellt eine Integrationsschicht zwischen der Workflow-Ebene und der betriebswirtschaftlichen Anwendung zur Verffigung. Sie erlaubt dem Benutzer eine rasche Anpassung der Workflows an ge~nderte Anforderungen.

9

Schnellere Implementierung von Workflows Integrierte L6sungen verwenden auf der Modellebene die Applikationsstruktur der Standardanwendungssoftware. Dadurch vereinfacht sich die Implementierung von Workflows. Der Anbieter kann zudem Templates (vorgefertigte Workflowspezifikationen) anbieten.

186

9

5 Prozessintegration

Weniger Redundanz Das Workflowmodell ist sowohl mit dem Funktions- als auch dem Prozessmodell der Anwendungssoftware abgestimmt. Das Organisationsmanagement und das Berechtigungskonzept der Standardanwendungssoftware bilden die Grundlage ffir das Stellen- bzw. Rollenmodell der Steuerungskomponente. Der Anwender muss damit die Aufbauorganisation nicht redundant beschreiben.

9 Niedrigere Komplexitiit Durch Verwendung einer integrierten LSsung muss der Anwender nicht eine zusiitzliche Software in das Informationssystem integrieren. 9

Bessere Releasef'~ihigkeit der Steuerungskomponente Andert sich das Release der betriebswirtschaftlichen Standardanwendungssoftware, ist anzunehmen, dass auch die entsprechenden Modifikationen ffir die Steuerungskomponente vorgenommen wurden. Im Gegensatz zu autonomen L/Ssungen muss sich nicht der Anwender um die Releasef'~ihigkeit der Steuerungskomponente ldimmern, sie bleibt Aufgabe des Anbieters.

Nachteile einer integrierten LOsung 9

Gr6ssere Abhiingigkeit vom Anbieter Die integrierte L6sung erh6ht die Abhiingigkeit vom Softwarelieferanten. Der Anbieter ist nun nicht nur Rir die Lieferung der betriebswirtschaftlichen Funktionalitiit zustiindig, sondern zus~itzlich ffir die Steuerungsfunktionalitiit. Der Anwender muss dadurch bei einem Wechsel des Softwareprodukts zwei Kernbereiche der Aufgabenabwicklung gleichzeitig migrieren.

9

Eingeschr~inkte Offenheit Bei den integrierten L/Ssungen steht die Einbindung der Steuerung in eine bestimmte Standardsoftware im Vordergrund. Die Schnittstellen sind entsprechend ffir diese LSsung entwickelt. Die Einhaltung und Bereitstellung allgemeiner offener Standards zur Integration heterogener Anwendungen in einem Workflow sind hiiufig Nebensache.

Unterschiede von konkreten L6sungen [Becker/Vogler 1997] haben die Inhalte und Unterschiede konkreter Produkte von betriebswirtschaftlicher Standardanwendungssoftware mit einer eigenen Workflowkomponente untersucht (SmartStream von Dun & Bradstreet Software, Oracle Workflow von Oracle, Peoplesoft Application Workflow von Peoplesoft, Ramco Marshal Enterprise Management System von Ramco Systems und R/3 Business Workflow von SAP). Die Untersuchung zeigte, dass die ffihrenden Softwarehiiuser das Workflow-Management in ihre Standardanwendungssoftware integrieren. Im Folgenden werden die zentralen Untersuchungsergebnisse dargestellt, fiir

5.3 Framework:Varianten der Prozessintegration

187

die Unterschiede der einzelnen Produkte im Detail sei auf [Becker/Vogler 1997; Becker et al. 1998] verwiesen. 9

Die Architektur der jeweiligen betriebswirtschaftlichen Standardanwendungssoflware bestimmt die Workflowarchitektur. So ist in der Mehrzahl der F~ille die Laufzeitumgebung integrierter Bestandteil der eigentlichen Applikationssteuerung.

9

Die Hauptunterschiede zwischen den verschiedenen Produkten liegen in der Einbindung der Funktionalit~it des Softwarepaketes in die Workflows. Die L6sungen reichen vonder Integration bestehender oder workflowspezifischer Transaktionen bis zur Bereitstellung elementarer Softwarefunktionen, die der Anwender zu Aktivit~iten zusammensetzt.

9

Die Mehrzahl der Anbieter verwendet einen ereignisorientierten Ansatz ~ r die Modellierung von Workflows.

9

Bis heute stehen keine umfassenden Referenzmodelle ~ r den Workflowentwurf zur Ver~gung. Vielmehr konzentrieren sich die Anbieter auf die Bereitstellung von Referenzaktivit~iten.

9

Der Anwender kann aus verschiedenen Workflow Clients w~ihlen. 0blich ist die Integration des Workflow Clients in den Application Client der Standardanwendungssoftware, es kann jedoch auch ein E-Mail oder ein Web Client als Workflow Client fungieren.

9

Die Internet-Technologie nimmt auch in diesem Bereich Einzug. Einige L6sungen zeichnen sich bereits ~ r die Integration der Workflowarchitekturen mit Internet-L6sungen ab.

9

Ftir die Interaktion der Workflowl6sungen mit Anwendungen ausserhalb der Standardanwendungssoftware stehen Schnittstellen zur Verfiigung, die sich jedoch h~iufig nicht an offenen Standards orientieren.

Integrierte Steuerungskomponente innerhalb einer eigenentwickelten Anwendung Unterst~tzt eine eigenentwickelte Anwendung weite Teile des Prozesses, kann eine Erweiterung dieser um eine Steuerungskomponente sinnvoll erscheinen. In der Regel handelt es sich hierbei jedoch um ein aufwendiges Vorhaben, soll doch die Ablaufsteuerung nicht nur f'tir einen einzigen Prozess einsetzbar sein. BenOtigt die Prozessuntersttitzung auch noch weitere Anwendungen des Informationssystems, mtissen entsprechende Schnittstellen geschaffen werden. Somit sind auch hier, wie bei der Eigenentwicklung einer autonomen Steuerungskomponente Oberlegungen in Bezug auf die Wiederverwendbarkeit, Standardisierung der Schnittstellen etc. durchzu~hren. Deshalb ist eine zugekaufte L6sung der Eigenentwicklung meist vorzuziehen. Die Kriterien, welche ~ir diesen Weg sprechen kOnnen, sind identisch mit denen der eigenentwickelten autonomen Steuerungskomponente und werden deshalb nicht nochmals aufge~hrt.

188

5 Prozessintegration

Kriterien fiir die Wahl der Untervarianten

Die Wahl zwischen den beiden Untervarianten l~isst sich anhand der folgenden Fragen treffen: 9

Ist im Rahmen des Workflows eine betriebswirtschaftliche Standardanwendungssoftware mit integrierter Steuerungskomponente im Einsatz?

9

Liegt fiir den vorliegenden Workflow die Verwendung einer betriebswirtschaftlichen Standardanwendungssoftware nahe?

9 Unterstiatzt eine (eigenentwickelte) Anwendung weite Teile der Workflows? 9 L~isstsich eine solche Anwendung leicht um eine Steuerungskomponente erweitem?

5.3.2.4 Gegeniiberstellung der Implementierungsvarianten

Der Einsatz einer autonomen Steuerungskomponente bietet gegentiber der integrierten L6sung eine Reihe von Vorteilen. So kann eine separate Software fiir die Steuerung die unterschiedlichsten Workflows untersttitzen und zu einer eigenen Softwareschicht im Informationssystem werden. Diese Ebene ist fi~r die Steuerung und Integration der desktopintegrierten Aktivit~ten gem~iss den Ablaufspezifikationen verantwortlich und hilft Transparenz in der Architektur des Informationssystems zu schaffen. Legt das Untemehmen bei der Auswahl der entsprechenden Produkte ausreichend Wert auf eine vielseitige Einsatzf'~ihigkeit (Unterstiitzung heterogener Plattformen, standardisierte Schnittstellen etc.), muss nicht bei jedem Projekt zur Prozessintegration eine neue Implementierungsvariante eruiert werden. Zudem k6nnen die innerhalb der Aktivit~ten verwendeten betrieblichen Anwendungen beliebig ausgetauscht werden, ohne auf die Steuerungsschicht gr6sseren Einfluss zu nehmen. Autonome Ablaufsteuerungen sind in der Regel mit einer Reihe von generischen Schnittstellen versehen, die auf die Integration heterogener Anwendungen abzielen. Derartige Schnittstellen helfen den Integrationsaufwand zu reduzieren. Die Variante der integrierten Komponente ist vor allem dann von Vorteil, wenn die tibergeordnete betriebliche Anwendung im gesamten Unternehmensgeschehen eine grosse Bedeutung besitzt und den tiberwiegenden Teil der Aufgabenuntersttitzung tibemimmt. Die Vorteile dieser Implementierungsvariante liegen in dem geringeren Integrationsaufwand. Da die Steuerung ftir die entsprechende Anwendung entworfen und realisiert wurde, kann sie auf die Transaktionen oder Funktionen ohne einen gesonderten Schnittstellenentwurf zugreifen. Einzig ~ r die Integration anderer ben~tigter Anwendungen sind Schnittstellen anzupassen oder neu zu schreiben. Je h~her der Anteil zu integrierender "Fremdanwendungen" ist, desto weniger kommt die integrierte L~Ssungin Frage. Ftir die make-or-buy-Entscheidung in Bezug auf die Workflowsteuerung gelten die gleichen Kriterien wie bei jeder betrieblichen Anwendung. Sie k6nnen in entsprechenden Untersuchungen nachgeschlagen werden [M~innel 1981; Picot 1991].

5.4 Methodeftir die Prozessintegration

189

5.4 Methode fiir die Prozessintegration Das im Abschnitt 4.4.2 eingefiihrte Vorgehen fiir die Prozessintegration (s. Abb. 5.21) wird nun im Detail erl/~utert.

Die Beschreibung des Vorgehens lehnt sich dabei an die Grunds/itze des Method Engineerings [Gutzwiller 1994, S. 12ff; Heym/Osterle 1992, S. 147] an. Das Method Engineering ist ein eigenst/~ndiger Forschungsbereich innerhalb des Software Engineering und der Wirtschaftsinformatik. Es wendet Prinzipien der Entwurfsmethoden von Informationssystemen auf die Entwicklung von Entwurfsmethoden selbst an. Eine Methode beinhaltet mehrere Phasen, in welchen Rollen (Menschen oder Gremien) Entwurfsaktivit/~ten durch~hren und dabei Ergebnisse erzeugen. Ein Metamodell beschreibt und strukturiert die Entwurfsergebnisse in Form eines konzeptionellen Datenmodells. Die Techniken geben an, wie die Entwurfsergebnisse in den einzelnen Entwurfsaktivit/iten zu erstellen sind. Abbildung 5.22 stellt den Zusammenhang zwischen diesen Komponenten in Form eines Datenmodells dar. Entstanden ist die Methode im Rahmen des Kompetenzzentrums Prozess- und Systemintegration (CC PSI) des Forschungsprogramms IM HSG. Ein erster Entwurf wurde mit den beteiligten Untemehmen diskutiert. Die daraus resultierende Methode haben die Partnerfirmen AGI und Informationsdienste PTT in Pilotprojekten eingesetzt. Die gemachten Erfahrungen flossen wiederum in die Weiterentwicklung der Methode ein. Die hier vorgestellte Methode ist soweit von der urspriinglichen Version [Derungs 1997b] abge/indert, dass sie in den Gesamtkontext der Enterprise Application Integration passt.

190

5 Prozessintegration

ist Oberge-

Metamodell [

ordnet

ist

Vorggnger

@Entwurls.@yon

erzeugt/

I aktivit~it I

verwendet

problem-l

ist orientierte

~ EigebnisI

Sicht auf ist

fOhrt aus

$

Oberge-~ ordnet lunterstOtzt das

Erstellenvon

ITeoho'l Abb. 5.22:

I

Rolle

]

Komponenten der Methodenbeschreibung [Gutzwiller 1994, S. 13]

Die Teile Metamodell, Ergebnisse und Techniken lassen sich allgemeingtiltig mr alle vorgestellten Varianten der Prozessintegration beschreiben. Fiir die Rollen und die Entwurfsaktivit/iten trifft dies nicht zu. Art und Umfang der bereitgestellten Ressourcen, der Ausbildungsstand und Erfahrungshintergrund der beteiligten Mitarbeiter, die zur Ver~gung stehende Zeit und die Kooperationskultur zwischen den betroffenen Organisationseinheiten sind unternehmens- und projektspezifisch. Ein Vorgehensmodell 1/isst sich flir die m6glichen Varianten auch nur in begrenztem Masse definieren, da es durch politisch-verhaltensorientierte Gestaltungsdimensionen, durch Zielformulierungen, Alternativbeurteilungen und Entscheidungsfindungen massgeblich beeinflusst wird [s. Derungs 1997a, S. 83]. Deshalb kann das hier vorgestellte Vorgehensmodell nur als Vorschlag verstanden werden, welcher der jeweiligen Projektsituation angepasst werden muss. Es konzentriert sich auf das Vorgehen mr einen transaktionsorientierten Workflow, da er den komplexesten Fall bei der Implementierung darstellt. Zudem bezieht sich die Methode nur auf die Architekturvarianten vier bis sechs der Prozessumsetzung (Taskflowsteuerung, Workflowsteuerung, Workflow und Taskflow) aus dem Abschnitt 4.3.3. Die restlichen Varianten mr die Prozessumsetzung sind mit Methoden des Softwareengineerings oder mit der in Kapitel 6 beschrieben Methode der Systemintegration zu realisieren.

5.4.1 Dokumentationsmodell

Abh~ingigkeiten der Entwurfsergebnisse Die vorgestellten Dokumente stehen nicht isoliert nebeneinander, sondem besitzen inhaltliche Abh[ingigkeiten. So kann eine Aktivit~it ohne vorherige Kenntnis der Tasks nicht exakt beschrieben werden oder der Workflow kann nur mit Hilfe des Aktivit~itenverzeichnisses entworfen werden.

5.4 Methodefiir die Prozessintegration

191

Unter Berticksichtigung dieser Abh~ingigkeiten, fasst die Prozessintegration die Erstellung der Entwurfsergebnisse in Phasen zusammen. In Anlehnung an Methoden aus dem Software Engineering unterscheidet die Prozessintegration die Phasen Voruntersuchung, Konzeption, Realisierung und Einftihrung (s. Abb. 5.23) [vgl. Eva 1992; Gutzwiller 1994; Humphrey 1990; Olle et al. 1991; Steinweg 1995].

9

Die Voruntersuchung analysiert die Ausgangssituation und vor allem die Anforderungen des Prozesses an die Computeruntersttitzung bzgl. der Steuerung. Weiterhin plant sie bereits die technologische Umsetzung. In diesem Zusammenhang entwirft das Projektteam Anforderungen an die Infrastruktur, auf welcher die Prozessintegration aufbaut. In der Regel handelt es sich hierbei um solche Komponenten, auf welche die Prozessintegration aufsetzt, die jedoch unabh~ingig von ihr entwickelt werden k6nnen. Somit k6nnen separate Projekte diese Anforderungen umsetzen. Ihre Planung und die Koordination der wesentlichen Meilensteine sind Bestandteil der Methode zur Prozessintegration.

9

Die Konzeption baut auf den Ergebnissen der Voruntersuchung auf und spezifiziert den Workflow aus konzeptioneller Sicht (m6glichst unabh~ingig von einem konkreten Implementierungswerkzeug).

9

Die Realisierung implementiert die Ergebnisse der Konzeption mit konkreten Werkzeugen.

9

Die Einfiihrung ftihrt den Workflow in das Produktivsystem ein, tibergibt die Anwendung dem Benutzer, nimmt letzte Korrekturen vor und iiberprtift die Zielerreichung. Diese Phase ist in allen Vorgehensmodellen ~ihnlich aufgebaut und kann deshalb im Rahmen dieser Arbeit vemachl~issigt werden.

In jeder der vorgestellten Phasen fallen unterschiedliche Entwurfsergebnisse der Prozessintegration an. Eine Zuordnung der einzelnen Entwurfsergebnisse zu den Phasen muss folgenden Aspekten Rechnung tragen:

192

5 Prozessintegration

9

Sie muss sich massgeblich an den Vorgaben aus dem Prozess orientieren. Vorrangig hat sie die Anforderungen des Prozesses an seine Computeruntersttitzung hinsichtlich der Steuerung zu identifizieren und somit die Steuerungsvariante festzulegen.

9

Sie bezieht friJhzeitig das vorhandene Informationssystem des Untemehmens in die Planung mit ein.

9

Sie bezieht die Komplexit~it des Projektes mit ein, indem sie umfangreiche Prozesse in kleinere, tiberschaubare Einheiten fiJr die Detailspezifikation und insbesondere mr die Implementierung zerlegt.

9

Sie legt eine Trennung der Ablaufsteuerung und der betrieblichen Anwendungen zugrunde.

9

Sie berticksichtigt den 0bergang zur Systemintegration insbesondere bei der Desktopintegration, legt aber den Schwerpunkt auf die Ablaufsteuerung.

9

Sie legt bereits in der Voruntersuchung eine Beurteilung der erarbeiteten Ergebnisse nahe und ermtiglicht damit Entscheidungen tiber WeiterRihrung, Rticksprtinge oder Abbruch des Projekts.

9

Sie bezieht den unterschiedlichen Abstraktionsgrad der einzelnen Phasen mit ein: von einer eher groben fachlichen Sicht in der Voruntersuchung tiber eine detailtierte logische Sicht in der Konzeption bis hin zu physischen Aspekten der Implementierung in der Realisierung.

Unter Berticksichtigung dieser Aspekte zeigt die Abbildung 5.24 die Zuordnung der Ergebnisse zu den Phasen der Prozessintegration. Dabei fehlen jedoch die konkreten Beziehungen zwischen den Ergebnissen. Sie sind im Dokumentationsmodell der Prozessintegration (Abb. 5.25) enthalten. Das Modell stellt Entwurfsergebnisse, die gemeinsam und aufeinander abgestimmt zu entwickeln sind, in Knoten dar. Die Ablauffolge der so entstehenden kleineren Untersuchungsbereiche ist durch gerichtete Kanten dargestellt.

Phase Voruntersuchung

Konzeption

Entwurfsergebnisse Taskliste (strukturiert) Workflowkontextdiagramm Workflowverzeichnis (Teil-)Projektauftr~ge Aktivit~itenbeschreibung Aktivit~itenverzeichnis AusfOhrungsbedingungen Berechtigungskonzept Taskbeschreibung Workflow ZustandsObergangsdiagramm

5.4 Methodefor die Prozessintegration

193

9 Voruntersuchung Aufgabe der Voruntersuchung ist die Wahl der adaquaten Steuerungsvariante. Im Falle eines sehr grossen oder bzgl. des Ablaufs heterogenen Prozesses, kann eine Unterteilung in mehrere Workflows sinnvoll sein. Die Voruntersuchung grenzt entsprechend den Anforderungen des Prozesses und den technologischen Rahmenbedingungen Workflows ab, legt Rir jeden die passende Steuerungsvariante lest und plant das weitere Vorgehen. 9 Konzeption Schwerpunkt ist die Abgrenzung der Aktivit~iten. Danach lassen sich relativ unabh~ingig einerseits deren Ablauffolge und andererseits ihre Detailspezifikation im Rahmen der Desktopintegration entwerfen.

194

9

5 Prozessintegration

Realisierung In der Realisierungsphase wird entsprechend den Vorgaben aus der Konzeption das Workflow-Managementsystem parametrisiert. Die desktopintegrierten Aktivit~iten werden in Form von Programmen in den Workflow eingebunden. Die Realisierung dieser Programmodule ist Aufgabe der Systemintegration und wird im Kapitel 6 n~iher beschrieben.

5.4.2 Techniken

Die Entwurfsergebnisse sind Basis mr ein ergebnisorientiertes Projektmanagement und erlauben dem Projektleiter eine Planung der Prozessintegration. Die Angabe der zu erarbeitenden Ergebnisse reicht in der Regel jedoch nicht aus. Vielmehr ben6tigen die Projektbeteiligten Techniken, die ihnen Hilfestellungen ftir die Erstellung der Ergebnisse liefern. Die nachfolgenden Abschnitte beschreiben die drei zentralen Techniken der Prozessintegration. Zur Beschreibung der einzelnen Techniken findet ein zweiteiliges Schema Anwendung. Im ersten Teil werden die jeweiligen Ziele der Technik erl~utert. Zudem erfolgt eine Einordnung der Technik in die Prozessintegration. Mit einer Obersichtsdarstellung der Technik schliesst der erste Teil der Beschreibung ab. Im zweiten Teil stehen konkrete Empfehlungen mr das Vorgehen im Mittelpunkt.

5.4.2.1 Workflowabgrenzung Die Workflowabgrenzung ist der Voruntersuchung zuzuordnen. Sie leitet aus den wesentlichen Ergebnissen eines Prozessentwurfs oder einer vorliegenden Prozessdokumentation die umzusetzenden Workflows ab. Nach der Wahl einer ad~iquaten Variante der Prozessintegration plant sie das weitere Vorgehen ftir die Umsetzung der gewtinschten Ablaufsteuerung.

Ziele und geplante Resultate

Der Prozessentwurf befasst sich in der Regel nur mit den wertsch6pfenden Kemprozessen eines Untemehmens, weshalb meist umfangreiche und komplexe Prozesse als Ergebnisse resultieren. Dartiber hinaus trifft der Prozessentwurf Grundsatzentscheidungen flit Innovationen und radikale Verbesserungen hinsichtlich des Ablaufes. Detaillierte Angaben tiber die gewtinschte Prozessintegration macht er aufgrund seines hohen Abstraktionsgrades nicht. Hierzu sind weiterfiihrende Untersuchungen und Aktivitiiten notwendig. Insbesondere das vorhandene Informationssystem muss in die Wahl einer Variante der Ablaufsteuerung mit einbezogen werden. Ziel der Workflowabgrenzung ist es, auf Basis der vorliegenden Prozessdokumentation und des vorhandenen Informationssystems die umzusetzenden Workflows abzugrenzen, die gewtinschte Variante der Prozessintegration auszuw~ihlen und dementsprechend das weitere Vorgehen zu planen [vgl. Derungs et al. 1996, S. 56].

5.4 Methodeftir die Prozessintegration

195

Abbildung 5.26 zeigt einen Oberblick tiber die Workflowabgrenzung. Der zentrale Kasten listet die durchzufiihrenden Schritte auf. Auf der linken Seite stehen die Input-Dokumente, welche die Workflowabgrenzung aus anderen Techniken tibemimmt. Auf der rechten Seite sind die Entwurfsergebnisse (Output-Dokumente) aufgefiihrt. Die Beziehungen zwischen den Input-Dokumenten, den Schritten und den Ergebnissen sind durch gerichtete Kanten dargestellt, wodurch inhaltliche Abh~ingigkeiten dokumentiert sind, jedoch nicht zeitliche. Zwischenergebnisse sind bewusst nicht im Abschnitt 5.4.1 vorgestellten Dokumentationsmodell aufgenommen, werden hier innerhalb der einzelnen Techniken jedoch aufgelistet.

Erarbeitung der Resultate Die Workflowabgrenzung setzt sich aus den vier Schritten 9

Aufgaben zerlegen und strukturieren,

9

Workflowkandidaten identifizieren und abgrenzen,

9

Steuerungsvariante w~ihlen und Workflowkandidaten beurteilen,

9

Umsetzung planen

zusammen. Im Schritt 1 tibemimmt sie die aufgabenbezogenen Informationen aus der Prozessbeschreibung, tiberprtift sie auf Vollst~indigkeit und zerlegt bzw. strukturiert sie bei Bedaft weiter. Der zweite Schritt grenzt auf Basis der (strukturierten) Taskliste Workflowkandi-

196

5 Prozessintegration

daten ab, die im Schritt 3 in Bezug auf die Ablaufsteuerung beurteilt werden. Die Steuerungsvariante wird gew/ihlt. Der Schritt 4 entscheidet fiber die Umsetzung des Workflows und berticksichtigt dabei auch die Planung zus~itzlich erforderlicher Teilprojekte.

Schritt 1: Aufgaben zerlegen und strukturieren lSPoer den Detaillierungsgrad der vorliegenden Prozessbeschreibung lassen sich keine allgemeingiiltigen Aussagen treffen. Die Tiefe der Informationen h/ingen zum Teil vonder zum Prozessentwurf angewandten Methode ab (vgl. Abschnitt 5.2.1) und sind zum Teil auch von der konkreten Projektsituation abh~ingig. Aus diesem Grund muss die Technik der Workflowabgrenzung an erster Stelle die vorhandene Prozessbeschreibung mit den ben6tigten Informationen abgleichen. Die Angaben fiber die Aufgaben des Prozesses sind, falls erforderlich, weiter zu verfeinem bis auf die elementare Stufe von Tasks. Das Ergebnis der Aufgabenzerlegung ist dann Ausgangspunkt mr die Identifikation von Workflowkandidaten im Rahmen des Prozesses. Aufgaben innerhalb eines Prozesses beschreiben ein Objekt mit der zugehOrigen Verrichtung (z.B. Auftrag erfassen) und kSnnen weiter strukturierbar sein. So kann eine Aufgabe sich aus mehreren untergeordneten Aufgaben zusammensetzen. Sie hebt in diesem Falle entweder Gemeinsamkeiten der Unteraufgaben hervor und unterdriackt Einzelheiten (Klasse von Aufgaben) oder sie setzt sich aus mehreren Teilaufgaben zusammen (Komplex von Aufgaben). Die Aufgaben k6nnen nach dem Klassen- und Komplexprinzip strukturiert in Tasks zerlegt werden. Das Klassen- und Komplexprinzip kann sich dabei sowohl auf das Objekt als auch auf die Verrichtung der Aufgaben beziehen. Dabei unterstiitzen folgende Fragestellungen die Analyse der Aufgaben mit Hilfe des Klassen- und Komplexprinzips [s. Derungs et al. 1996, S. 60f; Osterle 1981; vgl. auch Rumbaugh et al. 1993]: 9 Klassenprinzip 9 Welche Arten von Objekten gibt es? 9 Welche Arten der Verrichtung (Methoden) gibt es? 9 Komplexprinzip 9 Welche Teile des Objekts werden bearbeitet? 9 Welche Teilschritte gibt es in der Verrichtung (Bearbeitung)? Folgende Abbildung 5.27 zeigt eine Zerlegung der Aufgabe "Auftrag erfassen" einer Telefongesellschaft.

5.4 Methodeflir die Prozessintegration

197

Durch die Anwendung der beiden Prinzipien erhglt man sehr schnell ausreichend Informationen far die Workflowabgrenzung. Das Komplexprinzip generiert elementare Arbeitsschritte, die nicht weiter zerlegt werden k6nnen. Sie beschreiben die Aufgaben im Detail. Wann der ausreichende Detaillierungsgrad erreicht ist, lgsst sich wie folgt erkennen: mit Hilfe der Tasks muss der verantwortliche Bearbeiter oder das Informationssystem die Aufgabe vollst/~ndig und korrekt ausfahren k6nnen. Die Tasks lassen sich unterscheiden in IT-unterstt~tzte oder manuelle Tasks, wobei sich ITunterstt~tzte Tasks auf eine logische Transaktion, ein Serviceprogramm oder eine Bt~rosoftware beziehen. Ft~r den Benutzer sind sie durch ein Formular, ein Dokument, ein oder mehrere Bildschirmmasken etc. bestimmt. Das Klassenprinzip hilft bei der Strukturierung der Tasks und zeigt m6gliche Varianten der Ausfahrung auf. Diese k6nnen durch separate Workflows umgesetzt werden. Durch die Kombination der beiden Verfahren entsteht eine Taskliste, deren Struktur massgeblich das Klassenprinzip pr/~gt, w/~hrend die Beschreibung der Aufgaben mehr durch das Komplexprinzip bestimmt ist. Je Aufgabe entsteht eine mehrstufige Struktur (vgl. Abb. 5.28). Der Aufwand far die Durchfahrung dieses Schrittes h/ingt vom Detaillierungsgrad der bereits vorliegenden Prozessbeschreibung ab.

198

5 Prozessintegration Auftrag erfassen Auftrag eingeben Stammdaten 0bernehmen Neues Abonnement Adresse des neuen Anschlusses eingeben Einschalttermin eingeben Ger~itebestellung eingeben ETB-Eintrag eingeben Umzug Adresse des neuen Anschlusses eingeben Einschalttermin eingeben bisherige Adresse eingeben alten Anschluss suchen Ausschalttermin eingeben ETB-Eintrag eingeben ,~,nderung ETB alten Anschluss suchen ETB-Eintrag eingeben K0ndigung alten Anschluss suchen Ausschalttermin eingeben Auftrag speichern

Abb. 5.28:

Kunde suchen Au~rag scannen Kunden nach Name suchen Neukunde

Stammdaten erfassen Altkunde Kunden ausw~hlen Stammdaten 0bernehmen Auftrag pr0fen Unterschrift pr0fen Unterschrift vergleichen Ergebnis festhalten fehlende Angaben markieren Auftrag genehmigen Ger~itebestellung ausl0sen Ger~itebestellung aus Auftrag 0bernehmen Bestellung an Laden Qbermitteln

Ausschnitteiner strukturierten Taskliste

Schritt 2: Workflowkandidaten identifizieren und abgrenzen

Die Identifikation und Abgrenzung von Prozessen orientiert sich massgeblich an Leistungen, die zwischen Prozessen ausgetauscht werden. Der Einbezug des Informationssystems und der vorhandenen Informationstechnologie findet nicht oder nur unzureichend statt. Aus diesem Grund muss die Workflowabgrenzung verst/~rkt auf die Implementierung eingehen. Sie muss aufbauend auf den Ergebnissen der Prozessabgrenzung und-zerlegung die Einheiten der Implementierung (Workflows) definieren [vgl. Baresi et al. 1999, S. 22]. Um die Implementierung 0berschau- und gut planbar zu gestalten, ist bei der Abgrenzung von Workflows besonderer Wert auf die Komplexit/~t der entstehenden Workflows zu legen. Dabei spielt in der Regel nicht die Anzahl der Aufgaben innerhalb der Workflows (L/~nge) die entscheidende Rolle, sondern vielmehr die Anzahl der Verzweigungen (Breite). FOr die Identifizierung von Workflowkandidaten zieht die Workflowabgrenzung die Prozesszerlegungsmatrix und die Zerlegung der Aufgaben nach dem Klassenprinzip aus dem vorhergehenden Schritt als Informationsquelle heran und identifiziert erste Kandidaten. Diese vergleieht sie in Bezug auf deren Leistungserstellung, indem sie untersucht, inwieweit sich die Kandidaten in ihren Tasks unterscheiden oder 0bereinstimmen. FOr die endg01tige Identifikation der Workflowkandidaten sind die folgenden Fragen zu beantworten:

5.4 Methode fiir die Prozessintegration

9

199

Wie stark unterscheiden sich die Art und Weise der Leistungserstellung der einzelnen Workflowkandidaten?

9

Welche Workflowkandidaten sind in Bezug auf ihre Tasks identisch?

9

Welche Workflowkandidaten sind bereits in anderen Workflows enthalten?

9

Nach welchen Sequenzen ist die Aufteilung in Workflows aufgrund der Unterschiede in der Art und Weise der Leistungserstellung sinnvoll?

9

L~isst sich der Prozess sowohl in Bezug auf L~inge als auch Breite in Workflows unterteilen?

9

Wie beeinflussen die mOglichen Varianten der Prozessintegration die Abgrenzung von Workflowkandidaten? Auftrag.~_ ~m ~,