Automatisierung von Führungsentscheidungen: Framework, Modellierung und Prototyp

Jonas Rommelspacher Automatisierung von Führungsentscheidungen

VIEWEG+TEUBNER RESEARCH Entwicklung und Management von Informationssystemen und intelligenter Datenauswertung Herausgeber: Prof. Dr. Paul Alpar, Philipps-Universität Marburg Prof. Dr. Ulrich Hasenkamp, Philipps-Universität Marburg

Jonas Rommelspacher

Automatisierung von Führungsentscheidungen Framework, Modellierung und Prototyp

Mit einem Geleitwort von Prof. Dr. Ulrich Hasenkamp

VIEWEG+TEUBNER RESEARCH

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Dissertation Philipps-Universität Marburg, 2011

1. Auflage 2011 Alle Rechte vorbehalten © Vieweg+ Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2011 Lektorat: Ute Wrasmann

I Britta Göhrisch-Radmacher

Vieweg+ Teubner Verlag ist eine Marke von Springer Fachmedien. Springer Fachmedien ist Teil der Fachverlagsgruppe Springer Science+Business Media. www.viewegteubner.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von 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ären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN 978-3-8348-1705-1

Geleitwort Die Automatisierung von Führungsentscheidungen war seit dem Beginn des massenhaften Einsatzes von Informationstechnik in Unternehmen, etwa zu Beginn der 1970er Jahre, ein beherrschendes Thema. Nach schnellen Erfolgen bei der Automatisierung von einfachen Routinetätigkeiten, insbesondere des externen Rechnungswesens, wandte man sich vehement dem "Höheren" zu und stellte den Schwerpunkt der Entwicklung unter das Schlagwort "Management Information System". Der Gipfel der - aus heutiger Sicht naiven - Visionen war das "Total Information System". Die damit verbundene Vorstellung von einer vollen oder zumindest weitgehenden Automatisierung erwies sich als unerreichbar. Damit schlug das Pendel in die andere Richtung aus, und die Entwicklung der Informationstechnik konzentrierte sich auf eine bloße "Unterstützung" des Managements durch Informationsbereitstellungssysteme und analytische Informationssysteme, ohne den Anspruch einer AutomatiSierung im engeren Sinne. Damit geriet der Gedanke einer Automatisierung von Führungsentscheidungen genauso in Vergessenheit wie etwa die Künstliche Intelligenz, die wegen anfänglich zu euphorischer Erwartungen enttäuschte und erst später wieder interessant wurde.

Tatsächlich hat die Informationstechnik das Potenzial zur Übernahme von Aufgaben, die man gemeinhin als Managementaufgaben ansieht, und dieses Potenzial wurde und wird auch - zumindest auf unteren und mittleren Managementebenen - genutzt. Der Trend zum "Lean Management" in den 1980er und teilweise den 1990er Jahren wäre sonst nicht so erfolgreich gewesen. Allerdings waren die treibenden Kräfte die Praktiker. Eine wissenschaftliche Fundierung der Automatisierung von Führungsentscheidungen hat es nur ansatzweise gegeben. Auf der anderen Seite wurden Ansätze aus der Wissenschaft zur aktionsorientierten Informationsverarbeitung (Anreicherung von analytischen Informationssystemen um aktive Komponenten) von der Praxis (noch) nicht allgemein akzeptiert. Vor diesem Hintergrund hat der Verfasser sich die anspruchsvolle Aufgabe gestellt, das Wesen von Führungsentscheidungen an sich zu ergründen, um davon ausgehend die Automatisierbarkeit zu untersuchen und - im positiven Fall - ein Konzept dafür zu entwickeln.

Geleitwort

VI

In der Arbeit wird zunächst die Forschungskonzeption anhand einer Konfiguration wissenschaftstheoretischer Kategorien dargelegt. Der Verfasser entscheidet sich im Anschluss an die Skizzierung möglicher Positionen für ein konstruktionsorientiertes Forschungsparadigma, angelehnt an die im angelsächsischen Bereich so genannte Design Science. Nach der Herleitung grundlegender Begriffe werden die Merkmale von Führungsentscheidungen herausgearbeitet und ermittelt, unter welchen Voraussetzungen diese einer Automatisierung zugänglich sind. Die Automatisierung von Führungsentscheidungen erfolgt dabei in Anlehnung an die soziologische Systemtheorie mithilfe von Entscheidungsprogrammen, wobei je nach Ansatzpunkt der Programmdefinition zu unterscheiden ist in Konditional- und Zweckprogramme. Da sich beide Alternativen in ihrer Reinform nicht zur Automatisierung von Führungsentscheidungen eignen, nutzt der Verfasser die so genannte Programmverschachtelung, bei der untergeordnete Programme als Entscheidungsalternativen übergeordneter Zweckprogramme dienen. Auf dieser Basis entwickelt er ein Framework zur Automatisierung von Führungsentscheidungen. Die Überprüfung des Gedankengebäudes anhand eines Prototyps führt zwei kleine Beispiele aus dem Bankbereich ein. Die Modelle sind auf das Wesentliche reduziert und demonstrieren die relevanten Eigenschaften deutlich. Insgesamt handelt es sich um eine Arbeit, die die Diskussion um die Automatisierbarkeit von Führungsentscheidungen neu entfachen wird.

Prof. Dr. Ulrich Hasenkamp

Vorwort An dieser Stelle möchte ich mich bei den Menschen bedanken, die zum Gelingen dieser Arbeit beigetragen haben. Meinem Doktorvater Prof. Dr. Ulrich Hasenkamp danke ich für die Betreuung meiner Arbeit und für die große akademische Freiheit, die er mir beim Erstellen der Arbeit eingeräumt hat. Herrn Prof. Dr. Erich Priewasser danke ich für die sofortige Bereitschaft, das Zweitgutachten zu übernehmen und sein Engagement bei der Erstellung desselben. Bedanken möchte ich mich zudem bei Herrn Prof. Dr. Michael Kirk für den Vorsitz im Prüfungsausschuss. Sehr geholfen haben mir die fachlichen Diskussionen und Anregungen im Rahmen des Doktorandenkolloquiums am Institut für Wirtschaftsinformatik. Hervorheben möchte ich meinen Freund und Kollegen Dr. Lars Burmester, der durch das Lesen unfertiger Textfragmente und fruchtbare inhaltliche Diskussionen wesentlich zum Gelingen der Arbeit beigetragen hat. Zudem danke ich Ivonne Krösehel für das sorgfältige Korrekturlesen. Eine Promotion ist ein umfangreiches Projekt, das mit viel Arbeit und Unsicherheit verbunden ist. Diese Herausforderung konnte ich nur meistern, weil meine geliebte Frau Marion neben ihrer eigenen Doktorarbeit immer ein offenes Ohr für meine Probleme und Sorgen hatte. Ich hoffe auf viele weitere glückliche Jahre mit ihr und möchte ihr diese Arbeit widmen. Sicherlich viel langweiliger wäre unsere Promotionszeit ohne unsere Freunde Karsten und

Anne geworden. Dafür herzlichen Dank! Abschließend danke ich meinen Eltern für ihre Zuneigung und die vermittelten Werte sowie für ihre Unterstützung bei meinen Plänen und Vorhaben. Jonas Rommelspacher

Inhaltsübersicht Teil I: Prablemstelluns, Terminologie und Grundlagen ................................... 1 1

Einführung ..................................................................................................3

2

Terminologie und Grundlagen der Informationssystementwicklung....... 25

Teil 11: Forschunpgegenstand ...................................................................... 59

3

(Führungs-)Entscheidungen und deren Automatisierung ........................ 61

4

Informationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen ......................................................................93

Teil"': Erkenntnisangebot ......................................................................... 145

5

Framework zur Automatisierung von Führungsentscheidungen ........... 147

6

Modeilierungssprachen für das AvFe-Framework .................................. 183

Teil IV: Begründung ................................................................................... 225

7

Prototyp ..................................................................................................227

8

Konformitätstest.. ...................................................................................259

9

Fazit ........................................................................................................ 263

Anhang ...................................................................................................... 265 Lfteraturverzelchnls ....................................................................................281

Inhaltsverzeichnis Tell I: Problemstellung, TermlnolOJie und Grundlagen ................................... l 1

2

Einführung .................................................................................................. 3 1.1

Problemstellung und Forschungsziele ................................................... 3

1.2

Forschungskonzeption und Aufbau der Arbeit ...................................... 5 1.2.1

Forschungsparadigma .................................................................. 8

1.2.2

WIssenschaftstheoretische Grundpositionen ............................ 12

1.2.2.1

Wissenschaftstheoretische Fundierung des konstruktionsorientierten Forschungsparadigmas .......... 15

1.2.2.2

Wissenschaftstheoretische Grundpositionen dieser Arbeit ..................................................................... 16

1.2.3

Forschungsmethode ................................................................... 18

1.2.4

Aufbau der Arbeit ....................................................................... 23

Terminologie und Grundlagen der Informationssystementwicklung ....... 25 2.1

Information .......................................................................................... 26

2.2

Informationssystem .............................................................................28

2.3

Frameworks ......................................................................................... 32

2.4

Modelle ................................................................................................ 34 2.4.1

2.5

2.6

Perspektiven auf den allgemeinen Modellbegriff ...................... 35

2.4.2

Modellbegriff dieser Arbeit ....................................................... .42

2.4.3

Informationsmodelle ..................................................................43

Modellierungstechniken und ihre Bestandteile ................................. .46

2.5.1

Modellierungssprache ............................................................... .47

2.5.2

Handlungsanleitung ...................................................................51

2.5.3

Metamodelle einer Modellierungstechnik ................................. 52

Ereignis ................................................................................................. 54

XII

Inhaltsverzeichnis

Teil 11: Forschungsgegenstand .........................•............................•............... 59 3

(Führungs-)Entscheidungen und deren Automatisierung ........................ 61 3.1

3.2

3.3

4

Entscheidungen und Entscheidungsmodelle ....................................... 61 3.1.1

Die allgemeine Struktur von Entscheidungen ............................ 62

3.1.2

Entscheidungsmodelle ............................................................... 68

Entscheidungen von Führungskräften ................................................. 70 3.2.1

Führungsentscheidungen - eine betriebswirtschaftliche Darstellung .................................................................................70

3.2.2

Die Bestandteile von Führungsentscheidungen .........................73

Ansätze zur Automatisierung von Führungsentscheidungen ..............80 3.3.1

Die "Programmierung" von Entscheidungen .............................80

3.3.2

Anforderungen an ein System zur Automatisierung von Führungsentscheidungen ...........................................................85

Informationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen ......................................................................93 4.1

Analytische Informationssysteme ........................................................94 4.1.1

Datennutzung analytischer Informationssysteme .....................97

4.1.2

Datenbereitstellung analytischer Informationssysteme ............99

4.1.3

Datenhaltung analytischer Informationssysteme .................... 104

4.1.3.1

Data-Warehouse-Konzept .............................................. 105

4.1.3.2

Die Architektur eines Data-Warehouse-Systems ............ 107

4.1.4 4.2

4.3

Beurteilung analytischer Informationssysteme ....................... 111

Ereignisgetriebene Informationssysteme ..........................................111 4.2.1

Aktive Datenbanksysteme ........................................................ 113

4.2.2

Datenströme und Datenstrommanagement-Systeme ............. 116

4.2.3

Complex Event Processing ........................................................ 120

4.2.4

Beurteilung ereignisgetriebener Informationssysteme ........... 124

Existierende Informationssysteme zur Automatisierung von Führungsentscheidungen ..................................................................126 4.3.1

Active Data Warehouse ............................................................ 128

XIII

Inhaltsverzeichnis

4.3.1.1

Begriffliche Grundlegung ................................................128

4.3.1.2

Das Active-Data-Warehouse-Konzept von Thalhammer et al ...........................................................131

4.3.2 4.4

Beurteilung des Active-Data-Warehouse-Ansatzes ................. 140

Zwischenfazit .....................................................................................142

Teil 111: Erkenntnisangebot ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 145 5

Framework zur Automatisierung von Führungsentscheidungen ........... 147 5.1

5.2

Gestaltungsoptionen zur Weiterentwicklung von Entscheidu ngsprogrammen ...............................................................147 5.1.1

Die Absorption von Dynamik durch Konditionalprogramme ... 148

5.1.2

Integration von Konditional- und Zweckprogrammen durch Programmverschachtelung ......................................................151

5.1.3

Schlussfolgerungen aus den systemtheoretischen Gestaltungsoptionen für das AvFe-Framework ....................... 155

Automatisierung von Führungsentscheidungen durch Programmverschachtelung: Das AvFe-Framework ............................ 156 5.2.1

5.2.1.1

Zweckregeln ....................................................................156

5.2.1.2

Daten zur Prüfung der Ziel erreichung ............................ 159

5.2.1.3

Detaillierung der Funktion Entscheidung ....................... 161

5.2.1.4

Anbindung von ECA-Regeln und Integration der Teilmodelle zu einer Programmhierarchie ..................... 165

5.2.2

Modelle einer mehrgliedrigen Programmhierarchie ............... 169

5.2.2.1

Zweckregel-Hierarchien ..................................................169

5.2.2.2

Daten zur Prüfung der Zielerreichung in mehrgliedrigen Programmhierarchien ....................................................179

5.2.3 6

Modelle einer einfachen Programmhierarchie ........................ 156

Zusammenfassung ....................................................................180

Modellierungssprachen für das AvFe-Framework .................................. 183 6.1

Die abstrakte Syntax des AvFe-Frameworks ......................................183

XIV

Inhaltsverzeichnis

6.2

6.1.1

Die Konstruktion von sprach basierten Metamodellen mit der Objekttypenmethode ...............................................................184

6.1.2

Das sprach basierte Metamodell des AvFe-Frameworks .......... 189

6.1.2.1

Das Metamodell von Zweckregel-Hierarchien ................ 190

6.1.2.2

Das Metamodell multidimensionaler Daten nach Goeken ................................................................... 194

6.1.2.2.1

Die abstrakte Syntax qualifizierender Informationen 194

6.1.2.2.2

Die abstrakte Syntax quantifizierender Informationen .............................................................200

6.1.2.3

Die Metamodelle von ECA-Regel und Aktivierungsmatrix ......................................................... 202

6.1.2.4

Integration der (Teil-)Metamodelle ................................204

Auswahl und Konstruktion von Modellierungssprachen ...................207 6.2.1

Repräsentationsanalyse von Modellierungssprachen ............. 207

6.2.2

Das multidimensionale Entity-Relationship-Modell zur Modeliierung multidimensionaler Daten .................................209

6.2.2.1 6.2.2.2

Die konkrete Syntax des MER-Modells ...........................212

6.2.2.3

Repräsentationsanalyse des MER-Modells .....................212

6.2.3

Ein erweitertes MER-Modell zur Modellierung von ZweckregelHierarchien ...............................................................................214

6.2.3.1

Die abstrakte Syntax des erweiterten MER-Modells ...... 214

6.2.3.2

Die konkrete Syntax des erweiterten MER-Modells anhand eines Fallbeispiels ...........................................................217

6.2.4

6.3

Die abstrakte Syntax des MER-Modells ..........................210

Der regel basierte ModelIierungsansatz zur ModelIierung von ECA-Regeln ...............................................................................219

6.2.4.1

Die abstrakte Syntax des regelbasierten Modellierungsansatzes ...................................................219

6.2.4.2

Die konkrete Syntax des regelbasierten Modellierungsansatzes ...................................................221

6.2.4.3

Repräsentationsanalyse des regel basierten Ansatzes .... 221

Zusammenfassung .............................................................................223

Inhaltsverzeichnis

Teil IV: Begründung ................•...................................................•.............. 225 7

Prototyp ..................................................................................................227 7.1

GoodBank AG .....................................................................................227

7.2

Räumlich differenzierte Preis politik für Konsumentenkredite .......... 228 7.2.1

Datenbank zur Vergabe der Konsumentenkredite ................... 230

7.2.2

Konzeptionelle Modelle zur Automatisierung der Führungsentscheidung .............................................................231

7.2.2.1

Multidimensionale Daten zur Überprüfung der Zielerreichung .................................................................231

7.2.2.2

ECA-Regeln und Aktivierungsmatrix ............................... 232

7.2.2.3

Zweckregel-Hierarchie Preis politik ................................. 235

7.2.3

7.3

Prototypische Implementierung mit Microsoft SQL Server 2008 .......................................................................237

7.2.3.1

Implementierung des Hypercubes GoodBankl.. ............ 237

7.2.3.2

Implementierung von ECA-Regeln und Speicherung der Aktivierungsmatrizen .....................................................240

7.2.3.3

Implementierung der Zweckregel-Hierarchie Preispolitik ......................................................................242

Prüfung der Kreditwürdigkeit ............................................................247 7.3.1

Daten zur Prüfung der Kreditwürdigkeit .................................. 248

7.3.2

Konzeptionelle Modelle zur Automatisierung der Führungsentscheidung .............................................................249

7.3.2.1

Multidimensionale Daten zur Prüfung der Zielerreichung .................................................................249

7.3.2.2

ECA-Regeln und Aktivierungsmatrix ............................... 250

7.3.2.3

Zweckregel-Hierarchie Kreditwürdigkeit ........................ 252

7.3.3

Prototypische Implementierung mit Coral8 und Microsoft SQL Server 2008 .......................................................................253

7.3.3.1

Implementierung des Hypercubes GoodBank_KW ........ 254

7.3.3.2

Implementierung der ECA-Regeln mit CoraI8 ................. 255

7.3.3.3

Implementierung der Zweckregel-Hierarchie Kreditwürdigkeit.. ...........................................................257

XVI

Inhaltsverzeichnis

8

Konformitätstest .....................................................................................259

9

Fazit ........................................................................................................263

Anhang •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 265 A

B

Entity-Relationship-Modell .....................................................................267 A.1

Sprachbasiertes Metamodell zur Definition der abstrakten Syntax .................................................................................................267

A.2

Die konkrete Syntax des Entity-Relationship-Modells ....................... 269

Ereignisgesteuerte Prozessketten ..........................................................271 B.1

B.2

Modellierungssprache .......................................................................271 B.1.1

Sprachbasiertes Metamodell zur Definition der abstrakten Syntax .......................................................................................271

B.1.2

Die konkrete Syntax ereignisgesteuerter Prozessketten ......... 276

Prozessorientiertes Metamodell zur Definition der Handlungsanleitung ...........................................................................276

Literaturverzeichnis ....................................................................................281

Abbildungsverzeichnis Abbildung 1:

Konstruktion der Forschungskonzeption .................................... 7

Abbildung 2:

Konzepte einer Forschungsmethodik ....................................... 19

Abbildung 3:

Modell der Forschungsmethodik .............................................. 22

Abbildung 4:

Aufbau der Arbeit ..................................................................... 23

Abbildung 5:

Modellverständnis 5tachowiaks ............................................... 37

Abbildung 6:

Perspektiven auf den allgemeinen Modellbegriff ................... .41

Abbildung 7:

Informationsmodellklassen ......................................................44

Abbildung 8:

Modellierungstechnik ...............................................................46

Abbildung 9:

Metamodelle .................................................................. ..........53

Abbildung 10: Uneare Interdependenzen ........................................................64 Abbildung 11: ZIelsystem ................................................................................. 65 Abbildung 12: Konditionalprogramm ............................................................... 82 Abbildung 13: Bezugsobjekthierarchien .......................................................... 88 Abbildung 14: Mehrdimensionales Untersuchungsumfeld ............................. 90 Abbildung 15: Entscheidungsunterstützung und -automatisierung ................ 93 Abbildung 16: Informationssystempyramide ................................................... 96 Abbildung 17: Schalenmodell der analytischen Informationssysteme zur Oatennutzung ..................................................................... 98 Abbildung 18: Konzeptionelles Modell eines Hypercubes ............................. 101 Abbildung 19: Hypercube mit Elementen ......................................................102 Abbildung 20: SlIce-Operation ....................................................................... 103 Abbildung 21: Dice-Operation ........................................................................ 103 Abbildung 22: Drill-down und Roll-up ............................................................104 Abbildung 23: Data-Warehouse-Architektur ................................................. 108

XVIII

Abbildungsverzeichnis

Abbildung 24: ECA-Regel ................................................................................112 Abbildung 25: Funktionsweise eines DSMS ...................................................118 Abbildung 26: Ereigniswolke ..........................................................................121 Abbildung 27: Das komplexe Ereignis Front Running als Ereignisdiagramm .123 Abbildung 28: Latenzarten .............................................................................129 Abbildung 29: Architektur eines Active Data Warehouses ............................ 132 Abbildung 30: Einfache Programmhierarchie ................................................ 153 Abbildung 31: Zweckregel ..............................................................................157 Abbildung 32: Datenmodell mit Soll- und Ist-Daten ......................................160 Abbildung 33: Modelle einer Programmhierarchie .......................................167 Abbildung 34: Dimension Vertriebsort auf Typ- und Ausprägungsebene ..... 170 Abbildung 35: Zweckregel-Hierarchie ............................................................ l72 Abbildung 36: Heterarchie .............................................................................175 Abbildung 37: Parallele Hierarchie ................................................................. 176 Abbildung 38: Unterschiedliche pfadlängen .................................................. 176 Abbildung 39: Analysegraph von Thalhammer et al. .....................................178 Abbildung 40: Ist- und Soll-Daten ..................................................................180 Abbildung 41: Systematisierung von Abstraktionsprinzipien ........................ 187 Abbildung 42: Teilmodelle des sprachbasierten Metamodells ...................... 190 Abbildung 43: Metamodell der Zweckregel-Hierarchie ................................. 193 Abbildung 44: Metamodell multidimensionaler Daten (I) ............................. 195 Abbildung 45: Assoziation in einer Hierarchie ...............................................196 Abbildung 46: Metamodell multidimensionaler Daten (11) ............................ 197 Abbildung 47: Abstraktionsprinzipien auf Typ- und Ausprägungsebene ....... 198 Abbildung 48: Metamodell multidimensionaler Daten (111) ........................... 199 Abbildung 49: Metamodell der abstrakten Syntax multidimensionaler Datenmodelle .........................................201

Abbildungsverzeichnis

XIX

Abbildung 50: Metamodell der ECA-Regel. .................................................... 202 Abbildung 51: Metamodell von ECA-Regel und Aktivierungsmatrix .............. 204 Abbildung 52: Metamodell des AvFe-Frameworks ........................................ 206 Abbildung 53: Sprachbasiertes Metamodell des MER-Modells ..................... 211 Abbildung 54: Die konkrete Syntax des MER-Modells ................................... 212 Abbildung 55: Erweiterungen des MER-Metamodells ................................... 216 Abbildung 56: Zweckregel-Hierarchie mit dem erweiterten MER-Modell .... 218 Abbildung 57: Submodel Business Rule .........................................................220 Abbildung 58: Geschäftsregeln in ECAA-, ECA- und EA-Notation .................. 221 Abbildung 59: Prozesslandkarte GoodBank AG ............................................. 228 Abbildung 60: Vertriebsstruktur der GoodBank AG ....................................... 229 Abbildung 61: Relationenschema der Datenbank GoodBank_OLTP .............. 230 Abbildung 62: Konzeptionelles Modell des Hypercubes GoodBank1 ............ 232 Abbildung 63: ECA Regel "Filiale9-1" .............................................................233 Abbildung 64: Zweckregel-Hierarchie Preispolitik ......................................... 236 Abbildung 65: Datenquellensicht GoodBank1 ............................................... 238 Abbildung 66: Datenfluss der Zweckregel Gesamtvertrieb ........................... 243 Abbildung 67: Ergebnis der MDX-Abfrage ..................................................... 244 Abbildung 68: Ablaufsteuerung der Zweckregel-Hierarchie Preispolitik ....... 245 Abbildung 69: Konzeptionelles Modell des Hypercubes Goodbank_KW ....... 250 Abbildung 70: ECA-Regel Kredit1JO .............................................................251 Abbildung 71: Zweckregel-Hierarchie Kreditwürdigkeit ................................ 253 Abbildung 72: Datenquellensicht GoodBank_KW .......................................... 254 Abbildung 73: Datenfluss Coral8-Projekt Kredit1_70 .................................... 256 Abbildung 74: Ablaufsteuerung der Zweckregel-Hierarchie Kreditwürdigkeit .....................................................................258 Abbildung 75: Sprachbasiertes Metamodell des ER-Modells ........................ 268

xx

Abbildungsverzeichnis

Abbildung 76: Die konkrete Syntax des ER-Modells ......................................270 Abbildung 77: Sprachbasiertes Metamodell der EPK .....................................272 Abbildung 78: Sprachbasiertes Metamodell der eEPK ...................................275 Abbildung 79: Die konkrete Syntax der EPK ................................................... 276 Abbildung 80: Prozessorientiertes Metamodell der EPK ...............................279

Tabellenverzeichnis Tabelle 1:

Klassifikationsmerkmale von Informationssystemen ............... 31

Tabelle 2:

Ergebnismatrix .......................................................................... 68

Tabelle 3:

Formulierungsdefekte von Zielen ............................................. 78

Tabelle 4:

Anforderungen .......................................................................... 92

Tabelle 5:

Fachliche Anforderungen an operative und analytische Informationssysteme ................................................................ 97

Tabelle 6:

CL-Anfrage ..............................................................................119

Tabelle 7:

Struktur von Analyseregeln .................................................... 134

Tabelle 8:

Primäre Dimensionsebene Produkt ........................................135

Tabelle 9:

Hypercube SalesMarburgThisYear und zugehöriger Entscheidungsschritt ............................................................... 137

Tabelle 10:

Anatyseregel ChangePriceofproducts ....................................•139

Tabelle 11:

Ergebnismatrix von ECA-Regeln mit Zuständen ..................... 162

Tabelle 12:

Vollkommenes Informationssystem-Modell .......................... 164

Tabelle 13:

Kennzahlenbereiche ............................................................... 164

Tabelle 14:

Aktivierungsmatrix .................................................................. 165

Tabelle 15:

Zweckregel-Hierarchie in Tabellenform .................................. 174

Tabelle 16:

Repräsentationsanalyse des MER-Modells ............................. 213

Tabelle 17:

Repräsentationsanalyse des regel basierten Ansatzes ............ 222

Tabelle 18:

Tabelle Kredit der Datenbank GoodBank_OLTP .....................233

Tabelle 19:

Aktivierungsmatrix Konsumentenkredit_Flliale9 ...................234

Tabelle 20:

MDX-Skript zur Berechnung von Kennzahlenwerten .............239

Tabelle 21:

MDX-Skript zur Berechnung des KPI-Status ............................ 240

Tabelle 22:

T-SQL-Skript zur Definition einer ECA-Regel ........................... 241

XXII

Tabellenverzeichnis

Tabelle 23:

Konnektortabelle KonsumentenkreditJiliale9 ......................242

Tabelle 24:

Multidimensionale MDX-Anfrage ...........................................243

Tabelle 25:

Daten zur Prüfung der persönlichen Kreditwürdigkeit ........... 249

Tabelle 26:

Konnektortabelle Kreditl ....................................................... 257

Tabelle 27:

Beschränkungen der direkten Vorgänger-Nachfolger-Beziehung ........................................... 274

Tabelle 28:

Modellierungssprachen und verwendete Elementtypen ....... 277

Abkürzungsverzeichnis ARIS

Architektur integrierter Informationssysteme

AvFe-Framework

Framework zur Automatisierung von Führungsentscheidungen

bzgl.

bezüglich

CCL

Continuous Computation Language

CEP

Complex Event Processing

CQL

Continuous Query Language

DBMS

Datenbankmanagement-System

DSMS

Datenstrommanagement-System

DSS

Decision Support Systems

ECA

Event Condition Action

eEPK

erweiterte ereignisgesteuerte Prozessketten

EIS

Executive Information Systems

eo

element-of

EPK

Ereignisgesteuerte Prozessketten

ER-Modell

Entity-Relationship-Modell

FASMI

Fast Analysis of Shared Multidimensionalinformation

Fn.

Fußnote

GoM

Grundsätze ordnungsmäßiger Modellierung

hA

hinreichende Anforderung

IKS

Informations- und Kommunikationssysteme

io

instance-of

IS

Informationssysteme

ISR

Information Systems Research

KI

Künstliche Intelligenz

Abkürzungsverzeichnis

XXIV

KPI

Key Performance Indieator

MDX

Multidimensional Expressions

MER-Modell

Multidimensionales Entity-Relationship-Modell

MIS

Managementinformationssystem

MSDNAA

Microsoft Developer Network Academic Alliance

MSS

Management Support Systems

nA

notwendige Anforderung

o.J.

ohne Jahr

ODS

Operational Data Store

OLAP

Online Analytical Processing

OLTP

Online Transaction Processing

pO

part-of

SQL

Structured Query Language

SSAS

SQL Server Analysis Services

5515

SQL Server Integration Services

sso

subset-of

sto

subtype-of

WKD

Wertschöpfungskettendiagramm

WKWI

Wissenschaftliche Kommission Wirtschaftsinformatik

XPS

Expertensysteme

ZE

Zielerreichungsgrad

Teil I: Problemstellung, Terminologie und Grundlagen

1

Einführung

1.1

Problemstellung und Forschungsziele

• Will the corporotion be managed by machines?n1 In den vergangenen Jahren sind auf sämtlichen ökonomischen Märkten tiefgreifende Veränderungen zu beobachten, welche die Arbeit von Führungskräften deutlich erschweren. Zum einen ist auf der Nachfrageseite eine zunehmende Individualisierung zu konstatieren, was bspw. zu wachsender Produktvielfalt und neuen Geschäftsmodellen zum profitablen Verkauf von Nischenprodukten (.the long tail·) führt.' Zum anderen ermöglicht moderne Informationstechnologie auf der Angebotsseite eine bessere Informationsdiffusion, was zu einem extrem harten Wettbewerb (.Hypercompetition·) zwischen den Anbietern führt.' Eine Konsequenz der skizzierten Entwicklung ist, dass die Führungskräfte der involvierten Unternehmen eine ständig steigende Anzahl an bedeutenden und umfassenden Entscheidungen - sogenannte Führungsentscheidungen - treffen müssen, damit die Unternehmen in dem beschriebenen Wettbewerbsumfeld erfolgreich bestehen können.' Da viele dieser Entscheidungen zur Erzielung des maximalen ökonomischen Effekts zudem mit möglichst wenig Latenz getroffen werden müssen, stellt sich die Frage, wie Führungskräfte die ständig wachsende Zahl an Entscheidungen in ihrer knappen Arbeitszeit bewältigen können.'

Siman (1977), S. 11. Vgl. Bucklin et 01. (199B), S. 239 11.; Anderson (2006). Vgl. D'Aveni, Gunther (1994). Vgl. Bucklin et al. (1998), S. 239. Der Begriff der Führungsentscheidung wird ausführlich in Abschnitt 3.2 behandelt. Latenz beschreibt den Zeitraum zwischen dem Eintreten eines Ereignisses und dem Treffen einer entsprechenden Maßnahme. Die Minimierung der Latenz ist bei Führungsentscheidungen unter der Annahme sinnvoll, dass der Wert einer Entscheidung umso größer

ist, je früher diese ergriffen wird. Siehe ausführlich Abschnitt 4.3.1.1.

J. Rommelspacher, Automatisierung von Führungsentscheidungen, DOI 10.1007/978-3-8348-8251-6_1, © Vieweg + Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

Einführung

4

Führungskräfte werden bei ihren Entscheidungen durch analytische Informationssysteme unterstützt." Diese Systeme sind in den vergangenen Jahrzehnten konzeptionell und technisch gereift, wodurch sich Informationsversorgung und Entscheidungsunterstützung von Fach- und Führungskräften grundlegend verbessert haben.' Analytische Informationssysteme zielen allerdings auf eine Steigerung der Entscheidungsqualität und weniger auf eine Steigerung der Entscheidungsquantität ab. Da die bereitgestellten Informationen teilweise aufwändig verarbeitet werden müssen, sind sogar negative Effekte auf die Entscheidungsquantität denkbar. Ausgehend von den geschilderten Rahmenbedingungen ist die Überlegung naheliegend, strukturierte, explizierbare und regelmäßig auftretende Führungsentscheidungen zu automatisieren." Dadurch können Führungskräfte von Entscheidungen entlastet werden, sodass diese sich auf unstrukturierte und nicht-automatisierbare Entscheidungen konzentrieren können. In der Literatur existieren einige Ansätze zur Automatisierung von Führungsentscheidungen.

9

Diese zielen darauf ab analytische Informationssysteme um (aktive) Komponenten anzureichern, die beim Eintreten wohldefinierter Ereignisse selbstständig Aktionen anstoßen und somit Entscheidungen treffen. Obgleich von Praktikern ein ho her Bedarf an derartigen Systemen geäußert wird'o und sich die Wissenschaft bereits seit langem mit solchen Systemen beschäftigt, ist die praktische Akzeptanz und Verbreitung bisher als gering einzuschätzen." Der Grund für die geringe Verbreitung wird darin gesehen, dass die bisher vorgeschlagenen Ansätze die Automatisierung von Führungsentscheidungen

Das Ziel analytischer Informationssysteme ist es. den adäquaten Zugang von Fach- und Führungskräften zum Produktionsfaktor Information sicherzustellen und dadurch (taktische und strategische) Entscheidungen zu unterstützen und zu verbessern. Siehe Abschnitt 4.1 zu einer detaillierten Auseinandersetzung mit analytischen Informationssystemen. Vgl. zu Reifegradmodellen (Maturity Models) Eckerson (2004); Dittmar, Schulze (2006);

Schulze, Dittmar (2006). Vgl. zu empirischen Untersuchungen des Reifegrades Chamoni et al.

(2004); Chamoni, Gluchowski (2004).

10

11

Die Übernahme menschlicher Aufgaben durch Maschinen wird im Folgenden als Automatisierung bezeichnet. Siehe Abschnitt 4.3. Vgl. Russel (2007), S. 4 ff.j Vesset (2007), S. 5. In einer Studie stellen Chamoni et al. (2004), S. 126 f. fest, dass weniger als 1 % der befragten Unternehmen ein sogenanntes Active Oata Warehause einsetzen.

Forschungskonzeption und Aufbau der Arbeit

s

nicht auf die richtige Art und Weise unterstützen. Ehe diese These überprüft werden kann, ist zunächst zu zeigen, dass Führungsentscheidungen grundsätzlich automatisierbar sind. Anschließend werden aus theoretischen und praktischen Überlegungen Anforderungen formuliert, die ein Informationssystem erfüllen muss, um Führungsentscheidungen automatisieren zu können. Es lässt sich somit zusammenfassen: Das erste Forschungsziel dieser Arbeit ist es zu ermitteln, ob und wie Führungsentscheidungen automatisiert werden können. Die hergeleiteten Anforderungen können anschließend existierenden Ansätzen zur Automatisierung und Unterstützung von Führungsentscheidungen gegenübergestellt werden, wodurch Entwicklungsdefizite erkennbar werden. Für die dabei ermittelten Defizite werden im weiteren Verlauf der Arbeit Lösungsvorschläge erarbeitet. Das zweite Forschungsziel besteht in der Entwicklung von Lösungsvorschlägen zur Beseitigung der ermittelten Entwicklungsdefizite bei der Automatisierung von Führungsentscheidungen.

1.2

ForschungskonzeptIon und Aufbau der Arbeit

Nachdem im vergangenen Abschnitt mit den Forschungszielen definiert wurde,

was in dieser Arbeit erforscht wird, wird in diesem Abschnitt hergeleitet, wie die Forschungsziele erreicht werden können. Zugleich können die Forschungsziele im Laufe des Abschnitts detailliert werden. Bei der Suche nach einer geeigneten Forschungskonzeption ist die Orientierung an existierenden Konzeptionen der wissenschaftlichen Gemeinschaft - in dieser Arbeit ist dies die Wirtschaftsinformatik - naheliegend." Allerdings gibt es sowohl in der Wirtschaftsinformatik als auch in der nordamerikanisch geprägten Information Systems Research (lSR) - wenn auch mit unterschiedlichen Vorzeichen - eine kontroverse Diskussion darüber, welches Forschungsparadigma und welche Forschungsmethoden zu den gewünschten Forschungser-

12

Vgl. Schütte (1999), S. 214.

6

Einführung

gebnissen führen." Ohne die Diskussion hier im Einzelnen nachzuvollziehen, ist zu konstatieren, dass es keine allgemein anerkannte Forschungskonzeption in der Wirtschaftsinformatik gibt, an der sich der Forscher orientieren kann. Es scheint sich vielmehr - ebenso wie in anderen Wissenschaften, die von Menschen geschaffene Gegenstände (sogenannte Artefakte

l4

)

untersuchen - die

Position durchzusetzen, dass sowohl präskriptive als auch deskriptive Forschungsmethoden notwendig sind.

lS

Ausgehend von der Überlegung, dass sich

Wissenschaftler in einer pluralistischen und multiparadigmatischen Disziplin wie der Wirtschaftsinformatik weitgehend frei positionieren können, gewinnt Transparenz eine wesentliche Bedeutung: Nur wenn Konstruktionsentscheidungen und Annahmen einer Forschungskonzeption transparent gemacht werden, können die Forschungsergebnisse von der wissenschaftlichen Gemeinschaft eindeutig nachvollzogen und beurteilt werden. Dabei kann auf umfangreiche Vorarbeiten der Wissenschaftstheorie zurückgegriffen werden. Darüber hinaus gibt es innerhalb der Wirtschaftsinformatik (und auch der ISR) eine Fülle an wissenschaftstheoretischen Diskussionen und Vorarbeiten.

13

Die ISR Ist traditionell geprägt von einem verhaltenwissenschaftlichen Forschungsparadigma. Bereits seit Ende der 1980er Jahre wird in der ISR unter der Dichotomie uRigor vs. Relevance"

darüber diskutiert, ob die empirische Forschung verhaltenswissenschaftlicher Prägung zu den gewünschten Forschungsergebnissen führt und wie diese verbessert werden können. Vgl.

Galliers, land (1987); Banville, landry (1989); March, Smith (1995); Galliers (1995); Benbasat, Weber (1996); Siman (1996); Keck

14

15

et al. (2002); Benbasat, Zmud (2003); Rosemann, Vessey

(2008). Im Zuge dieser Diskussion ist die Bedeutung des konstruktionsorientierten Forschungsparadigmas in der ISR grundsätzlich gewachsen. Vgl. March, Smith (1995); Hevner et al. (2004); Frank (2006); Frank (2007); Zelewski (2007). Obwohl die Wirtschaftsinformatik traditionell einen Methodenpluralismus verfolgt, ist sie doch stark geprägt vom konstruktionsorientierten Forschungsparadigma. Vgl. zur wissenschaftstheoretischen Diskussion in der Wirtschaftsinformatik: Schütte (1998); Dresbach (1999); Schütte (1999); Frank (2002); Becker et al. (2003a); Frank (2003); Goeken (2003); Frank (2006); Becker, Niehaves (2007). Aufgrund zunehmender internationalisierungstendenzen wird in jüngster Zeit das verhaltensorientierte Forschungsparadigma auch in der Wirtschaftsinformatik stärker berücksichtigt. Der Begriff stammt von den lateinischen Begriffen ars und factum ab und bedeutet wörtlich "das durch Bearbeitung Gemachte". Vgl. March, Smith (1995) S. 252; Hevner et al. (2004). Während bei deskriptiven Erkenntniszielen die Erforschung und das Verständnis der Realität von zentraler Bedeutung sind, zielen präskriptive Gestaltungsziele auf die Schaffung und Veränderung realer Dinge und Sachverhalte ab. Vgl. zu dieser Differenzierung Becker et al. (2003a), S. 11 ff.; Goeken (2003), S. 11 ff.

Forschungskonzeption und Aufbau der Arbeit

7

Im Folgenden wird die Forschungskonzeption dieser Arbeit schrittweise hergeleitet, wobei zunächst in Abschnitt 1.2.1 ausgehend von den dargestellten Forschungszielen ein Forschungsparadigma ausgewählt wird, dem in dieser Arbeit gefolgt wird. Dieses gibt bereits einen gewissen Rahmen bzgl. der wissenschaftsthearetischen Grundpositionen vor, die anschließend in Abschnitt

1.2.2 definiert werden. Darauf aufbauend wird in Abschnitt 1.2.3 eine Forschungsmethode konfiguriert, mit deren Hilfe die definierten Forschungsziele

erreicht werden können. Aus der damit fertiggestellten Forschungskonzeption ergibt sich der Aufbau der Arbeit, welcher in Abschnitt 1.2.4 präsentiert wird. Die Konstruktion der Forschungskonzeption ist überblicksartig in Abbildung 1 dargestellt. Durch die nach unten abnehmende Balkenbreite ist angedeutet, dass die Entscheidungsspielräume in Abhängigkeit von den bereits getroffenen Entscheidungen von oben nach unten abnehmen. Abbildung 1: Konstruktion der Forschungskonzeption

Forschungsziele '--_ _ _ _ _ _ _ _ _....:..:;(Abschnitt lr.1.'-J_ _ _ _ _ _ _ _ _----'

Forschungsparadigma (Abschnitt 1.2.1) L -_ _ _ _ _ _ _ _~~ r~--------~

Wissenschaftstheoretische Gru ndpositionen (Abschnitt 1.2.2)

~------....:..:;

~------~

Aufbau der Arbeit (Abschnitt 1.2.4)

8

Einführung

1.2.1

Forschungsparadigma

Wissenschaftliche Erkenntnis ist nach FRANK durch die Merkmale Originalität, Abstraktion und Begründung geprägt." Die Originalität betont, dass es sich nur um wissenschaftliche Erkenntnis handelt, wenn diese neuartig in Bezug auf den bisherigen Wissensbestand einer Disziplin ist. Wissenschaftliche Forschung zielt außerdem auf allgemeingültige, d. h. abstrakte Aussagen ab. Die Forderung nach Abstraktion schließt Aussagen, die lediglich einzelne Beispiele erklären oder beschreiben, aus. Aus einer originellen und abstrakten Aussage wird allerdings erst eine wissenschaftliche Erkenntnis, wenn für die Aussage eine wissenschaftliche Begründung gegeben wird. Ein Forschungsparadigma stellt einen Rahmen für wissenschaftliche Forschung zur Verfügung und beschreibt die Vorgehensweise, wie wissenschaftliche Erkenntnis (mit den beschriebenen Merkmalen) erlangt werden kann.

17

Aus die-

ser Beschreibung lässt sich eine .Grobstruktur· bzgl. möglicher wissenschaftstheoretischer Grundpositionen und Forschungsmethoden ermitteln. Dabei können innerhalb einer Disziplin mehrere Forschungsparadigmen parallel existieren, wobei eine Forschungsarbeit in Abhängigkeit von den verfolgten Forschungszielen jeweils einem bestimmten Forschungsparadigma fOlgt.18 In der Wirtschaftsinformatik und ISR sind zwei Forschungsparadigmen verbreitet, zwischen denen sich der Forscher in Abhängigkeit von seinen Forschungszielen entscheiden muss. 1. Das verhaltenswissenschaftliche Forschungsparadigma wurde ursprünglich in der Psychologie entwickelt und zielt darauf ab, das Verhalten von Lebewesen mithilfe naturwissenschaftlicher Forschungsmethoden zu untersuchen.'" Das Merkmal der Neuartigkeit ist im verhaltenswissenschaftlichen 16 11

18 19

Vgl. Frank (2006), S. 33 ff.; Frank (2007), S. 172. Der Begriff des Forschungsparadigmas geht zurück auf Kuhn (1975). Er unterscheidet verschiedene Phasen des wissenschaftlichen Forschens. Nach einer "vorparadigmatischen Phase" gibt es in "normalen Zeiten" ein dominierendes Paradigma, das einen Rahmen für wissenschaftliche Forschung bereitstellt. In "revolutionären Zeiten" kommt es im Anschluss an Probleme mit dem geltenden Paradigma zu einem Paradigmenwechsel. Nach Kuhn wird wissenschaftlicher Fortschritt Insbesondere in revolutionären Zeiten generiert. Im Gegensatz zu Kuhn geht der Verfasser nicht davon aus, dass In einer wissenschaftlichen Disziplin (dauerhaft) nur ein Forschungsparadigma existieren kann. Ähnlich argumentieren March, Smith (1995). Vgl. Frank (2007), S. 162.

Forschungskonzeption und Aufbau der Arbeit

9

Forschungsparadigma erfüllt, wenn aus Theorien interessante und neuartige Hypothesen über das (menschliche) Verhalten deduziert werden." Die Begründung wissenschaftlicher Hypothesen erfolgt durch die empirische Überprüfung derselben. Können Hypothesen nicht verworfen werden, so werden diese nach und nach zu leistungsfähigeren Theorien verdichtet. Diese Abstraktion zielt darauf ab, die Realität besser zu erklären (und vorherzusagen). In der ISR und in der Wirtschaftsinformatik werden mittels des verhaltenswissenschaftlichen Forschungsparadigmas Theorien überprüft und (weiter-)entwickelt, .that explain or predict organizational and human phenomena surrounding the analysis, design, implementation, management, and use of information systems.

u21

Zu diesem Zweck werden aus ein-

schlägigen Theorien" Hypothesen über Informationssysteme und deren Nutzung deduziert und empirisch überprüft." Die Forschungsergebnisse des verhaltenswissenschaftlichen Forschungsparadigmas sind primär deskri ptiver Art. 2. Das

24

konstruktionsorientierte

Forschungsparadigma

(Design

Science)

stammt aus den Ingenieurwissenschaften und zielt auf die Schaffung (und Evaluation) neuer und innovativer Gegenstände (Artefakte) zur Lösung identifizierter Probleme ab." In Anlehnung an BRETZKE wird in dieser Arbeit unter einem Problem eine .subjektiv wahrgenommene Abweichungen zwischen Erreichtem und Erwünschtem verbunden mit einem ursprünglichen Mangel an Wissen, diese Lücke zu schließen·,'· verstanden." Während das 20

In Anlehnung an den kritischen Rationalismus sind insbesondere Hypothesen mit einem hohen Informationsgehalt und hohem Widerlegungsrisiko zu bevorzugen. Vgl. zum kritischen Rationalismus Albert (1978); Albert (1982); Albert (1991); Popper, Feyerabend (1992a); Popper, Feyerabend 11992b); Albert (1994); Popper (1994); Popper (1998); Popper (2000); Popper (2004).

23

Hevner et al. (2004), S. 76. Eine Sammlung in der ISR verbreiteter Theorien findet sich unter http://www.fsc.yorku.ca/yorkjistheory/wiki/index.php/Main_Page. Vgl. Becker et al. (2003a), S. 3 f. Die empirische überprüfung setzt voraus, dass die zentralen Begriffe einer Hypothese so operationalisiert werden, dass sie empirisch überprüft werden können. Für die Datenerhebung stehen Verfahren wie Beobachtung.. Interviews oder auch Dokumentenanalysen zur Verfilgung.

"

Vgl. March, Smlth (1995), S. 252.

21 22

25 26 27

Vgl. March, Smith (1995), S. 253; Hevner et al. (2004), S. 77. Bretzke (1980), S. 34. Dresbach (1999), S. 76 ff. formuliert und diskutiert die Merkmale von Problemen ausführlich.

Einführung

10

Merkmal der Originalität im konstruktionsorientierten Forschungsparadigma verlangt, dass es sich um neuartige Probleme handelt, fordert die Abstraktion, dass mithilfe des konstruierten Artefakts eine ganze Klasse an Problemen gelöst wird. Die Forderung nach Abstraktion ist besonders zu betonen, da im Rahmen konstruktionsorientierter Forschung immer die Gefahr besteht, lediglich singuläre Problemlösungen (z. B. in Praxisprojekten) zu produzieren, die keinen (wissenschaftlichen) Erkenntnisgewinn darstellen.'· Das Begründungspostulat verlangt, dass die Anforderungen an ein Artefakt - also die Problembeschreibung - sowie spätere Entwurfsentscheidungen zu begründen und zu evaluieren sind." Während das Paradigma in der deutschen Wirtschaftsinformatik bei der Gestaltung prototypischer Artefakte zur Lösung konkreter Probleme der betrieblichen Praxis seit Jahrzehnten eine große Bedeutung hat, ist es in der ISR lange Zeit kaum beachtet worden. Obwohl bereits Mitte der 1990er Jahre die Verwendung des konstruktionsorientierten Paradigmas in der ISR gefordert wurde'", wird erst seit einem vielbeachteten Artikel von HEVNER et al." kontrovers über die Verwendung konstruktionsorientierter Forschungsmethoden für den wissenschaftlichen Entwurf von Artefakten diskutiert." Die Forschungsergebnisse des konstruktionsorientierten Forschungsparadigmas sind präskriptiv." Wie das zweite Forschungsziel der Arbeit erkennen lässt, orientiert sich die vorliegende Arbeit am konstruktionsorientierten Forschungsparadigma. Übertragen auf die Terminologie des Forschungsparadigmas werden die Entwicklungsdefizite bestehender Ansätze im Folgenden als auslösendes Problem und die zu entwickelnden Lösungsvorschläge als Artefakte bezeichnet. Je nach

" " 30

31

32 33

Vgl. Frank 12002), s. 7; Goeken 12003), S. 6; Frank 12006), S. 5; Frank (2007). Vgl. Frank (2007), S. 179. Vgl. March, Smith (1995). Nicht zu vergessen ist auch die Übertragung des konstruktionswissenschaftlichen Forschungsparadigmas auf die Forschung zur KOnstlichen Intelligenz durch Siman (1996). Vgl. Hevner et al. (2004). Vgl. Frank (2007), S. 167 ff.; Zelewski (2007). Vgl. March, Smith (1995), S. 252.

Forschungskonzeption und Aufbau der Arbeit

11

Unterstützung der Problemlösung, werden in dieser Arbeit Artefakte unterschieden in Frameworks, Modelle, Methoden, Techniken und Instanzen." Framewarks dienen der zweckgerichteten Strukturierung und Gestaltung eines 35

Untersuchungsgegenstandes. Zur Darstellung verschiedener Aspekte integrieren Frameworks heterogene Modelle, welche zur Lösung eines Problems erstellt werden und sich zur Komplexitätsreduktion auf einen ausgewählten Aspekt sowie ausgewählte Merkmale beschränken. Die Automatisierung von Führungsentscheidungen stellt ein komplexes Problem dar, bei dem verschiedene Aspekte zu lösen sind, die jeweils von Teilmodellen berücksichtigt werden. Zur Integration der verschiedenen Modelle wird in dieser Arbeit ein Framework zur Automatisierung von Führungsentscheidungen, das sogenannte AvFe-Framework, entwickelt. Dieses gibt eine grundsätzliche Orientierung, wie Führungsentscheidungen automatisiert werden können. Bei der Erstellung der Teilmodelle wird die fachliche (betriebswirtschaftliche) Beschreibung als wesentliche Herausforderung aufgefasst. Zur fachlichen Beschreibung ist insbesondere die Kommunikation mit Führungskräften und Fachabteilungen von Bedeutung, weshalb sich diese Arbeit auf sogenannte (fach-) konzeptionelle Modelle konzentriert." Die Begriffe Framework und Modell werden in den Abschnitten 2.3 bzw. 2.4 ausführlich diskutiert. Methoden sind Vorschriften wie planmäßig, angeleitet durch Prinzipien" zur

Erreichung festgelegter Ziele vorzugehen ist." Unter einer Methode wird ein weitgehender Ansatz verstanden, der vollständig beschreibt, wie relativ hoch angesiedelte Ziele - etwa die Entwicklung eines Informationssystems oder die

34

35

36

Vgl. March, Smith (1995); Hevner et al. (2004), S. 78 ff. unterscheiden explizit Konstrukte, Modelle, Methoden und Instanzen. In dieser Arbeit soll eine leicht abweichende Terminologie verwendet werden. Frameworks werden von Hevner et al. (2004) nicht explizit als Artefakte erwähnt. Jedoch enthält Fig. 2 auf S. 80 Frameworks. Vgl. hierzu Zelewski (2007), S. 90. Siehe zur Unterscheidung in (fach-)konzeptionelle, logische und physische Modelle Abschnitt

2.4.3. 37

38

Prinzipien sind allgemeine und abstrakte Grundsätze bzw. Strategien des Handeins. Stahlknecht, Hasenkamp (2005), S. 212. nennen etwa die Top-Down- und die Bottom-UpVorgehensweise als Prinzipien der Informationssystementwicklung. Prinzipien sind nicht Bestandteil einer Methode, sondern methodenübergreifend. Vgl. Becker et al. (2001), S. 6. Vgl. March, 5mith (1995); Becker et al. (2001), 5. 5 ff.; Stahlknecht, Hasenkamp (2005), S. 212.

12

Einführung

Erreichung von Forschungszielen - erreicht werden." Eine Methode enthält

Techniken, die konkret und zielgerichtet die Handlungsweise für bestimmte (Teil-)Ziele oder Aufgaben darstellen.

40

Im Rahmen dieser Arbeit wird keine

abgeschlossene Methode entwickelt, den Nutzern des AvFe-Frameworks sollen jedoch geeignete Techniken zur Erstellung der Teilmodelle zur Verfügung gesteilt werden. Ein operationalisierter Ansatz zur Erstellung eines Modells wird als Modellierungstechnik bezeichnet.

41

Diese enthält eine Modellierungsspra-

ehe, in der das Modell zu formulieren ist und eine Handlungsanleitung, die beschreibt, wie unter Verwendung der Sprache ein Modell erzeugt wird. Der Begriff der Modellierungstechnik wird ausführlich in Abschnitt 2.5 dargestellt. Da Modellierungssprachen das grundlegende und wesentliche Element einer Modellierungstechnik darstellen, konzentriert sich die Arbeit aus Gründen der Forschungsökonomie auf Modellierungssprachen.

42

Instanzen demonstrieren die Machbarkeit, indem konstruierte Artefakte in ein funktionierendes System übertragen werden." Solche (prototypischen) Implementierungen sind wesentlicher Bestandteil konstruktionsorientierter Forschungsarbeiten und werden auch zur Begründung wissenschaftlicher Erkenntnis herangezogen.

44

Auch in dieser Arbeit wird ein Prototyp entwickelt,

um die Realisierbarkeit der entwickelten Artefakte zu belegen.

1.2.2

Wissenschaftstheoretische Grundpositionen

Ausgehend von den genannten Forschungszielen und in Anlehnung an das konstruktionsorientierte Forschungsparadigma werden in diesem Abschnitt die wesentlichen wissenschaftstheoretischen Positionen dieser Arbeit dargelegt. Dies betrifft einerseits die Annahmen über Beschaffenheit (Ontologie) und Erkennbarkeit (Erkenntnistheorie) der untersuchten Realwelt und andererseits die der Begründung wissenschaftlicher Aussagen zugrundeliegende Wahrheits39

40 41

42 43 44

Vgl. Heym, Österle (1992), S. 9. Umstritten ist in der Literatur insbesondere das Verhältnis zwischen Vorgehensmodellen und Methoden. Vgl. Goeken (20061. S. 51 ff. für eine

ausführliche Diskussion. In dieser Arbeit ist Methode der umfassendere Begriff und kann Vorgehensmodelle zur Beschreibung der erforderlichen Aktivitäten enthalten. Heym, Österle (1992), S. 9; Strahringer (1996), S. 91. Vgl. Strahringer (1996), S. 91; Holten (2000), S. 4. Siehe Abschnitt 2.5. Vgl. Bichler (2006), S. 133. Siehe Abschnitt 1.2.3.

13

Forschungskonzeption und Aufbau der Arbeit

konzeption. Die genannten Aspekte inklusive möglicher Ausprägungen werden im Folgenden kurz erläutert:

45

Ontologie ist die Wissenschaft des Seins und beschäftigt sich damit, was der

Gegenstand der Erkenntnis ist und wie dieser ist.

46

Während der ontologische

Realismus davon ausgeht, dass es eine Realwelt gibt, die unabhängig von der menschlichen Erkenntnis existiert, geht der ontologische Idealismus davon aus, dass die Realwelt ein Produkt des menschlichen Bewusstseins ist.

47

Die Erkenntnistheorie beschäftigt sich mit der Frage, ob eine externe Realität zumindest prinzipiell objektiv erkannt werden kann." Die Ausprägung des erkenntnistheoretischen Idealismus geht davon aus, dass dies nicht möglich ist und die Realität daher subjektiv konstruiert wird. Demgegenüber behauptet der erkenntnistheoretische Realismus, dass ein objektives Erkennen zumindest prinzipiell möglich ist. Während der erkenntnistheoretische Realismus einen ontologischen Realismus präsupponiert, ist die ontologische Position im Falle eines erkenntnistheoretischen Idealismus nicht vorgegeben. Die Kombination von ontologischem Realismus und erkenntnistheoretischem Idealismus wird als gemäßigter Konstruktivismus bezeichnet. Demgegenüber wird die Verknüpfung aus ontologischem und erkenntnistheoretischem Idealismus als radikaler Konstruktivismus bezeichnet. Wie bereits ausgeführt, ist die Begründung (neben Originalität und Abstraktion) wesentliches Merkmal wissenschaftlicher Erkenntnis." Mithilfe welcher Begründungsverfahren und -kriterien wissenschaftliche Erkenntnis auf Wahrheit überprüft wird, hängt von der Wahrheitstheorie ab, die zur Konstruktion der Wahrheitskonzeption herangezogen wird. Es werden die folgenden Wahrheitstheorien unterschieden:

45

46 47

48 49

Die genannten Aspekte erheben keinen Anspruch auf Vollständigkeit. Vgl. bspw. Becker, Niehaves (2007), S. 199 für ein Review in der Wirtschaftsinformatik verbreiteter Aspekte. Vgl. Schwemmer (1984), S. 1077 f. Vgl. Becker, Niehaves (2007), S. 202 f. Dort wird bzgl. der Ontologie darüber hinaus noch die vermittelnde Position von Kant genannt. Diese geht davon aus, dass einerseits Betrachtungsgegenstände unabhängig vom menschlichen Bewusstsein existieren und andererseits auch Gegenstände existieren, die an das menschliche Bewusstsein gebunden sind. Vgl. Schütte (1998), S. 26. Vgl. Frank (2007), S. 172 f.

14

•

Einführung

Nach der Korrespondenztheorie der Wahrheit ist eine Aussage dann wahr, wenn sie mit der Realwelt korrespondiert. Die Korrespondenztheorie setzt einen ontologischen und erkenntnistheoretischen Realismus voraus. Ausgehend von der Überlegung, dass letztlich kein absolutes Begründungskriterium formulierbar ist, kann es allerdings nur konjekturales Wissen geben. Die Schwierigkeiten, die bei der Begründung einer Begründungsstrategie entstehen, werden auch als Münchhausen-Trilemma bezeichnet.

•

50

Die Konsenstheorie der Wahrheit geht davon aus, dass etwas wahr ist, "wenn jeder Sachkundige und Gutwillige hätte zustimmen können."51 Die Richtigkeit einer wissenschaftlichen Aussage wird somit in einem wissenschaftlichen Diskurs überprüft, wobei es keine finale und endgültige Richtigkeit geben kann. Die Konsenstheorie verlangt keinen ontologischen Realismus.

•

Nach der Kohörenztheorie der Wahrheit ist eine Aussage dann wahr, wenn sie sich "konsistent begrifflich und logisch zusammenhängend in ein konsistentes, begrifflich und logisch zusammenhängendes und außerdem umfassendes System umgangssprachlicher und wissenschaftssprachlicher Aussagen einbetten lässt."52

Da das gewählte konstruktionsorientierte Forschungsparadigma eine Orientierung für mögliche wissenschaftstheoretische Grundpositionen gibt, wird in Abschnitt 1.2.2.1 zunächst eine denkbare wissenschaftstheoretische Basis des gewählten Paradigmas knapp dargestellt, ehe in Abschnitt 1.2.2.2 eine Positionierung für diese Arbeit erfolgt.

so

51

Nach Albert (1991), S. 15 endet jeder Begründungsversuch entweder in einem unendlichen Begründungsregress (regressus ad infinitum), einem Begründungszirkel (circulus vitiosus) oder der nichtbegründbaren dogmatischen Auszeichnung einer Begrandungsbasis. Vgl. auch MIttelstraB (1984), S. 945 f. Lorenz (1996a), S. 595. Nach Habermas (1971) S. 124 ist Wahrheit die ... potenzielle Zustimmung aller anderen Lorenz (1996a), S. 595 in geänderter Orthografie. H

•

52

15

Forschungskonzeption und Aufbau der Arbeit

1.2.2.1

Wissenschaftstheoretische Fundierung des konstruktionsorientierten Forschungsparadigmas

Während die wissenschaftstheoretische Basis konstruktionsorientierter Forschung in der ISR weitestgehend ungeklärt ist, hat in der deutschsprachigen Wirtschaftsinformatik die wissenschaftstheoretische Schule des Konstruktivismus eine gewisse Bedeutung erlangt.53 Insbesondere die sogenannte Erlanger Schule, deren wesentliche Vertreter KAMLAH und LoRENZEN sind, ist im Kontext der Informationssystementwicklung intensiv diskutiert worden, weshalb diese hier in Grundzügen dargestellt wird.

54

Die Vertreter der Erlanger Schule gehen

davon aus, dass Wissenschaft sich nicht nur mit einer gegebenen Realität beschäftigt, sondern dass diese im Wesentlichen sozial konstruiert ist (ontologischer Idealismus). Ausgehend von der konstatierten "babylonischen Sprachverwirrung" in den Sozialwissenschaften und den damit einhergehenden Unklarheiten und Missverständnissen betonen die Erlanger Konstruktivisten die Bedeutung einer präzisen, eindeutigen und zirkelfreien Wissenschaftssprache.

55

Eine soiche logische Kunstsprache ("Orthosprache") ist nach KAMLAH und

LORENZEN im Sinne einer logischen Propädeutik als Vorschule des vernünftigen

Redens zu definieren.'" Die rekonstruierte Sprach basis erlaubt anschließend eine wissenschaftliche Argumentation und Diskussion. Dabei wäre nach dem Gusto der Erlanger Konstruktivisten jeder Schritt präzise, eindeutig und zirkelfrei zu begründen. Mithilfe dieses Prinzips - das auch als Beratungsprinzip oder Transsubjektivitätsprinzip bekannt ist - sollen alle Teilnehmer eine Argumentation intersubjektiv nachvollziehen können. Die Wahrheitskonzeption der Erlanger Konstruktivisten wird auch als Dialogtheorie bezeichnet und ist eine mögliche Spielart der Konsenstheorie, wobei im Gegensatz zur Konzeption von HABERMAS der Schwerpunkt auf der Bedeutung der Sprache liegt und nicht auf 53

54

55 56

In jüngster Zeit ist insbesondere die wissenschaftstheoretische Fundierung des erwähnten Vorschlags von Hevner et al. (2004) intensiv diskutiert worden. Die Meinungen gehen dabei durchaus auseinander. Während Zelewski (2007), S. 7S hinter dem wissenschaftstheoretischen Framework eine wissenschaftlich aufgeklärte Position sieht, unterstellt Frank (2007), S. 168 den Autoren ein "mechanistisch/positivistisches Weltbild", welches das verhaltenswissenschaftliche Forschungsparadigma nicht grundsätzlich in Frage stellt. Vgl. zur Erlanger Schule: Lorenzen (1973); Lorenzen (1978); Lorenzen (1987); Kamlah, Lorenzen (1996). Vgl. zur Diskussion In der WIrtschaftsinformatik bspw. Wedeklnd, Ortner (1980); Ortner et al. (1990); Ortner (1998); Ortner (2002); Becker et al. (2003a); Becker, Niehaves (2007). Vgl. Seidel (2001), S. 44. Vgl. Kamlah, Lorenzen (1996).

16

Einführung

den Bedingungen, unter denen die Teilnehmer einen Konsens finden können.

57

WEDEKIND und ORTNER haben die Prinzipien des sprach kritischen Ansatzes der Erlanger Schule auf die Entwicklung von Informationssystemen übertragen.'" ORTNER schlägt dabei vor, bei einem Informationssystementwicklungsprojekt die relevante Fachterminologie umfassend zu rekonstruieren. Die resultierende Normsprache wird anschließend verwendet, um eindeutige und präzise Modelle erstellen zu können. Die dargestellten (möglichen) Grundpositionen des konstruktionsorientierten Forschungsparadigmas sind idealtypische Positionen, auf deren Basis im folgenden Abschnitt die wissenschaftstheoretischen Grundpositionen dieser Arbeit erarbeitet werden.

1.2.2.2

Wissenschaftstheoretische Grundpositionen dieser Arbeit

Zur Darstellung der wissenschaftstheoretischen Grundpositionen wird unterschieden zwischen dem Realitätsverständnis, bestehend aus ontologischem und erkenntnistheoretischen Aspekten, und der Wahrheitskonzeption.'"

RealItätsverständnis. Während die Erlanger Konstruktivisten klare Aussagen bzgl. der Ontologie vermeiden, wird in dieser Arbeit davon ausgegangen, dass die Realwelt unabhängig von der menschlichen Erkenntnis existiert. Die Annahme eines ontologischen Reolismus ist notwendig, um bei der Konstruktion 60

von Artefakten falsche von richtigen Handlungen unterscheiden zu können. Die zu erstellenden Artefakte beziehen sich somit auf Teile einer real existierenden Welt und zielen auf die Lösung realer Probleme ab. Weiter wird davon ausgegangen, dass die objektiv existierende Welt nur subjektiv erkannt werden kann (erkenntnistheoretischer Idealismus). Diese Positi-

on ist in der vorliegenden Arbeit notwendig, da davon ausgegangen wird, dass das Erkennen eines Problems durch subjektive Wahrnehmungen und die Konstruktion von Artefakten immer durch subjektive Entscheidungen geprägt ist.

57 58

S9

60

Vgl. zur Dialogtheorie bspw. Lorenz (1996a), S. 599. Vgl. Wedekind, Ortner (1980); Ortner et al. (1990); Ortner (1998); Ortner (2002); Becker et al. (2oo3a); Becker, Nlehaves (2007). Vgl. Becker, Niehaves (2007), S. 206 ff. Den Vorschlag von Becker, Niehaves (2007) verwendet etwa auch Delfmann (2006) zur wissenschaftstheoretischen Positionierung. Vgl. Schütte (1998), S. 26 f.

17

Forschungskonzeption und Aufbau der Arbeit

Eine vollständige Eliminierung des subjektiven Einflusses - wie dies etwa der kritische Rationalismus annimmt - ist bei der Konstruktion von Artefakten nicht möglich.·' In Verbindung mit der Position eines ontologischen Realismus wird in dieser Arbeit somit eine gemäßigt-konstruktivistische Erkenntnisposition eingenommen. Trotz der grundsätzlichen Skepsis bzgl. der objektiven Erkenntnisfähigkeit ist das Streben nach möglichst weitgehender Objektivierung 2

wesentlicher Gegenstand dieser Arbeit.·

Wahrheitskonzeption. Ausgehend von den ontologischen und erkenntnistheoretischen Positionen dieser Arbeit kann einer korrespondenztheoretischen Wahrheitskonzeption nicht gefolgt werden. Da sich Wahrheitskonzeptionen grundsätzlich gegenseitig nicht ausschließen, werden Konsenstheorie und Kohärenztheorie im Folgenden kombiniert, um eine möglichst weitgehende und vielseitige Begründung der wissenschaftlichen Aussagen zu erreichen.·' Mithilfe des Begründungskriteriums der Kohärenztheorie werden die wissenschaftlichen Erkenntnisse der vorliegenden Arbeit jeweils auf ihre Kohärenz zur existierenden Literatur evaluiert und überprüft. Wenn sie im Lichte der existierenden Literatur sinnvoll erscheinen, so wird dies als Indiz für eine wahre Aussage angesehen. Das Begründungskriterium der interpersonellen Verifizierung ist innerhalb dieser Arbeit nicht anwendbar, da die Bedingungen für einen Konsens in einem wissenschaftlichen Diskurs schon deshalb nicht erfüllt sind, weil die Gruppe der Sachkundigen nicht antworten kann. Allerdings werden in Anlehnung an Dialogtheorie und Transsubjektivitätsprinzip Begriffe vor ihrer Verwendung zunächst eingeführt und definiert, sodass Leser dieser Arbeit die Argumentation nachvollziehen können und somit die Möglichkeit haben, später in die wissenschaftliche Diskussion einzugreifen. Darüber hinaus werden Artefakte als Medien und als Diskussionsgrundlage zur Herstellung eines möglichen späteren Konsenses betrachtet.

61 62 63

Vgl. Delfmann (2006), S. 23. Vgl. Schütte (1998), S. 29; Schütte (1999), S. 229. Vgl. Lorenz (1996a), S. 595 f.; Frank (2006), 5. 15.

18

Einführung

1.2.3

Forschungsmethode

Nachdem Grundpositionen und Forschungsziele expliziert sind, kann die Forschungsmethode festgelegt werden. Eine Forschungsmethode beschreibt, wie planmäßig zur Lösung einer wissenschaftlichen Problemstellung vorzugehen ist. Dafür enthält eine Forschungsmethode einerseits Konzepte, die die Strukturierung des Forschungsgegenstandes ermöglichen und andererseits eine Vorgehensweise, die die Entwicklung von Forschungsergebnissen darstellt." In der Literatur werden verschiedene Forschungsmethoden vorgeschlagen, systematisiert und diskutiert."5 Vor dem Hintergrund heterogener Forschungsziele und -gegenstände sowie der unklaren wissenschaftstheoretischen Fundierung der Wirtschaftsinformatik scheint die strenge und dogmatische Anwendung einer idealtypischen Forschungsmethode nicht sinnvoll zu sein. Vielmehr können die verfügbaren Forschungsmethoden als kombinierbar aufgefasst und zu einer für das jeweilige Projekt maßgeschneiderten Forschungsmethodik konfiguriert werden"" Die Konfiguration muss allerdings nach bestimmten Regeln erfolgen, um sicherzustellen, dass eine Forschungsmethodik die notwendigen Bestandteile (Konzepte) enthält. Im Folgenden wird ein Framework von FRANK zur Konfiguration einer solchen Methodik verwendet'" Zur Strukturierung eines Forschungsprojektes werden folgende Konzepte einer Forschungsmethodik unterschieden: Das Erkenntnisziel bezieht sich auf einen Forschungsgegenstand und wird repräsentiert durch eine Darstellung. Bezogen

auf das Erkenntnisziel unterscheidet Frank zwischen dem abstrakten und konkreten Erkenntnisangebot, welche durch das Begründungskriterium und das

zugehörige Begründungsverfahren legitimiert bzw. geprüft werden.

.. 6S

&&

67

68

58

Die Kon-

Vgl. Frank (2007), S. 161 f. Vgl. bspw. Galliers, land (1987); Galliers (1995); Becker et al. (2003a); Goeken (2003); Wilde, Hess (2007). Vgl. in diesem Kontext die Überlegungen von Feyerabend (1976) zur "Wissenschaftsmethodologie als anarchisches System". Vgl. Frank (2006), S. 40 ff. Die Arbeit enthält auch Anwendungsrichtlinien und Fallbeispiele für das vorgeschlagene Framework. Vg!. zur Konfiguration zudem Frank (2007), S. ISS ff. Vg!. Frank (2006), S. 40 ff.

19

Forschungskonzeption und Aufbau der Arbeit

zepte sind mit ihren Beziehungen als Entity-Relationship(ER)-Modell in Abbildung 2 dargestellt." Abbildung 2: Konzepte einer Forschungsmethodik

Erkenntnisliel

epräsentie durch

1,0

0,0

'>----0,'----1

Darstellung

.r---o,,'- - - - I

Forschungsgegenstand

1, 1

spezialisie

bezieht sich auf

'"' 1,1

I

Abstraktes Erkenntni sangebot

r-ü,n

spezialisier

,oe

ü,n-

Konkretes Erkenr t nisa ngebot

I-ü,n

legitimiert durch

0,0

Begrendungskrit e rium

I

0,'

geprüft durch

BegründungsverfahreIl

Vgl, Frank (2006), S, 42.

Die einzelnen Konzepte werden im Folgenden mit Bezug auf diese Arbeit eingeführt:

1. FRANK unterscheidet bzgl. des Erkenntnisziels zwischen der Konstruktion neuen Wissens und der Kritik bestehenden Wissens,7. In dieser Arbeit steht die Konstruktion neuen Wissens im Vordergrund, wobei dieses Erkenntnisziel auf formulierter Kritik und Anforderungen basiert.

"

70

Siehe zum ER-Modell Anhang A. Vgl. Frank (2006), S. 40 f.

20

Einführung

2. Das abstrakte Erkenntnisangebot eines Forschungsprojektes differenziert FRANK weiter in die Abstraktion des Faktischen und die Abstraktion des Intendierten. Die Abstraktion des Faktischen beschreibt das Streben nach neuen Konzepten (wie z. B. Theorien) auf einem hohen Abstraktionsniveau zum besseren Verständnis und Erklären der existierenden Welt. Die Beschreibung möglicher Welten und die Beschreibung wie mögliche Welten zu erreichen sind, wird dagegen als Abstraktion des Intendierten bezeichnet. In der vorliegenden Arbeit werden beide Abstraktionen angewendet. Einerseits ist die Konstruktion neuer Artefakte (Framework, Modellierungssprachen) eine Beschreibung, wie mögliche Welten zu erreichen sind und somit eine Abstraktion des Intendierten. Andererseits wird für die Konstruktion auch auf bestehende Konzepte zurückgegriffen und somit auch teilweise vom Faktischen abstrahiert.

71

3. Das konkrete Erkenntnisangebot dieser Arbeit besteht in der Entwicklung eines Frameworks zur Automatisierung von Führungsentscheidungen und in der Auswahl und Konstruktion domänenspezifischer Modellierungsspraehen, die mit dem genannten Framework harmonieren. Bei der Konstruktion der Artefakte wird auf bestehende Konzepte und Theorien (z. B. aus der System- oder Entscheidungstheorie) zurückgegriffen. Eine wesentliche Annahme dieser Arbeit, die eine Abstraktion des Faktischen darstellt und in Abschnitt 1.1 bereits dargestellt wurde, ist die Überlegung, dass ein grundsätzlicher Bedarf an steigender Automatisierung ausgewählter Führungsentscheidungen existiert. 4. Der Forschungsgegenstand besteht aus dem Handlungssystem und aus der 72

Klasse von Informationssystemen , die das betrachtete Handlungssystem unterstützen. Das Handlungssystem des Forschungsgegenstandes sind Führungsentscheidungen. Das Informationssystem des Forschungsgegenstan-

71

Vgl. Frank (2006), S. 40 f. In der Wirtschaftsinformatik ist eine klare Trennung zwischen Abstraktion des Faktischen und Abstraktion des Intendierten problematisch, da es keine originären Theorien der WIrtschaftsinformatik gibt. In der Physik werden Abstraktionen des Faktischen etwa durch Theorien begründet, die mehr erklären als bestehende Teile der Realität.

72

Die Klasse der Informationssysteme wird von Frank (2006) als IS Artefact bezeichnet.

Forschungskonzeption und Aufbau der Arbeit

21

des sind Systeme zur Automatisierung und Unterstützung von Führungsentscheidungen. 5. Die Darstellung erfolgt im Wesentlichen in natürlicher Sprache. Teilweise werden auch semi-formale Modellierungssprachen zur Darstellung verwendet. 6. Wesentlicher Bestandteil einer Forschungsmethodik ist die Begründung des Erkenntnisangebotes. Dafür müssen sowohl Begründungskriterien als auch Begründungsverfahren angegeben werden. Wesentlich für die Begründung

eines konstruktionsorientierten Erkenntnisangebotes ist das Ableiten von Anforderungen an die zu schaffenden Artefakte. Die Anforderungen stammen dabei idealerweise aus theoretischen und praktischen Überlegungen, wobei existierende Lösungen die Anforderungen bisher nicht vollständig erfüllen sollten. Validiert werden die Ergebnisse dieser Arbeit anschließend durch die Begründungskriterien Wahrheit (nach der dargestellten Wahrheitskonzeption) und Angemessenheit. Die Angemessenheit ist in konstruktionsorientierten Forschungsprojekten ein wesentliches Begründungskriterium und wird in dieser Arbeit mithilfe eines Prototyps und eines Konformitätstests überprüft." Die erläuterte Forschungsmethodik der Arbeit ist überblicksartig in Abbildung 3 da rgestellt.

73

Im Rahmen des Konformitätstests wird Anforderungen erfüllen.

überprüft, ob Artefakte die formulierten

EinfLihrung

22

Abbildung 3: Modell der Forschungsmethodik

• ~] 0

~

•

•

~ •", ~ ""

Ni

•.., o >

.~ ~

~:~ .

1;1 ~~

~

" •• 0

~ oB .::i

<

" IH > • •

0

o "

E ~

1~

~

"' <sg' ,

.

";:§

"

~ 0 i ~

li~

j~

<

1 r" ,) 1

~

0

~

.»~n l~ 52 'g~ 0

8~

•j

,~

1f ! ~, ,

!

ö

~ ~

i, ~ Ji <

!

< .~

0

<

:~

!

i rf rr

\

~

•f ,1 ~

],

23

Forschungskonzeption und Aufbau der Arbeit

1.2.4

Aufbau der Arbeit

Der sich aus der Forschungskonzeption ergebende Aufbau der Arbeit ist in Abbildung 4 dargestellt, wobei die (dunkelgrau hinterlegten) vier Teile jeweils die rechts stehenden (hellgrau hinterlegten) Kapitel enthalten.

-

Abbildung 4: Aufbau der Arbeit Tel I:

.....

ElnfQhrunll

TermlnoioIIe. GruncIIcen

Tell I:

FondILa . . . . ataid

_..

TermlnolOille und Grundlll~m der Informationssystementwicklunl

(FOhrunp-)Enbcheldun.en und deren Automatisieruni

InformatIonssysteme zur AutomatIsIerun. und Unterstiitzun. von (Führunp-)Enbcheidulllen

Frllmework zur AutomatIsIeruni von Fiihrullpl!nt:scheidunpn

Modelllerungssprllchen fllr du AvFeFr.llmework

Tel rv:

prototyp

IEJß

Teil I beinhaltet neben dem vorliegenden Kapitel noch Kapitel 2, in dem für diese Arbeit wesentliche Begriffe und notwendige Grundlagen der Informationssystementwicklung eingeführt werden. In Teil 11 wird der Forschungsgegenstand dieser Arbeit vorgestellt. Kapitel 3 beschreibt mit Entscheidungen von Führungskräften zunächst das Handlungssystem und diskutiert, ob und wie Führungsentscheidungen automatisiert werden können (erstes Forschungsziel). Dabei werden auch Anforderungen formuliert, die Informationssysteme erfüllen müssen um Führungsentscheidungen zu automatisieren. Anschließend werden in Kapitel 4 bestehende Informationssysteme zur Automatisierung und Unterstützung von (Führungs-) Entscheidungen vorgestellt und den Anforderungen gegenübergestellt. Dadurch werden Defizite bisheriger Ansätze zur Automatisierung von Führungsentscheidungen offenbart. Teil 111 präsentiert das Erkenntnisangebot und zielt auf das zweite Forschungsziel dieser Arbeit ab. In Kapitel 5 wird ein Framework zur Automatisierung von Führungsentscheidungen entwickelt. Das Framework gibt eine grundsätzliche

24

Einführung

Orientierung, wie Führungsentscheidungen automatisiert werden können. Anschließend werden in Kapitel6 Modellierungssprachen ausgewählt und konstruiert, die zur Modellierung des zuvor beschriebenen Frameworks verwendet werden können. In Teil IV werden die entworfenen Artefakte wissenschaftlich begründet. Zu diesem Zweck wird in Kapitel 7 zunächst ein Prototyp entwickelt, ehe in Kapitel 8 ein Konformitätstest durchgeführt wird. Bei diesem werden die entwickelten Artefakte den hergeleiteten Anforderungen gegenübergestellt. Die Arbeit endet in Kapitel 9 mit einem Fazit.

Terminologie und Grundlagen der Informationssystementwicklung

2

Im folgenden Kapitel werden einige für diese Arbeit relevante Begriffe und Grundlagen der Informationssystementwicklung definiert und erläutert. Bei der Automatisierung von Führungsentscheidungen sind Informationen auf zwei Ebenen von zentraler Bedeutung. Zum einen werden Informationen bei der Entwicklung entsprechender Informationssysteme benötigt, zum anderen benötigen die Systeme selbst während des Betriebs Informationen, um Entscheidungen automatisch durchführen zu können. Aufgrund dieser Bedeutung wird in Abschnitt 2.1 der Informationsbegriff näher betrachtet, ehe darauf aufbauend in Abschnitt 2.2 der Begriff des Informationssystems vorgestellt wird. Anschließend werden die zu entwickelnden Artefakte detailliert vorgestellt. Ausgangspunkt ist der Begriff des Frameworks, welcher in Abschnitt 2.3 diskutiert wird. Das zu entwicklende AvFe-Framework besteht aus Modellen, die jeweils einen Aspekt der Automatisierung von Führungsentscheidungen fokussieren. Der Modellbegriff dieser Arbeit wird in Abschnitt 2.4 hergeleitet. Modelle werden mithilfe einer Modellierungstechnik erstellt. Diese stellt einen operationalisierten Ansatz zur Modellerstellung dar und beinhaltet eine ModelIierungssprache, in der das Modell zu erstellen ist, und eine Handlungsanlei74 tung für die Modellerstellung. Modellierungstechniken und ihre Bestandteile sind Gegenstand von Abschnitt 2.5. Neben diesen oftmals in wissenschaftlichen Arbeiten erläuterten Begriffen sind bei der Automatisierung von Führungsentscheidungen Ereignisse als Auslöser

74

Vgl. Strahringer (1996), S. 91; Holten (2000), S. 4. Da Modelle als Produkte von Sprachen angesehen werden können, führen einige Autoren zunächst den Begriff Sprache ein, um somit insbesondere den sprachlichen Aspekt von Modellen zu beleuchten. Vgl. 5trahringer (1996), 5.9 ff.; Goeken (2006), S. 70 ff. tar eine solche Vorgehensweise. Auch wenn ein solches Vorgehen sicherlich legitim Ist, soll In dieser Arbeit zunächst der Modellbegriff eingeführt werden, um Modelle nicht ex ante auf das Merkmal Sprache einzuschränken. Thomas (2005), S. 27 weist darauf hin, dass Modelle auch mentaler Art und Weise sein können, d. h. sie beschreiben die subjektive Vorstellung über das einem Modell zugrunde liegende Original.

J. Rommelspacher, Automatisierung von Führungsentscheidungen, DOI 10.1007/978-3-8348-8251-6_2, © Vieweg + Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

26

Terminologie und Grundlagen der Informationssystementwicklung

von Informationssystemen von wesentlicher Bedeutung. Der Ereignisbegriff ist daher Gegenstand von Abschnitt 2.6.

2.1

Information 7S

Obwohl der Informationsbegriff

einer der zentralen Begriffe der Wirtschafts-

informatik ist, wird er innerhalb der Disziplin uneinheitlich verwendet und es existiert in der Literatur eine beachtliche Zahl an Definitionen, die wiederum in Form von Abgrenzungen und Systematisierungen Gegenstand weiterer Untersuchungen sind.'· In der Wirtschaftsinformatik können folgende wesentliche Strömungen bei der Verwendung des Informationsbegriffes unterschieden werden: Die weiteste Begriffsauffassung entstammt der Informationstheorie und wird in technischen Zusammenhängen verwendet. Dabei wird Information als zu übertragende Zeichenreihe betrachtet, wobei der Inhalt einer Information durch die enthaltenen Zeichen und deren Auftrittswahrscheinlichkeiten bestimmt wird." Die Definition über enthaltene Zeichen kann in Anlehnung an die Semiotik als syntaktischer Definitiansansatz bezeichnet werden." Eine engere Begriffsauffassung berücksichtigt die Bedeutung der Information und baut für das Begriffstripel Daten, Information und Wissen eine Begriffshierarchie auf, indem aus zweckneutralen Daten mittels einer Interpretationsvorschrift zweckgerichtete Information wird, die für Entscheidungen verwendet werden kann.'" Wissen entsteht diesem Verständnis nach durch Vernetzung so der Information mit individuellen Erfahrungen und Kenntnissen. Die Definition über die Bedeutung einer Information wird als semantischer Definitionsan-

satz bezeichnet. al

75

76

" " 79

80 81

Die Etymologie des Begriffs wird hier nicht diskutiert. Vgl. etwa Rechenberg (2003), S. 317 f. für eine solche Darstellung.

Eine Übersicht findet sich bei Lehner, Meier (1994), S. 8 ff. und S. 77; Vgl. zur Diskussion des Informationsbegriffs die bei Bode (1997), S. 454, Fn. 30 genannte Literatur. Vgl. Shannon (1948); Rechenberg (2003), S. 320 f. Vgl. Bode (1997), S. 451. Vgl. Mertens et al. (2005), S. 53; Vgl. Ferstl, 51nz (2006), S. 131 f. tar die Bedeutung der Interpretationsvorschrift. Vgl. Mertens et al. (2005), S. 53. Vgl. Bode (1997), S. 451 f.

Information

27

Der Informationsbegriff kann durch den pragmatischen Definitionsansatz noch

weiter eingegrenzt werden, indem Informationen zudem auch für einen Zweck, wie bspw. "zur Vorbereitung von Handlungen und Entscheidungen geeignet sein müssen".82 Der bekannteste pragmatische Definitionsansatz ist der in der Betriebswirtschaftslehre verbreitete Informationsbegriff von WITTMANN, nach dem Information "zweckorientiertes Wissen" ist." Dieser Informationsbegriff ist vielfach kritisiert worden. Gegen ihn wird eingewendet, das Definitionsproblern sei nur auf die Begriffe Zweckorientierung und Wissen verlagert worden." Weiter wird die Beschränkung auf zweckorientiertes Wissen teilweise als problematisch erachtet, da hierdurch bestimmte Wissenskategorien keine Informationen sind, die umgangssprachlich als Informationen bezeichnet werden (z. B. populärwissenschaftliche Zeitschriften, Lexika, Software).85 Die genannten Kritikpunkte werden als nicht stichhaltig aufgefasst, weshalb in dieser Arbeit ein modifizierter pragmatischer Ansatz zur Definition des Informationsbegriffs verwendet wird. Die Modifizierung besteht in einer zweifachen Einschränkung des WITTMANN'schen Informationsbegriffs. Zunächst lässt sich die WITTMANN'sche Zweckorientierung in dieser Arbeit weiter eingrenzen auf Entscheidungsrelevanz, d. h. die Informationseigenschaft hängt davon ab, ob das Wissen für eine Entscheidung von Relevanz ist." In Anlehnung an SHANNON wird Information als Mittel zur Reduktion von Unsicherheit bei Entscheidungen verstanden.·' Eine weitere Einschränkung des Informationsbegriffes erfolgt durch die Überlegung, dass die Informationseigenschaft vom Wissensstand des Empfängers abhängt. In Anlehnung an ALPAR et al. kann Information als Bewegungsgröße und Wissen als Bestandsgröße aufgefasst werden und nur, wenn das Wissen

82

83

84

115 86 Wl

Bode (1997), S. 452. Vgl. Wittmann (1979), Sp. 2264; Holten (1999), S. 71-74; Stahlknecht, Hasenkamp (2005), S. 9; Goeken (2006), S. 8 f.; Alpar et al. (2008), S. 7. Dem ist nach Auffassung des Verfassers nicht zu folgen. Wittmann (1979), Sp. 2263 bezeichnet Wissen als "Vorstellungsinhalte (... ), die überzeugungen über die Wahrheit von Feststellungen (Aussagen, Sätzen, Behauptungen) zum Inhalt haben." Vgl. Bode (1997), S. 455 ff. fOr eine Auflistung solcher WissensgOter. Siehe zu Entscheidungen Kapitel 3. Vgl. Shannon (1948), S. 379 ff. Im Gegensatz zu Shannon wird in dieser Arbeit nicht davon ausgegangen, dass der Wert von Information messbar ist. Vgl. zur Informationstheorie und deren Bedeutung in der Informatik auch Rechenberg (2003).

28

Terminologie und Grundlagen der Informationssystementwicklung

für den Empfänger zusätzlich ist, handelt es sich um Information." Auch inhaltlich bereits vorhandenes Wissen kann eine Information sein, wenn bestehendes Wissen (zusätzlich) bestätigt und validiert wird. Zusammenfassend wird der Informationsbegriff unter Verwendung des WITTMANN'schen Wissensbegriffs·' für diese Arbeit folgendermaßen definiert:" Information ist für den Empfänger zusätzliches entscheidungsrelevantes Wissen. Informationen sind in dieser Arbeit auf zwei unterschiedlichen Ebenen von zentraler Bedeutung. Erstens werden Informationen innerhalb von Informationssysternen zur Automatisierung von strukturierten und revolvierend auftretenden Führungsentscheidungen genutzt." Durch die Entlastung bei Routineentscheidungen können Entscheidungsträger somit mehr Zeit für unstrukturierte Entscheidungen aufwenden. Zweitens sind bei der Entwicklung von Informationssystemen zur Automatisierung von Führungsentscheidungen Informationen erforderlich, um Konstruktionsentscheidungen treffen zu können. Nur so kann sichergestellt werden, dass die Systeme den fachlichen Anforderungen entsprechen und anschließend angemessene Entscheidungen treffen.

2.2

Informationssystem

Führungsentscheidungen sollen in dieser Arbeit mithilfe von Informationssys-

temen 92 automatisiert werden. Aus diesem Grund werden im Folgenden InBB

89

Vgl. Alpar et al. (20OS), S. 7 f. Vgl. Mag (1977), S. 4 für den Vorschlag, den Begriff ZWeckorientierung durch Entscheidungsorientierung zu substituieren. Vgl. Fn. 84. Der Wissensbegriff strahlt auf den Informationsbegriff aus und hat somit zur

(impliziten) Folge, dass Information zumindest der Überzeugung nach wahr sein muss, d. h. der Informationssender geht davon aus, dass die Information (subjektiv) wahr ist. Vgl. zum Wahrheitsgehalt auch Bode (1997), S. 453. 90

91

92

Es ist zu betonen, dass Begriffsdefinitionen im Sinne einer Nominaldefinition nicht wahr oder falsch, sondern lediglich zweckmäßig oder weniger zweckmäßig für eine wissenschaftliche Fragestellung sein können. Vgl. Bode (1997), 5. 451. In der literatur werden Informationsbegriffe teilweise danach unterschieden, ob lediglich das menschliche Gehirn Träger von Information sein kann (menschengebundener Ansatz) oder ob auch technische Medien Informationsträger sein können (nicht-menschengebundener Ansatz). Vgl. Bode (1997), 5. 452. In dieser Arbeit wird der Informationsträger nicht als konstituierendes Merkmal angesehen. Der Begriff Informationssysteme wird als Verkürzung des Begriffs Informations- und Kommunikationssysteme (IKS) verwendet.

Informationssystem

29

formationssysteme im Allgemeinen kurz vorgestellt, ehe die in dieser Arbeit verwendeten Informationssysteme charakterisiert werden. Informationssysteme verarbeiten Informationen für betriebliche Aufgaben und sind in dieser Funktion der Forschungsgegenstand der Wirtschaftsinformatik. Das Verarbeiten umfasst dabei die Erfassung, Übertragung, Transformation, Speicherung und Bereitstellung:' Aus systemtheoretischer Perspektive enthalten Informationssysteme genau die Elemente, die zur Erfüllung ihres (betriebswirtschaftlichen) Zweckes notwendig sind:' Auf abstrakter Ebene lassen sich dabei menschliche und technische Elemente von Informationssystemen unterscheiden. •

95

Menschen sind in mannigfaltigen Rollen an Informationssystemen beteiligt:· Vor Betrieb und Nutzung werden Informationssysteme von Menschen entwickelt und eingeführt. Während des Betriebes werden sie von Menschen administriert und gewartet. Vor allem werden Informationssysteme jedoch von Menschen zur Erfüllung ihres Handlungssystems genutzt, wodurch auch mittelbar betroffene Stakeholder zum Informationssystem (z. B. Kunde oder Lieferant) zählen. Menschen sind in Unternehmen und Verwaltungen in einen organisatorischen Kontext eigebettet, der so ebenfalls zu einem Teil von Informationssystemen wird.

•

Technische Elemente von Informationssystemen sind einerseits Anwendungssoftware und andererseits Hardware, auf der die Anwendungssoftware läuft. Die Gesamtheit der technischen Elemente eines Informations-

93 94

95

96

Vgl. Ferstl. 5inz (2006). 5. 1. Nach der 5ystemtheorie ist ein System eine Menge von Elementen. die in bestimmter Weise miteinander verbunden sind und von ihrer Umgebung abgegrenzt werden können. Vgl. Hesse et al. (1994). S. 42; Krcmar (2005). S. 25; Alpar et al. (2008), S. 16 ff. Die Systemtheorie versucht für Systeme in unterschiedlichen Anwendungsfeldern gleichermaßen geltende Prinzipien zu erkennen und daraus eine allgemeine und interdisplinär gültige Theorie zu schaffen. Vgl. von Bertalanffy (1957); von Bertalanffy (1968); Ackoff (1971); Unbehauen (19981; Unbehauen (2002). Teilweise werden Aufgaben (im Sinne betriebswirtschaftlicher Probleme oder Problembereiche) als weitere Elemente betrachtet. Diese dienen nach Ansicht des Verfassers jedoch vielmehr der Abgrenzung des Systems gegenüber der Umwelt. Vgl. Heinrich et al. (2007), S. 15 f. Einige denkbaren Rollen sind in Heinrich et al. (2007), S. 15 aufgeführt.

30

Terminologie und Grundlagen der Informationssystementwicklung

systems wird oftmals als Anwendungssystem bezeichnet.

97

Anwendungs-

systeme sind die technische Realisierung (spezifischer) betrieblicher Anwendungsaufgaben und ein Teil von Informationssystemen. Diese Elemente von Informationssystemen sind abhängig voneinander und beeinflussen sich wechselseitig. HEINRICH weist darauf hin, dass insbesondere die Beziehungen zwischen den Elementen (wissenschaftlich) interessant sind." Unter der Berücksichtigung der Elemente von Informationssystemen kann in Anlehnung an die Wissenschaftliche 99 (WKWI) definiert werden:

Kommission

Wirtschaftsinformatik

Informationssysteme sind Systeme, die menschliche und technische Elemente (Teilsysteme) umfassen. In der Wirtschaftsinformatik wird der Informationssystembegriff üblicherweise im Plural verwendet; ein Unternehmen verfügt demzufolge über mehrere oder viele Informationssysteme. Diese lassen sich nach bestimmten Merkmalen klassifizieren. Einen Überblick über mögliche Klassifikationsmerkmale und ihre Ausprägungen gibt Tabelle 1.'00

" 9B

" 100

VBI. Teubne, (1999), S. 26; Seibt (2001), S. 46 f. Vgl. Heinrich et al. (2007), S.16. Vgl. WKWI (1994), S. 80; Ähnlich auch Krema, (2005), S. 25; Alpa, et al. (20OS), S. 26. Vgl. Krcmar (2005), S. 26; Vgl. zum Merkmal des Automatlonsgrades Mertens (2005), S. 8; Alpar et al. (20OS), S. 28 ff. schlagen einen zweidimensionalen Ordnungsrahmen mit den Dimensionen Managementebene und Entscheidungsstruktur (bzw. Problemstruktur). In diesem Rahmen verorten sie anschlieBend Typen von Informationssystemen.

31

Informationssystem

Tabelle 1: Klassifikationsmerkmale von Informationssystemen

Merkmal

Ausprägungen

Verwendungszweck

operativ, analytisch

Managementebene

operativ, taktisch, strategisch

Entscheidungsstruktur

(wohl) strukturiert, semi-strukturiert, unstrukturiert

Automationsgrad

Vollautomation, Teilautomation

Sektorspezifität

sektorspezifisch, sektorneutral

Anwendungsfokus

betrieblich, überbetrieblich

Herkunft

Individualsoftware, Standardsoftware

Mithilfe der Merkmale Verwendungszweck, Managementebene, Entscheidungsstruktur und Automationsgrad können die Informationssysteme charakterisiert werden, welche in dieser Arbeit zur Automatisierung von Führungsentscheidungen eingesetzt werden. Nach dem Verwendung.zweck können operative und analytische Informationssysteme unterschieden werden. Während operative Informationssysteme die Administration und Disposition unterstützen, zielen analytische Informationssysteme auf die Unterstützung bei der Planung und Kontrolle eines Unternehmens ab.

'O' In dieser Arbeit werden schwerpunktmäßig analytische Informati-

onssysteme betrachtet. Es besteht eine hohe Korrelation zwischen den Merkmalen Verwendungszweck und Managementebene. Während operative Informationssysteme auf die Unterstützung der operativen Ebene abzielen, ist es erklärtes Ziel von analytischen Informationssystemen, den adäquaten Zugang von Führungskräften auf taktischer und strategischer Ebene zum Produktionsfaktor Information sicherzustellen.

101 102

10

'

Im Wesentlichen zielen die Informationssysteme dieser Arbeit

Vgl. zu dieser Klassifikation auch Mertens et al. (2005), S. 3 ff.; Mertens (2005), S. 1 ff. Siehe Abschnitt 4.1 zu einer detaillierten Auseinandersetzung mit analytischen Informationssystemen.

32

Terminologie und Grundlagen der Informationssystementwicklung

darauf ab, die taktische und strategische Managementebene zu unterstützen und zu entlasten. Abhängig von den vorliegenden Informationen kann differenziert werden in strukturierte, semi-strukturierte und unstrukturierte Entscheidungsstruktu103 ren. Da für eine Automatisierung sehr umfangreiche Informationen notwendig sind, unterstützen die Informationssysteme in dieser Arbeit insbesondere strukturierte Entscheidungen. Nach dem Automatiansgrad können teil- und vollautomatische Informationssysteme unterschieden werden.'04 Teilautomatische Informationssysteme lösen Aufgaben in einer Interaktion zwischen Mensch und Maschine.'os Ein wesentlicher Zweck teilautomatisierter Informationssysteme ist es, die Inforl6 mationsversorgung des menschlichen Aufgabenträgers zu verbessern." Demgegenüber bearbeitet ein vollautomatisches Informationssystem selbstständig Aufgaben, indem es bspw. auftretende Probleme aktiv erkennt und zu deren Beseitigung selbstständig andere Programme anstößt.,o7 lm Mittelpunkt dieser Arbeit stehen vollautomatische Informationssysteme.

2.3

Frameworks

Frameworks dienen - wie bereits in Abschnitt 1.2.1 erläutert - der zweckgerichteten Strukturierung und Gestaltung eines Untersuchungsgegenstandes. Da Zwecke und Untersuchungsgegenstände von Frameworks jedoch stark divergieren, wird der Begriff des Frameworks sehr heterogen verwendet. Während betriebswirtschaftliche Frameworks auf die Beantwortung komplexer betriebswirtschaftlicher Fragestellungen fokussieren, zielen Frameworks der konstruktionsorientierten Wirtschaftsinformatik insbesondere auf die Gestal-

103

104

Siehe Abschnitt 3.1.1. Vgl. Mertens (2005), S. 8. Zuboff (1985), S. 8 schlägt dagegen die Dichotomie Automati-

sieren/Informieren vor. Streng genommen stellt allerdings auch die Informationsversorgung eine (Teil-)Automation dar, da in einem derartigen Fall die Aufgabe der Informationssuche, beschaffung und -aufbereitung von einem Informationssystem abernommen wird. 105 106

101

Vgl. Mertens (2005), S. 8. Vgl. Mertens (1994), S. 35 ff. für eine Klassifikation von Informationssystemen nach Automationsgrad. Vgl. Mertens (2005), 5. 8.

Frameworks

33

tung von Informationssystemen ab. Die unterschiedliche Verwendung des Begriffs wird im Folgenden knapp skizziert. In der betriebswirtschaftlichen Forschung wurde der Begriff wesentlich von PORTER geprägt.'OB PORTER entwickelte Frameworks wie die Branchenstrukturanalyse zur Analyse komplexer betriebswirtschaftlicher Fragestellungen. Er bevorzugt Frameworks, da nach seiner Auffassung in sich geschlossene ökonomische Modelle durch ihre Konzentration auf ausgewählte Variablen und deren Beziehungen an Erklärungskraft und somit an praktischer Relevanz verlieren.'09 Frameworks im Sinne PORTERS zielen anders als Modelle nicht auf eine Verkürzung der komplexen Realität ab, sondern reichern ökonomische Modelle um praktische Erkenntnisse an."D Frameworks stellen Strukturierungsinstrumente und Ordnungsschemata zur Analyse komplexer praktischer Probleme zur Verfügung und bieten darüber hinaus idealerweise .Redeinstrumente" zur Generierung möglicher Handlungsalternativen an.

111

Der skizzierte Framework-

Begriff von PORTER ist in dieser Arbeit nicht unmittelbar verwendbar, da keine ökonomischen Modelle existieren, die als Nukleus um praktische Erkenntnisse angereichert werden können. In der Wirtschaftsinformatik stellen Frameworks im Wesentlichen einen Ordnungsrahmen zur Beschreibung und Entwicklung von Informationssystemen dar. Frameworks dienen der Wiederverwendung von Entwurfs- und Domänenwissen und integrieren heterogene Modelle, um verschiedene Aspekte von Informationssystemen beschreiben zu können.

112

Es existieren zum einen

technisch orientierte Frameworks, die insbesondere auf die Wiederverwendung von Code abzielen, und zum anderen konzeptionelle Frameworks, bei denen die Beschreibung fachlicher Anforderungen von Informationssystemen im Vordergrund steht.''' In der Wirtschaftsinformatik können etwa die Archi-

108

109 110

111 112

113

Vgl. Porter (1991), S. 97 f.; Osterloh, Grand (1994); Osterloh, Grand (1995). Vgl. Porter (1991), S. 98. Vgl. zu weiteren Frameworks Porter (1980): Porter (2008): Sachs, Hauser (2002), S. 44 11. Vgl. Osterloh, Grand (1995), S. 6 empfehlen Einzelfallstudien, um empirisch und praktisch relevante Variablen zu erkennen, die In Modellen nicht enthalten sind. Vgl. Porter (1991), s. 98: Osterloh, Grand (1995), S. 6. Vgl. Frank (2001), S. 203 f. Vgl. Frank (2001), S. 203 f.; Frank (2006), S. 52 f.

Terminologie und Grundlagen der Informationssystementwicklung

34

tektur integrierter Informationssysteme (ARIS) oder das Zachman-Framework als wichtige konzeptionelle domänenneutrale Frameworks genannt werden.'14 In dieser Arbeit wird das konzeptionelle domänenspezifische AvFe-Framework entwickelt, das einen Ordnungsrahmen zur Entwicklung von Informationssystemen zur Automatisierung von Führungsentscheidungen bietet.

2.4

ll5

Modelle

Modelle sind ein wesentliches Hilfsmittel im Umgang mit einer komplexen Realität, welches in vielen wissenschaftlichen Disziplinen, aber auch in der Praxis, auf vielfältige Art und Weise eingesetzt wird. Modelle reduzieren Komplexität, indem sie sich auf einen festgelegten Aspekt sowie auf wesentliche ausgewählte Merkmale beschränken. Mithilfe eines Modells können Zusammenhänge besser durchdrungen, analysiert und simuliert werden, als dies mit dem Original möglich wäre.'" Während der Modellbegriff in den Formal- und Naturwissenschaften klar und präzise definiert ist, wird er in den Geistes- und Sozialwissenschaften uneinheitlich verwendet.''' Selbst innerhalb der einzelnen Disziplinen hat sich kein einheitlicher Modellbegriff durchsetzen können.

l1B

Einige Autoren sehen in der

ungewöhnlichen Etymologie des Modellbegriffs die Ursache für Kommunikations- und Verständnisprobleme im Zusammenhang mit dem Modellbegriff."9 Andere Autoren weisen darauf hin, dass die unterschiedlichen Definitionen des Modellbegriffs auf unterschiedlichen (selten explizierten) wissenschaftstheoretischen Grundpositionen fußen und deshalb nur schwerlich miteinander verglichen werden können."· Insbesondere die erkenntnistheoretische Grundpositi-

114

115

Vgl. zu ARIS: Luckham, Frasca (1998); Scheer (1998a); Scheer (2002). Zum ZachmanFramework: Zachman (1987). Das AvFe-Framework ist domänenspezifisch, da die überwiegende Anzahl der enthaltenen Konzepte und Modelle sich auf die Domäne der Führungsentscheidung und deren

Unterstützung beziehen. Siehe zu domänenspezifischen und domänenneutralen Sprachen 1115

117

118 119

120

Abschnitt 2.5.1. Vgl. Kosiol (1961), S. 319; Rosemann (1996), 5.17. Vgl. Strahringer (1996), S. 19. Vgl. fOr den axiomatischen (mathematischen) Modellbegriff Stachowlak (1973), s. 243 ff.; Lehner et al. (1995), S. 27, 32; Thomas (2005), S. 11 ff. Vgl. Strahringer (1996), S. 19; Schütte (1998), S. 40; Thomas (2005), S. 7. Vgl. für eine ausführlichere Darstellung Schütte (1998), S. 40; Thomas (2005), S. 6. Vgl. Dresbach (1999), S. 71 ff.; Wyssusek et al. (2002), S. 239 ff.

Modelle

35

on erweist sich, wie weiter unten gezeigt wird, bei dem Modellbegriff als folgenreich. Obwohl der Modellbegriff in den letzten Jahren Gegenstand intensiver Diskussionen war, existiert auch in der Wirtschaftsinformatik bis heute keine allgemein akzeptierte Begriffsauffassung. Der lange als dominierend eingeschätzte abbildungsorientierte Modellbegriff verliert in den vergangenen Jahren zunehmend seine Bedeutung zugunsten eines konstruktivistischen Modeli begriffs. Im folgenden Abschnitt 2.4.1 werden die beiden Perspektiven auf den Modellbegriff daher ausgehend von der allgemeinen Modelltheorie STACHOWIAKS charakterisiert, ehe in Abschnitt 2.4.2 ein für diese Arbeit zweckmäßiger Modell121 begriff erarbeitet wird. In Abschnitt 2.4.3 wird mit den Informationsmodellen ein in dieser Arbeit wesentlicher Modelltyp vorgestellt. Entscheidungsmodelle als zweiter wesentlicher Modelltyp werden erst in Abschnitt 3.1.2 dargestellt, da sinnvollerweise zuvor die Bestandteile von Entscheidungssituationen eingeführt werden müssen.

2.4.1

Perspektiven auf den al/gemeinen Model/begriff

Nach STACHOWIAK ist ein Modell im Sinne der Semiotik definierbar als: "X ist Modell des Originals Y für den Verwender v in der Zeitspanne t bzgl. der Intention Z."122 STACHOWIAK verwendet - ähnlich wie später SCHünE - den Begriff des Originals, um sowohl reale als auch künstliche Sachverhalte als Ausgangspunkte der Modellbildung zu ermöglichen.'" STACHOWIAK identifiziert in seiner Begriffsanalyse drei wesentliche Merkmale des Abbildungsbegriffs, die im Folgenden kurz dargestellt werden. Abbildungsmerkmal. "Modelle sind stets Modelle von etwas, nämlich Abbildungen, Repräsentationen natürlicher oder künstlicher Originale, die selbst wieder Modelle sein können."'" Unter einer Abbildung wird in Anlehnung an die Mengentheorie die Zuordnung von Originalmerkmalen zu Modellmerkma-

121

122 123 124

Die von Stachowiak vorgeschlagene allgemeine Modelltheorie disziplInunabhängigen Modellbegriff zu entwickeln. Vgl. Stachowlak (1973). Stachowiak (1983), S. 118. Vgl. Schütte (1998), S. 41 und S. 59 (dort Fn. 106). Stachowiak (1973), S. 131.

versucht

einen

36

Terminologie und Grundlagen der Informationssystementwicklung

len verstanden.

12S

Bzgl. des Verhältnisses von Modell und Original wird zwi-

schen isomorphen und homomorphen Modellen unterschieden. Isomorphie ist die maximale strukturelle Ähnlichkeit zwischen Modell und Original. Für jedes Originalelement existiert ein entsprechendes Modellelement et vice versa.'2. Bei Homomorphie bildet das Modell zwar einige, aber nicht alle Elemente des Originals ab, das Modell ist somit eine verkürzte Abbildung des Originals.'27 Der bei Isomorphie mögliche Umkehrschluss ist bei homomorphen Modellen nicht möglich.

Verkürzungsmerkmal. nModelie erfassen im Allgemeinen nicht alle Attribute des durch sie repräsentierten Originals, sondern nur solche, die den jeweiligen n128 Modellerschaffern undloder Modellbenutzern relevant erscheinen. Die Verkürzung ist problematisch, da die Auswahl der relevanten Merkmale bei der Verkürzung eine Abstraktionsleistung und somit ein selektiver Bewusstseinsprozess des Modellierers ist, der nur schwer rekonstruierbar ist. Die Erfassung der Inkongruenz über einen vollständigen Vergleich von Original und Modell dürfte ebenfalls nicht möglich sein, da ein solcher Vergleich die Kenntnisse aller Merkmale voraussetzt.''' Daraus ergibt sich, dass ein Original durch mehrere Modelle abgebildet werden kann et vice versa.'30 Zur Spezifikation der Ersetzungsfunktion eines Modells muss also ein Subjektbezug hergestellt werden. Dies geschieht bei der Festlegung des pragmatischen Merkmals.

Pragmatisches Merkmal. nModelie sind ihren Originalen nicht per se eindeutig zugeordnet. Sie erfüllen ihre Ersetzungsfunktion a) für bestimmte - erkennende undloder handelnde, modellbenutzende - Subjekte, b) innerhalb bestimmter Zeitintervalle und c) unter Einschränkung auf bestimmte gedankliche oder tatsächliche Operationen. n131 Durch diese dreifach-pragmatische Relativierung des Modellbegriffs muss im Rahmen einer Modellanalyse nicht nur die Frage

125

Vgl. Stachowiak (1973), S. 132; Schütte (1998), S. 41; Thomas (2005), S. 9. In Abweichung von der Terminologie Stachowiaks wird im Folgenden statt Attributen von Merkmalen gesprochen.

126 Vgl. Stachowiak (1973), S. 143 f. Schütte (1998), S. 42. '" Vgl. Bretzke (19801, S. 28 ff. 128 Stachowiak (1973), S. 132 in geänderter Orthographie. 129 Ein solcher Vergleich wäre nur möglich, wenn Modell und Original von einem Subjekt erstellt wurden. Vgl. Stachowiak (1973), S. 132; Themas (2005), S. 9. 130 Vgl. Wyssusek et al. (2002), S. 242. 131 Stachowiak (1973), S. 132 f.

37

Modelle

beantwortet werden, wovon etwas Modell ist, sondern es ergibt sich als Charakterisierung von Modellen das "Frage-Quadrupel" Wovon? - Für wen? Wann? - Wozu? Die im Modell nicht erfassten Merkmale des Originals werden als präterierte Merkmale bezeichnet. Darüber hinaus enthalten Modelle üblicherweise Merkmale, die in dem entsprechenden Original nicht vorkommen. Diese werden als abundante Merkmale bezeichnet. Das Modellverständnis

STACHOWIAKS

ist in Abbildung 5 dargestellt. Abbildung 5: Modellverständnis Stachowiaks Original (Diskurswelt)

Abbildungsvorbereich

Modell

Abbildung

präterierte Merkmale

abundante Merkmale Vgl. Stachowiak (1973), S. 157

Die Abbildungsrelation ist beim allgemeinen Modellbegriff sehr undifferenziert dargestellt, was wohl auf den Anspruch der allgemeinen Modelltheorie zurückzuführen ist, einen disziplinunabhängigen Modellbegriff bereitzustellen. Die DetailIierung der Abbildungsrelation führt nämlich zu den zwei Perspektiven des allgemeinen Modellbegriffs - dem abbildungsorientierten und dem konstruktivistischen Modellbegriff - die im Folgenden überblicksartig dargestellt werden. Der abbildungsorientierten Model/begriff hat seine Wurzeln in den betriebswirtschaftlichen Arbeiten zur Entscheidungstheorie, zur Unternehmensforschung und zur Organisationslehre.'32 Neben seiner Verwendung in der Be-

132

Vgl. zur Entscheidungstheorie einfOhrend Kosiol (1961), S. 318 ff.; Schweitzer (1967), S. 279 ff. und siehe Kapitel 3 dieser Arbeit; Vgl. zur Unternehmensforschung Kern (1964); Känel (1966); Vgl. zur Organisationslehre Grochla (1969). Weitere Vertreter sind bei Thomas (2005), S. 13 angegeben.

Terminologie und Grundlagen der Informationssystementwicklung

38

triebswirtschaftslehre wird der abbildungsorientierte Modellbegriff auch in der Wirtschaftsinformatik häufig referenziert.''' Beim abbildungsorientierten Modellbegriff wird das Abbildungsmerkmal der allgemeinen Modelltheorie in den Mittelpunkt der Betrachtung gerückt; ein Modell stellt demnach "ein adäquates Abbild der betrachteten Wirklichkeit""4 dar.''' Viele Vertreter des abbildungsorientierten Modellverständnisses stellen einen konkreten Bezug zur Realität her, d. h. Modelle nehmen hier eine Stellvertreterfunktion ein, indem sie Teile der (objektiv gegebenen) Realwelt abbilden.''' Teilweise wird diese Sichtweise relativiert und statt der Realität oder Wirklichkeit die Abbildung von 137 Sachverhalten als konstituierend angenommen. Diese Erweiterung auf immaterielle Gegenstände scheint insbesondere in der Wirtschaftsinformatik zweckmäßig, da bspw. nicht alle zu modellierenden Sachverhalte materiell existieren.

B8

Auch im abbildungsorientierten Modellverständnis bestimmen der Zweck der Modellierung, die Anforderungen von Modellnutzer und Modellierer und der Zeitpunkt der Modellerstellung, welche Merkmale der Wirklichkeit oder des Originals im Modell abgebildet werden."> Entsprechend dieser pragmatischen Anforderungen findet die Modellbildung, d. h. die Verkürzung, durch den Modellierer statt. Durch Interpretation und Abstraktion entsteht dabei zunächst

133

Vgl. bspw. lehner et al. (1995), S. 27; Wyssusek et al. (2002), S. 241; Ferstl, Sinz (2006), S. 20. Es ist vielfach die Behauptung anzutreffen, dass ein abbildungsorientierter Modellbegriff am

134 135

'" 137

138

139

Weitesten verbreitet sei. Vgl. zu dieser Behauptung: Schütte (1998), S. 47, 52; vom Brocke (2003), S. 10 Thomas (2005), S. 14. Bemerkenswert ist, dass die meisten Autoren als Beleg ihrer These auf einen Workshopbericht von Pohl, Schürr (1998) verweisen. In der Quelle selbst ist diese Behauptung explizit allerdings nicht zu finden, sondern lediglich eine Abbildung zum Modellbegriff, die die Interpretation zulässt, dass ein Modell eine Abbildung von etwas Ist. Vgl. Pohl, Schürr (1998), S. 11 f. Kosiol (1961), S. 321. Kosiol weist darauf hin, dass die Abbildungsfunktion einer Aussage noch nicht ausreichend ist, um von einem Modell zu sprechen. Von Modellen spricht Kosiol (1961), S. 319 erst, uwenn es sich um zusammengesetzte Gedankengebilde handelt, die aus der Totalinterdependenz der Wirklichkeit abgegrenzte und übersehbare Teilzusammenhänge ausgliedern, um die bestehende Abhängigkeitsbeziehungen auf ihre Gesetzmäßigkeit zu untersuchen."

Vgl. Kosiol (1961), S. 321; Lehner et 01. (1995), S. 27; Ferstl, Sin, (2006), S. 20. Vgl. bspw. Wyssusek et al. (2002), S. 241. Vgl. Goeken (2006), S. 87. Wenn Modelle bel der Entwicklung von Informationssystemen eingesetzt werden, existieren die zu modellierenden Sachverhalte bei der Modellerstellung noch nicht. Vg!. Wyssusek et a!. (2002), S. 243.

39

Modelle

ein mentales Abbild der Diskurswelt, das sogenannte Objektsystem."o Dieses Objektsystem wird anschließend (mithilfe einer Modellierungssprache) in ein Modell übersetzt. Der abbildungsorientierte Modellbegriff fußt auf einem ontologischen und erkenntnistheoretischen Realismus. Bezogen auf die Modellbildung bedeutet dies, dass einerseits davon ausgegangen wird, dass das Original in der Realwelt unabhängig von der menschlichen Erkenntnis existiert und andererseits der Modellierer das abzubildende Original objektiv erkennt. Die Modellbildung reduziert sich unter diesen Annahmen auf objektives Wahrnehmen und logisches Schließen des Modellierers.'" In den vergangenen Jahren ist der abbildungsorientierte Modellbegriff stark in die Kritik geraten.'42 Die Hauptkritik zielt auf die Annahme eines intersubjektiv gültigen Objektsystems und den dadurch präsupponierten (naiven) erkenntnistheoretischen Realismus ab.'" Wird die Annahme eines erkenntnistheoretischen Realismus fallen gelassen und wird weiter davon ausgegangen, dass Modellierer und Modellnutzer nicht in allen Fällen übereinstimmen, so muss die Annahme einer eindeutigen Objekt-Modell-Relation tatsächlich aufgegeben werden.'44 Des Weiteren kritisiert SCHÜTTE, dass bereits Probleme als Ausgangspunkt der Modellbildung nicht objektiv, sondern in einer Subjekt-ObjektRelation entstehen.'4S Durch diese unzulässige Annahme eines objektiv existierenden Problems erübrigt sich für SCHÜTTE jede weitere Kritik am abbildungsorientierten Modellbegriff."6 Zusammenfassend lässt sich feststellen, dass der Forderung des abbildungsorientierten Modellverständnisses nach objektiven

140

Vgl. Nach Thomas (2005) repräsentiert das Objektsystem "dle (subjektive) Interpretation des gewählten Diskurssystems sowie den als relevant eingeschätzten Ausschnitt der Umwelt des Objektsystems. Ähnlich führen Ferstl. Sinz (2006), S. 5 f. aus: .. Die Diskursweltobjekte, die zugehörigen Umweltobjekte und die Beziehungen zwischen diesen Objekten bilden zusammen das betriebliche Objektsystem." Vg!. auch Rosemann (1996), S. 17 f.; vom Brocke (2003), S. 10. Vg!. Schütte (1998), S. 48. Vg!. Schütte (1998); Dresbach (1999); Wyssusek et a!. (2002); vom Brocke (2003). Vgl. vom Brocke (2003), S. 11 f. Schütte spricht gar davon, dass die Problematik der Beziehung zwischen realem System und Modell durch die Einführung eines Objektsystems geradezu "versteckt" wird. Vgl. SchOtte (1998), S. 48. Vgl. SchOtte (1998), S. 56 ff. fOr die Kritik am abbIldungsorientierten Modellverständnis aus erkenntnistheoretischer Sicht. Vg!. Schütte (1998), S. 58 für die Kritik aus der Perspektive des Modellerstellers. Vg!. Schütte (1998), S. 48. Vg!. Schütte (1998), S. 48. U

141 142

143

144

145 146

Terminologie und Grundlagen der Informationssystementwicklung

40

Modellen und intersubjektiver Nachvollziehbarkeit in der Wirtschaftsinformatik nicht gefolgt werden kann. Ausgehend von der Kritik am abbildungsorientierten Modellbegriff hat sich zunächst in der Betriebswirtschaftslehre'47 und später in der Informatik'" der konstruktivistische Model/begriff herausgebildet. Auch in der Wirtschaftsinformatik wird seit Mitte der 1990er Jahre der konstruktivistische Modellbegriff immer häufiger verwendet.'" Der konstruktivistische Modellbegriff bildet den Gegenpol zum abbildungsorientierten Modellbegriff und berücksichtigt insbesondere die Hauptkritik an diesem, indem die Annahme eines erkenntnistheoretischen Realismus zugunsten eines erkenntnistheoretischen Idealismus fallenge lassen wird. Da die Realität im konstruktivistischen Modellverständnis nicht objektiv erfahrbar ist, wird entweder von Originalen oder von Problemen als Ausgangspunkt der Modellbildung gesprochen. Modelle werden im konstruktivistischen Modellverständnis zur Lösung einer vom Modellierer als subjektiv problematisch empfundenen Situation erstellt.

l5O

Probleme zeichnen sich nach dem

konstruktivistischen Verständnis allerdings gerade durch einen Strukturmangel aus und nicht, wie für den abbildungsorientierten Modellbegriff erforderlich, durch wohldefinierte Strukturen.'51 Das zur Problem lösung konstruierte Modell verfügt somit über Merkmale, die dem Original fehlen, nämlich Strukturiertheit und Analysierbarkeit.

152

Originale existieren im konstruktivistischen Verständ-

nis nicht zwangsläufig vor der Modellbildung, sondern können erst während der Problemlösung entstehen, bspw. in Form eines Informationssystems. Von großer Bedeutung im konstruktivistischen Modellverständnis ist das pragmatische Merkmal: Der Modellnutzer bestimmt zunächst die (pragmatischen) Anforderungen an das Modell. Da er aber nicht die Methodenkompetenz zur Erstellung von Modellen hat, beauftragt er einen Modellierer. Bei der Kon-

u' Vgl. Bretzke 11980); De Moliere 11984). Vgl. Ortner (1997), S. 11; Floyd, Klischewski (19981, S. 21 ff. '" Vgl. Goorhuis (1994); Zelewski (1995), S. 1511.; Schütte (1998), S. 5911.; Wyssusek et al. (2002); vom Brocke (2003); Delfmann (2006); Goeken (2006). 148

150 151 152

Vgl. Zelewski (1995), S. 15; Thomas (2005), S. 18. Vgl. Dresbach (1999), S. 75. Vgl. auch den Problembegriff in Abschnitt 1.2.1. Vgl. Goeken (2006), S. 89.

41

Modelle

struktion des Modells (der Verkürzung) ergibt sich das Problem, dass die internen (mentalen) Modelle (das Objektsystem) des Originals von Modellierer und Nutzer nicht identisch sind und somit die Zielvorstellungen über das pragmatische Merkmal auseinanderfallen. Der Modellierer expliziert unter Mitwirkung des Nutzers mithilfe einer Modellierungssprache ein explizites Modell als Ergebnis der Modellierung - wobei die verschiedenen internen mentalen Modelle eine intensive Kommunikation zwischen Modellierer und Nutzer erfordern.'S3 Neben der Auffassung, dass im konstruktivistischen Modellverständnis kein intersubjektiv gültiges Objektsystem existiert, wird die Nachvollziehbarkeit von Modellen zusätzlich dadurch erschwert, dass auch der Zweck und das identifizierte Problem eines Modells subjektiv sind. Die dargestellte Abbildungsrelation des konstruktivistischen Modellbegriffs (b) ist in Abbildung 6 der Abbildungsrelation des abbildungsorientierten Modellbegriffs (a) gegenübergestellt. Abbildung 6: Perspektiven auf den allgemeinen Modellbegriff (al Abbildungsorientierter Modellbegriff Ori ginal (Diskurswelt)

Modell

Interpretation

Obj ektwstem

Abbildung

praterierte Merkmale Zweck

abundante Merkmale

(b) Konstruktivistisch er Modellbegriff

Orig inallDi~kursweltJ

Objektsystem de> Modelli

Modell

wstem

dc;

pr~te rierte

Merkmale

ModellnUllers

~bundante

Merkmale

Zweck

153

Vgl. Wyssusek et al. (2002), S. 243 zum Konzept der Viabilität. Floyd, Klischewski (1998), S. 23 f. heben hervor, dass die Modellbildung als "soziale Konstruktion zu betrachten ist. U

Terminologie und Grundlagen der Informationssystementwicklung

42

Wird einem abbildungsorientierten Modellbegriff gefolgt, können aufgrund des angenommen Zusammenhangs zwischen Original und Modell neue Erkenntnisse, die im Modell erzielt werden auf das Original übertragen werden. Ein solcher Analogieschluss ist bei einem konstruktivistischen Modellverständnis nur eingeschränkt möglich.'54 Es kann festgehalten werden, dass im Bereich der Wirtschaftsinformatik ein konstruktivistischer Modellbegriff zweckdienlicher erscheint, da der Umgang mit dem Phänomen der Subjektivität erleichtert wird. Mit den Grundsätzen ordnungsmäßiger Modellierung (GoM) existiert außerdem bereits ein Ansatz, um die intersubjektive Nachvollziehbarkeit von Modellen zu verbessern.'55

2.4.2

Model/begriff dieser Arbeit

Der Modellbegriff dieser Arbeit muss mit der in Abschnitt 1.2 explizierten Forschungskonzeption harmonieren. Im gewählten konstruktionsorientierten Forschungsparadigma fungieren Modelle als Artefakte, die zur Lösung eines Problems verwendet werden. Da auch die wissenschaftstheoretischen Grundpositionen, insbesondere der erkenntnistheoretische Idealismus, mit dem konstruktivistischen Modellbegriff vereinbar ist, wird ein solcher im Folgenden verwendet. 15• Ausgangspunkt der Modellbildung ist nach dem konstruktivistischen Modellbegriff ein Problem, d. h. ein Diskrepanzempfinden zwischen Erreichtem und Erwünschten. Zur Lösung des erkannten Problems wird anschließend ein Modell erstellt. Da die Wahrnehmung von Problemen durch Modellnutzer und Modellierer ebenso wie die Lösung der Probleme durch den Modellierer subjektiv ist und die Subjektivität des Problem begriffs auf den Modellbegriff ausstrahlt, wird davon ausgegangen, dass eine Modellbildung außerhalb subjektiver Wahrnehmungen unmöglich ist. Wie bereits in Abschnitt 1.2.2.2 ausgeführt, wird von einer objektiv existierenden Realität ausgegangen, da nach Auffassung des Verfassers ohne diese Annahme keinerlei Norm entwickelbar

154 155

156

Vgl. Wyssusek et al. (2002), S. 244. Vgl. ausfOhrlich Becker et al. (1995); Schatte (1998), S. 111 ff.i Knapper bel Becker, Schatte (2004), s. 12011. Auch Dresbach (1999), S. 74 hält weder einen Realismus noch Konstruktivismus in seiner reinen Form für angebracht in der Wirtschaftsinformatik.

43

Modelle

ist, um "richtige" von "falschen" Modellen zu unterscheiden.

157

Dass die an

dem Modellerstellungsprozess beteiligten Akteure Probleme haben, richtige von falschen Artefakten zu unterscheiden, liegt an dem Realitätszugang selbst. Modelle reduzieren gemäß dem Verkürzungsmerkmal Komplexität, indem sie sich auf ausgewählte Merkmale beschränken. Dabei ist zu betonen, dass komplexe Probleme üblicherweise keinesfalls mithilfe eines einzigen Modells gelöst werden. Es wird vielmehr eine Vielzahl an Modellen eingesetzt, die jeweils einen bestimmten Zweck gemäß dem pragmatischen Merkmal verfolgen. Das einzelne Modell beschränkt sich somit auf einen festgelegten Aspekt des Problems. Basierend auf den dargestellten Überlegungen ergibt sich für die vorliegende Arbeit folgender Modellbegriff: Ein Modell ist ein Artefakt, das zur Lösung eines identifizierten Problems von einem Modellierer für Modellnutzer erstellt wird. Modelle reduzieren durch Beschränkung auf einen Aspekt und ausgewählte Merkmale Komplexität. Je nachdem, auf welche Probleme Modelle fokussieren, werden in dieser Arbeit Informationsmodelle und Entscheidungsmodelle verwendet. Während Informationsmodelle in Abschnitt 2.4.3 vorgestellt werden, werden Entscheidungsmodelle in Kapitel 3.1.2 nach der Darstellung von Entscheidungssituationen vorgestellt. Zum Abschluss wird zur Vereinfachung noch die Sprach regelung festgelegt, dass Informationsmodelle im Folgenden als Modelle bezeichnet werden können. Entscheidungsmodelle dagegen werden immer explizit als solche bezeichnet.

2.4.3

Informationsmodelle

Informationsmodelle stellen einen Modelltyp zur Lösung von Problemen im Zusammenhang mit Informationssystemen dar.

15

'

Einer der wesentlichen Ein-

satzzwecke dieses klassischen Modelltyps der Wirtschaftsinformatik ist die Unterstützung der Informationssystementwicklung. Informationsmodelle können auf vielfältige Art und Weise klassifiziert werden. In Abbildung 7 werden in

157

158

Ähnlich argumentiert Schütte (1999), S. 224. Vgl. Schütte (1998), S. 63 ff.; vom Brocke (2003), S. 26 f.

Terminologie und Grundlagen der Informationssystementwicklung

44

Anlehnung an SCHÜTTE die für diese Arbeit relevanten Informationsmodellklassen als ER-Modell dargestellt.'59 Abbildung 7: Informationsmodellklassen


Informationsmodell

~-

-

achkonzeptionelles Irrformationsmodell logisches Irrformationsmodell physisches

Irrformationsmodell

~

Meta"-Modell

1

r--

Met amodell

'-----

Objektmodell

Vgl. SchUtte (19981, S. 64.

StrukturInformatiOllsmodell Verhaltens-

Inforrnation5modelle

J

Ist-Informat ionsmodell


5011-1 nforma tionsmodell

Während der Entwicklung eines Informationssystems kommt eine Vielzahl an Modellen zum Einsatz, die jeweils auf unterschiedliche Aspekte fokussieren und nach ihrer Nähe zur Informationstechnik in (fach-)konzeptionelle, logische und physische Modelle unterteilt werden. '60 Während konzeptionelle In!ormationsmodelle weitgehend losgelöst von technischen Überlegungen beschreiben, was ein Informationssystem aus betriebswirtschaftlicher Sicht leisten soll, enthalten logische Informationsmodelle bereits Überlegungen, wie das Informationssystem technisch zu realisieren ist.'" Physische Informationsmodelle dienen der programmiertechnischen Realisierung und Implementierung eines Informationssystems. In dieser Arbeit werden im Wesentlichen konzeptionelle Intormationsmodelle betrachtet, da aus Sicht der Wirtschaftsintormatik das

159

150

161

ff.; Becker, Schütte (20041, S. 68 ff. für eine Darstellung aller Informationsmodellklassen. Vgl. MVlopoulos (1998), S. 129 f.; Scheer (1998b), S. 14 ff. bezeichnet die Beschreibungsebenen als Fachkonzept, DV-Konzept und technische Implementierung. Bspw. enthalten logische Modelle einer Datenbank bereits eine Festlegung, mit welchem Datenbankmodell (z. B. hierarchisches, Netzwerk-, relationales Datenbankmodell) die Datenbank realisiert wird. Vgl. Schütte (1998), S. 64

Modelle

45

korrekte Erfassen betriebswirtschaftlicher Anforderungen als besonders kritisch erachtet wird und das Scheitern von Systementwicklungsprojekten oftmals auf fehlerhafte oder unvollständige Anforderungen zurückzuführen ist.'" Konzeptionelle Informationsmodelle sind verbreitet und dienen bei der Informationssystementwicklung insbesondere der Unterstützung der Kommunikation zwischen Fachabteilung und IT-Abteilung und somit der exakten Spezifikation der betriebswirtschaftlichen Problemstellung. Konzeptionelle Informationsmodelle werden üblicherweise mithilfe sem i-formaler Modellierungssprachen erstellt, die auch Mitarbeitern der Fachabteilung rasch zugänglich sind.'"

Ist-Informationsmodelle werden eingesetzt, um die Komplexität von Informationssysternen zu reduzieren und sie gedanklich zu durchdringen und zu analysieren.'" Während diese somit als "Fenster zur Wirklichkeit" fungieren, wirken

Soll-Informationsmodelle als "Handgriff zur Wirklichkeit", wenn das abgebildete Informationssystem (oder Teile davon) bisher nur in der Vorstellung eines Modellierers existiert und zur Entwicklung von Informationssystemen genutzt wird.'65 Da die vorliegende Arbeit Gestaltungsziele verfolgt, werden überwiegend Soll-Informationsmodelle eingesetzt.'66 Informationsmodelle können je nach systemtheoretischer Perspektive unterschieden werden in Struktur-Informationsmodelle und Verhaltens-Informationsmodelle.'67 Beide Modellarten werden im Rahmen dieser Arbeit eingesetzt. In Abhängigkeit von der semantischen Stufe werden Informationsmodelle in Objektmodelle, Metamodelle, Metametamodelle etc. unterschieden werden. Diese Unterscheidung wird in Abschnitt 2.5.3 detailliert.

Vgl. Wand, Weber (2002). Vgl. Becker, pfeiffer (2007), S. 1 f. Eine Übersicht derartiger Modellierungssprachen ist etwa bei Mylopoulos (1998) zu finden. '" Vgl. Thomas (2005), S. 3. 165 Vgl. Floyd, Klischewski (1998), S. 21 f.; Wyssusek et al. (2002), S. 241. Rosemann (1996), S. 19 f. unterscheidet zwischen Erklärungs- und Gestaltungsaufgabe von Modellen. 166 Vgl. Delfmann (2006), S. 44 für eine ähnliche Position. 167 Vgl. Schütte (1998). 162

163

46

2.5

Terminologie und Grundlagen der Informationssystementwicklung

Modellierungstechniken und ihre Bestandteile

Informationsmodelle und deren Konstruktion spielen in dieser Arbeit eine wesentliche Rolle. Da zur Erstellung derartiger Modelle eine Modellierungstechnik erforderlich ist, werden die Merkmale einer Modellierungstechnik im Folgenden dargestellt.''' Eine Modellierungstechnik besteht aus einer Modellierungssprache, in der das Modell zu formulieren ist und einer Handlungsanleitung, die ausführt, wie unter Verwendung dieser Sprache ein Modell generiert wird.''' Die Modellierungssprache wird als grundlegenderes und wichtigeres Element einer ModelIierungstechnik betrachtet, da eine Handlungsanleitung lediglich auf Basis einer Sprache beschrieben werden kann. VERHOEF et al. bezeichnen die sprachlichen Aspekte einer ModelIierungstechnik als "way of modelling" und den Prozess der Modellerstellung als "way of working".170 Die Struktur einer Modellierungstechnik ist in Abbildung 8 als ER-Modell dargestellt. Abbildung 8: Modellierungstechnik

r-:::ll,n~l,n ~~

','------0-',' L_M_""_·'Tlie_ru_'g>----.J technik

Modellierungssprache

'------,----' 1,1 rundlesend für

1,1 Handlungs-

anleitung

1&1

169 110

Der Vorgang der Modellerstellung wird als Modellierung bezeichnet. Es handelt sich dabei nach vom Brocke (2003), S. 25 um ein Arbeitsgebiet, Hdas die Gestaltung und Ausführung von Prozessen im Zusammenhang mit der Konstruktion von Modellen zum Gegenstand hat." Vgl. Holten (1999), S. 9i Holten (2000), S. 4. Sinz (2001) schlägt zur Klassifizierung von Modelllerungsansätzen die Merkmale Modellierungsrelchwelte, Modellierungszweck und Modellumfang vor. Vgl. Strahringer (1996), S. 91; Holten (2000), S. 4. Vgl. Verhoef et al. (1991), S. 502 ff.

47

ModelIierungstechniken und ihre Bestandteile

In den folgenden Abschnitten 2.5.1 und 2.5.2 werden Modellierungssprache bzw. Handlungsanleitung als die Komponenten einer Modellierungstechnik ausführlicher betrachtet. Die wesentlichen Merkmale einer Modellierungstechnik können mithilfe von Metamodellen dargestellt werden, weshalb Metamodelle einer Modellierungstechnik Gegenstand von Abschnitt 2.5.3 sind.

2.5.1

Modellierungssprache

Eine ModelIierungssprache als konstituierendes Element einer Modellierungstechnik ist eine künstliche Sprache zur Konstruktion von Modellen und ist ebenso wie Sprache im Allgemeinen - ein System von Konstrukten.'71 Eine Modellierungssprache verwendet als Konstrukte üblicherweise Symbole, die mindestens zweidimensional beschrieben sind (z. B. Kreise, Rechtecke, Rauten). Die Gesamtheit der Konstrukte bildet das Vokabular einer Modellierungssprache.

172

Liegt das Vokabular einer (Modellierungs-)Sprache vor, so fehlen noch Regeln, wie die Konstrukte zu größeren sprachlichen Ausdrücken (Sätzen) verknüpft werden. Die Summe der Verknüpfungsregeln wird als Syntax bezeichnet und bildet den wesentlichen Bestandteil einer Grammatik.'" Es kann unterschieden werden in konkrete und abstrakte Syntax einer Sprache.

174

Während die abs-

trakte Syntax die verfügbaren Konstrukte und deren Beziehung konzeptionell beschreibt, ordnet die konkrete Syntax - auch Notation genannt - den Kon-

171

172 173 174

Vgl. Patig (2007). S. 26. Teilweise werden Sprachen auch als ..System von Zeichen" bezeichnet. Der Begriff Konstrukt generalisiert die Begriffe Zeichen und Symbol und wird daher im Folgenden verwendet. Vgl. zu Sprache als System von Zeichen Carnap (1960). S. 1; Petöfi (1980), S. 599; vom Brocke (2003). S. 64; Goeken (2006). 5. 70. Zeichen können nach Petöfi (1980), 5. 599 unterschieden werden in Symbole (z. B. kultische Zeichen). ikonische Zeichen (z. B. Zeichnungen). Signale (z. B. Verkehrszeichen) und lautsprachliche Symbole. Andere Autoren unterscheiden dagegen lediglich in Symbole und "Satzstrukturen". Vgl. Larkin, Simon (1987), S. 68; Frank, van Laak (2003), S. 20. Nach ihrer Entstehung werden Sprachen unterschieden in kanstliche und natürliche Sprachen. Vgl. Petöfl (1980). S. 598; Lorenz (1996b), S. 52: Strahringer (1996). S. 17: Strahringer (1998). S. 1: Patig (2007). S. 27. Vgl. Patig (2007), S. 26. Vgl. Lorenz (1996c). S. 176 ff. Vgl. Frank, van Laak (2003), S. 20 f.

Terminologie und Grundlagen der Informationssystementwicklung

48

strukten konkrete Symbole zu. Eine Sprache kann dabei durchaus mehrere inhaltlich gleichwertige Notationen haben.

175

Die Semantik einer Modellierungssprache ordnet den Konstrukten eine Bedeutung zu, d. h. sie stellt einen Bezug zwischen sprachlichen Ausdrücken und Diskurswelt her.

170

Dabei ist zwischen der extensionalen und der intensionalen

Semantik zu unterscheiden. Die extensionoie Semontik beschreibt die Relation zwischen sprachlichem Ausdruck und einem konkreten Objekt der Diskurs177

welt. Anders ausgedrückt beschreibt die Extension den Begriffsumfang, indem sie sprachlichen Ausdrücken konkrete Objekte zuordnet. Die intensiona-

le Semantik dagegen beschreibt den Begriffsinhalt und wird auch als Konnotat oder Konnotation bezeichnet."· Zur Beschreibung der intensionalen Semantik eines sprachlichen Ausdrucks werden Merkmale festgelegt. Die Extension eines Modells sind die konkreten Objekte und Beziehungen des Objektbereichs, z. B. die konkreten Kunden (Herr Müller, Frau Meier, ... ) oder Lieferanten eines Unternehmens (Liefergünstig GmbH, Feiekom AG, ... ). Intensional betrachtet werden diese Objekte anhand von Merkmalen beschrieben. So haben etwa Kunden die Merkmale Kundennummer und Anschrift, während Lieferanten die Merkmale Lieferantennummer, Ansprechpartner und Kontonummer haben. Bei der Modellierung von Informationssystemen wird üblicherweise von der extensionalen Semantik abstrahiert. Die Semantik einer (Modellierungs-)Sprache variiert zwischen Personen, da diese unterschiedliche Intentionen und Perspektiven auf außersprachliche Gegenstände haben. Um präzise und eindeutige Informationsmodelle erstellen zu können, muss jedoch mindestens die abstrakte Syntax einer Modellierungssprache eindeutig und präzise definiert sein. Nur wenn die Konstrukte und deren Beziehung eindeutig definiert sind, kann die Modellierungssprache korrekt verwendet werden.

175

176 171

111

Strahringer (1996), S. 92; Holten (2000), S. 4 f.; Holten (2001a), S. 6 unterscheiden zwischen dem konzeptionellen und dem repräsentationalen Aspekt einer Modellierungstechnik. Diese Unterscheidung ist unpräziser als die hier gemachte, da die genannten Autoren nicht zwischen Vokabular, Syntax und Semantik unterscheiden. Vgl. Follesdal (1980), S. 570; Petöfi (1980). S. 599 f.; Lorenz (1995), S. 768 ff. Das konkrete Objekt eines sprachlichen Ausdrucks wird oftmals als Denotat bezeichnet. Vgl. Fuhrmann (1995), S. 775 f.; Strahringer (1996), S. 43 f.

ModelIierungstechniken und ihre Bestandteile

49

Modellierungssprachen können, je nachdem ob ihre Syntax und Semantik eindeutig festgelegt ist, nach ihrem Formalisierungsgrad klassifiziert werden.'" Eine informale Modellierungssprache stellt lediglich ein Vokabular zur Verfügung und verfügt weder über eine eindeutig festgelegte Syntax noch über eine 180 Eine semi-formale Modellierungssprache eindeutig festgelegte Semantik. besitzt dagegen neben einem Vokabular eine festgelegte abstrakte Syntax. Eine Semantik existiert bei semi-formalen Sprachen dagegen nur rudimentär und lässt Interpretationsspielräume zu.'·' Eine formale Modellierungssprache verfügt über ein Vokabular, dessen Semantik eindeutig festgelegt ist. Auch die zulässige Verwendung des Vokabulars bei der Modellerstellung ist durch abstrakte Syntax und semantische Integritätsbedingungen eindeutig festgelegt. Ein steigender Formalisierungsgrad geht meistens mit einer wachsenden Sprachkomplexität einher. Dies ist insbesondere dann problematisch, wenn Modellierungssprachen genutzt werden, um mit späteren Anwendern oder Mitarbei182 tern der Fachabteilung zu kommunizieren. Da die Arbeit wesentlich auf die Erstellung konzeptioneller Modelle abzielt und dabei die Kommunikation mit Mitarbeitern der Fachabteilung im Vordergrund steht, werden in dieser Arbeit 183 im Wesentlichen semi-formale Modellierungssprachen eingesetzt. Es wird unterschieden in domänenspezifische und domänenneutrale (Modellierungs-) Sprachen.

184

Während eine domänenneutrale Modellierungssprache

für vielfältige Verwendungszwecke eingesetzt werden kann, entspricht eine domänenspezifjsche Modellierungssprache den Anforderungen einer bestimm-

179

1111

181

182 183

184

Vgl. hier und zum folgenden Absatz: Frank, van Laak (2003), S. 20 f. Frank, van Laak (2003) weisen darauf hin, dass sich bei informalen Sprachen Syntax und Semantik indirekt durch Interpretation des Modellbetrachters ergeben können. Syntax und Semantik sind dann subjektiv und können mehrdeutig sein. Vgl. Goeken (2006), S. 72. Vgl. Lehner et al. (1995), 5. 82. In der Modellierungspraxis verbreitete semi-formale Modellierungssprachen oder vielmehr -techniken sind etwa das ER-Modell zur Strukturmodellierung und ereignisgesteuerte Prozessketten (EPK) zur Verhaltensmodellierung. ER-Modelle sind trotz der Bezeichnung kein Modell im Sinne dieser Arbeit, sondern eine Technik. Diese terminologische Schwierigkeit resultiert daraus, dass In der engllschsprachlgen Terminologie Sprachen oftmals als nmodel" und das Sprachprodukt als Hschema" bezeichnet werden. ER-Modell und EPK werden ausführlich in Anhang A bzw. Anhang B vorgestellt. Vgl. Harvey (2005), S. 672.

so

Terminologie und Grundlagen der Informationssystementwicklung

ten Anwendungsdomäne!85 Anders ausgedrückt ist das Vokabular und die abstrakte Syntax einer domänenspezifischen Modellierungssprache angepasst an die Konzepte der Anwendungsdomäne. Auch enthält eine domänenspezifische Modellierungssprache eine teilweise definierte intensionale Semantik. Sie ist dadurch ein für eine entsprechende Situation besser geeignetes Werkzeug, das allerdings in einer anderen Situation schlechter geeignet ist als eine domänenneutrale Modellierungssprache.

18

'

Die Entwicklung einer domänenspezifi-

schen Sprache muss demnach gerechtfertigt werden durch hinreichend große Vorteile gegenüber der Verwendung von domänenneutralen Sprachen. Mithilfe von (Modellierungs-)sprachen werden (wissenschaftliche) Aussagen über einen zu untersuchenden Gegenstandsbereich formuliert. Da Sprache selbst Gegenstand von Untersuchungen sein kann, ist es sinnvoll, in Anlehnung an die Sprachstufentheorie der Logik zwischen verschiedenen Sprachebenen, auch semantische Stufen genannt, zu unterscheiden.

187

Ist der beschriebene

Gegenstandsbereich nichtsprachlicher Art (Objekte einer Wissenschaft), wird die Sprache als Obje/ctsprache bezeichnet. Werden Aussagen über sprachliche Gegenstände, z. B. über die Struktur der Objektsprache, getroffen, handelt es sich bei der Sprache um eine sogenannte Metasprache!" Wird die Metasprache wiederum selbst sprachlich untersucht, so handelt es sich bei der verwendeten Sprache um die Metasprache der Metasprache der ursprünglichen Objektsprache, welche auch als Metametasprache bezeichnet wird. Da dieses Prinzip der metasprachlichen Untersuchung rekursiv anwendbar ist, kann eine beliebig große Hierarchie von Sprachebenen gebildet werden.

18

'

Die Eigen-

schaft einer Sprache Objekt- oder Metasprache zu sein ist relativ, d. h. ein und dieselbe Sprache kann als Objektsprache und als Metasprache fungieren. Sogar innerhalb einer einzigen Untersuchung kann dieselbe Sprache als Objekt- und

188

Becker, pfeiffer (2007), S. 8 bezeichnen eine Modellierungssprache als domänenspezifisch, "wenn ihre Konzepte zu einem überwiegenden Teil aus der Fachsprache einer bestimmten Anwendungsdomäne entlehnt sind,« Vgl. Holten (2000), S. 10. Vgl. Strahringer (1996), S. 17 f.; Holten (1999), S. 11. Essler (1980), S. 428 f.; Strahringer (1996), S. 17 f.; Holten (1999), S. 11.

la9

Vgl. Strahringer (1996), S. 18.

18S

186

1B7

ModelIierungstechniken und ihre Bestandteile

51

Metasprache fungieren, was jedoch problematisch sein kann, da unter Umständen die Sprachebene schwierig zu identifizieren ist. 2.5.2

190

Handlungsanleitung

Die Handlungsanleitung einer Modellierungstechnik - auch als way 0/ working oder Modellierungsprozess bezeichnet - beschreibt den Prozess, wie mithilfe der Sprache ein Modell zu erstellen ist.'" Eine Handlungsanleitung besteht aus einer Reihe von Arbeitsschritten (Aktivitäten, Aufgaben), die in einer bestimmten Reihenfolge abgearbeitet werden müssen, um ein syntaktisch und semantisch korrektes Modell zu erstellen.'" Wesentliches Ziel einer Handlungsanleitung ist die korrekte Zuordnung von Bezeichnungswörtern zu den Konstrukten der Modellierungssprache.'·' Für jeden Arbeitsschritt müssen dabei Kriterien definiert werden, wann die Aktivität beginnt, wann sie beendet ist und wann die darauffolgende Aktivität beginnt.'" Handlungsanleitungen können auch Restriktionen und syntaktische Regeln enthalten, wie die Konstrukte der Sprache kombiniert werden dürfen. Da Modelle oftmals schrittweise verfeinert werden, ist es sinnvoll, wenn Handlungsanleitungen dies berücksichtigen, etwa indem sie mehrfach durchlaufen werden können oder Verfeinerungen konkret beschrieben werden. Handlungsanleitungen einer ModelIierungstechnik werden oftmals eher am Rande beschrieben und bewegen sich meist auf einer recht globalen Ebene. Obwohl dies grundsätzlich bedauerlich ist, da eine detaillierte Handlungsanleitung zu potenziell besseren Modellen führen kann, werden in dieser Arbeit aus Gründen der Forschungsökonomie Handlungsanleitungen von Modellierungstechniken nicht betrachtet.'·s

1JlO

191

192 193

194

195

Strahringer (1996). S. 18 f. Ein derartiges Beispiel findet sich in Anhang A. Vgl. Strahringer (1996), S. 91 f. Ähnlich Karagiannis, Kühn (2002), S. 183: ... The modelling procedure describes the steps applying the modelling language to create results, i.e. models." Die Handlungsanleitung der EPK findet sich als ein Beispiel in Anhang B.2. Vgl. Becker et al. (2001), S. 9. Sie welsen darauf hin, dass die Identifikation der Relation zwischen Realwelt und Bezeichnungswörtern nicht Gegenstand der Handlungsanleitung ist. Vgl. Jablonski et al. (1997), S. 141. Vgl. Verhoef et al. (1991), S. 503 ff.

52

2.5.3

Terminologie und Grundlagen der Informationssystementwicklung

Metamodelle einer Modellierungstechnik

Ebenso wie Sprachen durch Sprachen beschrieben werden, können auch Modelle selbst Gegenstand der Modellbildung sein. Je nachdem, welchen Gegenstandsbereich sie beschreiben, können Modelle in Anlehnung an die Sprachstufentheorie der Logik unterschieden werden in (Objekt-)Modelle"', Metamodelle, Metametamodelle usw. In einer ersten Näherung kann ein Metamodell somit als das Modell eines Modells beschrieben werden.'" Diese Begriffsbildung ist allerdings zu unpräzise, da nicht deutlich wird, welcher Aspekt des zugrundeliegenden Modells von einem Metamodell beschrieben wird und zu viele unterschiedliche Modellarten als Metamodell zu bezeichnen wären.'" Der in einem Metamodell abgebildete Aspekt eines Modells wird von STRAHRINGER als Metaisierungsprinzip bezeichnet.'" Es werden zwei Metaisierungsprinzipien unterschieden, die von praktischer Relevanz sind: Wird die zur Erstellung eines Modells verwendete ModelIierungssprache in einem Modell abgebildet, so wird das Prinzip der sprachbasierten Metaisierung angewandt. Resultierende Modelle werden als sprach basierte Metamodelle bezeichnet und stellen die abstrakte Syntax dar. Wird dagegen der Modellbildungsprozess, also die Handlungsanleitung einer Modellierungstechnik, in einem Modell dargestellt, so wird das Prinzip der prozessbasierten Metaisierung angewendet und es entstehen prozessbasierte Metamodelle. Der sprach-

basierte Metamodellbegriff ist in der Literatur sehr dominant.'oo Oftmals wird verschwiegen, dass überhaupt ein weiterer relevanter Metamodellbegriff existiert. Da Metaisierungsprinzipien rekursiv anwendbar sind, können beliebig große Modellhierarchien gebildet werden. Beim Aufbau von Hierarchien können höhere Hierarchieebenen (z. B. die Metametamodellebene) nur erreicht werDer Begriff Objektmodell sorgt für terminologische Schwierigkeiten und soll daher im Folgenden nicht weiter verwendet werden. 197 Vgl. Strahringer (1996), S. 22. Ähnlich Holten (2001b), S. 300: ... Das Attribut meta beschreibt die Rolle eines Modells (... ), die diesem (... ) in Bezug auf ein anderes (Objekt-)Modell zukommt." 198 Vgl. Strahringer (1996), S. 22 f. 199 Vgl. Strahringer (1996), S. 24 ff. zoo Vgl. Strahringer (1996), S. 14 für eine Auswahl möglicher Metamodelldefinitionen. Rein sprachbasierte Metamodellbegriffe verwenden etwa Schütte (1998), S. 72; Karagiannis, Kühn (2002), S. 183; Ferstl, Sinz (2006), S. 125; Goeken (2006), S. 75 f. 196

ModelIierungstechniken und ihre Bestandteile

53

den, wenn innerhalb einer Hierarchie nicht das Metaisierungsprinzip gewechselt wird, d. h. zwischen Metametamodell und Metamodell muss dasselbe Metaisierungsprinzip verwendet werden, wie zwischen Metamodell und Modell etc.'·' In der Modellierungspraxis wird oftmals mit zweistufigen (Modell, Metamodell) oder dreistufigen Hierarchien (Modell, Metamodell, Metametamodell) gearbeitet. Mittels der genannten Metaisierungsprinzipien können die beiden wesentlichen Komponenten (Sprache, Handlungsanleitung) einer Modellierungstechnik beschrieben werden. Während die abstrakte Syntax durch ein sprachbasierten Metamodell repräsentiert wird, ist für die Handlungsanleitung ein prozessbasiertes Metamodell zu erstellen. Abbildung 9 veranschaulicht diesen Zusammenhang. Abbildung 9: Metamodelle

B B B

Metamodell (Sprache)

Modeliierungstechnik

sprachbasIerte Metalslerung

8-'"

-

Metamodell (Handlungsanleitung) prozess basierte Metalslerung

Modell

"'<el"dCCChG

-,

j Objektsystem

In der vorliegenden Arbeit werden sprach basierte Metamodelle zur Beschreibung der abstrakten Syntax semi-formaler ModelIierungssprachen eingesetzt. Da von Handlungsanleitungen abstrahiert wird, werden prozessbasierte Metamodelle (außer in Anhang B.2) nicht eingesetzt.

201

Vgl. Strahringer (1996), S. 26 ff.; Strahringer (1998).

Terminologie und Grundlagen der Informationssystementwicklung

54

2.6

Ereignis

Ereignisse sind bei der Automatisierung von Führungsentscheidungen von wesentlicher Bedeutung, da diese als Auslöser von Informationssystemen fungieren. Im Gegensatz zu den bisher in Kapitel 2 betrachteten Begriffen wurde dem Ereignisbegriff in der Literatur bisher relativ wenig Aufmerksamkeit geschenkt. Teilweise wird der Begriff vollkommen undefiniert verwendet und teilweise ist die Verwendung auch ungenau und problematisch.'o, Es muss unterschieden werden zwischen der umgangssprachlichen und der informatikorientierten Verwendung des Begriffes. Umgangssprachlich ist ein

Ereignis etwas was passiert im Sinne von "sich ereignen".203 Ein Ereignis kann etwa der Tod oder die Geburt eines Menschen, eine Naturkatastrophe, ein Staatsbesuch, eine Hochzeit, ein Konzert oder ein Fußballspiel sein. An dieser Aufzählung wird bereits deutlich, wie vielfältig der Begriff umgangssprachlich verwendet wird. Ein wesentliches Merkmal in der umgangssprachlichen Verwendung

ist,

dass

Ereignisse

Teilnehmer

haben.

Die

Formulierung

"Ereignisse passieren" legt die Vermutung nahe, dass der Einfluss der Teilnehmer auf das Ereignis gering oder nicht vorhanden ist.'04 Teilweise ist für einen beschränkten Teilnehmerkreis allerdings eine direkte Einflussnahme möglich (z. B. beeinflussen die Repräsentanten eines Staates das Ereignis Staatsbesuch oder ein Paar beeinflusst maßgeblich das Stattfinden seiner Hochzeit), während für die übrigen Teilnehmer keine (direkte) Einflussnahme möglich ist (z. B. die Besucher eines Konzertes oder die Zuschauer eines Fußballspiels). Im umgangssprachlichen Sinne kann ein Ereignis zudem eine zeitliche Ausdehnung haben, d. h. ein Ereignis kann eine Weile dauern. In der Wirtschaftsinformatik wird der Ereignisbegriff in unterschiedlichen Zusammenhängen und Forschungsgebieten verwendet. Am Häufigsten wird er nach Wahrnehmung des Verfassers bei der Beschreibung aktiver Datenbanksysteme'o, und bei der Modellierung betrieblicher Abläufe (Prozessmodellie-

202

203

204 205

Ein Beispiel für eine solch ungenaue Verwendung ist etwa der Ereignisbegriff bei der EPK. Vgl. Schatte (1998), S. 10211. Vgl. casatl, Varzl (2006): "Events are things that happen," oder Mlchelson (2006), S. 2: ·An event is a notable thing that happens inside or outside your business". Lorenz (1980), S. 568 beschreibt ein Ereignis daher auch als eine "unpersönliche Handlung Siehe Abschnitt 4.2.1. H

•

Ereignis

55

rung) verwendet.'06 Darüber hinaus wird der Ereignisbegriff seit einigen Jahren bei der Verarbeitung von Datenströmen (z. B. aus Sensornetzen wie RFID) diskutiert.'o7 Ein Ereignis beschreibt in der Wirtschaftsinformatik den Übergang zwischen zwei aufeinanderfolgenden Systemzuständen.'08 Unter einem Systemzustand wird dabei der Vektor der Merkmalsausprägungen eines Systems bezeichnet.''' Es ist zu unterscheiden zwischen Ereignistypen, die intensional jeweils durch ein Zustandspaar, bestehend aus Vor- und Folgezustand, beschrieben werden und Ereignisinstanzen, die darüber hinaus über konkrete Eintrittszeitpunkte verfügen. Im Folgenden sind immer Ereignistypen gemeint, wenn der Begriff Ereignis verwendet wird. Ein Ereignis im Sinne der (Wirtschafts-) Informatik besitzt keine zeitliche Ausdehnung, sondern ist eine punktförmige, atomare Entität."o Zusammenfassend lässt sich ein Ereignis definieren als: Ein Ereignis ist der Übergang von einem Vor- zu einem Folgezustand durch die Veränderung bestimmter Merkmalsausprägungen.'" Ein Ereignis selbst kann keinen weiteren Zustandsübergang direkt hervorrufen, sondern kann lediglich eine Aktion oder Funktion auslösen, die einen weiteren Zustandsübergang verursacht.''' Informationssysteme, die speziell für die Reaktion auf Ereignisse konzipiert sind, werden als ereignisgetriebene Informationssysteme bezeichnet und sind Gegenstand von Kapitel 4.2. Innerhalb eines Informationssystems treten viele Ereignisse auf und bei Weitem nicht jedes Ereignis löst eine Aktion aus. Informationssysteme müssen ebenso wie Lebewesen Ereignisse selektieren und nur nach relevanten Ereig-

206

2111

Vgl. Keller et al. (1992); Scheer (1998b), S. 49 ff.; Scheer, Thomas (2005), 5. 1069 ff. Siehe Abschnitt 4.2.2.

"" Vgl. Wand, Weber (19931, s. 222: Schütte (19981, 5.103: Chandy (20061, S. 3. "" Vgl. Wand, Weber (19931, S. 222. :110 211 212

Vgl. Schatte (1998), S. 103. Vgl. Rommelspacher (20OBa), S. 314; Ortner, Schneider (2008), S. 3. Schütte (1998), S. 103 spricht dagegen davon, dass ein Ereignis einen Zustandsübergang hervorruft.

S6

Terminologie und Grundlagen der Informationssystementwicklung

nissen entsprechende Aktionen auslösen.'" CHANDY schlägt vor, nur bedeutende (significant) Zustandsübergänge als Ereignis zu betrachten, wobei er ein Ereignis als bedeutend erachtet, wenn es nicht den Erwartungen entspricht, d. h. wenn der Zustandsübergang überrascht.'14 Auch wenn die ökonomischen Chancen und Risiken bei nicht erwarteten Ereignissen besonders hoch sind, scheint es unzweckmäßig, den Ereignisbegriff derart einzuschränken.'15 Im Folgenden wird ein Ereignis dann als relevant erachtet, wenn es für eine Aufgabe oder eine Entscheidung auslösenden oder unterbrechenden Charakter

hat.

216

In der Literatur gibt es eine ganze Reihe von Vorschlägen, nach welchen Kriterien Ereignisse klassifiziert werden können.''' Da diese Vorschläge oftmals domänenspezifisch sind, werden im Folgenden lediglich für die weitere Arbeit relevante Klassifikationen eingeführt. Erstens kann unterschieden werden zwischen temporalen und nicht-temporalen Ereignissen. •

Bei temporalen Ereignissen besteht der Zustandsübergang im Eintreten eines Zeitpunktes. Temporale Ereignisse enthalten somit intensionale An-

213

Vgl. Chandy (2005). S. 5 ff.: So bekommt etwa ein Raubtier, das auf der Lauer liegt eine Fülle von Ereignissen über seine Sinne geliefert, Jedoch werden diese Informationen vom zentralen Nervensystem gefiltert und es bleibt vollkommen ruhig auf der Lauer liegen bis zu dem Moment, wo ein relevantes Ereignis eintritt, etwa das Nähern einer möglichen Beute. Dieses Ereignis und seine Verarbeitung entscheiden in der Natur oftmals über Leben und Tot, denn natürlich reagiert auch das vermeintliche Opfer auf das relevante Ereignis und ergreift die

214

215

216 211

Flucht. Chandy unterscheidet zu diesem Zweck normale und abnormale Ereignisse, je nachdem, ob Ereignisse im planmäßigen Betrieb eines Informationssystems auftreten oder nicht. Normale Ereignisse gehören zum regulären Betrieb von Informationssystemen und können somit von Ihnen (problemlos) verarbeitet werden. Bel der Verarbeitung von abnormalen Ereignissen muss differenziert werden in antizipierte und nicht antizipierte abnormale Ereignisse. Antizipierte abnormale Ereignisse (etwa eine Lieferverzögerung) gehören zwar nicht zum planmäßigen Betrieb, Informationssysteme sind jedoch auf ihr Eintreten vorbereitet und es existieren üblicherweise Muster zur Erkennung und Reaktion. Nicht antizipierte abnormale Ereignisse (bspw. eine Attacke auf Informationssysteme) werden dagegen nicht erwartet und es fehlen Muster zur Identifikation und Verarbeitung. Es wird versucht, solche Ereignisse durch Abweichungen vom erwarteten Verhaltensmuster zu identifizieren. Die Abweichung muss jedoch zur Identifikation und weiteren Verarbeitung üblicherweise an einen Analysten weitergereicht werden. Vgl. Chandy (2006), S. 5 ff. Auch die Verarbeitung von erwarteten Ereignissen Ist schließlich Gegenstand von Informationssystemen. Vgl. Hesse et al. (1994), S. 42. Vgl. Rosemann (1996), S. 67; Jablonski et al. (1997), S. 305 f.; Chandy (2006), S. 5 ff.

Ereignis

57

gaben über den Eintrittszeitpunkt. Während sich absolute temporale Ereignisse auf genau einen feststehenden Zeitpunkt (z. B. den 2009-07-01, 0:00,00 Uhr) beziehen"·, beschreiben periodische temporale Ereignisse

mehrere nach einer bestimmten Regel wiederkehrende Ereignisse (z. B. der letzte Tag des Quartals). Relative temporale Ereignisse beziehen sich auf das Ende eines Zeitintervalls nach Eintritt eines anderen Ereignisses (z. B. ein Monat nach einer Produkteinführung).219 •

Nicht-temporale Ereignisse enthalten (intensional) keine Beschreibung bzgl.

des Eintrittszeitpunktes. Wie bereits gesagt, verfügen Ereignisinstanzen über konkrete Eintrittszeitpunkte. Zweitens können Ereignisse unterschieden werden in elementare und komplexe Ereignisse. Während elementare Ereignisse atomar und somit nicht teilbar sind, bestehen komplexe Ereignisse aus einer Reihe elementarer Ereignisse und anderer komplexer Ereignisse."· Zwischen einem komplexen Ereignis und seinen Teilereignissen besteht eine Aggregationsbeziehung, d. h. das komplexe Ereignis befindet sich auf einer hierarchisch höheren Ebene als seine Teile.'" Die Aggregationsbeziehung zwischen komplexen Ereignissen und den jeweiligen Teilereignissen ist durch die Angabe der verwendeten Operatoren zu verfeinern. Typische Operatoren sind:'" •

Sequenz: Alle Teilereignisse müssen in einer bestimmten Reihenfolge eintreten.

•

Konjunktion: Alle Teilereignisse müssen (unabhängig von ihrer Reihenfolge) eintreten.

218

219

220

221

222

Absolute temporale Ereignisse stellen gleichzeitig Ereignistyp und Ereignisinstanz dar. Vgl. Dittrich, Gatziu (2000), S. 19, Fn. 4. Vgl. Thalhammer et al. (2001), S. 243 und S. 251 ff. Vgl. Herbst, Knolmaver (1995), S. 151. Komplexe Ereignisse besitzen im Gegensatz zu elementaren Ereignissen eine zeitliche Ausdehnung. Vgl. Luckham (2002a), S. 95. Siehe zum Abstraktionsprinzip Aggregation Abschnitt 6.1.1. Temporale und .. kausale" Beziehungen zwischen Ereignissen werden In Abschnitt 4.2.3 betrachtet. Vgl. auch Luckham (2002.). S. 94 f. Vgl. Herbst, Knolmayer (1995), S. 151. Das Auswahlereignis wird hier nicht dargestellt, da es auch durch Disjunktion und Konjunktion darstellbar ist.

58

•

Terminologie und Grundlagen der Informationssystementwicklung

Disjunktion: Ein Teilereignis muss eintreten. Es kann zwischen inklusiver oder exklusiver Disjunktion unterschieden werden.

•

Negatives Ereignis: Ein bestimmtes Teilereignis darf in einem bestimmten Zeitraum nicht eintreten.

•

Periodenereignis: Das Teilereignis muss mit einer bestimmten Häufigkeit in

einem definierten Zeitraum eintreten. •

Intervallereignis: Tritt ein, wenn sich ein Teilereignis innerhalb eines bestimmten Intervalls ereignet, das durch zwei andere Teilereignisse (können auch absolute temporale Ereignisse sein) begrenzt ist.

•

Verzögerungsereignis: Ein komplexes Ereignis, das eintritt wenn nach einem Teilereignis ein bestimmtes Zeitintervall vergangen ist.

Damit ist die Definition und Erläuterung der für diese Arbeit relevanten Begriffe und Grundlagen der Informationssystementwicklung abgeschlossen. Die terminologischen und fachlichen Grundlagen dienen im Folgenden als Fundament zur Erreichung der definierten Forschungsziele.

Teil 11: Forschungsgegenstand

In Teil 11 wird der Forschungsgegenstand dieser Arbeit anhand seiner Bestandteile Handlungssystem und Informationssystem vorgestellt. In Kapitel 3 wird mit den Entscheidungen von Führungskräften das Handlungssystem des Forschungsgegenstandes dargestellt. Zum Erreichen des ersten Forschungsziels wird diskutiert, ob und wie Führungsentscheidungen automatisiert werden können. Dabei werden ausgehend von praktischen und theoretischen Überlegungen Anforderungen formuliert, welche ein Informationssystem erfüllen muss, das zur Automatisierung von Führungsentscheidungen verwendet wird. Gegenstand von Kapitel 4 ist das Informationssystem des Forschungsgegenstandes. Dabei werden existierende Ansätze zur Automatisierung und zur Unterstützung von (Führungs-)Entscheidungen den in Kapitel 3 formulierten Anforderungen gegenübergestellt. Hierbei ermittelte Entwicklungsdefizite dienen als Grundlage zur Konstruktion des AvFe-Frameworks und korrespondierender Modellierungssprachen in Teil 111.

3

(Führungs-)Entscheidungen und deren Automatisierung

Das vorliegende Kapitel zielt zum einen darauf ab, Führungsentscheidungen als Handlungssystem des Forschungsgegenstandes einzuführen. Zu diesem Zweck werden in Abschnitt 3.1 die Struktur von Entscheidungen im Allgemeinen sowie Entscheidungsmodelle dargestellt, ehe in Abschnitt 3.2 die Merkmale von Führungsentscheidungen im Speziellen präsentiert werden. Zum anderen zielt das Kapitel auf die Beantwortung der ersten Forschungsfrage ab. Daher wird in Abschnitt 3.3 diskutiert, ob und wie Führungsentscheidungen automatisiert werden können.

3.1

Entscheidungen und Entscheidungsmodelle

Individuen sowie Gruppen müssen ständig eine große Anzahl an Entscheidungen treffen. Das Lösen von Entscheidungsproblemen stellt eine wesentliche Herausforderung in allen Bereichen unseres Lebens dar. Aufgrund ihrer Bedeutung werden Entscheidungen von vielen wissenschaftlichen Disziplinen untersucht und mit der Entscheidungstheorie hat sich ein interdisziplinäres Forschungsgebiet herausgebildet, welches sich mit Entscheidungsproblemen und Entscheidungsverhalten beschäftigt.''' Während umgangssprachlich insbesondere wichtige Wahlprobleme als Entscheidungen bezeichnet werden, versteht die Entscheidungstheorie alle Wahl-

223

leinfellner (1980) bezeichnet die Entscheidungstheorie als Grundlagenwissenschaft der Sozialwissenschaften. Die Entscheidungstheorie umfasst logische und empirische Analysen des

rationalen bzw. intendierten Entscheidungsverhaltens. Während empirische Analysen darauf abzielen, beschreibende (deskriptive) Aussagen zu gewinnen, zielen logische Analysen auf die Gewinnung vorschreibender (präskriptiver) Aussagen ab. Je nachdem welche Analyse im Mittelpunkt einer Untersuchung steht, wird unterschieden In deskriptive und präskriptive Entscheidungstheorie. Vgl. March. Simen (1958); Cyert. March (1963); Helnen (1971); Mag (1977); Blasehe (1980); Bretzke 11980); Ganslandt 11980); Leinfellner 11980); Adam (1996); Schiemenz. Schönert (2005); Berger, Bernhard-Mehlich (2006). S. 169 ff.; Laux (2007); Bamberg et al. (2008).

J. Rommelspacher, Automatisierung von Führungsentscheidungen, DOI 10.1007/978-3-8348-8251-6_3, © Vieweg + Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

62

(Führungs-)Entscheidungen und deren Automatisierung

akte als Entscheidung. LAux definiert eine Entscheidung i. e. S. folgenderma-

ßen:

224

"Unter "Entscheidung" wird ganz allgemein die (mehr oder weniger bewusste) Auswahl einer von mehreren möglichen Handlungsalternativen

verstanden."225

Wie die obige Definition des Entscheidungsbegriffs bereits andeutet, setzen sich Entscheidungen aus bestimmten Bestandteilen zusammen. In Abschnitt 3.1.1 wird daher die allgemeine Struktur von Entscheidungen rekonstruiert, ehe in Abschnitt 3.1.2 diese Struktur durch Entscheidungsmodelle formalisiert wird.

3.1.1

Die allgemeine Struktur von Entscheidungen

Jede Entscheidung besteht aus Zielen des Entscheiders, Handlungsalternativen und Zuständen. Auslöser von Entscheidungen sind Entscheidungsprobleme. Diese Bestandteile einer Entscheidungssituation sowie deren Beziehung bilden die Struktur einer Entscheidung, welche im Folgenden detailliert wird. Die Entscheidungstheorie kann nur dann Hilfestellung bei der Wahl zwischen Handlungsalternativen bieten, wenn beim Entscheidungsträger gewisse Zielvorstellungen existieren.''' Ziele sind somit wesentlicher Bestandteil von Entscheidungssituationen und werden intensional durch die Merkmale Inhalt,

224

225

226

Entscheidungen i. w. S. beinhalten den gesamten Entscheidungsprozess bestehend aus Anregungsphase (Intelligente), Suchphase (Design), Auswahlphase (Choice) und Kontrollphase (Review). Vgl. Siman (1960), S. 1 ff.; Siman (1977). S. 40 ff. Laux (2007), S. 1. Er weist darauf hin, dass eine Entscheidungssituation nur vorliegt, wenn es mehrere Alternativen gibt und die Alternativen unterschiedliche Zielerreichungsgrade

aufweisen. Bei gleichem Zielerreichungsgrad handelt es sich zwar um eine Wahlsituation, aber um keine Entscheidungssituation. Vgl. auch Blasche (1980); Schiemenz, Schönert (2005), S. 25. Vgl. Adam (1996), S. 99; Schiemenz, Schönert (2005), S. 32; Laux (2007), S. 3. Um Handlungsalternativen In eine eindeutige Ordnung bringen zu können, sind präzise und eindeutig formulierte Ziele notwendig. In der Praxis genügen Ziele diesen Anforderungen oft nicht und es können nur Teilordnungen der Alternativen vorgenommen werden. Diese Problematik tritt insbesondere bei strategischen Zielen auf. Vgl. Adam (1996), S. 99 f.

Entscheidungen und Entscheidungsmodelle

63

Ausmaß, sachlicher Geltungsbereich und zeitlicher Bezug beschrieben.''' Der

Inhalt eines Ziels gibt an, welche Zielgröße als Kriterium zur Bewertung der Alternativen dient. Bei betriebswirtschaftlichen Zielgrößen findet oftmals eine Unterscheidung in monetäre (z. B. Gewinn, Kosten, Umsatz) und nichtmonetäre Zielgrößen (z. B. Marktanteil, Lieferzeit, Mitarbeiterzufriedenheit) statt. Das Merkmal Ausmaß gibt an, bis zu welcher Höhe die Zielgröße (des Zielinhalts) zu verfolgen ist. Neben der Maximierungsregel (z. B. maximaler Gewinn) und der Minimierungsregel (z. B. minimale Kosten), können auch niveaubezogene Ausmaße (z. B. 2 %ige Umsatzsteigerung) sowie Zielwerte (z. B. Absatz von 1 Million Euro) angegeben werden."· Wenn der Inhalt des Ziels begrenzt formuliert ist, so wird dies als Satisfiszierung bezeichnet.'" Der sachliche Geltungsbereich konkretisiert, auf welchen Realitätsausschnitt sich ein Ziel bezieht, bspw. auf ein bestimmtes Produkt oder auf eine bestimmte Region. Der zeitliche Bezug legt fest, in welchem Zeitraum ein Ziel zu realisieren ist."o Ein vollständig beschriebenes Ziel wäre etwa: "Umsatzsteigerung bei Produkt X im Jahr 2009 (im Vergleich zum Vorjahr) um 2 %N. Wenn ein Entscheider gleichzeitig mehrere Ziele verfolgt und diese Ziele miteinander in Beziehung stehen, so wird die Gesamtheit der Ziele und die Beziehung zwischen diesen als Zielsystem bezeichnet. Beziehungen zwischen Zielen können die Merkmale Interdependenz, kausale Verkettung und Präferenzrela-

'12.7

228

229

230

Vgl. Heinen (1971), S. 59 ff.; Bea et al. (2004), S. 316; Schiemenz, Schönert (2005), S. 32 ff.; Bamberg et al. (2008), S. 27 ff. unterscheiden zwischen den Merkmalen ZIelgröße und Präferenzrelationen bzgl. Höhe, Art, Zeit sowie Risiko- und Unsicherheit. Diese Präferenzrelationen sind nach Auffassung des Verfassers jedoch nur von Bedeutung, wenn mehrere konfliktäre Ziele angestrebt werden. Vgl. Bamberg et al. (2008), S. 28. Bei Zielwerten kann unter Umständen auch die Überschreitung des Wertes bedeuten, dass das Ziel nicht erreicht wurde. Simon hat gezeigt, dass Menschen aus kognitiven Gründen nicht in der lage sind, vollständig rationale Entscheidungen zu treffen. Nach dem Konzept der begrenzten Rationalität (bounded rationality) hat dies zur Folge, dass Entscheidungsträger keine optimalen, sondern lediglich satisfiszierende Problemlösungen anstreben. Auch die Entscheidungsmodelle dieser Arbeit zielen auf satlsflszlerende Problemlösungen ab. Vgl. Simon (1955); March, Simon (1958). Grundsätzlich kann der zeitliche Bezug auch durch einen Zeitpunkt beschrieben werden. Heinen (1971), 5. 86 f. begründet die Verwendung zeitraumbezogenener Ziele damit, dass sich unternehmerisches Handeln in einem Zeitablaufvollzieht.

(Führungs-)Entscheidungen und deren Automatisierung

64

tion (Wichtigkeit des Ziels) aufweisen.'" Die Interdependenz betrachtet die Art des Einflusses eines Ziels auf den Zielerreichungsgrad eines anderen Ziels. Sind Ziele komplementär, so steigt bei Erhöhung des Erreichungsgrades des einen Ziels auch der Erreichungsgrad des anderen Ziels. Bei konkurrierenden Zielen führt die Erhöhung des Erreichungsgrades des einen zu einem sinkenden Erreichungsgrad des anderen Ziels et vice versa.

232

Von indifferenten Zielen wird

gesprochen, wenn sich Ziele gegenseitig nicht beeinflussen.'" In Abbildung 10 sind lineare Interdependenzen überblicksartig dargestellt. Abbildung 10: Lineare Interdependenzen 'e) Komplementire Ziel.

(e) Indifferente Ziele

(b) Konkurrierende Ziele

N

N

N

W N

W N

W N

u

u

u

0

0

~

J~

~

~

~

~

~

Ereichungsgrad Ziell

Ereichungsgrad Ziell

Ereichungsgrad Ziel 1

Wenn Ziele durch kausale Verkettung miteinander verbunden sind, stehen sie zueinander in einem Zweck-Mittel-Verhältnis und können je nach Position in dieser Relation als Unterziele, Zwischenziele und Oberziele bezeichnet werden. Die Erreichung von Unterzielen dient der Erreichung von Zwischenzielen, weIche wiederum der Erreichung von Oberzielen dienen. Durch kausale Verket-

231

232 233

Schiemenz, Schönert (2005) unterscheiden weiter den Umfang der Gültigkeit einer Interdependenz. Gemeint ist damit, dass Komplementarität oder Konkurrenz nur einen Teil des

Entscheidungsfeides umfassen können. Dieser Spezialfall nicht-linearer Interdependenz soll hier nicht weiter betrachtet werden. Teilweise wird die Interdependenz auch als horizontale Zielrelatlon und die kausale Verkettung als vertikale ZIelrelation bezeichnet. Vgl. etwa Bretzke 119801, S. 78 ff.; Bea et al. (2004), S. 317 ff. Konkurrierende Ziele werden teilweise auch als konfliktär bezeichnet. Mathematisch spricht man bei Zielinterdependenz von Korrelation. Die Problematik, dass vollständig unkorrelierte Ziele in der Praxis kaum auftreten, wird hier nicht diskutiert.

Entscheidungen und Entscheidungsmodelle

65

tung können Zweck-Mittel-Schemata über beliebig viele Ebenen aufgebaut werden.

234

Die Präjerenzrelation beschreibt die Intensität des Strebens nach einem Ziel. Stehen Ziele in Konkurrenz zueinander, so ist die sogenannte Artenpräferenz von Bedeutung.

235

Sie bezeichnet die Intensität des Strebens nach einem Ziel

im Vergleich zu anderen Zielen und enthält Angaben darüber, welches der konkurrierenden Ziele zu berücksichtigen ist. Oftmals werden Ziele gewichtet, wobei das Ziel mit dem höheren Gewicht als Hauptziel und die Ziele mit niedrigeren Gewichten als Nebenziele bezeichnet werden. Darüber hinaus enthält die Präferenzrelation Angaben über die Risikopräferenz eines Entscheiders. Diese ist dann von Bedeutung, wenn keine vollständigen Informationen bzgl. der Entscheidungsergebnisse vorliegen.'" Die beschriebenen Elemente und Beziehungen eines Ziel systems sind in Abbildung 11 als ER-Modell dargestellt. Abbildung 11: Zielsystem

1.,

234

235

236

Ziel

Vgl. Schiemenz, Schönert (2005), S. 37 f. für denkbare Strukturen solcher Zweck-MittelSchemata. Die kausale Verkettung wird auch als Instrumentalrelation oder Zielhierarchie bezeichnet. Vgl. Bea et al. (2004), S. 318 f. Vgl. Schlemenz, Schönert (2005), S. 37 f. und S. 74 ff.i Bamberg et al. (2008) hält außerdem die Präferenzrelationen Zeitpräferenz und Höhenpräferenzrelation für Merkmale des Zielsystems. Nach Auffassung des Verfassers sind diese jedoch Merkmale des Ziels. Vgl. Bamberg et al. (2008), S. 29 ff.

66

(Führungs-)Entscheidungen und deren Automatisierung

Eine Entscheidungssituation liegt nur dann vor, wenn der Entscheider zwischen mehreren Handlungsalternativen zur Erreichung eines Ziels wählen kann, wobei eine der Alternativen darin bestehen kann, nichts zu tun.

237

Handlungsal-

ternativen als der zweite wesentliche Bestandteil von Entscheidungen ziehen Ergebnisse nach sich und werden derart formuliert, dass sie sich gegenseitig ausschließen.''' Werden die Ergebnisse in Relation zu einem Ziel gebracht, resultieren daraus Erreichungsgrade. Der dritte Bestandteil von Entscheidungssituationen sind Zustände des Realitätsausschnitts.'" Zustände beeinflussen das Ergebnis der Handlungsalternativen, ohne selbst von den Handlungen des Entscheidungsträgers abhängig zu sein. Dabei repräsentiert ein Zustand "eine denkbare Konstellation der in einer bestimmten Situation relevanten Faktoren.""o Zustände können in Abhängigkeit von ihrer Beeinflussbarkeit in exogene und endogene Zustände unterschieden werden. Entscheidungen werden oftmals danach klassifiziert, wie vollständig die Informationen bzgl. des wahren Zustands sind.'" Wenn der Entscheidungsträger vollständige Informationen über den eintretenden Zustand besitzt und somit auch die Ergebnisse aller Handlungsalternativen bekannt sind, so wird dies als Entscheidung unter Sicherheit bezeichnet. Wenn über das Eintreten der Zustände keine vollständigen Informationen vorliegen, sondern nur Wahrscheinlichkeiten für deren Eintreten angegeben werden können, so liegt eine Entscheidung unter Risiko vor. Sind noch nicht einmal Eintrittswahrscheinlichkeiten, sondern nur mögliche Zustände und die davon abhängigen Ergebnisse der Handlungsalternativen bekannt, so wird dies Ent-

scheidung unter Ungewissheit genannt. Auslöser von Entscheidungen sind Entscheidungsprobleme. Unter Verwendung des Problembegriffs aus Abschnitt 1.2.1 stellt das Zielsystem einer Entscheidungssituation das Erwünschte und der Zustand des Realitätsausschnitts das 237 Vgl. Bamberg et al. (2008), S. 16 f. ". Val.laux (2007), S. 4; Sambera et al. (2008), S. 16 f. 239 Zustände werden auch als Umweltzustände, Entscheidungsparameter, Nebenbedingungen, Daten oder Restriktionen bezeichnet. Vgl. Bea et al. (2004), S. 312 ff.; Schiemenz, Schönert (2005),5.29; laux (2007), s. 22 11.; Samberg et al. (2008), s. 1811. 240 Bamberg et al. (2008), S. 18. 241 Vgl. Bea et al. (2004), S. 324 ff.; Schiemenz, Schönert (2005), S. 27 f.; Sturm (2005), S. 56 f.; laux (2007). s. 23 f.

67

Entscheidungen und Entscheidungsmodelle

Erreichte dar. Eine Abweichung zwischen Zustand und Zielsystem signalisiert einen Entscheidungsbedarf. Je nachdem, bei welchem Element einer Entscheidungssituation die Abweichungen entstehen, können dabei verschiedene Problemklassen unterschieden werden:

24

'

1. Entscheidungsprobleme entstehen, wenn sich der Zustand des Realitätsausschnitts derart verändert, dass dieser vom Zielsystem des Entscheidungsträgers abweicht. 2. Wenn das Zielsystem sich ändert und dadurch eine Lücke zwischen Ziel und Zustand des Realitätsausschnitts entsteht, resultieren ebenfalls Entscheidungsprobleme. 3. Falls nach satisfiszierenden Lösungen gesucht wird, kann die Ursache für ein Entscheidungsproblem als Abweichung zwischen Ziel und Zustand des Realitätsausschnitts auch darin liegen, dass neue Informationen zu Handlungsalternativen (vergangener Entscheidungen) vorliegen.'" Dabei können sowohl vollständig neue Handlungsalternativen als auch neue Informationen zu Ergebnissen oder deren Wahrscheinlichkeiten vorliegen. Eine verbreitete Klassifizierung besteht darin, Entscheidungssituationen nach der Vollständigkeit ihrer Beschreibung in strukturiert, sem i-strukturiert und unstrukturiert zu unterteilen. Sind die Informationen zu allen Bestandteilen vollständig, so liegt eine strukturierte Entscheidung vor, die routine mäßig durchgeführt werden kann und somit für eine Automatisierung potenziell zugänglich ist.

24 •

Bei semi-strukturierten Entscheidungen liegen nur für Teile des

Entscheidungsproblems vollständige Informationen vor, sodass nur Teile der Entscheidung routine mäßig ausgeführt werden können. Bei unstrukturierten

Entscheidungen liegen auch für Teile des Entscheidungsproblems keine vollständigen Informationen vor, sodass diese überhaupt nicht routine mäßig gelöst werden können. 242

243 244 245

245

Ähnlich: Schiemenz, Schönert (2005), S. 28 f. Vgl. Bretzke (1980), S. 103 ff. zu Handlungsalternativen als Teil der Problemdefinition. Vgl. Ferstl, Sinz (2006), S. 108. Vgl. Schlemenz, Schönert (2005), S. 28. Die Strukturlerthelt bezieht sich explizit auf Entscheidungssituationen und nicht auf Probleme als Auslöser von Entscheidungen. Strukturierte Probleme sind nämlich keine Probleme, das wesentliche Merkmal eines Problems besteht gerade in seinem Mangel an Struktur. Vgl. Bretzke (1980), S. 34.

68

(Führungs-)Entscheidungen und deren Automatisierung

Nachdem nun die Struktur sowie die Klassifikation von Entscheidungssituationen verdeutlicht wurden, wird im kommenden Abschnitt mit den Entscheidungsmodellen ein Ansatz zur formalen Darstellung dieser Struktur vorgestellt.

3.1.2

Entscheidungsmodelle

Modelle, welche die formale Struktur einer Entscheidung darstellen, werden als Entscheidungsmodelle bezeichnet. BRETZKE charakterisiert Entscheidungsmodelle als "das Ergebnis eines Versuches, die für wesentlich gehaltenen Elemente und Beziehungen einer als "Problem" empfundenen Handlungssituation in einer formalisierten Sprache so zu definieren, dass aus dem resultierenden Strukturkomplex die Problemlösung als logische Implikation abgeleitet werden kann."246 Im Folgenden wird das sogenannte Grundmodell der Entscheidungstheorie präsentiert, das in der vorliegenden Arbeit zur formalen Darstellung von Entscheidungen angewendet wird.

24

'

Der erste wesentliche Bestandteil dieses Modells ist die Ergebnismatrix, in der die Ergebnisse ell, e12, ... e,m der Handlungsalternativen a" a" ... a, in Abhängigkeit von den Zuständen s" s" ... Sm dargestellt werden.

248

Bei einer Entscheidung unter Risiko kann die Ergebnismatrix durch Wahrscheinlichkeiten für das Eintreten der Zustände ergänzt werden. In Tabelle 2 ist eine Ergebnismatrix (ohne Wahrscheinlichkeiten) übersichtsartig dargestellt. Tabelle 2: Ergebnismatrix

" "

.. m 247

m

5,

5,

s.

e"

e"

e,.

e"

e"

e,.

e"

e"

e ••

Bretzke (1980), S. 8 in geänderter Orthographie. Vgl. Schneeweiß (1966)i Laux (2007), S. 34 f. Eine derartige Entscheidungsmatrix kann nur erstellt werden, wenn die Ergebnisse der

Handlungsalternativen in Abhängigkeit potenzieller Zustände bekannt sind. Vgl. Bamberg et al. (2008), S. 24 f.

Entscheidungen und Entscheidungsmodelle

69

Der zweite Bestandteil des Grundmodells der Entscheidungstheorie sind Entscheidungsregeln, welche die Handlungsalternativen der Ergebnismatrix in eine

Rangfolge bringen.''' Entscheidungsregeln stellen ein verkürztes Abbild des Zielsystems des Entscheidungsträgers dar. In Abhängigkeit vom abzubildenden Zielsystem und den Informationen bzgl. Ergebnissen und Eintrittswahrscheinlichkeiten werden verschiedene Entscheidungsregeln eingesetzt: Wenn der Entscheidungsträger bei einer Entscheidung unter Sicherheit lediglich ein Ziel verfolgt, so ergibt sich die Entscheidungsregel aus dem verfolgten Zielausmaß (MinimierungfMaximierungfSatisfiszierung).2So Werden mehrere Ziele verfolgt so ist die Artenpräferenz von Bedeutung. Zur Konstruktion einer Entscheidungsregel können Ziele in einer solchen Situation bspw. gewichtet werden.''' Hat der Entscheidungsträger keine vollständigen Informationen über den eintretenden Zustand, so liegen mehrwertige Erwartungen über das Ergebnis der Handlungsalternativen vor. Bei der Konstruktion einer Entscheidungsregel ist nun die Risikopräferenz des Entscheidungsträgers von Bedeutung. Handelt es sich um eine Entscheidung unter Risiko, so können die bekannten Eintrittswahrscheinlichkeiten in den Entscheidungsregeln berücksichtigt werden. Weit verbreitet für Entscheidungen unter Risiko sind die Bayes-Regel oder das (11, 0)Prinzip.''' Bei einer Entscheidung unter Ungewissheit müssen andere Entscheidungsregeln verwendet werden, da keine Wahrscheinlichkeiten über das Eintreten der Zustände bekannt sind. Verbreitet sind bspw. Maximin-, Maximax, Hurwicz- und LaplaceRegel.'53 Entscheidungsmodelle stellen nach dem Modellverständnis dieser Arbeit ein Artefakt dar, um ein Entscheidungsproblem, das zunächst durch einen Strukturmangel gekennzeichnet ist, mit Struktur zu versehen und mit dessen Hilfe anschließend das Entscheidungsproblem gelöst werden kann.'54 Einmal kon-

Vgl. Heinen (1971), S. 55 ff.; Bretzke (1980), S. 14 f. Vgl. Bamberg et al. (20OS), S. 44 f. 251 Vgl. Bamberg et al. (2008), 5. 47 f. für einen überblick über weitere Entscheidungsregeln bei Mehrfachzielen. '" Vgl. Bea et al. (2004), S. 326 f.; Sturm (2005), S. 57 f.; Bamberg et al. (20OS). 253 Vgl. Sturm (2005), S. 58; Bea et al. (2004), S. 327 ff.; Bamberg et al. (2008). 254 Auch die Bestandteile einer Entscheidung. die in ein Entscheidungsmodell überführt werden, sind gemäß der gewählten erkenntnistheoretischen Position nur subjektiv wahrzunehmen. Vgl. Schneeweiß (1966), S. 127; laux (2007), S. 59. 249 250

(Führungs-)Entscheidungen und deren Automatisierung

70

struierte Entscheidungsmodelle können wiederverwendet werden, um gleichartige Entscheidungen zu treffen. Ausgehend von einem detaillierten Entscheidungsmodell können Entscheidungen (zur automatischen Ausführung) somit .programmiert" werden.'55

3.Z

Entscheidungen von Führungskräften

Da die Anwendung des ökonomischen Prinzips - die Zuordnung knapper Mittel zu erstrebten Zwecken - Entscheidungen notwendig macht, spielen Entscheidungen sowohl in der Betriebswirtschaft als auch in der Betriebswirtschaftslehre eine bedeutsame Rolle. Ziel der entscheidungsorientierten Betriebswirtschaftslehre sind optimale betriebliche Entscheidungen.

2S6

Entscheidungen

stellen jedoch keine eigene betriebliche Teilfunktion oder Aufgabe dar, sondern vielmehr beinhaltet jede Funktion eine Vielzahl von Entscheidungen. Aus diesem Grund sind Entscheidungen als Querschnitts- oder Metafunktion zu betrachten.'57 In Abschnitt 3.2.1 werden Entscheidungen differenziert in Führungs- und Ausführungsentscheidungen und die wesentlichen Merkmale von Führungsentscheidungen aus betriebswirtschaftlicher Perspektive erläutert. Anschließend wird in Abschnitt 3.2.2 die Ausgestaltung der Entscheidungsbestandteile (Ziele, Handlungsalternativen und Zustände) bei Führungsentscheidungen dargestellt.

3.2.1

Führungsentscheidungen - eine betriebswirtschaftliehe Darstellung

Betriebliche Entscheidungen können danach differenziert werden, ob sie sich unmittelbar auf die Leistungserstellung eines Unternehmens beziehen (Ausführungsentscheidungen) oder ob es sich um Entscheidungen handelt, die mit der Leitung und Lenkung des Unternehmens in Zusammenhang stehen."· Letztere werden in Anlehnung an GUTENBERG in dieser Arbeit als Führungsentscheidun-

255 256

257

258

Siehe Abschnitt 3.3.1. Vgl. Heinen (1971): Heinen (1991), S. 1 ff: Adam (1996): Dinkelbach, Kleine (1996): Schiemenz, Schöner' (2005), S. 25 ff.; Bomberg e' 01. (200B). Vgl. Steinmann, Schreyögg (2005), S. 10. Vgl. Bender (1957), S. 29 f.; Ulrich (1968), S. 298; Gutenberg (1983), S. 3; Schiemenz, Schönert (2005), S. 27; Gluchowski et 01. (2008). S. 13 f.

Entscheidungen von Führungskräften

71

gen bezeichnet und von Führungskräften ausgeführt.'" Da diese dichotome Unterscheidung sehr unscharf ist und auch innerhalb der Führungsentscheidungen ein großes qualitatives Gefälle erkennbar ist, werden weitere Abgrenzungen vorgenommen. GUTENBERG führt zu den Führungsentscheidungen weiter aus: "Nicht alle diese Entscheidungsakte sind echte Führungsentscheidungen,,260 und definiert zur Abgrenzung folgende Merkmale echter Führungsentscheidungen: •

"Das erste Merkmal echter Führungsentscheidungen [ ... j bildet das Maß an Bedeutung, das eine Entscheidung für den Bestand eines Unternehmens besitzt. u261

•

"Diejenigen Entscheidungen sind echte Führungsentscheidungen, die nur

aus dem Ganzen des Unternehmens heraus getroffen werden können. •

u262

,,[... Djie echten Führungsentscheidungen [ ... j kann die Unternehmensleitung nicht an andere Personen delegieren."'"

Ausgehend von diesen Merkmalen definiert GUTENBERG einen Katalog echter Führungsentscheidungen.'64 Die Anforderungen bzgl. Bedeutung und Betroffenheit des Gesamtunternehmens werden dabei sehr hoch angesetzt.''' Echte Führungsentscheidungen sind diesem Verständnis nach:'66

Vgl. Gutenberg (1983), 5. 133 ff. Führungskräfte bilden aus funktionaler Perspektive das Management eines Unternehmens. Die funktionale Perspektive des Managementbegriffs, der in dieser Arbeit gefolgt wird, orientiert sich zunächst nicht an Positionen oder Personen, sondern an dem Komplex an Aufgaben und Funktionen, die zur Steuerung der Leistungsprozesse zu erfüllen sind. Mitglieder des Managements sind aus funktionaler Perspektive Mitarbeiter, die Managementfunktionen (und darin enthaltene Führungsentscheidungen) wahrnehmen. Aus institutioneller Perspektive sind Mitarbeiter Mitglieder des Managements, wenn sie Weisungsbefugnis über andere Mitarbeiter haben. Diese im angelsächsischen Sprachraum gängige Begriffsauffassung geht weit über die oberen Führungsebenen hinaus. Vgl. 5taehle (1999), 5. 71; Steinmann, Schreyögg (2005), 5. 6 f. '" Gutenberg (1983), S. 134. 261 Gutenberg (1983), 5.134. ,., Gutenberg (1983), S. 134. m Gutenberg (1983), S. 134. 264 Vgl. Gutenberg (1983). 265 Vgl. Gemünden (1983), S. 50. 266 Gutenberg (1983), 5. 140 in geänderter Orthographie. 259

(Führungs-)Entscheidungen und deren Automatisierung

72

1. Festlegung der Unternehmenspolitik auf weite Sicht 2. Koordination der großen betrieblichen Teilbereiche 3. Beseitigung von Störungen außergewöhnlicher Art im laufenden Geschäftsprozess

4. Geschäftliche Maßnahmen von außergewöhnlicher betrieblicher Bedeutung 5. Besetzung der Führungsstellen im Unternehmen Der dargestellte Katalog wird hier dahingehend interpretiert, dass er eine normative Liste mit Entscheidungsarten darstellt, auf die sich Führungskräfte konzentrieren sollten. Selbstverständlich können solche echten Führungsentscheidungen nicht automatisiert werden!·' Da im betrieblichen Alltag deutlich mehr Entscheidungen als Führungsentscheidungen bezeichnet werden und Führungskräfte auch deutlich mehr Aufgaben wahrnehmen müssen, wird der Begriff Führungsentscheidung im Folgenden weiter definiert:''' Eine Führungsentscheidung im Sinne dieser Arbeit ist für das Unternehmen zum einen von Bedeutung, d. h. die einzelne Entscheidung wirkt sich messbar auf den Zustand des Unternehmens aus. Zum anderen haben Führungsentscheidungen eine Reichweite, d. h. sie beziehen sich auf mehr als nur die Ausführung eines einzelnen Leistungsprozesses. Ein weiteres Merkmal von Führungsentscheidungen ist ihre Häufigkeit. Im Gegensatz zu theoretischen Überlegungen, die die Einmaligkeit und den Präzedenzcharakter von Führungsentscheidungen betonen, stellt GEMÜNDEN in einer empirischen Untersuchung fest, dass in 40 % aller Führungsentscheidungen ein häufig auftretendes Problem behandelt wird.

2

"

Insbesondere diese regelmäßig

auftretenden Führungsentscheidungen sind für eine Automatisierung potenziell interessant, da zum einen viele Informationen bzgl. des Entscheidungsproblems zu erwarten sind und zum anderen die Automatisierung häufiger Ent-

268

Dies erklärte bereits Gutenberg (1983), S. 133. Vgl. auch Bucklin et al. (1998), S. 236. Vgl. für eine ähnliche Argumentation Gemünden (1983), S. 50.

26i

Vgl. Gemünden (1983), S. 51.

267

Entscheidungen von Führungskräften

73

scheidungen wirtschaftlich interessant ist. Im Fokus dieser Arbeit stehen daher regelmäßig auftretende Führungsentscheidungen. Führungsentscheidungen können in Abhängigkeit von Bedeutung und Reichweite in strategische, taktische und operative Führungsentscheidungen unterschieden werden.

270

Auch wenn diese Unterscheidung äußerst grob rastert, so

wird in dieser Arbeit davon ausgegangen, dass insbesondere ausgewählte operative und taktische Führungsentscheidungen einer Automatisierung zugänglich sind, da zum einen deren Struktur bekannt ist und diese zum anderen häufiger auftreten. Die übrigen Führungsentscheidungen, also Führungsentscheidungen bei denen die Struktur nicht bekannt ist oder die nicht häufig auftreten sowie strategische Führungsentscheidungen sind somit nach wie vor von Führungskräften durchzuführen. Allerdings können Führungskräfte, so die Idee dieser Arbeit, mehr Zeit zum Treffen dieser nicht-automatisierbaren Entscheidungen verwenden. Nach der Darstellung von Führungsentscheidungen aus betriebswirtschaftlieher Sicht wird im folgenden Abschnitt diskutiert, wie die Bestandteile von Führungsentscheidungen ausgestaltet sind.

3.2.2

Die Bestandteile von Führungsentscheidungen

Führungsentscheidungen bestehen wie alle Entscheidungen (vgl. Abschnitt 3.1.1) aus Zielen, Handlungsalternativen und Zuständen. Da die genannten Bestandteile bei Führungsentscheiden jedoch besonders ausgestaltet sind, werden diese im vorliegenden Abschnitt mit Bezug auf Führungsentscheidungen noch einmal diskutiert. Schließlich können die zu lösenden Entscheidungsprobleme nur präzise beschrieben werden, wenn die Bestandteile von Führungsentscheidungen entsprechend berücksichtigt werden. Das betriebsbezogene Zielsystem von Führungskräften wird wesentlich beeinflusst durch das Zielsystem des Unternehmens. Dabei entstehen bezogen auf

270

Oftmals werden operative und strategische Führungsentscheidungen als kurzfristig bzw. langfristig bezeichnet. Auch wenn zwischen der Fristigkeit und der sachlichen Reichweite sicherlich eine hohe Korrelation besteht. so ist diese Gleichsetzung doch abzulehnen. 50 können kurzfristige Entscheidungen auch durchaus strategischer Art sein et vice versa. 5teinmann. 5chreyögg (2005). S. 163 nennen als Beispiel für eine kurzfristige strategische Entscheidung den Erwerb einer Unternehmensbeteiligung, die kurzfristig angeboten wird.

74

(Führungs-)Entscheidungen und deren Automatisierung

das Zielsystem der betrachteten Personengruppe Formulierungsdefekte, die eine Automatisierung erschweren und die im Folgenden dargestellt werden. Der erste Formulierungsdefekt besteht darin, dass Ziele umso höher aggregiert und allgemeiner sind, je weiter oben die Mitarbeiter, die diese verfolgen, in der 271 Unternehmenshierarchie angesiedelt sind. Allgemeine Ziele können durch wenige Zielgrößen, im Extremfall durch eine Zielgröße beschrieben werden.

272

Der Defekt allgemeiner Ziele besteht darin, dass zwar festzustellen ist, ob sie erfüllt sind oder nicht, sie aber so allgemein formuliert sind, dass kaum konkrete Entscheidungen auf Basis der Ziele getroffen werden können. Der zweite Formulierungsdefekt ist darin zu sehen, dass die Ziele von Führungskräften oftmals unklar formuliert sind.

273

Bei unklaren Zielen fehlt eine

eindeutige Zielgröße zur Bewertung der Zielerreichung. Diese Schwierigkeit führt dazu, dass Handlungsalternativen nicht zu eindeutig zu bewerten und Entscheidungsprobleme nicht objektiv zu identifizieren sind.'74 Unklarheit kann folgende Ursachen haben: Erstens kann ein Ziel unklar sein, weil für das Ziel keine eindeutige und klare Zielgröße existiert.''' Zweitens kann eine unklare Zielformulierung auch durchaus bewusst gewählt werden, um die Bewertung der Zielerreichung zu erschweren.''' Aufgrund der Interpretationsspielräume lässt sich ein vage formuliertes Ziel einfacher erreichen als ein klar formuliertes Ziel. Solche Ziele sind in der Regel als Komparativ formuliert und verfügen über keine Angabe des angestrebten Ausmaßes.'" Drittens kann ein Ziel unklar sein, weil es über eine Vielzahl an Zielgrößen verfügt und somit kein eindeutiges Kriterium existiert. DÖRNER bezeichnet solche Ziele als "verborgene" Mehrfachziele.

271

27 •

Die Unklarheit von Zielen resultiert hier aus dem Versuch, mehrere

Die Neigung zu allgemeinen Zielen ist eine Reaktion auf wachsende Komplexität. In Anlehnung an March, Siman (1958), S. 150 kann dies mit einem lagerhaltungsbeispiel verdeutlicht werden: Während das Top-Management allgemeine Ziele für den Gesamtbetrag des lagerwertes vorgibt, wird die Verteilung auf einzelne Artikel auf darunter liegenden

272

m 274 275 276 277 271

Managementebenen delegiert. Vgl. Dörner (2003), S. 76. Vgl. Dörner (2003), S. 76. Vgl. Gluchowski et al. (2008), S. 19 f. Meist handelt es sich dabei um Ziele, die nicht quantitativ beschrieben werden können. Vgl. Klein, Poesch (2003), S. 67. Z. B. Steigerung der Zinsspanne, Steigerung des Gewinns. Vgl. Dörner (2003), S. 76 f. und S. 80 ff.

Entscheidungen von Führungskräften

7S

eigentlich elementare Ziele zu einem nKomplexziel" 279 zusammenzufassen. So lässt sich bspw. das Komplexziel "Arbeitgeberattraktivität" nicht an einer Zielgröße festmachen, sodass weder der Inhalt noch das Ausmaß des Ziels beschrieben werden können. Wichtige Zielgrößen des genannten Ziels könnten etwa die Höhe des Gehaltes, Arbeitszeit, Arbeitssicherheit und Mitspracherechte sein. Die in einem Komplexziel enthaltenen Ziele stehen meist zueinander in Beziehung, wobei sie oftmals konkurrierend sind. Es lässt sich feststellen, dass Allgemeinheit und Unklarheit von Zielen in der Leitungshierarchie eines Unternehmens von unten nach oben zunimmt. Dies resultiert aus der Tatsache, dass die Mitarbeiter einer Managementebene die auf der darunter liegenden Ebene arbeitsteilig bearbeiteten Aufgaben integrieren müssen. Mögliche Widersprüche und Interdependenzen fallen erst bei der Integration auf und führen zu den beschriebenen Formulierungsdefekten. Bei Führungsentscheidungen ist ebenso wie bei anderen Entscheidungen eine

Handlungsalternative auszuwählen, welche wiederum ein Ergebnis nach sich zieht. Eine Besonderheit von Führungsentscheidungen besteht darin, dass Handlungsalternativen oftmals einen Rahmen vorgeben, in dem Ausführungsentscheidungen getroffen werden können. Um die Zustände von Führungsentscheidungen beschreiben zu können, ist der Realitätsausschnitt zu beschreiben, in dem Führungskräfte agieren und auf den sich die Zustände beziehen. Dieser Realitätsausschnitt wird im Folgenden in Anlehnung an das kognitionspsychologische Forschungsgebiet des "komplexen Problemlösens" mit den Merkmalen Komplexität, Dynamik und Intransparenz beschrieben werden."·

279

280

Vgl. Dörner (2003), S. 58. Vgl. zur Zielkomplexität und möglichen Folgen auch Adam, Johannwille (1998). Das Forschungsgebiet beschäftigt sich mit den Denken und Handeln von Menschen in komplexen, dynamischen und intransparenten Situationen. Wesentlich für die Entwicklung des Forschungsgebietes waren umfangreiche computerbasierte Szenarien (z. B. Lohausen, Tanaland, Tallorshop), In denen das Verhalten von Versuchspersonen In komplexen, dynamischen und intransparenten Situationen bebachtet wurde. Vgl. Dörner (1980); Reither (1981); Dörner, Schaub (1995); Dörner et al. (1999); Funke (1999); Dörner (2003); Funke (Z0061; Schaub (Z006).

(Führungs-)Entscheidungen und deren Automatisierung

76

Komplexität. Liegt vor, wenn ein Realitätsausschnitt durch viele voneinander abhängige Variablen beschrieben wird.'·' Komplexe Situationen sind also einerseits durch eine Menge an Variablen und andererseits durch Vernetztheit dieser Variablen untereinander gekennzeichnet, wobei die Komplexität umso größer ist, je mehr Variablen vorhanden sind und je mehr diese vernetzt sind.

28

'

Sind die Variablen vernetzt, so ist die isolierte Beeinflussung einer Vari-

ablen nicht möglich, sondern es treten sogenannte Fern- und Nebenwirkungen

auf. 283 Dynamik. Der Realitätsausschnitt von Führungskräften kann als dynamisches System verstanden werden, welches sich im Gegensatz zu statischen Systemen im Zeitablauf ohne Eingriff von außen verändert.

284

Dabei ist zwischen stabilen

und instabilen Systemen zu unterscheiden. Während bei stabilen Systemen die Beziehungen zwischen den Elementen bzgl. Zahl, Art und Wechselwirkung gleich bleiben, ändern sich bei instabilen Systemen die Wirkbeziehungen zwischen den Elementen und somit die Struktur des Systems. Dynamik in instabilen Systemen wird im Folgenden als strukturelle Dynamik bezeichnet. Dynamik im Allgemeinen kann Zeitdruck erzeugen und erfordert Prognosen über die Entwicklungstendenz des Systems.'·'

Intransparenz. Die meisten Situationen sind nicht vollständig zu durchschauen. Wenn es Variablen gibt, deren Werte nicht bestimmbar oder sichtbar sind, muss stattdessen auf Indikatoren zurückgegriffen werden.'·' Ebenso dürfte der Entscheider die Beziehungen der Variablen untereinander nicht vollständig überblicken. Solche strukturellen Informationsdefizite können zu falschen oder 287 unvollständigen Entscheidungsmodellen führen. Wenn der Realitätsausschnitt, in dem Führungskräfte agieren, komplex, dynamisch und intransparent ist und die Ziele allgemein und unklar sind, so hat dies Auswirkungen auf die Entscheidungsprobleme, mit denen diese Personen-

286

Vgl. Rosemann (1996), S. 16; Dörner (2003), S. 60i Gluchowski et si. (2008), S. 19. Vgl. Dörner (2003), S. 60i Dörner, Schaub (1995), S. 34 ff. Vgl. Schaub (2006), S. 447 ff. Vgl. Dörner, Schaub (1995), S. 37. Vgl. Dörner (2003), S. 62; Schaub (2006), 447 ff. Vgl. Dörner (2003), S. 63 f.

281

Vgl. Dörner (2003), S. 65.

281 282

283 284

2BS

Entscheidungen von Führungskräften

gruppe schwerpunktmäßig konfrontiert wird.

77 288

Hat eine Führungskraft allge-

meine Ziele, so ist auch der Zustand des Realitätsausschnitts, der mit dem Ziel verglichen wird, hoch aggregiert und letztlich resultieren allgemeine Entscheidungsprobleme. Da allgemeine Ziele durch wenige Zielgrößen beschrieben

werden, kann in einem Abgleich dieser Zielgrößen mit dem Zustand des Realitätsausschnitts entschieden werden, ob ein Entscheidungsproblem vorliegt oder nicht. Allerdings sind die Ziele meist so allgemein formuliert, dass keine konkreten Entscheidungen zur Lösung des allgemeinen Entscheidungsproblems getroffen werden können. Ein erfolgsversprechendes Konzept zum Spezifizieren von allgemeinen Zielen ist das Formulieren von Zwischenzielen, auch bezeichnet als schrittweises Spezifizieren. '89 Die Schwierigkeit unklarer Ziele wurde bereits oben angesprochen: Wenn unklare Ziele oder vielmehr ihre nichteindeutigen Zielgrößen mit dem Zustand des Realitätsausschnitts verglichen werden, so fehlt das Kriterium zur eindeutigen Identifikation eines Problems. Um Probleme eindeutig identifizieren zu können, müssen unklare Ziele konkretisiert werden. Wie diese Konkretisierung aussieht, ist von der Ursache der Unklarheit abhängig: Ist die Zielformulierung bewusst vage gewählt, so ist die Konkretisierung eine Frage des Willens. Existiert dagegen keine eindeutige Zielgröße, so müssen Indikatoren gesucht werden, die das Ziel operationalisieren können. Liegt die Unklarheit darin begrün-

288

289

Ein Beispiel findet sich in Putz-Osterloh (1987). Dort wird untersucht, ob Professoren der Wirtschaftswissenschaften, als ökonomische Experten, besser als eine studentische Vergleichsgruppe mit komplexen, dynamischen und intransparenten Systemen umgehen können. Tatsächlich wird festgestellt, dass Experten aber bessere heuristische Strategien zur Problemlösung vertagen und bel ökonomischen Fragestellungen auf aberlegene bereichsspezifische Algorithmen zurückgreifen können. Es ist bei allgemeinen Zielen nicht unbedingt sinnvoll, gleich zu Beginn sehr spezifische Ziele vorzugeben. Nach einem Beispiel von Dörner (2003), S. 79 f. ist etwa beim Schachspiel das Spezifizieren des allgemeinen Ziels" Mattsetzung des Königs" nicht sinnvoll. Spezifische Ziele wie .. Sein König muss auf h1 stehen, meine Dame auf d2, gedeckt durch einen läufer auf g3. Außerdem ... Dann ist er schachmatt" dürften kaum dazu führen, dass das allgemeine Ziel erreicht wird. In einem solchen Handlungsfeld empfiehlt Oesterreich (1982) nun solche Zwischenziele anzustreben, die einerseits eine hohe Eintrittswahrscheinlichkeit versprechen (Effizienz) und andererseits die Möglichkeit bieten, den Entscheidungsweg In möglichst viele unterscheidllche Richtungen fortsetzen (Divergenz) zu können. Diese beiden Aspekte der anzustrebenen Aspekte zusammengefasst, sollte die maximale Effizienz-Divergenz verfolgt werden. Resch, Oesterreich (1987) weisen empirisch nach, dass auf dem Weg zu einem allgemeinen Ziel effizient-divergente Situationen bevorzugt angestrebt werden.

78

(Führungs-)Entscheidungen und deren Automatisierung

det, dass es sich um ein verborgenes Mehrfachziel handelt, so ist eine Dekomposition in die enthaltenen Teilziele unabdingbar. Die Formulierungsdefekte von Zielen, ihre jeweiligen Ursachen und entsprechende Maßnahmen gegen die Defekte sind übersichtsartig in Tabelle 3 dargestellt. Tabelle 3: Formulierungsdefekte von Zielen

~UII.rungsdef;;ekt == ..Ur>ache

JL

Maßnahme

J

A1llemelne Ziele

Ziele zu hoch aggregiert

schrittweise spezifizieren

Unklare Ziele

Keine eindeutige ZielgröBe

Geeignete Indikatoren verwen-

den Ziel bewusst unklar formuliert

Konkretisieren

Verborgenes" Mehrfachziel

Dekomposition

D

Vorausgesetzt die Ziele sind hinreichend spezifisch und klar, so besteht die Herausforderung in einem komplexen, dynamischen und intransparenten Realitätsausschnitt in der Identifikation des Entscheidungsproblems durch Abgleich zwischen Zielen und Zustand des Realitätsausschnitts. Alle genannten Merkmale des Realitätsausschnitts von Führungskräften sorgen bei der Identifikation von Entscheidungsproblemen für Schwierigkeiten. •

Komplexität führt dazu, dass der betroffene Realitätsausschnitt schwierig zu

erfassen ist. Aber nur wenn die Menge der Variablen und ihre Vernetztheit beachtet werden, kann beurteilt werden, ob es sich um ein Entscheidungsproblem handelt oder nicht. •

Dynamik führt dazu, dass sich Entscheidungsprobleme im Zeitablauf verän-

dern. In dynamischen Systemen können sich Entscheidungsprobleme verschärfen, sie können sich aber auch von selbst erledigen. In dynamischen Systemen ist somit ein wiederkehrender Abgleich zwischen Ziel und Zustand erforderlich. •

Bei Vorliegen von Intransparenz steht der Entscheider vor dem Problem, dass die Struktur und/oder die Variablen des Systems nicht vollständig bekannt oder ermittelbar sind. Bei unbekannter Struktur des Realitätsaus-

79

Entscheidungen von Führungskräften

schnitts müssen Annahmen über die Struktur des Realitätsausschnitts gemacht werden, bei nicht beobachtbaren Variablen müssen Indikatoren verwendet werden. Ausgehend von den dargestellten Merkmalen des Realitätsausschnitts, in dem Führungskräfte agieren, kann nun ein weiteres Argument für die Automatisierung von Führungsentscheidungen eingeführt werden. Menschen haben große Schwierigkeiten mit der Verarbeitung eines komplexen, dynamischen und intransparenten Realitätsausschnitts. Zwar verfügt die menschliche Kognition über einen "Werkzeugkasten" zur Verarbeitung komplexer Datenmengen, die

enthaltenen Werkzeuge sind jedoch sehr fehlerträchtig.

29o

Wenn Menschen

etwa versuchen, die Komplexität durch Filterung zu reduzieren, so besteht die Gefahr, dass der Filter so gewählt wird, dass wichtige Variablen ausgeblendet werden und dadurch Verzerrungen entstehen. Auch die Generalisierung ist ein typisches Instrument zur Reduzierung von Komplexität, bei dem jedoch immer die Gefahr der .Übergeneralisierung· besteht.

29

'

Des Weiteren werden Men-

schen bei der Informationsverarbeitung stark von Kontext und Präsentation (Framing) beeinflusst.''' In den beschriebenen Situationen ist es nun durchaus möglich, dass Automaten gegenüber menschlichen Entscheidern überlegen sind. Gelingt es nämlich, die Schwierigkeiten zumindest bei der Konstruktion von Informationssystemen zur Automatisierung von Führungsentscheidungen zu kontrollieren, so sind die Entscheidungen von Informationssystemen in den beschriebenen Fällen letztlich .besser" als die Entscheidungen von Führungskräften. Nachdem in den vergangenen Abschnitten die Merkmale von Führungsentscheidungen und ihrer Bestandteile dargestellt wurden, ist nun der Gegenstand der Automatisierung hinreichend präzisiert, sodass im folgenden Ab290

291

292

Vgl. Gigerenzer, Goldstein (1996), S. 650 ff. Vgl. Dörner (2003), S. 137 ff. Dörner spricht von "übergeneralisierten" Konzepten, wenn die Abstraktion zu weitgehend ist. Eine solche ",Übergeneralisierung" liegt etwa vor, wenn zwingend notwendige Variablen nicht mehr betrachtet werden, weil von diesen abstrahiert wurde. Tversky, Kahneman (1986). Die Liste kognitiver Probleme bei der Verarbeitung großer Datenmengen lässt sich fortführen. So haben nach Dörner (2003) Menschen bspw. Schwierigkeiten, Entwicklungen im Zeitablauf vorherzusagen. Fehleranfällige Werkzeuge sind hier die Momentanextrapolation und die reduktive Hypothesenbildung. Zudem haben Menschen Schwierigkeiten, exponentielle Entwicklungen nachzuvollziehen.

80

(Führungs-)Entscheidungen und deren Automatisierung

schnitt diskutiert werden kann, ob und wie Führungsentscheidungen automatisiert werden können.

3.3

Ansätze zur Automatisierung von Führungsentscheidungen

Der vorliegende Abschnitt zielt auf das erste Forschungsziel dieser Arbeit ab und diskutiert, ob und wie Führungsentscheidungen automatisiert werden können. Zu diesem Zweck wird in Abschnitt 3.3.1 mithilfe der Programmierung von

Entscheidungen gezeigt,

dass

Entscheidungen grundsätzlich

auto-

matisierbar sind. Anschließend werden in Abschnitt 3.3.2 Anforderungen an ein Informationssystem zur Automatisierung von Führungsentscheidungen formuliert. Vorab ist zu betonen, dass die Vollautomation aller Führungsentscheidungen keinesfalls das Ziel dieser Arbeit ist.'" Es gibt unbestritten Entscheidungen von Führungskräften - bspw. die echten Führungsentscheidungen im Sinne GUTEN· BERGS - die nicht automatisiert werden können. Dies liegt zum einen daran, dass unternehmerische Entscheidungen oftmals mit Kreativität und Instinkt zusammenhängen. Zum anderen sind Entscheidungen bei unbekannter bzw. vollständig neuartiger Struktur von einer Automatisierung ausgeschlossen.'"

3.3.1

Die .Programmierung· von Entscheidungen

Die Automatisierbarkeit von Aufgaben bzw. Entscheidungen als deren Untermenge kann nach FERSTL und SINZ mithilfe formaler und sachlicher Kriterien geprüft werden.'" Anhand der formalen Kriterien kann geprüft werden, ob eine Entscheidung mithilfe eines Lösungsverfahrens automatisiert werden

294

Mertens schlägt die sinnhatte Vollautomation als konkrete Utopie und Superparadigma der Wirtschaftsinformatik vor. Sinn und ZWeck eines solchen Superparadigmas sollen hier nicht weiter diskutiert werden. Vgl. Mertens (1995); Mertens (2006). Zu einer Auseinandersetzung mit den Thesen Mertens' vgl. Eversmann (2003). Vgl. Abschnitt 3.2.

295

Vgl. Ferstl, Sinz (2006), S. 105 ff.

293

Ansätze zur Automatisierung von Führungsentscheidungen

81

kann.'96 Das erste formale Kriterium fordert eine formale Input-OutputBeziehung, wobei das auslösende Problem den Input und das resultierende Ergebnis den Output darstellt. Das zweite formale Kriterium verlangt, dass die Entscheidungssituation mithilfe entsprechender Modelle adäquat modelliert werden kann.'97 Dies bedeutet, dass zu allen Bestandteilen einer Entscheidung möglichst vollständige Informationen vorliegen müssen, wie dies bei strukturierten Entscheidungen der Fall ist.''' Im Folgenden werden Entscheidungsprogramme als Lösungsverfahren vorgestellt und gezeigt, inwieweit diese formal zur Automatisierung von Führungsentscheidungen geeignet sind. Wenn die formalen Kriterien bei einer Entscheidung erfüllt sind, so ist darüber hinaus mithilfe der sachlichen Kriterien eine Kosten-Nutzen-Analyse durchzuführen.'-Bei wiederkehrenden Entscheidungssituationen werden oftmals stark vereinfachte Entscheidungsmodelle in Form genereller Regeln eingesetzt, welche als Entscheidungsprogramme bezeichnet werden."'o Entscheidungsprogramme stellen ein Input-Output-System dar, welches darauf abzielt, gleichartige Entscheidungen in einer dynamischen Umwelt zu treffen. Entscheidungsprogramme können Anweisungen von Vorgesetzten (fallweise Regeln) ersetzen und sind daher - neben der Einrichtung einer Leitungshierarchie - ein wichtiges Instrument zur Koordination in arbeitsteiligen Unternehmen.'Ol Entscheidungsprogramme als Input-Output-Systeme können nach dem Ansatz der Programmdefinition unterschieden werden in Konditional- und Zweckprogram-

296

2m

Es ist zu erwarten, dass zu einer Entscheidung umso mehr Informationen vorliegen, je öfter sie bereits ausgeführt wurde, d. h. mit einer größer werdenden WIederholbarkelt einer Entscheidung nimmt auch deren Programmierbarkeit zu. Es handelt sich bei der Programmierbarkeit allerdings um ein Kontinuum, d. h. in Abhängigkeit von der zur Verfügung stehenden Information ist jeder Grad der Program-mierbarkeit denkbar. Vgl. Hayes-Roth (1985), S. 921. Ob eine Entscheidung tatsächlich automatisch ausgeführt wird, hängt im Wesentlichen mit wirtschaftlichen Überlegungen zusammen. Vgl. Ferstl, Sinz (2006), S. 107 f.

'" Val. March, Simon (1958), S. 142; Simon (1960); Luhmann (1964), S. 4. 299 Vgl. Ferstl, Sinz (2006), S. 109 ff. 300

301

Entscheidungsprogramme werden in der Literatur teilweise auch als Handlungsprogramme oder Programme bezeichnet. Der Begriff des Entscheidungsprogramms (performance programs) entlehnten March, Simon (1958), S. 142 ff.; Simon (1960), S. 5 ff. dem Bereich der elektronischen Daten-verarbeitung. Vgl. zudem Drepper (2003), S. 147 ff. Vgl. Luhmann (1964), S. 22; Habermas (1971), S. 22; Stein mann, Schreyögg (2005), S. 462 ff.

82

(Führungs-)Entscheidungen und deren Automatisierung

me.'02 Während die Definition von Konditionalprogrammen an Problemen, d. h. dem Input einer Entscheidung ansetzt, wird bei Zweckprogrammen der angestrebte Output durch die Definition eines Ziels festgelegt.'"' Konditionalprogramme setzen den Input invariant, indem ein ganz bestimmter

Zustand des Realitätsausschnitts und die entsprechende Reaktion auf diesen definiert werden.'04 Konditionalprogramme enthalten also nicht die üblichen Bestandteile einer Entscheidung, sondern bestehen lediglich aus einer Bedingung (IF) und einer Aktion (00).'°5 Wenn der im Bedingungsteil definierte Zustand eintritt, wird die Aktion ausgeführt. Ein einfaches Konditionalprogramm ist in Abbildung 12 dargestellt.,"6 Abbildung 12: Konditionalprogramm

IF

Kreditsumme > 5000

00

Kreditfähigkeit prüfen

Konditionalprogramme besitzen eine starke Kopplung zwischen der auslösenden Bedingung und der resultierenden Aktion, sodass Konditionalprogramme

302

303 304

30S

306

Diese Unterscheidung wird von Luhmann eingeführt, um die Theorie der Entscheidungsprogrammierung mit der Systemtheorie (Input-Output-Modell) zu verbinden. Der Input wird von luhmann als Information und der Output als Kommunikation bezeichnet. Vgl. luhmann (1966), Fn. 28; Luhmann (1973), S. 257 ff. Erste überlegungen, die in diese Richtung gehen, finden sich allerdings auch schon bei March, Simon (1958), S. 146 ff. Eine andere Klassifikation zur Entscheidungsleistung von Systemen schlägt Ackoff (1971), S. 665 ff vor. In älteren Publikationen Luhmanns werden Konditionalprogramme als Routineprogramme bezeichnet. Hier soll allerdings der Begriff Konditionalprogramm verwendet werden, da damit bereits die Struktur des Entscheidungsprogramms angedeutet wird. Konditionalprogramme werden In der neueren Uteratur auch oftmals als Geschäftsregeln (Business Rules) bezeichnet. Vgl. HayesRoth (1985); Herbst, Knolmayer (1995), S. 149 ff.; Hay, Healy (2000); Beierle, Kern-Isberner (2006), S. 71 ff.; Grob, Coners (2008), S. 282 ff. Vgl. Drepper (2003), S. 89 ff. und S. 148 f. Bei dem auslösenden Zustand handelt es sich lediglich um einen Indikator für ein Entscheidungsproblem, da kein Abgleich zwischen Ziel und Zustand durchgeführt wird. Diese grundsätzliche Struktur von Konditionalprogrammen wird bereits von March, Simon (1958), S. 146 dargestellt. Vgl. auch Rommelspacher (2008a), S. 314 f. Aufgrund fehlender Ziele enthalten Konditionalprogramme keinen zeitlichen Bezug. Konditionalprogramme erfüllen nicht bis zu einem bestimmten Zeitpunkt ein Ziel, sondern reagieren nur unter einer definierten Bedingung. In vielen Situationen sind Ziele auch nicht notwendig und auch nicht hilfreich. Luhmann (1964), S. 10 fragt etwa: H.Und wohin käme man, wenn ein Soldat, dem eine Wenn/Dann-Weisung erteilt ist, über Zwecke nachdächte."

Ansätze zur Automatisierung von Führungsentscheidungen

83

Input-Output-Beziehungen in stabilen Systemen formal gut beschreiben können.'" Konditionalprogramme können somit als Handlungsanweisungen automatisch abgearbeitet werden und erfüllen das erste formale Kriterium von FERSTL und SINZ.'" Für eine automatische Ausführung durch Informationssysteme sind Konditionalprogramme allerdings noch um Ereignisse zu erweitern, die festlegen, wann die Bedingung des Konditionalprogramms überprüft wird (siehe Abschnitt 4.2). Das zweite formale Kriterium fordert die adäquate Modellierung der Entscheidungssituation. Da Konditionalprogramme nicht alle Entscheidungsbestandteile enthalten, muss zunächst diskutiert werden, ob es sich dabei überhaupt um eine Entscheidung handelt. Trotz starker Vereinfachung und des Fehlens von Zielen findet in Konditionalprogrammen eine Wahl zwischen den Handlungsalternativen "Ausführen der Aktion" und "Nicht-Ausführen der Aktion" statt. Da sich der Entscheidungsbegriff dieser Arbeit an dieser Wahl orientierte, treffen Konditionalprogramme selbstständig Entscheidungen.'" Des Weiteren ist darüber zu diskutieren, ob Konditionalprogramme Führungsentscheidungen und deren Bestandteile adäquat modellieren können. Insbesondere das Fehlen von Zielen in Konditionalprogrammen ist als problematisch einzuschätzen, da Ziele für Führungsentscheidungen von überragender Bedeutung sind und diese sich zudem - wegen der wirtschaftlichen Dynamik und wegen der beschriebenen Formulierungsdefekte - ändern können."· Ausgehend von fehlenden Zielen können zum einen Zieländerungen nur sehr bedingt implementiert werden.'" Zum anderen ist auch die Beseitigung der beschriebenen Formulierungsdefekte bei Zielen von Führungskräften kaum möglich. Darüber hinaus ist auch der Realitätsausschnitt in einem Konditionalprogramm nur sehr stark vereinfacht dargestellt.'" Die Bedingung eines Konditionalprogramms stellt letztlich lediglich einen Indikator für ein Entscheidungs307 In stabilen Systemen ist das Ergebnis der ausgelösten Aktion konstant. Vgl. Abschnitt 5.1.1. .. Val. Luhmann (2000), S. 263. 309 Vgl. March, Simon (1958), S. 141. 310 Ökonomen sind sehr stark auf ZWecke bezogen. Vgl. bspw. Luhmann (2000), S. 262. 311 Unter Umständen massen bei einer ZIeländerung sehr viele Entscheidungsprogramme angepasst werden. Wichtige Voraussetzung einer Anpassung ist, dass dokumentiert ist, welche Entscheidungsprogramme von welchen betrieblichen Zielen abhängen. 312 Luhmann (1964), S. 13.

(Führungs-)Entscheidungen und deren Automatisierung

84

problem dar. Darüber hinaus können Konditionalprogramme mit der Dynamik in instabilen Systemen nicht umgehen, weil die Wirkung der ausgelösten Aktion nicht vorhersehbar ist. Zusammenfassend ist festzustellen, dass Konditionalprogramme zwar Entscheidungen automatisieren können, die Automatisierung von Führungsentscheidungen mit Konditionalprogrammen jedoch als problematisch einzuschätzen ist. Zweckprogromme setzen anders als Konditionalprogramme den Output einer

Entscheidung invariant, indem sie Zwecke (Ziele) enthalten.'13 Zur Erreichung der Ziele ist zwischen Mitteln - in der Terminologie dieser Arbeit Handlungsalternativen - zu wählen, wobei diese im Rahmen von Zweckprogrammen oftmals nicht exakt festgelegt sind.'l4 Die Zeitvorstellung, bis wann oder in weIcher Periode Ziele zu erreichen sind, ist wesentlicher Bestandteil von Zweckprogrammen und unterscheidet sie von Konditionalprogrammen.

315

Ein promi-

nentes Anwendungsbeispiel für die Zweckprogrammierung ist das Konzept "Management by Objectives", bei dem die Führung von Mitarbeitern und die Integration arbeitsteiliger Funktionen im Wesentlichen durch Zweckprogramme im Sinne von Zielvereinbarungen erfolgt.'" Zweckprogramme sind offensichtlich wesentlich besser zur Modellierung von Führungsentscheidungen geeignet, da diese über Ziele verfügen, mit deren Hilfe Handlungsalternativen ausgewählt werden. Zweckprogramme setzen allerdings lediglich den Output invariant, ohne den Input eines Systems zu betrachten, sodass die Input-Output-Beziehung nach FERSTL und SINZ nicht ausreichend berücksichtigt wird.'17 Zu diskutieren ist daher im Weiteren, inwiefern Zweckprogramme die Zustände des Realitätsausschnitts abbilden können und dadurch eine Input-Output-Beziehung realisiert werden kann. Im vergangenen Abschnitt wurde festgestellt, dass (Führungs-)Entscheidungen unter bestimmten Bedingungen automatisierbar sind. Es wurde auch festgestellt, dass die Automatisierung von Führungsentscheidungen durch Konditio-

313

Vgl. Luhmann (1973), S. 257 ff. Luhmann (2000), S. 261. Die Ziele sind dabei bzgl. der

Merkmale Inhalt, AusmaB, sachlicher Geltungsbereich und Zeit konkretisiert. 314 315 316 311

Vgl. Vgl. Vgl. Vgl.

Luhmann (2000), S. 261. Luhmann (1964), S. 8. Drucker (1954), S. 121 ff.; Steinmann, Schreyögg (2005), S. 463. Luhmann (1966). S. 36 und S. 44.

Ansätze zur Automatisierung von Führungsentscheidungen

8S

nalprogramme nicht sinnvoll ist und bei der Automatisierung mithilfe von Zweckprogrammen noch wesentliche Fragen offen sind. Um weiterführende Ansätze zur Automatisierung von Führungsentscheidungen beurteilen zu können, werden im folgenden Abschnitt die Anforderungen an ein System zur Automatisierung von Führungsentscheidungen noch weiter detailliert.

3.3.2

Anforderungen an ein System zur Automatisierung von Führungsentscheidungen

Basierend auf den Überlegungen der vorigen Abschnitte und der Tatsache, dass Entscheidungsprogramme Entscheidungssituationen adäquat abbilden müssen, werden nun Anforderungen formuliert, die ein Informationssystem und die enthaltenen Entscheidungsprogramme erfüllen müssen, um Entscheidungen von Führungskräften zu automatisieren. Dabei ist zu unterscheiden in notwendige (nA) und hinreichende Anforderungen (hA). Die notwendige Anforderung - ohne die eine Automatisierung von Führungsentscheidungen grundsätzlich nicht möglich ist - besteht darin, dass das Informationssystem Komponenten enthalten muss, die Entscheidungsprogramme und deren Input-Output-Beziehungen technisch realisieren und somit ein (re-)aktives Verhalten zur Verfügung stellen. Das Informationssystem muss zur Realisierung von Entscheidungsprogrammen reaktive Komponenten beinhalten. (nA) Die hinreichenden Anforderungen sollten zur Automatisierung von Führungsentscheidungen möglichst vollständig erfüllt sein, allerdings sind Informationssysteme auch unter Umständen eingeschränkt verwendbar, wenn nicht alle hinreichenden Anforderungen erfüllt sind. Die hinreichenden Anforderungen zielen darauf ab, dass Entscheidungsprogramme die Bestandteile von Führungsentscheidungen unter Berücksichtigung des betreffenden Realitätsausschnitts beinhalten. Der erste wesentliche Bestandteil von Führungsentscheidungen sind Ziele. Wie bereits erläutert wurde, kann auf diese bei einer Automatisierung kaum verzichtet werden, da sich Ziele von Führungskräften häufig ändern und die entsprechenden Entscheidungs-

86

(Führungs-)Entscheidungen und deren Automatisierung

programme bei einer solchen Zieländerung anzupassen sind. Als erste hinreichende Anforderung ergibt sich somit: Die Ziele einer Entscheidungssituation müssen Bestandteil der Entscheidungsprogramme sein. (hAl) Entscheidungsprogramme haben in dieser Arbeit zudem die Formulierungsdefekte des Zielsystems von Führungskräften zu berücksichtigen. Zur Spezifizierung allgemeiner Ziele sind Zweck-Mittel-Schemata in Form kausaler Beziehungen zwischen Unterzielen und Oberzielen zu definieren und in Entscheidungsprogramme zu integrieren. Als weitere Anforderung an ergibt sich somit: Entscheidungsprogramme müssen die kausale Verkettung von Zielen abbilden können. (hA2) Entscheidungsprobleme können identifiziert werden, indem Ziele mit dem Zustand des betrachteten Realitätsausschnitts verglichen werden.'" Um diesen Vergleich durchführen zu können, müssen adäquate Informationen bzgl. des Realitätsausschnitts vorhanden sein und in einem Informationssystem zur Verfügung gestellt werden. Um Mengen- oder Wertgrößen mit Zielen vergleichen zu können, müssen entsprechende Bezugsobjekte verwendet werden. Bezugsobjekt ist eine Sammelbezeichnung für Untersuchungsobjekte, denen entsprechende Wert- oder Mengengrößen wie Umsatz, Deckungsbeitrag usw. zugeordnet werden.'" Wenn bspw. das Ziel eine Umsatzsteigerung in einer Vertriebsregion ist, so ist als Bezugsobjekt die Vertriebsregion zu verwenden. Zur Darstellung des komplexen, dynamischen und intransparenten Realitätsausschnitts, in dem Führungskräfte agieren, ist nun aber eine Vielzahl an Bezugsobjekten notwendig, um so .nur ausschnittsweise und aus mehreren problemadäquaten Sichten nebeneinander oder im Zeitablauf wirklichkeitsnah in

318

Es werden in dieser Arbeit zwei grundsätzlich verschiedene Möglichkeiten der (automatischen) Identifikation von Problemen vorgestellt. Erstens gibt es die Möglichkeit (wie dies bei Zweckprogrammen üblich Ist), die Ziele mit dem Zustand des RealItätsausschnitts zu

vergleichen. Zweitens kann der Bedingungsteil eines Konditionalprogramms als Indikator für 31g

ein Entscheidungsproblem verstanden werden. Vgl. Riebel (1994), S. 759.

87

Ansätze zur Automatisierung von Führungsentscheidungen

anschaulicher Weise u32• den Realitätsausschnitt abzubilden. RIEBEL vergleicht dies mit der Vielzahl von Grund- und Aufrissen, Querschnitten, Detailzeichnungen und Ansichten, die beim Entwurf eines Hauses angefertigt werden müs-

sen. 321 Werden allgemeine Ziele mit dem korrespondierenden Zustand des Realitätsausschnitts verglichen, so resultieren allgemeine Probleme, die oftmals nicht direkt gelöst werden können. Bei einer Spezifizierung von Zielen müssen auch die Bezugsobjekte entsprechend spezifiziert werden. Analog zu Zweck-MittelSchemata sind daher zur Beschreibung des Realitätsausschnitts Bezugsobjekthierarchien erforderlich. Nach RIEBEL ist eine Bezugsobjekthierarchie "eine von

untergeordneten, spezielleren zu übergeordneten, allgemeineren Untersuchungsobjekten aufsteigende Rangordnung.

um

Das bedeutet, Bezugsobjekt-

hierarchien werden grundsätzlich von unten nach oben aufgebaut. Dabei orientieren sie sich ebenso wie Zweck-Mittel-Schemata oftmals an Leitungshierarchien von Unternehmen oder an Produkthierarchien. Je nach Problem können aber auch andere Merkmale in Bezugsobjekthierarchien eingebaut werden. Für die Aggregation originärer (elementarer) Bezugsobjekte

323

bieten sich

dadurch mannigfaltige Wege an, die beschritten werden können, indem die Geld- oder Mengengröße nach interessierenden Merkmalen (problemadäquat) gruppiert bzw. aggregiert werden. Eine Auswahl denkbarer Wege ist in Abbildung 13 veranschaulicht. Ein möglicher Verdichtungspfad zur Größe Gesamtumsatz ist in der Abbildung fett dargestellt.

'" Riebel (19921, s. 256 f. '" Vgl. Riebel (1992), S. 256; Holten (1999), S. 75. m Riebel (1994), S. 759. m ..Originäres Bezugsobjekt Ist das speziellste Objekt In der Hierarchie betrieblicher Bezugsobjekte, für die man die betrachtete Teilmenge einer Geld- oder Mengengröße gerade noch direkt disponieren, planen, erfassen oder zurechnen kann, ohne willkürliche Anlastungen (Aufteilungen) vornehmen zu müssen". Riebel (1994), S. 767.

88

(Führungs-)Entscheidungen und deren Automatisierung

Abbildung 13: Bezugsobjekthierarchien

Gesamtumsatz

Artikelgruppen

Kundengruppen

Auftragsarten

Auftragsgrößen-

Verkaufsgebiete

\\ ~. ;:........... . ./. "\. . . . . . ..... 1'!.... ...... klassen ............... . .\. . . ......."..r ......'Jr.\ \ J . . J ....'( / . " .... ...r \ ! ;\" ...)::-"'...... ; \ /'. \\, i;.............. \\ . . .f.! . . ...;.= ................ ~................ j \/ i'i.. ~ I

\ ......

);

'\'

:.\

!

......

1\

X

'.

........

"'1'-....._

\

i'

;1

! \ : \ " \

Artikel ________.A,'_.........

..

. .,.

\i ...·.. j ......... Kunden '1

\,

l

j'

' , '

-':<..

\

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

\

... '.........

...../

_

\

\

\

"",4.. 7',·, ....... ", \ \ .i-····'\. / ..... ............... .......... \ l . ..... _ ............ \ 'j

.

.......P,I.••----.,/------7'-........- ........- Verkau sbezirke

!

i

/

----"_,,,-

................ ,,_..--"

i / / ...··...··\

.....

....... "/ '\

..·..h ......'-J.. ..... i "'" /'...........

li/

\

......

,1"-"

" / ! /"

\\,

...

! ,

I,

....·.Pi.

Aufträge'"

\,

'\..

!

\

!

\

:

Auftragsposition Vgl. Riebel (1994), S. 406.

324

In dieser Arbeit werden Bezugsobjekte und Bezugsobjekthierarchien dafür verwendet, Ziele mit dem Zustand des entsprechenden Realitätsausschnitts vergleichen zu können. Wenn davon ausgegangen wird, dass allgemeine Ziele spezifiziert werden, so müssen auch Bezugsobjekte disaggregiert werden, d. h. obwohl Bezugsobjekthierarchien bei der Implementierung von unten nach oben aufgebaut werden, sind diese bei der Automatisierung von Entscheidungen zur zielorientierten Spezifizierung und Analyse allgemeiner Entscheidungsprobleme von oben nach unten zu durchlaufen.

324

Ähnliche Abbildungen finden sich bei Riebel (1992), S. 284; Holten (1999), S. 79.

Ansätze zur Automatisierung von Führungsentscheidungen

89

Das Informationssystem muss zur zielorientierten Spezifizierung und Analyse allgemeiner Entscheidungsprobleme flexible Bezugsobjekthierarchien bereitstellen. (hA3) Als zweiter Formulierungsdefekt von Zielen wurde deren Unklarheit genannt. Sowohl Ziele als auch die Zustände des Realitätsausschnitts müssen dekomponiert und konkretisiert werden, ehe diese zur Automatisierung von Führungsentscheidungen verwendet werden können. Zur konkreten Beschreibung werden Ziele und Zustände multidimensional eingeschränkt. So ist bspw. der sachliche Geltungsbereich des Ziels HDie Anzahl der vertriebenen Konsumentenkredite soll in der Region Marburg im Jahr 2009 um 5 % steigen" hinsichtlich der Dimensionen Produkt und Region eingeschränkt. Darüber hinaus ist Inhalt (Anzahl) und Ausmaß (5 %) auch durch einen zeitlichen Bezug (Jahr 2009) konkretisiert. Um solche mehrdimensional konkretisierten Ziele mit einem Zustand des Realitätsausschnitts vergleichen zu können, muss mithilfe mehrerer Bezugsobjekte ein mehrdimensionales Untersuchungsumfeld sachlich und zeitlich aufgespannt werden.'2S Zur Beschreibung des Untersuchungsumfeldes werden die abstrakten Bezugsobjekte Filiale (Marburg), Produkt (Konsumentenkredit) und Jahr (2009) verwendet. Der Inhalt wird mithilfe der Kennzahl Anzahl dargestellt. Das multidimensionale Untersuchungsumfeld ist in Abbildung 14 als Multidimensionales Entity-Relationship (MER)-Modell dargestellt.'"

'" Vgl. Codd et 01. (19931. S. 12; Holten (19991. S. 82. 326

Siehe zum MER-Modell Abschnitt 6.2.2.

90

(Führungs-)Entscheidungen und deren Automatisierung

Abbildung 14: Mehrdimensionales Untersuchungsumfeld

Jahr

Filiale

Anzahl

Die zur mehrdimensionalen Abgrenzung verwendeten Bezugsobjekte werden in der Regel in Dimensionen eingeordnet, wobei diese oftmals eine hierarchische Ordnung von spezielleren hin zu allgemeineren Bezugsobjekten aufweisen.

327

Im oben genannten Beispiel wäre eine Hierarchie Vertriebsort beste-

hend aus den Bezugsobjekten Filiale, Region und Alle Regionen denkbar. Hierarchisch aufgebaute Dimensionen zur sachlichen mehrdimensionalen Abgrenzung des Untersuchungsfeldes sind etwa Struktur von Kunden, von Absatzmärkten, von Produkten oder auch die Aufbauorganisation des Unternehmens.

328

Darüber hinaus lassen sich zeitliche Konkretisierungen z. B. nach Jahr,

Quartal, Monat, Kalenderwoche vornehmen. Das Informationssystem muss multidimensionale Sichten auf Wert- und Mengengrößen ermöglichen. (hA4) Nach der Identifikation eines Entscheidungsproblems wählen Entscheidungsprogramme Handlungsalternativen aus. Daher müssen neben dem Zielsystem und Zuständen auch notwendige Informationen bzgl. der existierenden Handlungsalternativen in einem Entscheidungsprogramm hinterlegt werden. Handlungsalternativen einer Entscheidungssituation müssen in Entscheidungsprogrammen enthalten sein. (hAS)

321 321

Vgl. Holten (1999), S. 84 f. Vgl. Riebel (1992), S. 279; Holten (1999), S. 82 f.; Gluchowski et al. (2008), S. 141.

Ansätze zur Automatisierung von Führungsentscheidungen

91

In Abschnitt 3.2.2 wurde bzgl. der Dynamik des Realitätsausschnitts differenziert in stabile und instabile Systeme. Während die Dynamik in stabilen Systemen grundsätzlich mittels Konditionalprogrammen beherrsch bar ist, müssen Informationssysteme zur Automatisierung von Führungsentscheidungen auch den Umgang mit struktureller Dynamik ermöglichen. Dies ist erforderlich, da bei ökonomischen Systemen davon auszugehen ist, dass es sich um teilweise instabile Systeme handelt. Das Informationssystem muss die strukturelle Dynamik des relevanten Realitätsausschnitts beherrschen. (hAG) Wenn die bisher formulierten Anforderungen nA und hAl bis hAG von einem Informationssystem erfüllt werden, so ist ein (automatischer) Abgleich zwischen Zielen und Zustand des relevanten Realitätsausschnitts möglich. Probleme können im Rahmen von Konditionalprogrammen außerdem identifiziert werden, indem der Bedingungsteil als Indikator für ein Entscheidungsproblem verstanden wird. Wenn Konditionalprogramme zur Identifikation von Entscheidungsproblemen verwendet werden, ist festzulegen, wann diese ausgeführt werden. Zu diesem Zweck werden in Informationssystemen Ereignisse verwendet. Für die effiziente Anwendung eines Konditionalprogramms müssen Ereignisse Veränderungen im relevanten Realitätsausschnitt repräsentieren.'" Ein derart konstruiertes Konditionalprogramm kann Dynamik in stabilen Sys-

temen absorbieren. Das Informationssystem muss Veränderungen des relevanten Realitätsausschnitts in Form von Ereignissen abbilden. (hA7) Die Komplexität und die Intransparenz des Realitätsausschnitts, in dem Führungskräfte agieren, verkompliziert allerdings die Erfassung von Veränderungen in Form von Ereignissen in einem Informationssystemen und es sind oftmals komplexe Ereignisse erforderlich, um Veränderungen im relevanten Realitätsausschnitt zu signalisieren. Als weitere Anforderung ergibt sich daher: 329

DarQber hinaus werden oftmals temporale Ereignisse als Auslöser von Konditionalprogrammen eingesetzt. Typischerweise sind Konditionalprogramme jedoch nicht zeitlich festgelegt. Daher sollen temporale Ereignisse als Auslöser von Konditionalprogrammen möglichst vermieden werden.

92

(Führungs-)Entscheidungen und deren Automatisierung

Das Informationssystem muss komplexe Ereignisse abbilden und verarbeiten können. (hA8) Die Anforderungen an ein Informationssystem zur Automatisierung von ausgewählten Führungsentscheidungen sind noch einmal in Tabelle 4 zusammengefasst. Tabelle 4: Anforderungen

Kürzel nA

Anforderung Das Informationssystem muss zur Realisierung von Entscheidungsprogrammen reaktive

Komponenten beinhalten. hA1

Die Ziele einer Entscheidungssituation müssen Bestandteil der Entscheidungspro-

gramme sein. hA2

Entscheidungsprogramme müssen die kausale Verkettung von Zielen abbilden können.

hM

Das Informationssystem muss zur zielorientierten Spezifizierung und Analyse allgemei-

ner Probleme flexible Bezugsobjekthierarchien bereitstellen. hA4

Das Informationssystem muss multidimensionale Sichten auf Wert- und Mengengrä-

Ben ermöglichen. hAS

Handlungsalternativen einer Entscheidungssituation müssen in Entscheidungsprogrammen enthalten sein.

hA6

Das Informationssystem muss die strukturelle Dynamik des relevanten Realitätsausschnitts beherrschen.

hA7

Das Informationssystem muss Veränderungen des relevanten Realitätsausschnitts in Form von Ereignissen abbilden.

hAB

Das Informationssystem muss komplexe Ereignisse abbilden und verarbeiten können.

Informationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

4

Im vorliegenden Kapitel wird das Informationssystem des Forschungsgegenstandes vorgestellt. Dabei werden Ansätze für Informationssysteme zur Unterstützung und Automatisierung von (Führungs-l Entscheidungen präsentiert und den in Kapitel 3 formulierten Anforderungen an ein System zur Automatisierung von Führungsentscheidungen gegenübergestellt. Die dadurch ermittelten Entwicklungsdefizite dienen als Grundlage zur Entwicklung des AvFeFrameworks sowie zugehöriger Modellierungssprachen in Kapitel 5 bzw. Kapitel6. Die Ansätze für Informationssysteme zur Automatisierung und Unterstützung von (Führungs-IEntscheidungen können erstens danach unterschieden werden, ob diese auf die Unterstützung von Führungsentscheidungen oder Ausführungsentscheidungen abzielen. Zweitens kann unterschieden werden, ob es sich um aktive oder passive Informationssysteme handelt. Durch Kombination der beiden Dimensionen ergibt sich eine zweidimensionale Matrix, die übersichtsartig in Abbildung 15 dargestellt ist. Abbildung 15: Entscheidungsunterstützung und -automatisierung

Kapitel 4.3

Fuhrungsentscheidungen

Kapitel 4.1 Analytische 15

AusfOhrungsentscheidungen

Passive operative 18

Passive 15

ISzur Automatisierung von Führungsentscheidungen

Kapitel 4.2 Ereignisgetriebene 18

Aklive 18 Vgl. Thalhammer (2001). S. 6.

J. Rommelspacher, Automatisierung von Führungsentscheidungen, DOI 10.1007/978-3-8348-8251-6_4, © Vieweg + Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

94

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Oas Kapitel ist folgendermaßen aufgebaut: In Abschnitt 4.1 werden analytische Informationssysteme vorgestellt, welche darauf abzielen, die Informationsversorgung von Fach- und Führungskräften sicherzustellen und dadurch Führungsentscheidungen zu unterstützen. Gegenstand des darauf folgenden Abschnitts 4.2 sind ereignisgetriebene Informationssysteme, welche sich insbesondere zur Automatisierung von Ausführungsentscheidungen eignen. In Abschnitt 4.3 werden existierende Ansätze zur Automatisierung von Führungsentscheidungen präsentiert. 4.1

Analytische Informationssysteme

Oas Bestreben, durch Informationssysteme Entscheidungen von Fach- und Führungskräften zu unterstützen, lässt sich bis in die 1960er Jahre zurückverfolgen und ist somit fast ebenso alt wie der kommerzielle Einsatz der Informationstechnologie selbst."o Während die ersten Projekte zum Aufbau sogenannter Managementinformationssysteme (MIS) zumeist an überzogenen Erwartungen und fehlenden informationstechnischen Voraussetzungen scheiterten, waren in den 1970er Jahren mit den modellorientierten Oecision Support Systems (055) und den berichtsorientierten Executive Information Systems (EIS) erste erfolgreiche Implementierungen zu beobachten.'" Es handelte sich jedoch meist um Insellösungen, die nur einem sehr eingeschränkten Nutzerkreis zur Verfügung standen.'" SeOTT MORTON prägte in dieser Zeit als Überbegriff für Systeme zur elektronischen Unterstützung von Entscheidungsträgern den noch heute verwendeten Begriff Management Support Systems (MSS).333 Seit Ende der 1980er Jahre entwickeln sich betriebswirtschaftliche Methoden 330

"1 332

333

334

sowie technische Ansätze

335

zur Informationsversorgung und Entschei-

Vgl. Chamoni, Gluchowski (2006), S. 6; Gluchowski, Kemper (2006), S. 12. Analytische Informationssysteme unterstützen außer Führungskräften auch Fachkräfte. Letztere bereiten durch entsprechende Informationsverarbeitung und -verdichtung Entscheidungen von Führungskräften vor. Für diese Tätigkeit nutzen Fachkräfte analytische Informationssysteme. Vgl. Laudon, Laudon (2006), 5. 21; Gluchowski et al. (2008), S. 15; Alpar et al. (2008), S. 22. Vgl. Stahlknecht, Hasenkamp (200S), 5. 382 f.; Chamoni, Gluchowski (2006), S. 6. Vgl. Chamoni, Gluchowski (2006), 7 f.; Gluchowski et al. (2008), S. 62 ff. für eine ausführlichere Erläuterung zu DSS und EIS. Scott Morton zählt zu MSS neben EIS und DSS auch Baslssysteme wie Textverarbeitung, Tabellenkalkulation, Grafikverarbeitung und Terminplanung. Vgl. Chamoni, Gluchowski (2006),

5.9. 334

Z. B. Kennzahlensysteme, Balanced Scorecard.

Analytische Informationssysteme

95

dungsunterstützung von Fach- und Führungskräften äußerst dynamisch und firmieren seit Mitte der 1990er Jahre unter dem Sammelbegriff Business Intelligence."· Statt dieses ubiquitär und oftmals unscharf verwendeten "Modeworts" wird in dieser Arbeit der Terminus analytische Informationssysteme verwendet. Der Klasse der analytischen Informationssysteme werden alle Systeme zugeordnet, bei denen die "Informationsversorgung und funktionale Unterstützung betrieblicher Fach- und Führungskräfte zu Analysezwecken im Vordergrund steht."m Das Ziel analytischer Informationssysteme ist es, den adäquaten Zugang von Fach- und Führungskräften zum Produktionsfaktor Information sicherzustellen und dadurch Führungsentscheidungen zu unterstützen und zu verbessern. Davon abzugrenzen sind operative Informationssysteme, die auf die Unterstützung von Ausführungsentscheidungen im Rahmen der Disposition und Administration abzielen und oftmals mittels betriebswirtschaftlicher Standardsoftware realisiert werden. Da die eingesetzten Informationssysteme von der Managementebene abhängen, werden operative und analytische Informationssysteme - ebenso wie Managementebenen - in Form einer Pyramide (siehe Abbildung 16) dargestellt. In Verbindung mit der pyramidenförmigen Anordnung wird auch von vertikaler Integration gesprochen, weil die von analytischen Informationssystemen verwendeten Daten im Wesentlichen den operativen Informationssystemen entstammen.'"

335

336

Z. B. Data Warehouse und OLAPj siehe Abschnitt 4.1.3 bzw. Abschnitt 4.1.2. Der Begriff Business Intelligence wurde 1989 von Howard Dresner, einem Analysten des Gartner-Konzerns geprägt. Zunächst wurde der Terminus wesentlich von Überlegungen des Gartner-Konzerns beeinflusst. So erklärte dieser im Jahr 1996: "By 2000, Information Democracy will emerge in forward-thinking enterprises, with Business Intelligence information and applications available broadly to employees, consultants, customers, suppliers, and the public. The key to thriving in a competitive marketplace is staying ahead of the competition. Making sound business decisions based on accurate and current information takes more than intuition. Data analysis, reporting. and query tools can help business users wade through a sea of data to synthesize valuable information from it - today these tools collectively fall into a category called "Business Intelllgence zitiert nach Anandarajan (2004), S. 18 f. Vgl. zu Begriffsanalysen und Definitionsvorschlägen: Gluchowski (2001); Mertens (2002); Gluchowski, Kemper (2006); Kemper, Baars (2006). Chamoni, Gluchowski (2006), S. 11. Vg!. Mertens, Meier (2009), S. 1. H

."

337

338

96

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Abbildung 16: Informationssystempyramide

Vertikale Integration

Analytische Informationssysteme

Operative Informationssysteme Die Unterschiede zwischen operativen und analytischen Informationssystemen können anhand der jeweiligen Anforderungen an diese Systeme erläutert werden. Die Anforderungen an analytische und operative Informationssysteme werden oftmals unter den Bezeichnungen Online Analytical Processing (OLAP) bzw. Online Transaction Processing (OLTP) zusammengefasst."'ln der Literatur existiert eine unübersichtliche Vielzahl an Gegenüberstellungen, wobei diese Übersichten darunter leiden, dass fachliche und technische Anforderungen vermischt werden und dadurch teilweise beliebige, unsystematische und unübersichtliche Kriterienkataloge entstehen.

340

Aus diesem Grund werden in

Tabelle 5 lediglich die fachlichen Anforderungen an operative und analytische Informationssysteme dargestellt. Jede Anforderung ist dabei von allen in der n9 Vgl. Mertens, Meier (2009), 5. 16 ff. Der OLAP-Begriff wurde geprägt von Codd et al. (1993). Die Autoren definieren den Begriff mithilfe von zwölf Merkmalen. Ein weiterer bekannter Anforderungskatalog verbirgt sich hinter dem Akronym FASMI (Fast Analysis of 5hared Multidimensional Information) von Pendse, Creeth (0.1.). Die Anforderungskataloge werden bspw. diskutiert in Jahnke et a!. (1996), Gabriel et al. (2000). 340 Vgl. bspw. Goeken (2006), 5. 21; Kemper et al. (2006), 5. 14; Alpar et a!. (2008), 5. 252; Mertens, Meier (2009), 5. 17.

97

Analytische Informationssysteme

Tabelle über ihr stehenden Anforderungen abhängig. In der Tabelle ist darüber hinaus die Zuordnung der Anforderungen zu den Funktionsblöcken Datennutzung, Datenbereitstellung und Datenhaltung dargestellt. Tabelle 5: Fachliche Anforderungen an operative und analytische Informationssysteme FunktIonsblock

Anforderung

OlTP

QlAP

Datennutzung

Prlmärzlel

Abwicklung von Geschäftsprozessen

Informationen für Fach- und Führungskräfte; Entschei-

Ergonomie

strukturiert; oft statisch im

benutzerfreundliche Ad-hoc-

Programmcode

Anfragen; vorgefertigte Berichtssysteme

Fokus

Daten lesen, schreiben, ändern und löschen

multidimensionale Analysen des Datenbestandes

Datenorganisation

funktions- bzw. geschäftsprozessorientiert

themenorientiert

Zustand

häufig redundant; tlw. inkonsistent

Integriert

Beständigkeit

flüchtig (werden überschrieben)

beständig

Zeitbezug

aktuell; zeitpunktbezogen

zeitliche Varianz, Historie

dungsunterstützung

Datenbereitstellung Datenhaltung

In Anlehnung an Tabelle 5 werden analytische Informationssysteme entsprechend der dargestellten Funktionsblöcke Datennutzung, Datenbereitstellung und Datenhaltung in den Abschnitten 4.1.1, 4.1.2 und 4.1.3 dargestellt. In Abschnitt 4.1.4 wird anschließend evaluiert, inwiefern analytische Informationssysteme den ermittelten Anforderungen an ein Informationssystem zur Automatisierung von Führungsentscheidungen entsprechen.

4.1.1

Datennutzung analytischer Informationssysteme

Das Primärziel der Datennutzung analytischer Informationssystemen ist es, Informationen für Fach- und Führungskräfte zur Verfügung zu stellen und dadurch deren Entscheidungen zu verbessern. Abgeleitet von diesem Primärziel gibt es eine Reihe sehr heterogener Nutzungsarten, die das in Tabelle 5 formulierte Ergonomie-Ziel (benutzerfreundliche Ad-hoc-Anfragen und vorgefertigte

98

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Berichtssysteme) auf unterschiedliche Art und Weise erfüllen. Existierende Systeme werden im Folgenden - einem Vorschlag von GLUCHOWSKI und KEMPER folgend - mithilfe eines Schalenmodells, das nach Nutzungsart unterscheidet, vorgestellt.'" Das Schalenmodell ist übersichtsartig in Abbildung 17 dargestellt. Abbildung 17: Schalenmodell der analytischen Informationssysteme zur Datennutzung

Prlselltalknls- und ZUpnpsyslleme

• •

BI-Portale Man.,ement COCIcpits und Dashboards

KonzeptorIentierte Systeme

·• • •

Balanced Scorecard Planung und Budgetierung Konsolidierung Wertorientiertes Management

Generische Basissysteme Berichtssysteme

·· ·

Ad-hoc-Berichte StandardReporting ExceptionReporting

Ad-hocAnalysesysteme

• •

OLAP-Analysen Ad-hoc-Anfragen (SQL, MDX)

Modellgestützte Analysesysteme

• • •

Decision Support Systems Expert Systems Data Mining

Vgl. Gluchowski, Kemper (2006), S. 16.

Generische Basissysteme stellen den Kern jeglicher analytischen Datennutzung dar und lassen sich unterscheiden in Berichtssysteme, Ad-hoc-Analysesysteme und modellgestützte Analysesysteme. Während Berichtssysteme'" Fach- und Führungskräfte push-orientiert mit Informationen versorgen, können mithilfe 341

342

Vgl. Gluchowski, Kemper (2006), S. 16; Statt der Präsentations- und Zugangssysteme werden in anderen Publikationen von Kemper et al. Implementierungsansätze in das Schalenmodell integriert. Vgl. Kemper, Baars (2006), S. 12; Kemper et al. (2006), S. 84. Vgl. diese Quellen auch für die folgende Darstellung der analytischen Informationssysteme zur Datennutzung. Berichtssysteme versorgen Fach- und Führungskräfte regelmäßig (Standard Reporting) oder in Ausnahmesituationen (Exception Reporting) mit Informationen. Darüber hinaus können individuelle und bedarfsgerechte Berichte erstellt werden .. Vgl. Kemper et al. (2006), S. 111 f.

99

Analytische Informationssysteme

von Ad-hoc-Analysesystemen multidimensionale Analysen zur Lösung eines Problems durchgeführt werden. Modellgestützte Analysesysteme enthalten eine ausgeprägte algorithmische oder regelbasierte Ausrichtung und sind meist für einen engen Anwendungsbereich konzipiert.'"

Konzeptorientierte Systeme

verwenden die Daten der generischen Basissysteme für betriebswirtschaftliche Konzepte wie die Balanced Scorecard oder das wertorientierte Management (Economic Value Added).344 Präsentations- und Zugangssysteme schließlich ermöglichen einen adäquaten Zugang zu den Informationen.'" Systeme, die sich an Führungskräfte richten, versuchen dabei meist eine einfache Bedien46

barkeit mit mächtigen Abfragen und Visualisierungstechniken zu verbinden:

Ausgehend von den in Abschnitt 3.3.2 formulierten Anforderungen an ein System zur Automatisierung von Führungsentscheidungen sind insbesondere die Ad-hoc-Analysesysteme von Bedeutung, da diese (flexible) multidimensionale Sichten auf Wert- und Mengengrößen ermöglichen:" Die übrigen Systeme zur Datennutzung werden dagegen im Folgenden nicht weiter betrachtet.

4.1.2

Datenbereitstellung analytischer In!ormationssysteme

Die zentrale fachliche Anforderung an die Datenbereitstellung analytischer Informationssysteme ist es, multidimensionale Sichten auf den Datenbestand

343

344

345

346 347

Zu den modellgestatzten Analysesystemen zählen DSS, Expertensysteme (XPS) und Data Mining. Vgl. für eine Übersicht Kemper et al. (2006), S. 102 ff.; Kemper, Baars (2006), S. 13. Vgl. zur Balanced Scorecard Kaplan, Norton (1992); zum wertorientierten Management bspw. Young, O'Byrne (2000). Präsentations- und Zugangssysteme können sehr vielfältig sein. Zu nennen sind hier Tabellenkalkulationsprogramme (z. B. Microsoft Excel), browsergestützte Front Ends oder speziell entwickelte OLAP-Clients, die interaktive Analysen ermöglichen. BI-Portale zielen darauf ab, die Informationen aus verschiedenen Systemen verdichtet an einem Ort anzubieten. Management-Dashboards und -Cockpits stellen dem Entscheidungsträger eine Instrumententafel zur Verfügung, mit der eine Organisation analog zu einem Fahrzeug oder einem Flugzeug gesteuert werden kann. Vgl. Gluchowskl, Kemper (2006), S. 17. Vgl. die Ergonomie-Anforderung in Tabelle 5 und Goeken (2006), S. 43. Vgl. Anforderung hA4 (multidimensionale Sichten) und hA3 (flexible Bezugsobjekthierarchien) in Abschnitt 3.3.2.

100

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

zu ermöglichen.'" Darüber hinaus soll eine flexible Navigation in diesem Datenraum im Sinne von Bezugsobjekthierarchien ermöglicht werden.'" Multidimensionale Datenräume bestehen aus quantifizierenden und qualifizierenden Informationen. Die quantifizierenden Informationen, repräsentiert durch betriebswirtschaftliche Kennzahlen, werden eingeschränkt und beschrieben durch qualifizierende Informationen. Zur multidimensionalen Beschreibung werden qualifizierende Informationen in Dimensionen eingeteilt, welche verschiedene Auswertungssichten auf Kennzahlen ermöglichen."· Innerhalb von Dimensionen können zwischen den qualifizierenden Informationen hierarchische Beziehungen bestehen. Durch Einordung der dimensionalen Elemente in Hierarchien können unterschiedliche Verdichtungsstufen entlang eines Konsolidierungspfads betrachtet werden.'" Die Elemente des Konsolidierungspfads werden auf Typebene als Dimensionsebenen bezeichnet. In Abbildung 18 ist das konzeptionelle MER-Modell eines multidimensionalen Datenraums dargestellt. Der Datenraum stellt Vertriebsinformationen bereit, in welchem die Kennzahlen Anzahl und Zins durch die Dimensionen Kunde, Vertriebsort, Zeit und Produkt beschrieben werden. Die Verdichtungsbeziehungen in den Dimensionen werden durch Dimensionsebenen dargestellt.

:Ma

349

350 351

Das Merkmal der Multidimensionalität ist auch das wesentliche Merkmal in den OLAPKriterienkatalogen von Codd et al. (1993) und Pendse, Creeth (o.J.). Beide sprechen von einem "multidimensional conceptual view", d. h. es geht bei dieser Anforderung zunächst nicht um die technische Realisierung der Multidimensionalität oder gar die Bindung an eine bestimmte Datenbanktechnologie. Vgl. zu Bezugsobjekthierarchien Abschnitt 3.3.2. Vgl. Kemper, Baars (2006), S. 62; Bauer, Günzel (2009), S. 189. Vgl. Holten (1999), S. 84 f.; Kemper, Baars (2006), S. 62.

Analytische Informationssysteme

101

Abbildung 18: Konzeptionelles Modell eines Hypercubes

Die Auswertungsmöglichkeit multidimensionaler Datenräume wird üblicherweise mittels der Würfel-Metapher dargestellt.'" In Abbildung 19 ist ein solcher Würfel - auch bezeichnet als Hypercube oder OLAP-Würfel - mit den Dimensionen Vertriebsort, Zeit und Produkt dargestellt. Neben den bereits eingeführten Begriffen multidimensionaler Datenräume ist in der Abbildung dargestellt, dass die ausgeprägten Elemente einer Hierarchie als Hierarchieelemente bezeichnet werden, mit deren Hilfe wiederum genau eine Zelle des

Hypercubes beschrieben werden kann, die entsprechende Kennzahlenwerte enthält.'S3

352

m

Vgl. Kemper et al. (2006), S. 95. Die WQrfeimetapher bedeutet nicht, dass die Anzahl der möglichen Dimensionen auf drei begrenzt ist. Der Begriff Hypercube deutet bereits an, dass die Anzahl der Dimensionen prinzipiell unbeschränkt ist. Vgi. Sapia etai. (1999), 5.107.

102

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Abbildung 19: Hypercube mit Elementen

~=-

l·m'~,"H_1

Hierarchie

l

:vertri~bsort

~.

M:'-E:~:F=F2=5

_________

:Jl~~""'~

lI=30===t'11

Stadtllilendo Produkte /

IJ./

2008

"", u hl ----.,.

Zeit -,-----------'

}-_--"-_---"_---Y 2007

~D~lm~.~~~o~,~

DispositIonskredite lConsumkredlte

2009

~~----E~

Die wichtigsten Operationen in einem multidimensionalen Datenraum sind Slice, Pivotierung, Dice und Drill-down bzw. Roll-up. Diese werden im Folgenden kurz vorgestellt.'" Um die Darstellungen generischer und übersichtlicher zu gestalten, wird auf die Darstellung von Kennzahlen, Dimensionsebenen und Hierarchien verzichtet. Mithilfe der Slice-Operation wird die n-Dimensionalität eines Datenraums auf n-1 Dimensionen beschränkt, indem der Wert einer Dimension auf einen Wert beschränkt wird.'55 Die Anwendung der Slice-Operation in dreidimensionalen Datenmodellen ist übersichtsartig in Abbildung 20 dargestellt, wobei die SliceOperation in (al, (bl und (cl jeweils in einer anderen Dimension erfolgt.

354

Weitere Operationen sind: Drill-Through, Drill-Across, SplitjMerge und Nest. Vgl. Goeken

355

Vgl. Kemper, Baars (2006), S. 98.

(2006): Kemper et 01. (2006), S. 96 11.

103

Analytische Informationssvsterne

Abbildung 20: Slice-Operation {_I AI" Prud..1rW .... d...........n z.1tr-. ..m flIr"n. t.tIITIIIIHYtlrtJt.........

{lfl Ah 1'nId.... In ....n "",I...n flIr "n.. t.tIm .....n z.1tiI~kt

tvertrtebsort

t Vertrleb50rt

/1 /

J.---------

///

/

/,,,, V----

,.-

'l'IIckoktt

{eiAI" ........ D~r.n",""'nz.ttr.um ftlr .1n ....mmt. Prud.. 111

•

'VertrieblDrt

/1/ / I

..."".-

///~

/

/i

-7~~-

/

V---""

....,.-

/

Bei der Pivotierung wird der Würfel um eine Achse gedreht."· Häufige Anwendung findet diese Operation bei Pivot-Tabellen marktüblicher Tabellenkalkulationsprogramme,357 Die Operation Dice wird verwendet. um Teilwürfel aus einem multidimensionalen Datenraum zu extrahieren.'" Dieser Vorgang ist in Abbildung 21 dargestellt. Abbildung 21: Dice-Operation (b) TellWÜrfel

(a) GeumtwOrfel mit Tellwürfel

/

• Vertriebsort

/ V

/

-...,

;'

3S6

357 358

Vgl. Jukic et al. (20OS), S. 267 f. Vgl. Kemper et al. (2006), S. 96. Vgl. Kemper, Baars (2006), S. 98 f.

I

Vertriebsort

Konsurnentenkredfte In der RetIon MarburJ Im Jahr 2000

//~------L ~ --~:~ Produkt~

•

Produkte."

;'

/

/

Zeo ---~

104

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Die Operationen Drill-down und Roll-up werden zur Navigation innerhalb von Hierarchien verwendet.'" Mithilfe von Drill-down wird ein aggregierter Wert in seine Bestandteile auf der darunter liegenden Dimensionsebene detailliert. Ein RolI-Up verringert dagegen den Detaillierungsgrad, indem die Werte auf einer höheren Dimensionsebene aggregiert werden. Die Operationen Drill-down und Roll-up sind in Abbildung 22 dargestellt. Abbildung 22: Drill-down und Roll-up

Februar

MiI ..

140.000

100.000

200.000

120.000

40.000 45.000 55.000

30.000 35.000 35.000

70.000 60.000 70.000

40.000 35.000 45.000

Vgl. Kemper et 01. (2006), S. 97.

Zur technischen Realisierung multidimensionaler Datenbereitstellung werden sogenannte OLAP-Server eingesetzt. Die Implementierung kann entweder mithilfe von relationaler oder multidimensionaler Datenbanktechnologie realisiert werden, wobei bei relationaler Datenbanktechnologie die Multidimensionalität durch Star-Schemata und deren Varianten realisiert wird."o

4.1.3

Datenhaltung analytischer Informationssysteme

Aufgrund der unterschiedlichen Anforderungen an analytische und operative Informationssysteme bzgl. Datennutzung und Datenbereitstellung sollten analytische Informationssysteme nicht unmittelbar auf der selben Datenbasis wie operative Informationssysteme arbeiten, sondern eine den Anforderungen

359

360

Vgl. Jukic et al. (2008), S. 268 f. Star-Schemata und Varianten werden bspw. in Schelp, Chamoni (2000), S. 1132; Azevedo et al. (2009), S. 51 ff. ausführlich vorgestellt.

Analytische Informationssvsteme

entsprechende eigenständige Datenbasis verwenden.

105 361

Der dritte Funktions-

block analytischer Informationssysteme ist daher die Datenhaltung. Zentraler Bestandteil analytischer Systeme zur Datenhaltung ist ein Data Warehouse, das eine von operativen Informationssystemen losgelöste, analytische

Datenbasis zur Verfügung stellt. In Abschnitt 4.1.3.1 wird zunächst das Konzept des Data Warehouses detailliert, ehe in Abschnitt 4.1.3.2 die Architektur eines Data-Warehouse-Systems dargestellt wird. 4.1.3.1

Data-Warehouse-Konzept

Ein Data Warehouse ist eine von den operativen Datenbeständen losgelöste, redundant gehaltene, einheitliche und konsistente Datenbasis, die idealerweise von allen analytischen Informationssystemen einer Organisation genutzt wird. Nach einer verbreiteten Definition von INMON kann ein Data Warehouse durch die Merkmale Themenorientierung, Integration, Beständigkeit und zeitliche Varianz genauer charakterisiert werden: "A data warehouse is a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management's decision"362

Diese Merkmale können als Anforderungen an die Datenhaltung analytischer Informationssysteme betrachtet werden und werden im Folgenden vorgestellt.

Themenorientierung (.subject-orlented N ) . Während operative Informationssysteme funktions- und geschäftsprozessorientiert aufgebaut sind, orientiert sich ein Data Warehouse am Informationsbedarf von Fach- und Führungskräften und ist daher themenorientiert nach betriebswirtschaftlich relevanten Bezugsobjekten angelegt.''' Weit verbreitete Bezugsobjekte entstammen der

361 362

363

Vgl. Winter (2000), S. 128 f. Inmon (2002), S. 31. Da die Definition eines Data Warehouses von Inmon sehr restriktiv ist, ist sie nicht ohne Kritik geblieben. So fordert etwa Zeh (2003) eine wesentlich umfassendere Definition. Vgl. zu Interpretationen der Inmon-Definition bspw. Goeken (2006), S. 17 ff.; Goeken et al. (2006), S. 1410: Kemper et al. (2006), S. 1711.: Alpar et al. (20OS), S. 253 f. Vgl. Abschnitt 3.3.2 zu Bezugsobjekten. Es ist in der Literatur umstritten, wie eine Themenorientierung erreicht werden kann. Während Inmon (2002) eine Orientierung am Unternehmensdatenmodell empfiehlt, betont bspw. Goeken (2006), dass die Themenorientierung im Wesentlichen durch den Informationsbedarf von Fach- und Führungskräften herzustellen ist.

106

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Aufbauorganisation

(Geschäftsbereiche,

Organisationsbereiche,

rechtliche

Einheiten), der Produktstruktur (Produktgruppen, Produkte), der Regionalstruktur (Länder, Gebiete, Bezirke, Filialen), der Kundenstruktur (Kundensegmente, Kunden) oder der Zeitstruktur (Quartale, Monate).'64 Den Bezugsobjekten werden entsprechende Geld- oder Mengengrößen zugeordnet.

Integratian (.integrated N). Das Data Warehouse integriert Daten, u.a aus den heterogenen operativen Informationssystemen eines Unternehmens.

365

Darü-

ber hinaus gewinnt die Integration unternehmensexterner und teilweise unstrukturierter Daten zunehmend an Bedeutung. Um eine konsistente und systemübergreifende Datenbasis zu gewährleisten, müssen die zu integrierenden Daten vor ihrer Übernahme in das Data Warehouse homogenisiert, transformiert und ggf. bereinigt werden. Die Integration der Daten erfolgt in fest definierten, regelmäßigen Abständen.

Beständigkeit (.nanvolatile N ). Die Daten operativer Informationssysteme repräsentieren den aktuellen Status von Geschäftsprozessen und werden entsprechend überschrieben, gelöscht oder neu angelegt.'" Die Historie der Daten wird üblicherweise nicht systematisch gespeichert. Da ein Data Warehouse ausdrücklich eine Historie bereitstellen soll, werden die einmal ins Data Warehouse geladenen Daten nicht mehr verändert. Data·Warehouse-Daten können somit nur gelesen werden.

Zeitliche Varianz (.time-variant R ). Während die Daten operativer Informationssysteme zu jedem Zeitpunkt den aktuellen Status widerspiegeln, beziehen sich die in einem Data Warehouse gespeicherten Daten jeweils auf exakt einen Zeitpunkt, bspw. den Zeitpunkt des Datenimports.'67 Mit jedem Datenimport wird ein "Schnappschuss· des Unternehmensgeschehens aus den operativen Informationssystemen in das Data Warehouse übertragen. Um die Daten historisiert speichern zu können, erhalten die Daten einen Zeitstempel. Dieser Zeitstempel kann verwendet werden, um Trends in den Unternehmensdaten zu

364 365

366 361

Vgl. Kemper et al. (2006), S. 18. Die Integration von operativen Daten in einem Data Warehouse wird in Anlehnung an die Informationssystempyramide (vgl. Abbildung 16) auch als vertikale Integration bezeichnet. Vgl. Mertens, Meier (2009), S. 1. Vgl. Kemper et al. (2006), S. 19. Vgl. Gluchowski et al. (2008), S. 120.

Analytische Informationssvsterne

107

betrachten und zu analysieren. Zu dem Merkmal der zeitlichen Varianz ist anzumerken, dass in den vergangenen Jahren unter Schlagworten wie Real-Timeoder Right-Time-Data-Warehousing eine Absenkung der Datenlatenz in Verbindung mit einer häufigeren Befüllung des Data Warehouses diskutiert wird und die Bedeutung dieses Merkmals somit abnimmt.''' Nachdem im vergangenen Abschnitt die Merkmale eines Data Warehouses erläutert wurden, stellt der folgende Abschnitt die Architektur eines DataWarehouse-Systems dar und verdeutlicht somit die technische Realisierung eines Data Warehouses.

4.1.3.2

Die Architektur eines Data-Warehouse-Systems

Im Folgenden wird analog zum Begriffspaar Datenbank und Datenbanksystem zwischen einem Data Warehouse und einem Data-Warehouse-System differenziert.''' Während das Data Warehouse die beschriebene Datenbasis in Form einer oder mehrerer Datenbanken umfasst, enthält ein Data-WarehouseSystem darüber hinaus Werkzeuge und Programme zur Nutzung des Data Warehouses.

370

Die Architektur eines Data-Warehouse-Systems beschreibt die Komponenten des Systems und ihre Verbindungen. Die Darstellung erfolgt dabei entlang des Datenflusses in Form von Ebenen-Modellen, wobei deren Anzahl je nach Darstellung variieren kann.'71 Wesentliche Ursache für die unterschiedliche Anzahl der Ebenen ist, dass die analytischen Informationssysteme zur Datennutzung sowie zur Datenbereitstellung teilweise in die Architektur eines DataWarehouse-Systems integriert werden.''' Im Folgenden wird allerdings eine Data-Warehouse-Architektur vorgestellt, die lediglich aus den Ebenen Datenquellen, Datenerfassung und Datenhaltung besteht.''' Die Ebene der Datenhaltung berücksichtigt implizit bereits Aspekte 368

369 370

371

372

373

Vgl. Brobst (2004); Brobst (2004) Karakasidis et al. (2005); Schelp (2006). Siehe zur Absenkung der latenz auch Abschnitt 4.3.1 dieser Arbeit. Vgl. Stahlknecht, Hasenkamp (2005), 5.159; Vossen (200S), 5.10 f. Vgl. Winter (2000), S.12S. Böhnlein, Ulbrich-vom Ende (2000), 5.17. Vgl. Jung, Winter (2000), S. 10 ff.; Propach, Reuse (2003), S. 9S ff.; Goeken (2006), 26 ff.; Mucksch (2006), S. 131 ff.; Goeken et al. (2006), 1410 ff. Vgl. bspw. Propach, Reuse (2003), S. 9S ff.; Goeken (2006), 26 ff.; Goeken et al. (2006), 1410 ff. Eine ähnliche Architektur wird bspw. von Kemper et al. (2006), S. 21 ff. präferiert.

108

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

der späteren Datenbereitstellung, da die Anforderungen an die Datenbereitstellung bei der Datenhaltung zu beachten sind. Die Architektur ist in Abbildung 23 dargestellt und wird im Folgenden entlang des Datenflusses beschrieben. Abbildung 23: Data-Warehouse-Architektur

Metadaten

Administration

Data Warehouse

oatenerflluulIJMbene Laden Transfonnation Extraktion

>

Administration

Dltenquellen

Interne Datenquelien

Externe Diltenquelien

Die Ebene der Datenquellen enthält Informationssysteme, die das Data Warehouse mit Daten beliefern. Dabei können interne und externe Datenquellen unterschieden werden. Die Mehrheit der Daten stammt üblicherweise aus internen operativen Informationssystemen und liegt strukturiert in (relationalen) Datenbanken vor. Darüber hinaus können allerdings auch unstrukturierte Daten bspw. aus Textdokumenten integriert werden. Eine wachsende Bedeutung kommt der Integration externer Daten (z. B. Umrechnungskurse von Wäh-

Analytische Informationssvsteme

rungen)

109

ZU.'74 Die Auswahl der zu integrierenden Daten muss sorgfältig ent-

sprechend den informatorischen Anforderungen von Fach- und Führungskräften erfolgen, da die Qualität der Daten die Qualität des gesamten DataWarehouse-Systems stark beeinflusst.''' Auf der Datenerfassungsebene werden die Daten von den Datenquellen in das Data Warehouse übertragen. Die Überführung wird unterteilt in die Schritte Extraktion, Transformation und Laden und daher kurz als ETL-Prozess bezeichnet.

37 •

Die Extraktion als erster Schritt beschreibt das kopierende Übertragen

von relevanten Daten aus den Quellsystemen in die sogenannte Staging Area.'" Dort werden die Daten im nächsten Bearbeitungsschritt - der Trans-

formation - syntaktisch und semantisch vereinheitlicht und konsolidiert. Zur syntaktischen Vereinheitlichung zählen die Datentypharmonisierung, die Bereinigung von inhaltlich überflüssigen Feldern, die Vergabe einheitlicher Datumsformate und die Verwendung einheitlicher Währungen. 37• Bei der semantischen Vereinheitlichung werden insbesondere Inkonsistenzen, Synonyme und Homonyme beseitigt, die erst durch die Kombination mehrerer Felder erkennbar werden.''' Anschließend werden umfangreiche Konsolidierungen durchgeführt, um die Daten entsprechend der Anforderungen des Data Warehouses zu transformieren. Dazu zählt bspw. die Aggregation von Daten, die Vergabe einheitlicher Surrogatschlüssel oder das Zusammenführen von Datensätzen aus mehreren Datenquellen ("Join").38O Beim abschließenden Laden werden die aufbereiteten Daten in die Datenhaltungsebene übertragen. 374

Vgl. Holthuis (1999), S. 90 ff.; Propach, Reuse (2003), S. 100; Goeken (2006), S. 28; Mertens,

Meier (20091, S. 21 11.

375 376

377

371 379

3111

Vgl. Propach, Reuse (2003). Vgl. Goeken et al. (2006), S. 1411; Kemper et al. (2006), S. 22 ff. Diese Schicht stellt einen der erfolgskritischsten Faktoren bei der Implementierung eines Data Warehouse dar. Nach Aussage verschiedener Autoren müssen bis zu 80 % des gesamten Projektaufwandes für diese Schicht und somit für das Reinigen und Transformieren der vorhandenen operativen Daten verwendet werden. Vgl. Vassiliadis et al. (2002), S. 14; Trujillo, lujan-Mora (2003), S. 308. Vgl. Bartel et al. (2000), S. 53. Die Autoren führen weiter aus, dass entweder im Extraktionsschritt alle Daten in die Staging Area kopiert werden können oder alternativ bereits eine erste Selektion stattfinden kann. Vgl. Bartel et al. (2000), S. 53. Vgl. Bartel et al. (2000), 5. 53. Vgl. Trujillo, lujan-Mora (2003), S. 309 ff. für eine Übersicht zu ETl-Standardaktivitäten. Kemper et al. (2006), S. 23 ff. unterscheiden die Teilprozesse Filterung, Harmonisierung, Aggregation und Anreicherung.

110

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Wesentlicher Bestandteil der Datenhaltungsebene ist eine zentrale DataWarehouse-Datenbank (auch als Core Data Warehouse bezeichnet), in welche die vom ETL-Prozess generierten Daten eingelesen werden.'81 Zur Steigerung der Performance und zur besseren Übersichtlichkeit werden meist Teile des Data Warehouses in sogenannten Data Marts gehalten. Ein Data Mart kann definiert werden als ein fachlich begrenztes Data Warehouse oder als eine aufgabenbezogene Teilmenge eines Data Warehouses.'" Umstritten ist die Frage, ob innerhalb der Datenhaltungsebene die Daten zunächst normalisiert und möglichst redundanzfrei vorgehalten werden und anschließend (bspw. in Data Marts) auswertungsorientiert organisiert werden (bspw. in Form von Star Schemata) oder ob die Daten unmittelbar auswertungsorientiert gespeichert werden sollen.'" Ergänzt wird die Datenhaltungsebene um Metadaten, die Informationen über die Daten des Data Warehouses und deren Herkunft enthalten.'"

381

382

383

384

Teilweise werden auch dezentrale Oata-Warehouse-Architekturen diskutiert. Vgl. Kemper et al. (2006), S. 19 f. Für operative Zwecke wird die Architektur oftmals um ein Operational Oata Store (DOS) ergänzt. Vgl. Jung, Winter (2000), S. 12; Winter (2000), S. 13S. Kemper et al. 12006), 5. 38 ff.; Mertens, Meier (2009), 5. 35. Vgl. Kemper et al. (2006), S. 22; 36 f.; Mertens, Meier (2009), S. 34. Die Architektur eines zentralen Oata Warehouses und angeschlossenen Oata Marts wird auch als Nabe-SpeicheArchitektur bezeichnet. Es sind allerdings auch andere Architekturvarianten denkbar. Vgl. Gluchowski et al. (2008), S. 129 ff. Vgl. für die erste Position bspw. Jung, Winter (2000), S. 10 ff. Klmball, Ross (2002), S. 9 ff. vertreten dagegen die Position, dass die doppelte Speicherung einen unnötigen Aufwand darstellt. Vgl. Schwarz (2000), S. 102 ff.; Mucksch (2006), S. 137 ff.

111

Ereignisgetriebene Informationssysteme

4.1.4

Beurteilung analytischer Infarmationssysteme

Analytische Informationssysteme sind passiv, d. h. sie erfüllen die notwendige Anforderung (nA) an ein Informationssystem zur Automatisierung von Führungsentscheidungen nicht. Allerdings ermöglichen analytische Informationssysteme multidimensionale Sichten auf Wert- und Mengengrößen und stellen flexible Bezugsobjekthierarchien zur Verfügung. Die Systeme stellen somit Informationen bzgl. des betrachteten Realitätsausschnitts in der geforderten Form zur Verfügung und erfüllen die Anforderungen hA3 und hA4. Analytische Informationssysteme scheinen somit grundsätzlich als Datenquelle zur Automatisierung von Führungsentscheidungen interessant. Existierende Ansätze zur Erweiterung von analytischen Informationssystemen um reaktive Komponenten werden in Abschnitt 4.3 diskutiert.

4.2

Ereignisgetriebene Informationssysteme

Gegenstand des vorliegenden Abschnitts sind ereignisgetriebene Informations-

systeme.'·' Es handelt sich dabei um Systeme, die von Ereignissen ausgelöst werden und insbesondere auf die Automatisierung von Ausführungsentscheidungen abzielen. Ereignisgetriebene Informationssysteme waren lange Zeit auf die Anwendungsbereiche eingebettete Systeme (embedded systems) und aktive Datenbanksysteme beschränkt, in den letzten Jahren ist jedoch eine deutlich steigende Bedeutung ereignisgetriebener Informationssysteme für andere Anwendungen zu beobachten. Wesentliche Ursache für die steigende Verbreitung ist die stark ansteigende Datenflut bspw. aus dem Internet, aus Sensornetzen und sonstigen Netzwerken.'86 So entstehen im Kundenservice von Telekommunikationsunternehmen (z. B. bei der Abwicklung von Mehrwertdiensten) oder in Logistikunternehmen (z. B. bei Sensornetzen auf Basis von RFID) riesige Ereigniswolken, die nach Ereignismustern zu durchsuchen

3115

Erelgnlsgetrlebene Informationssysteme werden In englischsprachlgen Publikationen entweder als ... Event-driven oder als ... Sense and Response Applications bezeichnet. Vgl. Schiefer, Seufert (2005); Chandy (2006); Chandy, Olson (2008). Vgl. Babcock et al. (2002), S. 1; Cammert et al. (2004), 5. 5. H

38Ii

H

112

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

sind.'·' Zur schnellen Verarbeitung verwenden Unternehmen zunehmend ereignisgetriebene Informationssysteme. Wesentlicher Bestandteil ereignisgetriebener Informationssysteme sind ECARegeln, welche eine Integration der in Abschnitt 3.3.1 dargestellten Konditionalprogramme sowie auslösenden Ereignissen darstellen.'·· Das Akronym ECA rührt von den englischsprachigen Bezeichnungen der Bestandteile von ECARegeln her: • •

Das Ereignis (Event) legt fest, wann die ECA-Regel ausgeführt wird. Die Bedingung (Condition) einer ECA-Regel wird überprüft und nur wenn diese erfüllt ist, wird die Aktion ausgeführt. In bestimmten Fällen kann die Abgrenzung zwischen Ereignis und Bedingung nicht eindeutig sein.'·' So können etwa in einfachen Fällen Bedingungen des Konditionalprogramms in der ECA-Regel auch als Ereignis formuliert werden.

•

Die Aktion (Action) legt fest, wie bei Erfüllung der Bedingung reagiert werden soll.

In Abbildung 24 sind Ereignis (ON), Bedingung (IF) und Aktion (00) einer ECARegel da rgestellt. '90 Abbildung 24: ECA-Regel

ON

Kreditantrag

IF

Kreditsumme > 5000

DO

Kreditfähigkeit prüfen

Es existieren verschiedene Ansätze zur Realisierung ereignisgetriebener Informationssysteme, die im Folgenden vorgestellt werden.'''

387 388

389

390

Vgl. Rommelspacher (2008a). Synonym zu ECA-Regeln wird teilweise der Begriff Trigger verwendet. Vgl. Dittrich et al. (1995), S. Si Dittrich, Gatziu (2000), S. 10 und S. 100. Vgl. Herbst, Knolmayer (1995), S. 150. Dlttrlch, Gatzlu (2000), S. 8 ff. fClhren zudem noch den Begriff der Situation ein, die Ereignis und Bedingung integriert. Zur Darstellung der ECA-Regel wird der regelbasierte Modellierungsansatz verwendet, welcher ausführlich in Abschnitt 6.2.4 eingeführt wird.

113

Ereignisgetriebene Informationssysteme

Der erste Ansatz zur Realisierung ereignisgetriebener Informationssysteme sind sogenannte aktive Datenbanksysteme. Ändern sich die persistent gespeicherten Daten eines Datenbanksystems (bspw. durch eine UPDATE-Operation), so kann dieses Ereignis als Auslöser einer ECA-Regel dienen. Aktive Datenbanksysteme sind Gegenstand von Abschnitt 4.2.1. Die zweite Möglichkeit zur Realisierung sind sogenannte Datenstrommanagement-Systeme. Diese Informationssysteme zielen auf die Verarbeitung von Datenströmen ab. Das Auftreten der Daten kann hier als auslösendes Ereignis verwendet werden. Datenströme und Datenstrommanagement-Systeme werden in Abschnitt 4.2.2 detailliert erläutert. Eine Erweiterung der Datenstrommanagement-Systeme stellt das sogenannte Complex Event Processing dar. Mithilfe dieses Ansatzes können komplexe Ereignismuster in Datenströmen verarbeitet werden. Die Verarbeitung komplexer Ereignisse mithilfe von Complex Event Processing ist Gegenstand von Abschnitt 4.2.3. In Abschnitt 4.2.4 werden die dargestellten Ansätze den formulierten Anforderungen gegenübergestellt, um Entwicklungsdefizite, aber auch Ansatzpunkte für die Automatisierung von Führungsentscheidungen aufzuzeigen.

4.2.1

Aktive Datenbanksysteme

Datenbanksysteme sind ein gängiges Mittel zur Organisation, Speicherung, Manipulation, Integration und Verwaltung großer Datenmengen.'92 Klassischerweise sind Datenbanksysteme passiv, d. h. Aktionen werden vom Datenbankmanagement-System (DBMS) nur durchgeführt, wenn Befehle von Benutzern oder anderen Anwendungsprogrammen erteilt werden. Im Gegensatz dazu können aktive Datenbanksysteme mithilfe von ECA-Regeln um reaktives Verhalten erweitert werden.'" Zur Definition von ECA-Regeln in aktiven Datenbanksystemen werden analog zur Datendefinitionssprache passi-

391

Ein

historischer

Oberblick ereignisgetriebener Systeme

findet

sich

in

Chakravarthy,

Adaikkalavan 12009), S. 243 ff. m

Vgl. Vossen (20OS), S. 3.

m

Vgl. Dlttrlch el al. 11995); Palon, Dia. 11999), S. 64; Dlttrlch, Gal.lu (2000), S. 7; Rlzvl 12005), S. 3. Nach Paton, Diaz (1999), S. 64 haben aktive Datenbanksysteme insbesondere den Vorteil, dass die Anwendungslogik in der Datenbank zentral vorgehalten wird und nicht in Anwendungsprogrammen verteilt ist.

114

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

ver Datenbanken Regeldefinitionssprachen benötigt.'" Die wesentlichen Merkmale aktiver Datenbanksysteme werden im Folgenden knapp dargestellt.'" Ereignisse werden in den ECA-Regeln aktiver Datenbanksysteme anhand ihrer

Merkmale definiert. Während der Laufzeit eines aktiven Datenbanksystems können mehrere Ereignisinstanzen eines intensional definierten Ereignisses

auftreten. In aktiven Datenbanksystemen resultieren Ereignisse im Wesentlichen aus Datenmodifikationsoperationen (im Falle einer relationalen Datenbank die Operationen INSERT, UPDATE, DELETE auf einer Relation) oder aus anderen DBMS-Operationen (bspw. Transaktionsanfang, -ende, -abbruch oder Benutzer- und Zugriffsverwaltung)."· Darüber hinaus können temporale und abstrakte Ereignisse (Ereignisse, die außerhalb des Datenbanksystems stattfinden) als Auslöser von ECA-Regeln definiert werden.''' Neben elementaren Ereignissen können auch komplexe Ereignisse in ECA-Regeln definiert werden. Zur Beschreibung und Definition komplexer Ereignisse ist eine Ereignisalgebra erforderlich.''' Einen guten Überblick über die notwendigen Eigenschaften einer Ereignisalgebra zur Beschreibung komplexer Ereignisse (in aktiven Datenbanksystemen) gibt das Metamodell von ZIMMER und UNlAND.'" Dieses beinhaltet die Dimensionen Struktur, Instanzauswahl und Instanzverbrauch komplexer Ereignisse. Während zur Beschreibung der Struktur komplexer Ereignisse die Operatoren aus Abschnitt 2.6 verwendet werden, beschreibt die Dimension Instanzauswahl das Problem, welche Instanz eines elementaren Ereignisses (wenn mehrere zur Auswahl stehen) an das komplexe Ereignis "gebunden" wird. Das Metamodell stellt Schlüsselwörter wie FIRST, LAST oder

394 395

396 397 398

399

Vgl. bspw. Gatziu, Dittrich (1994). Die Darstellung orientiert sich an u The Active Database Management ManifesteN. Es handelt sich dabei um ein Kensenspapier über die erwartete Funktienalität ven aktiven Datenbanksystemen. Entstanden ist das Papier im Rahmen des EU-Netzwerkes uACT-NET"", einem Zusammenschluss europäischer Ferschungsgruppen des Ferschungsbereichs aktive Datenbanksysteme. Vgl. Dittrich et al. (1995). Eine deutschsprachige Übersetzung findet sich in Dittrich, Gatziu (2000), S. 97 ff. Vgl. Dittrich, Gatziu (2000), S. 23 und S. 100; Dittrich et al. (1995), S. 5. Vgl. Dlttrlch, Gatzlu (2000), S. 23 ff. Vgl. bspw. Chakravarthy, Mishra (1994); Gatziu, Dittrich (1994). Vgl. für eine Übersicht und Evaluation existierender Ereignisalgebra Zimmer, Unland (1999). Vgl. Zimmer, Unland (1999); Rizvi (2005), S. 8 ff.

Ereignisgetriebene Informationssysteme

115

CUMULATIVE zur Definition einer Instanzauswahl zur Verfügung.

400

Der

Instanzverbrauch unterscheidet, ob eine Ereignisinstanz zur Konstruktion meh-

rerer komplexer Ereignisse verwendet werden kann oder nicht. Ereignisinstanzen können neben dem Eintrittszeitpunkt über weitere Ereignisparameter, wie bspw. den Name der betroffenen Relation oder den

Identifikator des Benutzers, der die Transaktion gestartet hat, verfügen. Ereignisparameter können bei der Konstruktion komplexer Ereignisse als Nebenbedingung verwendet werden.

401

So kann bei einem komplexen Ereignis bspw.

die Nebenbedingung existieren, dass alle Teilereignisse sich in einer Relation ereignen müssen.

Ein aktives Datenbanksystem verfügt über eine Ereignisgeschichte, in der die relevanten elementaren und komplexen Ereignisse in einer chronologisch geordneten Folge gespeichert werden.

40

'

Relevant ist ein Ereignis, wenn es Be-

standteil einer definierten ECA-Regel oder Bestandteil eines komplexen Ereignisses ist.

40

'

Wenn aus Kapazitätsgründen nicht die gesamte Ereignisgeschichte

gespeichert werden soll, so muss definiert werden, wie lange Ereignisse gespeichert werden.

404

Die Bedingung einer ECA-Regel gibt an, was überprüft werden muss, ehe ggf. die Aktion ausgeführt wird. Bedingungen in ECA-Regeln sind entweder erfüllt (true) oder nicht erfüllt (false) und können beschrieben werden als vollständige SQL-Anfrage mit einem nicht-leeren (true) oder leeren (false) Ergebnis oder im Stile einer WHERE-Klausel einer SQL-Anfrage.'"' Die Aktion einer ECA-Regel eines aktiven Datenbanksystems gibt an, welche Reaktion bei Erfüllung der entsprechenden Bedingung auf ein Ereignis auszu-

400 401 402

403 404

405

Vgl. Zimmer, Unland (1999). Vgl. Dittrich et al. (1995), S. 5; Dittrich, Gatziu (2000), S. 101. Wesentliche Annahme ist dabei, dass pro Zeiteinheit nur ein Ereignis auftreten kann. Dies kann über die Annahme einer unendlich feinen Zeitgranularität gewährleistet werden. Vgl. Dittrich, Gatziu (2000), S. 28. So kann etwa festgelegt werden, dass Ereignisse nur bis zum Ende einer Transaktion oder bis zum Ende einer Sitzung gespeichert werden. Ebenso kann festgelegt werden, dass ein Ereignis aus der Ereignisgeschichte entfernt wird, sobald alle zugehörigen Regeln von dem Ereignis Kenntnis genommen haben und das Ereignis nicht mehr Teilereignis eines komplexen Ereignisses sein kann. Vgl. Dittrich, Gatziu (2000), s. 28. Vgl. Dittrich et al. (1995), S. 6; Dittrich, Gatziu (2000), S. 101.

116

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

führen ist. Die Aktion kann (in Abhängigkeit vom zugrundeliegenden Datenbanksystem) Datenmodifikations-, Datenbank- oder DBMS-Operationen, gespeicherte Datenbankprozeduren oder Methodenaufrufe enthalten. Diese Operationen können wiederum als auslösende Ereignisse weiterer ECA-Regeln verwendet werden, wodurch eine Verschachtelung von ECA-Regeln ermöglicht wird. Die Summe der definierten Regeln eines Datenbanksystems wird als Rege/basis bezeichnet. Nach ihrer Definition überwacht das aktive DBMS alle relevanten Ereignisse und führt bei Eintreten eines Ereignisses alle für dieses Ereignis definierten Regeln aus.

406

Literatur beschrieben.

4.2.2

Die Rege/ausführung ist detailliert in der einschlägigen

407

Datenströme und Datenstrommanagement-Systeme

In den vergangenen Jahren ist eine Vielzahl datenintensiver Informationssysterne entstanden, bei denen die Daten nicht persistent in Relationen, sondern flüchtig in Form eines Datenstroms vorliegen.

408

Ein Datenstram besteht aus

einer temporal geordneten Abfolge von Datensätzen, wobei die Menge der ankommenden Datensätze pro Zeiteinheit (Datenrate) variieren kann und die Menge der im Zeitablauf auftretenden Daten potenziell unbegrenzt ist.

409

Da-

tenströme resultieren etwa aus Sensornetzen, der Datenübertragung in Netzwerken, Börsentickern, Verkehrsmanagementsystemen, Internetanwendungen USW.

41O

Im Folgenden wird zur Illustration der Datenstrom eines Verkehrsmanagementsystems verwendet, wobei ein Datensatz die Geschwindigkeit eines Fahrzeuges zu einem bestimmten Zeitpunkt repräsentiert, welche an einem Kontrollpunkt gemessen wurde. Es ist nicht sinnvoll, alle Datensätze eines Datenstroms persistent in einem

klassischen Datenbanksystem zu speichern und auf dieser Datenbasis zu ope-

406

407

408 409

410

Vgl. Dittrich et al. (1995), S. 5. Vgl. Dlttrlch et al. (1995), S. 5; Dlttrlch, Gatzlu (2000), S. 102 ff. Vgl. Babcock et al. (2002), S. 1. Vgl. Seeger (2004), S. 31. Vgl. Babcock et al. (2002), S. 1; Cammert et al. (2004), S. 5.

Ereignisgetriebene Informationssysteme

rieren.

411

117

Dagegen sprechen die potenziell unbeschränkte Größe von Daten-

strömen sowie die Überlegung, dass die Datensätze eines Datenstroms nur eine beschränkte Zeit verfügbar sein müssen. Neben speziell auf bestimmte Datenströme (z. B. Video/Audio) zugeschnittenen Systemen wurden in den vergangenen Jahren zur allgemeinen Verwaltung von Datenströmen sogenannte Datenstrommanagement-Systeme (DSMS) entwickelt.

412

Die Merkmale

dieser Systeme werden im Folgenden dargestellt und anhand des genannten Beispiels illustriert. •

Datenströme werden in DSMS aufgrund ihrer potenziell unbeschränkten Größe nicht dauerhaft gespeichert. In den meisten DSMS werden die Datenströme allerdings zur Verarbeitung zwischenzeitlich in Relationen umgewandelt. Die gespeicherten Daten werden mit einem Gültigkeitsintervall versehen und bei abgelaufener Gültigkeit wieder aus dem DSMS entfernt. Wenn beispielsweise mithilfe des genannten Datenstroms ausschließlich die durchschnittliche Geschwindigkeit aller Fahrzeuge an dem Kontrollpunkt in der letzten Stunde bestimmt werden soll, so müssen die Datensätze des Datenstroms lediglich eine Stunde vorgehalten werden.

•

Die Verarbeitung der Daten erfolgt bei DSMS direkt bei Ankunft der Daten. Diese Systeme können daher als datengetrieben bezeichnet werden. Wenn ein Datensatz des oben genannten Datenstroms neu eintrifft, wird die Durchschnittsgeschwindigkeit neu berechnet.

•

Die Daten eines Datenstroms können vom DSMS nicht verändert werden. Ein Datenstrom kann somit als "append-only" charakterisiert werden.

•

Während SQL-Anfragen in klassischen Datenbanksystemen einmalig ausgeführt werden und das (zu dem Zeitpunkt der Abfrage gültige) Ergebnis an den Nutzer zurückgegeben wird, werden Anfragen eines DSMS kontinuier41

lich auf den ankommenden Datenstrom ausgeführt. ' Zur Realisierung solcher kontinuierlicher Anfragen sind sogenannte gleitende Fensteranfragen üblich.'" Das Fenster kann entweder durch einen Zeitraum oder durch eine 411 412 413 414

Vgl. Vgl. Vgl. Vgl.

Babcock et al. (2002), S. 1 ff. Babcock et al. (2002); Cammert et al. (2004); Seeger (2004); Luckham (2006). Babcock et al. (2002), S. 3. Golab, Özsu (2003) für weitere Techniken.

118

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Anzahl der betrachteten Tupel beschränkt werden.

41

'

Die Fensteranfragen

sind gleitend, weil sich mit fortschreitendem Datenstrom die Anfrage auf einen anderen Teil des Datenstroms bezieht. Zur Bestimmung der durchschnittlichen Geschwindigkeit in dem dargestellten Verkehrsmanagementsystem ist ein Zeitraum - hier eine Stunde - für das gleitende Fenster angegeben. Das DSMS verwaltet die Anfragen auf heterogene Datenströme und sendet die Anfrageergebnisse an beteiligte Informationssysteme. Die Ergebnisse können

entweder in Form von weiteren Datenströmen versendet werden oder in Relationen gespeichert werden."· Die beschriebene grundsätzliche Funktionsweise eines DSMS ist überblicksartig in Abbildung 25 dargestellt. Abbildung 25: Funktionsweise eines DSMS

Eingehender Datenstrom

Anfrageergebnis wird In Relation gespeichert

DSMS

Anfrage-Ergebnls wird als Datenstrom ausgegeben Le&ende Daten Anfrage

-----.

Datenstrom

Relation

Zur Formulierung kontinuierlicher Anfragen werden deklarative Anfragespraehen verwendet. Die vorgeschlagenen Sprachen stellen Erweiterungen der 417

Bisher hat sich kein Standard etabliert und im Datenbanksprache SQL dar. Folgenden wird die Sprache Continuous Computation Language (CCL) zur For415

416

411

Auch weitere Fensterarten sind denkbar. Während Arasu et al. (2006) partitionierte Fenster einfUhren, diskutiert Rizvi (2005) sogenannte semantische Fenster. Die Relationen können Tell des DSMS sein. Ebenso können die Ergebnisse an die Relationen externer Datenbanksysteme geliefert werden. Z. B. die Continuous Query Language (COl) oder Continuous Computation Language (CCL). Vg!. Arasu et al. (2006) bzw. Aleri (2009).

Ereignisgetriebene Informationssysteme

119

mulierung kontinuierlicher Anfragen verwendet, da diese auch bei der Entwicklung des Prototyps in Kapitel 7 eingesetzt wird.

41

'

In Tabelle 6 ist die CCL-Syntax zur Formulierung eines gleitenden Fensters und einer kontinuierlichen Anfrage aus dem obigen Beispiel dargestellt. Ergebnis der Anfrage ist die durchschnittliche Geschwindigkeit in der letzten Stunde. Tabelle 6: CCL-Anfrage Create a window CREATE WINDON FilteredMeasures SCHEMA (Speed FLOAT) KEEP 1 HOUR; -- Insert rows into the window INSERT INTQ FilteredMeasures SELECT * FROM S treamIN; -- Calculate an average and insert into the output stream INSERT INTO StreamOut SELECT AVG (Speed) AS Speed_AVG FROM FilteredMeasures;

Je nachdem, wie das Anfrageergebnis ausgegeben wird, kann es entsprechend weiterverarbeitetet werden. Wenn das Anfrageergebnis in die Relation eines aktiven Datenbanksystems geschrieben wird, können die oben dargestellten ECA-Regeln aktiver Datenbanksysteme zur weiteren Verarbeitung verwendet werden. Wenn die Anfrageergebnisse dagegen wie oben in Form eines Datenstrams weitergegeben werden, so können die resultierenden Ereignisse entweder erneut von einem DSMS oder auch von proprietären Informationssystemen verarbeitet werden. DSMS besitzen im Gegensatz zu Datenbanksystemen durch die dargestellten kontinuierlichen Anfragen per se ein reaktives Verhalten im Sinne von ECARegeln.

411 41.9

41 '

Das Auftreten von Daten im eingehenden Datenstrom eines DSMS

CCL Ist ausfOhrlich dokumentiert in Alerl (2009). Für komplexe Ereignismuster, die im Rahmen des Complex Event Processing verarbeitet werden, erkennt Luckham (2002a), S. 119 dieses Merkmal (siehe Abschnitt 4.2.3). Mohania et al. (2005) streben dagegen die Erweiterung von Datenströmen um ECA-Regeln an.

120

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

kann im Sinne dieser Arbeit als Ereignis verstanden werden.

42

•

Die kontinuierli-

che Anfrage wiederum wird ausgeführt, sobald ein neuer Datensatz eintrifft. Nur wenn die im optionalen WHERE-Teil der Anfrage enthaltene Bedingung einer Anfrage erfüllt ist, resultiert eine Aktion. Die Aktion einer kontinuierlichen Anfrage besteht darin Daten auszugeben und somit ein neues Ereignis auszulösen. Die Aktion wird im SELECT-Teil der Anfrage definiert und kann durchaus auch die in SQL enthaltenen Aggregatfunktionen AVG, COUNT, MAX, MIN, SUM enthalten (Vgl. Tabelle 6). 4.2.3

Complex Event Processing

Wie im vorigen Abschnitt dargestellt, verarbeiten DSMS eingehende Datensätze (Ereignisse) unmittelbar nach ihrer Ankunft. Diese Verarbeitungsweise ist äußerst effizient zur Verarbeitung eines einzelnen Datenstroms. DSMS sind allerdings nicht dafür konzipiert, komplexe Ereignismuster in der nEreigniswolu

ke mehrerer Datenströme zu erkennen und zu verarbeiten.

421

Zur effizienten

Verarbeitung derartiger Ereigniswolken existiert mit dem Complex Event Processing (CEP) eine Weiterentwicklung von DSMS.

422

Um den CEP-Ansatz von

LUCKHAM nachvollziehen zu können, werden zunächst die Beziehungen zwischen den Ereignissen einer Ereigniswolke betrachtet. Anschließend wird erläutert, wie Ereignismuster definiert und in CEP-Systemen durch das Erstellen komplexer Ereignisse verarbeitet werden.

423

Die Ereignisse einer Ereigniswolke entstammen in der Regel nicht nur einem Datenstrom und sind temporal sowie teilweise kausal miteinander verbunden. Mit der temporalen Beziehung können Ereignisse nach dem Kriterium Zeit geordnet werden. Die zeitliche Beziehung zwischen Ereignissen hängt von einer 420

421 422

Aus diesem Grund werden DSMS in der Literatur teilweise auch als EreignisstrommanagementSysteme (Event Stream Management Systems) bezeichnet. Vgl. bspw. Nguyen et al. (200Sa); Luckham (2006); Nguyen et al. (2oo7a). Vgl. luckham (2006). CEP wurde in den 1990er Jahren von einer Forschergruppe um luckham an der Stanford University entwickelt. Vgl. luckham, Frasca (1998); luckham (2002a). In der Literatur findet eine rege Diskussion über den Begriff und potenzielle Andwendungsbereiche statt. Vgl. Luckhom (2002b); Rizvi (2005), S. 1 11.; Kobielu. (2007); Son et 01. (2007), S. 1 11. Luckhom

(2oo7)i Plalchner (2008); Rommelspacher (20OSb)i Helnz, Grelner (2009), S. 82 ff.; Eckert, Bry (2009). s. 163 11. 423

Nicht Gegenstand des Abschnitts sind Ereignishierarchien und ursprüngliche technische Konzepte zur Realisierung von CEP-Systemen von luckham et al. Vgl. dazu luckham (2002a).

121

Ereignisgetriebene Informationssysteme

Uhrzeit ab. Zu diesem Zweck erhalten Ereignisse bei ihrem Eintreten einen Zeitstempel. Darüber hinaus kann in Ereigniswolken eine kausale Beziehung zwischen Ereignissen vorliegen. Wie in Abschnitt 2.6 erläutert wurde, kann ein Ereignis kein anderes Ereignis unmittelbar auslösen. LUCKHAM begreift Ereignisse jedoch als das Ergebnis einer Aktivität, d. h. wenn ein Ereignis A eine Aktivität auslöst, deren Ergebnis Ereignis B ist, so liegt im CEP-Ansatz LUCKHAMS eine kausale Beziehung zwischen den Ereignissen A und B vor.

424

Kausalität ist für

eine adäquate Reaktion erforderlich, wenn ein Ereignis verschiedene Ursachen haben kann.

42

'

In Abbildung 26 ist ein Ausschnitt der Ereigniswolke der Handelsabteilung einer Bank dargestellt.

42

'

Dabei ist anhand eines Pfeils erkennbar, dass die Ereignisse

Kauf und Verkauf von Aktien kausal von den Ereignissen Kauf- bzw. Verkaufsorder abhängen, wenn diese nicht für ein Eigendepot (eines Börsenhändlers) ausgeführt werden. Abbildung 26: Ereigniswolke

- - - - - - - - - - - - ; Z e i t - - - - - - - - - - - -...

424 42S

426

Vgl. Luckham (2002a), S. 95. Vgl. Luckham (2002a), S. 242 f. Das Beispiel wurde in Anlehnung an Luckham (2007), S. 3 erstellt.

122

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Der CEP-Ansatz zielt darauf ab, innerhalb einer solchen Ereigniswolke interes-

sierende Mengen von Ereignissen - sogenannte Ereignismuster - zu erkennen und zu verarbeiten.

42

'

Wesentliche Idee der Verarbeitung ist es, bei Eintreten

der Instanz eines Ereignismusters (durch das CEP-System) ein komplexes Ereignis zu erstellen. Das erstellte komplexe Ereignis signalisiert, dass die Instanz

eines Ereignismusters eingetreten ist und kann im Vergleich zu den enthaltenen Teilereignissen als ein semantisch höheres Ereignis betrachtet werden. Die Beziehung zwischen dem erstellten komplexen Ereignis und den beteiligten elementaren Ereignissen wird daher als Aggregationsbeziehung bezeichnet.

42

•

Die Aggregationsbeziehung beschreibt das Ereignismuster, also die beteiligten Teilereignisse und die angewendeten Operatoren (bspw. Sequenz, Konjunktion, Disjunktion) sowie das resultierende komplexe Ereignis. Dies wird im Folgenden anhand eines Beispiels erklärt. Um Insidergeschäfte zu unterbinden, wird in der obigen Ereigniswolke nach dem Ereignismuster Front Running gesucht.'" Front Running ist eine (illegale) Handelsstrategie unter

Ausnutzung von Informationen über auszuführende Kundenaufträge.

430

Dabei

versucht der Händler vom Preisanstieg einer großen Kauforder (auf engen Märkten) zu profitieren. Dafür kauft er vor der Ausführung der Kauforder Aktien des gleichen Typs für das eigene Depot. Nach der Preissteigerung durch Ausführen der Kauforder verkauft er die Aktien aus seinem eigenen Depot wieder. Das beschriebene Ereignismuster liegt allerdings nur vor, wenn die Ereignisse genau in dieser Reihenfolge eintreten. Wie leicht erkennbar ist, liegt in der Ereigniswolke in Abbildung 26 ein solches Ereignismuster vor (grau hinterlegte Ereignisse). Im CEP-Konzept wird das interessierende Ereignismuster beschrieben, indem zwischen den vier beschriebenen elementaren Ereignissen mittels Sequenz421

428 429 430

Vgl. luckham (2002a), S. 114 f. luckham zählt nur kausale und temporale Beziehungen zu einem Ereignismuster. Diese Darstellung ist nach Auffassung des Verfassers nicht zutreffend. Vielmehr scheint es schlüssig.. die Beziehungen zwischen den elementaren Ereignissen einer Ereigniswolke (lnterebenenbeziehungenl von den Beziehungen zwischen komplexen Ereignissen und Teilereignissen (Intraebenenbeziehungen) zu unterscheiden. Auch luckham verwendet Im Übrigen weitere Operatoren (z. B. das logische Und) zur Musterdeflnltlon. Vgl. luckham (2002a), S. 116. Siehe zum Abstraktionsprinzip der Aggregation Abschnitt 6.1.1. Vgl. luckham (2007), S. 3. Vgl. Gerke (2003), S. 97 f.

123

Ereignisgetriebene Informationssysteme

«)

eine Aggregationsbeziehung zum komplexen Ereignis Front Running aufgebaut wird. In Abbildung 27 ist das komplexe Ereignis Front

Operator

Running aus dem obigen Beispiel in Form eines Ereignisdiagramms modelliert.'" Abbildung 27: Das komplexe Ereignis Front Running als Ereignisdiagramm

Front Running

<

Kauf

Kauf

Verkauf

1000 Aktien X

1000 Aktien x

Eigendepot

Eigendepot

Legende Sequenz-Operator

Die Erzeugung komplexer Ereignisse und somit das reaktive Verhalten von CEPSystemen wird realisiert durch sogenannte Ereignismusterregeln.432 Diese bestehen aus Ereignismuster und Aktionsteil, wobei letzterer nur ausgeführt wird, wenn die Instanz eines Ereignismusters eintritt. Wie bei den kontinuierlichen Anfragen von DSMS besteht auch bei CEP-Systemen die Aktion in der Erstellung eines neuen, hier allerdings komplexen Ereignisses. Im originären Ansatz von LUCKHAM wurden zur Definition von Ereignismusterregeln proprietä-

431 432

Vgl. Rommelspacher (20OSb), s. 79 ff. Vgl. Luckham (2oo2a), S. 119 ff.

124

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

re Sprachen wie STRAW-EPL oder Rapide verwendet.

433

Zur technischen Reali-

sierung werden heute, ähnlich wie bei DSMS, kontinuierliche Anfragen auf multiple Datenströme eingesetzt, die zumeist in einer an SQL angelehnten Syntax formuliert werden.'" Zur Beschreibung von Ereignismustern verfügen s diese Sprachen über einen Muster-Operator." Zur Erkennung von unbekannten Mustern in Datenwolken können darüber hinaus Verfahren der Kloder des Data Minings eingesetzt werden."· Diese werden in der vorliegenden Arbeit jedoch nicht betrachtet. Wesentlicher Kritikpunkt an der technischen Umsetzung durch gleitende Fensteranfragen ist, dass die verwendeten Anfragesprachen zu wenige Musteroperatoren zur Verfügung stellen. Insbesondere das Fehlen kausaler Operatoren ist im Hinblick auf den skizzierten originären CEP-Ansatz problematisch.'"

4.2.4

Beurteilung ereignisgetriebener Informationssysteme

Nachdem im vorigen Abschnitt ereignisgetriebene Informationssysteme und drei verschiedene Ansätze der technischen Realisierung vorgestellt wurden, wird in diesem Abschnitt geprüft, inwiefern die vorgestellten Ansätze den Anforderungen an ein Informationssystem zur Automatisierung von Führungsentscheidungen entsprechen. Zunächst einmal ist zu konstatieren, dass ereignisgetriebene Informationssysteme reaktive Komponenten enthalten und somit die notwendige Anforderung (nA) zur Automatisierung von Führungsentscheidungen erfüllt ist. Obwohl die ECA-Regeln ereignisgetriebener Informationssysteme erstellt werden, um ein Ziel zu erreichen, kann festgestellt werden, dass die ECA-Regeln aller vorgestellten ereignisgetriebenen Informationssysteme diese Ziele nicht

433

434 435

436 431

Luckham (2002a) führt auf S. 116 ff. zunächst die tabellarische Sprache STRAW-EPl und auf S. 145 ff. die weiterentwickelte Sprache Rapide ein. Moderne Varianten der technischen Realisierung stellt Eckert, Bry (2009), S. 163 ff. dar. Die fachkonzeptionelle Modellierung diskutieren Barras et al. (2007): Decker et al. (2007): Rommelspacher (2008b). Alternativen zu dieser technischen Realisierung diskutieren Eckert, Bry (2009), S. 165 f. CCl verfügt bspw. aber Sequenz-, Konjunktion-, Disjunktion und NOT-operatoren. Zudem kann ein Zeitraum angegeben, Innerhalb dessen das Muster erfüllt sein muss, um die Regel auszulösen. Vgl. Aleri (2009), S. 111 ff. Vgl. Eckert, Bry (2009), S. 164; Heinz, Greiner (2009), S. 84 ff. Vgl. luckham (2008).

Ereignisgetriebene Informationssysteme

125

explizieren, d. h. es ist von der ECA-Regel kein Rückschluss mehr auf das ursprünglich intendierte Ziel möglich. Ausgehend von den nicht enthaltenen Zielen, können auch keine Beziehungen zwischen Zielen in ereignisgetriebenen Informationssystemen abgebildet werden. Die Anforderungen hAi und hA2 sind somit nicht erfüllt. Die ECA-Regeln ereignisgetriebener Informationssysteme ermöglichen in ihrem Bedingungsteil die rudimentäre Definition eines einzigen Zustands, welcher 43 wiederum ein Indikator für ein Entscheidungsproblem darstellt. • Das Formulieren mehrerer Zustände ist allerdings nicht möglich. Darüber hinaus enthalten ereignisgetriebene Informationssysteme keine flexiblen Bezugsobjekthierarchien und ermöglichen keine multidimensionalen Sichten auf Geld- und Mengengrößen. Das bedeutet, dass ereignisgetriebene Informationssysteme den Zustand des Realitätsausschnitts nicht adäquat darstellen können und die Anforderungen hA3 und hA4 nicht erfüllen. Der Aktionsteil einer ECA-Regel enthält die Handlungsalternativen "Ausführen" und "Nicht-Ausführen" einer definierten Aktion. Während bei den kontinuierlichen Anfragen von DSMS und CEP-Systemen die Aktion im Erstellen eines neuen Datensatzes und somit eines Ereignisses besteht, ist die Aktion eines aktiven Datenbanksystems deutlich flexibler. Da die Darstellung mehrerer Handlungsalternativen nicht möglich ist, kann die Anforderung hA5 als teilweise erfüllt betrachtet werden. Zudem können ereignisgetriebene Informationssysteme die strukturelle Dynamik im relevanten Realitätsausschnitt nicht beherrschen, da die ECA-Regeln eine invariante Kopplung zwischen Input und Output enthalten und somit nicht auf strukturelle Veränderungen reagieren können. Auch die Anforderung hA6 wird von ereignisgetriebenen Informationssystemen nicht erfüllt. Ereignisgetriebene Informationssysteme können Veränderungen in dem betreffenden Realitätsausschnitt in Form von Ereignissen abbilden und davon ausgehend ECA-Regeln ausführen. Während Ereignisse aktiver Datenbanken im Wesentlichen Datenbankoperationen darstellen, wird in DSMS und CEPSystemen das Eintreffen von neuen Daten in einem Datenstrom bzw. einer

438

Vgl. Abschnitt 3.3.2.

126

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Datenwolke als Ereignis begriffen. Die Anforderung hA7 ist somit grundsätzlich erfüllt, allerdings ist vor einer Implementierung zu prüfen, in welcher Form die Daten vorliegen oder eintreffen. Entsprechend der Anforderung hA8 muss das Informationssystem komplexe Ereignisse abbilden können. Wie bereits dargestellt, können unter Verwendung des jeweiligen Ereignisbegriffes CEP-Systeme und aktive Datenbanken komplexe Ereignisse verarbeiten. DSMS unterstützen dagegen keine komplexen Ereignisse. Zusammenfassend kann festgestellt werden, dass ereignisgetriebene Informationssysteme zur Automatisierung von Ausführungsentscheidungen geeignet sind. Zur Automatisierung von Führungsentscheidungen sind sie dagegen ungeeignet, da sowohl das Zielsystem als auch der relevante Realitätsausschnitt nicht adäquat abgebildet werden.

4.3

Existierende Informationssysteme zur Automatisierung von Führungsentscheidungen

Die aktive Beteiligung von Informationssystemen an Entscheidungen von Führungskräften wurde in den vergangenen Jahrzehnten wiederholt eingefordert und diskutiert.'"' Nachdem in den 1970er Jahren deutlich zu euphorisch die baldige Vollautomation des Managements prognostiziert wurde,440 haben MIU und MANHEIM in den späten 1980er Jahren vorgeschlagen, die modell basierten DSS um aktive Komponenten zu erweitern, um den Entscheidungsprozess zu unterstützen.'41 DSS zielen allerdings auf die Unterstützung von semi- oder unstrukturierten Entscheidungen ab, weshalb die genannten Ansätze lediglich Entscheidungsträger aktiv bei Entscheidungen unterstützen, statt Entscheidungen vollständig zu automatisieren.'42 Darüber hinaus wurde diskutiert, ob (Aus-

439

Nach Dutta et al. (1998) können DSS die Modi Informieren (Informate), Automatisieren (Automate) oder Stimulieren (Stimulate) wahrnehmen.

... Vgl. Simon 11977), S. 33 f. Mertens (1995) . .., Vgl. Manheim (1988), S. 356 ff.; MiIi, Manheim (1989), S. 24 ff.; Raghavan (1991), S. 379 ff.

442

Shim et al. (2002) In etwa zur gleichen Zeit wurde auch die (Teil-)Automatisierung militärischer Entscheidungen in der Uteratur diskutiert. Vgl. Rao et al. (1994), S. 85 ff. sowie die dort angegebene Literatur. Aus diesem Grund bezeichnen Bucklin et al. die Entscheidungsautomatisierung als ..A 2020 Vision". Vgl. Bucklin et al. (1998), S. 235 ff.

Existierende Informationssysteme zur Automatisierung von Führungsentscheidungen

127

führungs-)Entscheidungen von Experten und Fachkräften mithilfe sogenannter Expertensysteme automatisiert werden können. Diese zielen darauf ab, das Wissen menschlicher Experten in domänenspezifischen Anwendungsgebieten zur Verfügung zu stellen. Während für strukturierte Entscheidungen "regelbasierte Expertensysteme" eingesetzt werden, die bereits in Abschnitt 4.2 vorgestellt wurden, werden für sem i- und unstrukturierte Entscheidungen Metho443

Nach vorherrden und Verfahren der Künstlichen Intelligenz (KI) eingesetzt. schender Meinung sind die Systeme für semi- und unstrukturierte Entscheidungen jedoch zu spezialisiert auf eine bestimmte Problemdomäne, um mit ihrer Hilfe Entscheidungen von Experten vollständig automatisieren zu können.

444

Einhergehend mit der Etablierung eines konsolidierten und integrierten analytischen Datenbestands in Form von Data-Warehouse-Systemen sind seit der Jahrtausendwende neue Ansätze zur Automatisierung von Führungsentscheidungen entstanden. Zentrale Idee dieser Ansätze ist es, analytische Informationssysteme um reaktive Komponenten zu erweitern. Eine solche Erweiterung

scheint vielversprechend, da zur Automatisierung der konsolidierte und integrierte Datenbestand analytischer Informationssysteme genutzt wird, den auch Führungskräften zur Entscheidungsfindung nutzen. Ein detailliertes Konzept für derartige Systeme wurde von THALHAMMER et al. unter dem vielfach verwendeten Schlagwort Active Data Warehouse vorgeschlagen (siehe Abschnitt 4.3.1). Des Weiteren sind Ansätze zu nennen, welche darauf abzielen, Ausführungsentscheidungen durch die Nutzung analytischer Datenbestände informatorisch optimal zu unterstützen. Diese Nutzung analytischer Informationssysteme wird in der Literatur unter dem Schlagwort Operational Business Intelligence diskutiert.

44S

Vereinzelt gibt es Ansätze zur automatischen Ausführung solcher ope-

rativen Entscheidungen, wobei die Nutzung der analytischen Daten sich meist

443

444 445

Vgl. Alpar et al. (2008), S. 33 ff. einfahrend zu Expertensystemen. Vgl. zu regelbasierten Expertensystemen: Hayes-Roth (1985). Vgl. Stahlknecht, Hasenkamp (2005), S. 433; Kemper et al. (2006), S. 104. Vgl. Blasum (2006); Bucher (2008); Gluchowski et al. (2009), S. 8 ff.

128

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

auf wenige (historische) Kennzahlen beschränkt.'46 Solche Informationssysteme stellen eine Erweiterung ereignisgetriebener Informationssysteme dar und zielen somit auf die Automatisierung von Ausführungsentscheidungen ab. Aus diesem Grund soll eine ausführliche Darstellung im Folgenden unterbleiben. Abschnitt 4.3 ist folgendermaßen aufgebaut: In Abschnitt 4.3.1 wird zunächst der Begriff Active Data Warehouse eingegrenzt (4.3.1.1) und das Konzept von THALHAMMER et al. vorgestellt (4.3.1.2). Anschließend wird in Abschnitt 4.3.2 analysiert, inwiefern Active-Data-Warehouse-Systeme zur Automatisierung von Führungsentscheidungen geeignet sind.

4.3.1

Active Data Warehouse

4.3.1.1

Begriffliche Grundlegung

Das Schlagwort Active Data Warehouse wird in Literatur und Praxis vielfältig und uneinheitlich verwendet. Einvernehmen besteht lediglich so weit, dass Active-Data-Warehouse-Systeme auf die Verkürzung der Aktionszeit - der sogenannten Latenz - einer Entscheidung abzielen. Die Latenz beschreibt den Zeitraum zwischen dem Eintreten eines Ereignisses und dem Treffen einer entsprechenden Maßnahme.'47 Latenz kann bezogen auf die Unterstützung durch analytische Informationssysteme unterteilt werden in Daten/atenz (Zeitraum zwischen einem Ereignis im operativen Informationssystem und dem Vorliegen der Daten im analytischen Informationssystem), Ana/yse/atenz (Zeitraum zwischen Vorliegen der Daten im analytischen Informationssystem und dem adäquaten Aufbereiten der Information"'), Ent-

scheidungs/atenz (Zeitraum zwischen dem Aufbereiten der Information und der tatsächlichen Entscheidung) und Umsetzungs/aten, (Zeitraum zwischen Entscheidung und tatsächlicher Umsetzung).'" 446

Nguyen et al. nutzen bspw. in dem von ihnen entwickelten ZElESSA-System analytische Informationen zur Entdeckung von Betrugsversuchen, indem ein aktuelles Verhalten historischen Verhaltensmustern gegenüber gestellt wird. Vgl. Nguyen et al. (200Sb); Nguyen et

01. (20050): Nguven et 01. (20070) . ..., Vgl. 5chelp (2006), 5. 426. 448

Bei der Aufbereitung können komplexe Auswertungen durchgefQhrt werden. Bspw. kann das System drohende Nicht-Verfügbarkeits-Situationen berechnen. Vgl. Gluchowski et al. (2008),

5.337. 44!1

Vgl. Hackathorn (2002), S. 24 f.; Kemper et al. (2006), S. 8S ff.

Existierende Informationssysteme zur Automatisierung von Führungsentscheidungen

129

Wie in Abbildung 28 zu sehen ist, können Wertverlust einer Information und die unterschiedenen Latenzarten im Zeitablauf dargestellt werden.

450

Abbildung 28: Latenzarten

Malnahme umpsetzt ...--Diltenlatenz----..LAnalvselatenz----J.EntsCheidungslatenz..!.-umsetzungslatenz-J Zolt + - - - - - - - - - - - A k t i o n s z e i t - - - - - - - - - -. .

Vgl. Kemper et al. (2006), S. 85.

Mithilfe der eingeführten Latenzarten kann die unterschiedliche Verwendung des Schlagworts Active Data Warehouse im Folgenden systematisiert wer-

den.

451

Teilweise werden analytische Informationssysteme, die auf eine Erhöhung der Systemaktualität durch Verringerung der Datenlatenz und der Analyselatenz 45

abzielen, unter dem Schlagwort Active Data Warehouse subsumiert. ' Dabei wurde zunächst die adäquate Nutzung und Steuerung klassischer ETL-Prozesse zur Erhöhung der Systemaktualität und die Sicherstellung von zeitlicher Konsis4SO

451

Die Abbildung ist idealtypisch. Zum einen sind andere Kurvenverläufe denkbar (vgl. Schelp (2006), S. 429) und zum anderen können die Anteile der latenzarten an der gesamten latenz durchaus unterschiedlich groß sein (vgl. Kemper et al. (2006), S. 85). Eine weitere Übersicht über die Verwendung des Begriffs findet sich in Bouattour et al. (2008),

5.21. 452

Karakasldls et al. (2005), S. 28: .. Actlve Data Warehouslng refers to a new trend where data warehouses are updated as frequently as possible, due to the high demands of users for fresh data. Vgl. für ein gleichartiges Verständnis Mertens (2001), S. 289 f.; Töpfer (20OS), S. 9 ff. kommt zu einem ähnlichen Schluss. H

130

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

45 tenz erforscht. ' Neuere Ansätze zielen dagegen insbesondere darauf ab, auch 45 Daten aus Datenströmen zu integrieren. • Der skizzierte Gebrauch des Begriffes ist jedoch abzulehnen, da diese Informationssysteme dem Benutzer keine Aufgaben aktiv abnehmen und Bezeichnungen wie Real-Time oder Right-Time Data Warehousing aussagekräftiger und korrekter sind.

45

'

Systeme, welche auf eine Reduktion der Entscheidungslatenz und Umsetzungslatenz abzielen, übernehmen aktiv bestimmte Aufgaben der Entscheidungsträger und können daher zu Recht als Active-Data-Warehouse-Systeme bezeich45 net werden. • Steht lediglich die Reduktion der Entscheidungs/atenz im Vordergrund, so werden den Entscheidungsträgern entweder auffällige Datenkonstellationen aktiv gemeldet (Alert-Funktion) oder entscheidungsrelevante Informationen (individuell) geliefert.

457

Während eine Alert-Funktion die Ent-

scheidungslatenz verkürzt, indem umgehend auf einen Entscheidungsbedarf hingewiesen wird, steht bei der Lieferung von Informationen die Verkürzung der Entscheidungslatenz durch eine bessere Informationsversorgung im Mit45 telpunkt. • Die weitestgehende Begriffsauffassung des Schlagwortes Active Data Warehouse zielt darüber hinaus auf eine Verkürzung der Umsetzungs/a-

tenz ab, indem Entscheidungen automatisch gefällt und anschließend umgesetzt werden. Entscheidungen werden dabei realisiert, indem geänderte Parameter an die operativen Informationssysteme zurückgegeben werden. Ein solches System kann folgendermaßen definiert werden: »[An] active data warehouse [ ... ] offers the possibility to automate decision making of routine decision tasks and the routinizable elements of sem i-routine tasks. An active data warehouse can export decisions back to OLTP systems directly or after user confirmation.»459

Vgl. Bruckner, Tjoa (2001), s. 241 ff.; Karakasidis et al. (2005), S. 28 ff. Vgl. Nguyen et al. (2007b), S. 26; Polyzotis et al. (2007), S. 476 ff. 455 Vgl. Brobst (2004); Brobst (2004); Kemper et al. (2006), S. 84 ff.; Schelp (2006). Auch der Begriff Real-TIme Business Intelligence wird verwendet. Vgl. Gluchowski et al. (2008), S. 339 ff. 456 Vgl. Gluchowski et al. (2008), S. 347. ", Vgl. Merten. 12001), 5. 290; Felden 12005) 5. 138611.; Felden 12006), 5. 98 11.; Gluchowski et 01. (2008), S. 348. Die technische Realisierung wird bspw. in Cognos (2009) beschrieben. 458 Vgl. Felden (2005), S. 1385 ff. 459 Thalhammer et al. (2001), S. 242. Ein identisches Verständnis wird von Gelhoet, Rieger (2005) vertreten. 453

454

Existierende Informationssysteme zur Automatisierung von Führungsentseheidungen

131

Zu erwähnen ist, dass eine Verringerung von Entscheidungs- und Umsetzungslatenz oftmals eine Erhöhung der Systemaktualität notwendig macht, d. h. eine Active-Data-Warehouse-Lösung kann auch eine Reduktion von Daten- und Analyselatenz erfordern.

460

Im Folgenden soll der weitestgehenden Begriffsauffassung gefolgt werden, das heißt ein Active Data Warehouse unterstützt nicht nur Entscheidungen, sondern führt Entscheidungen von Führungskräften automatisch durch und setzt diese anschließend entsprechend um. Im kommenden Abschnitt wird ein Ansatz von THALHAMMER et al. vorgestellt, welcher der beschriebenen Begriffsauffassung entspricht und in der Literatur sehr detailliert beschrieben ist.

4.3.1.2

Das Active-Data-Warehouse-Konzept von Thalhammer et al.

THALHAMMER et al. schlagen zur Automatisierung von Führungsentscheidungen eine Erweiterung analytischer Informationssysteme um reaktives Verhalten vor. Zu diesem Zweck wird die Data-Warehouse-Architektur um Ana/yserege/n erweitert, welche die Top-Down-Vorgehensweise von Führungskräften bei der Analyse eines Problems und der anschließenden Entscheidungsfindung imitieren.

460 461

461

Vgl. Gluchowski et al. (2008), S. 349 f. Vgl. Thalhammer et al. (2001), S. 248. Vgl. zu dem vorgestellten Active-Data-WarehouseKonzept aueh: Sehrefl, Thalhammer (2000); Thalhammer (2001); Thalhammer, Sehrefl (2002).

132

InformatIonssysteme zur Automatisierung und UntI!rstOtzung \/On (FDhrungs-)Entschl!ldungen

.ECA-Rules that mlmlc the work of an analyst are ca lied analysis ru/es. Analysis rules are modeled from the perspective of an analyst who speeifies (1) the timepoints at which the analysis rule has to be ,.fired·, (2) the cubes, which have to be analyzed (the analysis graph) by using certain criteria for deeision making (the decision steps), and (3) the transaction that will be executed for an entity in an OlTP system if adecision is 462 satisfied.· Analyseregeln reduzieren Entscheidungs- und Umsetzungslatenz mithilfe eines Closed-loop-Ansatzes, indem während eines Analysedurchlaufs (sogenannter ADW-Cycle) zunächst operative Daten In das analytische Informationssystem übertragen werden (ETl-Prozess). Anschließend treffen Analyseregeln Innerhalb des analytischen Informationssystems Entscheidungen, welche zurück in die operativen Informationssysteme exportiert werden.4&3 Die skizzierte Architektur eines solchen Active-Data-Warehouse-Systems ist in Abbildung 29 dargestellt. Abbildung 29: Architektur eines Actllle Data Warehousl!s

,

ActivfI Dala Ws ..,.,.,.., (Pa.sw.) Da ... war"""'-

~V

'1\

~-

~c

f---

• Ru ....

BC9 fi·~· . MB Er ~;(.[j;~

TI T2T3

--- --

f-

t--

Thalhammer et al. (2001). S. 244.

4N Thalhammer (20D1). S. 243. 4M VII. Thalhammer. Sehret! (2002). S.1194.

Existierende Informationssysteme zur Automatisierung von Führungsentscheidungen

133

Analyseregeln besitzen ähnlich wie ECA-Regeln eine dreigliedrige Grundstruktur, die aus folgenden Bestandteilen besteht:• •

Der Ereignisteillegt fest, wann eine Analyseregel ausgeführt wird. Der Analyseteil definiert, welche multidimensionalen Datenräume zu untersuchen sind und nach welchen Kriterien eine Entscheidung getroffen wird.

•

Der Aktionsteillegt fest, welche Transaktion im operativen Informationssystem ggf. ausgelöst wird.

Die Grundstruktur wird von THALHAMMER et al. weiter detailliert und die Beziehungen zwischen der ECA-Grundstruktur und den Detaillierungen ist in Tabelle 7 dargestellt. Zudem wird die Funktion der einzelnen Bestandteile beschrieben.

464

Die Unterteilung in Ereignisteil, Analyseteil und Aktionsteil ist eine Interpretation des Verfassers, um Analyseregeln zu strukturieren.

134

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Tabelle 7: Struktur von Analyseregeln

Grundstruktur

Bestandteile nach

Funktion

Thalhammer et al. Ereignis

Ereignis

Legt fest, wann eine Analyseregel ausge-

führt wird. Analyse

Primäre Dimensionsebene

Definiert eine für die gesamte Analyseregel gültige unveränderliche Dimensionsebene.

Primäre Bedingung

Spezifiziert, für welche Instanzen der primären Dimensionsebene eine Analyse durchzuführen ist.

Analysegraph

Definiert den multidimensionalen Datenraum

in

Form

mehrerer Hypercube-

Sichten, die Top-Down analysiert werden. Entscheidungsschritte

Definieren für jede Hypercube-Sicht ein Konditionalprogramm, mit deren Hilfe eine Entscheidung getroffen wird.

Aktion

Aktion

Legt die auszuführende Aktion im opera-

tiven Informationssystem fest. Vorbedingungen und

Die Vorbedingungen stellen sicher, dass

Konfliktlösungsmechanimus

die Daten im operativen Informationssystem während eines Analysedurchlaufs nicht verändert wurden. Ein Konfliktlösungsmechanismus ist notwendig, um konkurrierende Änderungen von Analyseregeln zu behandeln.

Im Folgenden werden die Bestandteile nach

THALHAMMER

et al. entsprechend

der eingeführten Struktur dargestellt: Ereignisteil. Der Ereignisteillegt fest, wann eine Analyseregel ausgeführt wird. Es ist zu unterscheiden zwischen absoluten temporalen Ereignissen (z. B. 200904-17), periodisch wiederkehrenden temporalen Ereignissen (z. B. Quartalsen-

Existierende Informationssysteme zur Automatisierung von Führungsentscheidungen

135

de) und relativen temporalen Ereignissen (z. B. 20 Tage nach einem Ereignis im Quellsystem).465 Da THALHAMMER et al. ein objektorientiertes Datenbanksystem als operatives Quellsystem verwenden, beziehen sich relative temporale Ereignisse auf den Aufruf einer Methode im objektorientierten Datenbanksystem.

46

'

Analyseteil. Im Analyseteil werden die in einem Data Warehouse vorgehaltenen Daten analysiert, um eine Entscheidung herbeizuführen. Die primäre Dimensionsebene definiert eine für die gesamte Analyseregel gültige unveränderliche Dimensionsebene. Im Ansatz von THALHAMMER definiert diese zugleich das Objekt, das ggf. im operativen Quellsystem zu ändern ist. Mithilfe der primären Dimensionsebene werden zur Bildung von HypercubeSichten sogenannte Nest-Operationen durchgeführt, deren Ergebnis physisch zweidimensionale Tabellen sind, in denen durch Wiederholungsgruppen logisch mehrere Dimensionen dargestellt werden. THALHAMMER et al. verwenden in ihrem begleitenden Fallbeispiel als primäre Dimensionsebene die Artikelebene der Produktdimension.

467

Eine Tabelle mit der primären Dimensions-

ebene Produkt ist in Tabelle 8 dargestellt: Tabelle 8: Primäre Oimensionsebene Produkt Produkt

Quartal (Jahr 20081

Filiale Marburg

Ratenkredit 12M

Quartal 1

148

Quartal 2

120

Quartal 3

102

Quartal 4

98

Quartal 1

25

Quartal 2

23

Quartal 3

27

Quartal 4

23

Annuitätenkredit 48M

465

466 467

Ereignisse im operativen Quellsystem können nicht unmittelbar Analyseregeln anstoßen, da die Ereignisse erst in das Oata Warehouse geladen werden müssen. Aus diesem Grund sind relative temporale Ereignisse von großer Bedeutung Im Konzept von Thalhammer. Vgl. Thalhammer (2001), 5. 86. Vgl. Thalhammer et al. (2001), S. 252; Thalhammer (2001), S. 85 f. Vgl. Thalhammer et al. (2001), S. 249.

136

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Die primäre Bedingung legt fest, welche Instanzen der primären Dimensionsebene zu analysieren sind. Die primäre Bedingung wird als boolescher Ausdruck formuliert, der sich auf ein beschreibendes Merkmal der primären Dimensionsebene bezieht.'58 Instanzen der primären Dimensionsebene werden von der Analyseregel untersucht, wenn die primäre Bedingung erfüllt ist. Ausgehend von der primären Dimensionsebene und der primären Bedingung führt die Analyseregel multidimensionale Analysen durch. Die Vorgehensweise orientiert sich dabei an einer inkrementellen Spezifizierung, wie sie Führungskräfte zur Analyse allgemeiner Probleme anwenden.'" Die Analyse beginnt mit einer hoch aggregierten Hypercube-Sicht. Wenn für eine zu untersuchende Instanz basierend auf den Daten der vorliegenden Hypercube-Sicht keine Entscheidung getroffen werden kann, wird eine detailliertere Hypercube-Sicht erstellt und die Untersuchung fortgesetzt. Die beschriebene Spezifizierung kann je nach Problem mehrfach erfolgen. Um die beschriebene Vorgehensweise zu realisieren, enthält eine Analyseregel einen Analysegraph, der die für eine multidimensionale Analyse notwendigen Hypercube-Sichten definiert.

47o

Der Startpunkt des Analysegraphs, d. h. die am

meisten aggregierte Sicht auf den Hypercube einer Analyseregel, wird als .reot cube· bezeichnet.

471

Die weiteren Sichten auf den Hypercube des Analyse-

graphs werden inkrementeIl mithilfe von OLAP-Operationen von diesem .reot cube" abgeleitet. Der Analysegraph stellt somit eine Hierarchie von HypercubeSichten dar, die bei einer Analyse von oben nach unten zu durchlaufen ist. Neben dem Analysegraph sind für die multidimensionale Analyse Entscheidungsschritte notwendig. Jeder Entscheidungsschritt führt die Analyse einer

Hypercube-Sicht des Analysegraphen durch und entscheidet für jede Instanz in Abhängigkeit von definierten Bedingungen über die Handlungsalternativen (1) Aktionsteil der Analyseregel ausführen (TRIGGER ACrlON), (2) Aktionsteil der Analyseregel nicht ausführen oder (3) Analyse mit einer detaillierteren Hyper-

468

469 470 471

Vgl. Thalhammer et al. (2001), S. 253. Ein solches Merkmal kann bspw. die Zugehörigkeit zu einer bestimmten (Produkt-)Kategorie sein. Vgl. Abschnitt 3.3. Vgl. auch Thalhammer et al. (2001), S. 256. Thalhammer et al. bezeichnen die Sichten fälschlicherweise als Hypercubes. Der "root cubeN kann aus einem global verfügbaren Hypercube (global cube) abgeleitet werden. Vgl. Thalhammer et al. (2001), S. 257 f.

Existierende Informationssysteme zur Automatisierung von Führungsentscheidungen

137

cube-Sicht fortsetzen (DETAIL ANALYSIS).47' Handlungsalternative (2) kann ausgedrückt werden als ~ (TRIGGER ACTION V DETAIL ANALYSIS), sodass nur (1) und (3) in der korrespondierenden Hypercube-Sicht überprüft werden müssen.'" Die beschriebene Funktionsweise der multidimensionalen Analyse mithilfe eines aus mehreren Hypercube-Sichten bestehenden Analysegraphs und Entscheidungsschritten ist in Tabelle 9 am Beispiel der Hypercube-Sicht SalesMarburgThisYear und des zugehörigen Entscheidungsschrittes dargestellt. Tabelle 9: Hypercube SalesMarburgThlsYear und zugehöriger Entscheldungsschrltt

Hypercube-Sicht

Entscheidungsschritt

SalesMarburgThisYear

TRIGGER ACTION (TA)

Sales< 100

DETAIL ANALYSIS (DA)

lO1<Sales<400

TA

Produkt Ratenkredit 12M

2008

468

Ratenkredit 24M

2008

187

Annuitätenkredit 48M

2008

98

x x x

Für das Produkt "Ratenkredit 24M" muss die Analyse noch weiter fortgesetzt werden. Denkbar wäre ein Drill-down auf die Dimensionsebene Quartal (vgl. Tabelle 8). Der korrespondierende Entscheidungsschritt könnte bspw. eine Aktion auslösen, wenn der Trend auf Quartalsbasis nach unten zeigt.47. Aktionsteil. Analyseregeln automatisieren Entscheidungen, indem Daten im operativen Informationssystem verändert oder nicht verändert werden. Der

Aktionsteil einer Analyseregel legt die auszuführende Transaktion im operativen Informationssystem fest. THALHAMMER et al. beschränken sich auch hier auf den Aufruf oder Nichtaufruf einer Methode für die Instanz eines Objektes mit zugehörigen Parametern.

472 473 474 475

475

Darüber hinaus enthält der Aktionsteil weitere

Vgl. Thalhammer et al. (2001), S. 262 f. Vgl. Thalhammer et al. (2001), S. 263 f. Vgl. Thalhammer (2001), S. 248 ff.; Thalhammer, Schrefl (2002), S. 1200. Vgl. Thalhammer et al. (2001), S. 254.

138

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

Vorbedingungen und einen Konfliktlösungsmechanismus. Die Vorbedingungen müssen sicherstellen, dass sich die Daten des operativen Quellsystems nicht während der Entscheidungsfindung wesentlich verändert haben.

47

'

Entschei-

dungskonflikte können entstehen, wenn mehrere Entscheidungen für ein und dieselbe Instanz eines Objektes von unterschiedlichen Analyseregeln getroffen werden. Um solche Konflikte zu lösen, wird eine Konflikttabelle verwendet, die festlegt, welche Aktion im Kollisionsfall auszuführen ist.

477

Nachdem nun Analyseregeln und ihre Struktur dargestellt wurden, wird im Folgenden eine Analyseregel dargestellt, welche in einem Kreditinstitut verwendet werden könnte. Die Analyseregel ChangePriceOfProducls überprüft jeweils am Ende eines Jahres die Absatzzahlen von Produkten der Kategorie Konsumentenkredite. Wenn der Absatz einer Filiale unter 100 fällt, so soll der Zinssatz (relativ) um 5 % gesenkt werden. Wenn der Absatz größer als 100, jedoch kleiner als 400 ist, so soll der Absatz auf Quartalsbasis analysiert werden. Ist ein negativer Trend erkennbar, soll der Zins ebenfalls um (relativ) 5 % abgesenkt werden. Zur Definition von Analyseregeln schlagen THALHAMMER et al. eine formale Sprache vor.

47 •

In Tabelle 10 ist die dargestellte Analyseregel in der vorgeschla-

genen formalen Sprache formuliert.

476

477 471

Vgl. Thalhammer et al. (2001), S. 254 f. Z. B. kann das Objekt nicht mehr vorhanden sein. Das Erkennen von nicht endenen Regelschleifen stellt in dem beschriebenen Konzept kein Problem dar, da während eines ADW-Durchlaufes keine neuen Ereignisse Im Active Data Warehouse erzeugt werden. Vgl. Thalhammer et al. (2001), S. 255. Die Syntax wird ausführlich in Thalhammer (2001) eingeführt.

Existierende Informationssysteme zur Automatisierung von Führungsentscheidungen

139

Tabelle 10: Analyseregel ChangePriceofProducts DEFINE ANALYSIS RULE ChangePriceOfProducts FOR a:Product [Articlel ON eoy:EndOfYear IF (a.category - ,Konsumentenkredite') USING CUBES SalesMarburgThisYear Primary p AS SLICE t.yid - eoy.yearid FROM SalesArticlesMarburgYears; SalesMarburgThisYearQuarters AS DRILLDOWN T TO Quarter FROM SalesMarburgThisYear; BEGIN ANALYSE SalesMarburgThisYear TRIGGER ACTION IF Sales <100 DETAIL ANALYSIS IF Sales < 400; ANALYSE SalesMarburgThisYearQuarters TRIGGER ACTION IF TREND (sl.Sales, s2.Sales, s3.Sales, s4.sales) = 'DOWN' FOR CELLS sI WHERE eoy.1stQua, s2 WHERE eoy.2ndQua, s3 WHERE eoy.3rdQua, s4 WHERE eoy.4thQua; TO EXECUTE (a@OLTP) .changePrice WITH ratio

0.95

END ChangePriceOfProducts

Das auslösende Ereignis der Analyseregel ist ein periodisch wiederkehrendes temporales Ereignis und löst jeweils zum Jahresende die Analyseregel aus (ON eoy:EndOfVear). Die primäre Dimensionsebene ist in der dargestellten Analyseregel die Artikelebene der Produktdimension (a:Product [Article]). Die zu analysierenden Instanzen der primären Dimensionsebene werden durch die primäre Bedingung (IF a.category = ,Konsumentenkredite') eingeschränkt. Der Analysegraph beginnt mit dem Statement USING CUBES. Die beiden definierten Hypercube-Sichten werden jeweils von einem zugehörigen Entscheidungsschritt in der oben dargestellten Art und Weise analysiert. Die Definition eines Entscheidungsschrittes beginnt mit ANALYSE und enthält den Namen der zu analysierenden Hypercube-Sicht und die Handlungsalternativen TRIGGER ACTION und DETAIL ANALYSIS. Der Aktionsteil der Analyseregel beginnt mit TO

140

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

EXECUTE und senkt mithilfe der Methode changePrice und dem übergebenen Parameter 0.95 den Zins um relativ 5 %. In seiner Dissertation führt THALHAMMER einige Erweiterungen für Analyseregeln ein.

47

'

Während der Ereignisteil um die Bildung logischer Ereignisse erwei-

tert wird, wird der Aktionsteil um flexible Parameter erweitert.

480

Im Analyse-

teil werden für Entscheidungsschritte die Bedingungen von TRIGGER ACTION und DETAIL ANALYSIS flexibilisiert.

481

Zum einen können (irresolute) Bedingun-

gen formuliert werden, die eine weitere Analyse durch Führungskräfte erfordern und zum anderen können auch "schwache" Bedingungen formuliert werden, deren Ergebnis vorläufige Entscheidungen sind. Darüber hinaus führt THALHAMMER aus, wie innerhalb einer Analyseregel eine Gesamtentscheidung, die sich aus vielen Teilentscheidungen zusammensetzt, zu implementieren iSt.

482

4.3.2

Beurteilung des Active-Data-Warehouse-Ansatzes

In den vorigen Abschnitten wurden existierende Ansätze zur Automatisierung von Führungsentscheidungen dargestellt. Dabei wurden der Active-DataWarehouse-Ansatz im Allgemeinen und der Ansatz von THALHAMMER et al. im Speziellen dargestellt. Im Folgenden wird der Ansatz von THALHAMMER et al. den Anforderungen an ein Informationssystem zur Automatisierung von Führungsentscheidungen gegenübergestellt. Zunächst einmal ist zu konstatieren, dass Active-Data-Warehouse-Systeme reaktive Komponenten enthalten und somit die notwendige Anforderung (nA) an Informationssysteme zur Automatisierung von Führungsentscheidungen erfüllen. Darüber hinaus ist festzustellen, dass die beschriebenen Analyseregeln im Prinzip aus mehreren sequenziell hintereinander geschalteten ECA41g

480

481 482

Vgl. Thalhammer (2001), S. 113 ff. Die hierarchische Organisation bzw. inkrementelle Spezifizierung von Entscheidungen wird zwar von Thalhammer genannt und begründet, jedoch nicht eingeführt. Vgl. Thalhammer (2001), S. 123 ff. Logische Ereignisse unterscheiden sich von komplexen Ereignissen, da sie nicht mit den dargestellten Aggregationsoperatoren erstellt werden, sondern deklarativ bspw. mithilfe einer SOl-Anfrage erstellt werden. Flexible Parameter können bspw. bestimmen, dass der Preis bei einem AbsatzrQckgang um 5 % gesenkt wird. Wenn aber der RQckgang kleiner als 5 % Ist, wird der Preis nur um 2,5 % gesenkt. Vgl. Thalhammer (2001), S. 118 ff. Vgl. Thalhammer (2001), S. 121 ff. und S. 141 ff.

Existierende Informationssysteme zur Automatisierung von Führungsentscheidungen

Regeln bestehen.

48

'

141

Jeder Entscheidungsschritt lässt sich auflösen in zwei ECA-

Regeln und auch die aufgelösten ECA-Regeln mehrerer Entscheidungsschritte können sequenziell geschaltet werden.

484

Analyseregeln beinhalten daher -

ebenso wie die ECA-Regeln ereignisgetriebener Informationssysteme - keine expliziten Ziele. Implizit spielen Ziele dagegen insbesondere bei der Formulierung von Entscheidungsschritten eine Rolle. Ausgehend von der fehlenden expliziten Zielformulierung in Analyseregeln, sind auch Zielsysteme nicht in Analyseregeln enthalten, d. h. die Anforderungen hAi und hA2 werden von 485 Active-Data-Warehouse-Systemen nicht erfüllt. Zustände können in Analyseregeln in dem Bedingungsteil der Entscheidungsschritte dargestellt werden. Dadurch, dass jeder einzelne Entscheidungsschritt bereits zwei Bedingungen und eine Analyseregel normalerweise mehrere Entscheidungsschritte enthält, können Zustände in Analyseregeln insgesamt besser als in einer ECA-Regel abgebildet werden. Das Active-Data-WarehouseKonzept ermöglicht durch die Definition einer primären Dimensionsebene in Verbindung mit der skizzierten Nest-Operation die multidimensionale Betrachtung von Wert- und Mengengrößen. Durch die Definition des Analysegraphs können darüber hinaus Bezugsobjekthierarchien definiert werden. Einschränkend muss allerdings hinzugefügt werden, dass die verwendeten HypercubeSichten ex ante definiert werden müssen und die Flexibilität durch die primäre Dimensionsebene

eingeschränkt

ist.'"

Trotzdem

können

Active-Data-

Warehouse-Systeme die Zustände des Realitätsausschnitts adäquat wiedergeben und erfüllen daher die Anforderungen hA3 und hA4. Handlungsalternativen können von Analyseregeln in ihrer ursprünglichen Form kaum besser dargestellt werden als von ECA-Regeln. Zwar können innerhalb eines Entscheidungsschrittes neben den Alternativen TRIGGER ACTION und keine Aktion noch die Alternative DETAIL ANALYSIS gewählt werden. In toto gibt es allerdings auch in einer Analyseregel nur die Alternativen "Aktion aus... Vgl. Luhmann (2000), S. 263 f. ... Vgl. Thalhammer, Schrefl (2002), S. 1218 f. 485 Ein interessanter Ansatz zur hierarchischen Organisation von Entscheidungen ist sicherlich die In Fn. 479 genannte Inkrementelle Spezlfzlerung von Entscheidungen. Je nachdem, wie eine solche Lösung realisiert wird, könnte dies möglicherweise ein Ansatz zur Implementierung von Zweck-Mittel-Schemata darstellen. Vg!. Thalhammer (2001), S. 123 ff. 486 Dies wird in Abschnitt 5.2.2.1 noch einmal detaillierter beschrieben.

142

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

führen" und "Aktion nicht ausführen" und die Anforderung hAS wird demnach nur eingeschränkt erfüllt.

48

'

Die strukturelle Dynamik im relevanten Realitätsausschnitt kann dagegen von Active-Data-Warehouse-Systemen nicht ausreichend beherrscht werden, da die Analyseregeln im Prinzip sequenziell hintereinander geschaltete ECARegeln darstellen. Diese sind aufgrund ihrer invarianten Kopplung zwischen Input und Output nicht für strukturelle Dynamik geeignet. Die Anforderung hA6 ist somit nicht erfüllt. Im dargestellten Active-Data-Warehouse-Konzept von

THAlHAMMER

et al. wer-

den Veränderungen im relevanten Realitätsausschnitt mithilfe von Ereignissen signalisiert. Zu bemängeln ist allerdings, dass lediglich temporale Ereignisse und Methoden-Ereignisse aus objektorientierten Quelldatenbanken als Auslöser verwendet werden können. Die Integration relationaler DatenbankEreignisse und Ereignisse aus Datenströmen und -wolken ist in der bisherigen Konzeption von Analyseregeln nicht vorgesehen. Die Anforderung hA7 ist somit nur teilweise erfüllt. Die Definition und Verwendung komplexer Ereignisse wird im Konzept von THAlHAMMER

nicht unterstützt. Die Anforderung hAB ist somit als nicht erfüllt zu

betrachten. ZWIschenfazit

4.4

In Kapitel 3 wurde mit den Führungsentscheidungen das Handlungssystem dieser Arbeit dargestellt. Es wurde gezeigt, dass Führungsentscheidungen im Sinne dieser Arbeit grundsätzlich automatisierbar sind. Darüber hinaus wurden ausgehend von praktischen und theoretischen Überlegungen Anforderungen an ein Informationssystem zur Automatisierung von Führungsentscheidungen formuliert. Damit kann das erste Forschungsziel als erreicht angesehen werden. In Kapitel 4 wurde das Informationssystem des Forschungsgegenstandes dargestellt. Zu diesem Zweck wurden existierende Vorschläge zur Automatisierung

481

Eine deutliche Weiterentwicklung für die Implementierung von Handlungsalternativen wäre die Implementierung flexibler Entscheidungsparameter. Vgl. Thalhammer (2001), S. 123.

143

ZWischenfazit

und Unterstützung von Führungsentscheidungen vorgestellt und den in Kapitel 3 formulierten Anforderungen gegenübergestellt. Selbst das explizit zur Automatisierung von Führungsentscheidungen konzipierte Active-DataWarehouse-Konzept von THALHAMMER et al. weist dabei erhebliche Defizite auf. •

Sämtliche vorgestellten Informationssysteme können mit der strukturellen Dynamik des Realitätsausschnitts nicht umgehen. Die Ursache hierfür ist darin zu sehen, dass alle betrachteten Informationssysteme ausschließlich auf ECA-Regeln als Erweiterung von Konditionalprogrammen basieren.

•

Die vorgestellten Informationssysteme sind nicht in der Lage, die Ziele und das Zielsystem von Entscheidungssituationen explizit abzubilden. Ausgehend von der zentralen Bedeutung von Zielen für Führungsentscheidungen und deren häufigen Änderung scheint die Automatisierung von Führungsentscheidungen ohne die explizite Berücksichtigung von Zielen und Zielsystem nicht möglich.

•

Darüber hinaus ist die Ereigniskomponente des vorgestellten Active-DataWarehouse-Konzepts insgesamt nicht zufriedenstellend. Erstens ist die Beschränkung auf objektorientierte bzw. objektrelationale Datenbanktechnologie nicht wünschenswert. Zweitens sollten auch Ereignisse aus Datenströmen und -wolken in der Ereigniskomponente berücksichtigt werden können und drittens müssen komplexe Ereignisse als Auslöser von Analyseregeln implementierbar sein.

488

Die beschriebenen Defizite werden in Kapitel 5 bei dem Entwurf des Frameworks zur Automatisierung von Führungsentscheidungen berücksichtigt. Ein weiterer Kritikpunkt an dem Active-Data-Warehouse-Konzept ergibt sich aus der Tatsache, dass bisher keine semi-formalen Modellierungssprachen existieren, welche die Kommunikation mit Führungskräften unterstützen. Die in Abschnitt 4.3.1.2 dargestellte formale Sprache zur Definition von Analyseregeln scheint aufgrund ihrer Komplexität zur direkten Kommunikation mit Füh-

4l1li

Ein weiterer Kritikpunkt an der Ereigniskomponente findet sich bei Gelhoet, Rieger (200S), S. 1408 und S. 1410 f. Sie fordern Ereignisse, die sich auf die Datenkonstellation im Data Warehouse beziehen. Dieser Ansatz wird hier nicht weiter verfolgt.

144

Infonnationssysteme zur Automatisierung und Unterstützung von (Führungs-)Entscheidungen

rungskräften nicht geeignet.'" Dies ist als problematisch einzuschätzen, da bei der Automatisierung von Führungsentscheidungen das Wissen von Führungskräften unbedingt genutzt werden muss. Dieser Kritikpunkt wird in Kapitel 6 berücksichtigt, indem semi-formale domänen spezifische Modellierungssprachen vorgeschlagen und konstruiert werden, die mit dem AvFe-Framework

harmonieren.

489

Auch Thalhammer (2001), S. 231 betont die Notwendigkeit einer semi-formalen Sprache zur Beschreibung von Analyseregeln.

Teil 111: Erkenntnisangebot

In Teil 111 wird das Erkenntnisangebot dieser Arbeit entwickelt und dargestellt. Dabei wird den in Teil 11 ermittelten Entwicklungsdefiziten durch die Konstruktion von Artefakten begegnet. In Kapitel 5 wird ein Framework zur Automatisierung von Führungsentscheidungen entwickelt. Dieses Framework gibt eine grundsätzliche Orientierung, wie Führungsentscheidungen automatisiert werden können und unterbreitet einen Vorschlag, mit dem die erkannten Entwicklungsdefizite bisheriger Vorschläge zur Automatisierung von Führungsentscheidungen beseitigt werden. Gegenstand von Kapitel 6 ist die Auswahl und Konstruktion semi-formaler domänenspezifischer Modellierungssprachen, welche zur Erstellung der Teilmodelle des in Kapitel 5 beschriebenen Frameworks verwendet werden können. Zu diesem Zweck wird zunächst ein sprachbasiertes Metamodell entwickelt, das die abstrakte Syntax des Frameworks beschreibt. Mithilfe dieses Metamodells werden anschließend Modellierungssprachen beurteilt und konstruiert.

5

Framework zur Automatisierung von Führungsentscheidungen

Im vorliegenden Kapitel wird ein Framework zur Automatisierung von Führungsentscheidungen entworfen, welches im Folgenden verkürzend als AvFeFramework bezeichnet wird. Dafür werden in Abschnitt 5.1 die systemtheoretischen Gestaltungsoptionen zur Beseitigung der erkannten Entwicklungsdefizite bisheriger Vorschläge aufgezeigt. In Abschnitt 5.2 wird schließlich gezeigt, wie mithilfe der sogenannten Programmverschachtelung Führungsentscheidungen automatisiert werden können. Die (wissenschaftliche) Begründung eines konzeptionellen Frameworks ist problematisch und lediglich durch Kriterien wie Zweckmäßigkeit oder Ange490

messenheit möglich. Im Rahmen dieser Arbeit erfolgt die Begründung des AvFe-Frameworks daher mithilfe eines Prototyps und eines Konformitätstests in Kapitel 7 bzw. KapitelS. 5.1

Gestaltungsoptionen zur Weiterentwicklung von Entscheidungsprogrammen

Im folgenden Abschnitt werden ausgewählte Gestaltungsoptionen zur Weiterentwicklung von Entscheidungsprogrammen aufgezeigt, um verschiedene Möglichkeiten zur Beseitigung der ermittelten Defizite darzulegen. Die Überlegungen entstammen dabei zu weiten Teilen der soziologischen Systemtheorie von LUHMANN und zielen auf die Beherrschung der strukturellen Dynamik und 491 die Berücksichtigung von Zielen in Entscheidungsprogrammen ab. Die genannten Schwächen der Ereigniskomponente sind dagegen technischer Art und werden in Abschnitt 5.2.1 wieder aufgegriffen. Der Abschnitt ist folgendermaßen aufgebaut: Zunächst wird in Abschnitt 5.1.1 dargestellt, wie Konditionalprogramme die Dynamik eines Realitätsausschnitts absorbieren können. Anschließend wird in Abschnitt 5.1.2 mit der Programmverschachtelung eine weitere systemtheoretische Gestaltungsoption präsentiert, bei der Zweck- und Konditionalprogramme ineinander verschachtelt

4!lO

491

Vgl. Frank (2006), S. 53. Vgl. einführend zur soziologischen Systemtheorie bspw. Luhmann (1984): Luhmann (2002).

J. Rommelspacher, Automatisierung von Führungsentscheidungen, DOI 10.1007/978-3-8348-8251-6_5, © Vieweg + Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

148

Framework zur Automatisierung von Führungsentscheidungen

werden. In Abschnitt 5.1.3 werden die Gestaltungsoptionen knapp zusammengefasst und es wird deren Eignung zur Beseitigung der erkannten Defizite diskutiert. 5.1.1

Die Absorption von Dynamik durch Konditionalprogramme

Im folgenden Abschnitt wird gezeigt, welche Möglichkeiten es gibt, damit Konditionalprogramme die Dynamik des Realitätsausschnitts weitgehend absorbie-

ren können. Dabei ist zu unterscheiden zwischen stabilen und instabilen Systemen.

Wenn der dynamische Realitätsausschnitt ein stabiles System darstellt, so ist es als Vorteil von Konditionalprogrammen einzuschätzen, dass sie in diesem dynamischen Realitätsausschnitt mithilfe der konditionalen Formulierung konstante Entscheidungen treffen.'" Konditionalprogramme werden unabhängig von einem Zeitpunkt definiert, d. h. sie werden ausgeführt, wenn der im Bedingungsteil definierte Zustand eintritt, ohne dass definiert ist, wann und wie oft dieser Zustand eintreten wird.'" Dies verdeutlicht

LUHMANN:

.Anders als bei

Zweckprogrammen beruht die systemerhaltende Funktion der Routine nicht auf Flexibilität in der Auswahl verschiedener Handlungsalternativen als Mittel, sondern auf der Indifferenz gegenüber einer unberechenbaren Zeitfolge von Informationen ....• Durch die konstante Entscheidungsleistung und die beschriebene zeitliche Unabhängigkeit können Konditionalprogramme dafür verwendet werden, um das dynamische System in eine gewünschte Richtung zu lenken. Der soeben beschriebene Vorteil kann allerdings zu einem Nachteil werden, wenn es sich bei dem relevanten Realitätsausschnitt um ein instabiles System handelt und somit strukturelle Dynamik vorliegt. In einem solchen Realitätsausschnitt können Konditionalprogramme inadäquat werden.'" Zum einen 492 Vgl. luhmann (1964), S. 8 ff.; Luhmann (1975), S. 119 ff. 49' Vgl. luhmann (1964), S. 8 f. Konditionalprogramme können auch durch extrem seltene Situationen ausgelöst werden. Luhmann (2000), S. 271 nennt als Beispiele Mobilisierungsprogramme für den Fall eines Krieges oder Katastrophenschutzprogramme. Die Herausforderung bel selten auszufahrenden Konditionalprogrammen Ist, dass Menschen diese vergessen können. Daher müssen sie regelmäßig geübt und ins Gedächnis gerufen werden.

494 495

Luhmann (1964), S. 12; Luhmann (1975), S. 122. Vgl. Luhmann (1964), S. 25 ff.

Gestaltungsoptionen zur Weiterentwickl ung von Entscheidu ngsprogrammen

149

besteht die Gefahr, dass die auslösenden Informationen nicht mehr zeitgemäß sind und zum anderen können möglicherweise die Aktionen des Entscheidungsprogramms nicht zu den gewünschten Ergebnissen führen, weil sich die Wirkbeziehungen zwischen den Variablen entscheidend verändern können. Im weiteren Verlauf des Abschnitts werden daher Möglichkeiten vorgestellt, wie strukturelle Dynamik durch Konditionalprogramme absorbiert werden kann. Bisher wurden Konditionalprogramme dargestellt, als gäbe es eine völlig invariante Kopplung zwischen dem auslösenden Zustand und der definierten Reaktion.'" Ist dies der Fall, so bestehen bei der Anwendung von Konditionalprogrammen weder beim Input noch bei der Reaktion Freiheitsgrade - gleich ob das Programm nun von einem Menschen oder von einem Computer ausgeführt wird. Eine solche Ausgestaltung von Konditionalprogrammen führt dazu, dass auf die strukturelle Dynamik des Realitätsausschnitts nicht entsprechend reagiert werden kann. Ausgehend von dieser Feststellung ist es naheliegend, die skizzierte Unbeweglichkeit des Entscheidungsganges zu relativieren, um strukturelle Dynamik absorbieren zu können. Diese Flexibilisierung von Konditionalprogrammen - in der Terminologie

LUHMANNS

als Elastizität bezeichnet - kann

erreicht werden, indem entweder der auslösende Zustand, die darauf folgende Reaktion oder beides variabler gestaltet wird.

49

'

Die erste Gruppe der Flexibilisierungsmöglichkeiten bezieht sich auf den auslösenden Zustand des Konditionalprogramms. Zunächst zu erwähnen ist die Generalisierung, die in praktisch allen Konditionalprogrammen enthalten ist. Diese besteht bei einem Konditionalprogramm darin, dass der auslösende Zustand durch wenige kennzeichnende Merkmale beschrieben wird."· Durch diese Abstraktion werden andere (für die Entscheidung nicht relevante) Merkmale ausgeblendet und deren Dynamik somit absorbiert. Wenn die definierten Merkmale zweier unterschiedlicher Zustände identisch sind, so können beide Zustände mit einer gleichbleibenden Reaktion beantwortet werden.'" Eine zweite Möglichkeit, den auslösenden Zustand zu flexibilisieren besteht darin,

496

497 498 499

Vgl. Luhmann (1964). S. 12; Luhmann (1975), S. 122. Diese Unbeweglichkeit ist laut March, Simon (1958), S.141Jedoch nicht das Ziel von Entscheidungsprogrammen. Luhmann (1964), S. 12 ff.; Luhmann (1975), S. 122 ff; Hoftjann (2007), S. 35. Das Abstraktionsprinzip der Generalisierung wird in Abschnitt 6.1.1 erläutert. Vgl. Luhmann (1964), S. 14.

Framework zur Automatisierung von Führungsentscheidungen

150

den Zustand teilweise unbestimmt zu beschreiben. In einem solchen Fall sind weitere Interpretationen erforderlich, um zu entscheiden, ob ein auslösender 50o Diese Subsumption - wie sie bspw. in den Zustand vorliegt oder nicht. Rechtswissenschaften bei der Zuordnung von einem Sachverhalt zu einer Rechtsnorm stattfindet - kann allerdings nicht automatisch durchgeführt werden. Drittens kann der auslösende Zustand flexibilisiert werden, indem der Bedingungsteil des Konditionalprogramms durch ein sogenanntes Regelsol Ausnahme-Schema ergänzt wird. Der auslösende Zustand wird dabei derart suprakonditioniert, dass die Aktion nur durchgeführt wird, wenn die genannten Ausnahme-Bedingungen nicht vorliegen. LUHMANN weist darauf hin, dass dieses Regel-Ausnahme-Schema in Konditionalprogrammen das funktionale Äquivalent zur Suche nach Handlungsalternativen im Rahmen von Zweckprogrammen 50 darstellt. ' Eine zweite Gruppe der Flexibilisierungsmöglichkeiten zeichnet sich dadurch aus, dass die Reaktion von Konditionalprogrammen teilweise unbestimmt defiso niert oder lediglich ein grober Rahmen vorgegeben wird. , MARCH und SIMON bezeichnen diese Flexibilität in Programmen als Ermessensspielraum (discretion).s04 Um bei einer derartigen outputorientierten Unbestimmtheit Entscheidungen treffen zu können, sind die Unbestimmtheitsstellen des Programms auszufüllen. Dies kann implizit durch sich einspielende Verhaltensweisos sen oder auch explizit durch Kriterien oder Zwecke erfolgen. Wenn die Reaktion einem bestimmten Zweck genügen muss, so besteht die Unbestimmtheit darin, dass die genauen Mittel, d. h. die Art und Weise, wie der Zweck zu erreichen ist, nicht festgelegt ist. Eine solche Integration von Zweckprogrammen in SllO

Bei Konditionalprogramme wird auch als Programmverbindung bezeichnet. einer Programmverbindung sind Zweckprogramme als untergeordneter Be-

500

Vgl. Luhmann (1964), S. 13 f. Eine weitere, hier allerdings nicht diskutierte, Möglichkeit die

Empfangselastizität eines Konditionalprogramms zu erhöhen

besteht darin,

bei der

502

Subsumption entstehende Zweifel für eine Weiterentwicklung des Programms zu verwenden. Vgl. Luhmann (1964), S.14. Vgl. Luhmann (2000), S. 264. Vgl. Luhmann (2000), S. 264 f.

503

Vgl. Luhmann (1964), S. 15 f.

SOl

505

Vgl. March, Simen (1958), 5.147. Vgl. March, Simen (1958), S. 147 f.; Luhmann (1964), S. 15 f.; Luhmann (2000), S. 264.

506

Vgl. Drepper (2003), Fn. 82.

5IM

Gestaltungsoptionen zur Weiterentwickl ung von Entscheidu ngsprogrammen

standteil

ZU

151

betrachten, d. h. die Struktur des Entscheidungsprogramms orien-

tiert sich an der grundsätzlichen Struktur von Konditionalprogrammen und flexibilisiert lediglich die Reaktion auf den auslösenden Zustand, indem die Reaktion einem angegebenen Zweck genügen muss.'·7 Ehe in Abschnitt 5.1.3 darauf eingegangen wird, inwiefern die dargestellten Erweiterungen von Konditionalprogrammen zur Beseitigung der Entwicklungsdefizite beitragen können, wird im nächsten Abschnitt zunächst die sogenannte Programmverschachtelung als weitere systemtheoretische Gestaltungsoption dargestellt. 5.1.2

Integration von Konditional- und Zweckprogrammen durch Programmverschachtelung

Zweckprogramme orientieren sich - wie bereits in Abschnitt 3.3.1 erläutert an einem Ziel. Mit welchen Mitteln das Ziel erreicht wird, bleibt zu einem gewissen Maß offen. Anders als Konditionalprogramme werden Zweckprogramme nicht durch einen bestimmten Zustand ausgelöst, sondern das enthaltene Ziel muss bis zu einem bestimmten Zeitpunkt erreicht sein. Durch diese Konstruktion erlangen Zweckprogramme ein andere Art Invarianz und Elastizität als Konditionalprogramme: Während das Programm invariant gegenüber den erwünschten Programmwirkungen ist, besteht bei der Auswahl der Mittel (Handlungsalternativen) Flexibilität.'" Durch diese Ausgestaltung können Zweckprogramme mit der strukturellen Dynamik des Realitätsausschnitts deutlich besser umgehen als Konditionalprogramme: Zum einen können inadäquate Zweckprogramme leicht ermittelt werden, indem nach Ausführung des Programms die erzielte Wirkung durch Ex-post-Vergleich zwischen Ziel und Zustand geprüft wird. Zum anderen können in instabilen dynamischen Systemen auftretende Entscheidungsprobleme relativ leicht identifiziert werden, indem gemäß einem Zweckprogramm regelmäßig ein Abgleich zwischen Ziel und Zustand stattfindet. Die genannten Vorteile von Zweckprogrammen in instabilen Systemen sind allerdings bei der Automatisierung von Führungsentscheidungen nur dann zu Luhmann spricht hier vom Strukturgesetz der Routine, das einzuhalten ist. Vgl. Luhmann (1964). S. 16. sos Vgl. Luhmann (2000), S. 266.

Sf17

Framework zur Automatisierung von Führungsentscheidungen

152

nutzen, wenn Zweckprogramme so beschrieben werden, dass sie automatisch

ausgeführt werden können.

509

Dies ist jedoch nur möglich, wenn das enthalte-

ne Ziel das Handeln unmittelbar und eindeutig festlegt, da ansonsten die Flexibilität bzgl. der zu verwendenden Mittel zu groß ist.''' Eine indirekte Vorgehensweise zur Einschränkung der Flexibilität und somit zur nAutomatisierbarkeit" von Zweckprogrammen ist die sogenannte Programmverschachtelung. Die Grundidee der Programmverschachtelung ist die hierar-

chische Organisation von Entscheidungsprogrammen, wobei die hierarchisch untergeordneten Programme dabei jeweils der Erfüllung des übergeordneten Zweckprogramms dienen. 511 Bei einer einjochen Programmhierarchie werden die enthaltenen Programme in der Form einer einfachen Zweck-Mittel-Beziehung programmiert. Dabei fungieren Konditionalprogramme als Handlungsalternativen (Mittel) des übergeordneten Zweckprogramms, wobei ein Konditionalprogramm gewählt wird, welches das Ziel (des Zweckprogramms) zufriedenstellend erreicht.''' Eine solche Verschachtelung bezeichnet

LUHMANN

als »eine Möglichkeit (... ], durch

die sich die Verwaltung umweltabhängig und doch elastisch organisieren kann.»'" Während die Umweltabhängigkeit durch die (untergeordneten) Konditionalprogramme sichergestellt wird, gewährleistet das übergeordnete Zweckprogramm die notwendige Flexibilität, um in einem dynamischen und instabilen System das Ziel zu erreichen. Eine einfache Programmhierarchie ist übersichtsartig in Abbildung 30 dargestellt.

509

Vgl. Luhmann (1966), S. 38.

511

Vgl. Luhmann (1966), S. 38; Luhmann (2000), S. 268 f. Eine derartige Hierarchisierung deuten March und Siman an, wenn sie die Tatsache beschreiben, dass Programme durch höherrangige Programme verändert werden können. Vgl.

512

Vgl. luhmann (1964), S. 11 f. und S. 16. Eine weitere Möglichkeit der Integration von

513

Konditionalprogramme in ZWeckprogramme ist in Luhmann (1966), S. 39 beschrieben. Dort wird die Wahl der Mittel eines ZWeckprogramms durch untergeordnete Konditionalprogramme eingeschränkt, bspw. darf fOr den ZWeck A das Mittel B2 nur gewählt werden, wenn die Bedingung Cl erfOlit Ist. Bel ErfClllung der Bedingung Cl Ist das untergeordnete Konditionalprogramm allerdings nicht zwingend auszuführen. Die beschriebene Hierarchisierung wird hier nicht weiter diskutiert. Luhmann (1964), S. 11.

510

March, Siman (1958), S. 150; luhmann (1964), S. 11 f. und S. 16.

Gestaltungsoptionen zur Weiterentwickl ung von Entscheidu ngsprogrammen

153

Abbildung 30: Einfache Programm hierarchie

Zweckprogramm

1C"''''llanolprGt:romm (riclrUktiv)

-Auslösender Zustand

Reaktion

Konditionalprogramm (nicht aktiv)

Lq;ende Aktivieren bzw. Deaktivieren eines geeigneten Konditionalprogramms

•

Überwachung der Zielerreichung

Mit der dargestellten Form der Programmverschachtelung ist es möglich, Konditionalprogramme derart zu programmieren, dass diese indirekt einem Ziel folgen, indem bei einem Problem jeweils das adäquate Konditionalprogramm auf auslösende Zustände reagiert. Die Natürlichkeit einer Programmhierarchie aus Konditionalprogrammen und übergeordneten Zweckprogrammen wird klar, wenn berücksichtigt wird, dass alle Konditionalprogramme originär für einen bestimmten Zweck erstellt werden, der wiederum als Zweckprogramm formuliert werden kann. Eine Programmhierarchie kann außerdem dahingehend interpretiert werden, dass Zweckprogramme (als Führungsentscheidungen) einen Rahmen für Konditionalprogramme (Ausführungsentscheidungen) vorgeben. Wie in Abschnitt 3.2.2 besprochen, ist dies typisch für Handlungsalternativen von Führungsentscheidungen. Wie bereits dargestellt, sind die Ziele von Führungskräften jedoch oftmals zu allgemein formuliert. Die Abweichung zwischen einem allgemeinen Ziel und

Framework zur Automatisierung von Führungsentscheidungen

154

korrespondierendem Zustand führt zu allgemeinen Problemen.'14 Zur Programmierung allgemeiner Probleme werden mehrgliedrige Programmhierarchien vorgeschlagen, bei denen mithilfe von mehreren Zweckprogrammen das 51

allgemeine Problem nach und nach spezifiziert wird. ' Dabei dienen die jeweils untergeordneten Zweckprogramme als Mittel eines übergeordneten Zweckprogramms. Wenn das untergeordnete Zweckprogramm keine unmittelbare Entscheidung mittels eines Konditionalprogramms ermöglicht, so wird das allgemeine Problem mithilfe wiederum untergeordneter Zweckprogramme weiter spezifiziert usw.

S1

•

Die Definition der einzelnen Zweckprogramme kon-

kretisiert darüber hinaus unklare Ziele, sodass beide Formulierungsdefekte von Zielen der betrachteten Personengruppe mittels mehrgliedriger ProgrammhieS17

rarchien zu beheben sind. Zudem ist festzustellen, dass mehrgliedrige Programmhierarchien Zweck-Mittel-Ketten beinhalten und somit auch die kausale Verkettung von Zielen abbilden können (vgl. Anforderung hA2). Die dargestellte Organisation kann auch deshalb strukturelle Dynamik absorbieren, weil - funktionale Äquivalenz vorausgesetzt - einzelne Glieder der Programmhierarchie getrennt beurteilt und geändert werden können. Die Komplexität des betroffenen Realitätsausschnitts kann in mehrgliedrigen Programmhierarchien ebenfalls gut absorbiert werden, wenn die Konditionalprogramme dazu in der Lage sind, komplexe Ereignisse zu verarbeiten (vgl. Anforderung hA8). Abschließend wird angemerkt, dass in Organisationen eine hohe Übereinstimmung zwischen der hierarchischen Beziehung von Organisationsmitgliedern und den hierarchischen Beziehungen zwischen Programmen zu beobachten ist. Ein wesentlicher Anteil der Programme von Mitarbeitern höherer Managementebenen besteht somit in der Änderung und Erstellung von Programmen für untergeordnete Managementebenen.

514 515

516 517

S18

Vgl. Abschnitt 3.2,2. Vgl. Luhmann (1973), S. 292 ff. Vgl. Luhmann (1973), S. 292. Verborgene Mehrfachziele massen allerdings vor einer Automatisierung entsprechend

dekomponiert werden, da sonst in Ermangelung einer eindeutigen Zielgröße kein 511

Entscheidungsproblem identifiziert werden kann. Vgl. March, Siman (1958), S. 150.

Gestaltungsoptionen zur Weiterentwickl ung von Entscheidu ngsprogrammen

5.1.3

155

Schlussfolgerungen aus den systemtheoretischen Gestaltungsoptionen für das AvFe-Framework

In dem vorliegenden Abschnitt werden die beschriebenen Gestaltungsoptionen knapp zusammengefasst und es wird erörtert, inwiefern diese zur Beseitigung der dargestellten Entwicklungsdefizite verwendeten werden können. In Abschnitt 5.1.1 wurde diskutiert, welche Möglichkeiten der Flexibilisierung es bei Konditionalprogrammen gibt. Die erste Gruppe der Flexibilisierungsmöglichkeiten setzt dabei an dem auslösenden Zustand an und die zweite Gruppe flexibilisiert die Reaktion des Programms. Während aus der ersten Gruppe die Generalisierung praktisch in jedem Konditionalprogramm enthalten ist und somit auch bei der Automatisierung genutzt werden kann, ist die unbestimmte Beschreibung des Zustands für eine Automatisierung nicht praktikabel zu nutzen. Das Regel/Ausnahme-Schema ist eine technisch realisierbare Erweiterung zur Flexibilisierung von Konditionalprogrammen. Allerdings wird sie im Folgenden nicht weiter betrachtet, da sie für die Absorption struktureller Dynamik nicht geeignet erscheint. Die Programmverbindung zur Flexibilisierung der Reaktion ist für die Beseitigung der beschriebenen Defizite ein interessanter Ansatz, da der Programmverbund explizite Ziele enthält und sich die Reaktion an diesen Zielen orientiert. Durch diese Unbestimmtheit im Programmverbund kann die Reaktion an die strukturelle Dynamik des Realitätsausschnitts angepasst werden. Um diesen Programmverbund automatisieren zu können, müssten allerdings die

Unbestimmtheitsstellen des enthaltenen Zweckprogramms vollständig ausgefüllt werden. Dies würde letztlich zu einer starren Programmkonstruktion führen, welche wiederum nicht adäquat auf die strukturelle Dynamik des Realitätsausschnitts reagieren kann. Bei der Programmverschachtelung werden Entscheidungsprogramme derart hierarchisch organisiert, dass untergeordnete Programme als Mittel eines übergeordneten Zweckprogramms fungieren. Die Kopplung zwischen den Programmen ist bei einer Verschachtelung deutlich geringer als bei einer Programmverbindung, da letztlich sowohl enthaltene Zweck- als auch Konditionalprogramme in ihrer ursprünglichen Form erhalten bleiben. Mithilfe der in einer Programmhierarchie enthaltenen Ziele kann die strukturelle Dynamik eines

Framework zur Automatisierung von Führungsentscheidungen

156

Realitätsausschnitts absorbiert werden, indem durch Abgleich zwischen Ziel und Zustand Entscheidungsprobleme identifiziert werden. Zudem kann expost die Adäquanz von (isolierten) Programmen geprüft werden. Mehrgliedrige Programmhierarchien sind darüber hinaus zur Automatisierung von Führungsentscheidungen gut geeignet, weil sie die Spezifizierung allgemeiner Probleme ermöglichen. Zusammenfassend kann festgestellt werden, dass die Programmverschachtelung in Form einer mehrgliedrigen Programmhierarchie zur Beseitigung der Entwicklungsdefizite ein vielversprechender Ansatz ist und daher im Folgenden verfolgt wird. Automatisierung von Führungsentscheidungen durch Programmverschachtelung: Das AvFe-Framework

5.2

Im folgenden Abschnitt wird ein Framework zur Automatisierung von Führungsentscheidungen mittels mehrgliedriger Programmhierarchien präsentiert. Da dabei die informationstechnische Realisierung im Vordergrund steht und somit Ereignisse als Auslöser der Zweck- und Konditionalprogramme erforderlich sind, werden die Bestandteile einer Programmhierarchie im Folgenden als Zweckregeln und ECA-Regeln bezeichnet. Um die Komplexität der Darstellung zu reduzieren, wird zunächst in Abschnitt 5.2.1 eine einfache Programmhierarchie präsentiert, ehe in Abschnitt 5.2.2 die Modelle einer mehrgliedrigen Programmhierarchie vorgestellt werden.

5.2.1

Modelle einer einfachen Programmhierorchie

5.2.1.1

Zweckregeln

Zur technischen Realisierung von Zweckprogrammen werden im Folgenden sogenannte Zweckregeln eingesetzt. Eine Zweckregel ist - in Analogie zum Begriffspaar ECA-Regel/Konditionalprogramm - die Erweiterung eines Zweckprogramms um ein auslösendes temporales Ereignis.'l9 Da eine Zweckregel insbesondere zur Automatisierung regelmäßig wiederkehrender Entscheidungen eingesetzt wird, handelt es sich üblicherweise um ein periodisches tempo-

rales Ereignis. In Abbildung 31 ist die Zweckregel, welche durch dieses Ereignis ausgelöst wird, als EPK dargestellt.

51g

Vgl. zu temporalen Ereignissen Abschnitt 2.6.

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

157

Abbildung 31: Zweckregel

temporales Ereignis

Zielerreichung prüfen

, - - - - - - { XOR ) - - - ,

Ziel nicht erreicht

Ziel erreicht

Entscheidung

Führungsentscheidungen werden - wie alle anderen Entscheidungen - durch Entscheidungsprobleme ausgelöst. Wenn eine Zweckregel von einem definierten (periodischen) temporalen Ereignis ausgelöst wird, besteht somit die erste Funktion der Regel darin zu überprüfen, ob ein Problem vorliegt, das eine Entscheidung erfordert. Da Zweckregeln Ziele enthalten, können diese Probleme identifizieren, indem die Zielerreichung geprüft wird. Dafür wird kontrolliert, ob für den Inhalt des Ziels, welcher durch sachlichen Geltungsbereich und zeitlichen Bezug multidimensional beschrieben wird, das angestrebte Ausmaß

Framework zur Automatisierung von Führungsentscheidungen

158

erreicht ist. Das Ausmaß wird im Folgenden durch Zielwerte (Soll-Daten) dargestellt, die mit dem korrespondierenden Zustand (Ist-Daten) verglichen werden.

52

•

Die Herkunft der Daten für den Soll-Ist-Abgleich zur Identifikation von

Entscheidungsproblemen ist Gegenstand von Abschnitt 5.2.1.2. Als Ergebnis der Funktion Zielerreichung prüfen resultiert entweder das Ereignis Ziel nicht erreicht oder das Ereignis Ziel erreicht. Wenn letzteres der Fall ist, so ist die

Zweckregel bereits beendet. Wenn dagegen das Ereignis Ziel nicht erreicht eintritt, so liegt ein Entscheidungsproblem vor. Im Rahmen der dadurch ausgelösten Funktion Entscheidung ist in einer Programmhierarchie von der Zweckregel zu prüfen, ob eine

ECA-Regel vorliegt, die genau das identifizierte Problem lösen und das angestrebte Ziel erreichen kann. Wenn eine derartige ECA-Regel ermittelt wird, so wird diese von der Zweckregel entsprechend aktiviert und die Zweckregel wird mit dem Ereignis Entscheidung getroffen beendet. Wie die skizzierte Funktion Entscheidung detailliert vonstatten geht und welche weiteren Modelle dafür erforderlich sind, ist Gegenstand von Abschnitt 5.2.1.3.

521

Anschließend wird in

Abschnitt 5.2.1.4 die Anbindung von ECA-Regeln und die Integration der Teilmodelle zu einer Programmhierarchie dargestellt. Vermag die Funktion Entscheidung keine geeignete ECA-Regel zu ermitteln, so kann das Problem von der Zweckregel nicht automatisch gelöst werden (Ereignis keine Entscheidung möglich). Aufgrund der erkannten Formulierungsdefekte von Führungsentscheidungen wird weiter angenommen, dass das identifizierte Problem zu allgemein ist und somit spezifiziert werden muss. Die Spezifizierung erfolgt mittels einer mehrgliedrigen Programmhierarchie und ist Ge-

genstand von Abschnitt 5.2.2. Die Spezifizierung ist in dem Modell als EPKProzessschnittstelle dargestellt.

Bei Zielwerten ist die Besonderheit zu erwähnen, dass bei bestimmten Zielen sowohl das Unter- als auch Überschreiten eines Zielwertes ein Problem darstellen kann, welches eine Entscheidung erfordert. 521 Wie das Svmbol rechts unterhalb der Funktion HEntscheidung" in Abbildung 31 zeigt, ist die Funktion detaillierter beschrieben. Diese DetailIierung wird in der Modellierungspraxis auch als 520

Hinterlegung oder Verfeinerung bezeichnet.

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

5.2.1.2

159

Daten zur Prüfung der Zielerreichung

Zur (automatischen) Identifikation von Entscheidungsproblemen müssen Zweckregeln auf Informationen über den Zustand (Ist-Daten) und das verfolgte Ziel (Soll-Daten) zugreifen können. Darüber hinaus müssen sich die beiden Informationen auf einen identischen Sachverhalt beziehen, d. h. die verglichenen Kennzahlen sind durch identische Elemente qualitativ zu beschreiben. Da Zweckregeln auf die Automatisierung von Führungsentscheidungen abzielen, ist es naheliegend, die Ist-Daten des entsprechenden Realitätsausschnitts analytischen Informationssystemen zu entnehmen. Da die Daten gemäß Anforderung hA4 multidimensional zu qualifizieren sind, bietet sich die Nutzung existierender Hypercubes an. Innerhalb der Daten von Hypercubes kann darüber hinaus mithilfe der beschriebenen OLAP-Operationen flexibel navigiert werden, sodass auch die Anforderung hA3 bzgl. flexibler Bezugsobjekthierarchien zur Beschreibung des komplexen Realitätsausschnitts durch analytische Informationssysteme erfüllt wird. Die Soll-Daten zur Beschreibung der intendierten Ziele sind in analytischen Informationssystemen typischerweise nicht enthalten. Da die Soll-Daten allerdings durch die gleichen Elemente wie die Ist-Daten zu beschreiben sind, ist es naheliegend, die Dimensionen der Ist-Daten ganz oder zumindest teilweise auch zur Beschreibung der Soll-Daten zu verwenden. Die einfachste Möglichkeit zur Verwendung identischer Dimensionen bei der Beschreibung der SollDaten besteht in einer Erweiterung des Hypercubes, aus dem die Ist-Daten stammen, um eine weitere Kennzahl. Die Kennzahl stellt den Inhalt des Ziels 52

dar und enthält Zielwerte, die das Ausmaß des verfolgten Ziels beschreiben. ' Sachlicher Geltungsbereich und zeitlicher Bezug des Ziels werden durch sachliche Dimensionen bzw. die Zeitdimension entsprechend beschrieben.'" Eine aufwändigere Möglichkeit zur Verwendung identischer Dimensionen besteht

52l

m

Das Ausmaß wird im Folgenden ausschließlich in Form von Zielwerten beschrieben. Maximierungs- bzw. Minimierungsregel sowie niveaubezogene Ausmaße werden nicht beschrieben. Vgl. Abschnitt 3.1.1. Sowohl Bulos (1996), S. 33 ff. als auch Totok (2000), S. 124 f. schlagen eine Faktendimension "SzenarioN mit den Elementen Plan, Ist und Abweichung vor. Neben dem betrachteten Zeitraum ist noch eine Angabe zum zeitlichen Bezug erforderlich, d. h. bis wann das Ziel zu erreichen ist. Diese Angabe ist in dem temporalen Ereignis einer Zweckregel enthalten.

160

Framework zur Automatisierung von Führungsentscheidungen

darin, für die Soll-Daten einen eigenständigen Hypercube aufzubauen und in diesem die Dimensionen der Ist-Daten (wieder) zu verwenden. Derartige Dimensionen, die von mehreren Hypercubes verwendet werden, werden in Anlehnung an KIMBALL und Ross als "conformed dimensions" bezeichnet.'24 Die letztgenannte Möglichkeit wird im Folgenden aufgrund des höheren Aufwandes nicht weiter diskutiert. Nach diesen Ausführungen wird im Folgenden das multidimensionale Datenmodell einer Zweckregel nach dem AvFe-Framework entwickelt. Ausgangspunkt ist das bereits in Abschnitt 4.1.2 vorgestellte konzeptionelle MER-Modell eines Hypercubes, welches in Abbildung 32 dargestellt ist. Das Modell enthält die Kennzahlen Anzahl (lSn und Anzahl (SOLL). Abbildung 32: Datenmodell mit 5011- und Ist-Daten

Um die zu analysierenden Daten vollständig zu definieren sind in zweifacher Hinsicht Detaillierungen erforderlich. Zum einen muss festgelegt werden, weIche Dimensionsebene zur Beschreibung der Daten auf Typebene verwendet 524

Vgl. Kimball, Ross (2002), S. 82 ff.

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

161

werden. Es muss also für jede zur Beschreibung verwendete Dimension die interessierende Dimensionsebene festgelegt werden. Bspw. können aus den Dimensionen Vertriebsort, Produkt und Zeit die Ebenen Alle Regionen, Kotegorie und Monot ausgewählt werden. Diese ausgewählten Dimensionsebenen sind in Abbildung 32 grau hinterlegt. Zum anderen müssen die Daten des Hypercubes auch auf Ausprägungsebene beschrieben werden. Nur so ist es möglich die qualifizierenden Informationen innerhalb eines Hypercubes eindeutig zu spezifizieren.'25 Mögliche Hierarchieelemente als Ausprägungen der gewählten Dimensionsebenen müssen in einer Zweckregel definiert werden. Im dargestellten Fall könnten die Ausprägungen (in Klammern die zugeordneten Typen) bspw. Gesamtvertrieb (Alle Regionen), Konsumentenkredite (Kategorie) und Juli 2009 (Monat) lauten. Da die verwendete Modellierungssprache die Modellierung auf Ausprägungsebene jedoch nicht vorsieht, unterbleibt diese Darstellung einstweilen. Zweckregeln werden - ausgelöst durch periodische temporale Ereignisse - in regelmäßigen, bspw. monatlichen Abständen ausgeführt. Bei der Überprüfung der Zielerreichung ist daher der betrachtete Zeitraum entsprechend zu variieren. Wenn sich das Ziel jeweils auf den vergangenen Monat bezieht, so muss das Hierarchieelement aus der Zeitdimension entsprechend aktualisiert werden. Somit liegen nun die Daten für die Identifikation eines isolierten Entscheidungsproblems vor. Wenn ein zu allgemeines Problem vorliegt, das (mittels einer mehrgliedrigen Hierarchie) zu spezifizieren ist, sind wiederum entsprechende Soll- und Ist-Daten erforderlich. Die Generierung von Daten zur Überprüfung der Zielerreichung in mehrgliedrigen Programmhierarchien ist Gegenstand von Abschnitt 5.2.2.2. 5.2.1.3

DetailIierung der Funktion Entscheidung

In diesem Abschnitt wird die Funktion Entscheidung einer Zweckregel ausführlich beschrieben und diskutiert, wie Zweckregeln geeignete ECA-Regeln auswählen. Zur formalen Darstellung werden dabei Entscheidungsmodelle ver-

525

In der multidimensionalen Modellierung Ist die Ausprägungsebene - anders als bel der sonstigen Datenmodellierung - von wesentlicher Bedeutung und muss somit explizit modelliert werden. Vgl. Gabriel, Gluchowski (1998), S. 497; Goeken (2006), s. 149 f.; Bauer, Günzel (2009), s. 191.

Framework zur Automatisierung von Führungsentscheidungen

162

wendet.

52

•

In Anlehnung an das Grundmodell der Entscheidungstheorie ist der

wesentliche Bestandteil eines Entscheidungsmodells die Ergebnismatrix, weIche im vorliegenden Fall die Ergebnisse der verfügbaren ECA-Regeln in Abhängigkeit von definierten Zuständen darstellt.

527

In Tabelle 11 ist übersichtsartig

in einer Ergebnismatrix dargestellt, wie sich die Ergebnisse einer Entscheidung beim Einsatz verschiedener ECA-Regeln in Abhängigkeit von dem Zustand sJ verändern. Tabelle 11: Ergebnismatrix von ECA-Regeln mit Zuständen

s,

5,

S,

"

ECA,

-0,13

-0,08

0,00

0,20

ECA,

-0,13

·0,14

·0,05

0,01

ECA,

-0,08

-0,02

0,05

0,10

ECA,

0,01

0,05

0,09

0,15

Die Ergebnismatrix ist nach dem Grundmodell der Entscheidungstheorie um eine Entscheidungsregel zu ergänzen. Hat der Entscheidungsträger keine vollständigen Informationen über den eintretenden Zustand und die Eintrittswahrscheinlichkeiten der Zustände, so werden entsprechende Entscheidungsregeln wie bspw. die Maximin-Regel eingesetzt. Das Problem derartiger Entscheidungsregeln besteht darin, dass es für eine automatische Auswahl von ECARegeln praktisch wertlos ist, weil bei gleich bleibender Ergebnismatrix und Entscheidungsregel jedes Mal die gleiche ECA-Regel ausgewählt wird. Die Ursache ist darin zu sehen, dass die Zustände im Grundmodell als Zufallskomponente fungieren, über die keine weiteren Informationen vorliegen. Insofern ist es für eine Automatisierung notwendig, Informationen über die Zustände in das Entscheidungsmodell zu integrieren.

526

Vgl. Abschnitt 3.1.2.

521

Es handelt sich im vorliegenden Fall um eine Entscheidung unter Ungewissheit.

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

163

BAMBERG et al. führen aus, dass der Kenntnisstand bzgl. des Zustands mithilfe

eines sogenannten Informationssvstems verbessert werden kann.

52

'

Zur Ab-

grenzung gegenüber anderen Informationssvstemen dieser Arbeit werden diese im Folgenden als Informationssvstem-Modell bezeichnet. Ein Informationssvstem-Modell besteht aus einer Menge potenzieller Informationen V" V2, ... , Vk über die möglichen Zustände sJ mit j=1, ... , m und einer Struktur.'29 Jede

Information

VI

mit I = 1, ..., k repräsentiert dabei eine Konstellation mehrerer

Kennzahlen, die jeweils durch Kennzahlenbereiche konkretisiert sind. Die Struktur eines Informationssvstem-Modells wird beschrieben durch die bedingte Wahrscheinlichkeit Pjl. Letztere definiert die Wahrscheinlichkeit, dass die Information VI empfangen wird, wenn der Zustand Sj vorliegt.53.

PI' =P(y,lsJ Unter der Annahme, dass sich die Informationen gegenseitig ausschließen und exakt eine Information vorliegt, summieren sich die bedingten Wahrscheinlichkeiten eines Zustands auf 1. Im Folgenden wird von einem vollkommenen Informationssvstem-Modell ausgegangen, das über ebenso viele Zustände wie Informationen verfügt und in dem die bedingten Wahrscheinlichkeiten alle entweder den Wert 0 oder 1 annehmen.'" In Verbindung mit der obigen Annahme, dass sich die bedingten Wahrscheinlichkeiten auf 1 summieren, ist in einem solchen Modell jeder Information mit der Wahrscheinlichkeit 1 genau ein Zustand zuzuordnen. Ein derartiges Informationssvstem-Modell ist übersichtsartig in Tabelle 12 dargestellt.

S28

529 530

531

Bamberg et al. (2008), S. 19 ff. Vgl. auch Adam (1996), S. 33 f. Vgl. Bamberg et al. (2008), S. 19. Vgl. Bamberg et al. (2008), S. 19. Vgl. Bamberg et al. (2008), S. 19 ff. für unvollkommene Informationssysteme. Grundsätzlich ist die Annahme eines vollkommenen Informationssystems nicht unproblematisch. Letztlich ist die Annahme eines derartigen Systems jedoch zum einen notwendig, um ECA-Regeln automatisch aktivieren zu können. Zum anderen kann argumentiert werden, dass auch Entscheidungsträger gleichartig vorgehen. Sie bewerten subjektiv die vorliegenden Informationen und schließen auf Basis dieser Informationen auf einen bestimmten Zustand. Das Informationssystem ist somit ein subjektiv erstelltes Modell, das eingehende Informationen jeweils einem Zustand zuordnet.

164

Framework zur Automatisierung von Führungsentscheidungen

Tabelle 12: Vollkommenes Informationssystem-Modell

y,

y,

y,

y,

5,

1

0

0

0

5,

0

1

0

0

"

0

0

0

1

5,

0

0

1

0

Um Informationssystem-Modelle einsetzen zu können, müssen Kennzahlen und Kennzahlenbereiche definiert werden, die eine Information repräsentieren. Grundsätzlich können beliebig viele Kennzahlen für eine Information definiert werden und die Kennzahlen können auch aus beliebigen Quellen stammen. Da im vorliegenden Fall bereits Soll- und Ist-Daten für den Realitätsausschnitt einer Zweckregel zur Verfügung stehen, wird die Kennzahl Zielerreichungsgrad (ZE) verwendet, und verschiedene Bereiche dieser Kennzahl repräsentieren unterschiedliche Informationen. Mögliche Kennzahlenbereiche sind in Tabelle 13 dargestellt.

53

'

Tabelle 13: Kennzahlenbereiche

y,

y,

y,

y,

ZE < 0,9

0,9 HE S 0,9S

1,05 s ZE S 1,1

l,l
Wenn jeweils eine Information durch genau einen Kennzahlenbereich repräsentiert wird, ist es möglich, dass in dem Informationssystem-Modell direkt die Kennzahlenbereiche abgetragen werden. Darüber hinaus ist es möglich, die Ergebnismatrix und das Informationssystem-Modell zu integrieren. Zu diesem Zweck werden in den Spalten die Kennzahlenbereiche abgetragen. In den Zeilen werden die Handlungsalternativen, im vorliegenden Fall also ECA-Regeln, dargestellt. In einem Zwischenschritt können zunächst die Ergebnisse abgetragen werden. Je nachdem, in welchem Kennzahlenbereich die Kennzahl tatsäch532

Der Bereich zwischen -0,95 und 1,05 wurde nicht definiert, da er sehr eng an dem angestrebten Ziel liegt und hier die Interpretation erfolgt, dass kein Entscheidungsproblem vorliegt

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

165

lich liegt, wird aus der betroffenen Spalte der Ergebnismatrix die Alternative entsprechend einer zu definierenden Entscheidungsregel ausgewählt.''' Da in der Ergebnismatrix in Tabelle 11 die (negativen und positiven) Abweichungen von einem angestrebten Ziel dargestellt sind und eine möglichst geringe Abweichung anzustreben ist, wird hier eine modifizierte Minimierungsregel angewendet, die in der betroffenen Spalte den betragsmäßig niedrigsten Wert auswählt. Wenn die zu wählende Alternative mit einer 1 und die nicht zu wählenden Alternativen mit einer 0 dargestellt werden, ergibt sich die in Tabelle 15 dargestellte Aktivierungsmatrix. In Klammern sind jeweils die Ergebnisse dargestellt. Tabelle 14: Aktivierungsmatrix

ZE < 0,9

0,9 S ZE S 0,95

1,OS S ZE S 1,1

1,1< ZE

ECA,

0(oG,131

O(oG,osl

1(0.001

0(0,201

ECA,

O(oG,nl

O(oG,14)

O(oG,oS)

1(0,011

EtA,

O(oG,DIII

1(oG,02)

O(o.osl

0(0,10)

ECA,

1(0,01)

O(o,os)

O(o,ogl

0(0,151

Die Zweckregel prüft den entsprechenden Zielerreichungsgrad und aktiviert anschließend die entsprechende ECA-Regel. Gleichzeitig deaktiviert die Zweckregel die bisher aktiven ECA-Regeln der Aktivierungsmatrix. Je nachdem, wie die die Kennzahlenbereiche des Informationssystem-Modells definiert sind, kann der Fall auftreten, dass eine Kennzahlenausprägung eintritt, die nicht in der Aktivierungsmatrix definiert ist. In einem solchen Falle liegt für das zu lösende Entscheidungsproblem keine geeignete ECA-Regel vor und es ist eine Spezifizierung durchzuführen (siehe Abschnitt 5.2.2). 5.2.1.4

Anbindung von ECA-Regeln und Integration der Teilmodelle zu einer Programmhierarchie

In den vergangenen Abschnitten wurden die Funktionsweise und Daten einer Zweckregel dargestellt. Eine Zweckregel bezieht sich dabei immer auf Hyper533

Oftmals wird die Maximierungs- bzw. Minimierungsregel verwendet.

Framework zur Automatisierung von Führungsentscheidungen

166

cube-Zellen, welche durch identische Hierarchieelemente beschrieben sind, wodurch die Bindung zwischen Daten und Zweckregel sehr stark ist. Zur Vollendung einer Programmhierarchie ist allerdings noch eine Verbindung zwischen der Zweckregel und den zugehörigen ECA-Regeln zu implementieren. Diese Anbindung ist Gegenstand des vorliegenden Abschnitts. Zunächst ist festzuhalten, dass die effiziente Implementierung von Zweckregeln es erfordert, dass nicht bei jeder Änderung einer ECA-Regel auch die zugehörige Zweckregel entsprechend anzupassen ist. Anderenfalls wird die Kopplung zwischen Zweck- und ECA-Regeln sehr stark. Des Weiteren sollen Zweckregeln die in Abschnitt 5.2.1.3 eingeführte Aktivierungsmatrix zur Auswahl von ECARegeln verwenden. Diese kann ebenfalls nicht in ECA-Regeln und Zweckregel gespeichert werden, da ansonsten wiederum die Kopplung zwischen den Regeln sehr stark wird. Da eine Zweckregel die Zielerreichung immer mittels Hypercube-Zellen überprüft, die durch identische Hierarchieelemente (mit Ausnahme des Hierarchieelements der Zeithierarchie) beschrieben sind, besteht die Idee darin, für jede Hypercube-Zelle, die von einer Zweckregel überprüft wird, eine Konnektortabelle als Verbindungsglied zwischen Hypercube-Zelle und ECA-Regel(n) zu erstellen. Um eine eindeutige Zuordnung zwischen Hypercube-Zelle und Konnektortabelle zu ermöglichen wird im Folgenden für die Tabellen eine Namenskonvention verwendet, welche die beschreibenden Hierarchieelemente der Hypercube-Zelle - geordnet nach Hierarchie in alphabetischer Reihenfolge - enthält. Da die Hierarchieelemente der Zeit-Hierarchie variieren, werden diese bei der Namensgebung der Tabellen nicht berücksichtigt. Die Anbindung der ECA-Regeln an die übrigen Modelle einer (einfachen) Programmhierarchie 534

Gesamtvertrieb

534

durch

die

Konnektortabelle

Konsumentenkredite-

ist übersichtsartig in Abbildung 33 dargestellt.

Konsumentenkredite und Gesamtvertrieb sind Ausprägungen der Dimensionsknoten Kategorie bzw. Alle Regionen

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

167

Abbildung 33: Modelle einer Programmhierarchie

!lt.o,1II) !lt.o,14) 1(.0,11:1)

0,...

"",., 1"'1IIl)

0,.., 0,..,

....,

..... ..... 1(0,01)

"'-'"

Nach der erfolgten Integration der Teilmodelle zu einer Programmhierarchie finden sich im Folgenden noch einige Implementierungsüberlegungen. Die erste Überlegung zielt darauf ab, wo die ECA-Regeln einer Programmhierarchie idealerweise vorgehalten werden. Wenn der verwendete Hypercube auf einer relationalen Data-Warehouse-Datenbank aufbaut, so können ECA-Regeln in dieser Datenbank vorgehalten werden, zumindest wenn diese als aktives Datenbanksystem betrieben werden kann. Aus fachlicher Perspektive gibt es allerdings klare Argumente gegen diese Lösung: Zunächst einmal ist die Reaktion auf Ereignisse außerhalb des Data-Warehouse-Systems problematisch, da diese aufwändig in das Data Warehouse zu integrieren sind.

53S

Zudem ist die

Bindung an eine relationale Data-Warehouse-Datenbank problematisch, da auch Ereignisse aus Datenströmen und Datenwolken zu berücksichtigen S35

Eine solche Integration relevanter Ereignisse führen bspw. Thalhammer, Sehrefl (2002), S. 1199 ff. und S. 1211 durch, um Ereignisse aus operative Datenquellen berücksichtigen zu können.

168

Framework zur Automatisierung von Führungsentscheidungen

sind.

53

'

Die Speicherung von ECA-Regeln innerhalb der Data-Warehouse-

Datenbank ist demnach realisierbar, hat allerdings wesentliche Schwächen. Darüber hinaus können ECA-Regeln in den Datenquellen von Data-WarehouseSystem und zugehörigen Hypercubes gespeichert werden. Aus fachlicher Perspektive handelt es sich dabei um eine überlegene lösung, weil entsprechend den Anforderungen hA6 und hA7 beliebige Ereignisse in die Programmhierarchie integriert werden können. Dadurch lässt sich - im Sinne von lUHMANN eine hohe Umweltabhängigkeit der Programmhierarchie sicherstellen.'" Ein weiterer Vorteil einer derartigen Speicherung von ECA-Regeln ist darin zu sehen, dass ECA-Regeln sowohl in aktiven Datenbanksystemen als auch in DSMS und CEP-Systemen realisiert werden können und somit auch Ereignisse aus Datenströmen und -wolken zu berücksichtigen sind.

538

Aufgrund der genann-

ten Vorteile empfiehlt es sich die ECA-Regeln mehrgliedriger Programmhierarchien in den operativen Quellsystemen vorzuhalten. An dieser Stelle wird noch einmal betont, dass die von einer Zweckregel aktivierte ECA-Regel erst ausgeführt wird, wenn das dort definierte Ereignis in dem entsprechenden Informationssystem eintritt. Somit liegt hier - im Gegensatz zu dem Konzept von THALHAMMER et al. - keine Beschränkung der Ereigniskomponente der ECA-Regel vor und die in Abschnitt 4.4 genannten Schwächen der Ereigniskomponente können somit als beseitigt betrachtet werden. Darüber hinaus können in dem Framework statt der ECA-Regeln klassischer Datenbanksysteme auch kontinuierliche Anfragen von DSMS und CEP-Systemen aktiviert werden. Die Fähigkeit auch komplexe Ereignisse als Auslöser verwenden zu können, hängt dabei von der leistungsfähigkeit des verwendeten Systems ab. Nachdem nun geklärt ist, wo ECA-Regeln idealerweise betrieben weren, ist darüber hinaus zu überlegen, wo die Konnektortabellen und die darin enthaltenen Aktivierungsmatrizen gespeichert werden können. Da diese die ECARegeln in den operativen Quellsystemen mit den betroffenen Zellen eines Hypercubes verbinden sollen, bietet sich dafür die Data-Warehouse-Datenbank

536 531 531

Vgl. Abschnitt 4.4. Vgl. Luhmann (1964), S. 11. Vgl. Abschnitt 4.4.

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

169

an, welche sich zwischen den operativen Quellsystemen und dem betroffenen Hypercube befindet.

5.2.2

Modelle einer mehrgliedrigen Programmhierarchie

In Abschnitt 5.1 wurde herausgearbeitet, dass Führungsentscheidungen mittels einer mehrgliedrigen Programmhierarchie automatisiert werden können. Nachdem im vergangenen Abschnitt die Modelle einer einfachen Programmhierarchie dargestellt wurden, wird in diesem Abschnitt diskutiert, wie diese Modelle in einer mehrgliedriger Programmhierarchien zu modifizieren sind. Dies betrifft die Zweckregeln und die Daten zur Prüfung der Zielerreichung. Die Anbindung von ECA-Regeln und die Integration der Teilmodelle sowie die Entscheidung darüber, welche ECA-Regeln zu aktivieren und welche zu deaktivieren sind, ändern sich in mehrgliedrigen Programmhierarchien dagegen nicht. 5.2.2.1

Zweckregel-Hierarchien

Der zentrale Gedanke bei der Realisierung mehrgliedriger Programmhierarchien besteht darin, dass Entscheidungsprobleme, die von einer Zweckregel nicht gelöst werden können, spezifiziert werden und an andere Zweckregeln weitergereicht werden. Die Gesamtheit mehrerer Zweckregeln, welche das Spezifizieren von Problemen erlaubt, wird im Folgenden als ZweckregelHierarchie bezeichnet. Zum Aufbau derartiger Zweckregel-Hierarchien wird die Tatsache genutzt, dass die Hierarchieelemente multidimensionaler Daten zur Überprüfung der Zielerreichung bereits hierarchisch organisiert sind. Diese Hierarchien können als Navigationspfad verwendet werden. Um die Eignung von HypercubeHierarchien zur Spezifizierung zu verdeutlichen, sind die qualifizierenden Informationen eines Hypercubes auf Ausprägungsebene zu betrachten. Dabei wird ersichtlich, dass es sich bei Hierarchien um Baumstrukturen handelt, in denen jedes Hierarchieelement (abgesehen von dem obersten) exakt ein übergeordnetes und (außer dem untersten) ein oder mehrere untergeordnete Hierarchieelement(e) besitzt.

539

Zunächst werden im Folgenden einfache Hie-

rarchien betrachtet, die zum einen balanciert sind, d. h. alle Pfade vom oberssag

Vgl. Holten (1999), S. 85. Vgl. Stahl knecht, Hasenkamp (2005), S. 155 und S. 170 zu Baumstrukturen.

Framework zur Automatisierung von Führungsentscheidungen

170

ten bis zum untersten Hierarchieelement besitzen die gleiche Länge, und zum anderen werden alle enthaltenen Hierarchieelemente disjun/ct zerlegt, d. h. Hierarchieelemente besitzen auf der untergeordneten Ebene keine gemeinsamen Hierarchieelemente.'40 In Abbildung 34 ist die Struktur der Dimension Vertriebsort sowohl auf Typ- (al als auch auf Ausprägungsebene (bl dargestellt, wobei aus Platzgründen auf der Dimensionsebene Filiale nur die Hierarchieelemente der Vertriebsregion Mitte abgebildet sind. 541 Abbildung 34: Dimension Vertriebsort auf Typ- und Ausprägungsebene (b) AusprIJunpebene

Mithilfe der hierarchisch geordneten Hierarchieelemente können Kennzahlen auf unterschiedlichen Verdichtungsstufen betrachtet und Entscheidungsprobleme somit spezifiziert werden. Darüber hinaus werden die betrachteten Kennzahlen durch weitere Hierarchieelemente aus anderen Dimensionen multidimensional eingeschränkt. Wenn die Hierarchieelemente der anderen Dimensionen konstant gehalten werden, so kann die baumartige Struktur einer Hypercube-Hierarchie als Zweck-Mittel-Hierarchie aufgefasst und verwendet werden. Für den Umsatz des Gesamtvertriebs können die Vertriebsregionen als Mittel betrachtet werden. Um diese Mittel allerdings verfolgen zu können, müssen diese zu einem Ziel transformiert werden, was bedeutet, dass für die

540

541

Vgl.

zu balancierten Bäumen Bauer, Günzel (2009), S. 191. Auch Goeken (2006). S. 168

formuliert diese Eigenschaften von einfachen Hierarchien. Allerdings macht er balancierte Bäume an einer totalen Zerlegung fest. Aus einer totalen Zerlegung eines Objektes folgen Jedoch nicht zwingend gleich lange Pfade, da die Zerlegung auch total sei" kann, wenn sie auf unterschiedlichen Dimensionsebenen erfolgt. Vgl. Schelp (2000), S. 243 ff.; Goeken (2006), S. 164 ff. für eine ähnliche Darstellungsweise von Dimensionshierarchien.

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

171

einzelnen Vertriebsregionen ebenfalls Zielwerte zu definieren sind. Eine solche Transformation wird auch als Zweck-Mittel-Verschiebung bezeichnet und kann rekursiv angewandt werden. 542 Wenn bei der in Abschnitt 5.2.1 dargestellten Zweckregel ein Entscheidungsproblem vorliegt und keine geeignete ECA-Regel zur Verfügung steht, so ist das Problem zu allgemein und es ist eine Hierarchie zu definieren, in der ein Drilldown zur Spezifizierung des allgemeinen Problems durchgeführt werden kann. Im Anschluss an den Drill-down wird für jedes auf der nun erreichten Dimensionsebene vorhandene Hierarchieelement eine Zweckregel in der dargestellten Form durchgeführt. Der Auslöser dieser Regel ist allerdings kein temporales Ereignis, sondern das Ereignis keine Entscheidung möglich aus der übergeordneten Zweckregel. Zunächst wird wiederum geprüft, bei welchen Hierarchieelementen ein Entscheidungsproblem vorliegt. Zur Problemlösung werden für die betroffenen Hierarchieelementen nach Möglichkeit geeignete ECA-Regeln eingesetzt. Existieren keine geeigneten ECA-Regeln, so muss das Problem für das betroffene Hierarchieelement noch weiter spezifiziert werden, indem ein Drill-down auf die untergeordnete Hierarchieebene durchgeführt wird. In Abbildung 35 ist das Modell einer derart aufgebauten Zweckregel-Hierarchie skizziert, welche in Anlehnung an die die Hypercube-Hierarchie Vertriebsort erstellt wurde.

S42

Vgl. Luhmann (1973), Charakterisierungen.

s.

266 ff.

und

296 ff.

zur Relativität von

Zweck-Mittel-

172

Framework zur Automatisierung von Führungsentscheidungen

Abbildung 35: ZWeckregel-Hierarchie

,-------------{

.

Verb1ebsrealon Mitte

r---{m.

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

173

In Abbildung 35 kann eine mögliche Ausprägung des Entscheidungsganges innerhalb der Zweckregel-Hierarchie nachvollzogen werden, indem den schattierten Ereignissen und Funktionen von oben nach unten gefolgt wird. Um die Zweckregel-Hierarchie zu vervollständigen, wäre noch eine Slice-Operation auf das Hierarchieelement Vertriebsregion Mitte mit anschließenden Drill-down notwendig. Die einzelnen Filialen dieser Vertriebsregion müssten wiederum mit jeweils einer Zweckregel untersucht werden. Aus Platzgründen ist dies in Abbildung 35 ebenso nicht dargestellt wie die Zweckregeln der Vertriebsregionen Nord und Süd. Wenn auf der untersten Dimensionsebene - wie hier die Filial-Ebene - ein Entscheidungsproblem auftritt, das nicht mithilfe einer ECARegel gelöst werden kann, so ist ein Mitarbeiter zu informieren, dass ein Entscheidungsproblem vorliegt, welches nicht automatisch gelöst werden kann. Die Ausprägung eines Entscheidungsgangs kann wesentlich kompakter in Form einer Tabelle dargestellt werden. Dabei wird jede zu analysierende Dimensionsebene in einer Spalte dargestellt, wobei in die Spalte die zugehörigen Ausprägungen, die sogenannten Hierarchieelemente, eingetragen werden. Für

jedes betrachtete Hierarchieelement wird in einer weiteren Spalte angegeben, ob das Ziel erreicht wird oder nicht. Wenn das Ziel nicht erreicht wird, so wird in einer weiteren Tabellenspalte eingetragen, ob entsprechende ECA-Regeln zur Lösung des Entscheidungsproblems vorliegen oder nicht. In Abhängigkeit von der Existenz solcher Regeln ist in der Spalte Drill-down abzutragen, ob ein Drill-Down zur Spezifizierung des Problems notwendig ist oder nicht. In Tabelle 15 ist der in Abbildung 35 bereits dargestellte Entscheidungsgang dargestellt.

Framework zur Automatisierung von Führungsentscheidungen

174

Tabelle 15: Zweckregel-Hierarchie in Tabellenform

Alle Regionen

Vertriebsn!lion~ ~ Filiale

Gesamtvertrieb

Ziel erreicht

ECA.-Regeln

Drill-down

Nel"

Nein

Ja

Nein

Nein

Ja

Nord

Mitte GieRen

Marburg Stadtallendorf ...

Süd

Bisher wurden lediglich einfache Hypercube-Hierarchien verwendet, weil dort eindeutige Navigationspfade existieren, die zur Spezifizierung allgemeiner Probleme eingesetzt werden können. Darüber hinaus existiert jedoch eine Reihe von Strukturbesonderheiten in Hypercube-Hierarchien, die sich ergeben, wenn kein balancierter Baum und/oder keine disjunkte Zerlegung von Hierarchieelementen vorliegtfen. Diese werden im Folgenden knapp vorgestellt und es wird geprüft, ob die Hierarchien trotz der Strukturbesonderheiten zur Konstruktion von Zweckregel-Hierarchien herangezogen werden können. Die erste Strukturbesonderheit sind sogenannte Heterarchien, die dadurch gekennzeichnet sind, dass mehrere übergeordnete Hierarchieelemente sich auf gemeinsame untergeordnete Hierarchieelemente beziehen und die Zerlegung somit nicht disjunkt ist.'43 Während bei einfachen Hierarchien die Beziehungen zwischen den Hierarchieelementen zweier Dimensionsebenen immer

l:n ist, können in Heterarchien n:m-Beziehungen zwischen den ausgeprägten Hierarchieelementen auftreten. Heterarchien treten standardmäßig in Zeitdimensionen auf. Wenn dort Betrachtungen sowohl auf Wochen- als auch auf Monatsbasis durchgeführt werden, so sind einzelne Wochen auf zwei Monate zu verrechnen. Eine derartige Heterarchie ist übersichtsartig in Abbildung 36 dargestellt. '" Vgl. Schelp 12000), S. 243 f.: Goeken (2006), S. 169 f.

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

175

Abbildung 36: Heterarchie lai TypeIIeIll! Quirtill

Monat

Januar

Februar

M'"

Schelp (2000), S. 244.

Heterarchien stellen zwar - zumindest wenn sie von oben nach unten durchlaufen werden - grundsätzlich einen eindeutigen Hierarchiepfad zur Verfügung, allerdings ist ihr Einsatz zur Konstruktion von Zweckregel-Hierarchien trotzdem problematisch, da die anteilige Verrechnung von Soll- und Ist-Daten der Elemente mit n:m-Beziehungen einen extrem hohen Aufwand bedeutet. Eine Möglichkeit, diese anteilige Verrechnung von Heterarchien zu umgehen, ist die Überführung in parallele Hierarchien. Dabei werden zwei oder mehr pfade zwischen Hierarchieelementen definiert, sodass zwischen den Elementen zweiter Ebenen immer l:n-Beziehungen vorliegen. Die Hierarchieelemente einer Dimension werden zu diesem Zweck nach unterschiedlichen, disjunkten Kriterien gruppiert.

S44

In Abbildung 37 wird die oben dargestellte Heterarchie

überführt in eine parallele Hierarchie, in der nun die Hierarchiepfade (1) Jahr-+Quartal-+Monat-+Tag und (2) Jahr-+Woche-+Tag existieren. Parallele Hierarchien können zur Konstruktion von Zweckregel-Hierarchien nicht verwendet werden, da sie mehrere Hierarchiepfade zur Verfügung stellen und für die Spezifizierung daher unbrauchbar sind. Eine denkbare Alternative zu parallelen Hierarchien besteht in der expliziten Definition mehrerer einfacher Hierarchien für die gewünschten Hierarchiepfade in einer Hierarchie. Diese einfachen Hierarchien können wiederum konkret angesprochen und somit für eine Automatisierung genutzt werden. Bspw. könnte die einfache Hierarchie .Jahr-+Quartal-+Monat" definiert und von einer Zweckregel verwendet werden.

'" Vgl. Schelp (2000), S. 144.

Framework zur Automatisierung von Führungsentscheidungen

176

Abbildung 37: Parallele Hierarchie

Jlhr

Monat

Die dritte und letzte Strukturbesonderheit, die hier besprochen wird, sind Hierarchien mit unterschiedlichen Pfadlängen.'45 Derartige Hierarchien sind da-

durch gekennzeichnet, dass die Anzahl der Hierarchieelemente vom obersten bis zum untersten Element nicht für alle Ausprägungen gleich groß ist, d. h. es handelt sich nicht mehr um einen balancierten Baum. Hierarchien mit unterschiedlichen Pfad längen sind oftmals in Produktdimensionen zu finden, wenn es bspw. für eine bestimmte Produktkategorie derart wenige Produkte gibt, dass diese nicht noch in Untertypen gruppiert werden. Eine solche Produkthierarchie ist übersichtsartig in Abbildung 38 dargestellt. Abbildung 38: Unterschiedliche pfadlängen (a) Typebene

I I

Alle Produkte

1 K.tegorie

{bI Ausprägungsebene

I

I

I

I

1 1

Wo

I

1

Ratenkredit

1 1

545

Produkt

1

I

Konsumentenkredite

I

I

Dispositionskredite

IAnnuit~tenkredit I I

1

I

Produkte

1 48 M

1

I

/~

1Dispositionskredit I I STANDARD I

1 Di5P05ition5kredit COMFORT

I I

Vgl. Schelp (2000), S. 143 f.; Goeken (2006), S. 170 ff. Bauer, Günzel (2009), S. 191 bezeichnet solche Hierarchien als "entartet H

•

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

177

Hierarchien mit unterschiedlichen Pfadlängen können im Gegensatz zu den anderen dargestellten Strukturbesonderheiten problemlos für eine Spezifizierung verwendet werden, da die Pfade zwischen den Elementen eindeutig sind. Es kann allgemein festgehalten werden, dass Hypercube-Hierarchien genau dann zur Konstruktion von Zweckregel-Hierarchien und somit zur Automatisierung von Führungsentscheidungen eingesetzt werden können, wenn sie einen eindeutigen Hierarchiepfad zur Verfügung stellen. Im Falle von Heterarchien sind zudem eindeutige anteilige Verrechnungen zu gewährleisten. Neben den in einem Hypercube bereits vorhandenen Dimensionshierarchien können weitere Hierarchien mit eindeutigen Hierarchiepfaden und Verrechnungen definiert und anschließend für die Automatisierung von Führungsentscheidungen genutzt werden. Bei der Definition einer Hierarchie können die Hierarchieelemente auch verschiedenen Dimensionen entstammen, sodass daraus entspre54 chend der Anforderung hA3 eine flexible Bezugsobjekthierarchie resultiert. '

Zum Abschluss des Abschnitts wird noch ein wesentlicher Unterschied von Zweckregel-Hierarchien gegenüber dem Active-Data-Warehouse-Konzept von THALHAMMER

dargestellt. Dieser Unterschied betrifft die Spezifizierung von all-

gemeinen Problemen. Während die Analyseregeln von THALHAMMER et al. zu diesem Zweck einen Analysegraphen enthalten, verwenden ZweckregelHierarchien eine fest definierte Hierarchie eines Hypercubes.

547

Zur Illustration

ist ein Analysegraph von THALHAMMER in Abbildung 39 dargestellt.

S46

547

Vgl. Sapia et al. (1999), S. 9. Vgl. Thalhammer (2001), S. 257 ff.

178

Framewort zur Automatisierung von FQhrungsenucheldungen

Abbildung 39: Analysegraph von Thalhammer et al.

_-.,,:t

"$aJesUpperAustria· ~ ThisQuarter"

D~ ,,~D ~ "SalesUppe rAustria-

ffffi'/

'SalesUACitiesTh,sQuarter" !BEl

.s.•,uo: tIt L

ThisOuarter"

I'

~ ThisQuarterMonths'

Legend:

liII

'cube"

~ ~

incremental speciflcation

",--direct "more specihc' edge

I

~~i

'SalesLinzThisOuarlerMonths'

RU

AOLLUP

00 SL 1$

DRILlDQWN SLICE INTEASECTtON

Thalhammer (2001), S. 263.

Zunächst einmal ist der Vorteil des Analysegraphen darin zu sehen, dass die OLAP-Operationen auf mehr als eine Hierarchie angewendet werden. Die Ergebnisse der OLAP-Operatlonen werden als Hypercube-Slchten vorgehalten und können weiter verarbeitet werden.

S48

Mithilfe der Operation Intersection

kann zudem eine Dice-Operation nachgestellt werden, sodass letztlich Hierarchieelemente in zwei oder mehr Hierarchien spezifiziert werden können. In dem oben dargestellten Analysegraphen wird allerdings auch der Nachteil einer derartigen Vorgehenswelse deutlich, wenn betrachtet wird, wie spezifisch anzugeben Ist, auf welches Element bspw. eine Slice-Operation vorzunehmen ist. In dem dargestellten Fall wird etwa die Slice-Operation von der Hypercube-Sicht SalesUACitiesThisQuarter ausgehend immer auf das Hierarchieelement Linz durchgeführt. Demgegenüber ist die vorgeschlagene Spezifizierung durch ZWeckregel-Hierarchien entlang einer definierten HypercubeHierarchie wesentlich flexibler. Durch die In Zweckregel-Hlerarchlen enthaltenen Ziele und Hierarchien werden Slice-Operationen genau dort durchgeführt, wo ein Entscheidungsproblem vorliegt, ohne dass dies vorher antizipiert wer541 VII. Thalhammer (2001), 5. 258.

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

179

den muss. Durch diese Eigenschaften können Zweckregel-Hierarchien deutlich besser als Analyseregeln mit struktureller Dynamik umgehen. Das zeitgleiche Spezifizieren in mehreren Hierarchien ist mithilfe von Zweckregeln dagegen weder möglich noch sinnvoll, weil die sich ergebenden Hierarchiepfade wiederum nicht eindeutig sind.'49 5.2.2.2

Daten zur Prüfung der Zielerreichung in mehrgliedrigen Programmhierarchien

Wie bereits im vergangenen Abschnitt deutlich wurde, benötigen ZweckregelHierarchien nicht nur multidimensionale Daten, sondern in diesen müssen

auch die OLAP-Operationen Slice und Drill-down realisierbar sein, um die Hypercube-Hierarchien in der beschriebenen Art und Weise als Navigationspfad verwenden zu können. Ist-Daten werden, wie in Abschnitt 3.3.2 erläutert, von unten nach oben (bottom-up) aus operativen Informationssystemen gewonnen und in Hypercubes gespeichert. Zur Generierung der Soll-Daten müssen allgemeine Ziele mit den entsprechenden Unterzielen verknüpft werden und es muss sichergestellt werden, dass die angestrebten Zielwerte miteinander harmonieren.''' Das Beziehungsgeflecht in Form von Zweck-Mittel-Ketten liegt üblicherweise - z.B. in Form einer Balanced Scorecard - bereits vor.

551

Die konkre-

ten Soll-Daten eines bestimmten Zeitraums werden im Gegenstromverfahren zwischen den Organisationseinheiten eines Unternehmens ausgehandelt und müssen zur Automatisierung von Führungsentscheidungen im analytischen Informationssystem hinterlegt werden.'52 Die dargestellte Gewinnung der Istund Soll-Daten ist in Abbildung 40auf der linken bzw. rechten Seite dargestellt.'''

In Analyseregeln wird dieses Problem gelöst, indem für jeden Entscheidungsschritt exakt definiert wird, welche Hypercube-Sicht genutzt werden soll. '" Vgl. Kaplan, Norton (1992), S. 71 ff.; GolfarelIi et al. (2004), S. 2; Melchert, Winter (2004), S. 535 ff.; Dinter, Bucher (2006), S. 31 ff. 551 Vgl. Dinter, Bucher (2006), S. 31. m Das Gegenstromverfahren vereint Elemente des Bottom-up-Ansatzes und des Top-downAnsatzes. Vgl. Müller-BOling, Schreiterer (1999), S. 20 ff. Eine denkbare Datenquelle sind die Budgetplanungen von Unternehmen. i l l Vgl. für eine ähnliche Abbildung: GolfarelIi et al. (2004), S. 2. 549

180

Framework zur Automatisierung von Führungsentscheidungen

Abbildung 40: Ist- und Soll-Daten

Ziele/Stratesie

Spezifizieren

Operative Informationssysteme

Darüber hinaus ist in der Abbildung mithilfe des grau hinterlegten Pfeils in der Mitte dargestellt, dass die Daten bei allgemeinen Problemen spezifiziert werden, indem ein bestimmtes Hierarchieelement entsprechend spezifiziert wird. In dem gewählten Beispiel werden 5011- und Ist-Daten bzgl. des Umsatzes des gesamten Unternehmens spezifiziert in einzelne Vertriebsregionen.

5.2.3

Zusammenfassung

Damit sind sämtliche Teilmodelle des Frameworks zur Automatisierung von Führungsentscheidungen hergeleitet. Bevor im folgenden Kapitel die Auswahl und Konstruktion von ModelIierungssprachen zur Erstellung dieser Teilmodelle diskutiert wird, sollen noch kurz die Weiterentwicklungen des AvFeFrameworks gegenüber dem Active-Data-Warehouse-Konzept dargestellt werden:

Automatisierung von Führungsentscheidungen durch ProgramlTl'Jerschachtelung: Das AvFe-Framework

•

181

Zweckregeln berücksichtigen explizit Ziele und Zielsystem. Durch die hierarchische Verbindung mit ECA-Regeln orientieren sich auch ECA-Regeln mittelbar an Zielen.

•

Zweckregel-Hierarchien können die Dynamik des Realitätsausschnitts in beträchtlichem Maße absorbieren, da Zweckregeln revolvierend Ziel und Zustand eines Realitätsausschnitts miteinander vergleichen und im Falle eines Problems geeignete ECA-Regeln aktivieren.

•

Durch den dargestellten Aufbau ist die Ereigniskomponente deutlich flexibler und eine Bindung an eine bestimmte Technologie ist nicht vorhanden, weil die Regeln in den Quellsystemen lediglich aktiviert und deaktiviert werden. ECA-Regeln in (objekt-)relationalen Datenbanksystemen können dabei ebenso aktiviert werden wie kontinuierliche Anfragen in DSMS oder CEP-Systemen. Die Anforderungen hA7 und hAB an das Informationssystem können somit als erfüllt betrachtet werden.

6

Modellierungssprachen für das AvFe-Framework

Gegenstand des vorliegenden Kapitels ist die Auswahl und Konstruktion sem iformaler domänenspezifischer Modellierungssprachen, welche die Erstellung konzeptioneller Teilmodelle des in Kapitel 5 beschriebenen Frameworks anleiten. Dabei werden dem Nutzer des Frameworks keine bestimmten Modellierungssprachen vorgeschrieben, sondern es wird vielmehr gezeigt, wie anhand eines Metamodells Modellierungssprachen ausgewählt und konstruiert werden können. Die im Folgenden verwendeten Modellierungssprachen sind somit lediglich als Vorschläge zu verstehen und die Auswahl der konkreten Modellierungssprachen obliegt letztlich dem Nutzer des AvFe-Frameworks. Um dieses Ziel zu erreichen, wird zunächst in Abschnitt 6.1 die abstrakte Syntax des AvFe-Frameworks rekonstruiert. Dazu werden Teil-Metamodelle gebildet, die anschließend zu einem Gesamt-Metamodell integriert werden. In Abschnitt 6.2 werden anschließend für die Teil-Metamodelle geeignete Modellierungssprachen präsentiert. Wenn für die Teilmodelle geeignete Modellierungsspraehen existieren, so wird eine Modellierungssprache beispielhaft ausgewählt, und deren Eignung wird mithilfe einer Repräsentationsanalyse geprüft. Existiert dagegen für ein Teilmodell keine geeignete Modellierungssprache, so wird eine entsprechende ModelIierungssprache entwickelt. 6.1

Die abstrakte Syntax des AvFe-Frameworks

Im vorliegenden Abschnitt wird ein Metamodell zur Beschreibung der abstrakten Syntax des AvFe-Frameworks entwickelt. Zu diesem Zweck wird zunächst in Abschnitt 6.1.1 diskutiert, wie zur Konstruktion von sprachbasierten Metamodellen idealerweise vorzugehen ist. In Abschnitt 6.1.2 wird anschließend das Metamodell des AvFe-Frameworks entsprechend hergeleitet. Das resultierende Metamodell wird dann zur Evaluation und Auswahl existierender sowie zur Entwicklung neuer Modellierungssprachen herangezogen.

J. Rommelspacher, Automatisierung von Führungsentscheidungen, DOI 10.1007/978-3-8348-8251-6_6, © Vieweg + Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

184

Modellierungssprachen für das AvFe-Framework

6.1.1

Die Konstruktion von sprachbasierten Metamodellen mit der Objekttypenmethode

Ein sprachbasiertes Metamodell normiert die abstrakte Syntax einer Modellierungssprache, d. h. es definiert die Konstrukte einer domänenspezifischen Modellierungssprache sowie deren Beziehung untereinander. Je nach wissenschaftstheoretischer Position und Modellverständnis können verschiedene Ansätze zur Konstruktion von sprachbasierten Metamodellen herangezogen werden: Erstens können sogenannte Ontologien als Grundlage eines Metamodells verwendet werden.'54 Nach GRUBER können Ontologien folgendermaßen definiert werden: "An ontology is an explicit specification of a conceptualization N .'55 Im Gegensatz zu konzeptionellen (im Sinne von begrifflichen) Modellen sind Ontologien formalsprachliche Konstrukte mit dem Ziel, Wissen über einen bestimmten Weltausschnitt über ein konkretes Projekt hinaus mit anderen zu teilen (Wiederverwendung).556 Die Verwendung von Ontologien zur Konstruktion eines Metamodells wird in dieser Arbeit abgelehnt, da ihre Verwendung vor dem Hintergrund der eingenommenen wissenschaftstheoretischen Position und dem dargelegten Modellbegriff problematisch ist. Insbesondere die eingenommene Position als erkenntnistheoretischer Idealist verkompliziert die Situation. Noch diskutabel ist die Frage, ob bereits der Weltausschnitt von Ontologien das Resultat einer subjektiven Vorstrukturierung ist. Der subjektive Einfluss der Ontologienersteller kann jedoch aus der genannten wissenschaftstheoretischen Position nicht abgestritten werden und führt zu mannigfaltigen Problemen.

557

Ein zweiter möglicher Ansatz zur Konstruktion von sprach basierten Metamodellen besteht in der präzisen, eindeutigen und zirkelfreien Rekonstruktion

554

Die pluralistische Rede von Ontologien ist abzugrenzen von der oben eingeführten philosophischen Verwendung des Ontologiebegriffs. Statt philosophischen Aussagen über die Wissenschaft des Seins, sind Ontologien vom Menschen geschaffene Artefakte, die begriffliche Strukturen eines bestimmten Weltausschnittes, wie z. B. einer Domäne, beschreiben. Vgl. Mylopoulos (1998), S. 136: uan ontology characterlzes some aspects of a class of applicatlons Vgl. auch Schatte, Zelewskl (1999), S. 4. Gruber (1993), S. 199. Vgl. Schütte, Zelewski (1999), S. 9; Hesse (2005). Vgl. ausführlich: Schütte, Zelewski (1999). H

•

555

556 551

Die abstrakte Syntax des AvFe-Frameworks

185 55

domänenspezifischer Konstrukte und ihrer Beziehungen. ' Ein derartiges Herleiten einer eindeutigen Sprach basis kommt in Informationssystementwick55

lungs-Projekten häufig vor. ' Während in solchen Projekten die Konstrukte mit Bezug auf eine konkrete Anwendung (bspw. die Entwicklung einer Datenbank zur Kundenverwaltung) zu normieren sind, werden in einem sprachbasierten Metamodell die Konstrukte einer (betriebswirtschaftlichen) Domäne rekonstruiert. Beide Spezifikationsprobleme gleichen der in Abschnitt 1.2.2.1 skizzierten Konstruktion einer Orthosprache in der Wissenschaftstheorie.

s5O

Da die

zugrunde liegenden wissenschaftstheoretischen Positionen der Erlanger Schule mit den in dieser Arbeit vertretenen Positionen und des daraus abgeleiteten Modellverständnisses harmonieren, wird das sprachbasierte Metamodell im Folgenden durch die Rekonstruktion der domänenspezifischen Konstrukte hergeleitet. Eine bewährte und ausgereifte Methode zur Konstruktion einer Orthosprache in der Informationssystementwicklung ist die Objekttypenmethode von WEDEKIND.

S61

Diese ist wesentlicher Bestandteil einer umfassenden Entwurfs-

methode für Datenbanken und geht dem "operationellen Herstellen" eines S62 Informationssystems zur Lösung einer Problemstellung voraus. Die Objekttypenmethode erklärt phänomenologisch das Zustandekommen betrachteter Gegenstände, reduziert diese auf wesentliche Merkmale, um sie erst am Ende zu formalisieren.'" Dabei sind die notwendigen Konstrukte ohne Zirkel (das Konstrukt wird durch sich selber erklärt), ohne Sprünge (verstehensnotwendige Schritte werden ausgelassen) und ohne implizite Definitionen in Einzelschritten zu begründen und zu rechtfertigen.'"

Vgl. Wedekind (1979); Wedekind (1980); Wedekind (1981); Holten (1999); Holten (2000); Holten (2001a). Holten und Wedekind bezeichnen die Grundbestandteile von Sprachen nicht als Konstrukte, sondern als Begriffe. Um die Terminologie zu vereinheitlichen, wird in dieser Arbeit auch bei der Objekttypenmethode von Konstrukten gesprochen. '" Vgl. ehen (1976); Wedekind (1979); Wedekind (1980); Wedekind (1981); Mylopoulos (1998). '" Vgl. Wedekind (1981), S. 9. 561 Vgl. Wedekind (1979); Wedekind (1980); Wedekind, Ortner (1980); Wedekind (1981). Die Objekttypenmethode wurde von Ortner weiterentwickelt. Vgl. Ortner (1997); Ortner (1998); Ortner (2002). S62 Vgl. Wedekind (1981), S. 65 ff. S4a Vgl. Wedekind (1979), S. 367. S64 Vgl. Wedekind (1981), S. 46 f. S5II

ModelIierungssprachen für das AvFe-Framework

186

Zur Rekonstruktion von Konstrukten verwendet WEDEKIND den sprachlichen Prozess der Abstraktion. Dabei wird von unwesentlichen Merkmalen eines Gegenstandes abstrahiert und die wesentlichen Merkmale werden betont.'6S WEDEKIND folgt nun dem Abstraktionsverfahren der modernen Logik - das auf FREGE zurückzuführen ist - und definiert Konstrukte durch ihre gemeinsamen explizit genannten Merkmale und keinesfalls durch ihre Unterschiede.''' Die sprachliche Abstraktion realisiert WEDEKIND mittels Abstraktionsprinzipien, wobei er zwischen Subsumption, Subordination, Reduktion und Komposition unterscheidet.'·7 Statt dieser Bezeichnungen WEDEKINDS wird im Folgenden die in der Wirtschaftsinformatik verbreitete Terminologie für Abstraktionsprinzipien verwendet und es wird in Klassifikation, Generalisierung, Assoziation und Aggregation unterschieden.''' Die genannten Abstraktionsprinzipien können grundsätzlich danach unterschieden werden, ob diese eine merkmalsbasierte oder eine Abstraktion nach dem Ganz/Teil-Prinzip durchführen.'·' Die merkmalsbasierte Abstraktion ist dadurch charakterisiert, dass Elemente einem abstrakten Element untergeordnet werden, wenn die untergeordneten Elemente gemeinsame Merkmale oder Merkmalsausprägungen aufweisen. Bei der Abstraktion nach dem Ganz/Teil-

Prinzip bilden heterogene Elemente dagegen ein übergeordnetes, abstraktes Element (Aggregat). Während bei der merkmalsbasierten Abstraktion zwischen existenz- und wertbasierten Abstraktionsprinzipien (Klassifikation/Generalisierung bzw. Assoziation) unterschieden werden kann, wird die Abstraktion nach dem Ganz/Teil-Prinzip durch das Abstraktionsprinzip der Aggregation umgesetzt. Abbildung 41 stellt die dargestellte Unterteilung übersichtsartig dar, ehe Klassifikation, Generalisierung, Assoziation und Aggregation im Folgenden erläutert werden.

565 566 567

570

Vgl. Wedekind (1981), S. 107; Vossen (2008), S. 59. Vgl. Wedekind (1980), S. 666 ff.; Wedekind (1981), S. 109, Vgl. Wedekind (1981), S. 112 ff.

". Vgl. Mottos (1989), s. 475 ff.; Winter (1991), S. 19 ff.; Mylopoulos (1998), S. 140 ff.; Vossen (2008), S. 59 f. 569 Vgl. Winter (1991), S. 19 f. 570

In Abhängigkeit von dem verwendeten Abstraktionsprinzip entstehen unterschiedliche

Beziehungen zwischen untergeordneten Elementen und abstraktem Element. In der obigen Abbildung ist unter jedem Abstraktionsprinzip jeweils noch die englischsprachige Bezeichnung der entstehenden Beziehung in Anlehnung an Mattes (1989) dargestellt.

187

Die abstrakte Syntax des AvFe-Frameworks

Abbildung 41: Systematisierung von Abstraktionsprinzipien

Abstraktionsprinzipien

MerkmalsbasIerte Abstraktion

Ganz!Teil-Abstraktlon

_..

.ExistI!nzbaslerte Merkmalsabstraktion· Klassmkatlon

I"bStnIkdon wn Ellm.rn.l

(Abstraktion von

und/oder~nl

Elementen

part-of(po)

instance-of (io)

.Wertbaslerte Merkmalsabstraktion-

Generali5ierunl (Abstraktion von Typen)

5Ubtype-of (sto)

Das Abstraktionsprinzip Klassi/ikation

571

AssozJat1on

Assozlildion

(Abstraktion von

Elementen

(Abstraktion von M. •

element-of (eo)

IUbset-of (sso)

ordnet Elemente (angeordnet auf der

sogenannten Ausprägungsebene) anhand der Existenz bestimmter Merkmale einem abstrakten Element Typ (angeordnet auf der sogenannten Typebene) zu, wobei der Typ den Elementen der Ausprägungsebene hierarchisch übergeordnet ist.

572

Eine enge Auslegung des Klassifikationskonzepts geht davon aus,

dass Typen lediglich aus atomistischen Elementen gebildet werden können.

57

'

Demnach kann bei ausschließlicher Verwendung des Abstraktionsprinzips Klassifikation lediglich eine 2-Ebenen-Hierarchie erstellt werden. Gegenstand des Abstraktionsprinzips Generalisierung ist die Abstraktion von bereits abstrahierten Elementen (Typen).'74 Es wird somit auf Typen zurückgegriffen, die vorher mithilfe des Abstraktionsprinzips Klassifikation erstellt wurden. 571

S72

575

Typen werden generalisiert, indem ihre gemeinsamen Merkmale auf

Synonym wird in der Literatur der Begriff Typisierung verwendet_ Die Umkehrung des Abstraktionsprinzips wird als Instanziierung bezeichnet_ Vgl. Mattos (1989), S_ 47S; Porac, Thomas (1990), S_ 228; Winter (1991), S_ 26; Elmasri,

Navathe (1994), S. 634; Wand et al. (199S), S. 290; Seheer (1998b), S. 36; Goeken (2006), S. 154; Vossen (2008), S. S9. '" Vgl. Mattos (1989), S. 475; Winter (1991), S. 26; Schütte (1998), S. 96. 574

575

Vgl. Smith, Smith (1977), S. 105 ff.; Mattos (1989), S. 476; Mattos, Michels (1990), S. 162; Elmasri, Navathe (1994), S. 635; Scheer (1998b), S. 36 ff.; Vossen (2008), S. 60. Porac und Thomas bezeichnen dies als Klasseninklusion. Je mehr Unterklassen eine Klasse beinhaltet, als desto abstrakter ist diese anzusehen und desto höher ist sie hierarchisch angeordnet_ Vgl. Porac, Thomas (1990), S_ 227 f.

188

ModelIierungssprachen für das AvFe-Framework 57

einen neuen Typ der höheren Ebene (Supertyp) übertragen werden. ' Das Abstraktionsprinzip ist rekursiv anwendbar, sodass mittels Typen n-EbenenHierarchien realisiert werden können. Antonym zur Generalisierung ist die Spezialisierung. Beim Konzept der Spezialisierung erben spezialisierte Typen (Subtypen) die Merkmale ihres Supertyps. Subtypen besitzen i. d. R. darüber

hinaus zusätzliche, eigene Merkmale und können möglicherweise auch ererbte Merkmale abändern. Die bisher präsentierten Abstraktionsprinzipien abstrahieren von Merkmalsausprägungen, weshalb Typen nicht als wertmäßige Stellvertreter fungieren 577 können. Für Abstraktionen auf der Ausprägungsebene wird daher das Abstraktionsprinzip der Assoziation

57 •

herangezogen.

57

'

Bei diesem werden Ele-

mente in Abhängigkeit von Merkmalsausprägungen assoziiert. Für das entstehende abstrakte Element Menge werden Mitgliedschaftsbedingungen formu580 liert, die von Elementen zu erfüllen sind, um assoziiert zu werden. Ziel der

Assoziation ist die Beschreibung einer Menge als solches, d. h. die Menge verfügt nach ihrer Bildung selbst über Merkmalsausprägungen und kann als Stellvertreter ihrer Elemente fungieren.'·' Bei der Abstraktion durch Assoziation kann hinsichtlich des Gegenstandes in die Assoziation atomistischer Elemente (Elementassoziation) oder der Assoziation von Mengen (Mengenassoziation) unterschieden werden.''' Während mithilfe der Elementassoziation lediglich 2-Ebenen-Hierarchien aufgebaut werden können, kann die Mengenassoziation durch rekursive Anwendung n-Ebenen-Hierarchien realisieren.'83 Auch eine Kombination bei der Assoziationsarten ist möglich.

576

577

Vgl. Scheer (1998b), S. 36 f. Vgl. Winter (1991), S. 26.

579

Synonym wird in der Literatur der Begriff Gruppierung verwendet. Vgl. Mattos (1989), S. 479 f.; Winter (2000), S. 22 ff.; Goeken (2006), S. 157 ff.

580

Mitgliedschaftsbedingung sind

578

üblicherweise

konkrete

Merkmalswerte.

Neben

diesen

Merkmalen verfügen aber Mengen üblicherweise über weitere Merkmale. 581

SB2 SB3

Winter (1991), S. 22 f. spricht davon, dass die Eigenschaften der Gruppe aus ihren Elementen durch Konvexkombination ermittelt werden können. Nach Bildung der stellvertretenden Menge unterscheidet Winter (1991), S. 23 den natürlichen Stellvertreter, das Durchschnittsobjekt und das Mixobjekt als künstlicher Stellvertreter. Vgl. Mattos (1989), S. 479 f.; Goeken (2006), S. 157 f. Dies findet bspw. bei der Bildung von Kennzahlensystemen, wie etwa dem DuPont-Schema, Anwendung. Vgl. Holten (1999), S. 97, wobei hier unspezifisch der Begriff Aggregation verwendet wird.

Die abstrakte Syntax des AvFe-Frameworks

189

Bei dem Abstraktionsprinzip Aggregation werden mehrere Elemente durch funktionales (kausales oder temporales) Zusammenwirken zu einem neuartigen Aggregat zusammengefasst.'84 Um Bestandteil eines Aggregats zu sein, müssen die gemeinsamen Elemente somit keine gemeinsamen Merkmale haben. Das Abstraktionsprinzip der Aggregation kann zur gleichen Zeit auf Elemente und auf Aggregate angewendet werden, sodass ein Aggregat zugleich aus Elementen und (Sub-) Aggregaten bestehen kann, wodurch komplexe Hierarchien realisiert werden können. Ein weiteres Merkmal der Aggregation ist, dass eine Beschreibung erfolgen muss, wie aus den Elementen das Aggregat entsteht.'85 Diese Beschreibung kann entweder direkt bei der Abstraktion oder als Komplement der Abstraktionsbeziehung dargestellt werden. 6.1.2

Das sprachbasierte Metamodell des AvFe-Frameworks

Mit der Objekttypenmethode und den enthaltenen Abstraktionsprinzipien steht nun eine Methode zur Verfügung, welche im vorliegenden Abschnitt zur Konstruktion des sprachbasierten Metamodell des AvFe-Frameworks verwendet wird. Mithilfe der Abstraktionsprinzipien werden die im Framework enthaltenen Konstrukte schrittweise, ohne Zirkel, Sprünge und implizite Definitionen eingeführt.'86 Um die Komplexität bei der Konstruktion des Metamodells zu reduzieren, werden im Folgenden zunächst Teil-Metamodelle entwickelt, die sich jeweils auf einen ausgewählten Aspekt beschränken. Anschließend werden diese zu einem umfassenden Metamodell integriert.'·7 Zunächst wird in Abschnitt 6.1.2.1 das Metamodell von Zweckregel-Hierarchien rekonstruiert. Im Rahmen des AvFe-Frameworks prüfen Zweckregeln mithilfe multidimensionaler Daten die Zielerreichung. In Abschnitt 6.1.2.2 wird daher das Metamodell multidimensionaler Daten nach Goeken dargestellt. Zweckre-

Vgl. Mattos (1989), S. 481; Winter (1991) S. 20.; Mylopoulos (1998), S. 142; Vossen (2008), S. 60. Bspw. kann aus bestimmten Zutaten (Elementen) eine bestimmte Mahlzeit (Aggregat) zubereitet werden. Vgl. Mattos, Michels (1990), S. 163. sas Bei der Zubereitung einer Mahlzeit muss bspw. angegeben werden, wie, in welcher Reihenfolge, welche Zutaten kombiniert werden müssen, um das erwünschte Ergebnis zu erzielen. Inter-Elementbeziehungen können logischer (AND, OR, XOR, NOT) oder temporaler Natur (geht vor, folgt, Ist nebenläufIg) sein. SII6 Vgl. Wedekind (1981), S. 46 f. S87 Diese Vorgehensweise findet sich bspw. in Holten (1999), S. 87 ff.; Felden (2005); Goeken 584

(2006). S. 143 11.; Felden (2006). S. 220 11.

ModelIierungssprachen für das AvFe-Framework

190

geln aktivieren und deaktivieren mithilfe der eingeführten Aktivierungsmatrix ECA-Regeln. Die Metamodelle von ECA-Regel und Aktivierungsmatrix sind Gegenstand von Abschnitt 6.1.2.3, ehe in Abschnitt 6.1.2.4 die Teilmodelle zu einem Gesamt-Metamodell integriert werden. Die genannten Teilmodelle sowie der skizzierte Aufbau des Abschnitts ist übersichtsartig in Abbildung 42 dargestellt. Abbildung 42: Teilmodelle des sprachbasierten Metamodells

Zweckregel-Hierarchien (Abschnitt 6.1.2.1)

ECA-Regeln (Abschnitt 6.1.2.3)

Multidimensionale Daten (Abschnitt 6.1.2.2)

Aktivierungsmatrix (Abschnitt 6.1.2.3)

Integration der Metamodelle (Abschnitt 6.1.2.4)

6.1.2.1

Das Metamodell von Zweckregel-Hierarchien

Zweckregel-Hierarchien ermöglichen die Automatisierung von Führungsentscheidungen und sind wesentlicher Bestandteil des AvFe-Frameworks. In Abschnitt 5.2.1.1 wurde der Prozess einer einzelnen Zweckregel als EPK-Modell beschrieben. Die dort beschriebenen Ereignisse und Funktionen sind in jeder Zweckregel gleichartig und wiederholen sich in Zweckregel-Hierarchien entsprechend.''' Zur Beschreibung der abstrakten Syntax in Form eines Metamodelis erscheint es sinnvoll, zunächst die Struktur einer Zweckregel herzuleiten und diese dann auf Zweckregel-Hierarchien zu verallgemeinern.''' Die Überführung von Strukturen in entsprechende Prozesse erfolgt dann im Zuge einer physischen Implementierung. SB8 589

Vgl. Abbildung 35. Vgl. Stefanov et al. (200S), S. 3 ff. für einen Vorschlag, wie an die EPK multidimensionale Daten annotiert werden können.

Die abstrakte Syntax des AvFe-Frameworks

191

Eine Zweckregel besteht aus einem auslösenden temporalen Ereignis, einem Ziel und Informationen über den Zustand des Realitätsausschnitts. Anhand dieser drei Hauptbestandteile wird im Folgenden das Metamodell rekonstruiert. Ziele können, wie in Abschnitt 3.1.1 beschrieben, durch die Merkmale Inhalt,

Ausmaß, sachlicher Geltungsbereich und zeitlicher Bezug beschrieben werden. Um die Mapping-Beziehungen zwischen Zweckregeln und den übrigen TeilMetamodellen des AvFe-Frameworks eindeutiger modellieren zu können, werden die genannten Zielmerkmale bei der Erstellung des Metamodells (siehe Abbildung 43) leicht modifiziert und teilweise in eigenständige Konstrukte überführt. Ziele sind in Zweckregeln eine Aggregation aus den Konstrukten Soll-Daten, sachlicher Geltungsbereich und zeitlicher Bezug. Soll-Daten besitzen die Merkmale Kennzahl und Zielwert, womit der Inhalt bzw. das angestrebte Ausmaß eines Ziels beschrieben wird. 590 Eingeschränkt werden die SollDaten eines Ziels durch den sachlichen Geltungsbereich und den zeitlichen Bezug. Der zeitliche Bezug wird durch ein Hierarchieelement der Zeitdimension

beschrieben und der sachliche Geltungsbereich durch Hierarchieelemente anderer (sachlicher) Dimensionen. Das Ziel hat dabei genau einen (1,1) zeitlichen Bezug, besitzt genau einmal (1,1) Soll-Daten und kann multidimensional (l,n) durch einen sachlichen Geltungsbereich eingeschränkt werden. Die Zweckregel wird ausgelöst durch ein temporales Ereignis. Da der zeitliche Bezug entsprechend dem auslösenden Ereignis zu variieren ist, besteht eine enge Beziehung zwischen den Konstrukten zeitlicher Bezug und temporales Ereignis. Zur Identifikation von Problemen prüfen Zweckregeln die Zielerreichung durch einen Abgleich von Ziel und Zustand des Realitätsausschnitts. Da sich der Zustand auf den gleichen Realitätsausschnitt im gleichen Zeitraum beziehen muss, werden die Konstrukte zeitlicher Bezug und sachlicher Geltungsbereich, welche zur Beschreibung des Ziels eingeführt wurden, zur Beschreibung des Zustands wiederverwendet. Der Inhalt und Ausmaß des Zustands wird durch

S90

Die Beschränkung auf Zielwerte findet hier aus Komplexitätsgründen statt. Grundsätzlich kann das Ausmaß bspw. auch durch Maximierung. Minimierung oder niveaubezogene Größen beschrieben werden.

192

ModelIierungssprachen für das AvFe-Framework

das Konstrukt Ist-Daten beschrieben, welches für die (oben bereits eingeführte) Kennzahl einen Istwert enthält. Die Kardinalitäten der Beziehungen verhalten sich dabei analog zu den Beziehungen zwischen Ziel und den entsprechenden Konstrukten. Zur Realisierung von Zweckregel-Hierarchien müssen Ziele zu einem Zielsystem aggregiert werden. Zur Beschreibung von Zweck-Mittel-Beziehungen in Zielsysternen verwenden Zweckregel-Hierarchien Spezifizierungshierarchien. Dies ist im Metamodell durch den umdefinierten Beziehungstyp Spezifizierungshierarchie dargestellt. Das Metamodell der Zweckregel-Hierarchie ist in Abbildung 43

übersichtsartig dargestellt.

Die abstrakte Syntax des AvFe-Frameworks

193

Abbildung 43: Metamodell der Zweckregel-Hierarchie

Temporales Ereignis 1,1 bezieht sich auf 1,1

1,1-------11 Zeitlich~r f-1-----1,l Bezug

l,n

O,n pezifizierun

0 O,n

1,1

-Hierarchie

Soll-Daten

1 ,1

Sachlicher Geltungsbereich

l'l~nr---!,----, 1,1-

<E.:3> 1,I1

Ist-Daten

Mit dem Metamodell von Zweckregel-Hierarchien ist der wesentliche Bestandteil des AvFe-Frameworks bereits beschrieben. Um das Framework vollständig modellieren zu können, sind jedoch auch die weiteren Bestandteile (multidimensionale Daten, ECA-Regeln, Aktivierungsmatrix) durch sprach basierte Metamodelle zu beschreiben.

ModelIierungssprachen für das AvFe-Framework

194

6.1.2.2

Das Metamodell multidimensionaler Daten nach Goeken

Im Folgenden wird das sprach basierte Metamodell multi dimensionaler Datenmodelle nach GOEKEN dargestellt.

59l

In diesem wird die abstrakte Syntax der

qualifizierenden und quantifizierenden Informationen multidimensionaler Datenmodelle getrennt voneinander entwickelt und anschließend integriert. Daher wird in Abschnitt 6.1.2.2.1 zunächst die abstrakte Syntax qualifizierender Informationen in Form eines Metamodells dargestellt, ehe in Abschnitt 6.1.2.2.2 das Metamodell um die abstrakte Syntax quantifizierender Informationen ergänzt wird. 6.1.2.2.1

Die abstrakte Syntax qualifizierender Informationen

Es ist bereits darauf hingewiesen worden, dass bei der Modellierung qualifizierender Informationen multidimensionaler Datenmodelle neben der Typebene auch die Ausprägungsebene explizit modelliert werden muss, um Verdichtungs- bzw. Aggregationspfade sowie Strukturbesonderheiten nachvollziehen zu können.'92 Aus diesem Grund integriert GOEKEN die Ausprägungsebene in sein Metamodell und wählt diese als Ausgangspunkt der MetamodelIierung. Die qualifizierenden Informationen der Ausprägungsebene werden als Hier-

archieelemente bezeichnet.'" Mithilfe des Abstraktionsprinzips der Aggregation (po) bilden Hierarchieelemente Hierarchien. Diese Abstraktion, die zum ersten Ausschnitt des Metamodells führt, ist in Abbildung 44 dargestellt. 594

591

592 593

S94

Vgl. Goeken (2006), S. 143 ff. Ein konkurrierendes Metamodell der abstrakten Syntax multidimensionaler Datenmodelle findet sich in Holten (1999), S. 87 ff. Nach Auffassung des Verfassers ist das Metamodell nach Goeken jedoch allgemeingültiger und wird daher im

Folgenden verwendet. Vgl. Priebe, Pernul (2001), S. 83. Vgl. auch Fn. 525 und die dort angegebene Literatur. Goeken bezeichnet die Objekte der Ausprägungsebene als Hierarchieknoten. Nach Auffassung des Verfassers bringt der Begriff Hierarchieelement besser zum Ausdruck, dass es sich um Objekte der Ausprägungsebene handelt. Goeken verzichtet aus Gründen der Übersichtlichkeit auf die Darstellung von Merkmalen und Kardinalitäten. Auch Wedekind definiert für Grundbegriffe keine Merkmale, sondern setzt ein gewisses Fach-Vorverständnis voraus. Vgl. Wedekind (1981), S. 51 f.

195

Die abstrakte Syntax des AvFe-Frameworks

Abbildung 44: Metamodell multidimensionaler Daten (I)

Hierarchielement he, (mitO
po

Hierarchie

Die Hierarchieelemente he, können im Metamodell weiter differenziert werden nach der Rolle, die sie innerhalb einer Hierarchie einnehmen. Dabei gibt der Index i die Hierarchieebene an. •

Primäre Hierarchieelemente he. sind nicht weiter zerlegbar und werden mithilfe der Elementassoziation abstrahiert zu übergeordneten Hierarchie-

elementen. •

Das Hierarchieelement der obersten Ebene m wird als Top-Hierarchieelement hm bezeichnet. Es stellt die (indirekte) Vereinigungs menge aller hierarchisch untergeordneten Hierarchieelemente dar.

•

Die Hierarchieelemente he, (mit 0 < n <mI zwischen der untersten und der obersten Ebene fassen untergeordnete Elemente und Mengen zusammen und sind selbst Teilmenge einer übergeordneten Menge.

Übergeordnete Hierarchieelemente fungieren in Hierarchien als wertmäßige Stellvertreter untergeordneter Hierarchieelemente. Zur Beschreibung der Struktur von Hierarchien verwendet GOEKEN daher das Abstraktionsprinzip der Assoziation.

59s

Während primäre Hierarchieelemente mittels Elementassoziati-

on (eo) zu übergeordneten Mengenelementen abstrahiert werden, kommt bei der Abstraktion von Mengenelementen die Mengenassoziation (550) zum Tragen. Durch die Kombination der bei den Assoziationsarten können n-Ebenen59

Hierarchien realisiert werden. ' Abbildung 45 illustriert anhand der bereits bekannten Dimension Vertriebsort die Verwendung von Element- und Mengenassoziation in Hierarchien. Mithilfe des Abstraktionsprinzips der Elementassoziation werden die primären Hierarchieelemente Gießen, Marburg und StadtS95 596

Vgl. Goeken (2006), S. 157. Vgl. Abschnitt 6.1.1.

ModelIierungssprachen für das AvFe-Framework

196

allendorf zu dem übergeordneten Mengenobjekt Mitte abstrahiert. Zusammen mit den Mengenelementen Nord und Süd wird dann im Zuge einer Mengenassoziation das Mengenelement Gesamtvertrieb gebildet. Abbildung 45: Assoziation in einer Hierarchie

o

eo

Vgl. Goeken (2006), S. 159.

Mithilfe der dargestellten Erweiterungen kann nun das Metamodell der qualifizierenden Informationen auf Ausprägungsebene komplettiert werden: In Abbildung 46 ist zunächst die disjunkte und totale (d,t) Spezialisierung der Hierarchieelemente in heo, he" und he m zu erkennen. In dem Metamodell sind zudem die verwendeten Abstraktionsbeziehungen (eo und

550)

zwischen den

spezialisierten Hierarchieelementen enthalten. Darüber hinaus sind in dem Metamodell noch Gleichordnungsbeziehungen sowie Über- und Unterordnungsbeziehungen zwischen Hierarchieelementen dargestellt. Diese Aggregationen stellt GOEKEN mithilfe der uminterpretierten Beziehungstypen Hier-

archieebene bzw. Hierarchiepfad dar.'97

591

Goeken nennt bei der Konstruktion von Hierarchieebene und Hierarchiepfad nicht explizit das Abstraktionsprinzip der Aggregation.

Die abstrakte Syntax des AvFe-Frameworks

197

Abbildung 46: Metamodell multidimensionaler Daten (11)

Vgl. Goeken (2006), S. 163.

Nach Fertigstellung des Metamodells auf Ausprägungsebene ist nun das Metamodell der Typebene zu entwickeln. Wie in der Modellierung üblich, konstruiert GOEKEN die Konstrukte der Typebene - im Folgenden als Dimensionsknoten bezeichnet - mithilfe der Klassifikation. Die abstrahierten Hierarchieelemente entstammen dabei immer einer Hierarchieebene, sodass durch Klassifikation (io) die Dimensionsstruktur auf Typebene entsteht. Diese Abstraktion ist in Abbildung 47 durch die horizontalen Beziehungen zwischen Hierarchieelementen und Dimensionsknoten dargestellt. Zwischen den Dimensionsknoten einer Dimension liegt eine Generalisierungsbeziehung (sto) vor, da bereits abstrahierte Typen weiter abstrahiert werden. In linken Teil (a) von Abbildung 47 ist diese Abstraktion für die bekannte Dimension Vertriebsort mithilfe der vertikalen Beziehung dargestellt: Der Dimensionsknoten Filiale wird generalisiert zu Vertriebsregion, welcher wiederum zum Dimensionsknoten Alle Regionen abstrahiert wird. Wie zu erkennen ist, werden mithilfe der Generalisierung die multidimensionalen Navigationswege in einem Hypercube realisiert.

ModelIierungssprachen für das AvFe-Framework

198

Abbildung 47: Abstraktionsprinzipien auf Typ- und Ausprägungsebene (a) Typebene

(b) Aulprllunpebeße

I Alle Regionen

;0

Gesamtvertrieb

ss

Slo

IVertriebsregion

10

Slo

I

Filiale

r

/ II

Gießen

Mitte

00

Marburg

sso

550

I I

I

I I

Nord

SCd

I

0

II

Stadtallendorf

I

Vgl. Gooken (2006), S. 164.

Nachdem die Abstraktionsprinzipien zwischen Typ- und Ausprägungsebene sowie zwischen den Dimensionsknoten verdeutlicht wurden, kann nun das Metamodell auf Typebene rekonstruiert werden (vg!. zu den Ausführungen im Folgenden Abbildung 48). Wie bereits erläutert, werden Hierarchieelemente durch Klassifikation zu Dimensionsknoten. Durch das Abstraktionsprinzip der Aggregation (po) entsteht aus Dimensionsknoten eine Dimension. Dimensionsknoten werden je nach ihrer Rolle in Dimensionen - analog zu Hierarchieelementen - in primäre Dimensionsknoten DKo, Dimensionsknoten DKn (mit l
199

Die abstrakte Syntax des AvFe-Frameworks

parallelen Hierarchien auf, weshalb die Begriffe Dimensionsebene und Dimensionsknoten oftmals synonym verwendet werden.

59

'

Das damit vollständig rekonstruierte Metamodell der qualifizierenden Informationen findet sich in Abbildung 48. Abbildung 48: Metamodell multidimensionaler Daten (111)

Hierarchie

Dimension

Vgl. Goeken 120061, S. 167.

S98

Vgl. Goeken (2006), S. lS7 und S. 167. Bisher wurden auch in dieser Arbeit die Begriffe synonym verwendet.

ModelIierungssprachen für das AvFe-Framework

200

6.1.2.2.2

Die abstrakte Syntax quantifizierender Informationen

Quantifizierende Informationen multidimensionaler Datenmodelle repräsentieren den Gegenstand der Untersuchung und werden von GOEKEN als Kennzahlen bezeichnet.

59

'

Dabei ist - ebenso wie bei qualifizierenden Informationen -

zwischen der Kennzahl auf Typebene und der Kennzahlenausprägung zu unterscheiden. Die beiden Konstrukte sind durch das Abstraktionsprinzip der Klassifikation (io) miteinander verbunden. Kennzahlen und Kennzahlenausprägungen können mithilfe von Kennzahlensystemen hierarchisch organisiert werden. Im Metamodell wird dieser Sachverhalt abgebildet, indem die rekursiven Beziehungstypen Kennzahlensystem bzw. Kennzahlenberechnung uminterpretiert werden. Kennzahlen werden in multidimensionalen Datenmodellen durch qualifizierende Informationen (multidimensional) eingeschränkt und näher bezeichnet. Die Zuordnung von Kennzahlen zu qualifizierenden Dimensionsknoten bezeichnet GOEKEN als Fakt. Der uminterpretierte Beziehungstyp Fakt verbindet die quantifizierenden und die qualifizierenden Informationen des Metamodells. Das nun vollständige Metamodell multidimensionaler Daten ist übersichtsartig in Abbildung 49 dargestellt, wobei die quantifizierenden Informationen grau hinterlegt sind.

599

Goeken spezialisiert Kennzahlen In Anlehnung an die betriebswlrtschaftllche Uteratur In abgeleitete Kennzahlen und Basiskennzahlen sowie in relative und absolute Kennzahlen. Die Unterscheidungen werden hier nicht nachvollzogen und auch im Metamodell nicht dargestellt. Vgl. Goeken (2006), S. 177 f.

201

Die abstrakte Syntax des AvFe-Frameworks

Abbildung 49: Metamodell der abstrakten Syntax multidimensionaler Datenmodelle AuspriJuqsebene

Hierarchie

.... '0 '-..,,-------------'

....

Vgl. Goeken (2006), S. 186.

202

ModelIierungssprachen für das AvFe-Framework

6.1.2.3

Die Metamodelle von ECA-Regel und Aktivierungsmatrix

Im Rahmen des AvFe-Frameworks besteht eine Entscheidung darin, ECARegeln zu aktivieren oder zu deaktivieren, wobei die aktiven Regeln bei Eintritt eines definierten Ereignisses automatisch reagieren. Im Folgenden wird daher neben der abstrakten Syntax von ECA-Regeln auch die abstrakte Information der Aktivierungsmatrix rekonstruiert, die entscheidungsrelevante Informationen beinhaltet, welche ECA-Regel bei einem Entscheidungsproblem zu aktivie-

ren ist. Eine ECA-Regel entsteht durch Aggregation der bereits genannten Bestandteile Ereignis, Bedingung und Aktion. '00 Dieser Sachverhalt wird im Metamodell der ECA-Regeln (siehe Abbildung 50) dargestellt, indem der uminterpretierte Beziehungstyp ECA-Regel die Entitätstypen Ereignis, Bedingung und Aktion verbindet. Die Kardinalitäten verdeutlichen, dass eine ECA-Regel aus genau einem (1,1) Ereignis, einer optionalen (0,1) Bedingung und genau einer (1,1) Aktion besteht. Abbildung 50: Metamodell der ECA-Regel

"-1 <6? Ir----··· I

Erelsnls

~

Wie bereits in Abschnitt 2.6 erläutert, können Ereignisse durch die Merkmale Vorzustand und Folgezustand charakterisiert werden. Neben elementaren Ereignissen können auch komplexe Ereignisse Bestandteil von ECA-Regeln sein. Diese entstehen durch Aggregation elementarer Ereignisse, was in dem Meta600

Alternative Metamodelle von ECA-Regeln finden sich in Herbst, Myrach (1996); Wagner (2002); Schiefer et al. (2007).

203

Die abstrakte Syntax des AvFe-Frameworks

modell durch den uminterpretierten, rekursiven Beziehungstyp komplexes Ereignis dargestellt ist. Komplexe Ereignisse besitzen im Metamodell dieser

Arbeit in Anlehnung an ZIMMER und UNlAND die Merkmale Struktur, Instanzauswahl und Instanzverbrauch.,ol Bedingungen und Aktionen als weitere Bestandteile von ECA-Regeln wurden bereits in Abschnitt 4.2 ausführlich charakterisiert und werden im Metamodell als Grundbegriffe im Sinne von WEDEKIND verwendet, für die keine Merkmale zu definieren sind.

60

'

Entscheidungen über das Aktivieren und Deaktivieren von ECA-Regeln werden 60

im Rahmen des AvFe-Frameworks mithilfe der Aktivierungsmatrix getroffen. ' Diese ist genau einer Hypercube-Zelle zugeordnet und enthält Informationen darüber, ob bei einem Entscheidungsproblem, das sich auf die entsprechende Hypercube-Zelle bezieht, Handlungsalternativen in Form von ECA-Regeln zu aktivieren oder zu deaktivieren sind. Dabei wird geprüft, in welchem Kennzahlenbereich eine ausgewählte Kennzahl der Hypercube-Zelle liegt. Eine Aktivierungsmatrix stellt somit eine Aggregation von Kennzahlenbereich und Handlungsalternativen dar. Diese Abstraktion ist im Metamodell in Abbildung 51 dargestellt, indem Kennzahlenbereich und Handlungsalternativen durch den uminterpretierten Beziehungstyp Aktivierungsmatrix verbunden werden. Die Information über Aktivieren und Deaktivieren wird in dem Merkmal Aktivierung gespeichert. Mithilfe von Kardinalitäten ist in dem Metamodell zudem dargestellt, dass eine Aktivierungsmatrix über zwei bis viele (2,n) Handlungsalternativen und mindestens ein bis viele (1,n) Kennzahlenbereiche verfügt. Darüber hinaus ist in Abbildung 51 die Mapping-Beziehung zwischen der Handlungsalternative und ECA-Regel enthalten. Diese Beziehung integriert die Metamodelle von Aktivierungsmatrix und ECA-Regel und besitzt (in beide Richtungen) die Komplexität (1,1).

601 602

603

Vgl. Zimmer, Unland (1999), S. 395 ff. Vgl. Wedekind (1981), S. 51 f. Vgl. auch die Ausführungen in Abschnitt 5.2.1.3.

ModelIierungssprachen für das AvFe-Framework

204

Abbildung 51: Metamodell von ECA-Regel und Aktivierungsmatrix Alnlvlarunpmltrlx

,------, lCennzahlenberelch

I

1,' Handlunss-

alternative

i===================<:~mapptluf >=======~ ECA-Repl 1,1 1,1

g

0,1

" Ereignis

6,1,2.4

11

f---1,1

Aktion

Integration der (Teil-)Metamodelle

Nachdem nun die einzelnen Teil-Metamodelle rekonstruiert sind, können diese im vorliegenden Abschnitt zu einem Gesamt-Metamodell integriert werden. Die Integration zwischen den Teilmodellen erfolgt durch die Rekonstruktion von Mapping-Beziehungen zwischen den Konstrukten der Teilmodelle. Ausgangspunkt ist das Metamodell multidimensionaler Daten nach Goeken. Bei dessen Rekonstruktion wurden Typ- und Ausprägungsebene eingeführt. Diese Unterscheidung erweist sich als hilfreich, da sich die Bestandteile von Zweckregel-Hierarchien auf ausgeprägte Konstrukte des multidimensionalen Datenmodells beziehen. Soll- und Ist-Daten der Zweckregel-Hierarchie sind verbunden mit Kennzahlenausprägungen multidimensionaler Daten. Sachlicher Geltungsbereich und zeitlicher Bezug der Zweckregel-Hierarchie beziehen sich

Die abstrakte Syntax des AvFe-Frameworks

205

auf Hierarchieelemente multidimensionaler Daten und die Spezifizierungshierarchie beschreibt in Zweckregel-Hierarchien Über- und Unterordnungsbeziehungen, was in multidimensionalen Daten durch den Hierarchiepfad repräsentiert wird. Darüber hinaus besteht eine Beziehung zwischen dem Metamodell multidimensionaler Daten und dem Metamodell der Aktivierungsmatrix durch die Konstrukte Fakt und Aktivierungsmatrix. Diese Beziehung ermöglicht die Zuordnung einer Aktivierungsmatrix zu genau einer (1,1) Hypercube-Zelle. Es wird weiter geprüft, in welchem Kennzahlenbereich die Kennzahlenausprägung des Fakts liegt. Das nun vollständig rekonstruierte Gesamt-Metamodell des AvFe-Frameworks ist übersichtsartig in Abbildung 52 dargestellt. Um die Übersichtlichkeit zu steigern, wurden die bisher verwendeten ER-Attribute in dem Modell nicht dargestellt.

206

ModelIierungssprachen für das AvFe-Framework

Abbildung 52: Metamodell des AvFe-Frameworks

,

i~

8.~

E ..

.!,::;

,

~,

1!

iäi

II1II

~

~ %

,

~

1

:l

.. ~i L-~

•• ~

.•• ~

j~-

~-

------0 -

l-

""

2111

J li

~

a :l1!

- .. -JO]

rr , 1l

1

,

i

I

~J!

I

I "• " ~

•• ~!

~

1i

,

,~

••

J

I

'0

.!l

207

Auswahl und Konstruktion von Modellierungssprachen

Nachdem nun das sprachbasierte Metamodell des AvFe-Frameworks vollständig hergeleitet ist, können im folgenden Abschnitt geeignete Modellierungssprachen ausgewählt und konstruiert werden. 6.2

Auswahl und Konstruktion von Modellierungssprachen

Der vorliegende Abschnitt zielt darauf ab, semi-formale Modellierungsspraehen für die Teilmodelle des AvFe-Frameworks auszuwählen oder zu konstruieren. Wenn für Teilmodelle bereits ModelIierungssprachen existieren, so wird eine Modellierungssprache beispielhaft ausgewählt. Anschließend wird die Eignung der ausgewählten Modellierungssprache mithilfe einer sogenannten Repräsentationsanalyse geprüft. Existiert dagegen für ein Teilmodell bisher keine Modellierungssprache, so wird eine entsprechende Modellierungsspraehe konstruiert und vorgeschlagen. Der Abschnitt ist folgendermaßen aufgebaut: Zunächst wird in Abschnitt 6.2.1 die Repräsentationsanalyse von Modellierungssprachen erläutert. Anschließend wird in Abschnitt 6.2.2 die Repräsentation multidimensionaler Daten durch das MER-Modell geprüft. Davon ausgehend werden in Abschnitt 6.2.3 Erweiterungen des MER-Modells vorgeschlagen, um Zweckregel-Hierarchien modellieren zu können. In Abschnitt 6.2.4 wird mit dem regel basierten ModelIierungsansatz eine Modellierungssprache für ECA-Regeln vorgestellt und analysiert. Aktivierungsmatrizen werden in der oben dargestellten Tabellenform verwendet und eine Repräsentationsanalyse scheint daher verzichtbar.

6.2.1

Repräsentationsanalyse von Modellierungssprochen

Zur Analyse von Modellierungssprachen wird von WAND und WEBER die sogenannte Repräsentationsanalyse vorgeschlagen.'04 Bei dieser wird geprüft, ob mit den Konstrukten einer Modellierungssprache Modelle erstellt werden können, die eine gute Repräsentation des entsprechenden Realitätsausschnitts 6OS darstellen. WAND und WEBER schlagen als Analyse-Referenz die Ontologie von BUNGE vor und prüfen in der Repräsentationsanalyse durch Repräsentationszuordnung, ob die Konstrukte einer Modellierungssprache die Konstrukte der

604

605

Vgl. Wand, Weber (1993), S. 219 ff.i Wand, Weber (1995), S. 208 5.287 ff.; Wand, Weber (2002), S. 365 ff. Vgl. Wand, Weber (1995), S. 209.

ff.i Wand et al. (1995),

ModelIierungssprachen für das AvFe-Framework

208

Bunge-Ontologie abbilden können.'" Eine Modellierungssprache wird demnach als vollständig bezeichnet, wenn sie Konstrukte zur Verfügung stellt, die alle Phänomene des Realitätsausschnitts modellieren können.

5O

'

Darüber hin-

aus ist eine Modellierungssprache eindeutig, wenn zwischen jedem Konstrukt der ModelIierungssprache eine l:l-Beziehung zu einem Konstrukt der Referenz besteht. Ist eine Modellierungssprache nicht eindeutig, so können folgende Typen sprachlicher Mängel unterschieden werden:"· •

Konstruktüberladung: Mehrere Konstrukte der Referenz sind einem Konstrukt der zu analysierenden ModelIierungssprache zugeordnet.

•

Konstruktredundanz: Mehrere Konstrukte der zu analysierenden Modellierungssprache sind einem Konstrukt der Referenz zugeordnet.

•

Konstruktüberschuss: Ein Konstrukt der zu analysierenden Modellierungssprache kann keinem Konstrukt der Referenz zugeordnet werden.

•

Konstruktdefizit: Ein Konstrukt der Referenz wird nicht in der zu analysierenden Modellierungssprache repräsentiert.

Im Anschluss an eine Repräsentationsanalyse kann die Eignung einer Modellierungssprache für einen bestimmten Zweck beurteilt werden und es können verschiedene Modellierungssprachen miteinander verglichen werden. Darüber hinaus können Modellierungssprachen als Konsequenz aus einer Repräsentationsanalyse entsprechend geändert und weiterentwickelt werden.

609

Im Folgenden wird mithilfe der Repräsentationsanalyse geprüft, ob eine Modellierungssprache geeignet ist, ein Teilmodell des AvFe-Frameworks zu modellieren. Da der Einsatz von Ontologien nicht mit der wissenschaftstheoretischen Position der Arbeit harmoniert, werden - einem Vorschlag von ROSEMANN und GREEN folgend - die sprachbasierten Metamodelle aus Abschnitt 6.1 als Refe-

'" Vgl. Wand, Weber (1993), S. 221 f.; Bunge (1977); Bunge (1979). 607 Vgl. hierzu und Im Folgenden Wand, Weber (1995), S. 209. 608 609

Vgl. Wand, Weber (2002), S. 365. Die Repräsentationsanalyse von Wand und Weber wurde in der Literatur bereits vielfach eingesetzt. Eine Übersicht findet sich bspw. in Rosemann, Green (2002), S. 76.

Auswahl und Konstruktion von Modellierungssprachen

209

510

renz eingesetzt. Um einen Vergleich durchführen zu können, sind zu diesem Zweck auch die Modellierungssprachen in Form von Metamodellen zu formulieren. 6.2.2

Das multidimensionale Entity-Relationship-Modell zur Modellierung multidimensionaler Daten

Es existiert eine Vielzahl an Modellierungssprachen zur Erstellung multidimensionaler Datenmodelle. Es wäre möglich, jede existierende Modellierungssprache mit der Repräsentationsanalyse zu evaluieren und anhand bestimmter Kriterien eine noptimale" Modellierungssprache zu bestimmen.

611

Zum einen

sind derartige Kriterienkataloge jedoch durch eine gewisse Beliebigkeit gekennzeichnet. Zum anderen haben unterschiedliche Modellierer (vielleicht je nach Organisation oder je nach Modellnutzer) bevorzugte Modellierungssprachen. Im folgenden Abschnitt wird mit dem MER-Modell eine Modellierungssprache für multidimensionale Datenmodelle ausgewählt und es wird die Repräsentation multidimensionaler Daten durch diese Modellierungssprache geprüft. Damit wird gezeigt, wie die Repräsentationsanalyse mit Metamodellen des AvFeFrameworks durchgeführt werden kann. Je nach Anforderung und Präferenz können auch andere multidimensionale ModelIierungssprachen als das MERModell auf ihre Eignung geprüft und ggf. verwendet werden. Der Abschnitt ist folgendermaßen aufgebaut: Zunächst wird das MER-Modell vorgestellt, wobei in Abschnitt 6.2.2.1 die abstrakte Syntax in Form eines sprachbasierten Metamodells dargestellt wird. Anschließend wird in Abschnitt 6.2.2.2 kurz auf die konkrete Syntax der Sprache eingegangen, ehe in Abschnitt 6.2.2.3 eine Repräsentationsanalyse durchgeführt wird. Bei dieser werden die Konstrukte des MER-Metamodells den Konstrukten des Metamodells multidimensionaler Daten aus Abschnitt 6.1.2.1 zugeordnet und auf Vollständigkeit sowie Eindeutigkeit geprüft.

610 611

Vgl. Rosemann, Green (2002). Eine Übersicht sowie eine Analyse verschiedener Modellierungstechniken findet sich bspw. in Goeken (2006), S. 191 ff.

210

ModelIierungssprachen für das AvFe-Framework

6.2.2.1

Die abstrakte Syntax des MER-Modells

Das MER-Modell ist eine semi-formale Modellierungssprache zur konzeptionellen Modellierung multidimensionaler Datenstrukturen und stellt eine Erweiterung des ER-Modells dar.

612

Ausgangspunkt der Weiterentwicklung war die

Feststellung, dass herkömmliche Techniken zur Datenmodellierung, wie bspw. das ER-Modell, zur Modellierung multidimensionaler Datenstrukturen nur sehr bedingt geeignet sind.'13 SAPIA et al. begründen ihre Erweiterung durch ein sprachbasiertes Metamodell, das im Folgenden vorgestellt wird.'14 Die Autoren führen zur Modellierung multidimensionaler Datenstrukturen drei zusätzliche Entitätstypen ein, die allesamt Spezialisierungen der ER-Konzepte sind:'" •

Die Dimensionsebene (dimension level) ist eine Spezialisierung des EREntitätstyps und ist zur Modellierung von qualifizierenden Informationen (auf Typebene) in multidimensionalen Datenstrukturen geeignet.

•

Die hierarchische Beziehung zwischen zwei Dimensionsebenen kann im

MER-Modell mithilfe des hierarchischen Beziehungstyps (rolls-up-to relationship) modelliert werden, wobei die Beziehung von der niedriger zur höher aggregierten Dimensionsebene geht und keine Zyklen in Dimensionen entstehen dürfen.'16 Der hierarchische Beziehungstyp stellt eine Spezialisierung des ER-Beziehungstyps dar, wobei es sich um einen binären Beziehungstyp handelt, d. h. dieser verbindet genau zwei Dimensionsebenen

miteinander. •

612 613

Der Faktenbeziehungstyp (fact relation) ist ebenfalls eine Spezialisierung des Beziehungstyps. Es handelt sich dabei um einen n-ären Beziehungstyp,

Vgl. zum ER-Modell Anhang A. Vgl. zum MER-Modell Sapia et al. (1999). Vgl. Sapia et al. (1999). S. 105. Es gibt eine Viehlzahl an Vorschlägen, wie mithilfe des ERModells auch multidimensionale Strukturen modelliert werden können. Einen Überblick über

die verschiedenen Ansätze gibt bspw. Goeken (2006), S. 192 ff. 614

615 616

Das Metamodell des ER-Modells findet sich in Abschnitt A.l, wobei das dort präsentierte

Metamodell leicht von dem von Sapia et. al verwendeten ER-Metamodell abweicht. Da nach Auffassung des Verfassers das in Abschnitt A.l präsentierte ER-Meta modell vollständiger und eindeutiger ist, wird auch das MER-Metamodell von Sapia et al. im Folgenden leicht modifiziert, um es als Erweiterung des In dieser Arbeit verwendeten ER-Metamodells darstellen zu können. Vgl. Sapia et al. (1999), S. 110. Vgl. Sapia et al. (1999), S. 109 ff. Sapia et al. (1999), S. 110 formulieren zu diesem Zweck eine Integritätsbedingung.

Auswahl und Konstruktion von Modellierungssprachen

211

der die primären Dimensionsebenen verschiedener Dimensionen miteinander verbindet.·

17

Mithilfe des Faktenbeziehungstyps kann die Trennung von

qualifizierenden Dimensionsebenen und quantifizierenden Kennzahlen, bei SAPIA et al. als Measures bezeichnet, modelliert werden. Die Kennzahlen werden als ER-Attribute an den Faktenbeziehungstyp annotiert. Das skizzierte sprach basierte Metamodell des MER-Modells ist übersichtsartig in Abbildung 53 dargestellt, wobei auf der linken Seite (al die Konstrukte des ER-Modells und auf der rechten Seite (bl die dargestellten Erweiterungen des MER-Modells abgebildet sind. Abbildung 53: 5prachbasiertes Metamodell des MER-Modells (bi MER-Modall

B

~

~

-"

wbindet

Vgl. Sapia et al. (1999), S. 110.

617

Vgl. Sapia et al. (1999), S. 110 f.

ModelIierungssprachen für das AvFe-Framework

212

6.2.2.2

Die konkrete Syntax des MER-Modells

In Abbildung 54 ist die konkrete Syntax des MER-Modells nach SAPIA et al. dargestellt, welche im Folgenden zur Modellierung multidimensionaler Datenstrukturen (auf Typebene) eingesetzt wird. Abbildung 54: Die konkrete Syntax des MER-Modells level name

Dimensionsebene

Hierarchischer Beliehungstyp

~

~

~ ~

F,k<ecb"iehcog>
Attribut

Vgl. Sopio et 01. (1999), S. 111.

6.2.2.3

Repräsentationsanalyse des MER-Modells

Als Referenz für eine Repräsentationsanalyse fungiert das Metamodell multidimensionaler Daten aus Abschnitt 6.1.2.1. Vorab ist allerdings zu konstatieren, dass das MER-Modell - ebenso wie das ER-Modell - lediglich die Typebene betrachtet. Da die Ausprägungsebene in multidimensionalen Datenmodellen jedoch explizit zu modellieren ist, kann bereits vorab festgestellt werden, dass die Modellierungssprache nicht vollständig ist und die Repräsentation der Konstrukte der Ausprägungsebene im Folgenden nicht einzeln durchzuprüfen ist."18 Das genannte Referenz-Metamodell wird daher eingeschränkt auf die Typebene. Im Folgenden werden die Konstrukte der Referenz einzeln durchgeprüft: Die Dimension wird im MER-Modell nicht explizit modelliert, sodass hier ein Konstruktdefizit festzustellen ist. Das MER-Modell bezeichnet die Konstrukte zur Modellierung qualifizierender Information als Dimensionsebenen. Dabei 618

Die Ausprägungsebene multidimensionaler Datenstrukturen wird auch von anderen existierenden Modellierungssprachen nicht betrachtet, ansonsten wäre eine andere Modellierungssprache ggf. zu bevorzugen.

Auswahl und Konstruktion von Modellierungssprachen

213

wird - wie in Literatur verbreitet - nicht zwischen den Konstrukten Dimensi-

onsknoten und -ebene unterschieden, sodass hier eine Konstruktüberladung zu konstatieren ist. Das Konstrukt Dimensionspfod wird im MER-Modell eindeutig durch den hierarchischen Beziehungstyp repräsentiert. Ebenso sind den Referenzkonstrukten Fakt und Kennzahl eindeutig die MER-Konstrukte Faktenbeziehungstyp bzw. Attribut zugeordnet. Die Ergebnisse der RepräsentationsanaIyse sind übersichtartig in Tabelle 16 dargestellt. Tabelle 16: Repräsentationsanalyse des MER-Modells

Konstrukt des Metamodells

Konstrukt des MER-Modells

multIdimensIonaler Daten

Ergebnis der Repräsentationsanalyse

Dimension

nicht vorhanden

Konstruktdefizit

Dimensionsknoten

Dimensionsebene

Konstruktüberladung

DImensionsebene

DImensionsebene

KonstruktClberladung

Dimensionspfad

hierarchischer Beziehungstyp

Eindeutig

Fakt

Faktenbeziehungstyp

Eindeutig

Kennzahl

Attribut

Eindeutig

Zusammenfassend kann festgestellt werden, dass mithilfe des MER-Modells multidimensionale Datenmodelle auf Typebene gut modelliert werden können. Die Konstruktüberladung des Konstrukts Dimensionsebene führt in parallelen Hierarchien zu Schwierigkeiten. Da in den Programmhierarchien des AvFeFrameworks jedoch keine parallelen Hierarchien verwendet werden, schlägt dieses Defizit bei der Modellierung multidimensionaler Daten des AvFeFrameworks nicht durch. Auch das Konstruktdefizit bei der Dimension ist als nicht entscheidend anzusehen, da davon ausgegangen werden kann, dass Dimensionen in MER-Modellen zumindest implizit enthalten sind."19

619

So sprechen Sapia et al. bspw. mehrfach von der .,time dimension

H

•

214

Modellierungssprachen für das AvFe-Framework

6.2.3

Ein erweitertes MER-Modell zur Modellierung von ZweckregelHierarchien

Zweckregel-Hierarchien sind der zentrale Bestandteil des AvFe-Frameworks, weshalb deren ModelIierung eine entscheidende Bedeutung zukommt. Zugleich sind Zweckregel-Hierarchien jedoch ein innovatives und neuartiges Artefakt, für das bisher keine domänenspezifische Modellierungssprache existiert. In Abschnitt 6.1.2.4 wurde festgestellt, dass die Konstrukte von ZweckregelHierarchien Mapping-Beziehungen zu Konstrukten der Ausprägungsebene des multidimensionalen Datenmodells besitzen. Da die Ausprägungsebene von multidimensionalen Modellierungssprachen jedoch nicht betrachtet wird, erweitert der Verfasser im Folgenden die ausgewählte multidimensionale Modellierungssprache MER um Konstrukte, sodass Zweckregel-Hierarchien modelliert werden können."o Nach Definition der abstrakten Syntax wird in Abschnitt 6.2.3.2 eine konkrete Syntax zur Modellierung von Zweckregel-Hierarchien vorgeschlagen. 6.2.3.1

Die abstrakte Syntax des erweiterten MER-Modells

Die abstrakte Syntax des erweiterten MER-Modells wird im vorliegenden Abschnitt in Form eines erweiterten Metamodells dargestellt.'" Dabei werden folgende Konstrukte eingeführt: •

Das Hierarchieelement ist eine Instanziierung (io) der Dimensionsebene. Hierarchieelemente dienen im Folgenden dazu, die qualifizierenden Informationen einer Zweckregel zu modellieren. Zu erwähnen ist, dass das Hierarchieelement der Zeithierarchie variiert. Wenn bspw. der vergangene Monat analysiert werden soll, so ändert sich je nach Ausführungsdatum dieses Hierarchieelement entsprechend.

•

Die Zweekregel-Hierarehie ist eine Instanziierung (io) des Faktenbeziehungstyps und verbindet die Hierarchieelemente aus verschiedenen Hierarchien miteinander. Die Zweckregel-Hierarchie wird um ausgeprägte Attribute ergänzt, welche 5011- und Ist-Daten beschreiben.

&20

621

Goeken (2006), S. 191 ff. evaluiert verschiedene multidimensionale Modellierungssprachen und stellt dabei für sämtliche Sprachen fest, dass die Ausprägungsebene nicht betrachtet wird. Bei der Weiterentwicklung von Modellierungssprachen ist es verbreitet, existierende Metamodelle zu erweitern. Vgl. Grief, Seidimeier (2005); Seel, Vanderhaegen (2005)

Auswahl und Konstruktion von Modellierungssprachen

•

21S

Hierarchische Beziehungen verbinden Hierarchieelemente miteinander und

stellen eine Instanziierung (io) des Hierarchischen Beziehungstyps dar. Das Konstrukt wird in Zweckregel-Hierarchien zur Modellierung der Spezifizierungshierarchie verwendet, welche bei Zweckregel-Hierarchien einen eindeutigen Navigationspfad zur Verfügung stellen muss.'" • Eine Zweckregel-Hierarchie wird ausgelöst durch ein temporales Ereignis. Dieses Konstrukt steht in keiner Beziehung zum originären MER-Modell und wird ebenfalls an das Konstrukt Zweckregel-Hierarchie annotiert. In Abbildung 55 ist die abstrakte Syntax von ER-Modell (a), MER-Modell (b) und erweitertem MER-Modell (c) übersichtsartig dargestellt. Die Konstrukte des erweiterten MER-Modells repräsentieren dabei die Ausprägungsebene des multidimensionalen Datenmodells.

622

Vgl. Abschnitt 5.2.2.1.

216

ModelIierungssprachen für das AvFe-Framework

Abbildung 55: Erweiterungen des MER-Metamodells

~

[ill,~,

~ ~~~v~

~---v-lEJ "~

"~

Auswahl und Konstruktion von Modellierungssprachen

217

Im Folgenden könnte noch mittels einer Repräsentationsanalyse geprüft werden, ob das erweiterte MER-Modell die im Metamodell einer ZweckregelHierarchie geforderten Konstrukte repräsentiert. Da das MER-Modell jedoch um genau die im Metamodell einer Zweckregel-Hierarchie geforderten Konstrukte erweitert wurde, würde die Repräsentationsanalyse einen fragwürdigen Zirkel darstellen und unterbleibt an dieser Stelle.

6.2.3.2

Die konkrete Syntax des erweiterten MER-Modells anhand eines Fallbeispiels

Nachdem die abstrakte Syntax des erweiterten MER-Modells dargestellt wurde, wird nun eine konkrete Syntax vorgeschlagen, die zum einen an die typisierten Konstrukte des MER-Modells erinnert, zum anderen aber auch unterscheidbar von diesen ist. Die Konstrukte Hierarchieelement und ZweckregelHierarchie werden daher mit den gleichen Symbolen wie die typisierten Konstrukte, allerdings mit doppelter Umrandung dargestellt. Hierarchische Beziehungen werden mit einer doppelten Pfeilspitze symbolisiert. Die Ereignisnotation ist der EPK entliehen, wurde jedoch ebenfalls mit einer doppelten Umrandung versehen.

623

In Abbildung 56 ist mithilfe der konkreten Syntax des erweiterten MER-Modells eine Zweckregel-Hierarchie dargestellt. Ziel und Zustand werden beschrieben durch die Hierarchieelemente Alle Kunden, Konsumentenkredite und Gesomt-

vertrieb. Darüber hinaus ist aus der Zeitdimension das Hierarchieelement des jeweils vergangenen Monats hinzuzufügen, wenn die Zweckregel-Hierarchie durch das temporale Ereignis am 1. eines Monats ausgelöst wird. Wenn ein Entscheidungsproblem mit den genannten Hierarchieelementen nicht gelöst werden kann, so verfügt die Zweckregel-Hierarchie darüber hinaus über eine Spezifizierungshierarchie: Durch Drill-down auf untergeordnete Elemente der Hierarchie Vertriebsort, welche hier vollständig dargestellt ist, kann das Entscheidungsproblem entsprechend spezifiziert werden.

623

Vgl. zur EPK Anhang B.

218

ModelIierungssprachen für das AvFe-Framework

Abbildung 56: ZWeck regel-Hierarchie mit dem erweiterten MER-Modell

00

8m m rn

o~ o o o0 ~

Auswahl und Konstruktion von Modellierungssprachen

219

Mit dem erweiterten MER-Modell steht nun eine Sprache zur konzeptionellen Entwicklung von Zweckregel-Hierarchien zur Verfügung. Bei der physischen Implementierung (siehe Kapitel 7) ist für jede einzelne Zweckregel der Prozess zu realisieren, welcher in Abschnitt 5.2.1.1 als EPK beschrieben wurde.

6.2.4

Der regelbasierte Modellierungsansatz zur Modellierung von ECA-Regeln

Im Folgenden wird mit dem regelbasierten Modellierungsansatz von HERBST eine Modellierungssprache für ECA-Regeln vorgeschlagen und analysiert. Zunächst wird in den Abschnitten 6.2.4.1 und 6.2.4.2 die abstrakte bzw. konkrete Syntax der Modellierungssprache präsentiert. Anschließend wird die Modellierungssprache in Abschnitt 6.2.4.3 einer Repräsentationsanalyse unterzogen. 6.2.4.1

Die abstrakte Syntax des regel basierten Modellierungsansatzes

Der regelbasierte Modellierungsansatz ist eine semi-formale Modellierungssprache zur Modellierung von Geschäftsprozessen.

624

Die Modellierungsspra-

ehe wurde im Rahmen des Forschungsprojektes SWORDIES entwickelt und verwendet Geschäftsregeln zur Modellierung von Geschäftsprozessen und deren Transformation in Workflows.'25 Im Folgenden werden die von HERBST vorgeschlagenen Geschäftsregeln zur Modellierung von ECA-Regeln verwendet.

Geschäftsregeln bestehen im regelbasierten Modellierungsansatz - in Anlehnung an ECA-Regeln - aus den drei Konstrukten auslösendes Ereignis, zu prüfende Bedingung und auslösende Aktion. Darüber hinaus werden Geschäftsregeln um eine zweite Aktion ergänzt, welche bei Nicht-Erfüllung der Bedingung ausgeführt wird.'26 Es können sowohl komplexe Ereignisse als auch komplexe Bedingungen definiert und als Bestandteil von Geschäftsregeln verwendet 627 Die durch Aggregation der Bestandteile resultierenden Regeln werwerden.

'" Vgl. Herbst 11995), 5. 18611.; Herbst, Myrach 11996), 120 11.; Herbst 11997), 5. 89 11. '" Vgl. Endl et al. 11998); Hohei.el 11999); Hohei.el 12000); Endl 12004). Im Rahmen des

626 627

regelbasierten Modellierungsansatzes werden Geschäftsregeln zur Modellierung von Geschäftsprozessen verwendet, indem mit Geschäftsregeln Tellprozesse modelliert werden, die dann zu einem Gesamtprozess integriert werden. Vgl. Herbst, Myrach (1996), S. 121. Vgl. Endl et al. (1998), S. 5 f.

220

ModelIierungssprachen für das AvFe-Framework

den als ECAA-Regeln bezeichnet. ECA- und EA-Regeln, d. h. Regeln ohne zweite Aktionskomponente bzw. ohne Bedingung und zweite Aktionskomponente werden als Sonderfälle von ECAA-Regeln betrachtet. Die abstrakte Syntax von Geschäftsregeln ist in Form eines sprachbasierten Metamodells in Abbildung 57 dargestellt. Das Metamodell ist dabei lediglich ein kleiner Ausschnitt des von HERBST vorgeschlagenen Metamodells.

628

Das

vollständige Modell enthält darüber hinaus - ähnlich wie das ARIS-Framework - die Konstrukte weiterer zu modellierender Aspekte wie bspw. Datensicht, Organisationssicht und Informationssysteme.'" Abbildung 57: Submodel Business Rule speclallzed_by-----,

l""

1."

Business Rule

q r----"------~...J O.N

roT_of~ I ~N

Event


;'_''''''''''_01

-

1."---...,

I

01'

Condition

Action

---''1"

°j"L_ _ _ _ _ _ _ _ _ _ ls_raISl!d_b1Y-l_ _ _ _ _ _ _ _ _

Vgl. Herbst (1995), S. 191.

628 62g

Vgl. zum vollständigen Metamodell Herbst (1995), S. 193. Vgl. Herbst (1995), S. 191; Herbst, Myrach (1996), S. 126; Herbst (1997), S. 92.

221

Auswahl und Konstruktion von Modellierungssprachen

6.2.4.2

Die konkrete Syntax des regelbasierten Modellierungsansatzes

In Abbildung 58 ist die Notation des regelbasierten Modellierungsansatzes übersichtsartig dargestellt. Dabei fällt auf, dass die Modellierungssprache semiformal gehalten ist. Wie bereits erläutert, kommt dies der Kommunikation mit Führungskräften entgegen. Abbildung 58: Geschäftsregeln in ECM-, ECA- und EA-Notation

ON

Event

ON

Event

ON

Event

IF

Condition

IF

Condition

DO

Action

DO

Action

DO

Action

EISE

Alternative Action

EndI12004), S. 68.

6.2.4.3

Repräsentationsanalyse des regelbasierten Ansatzes

Im Folgenden wird eine Repräsentationsanalyse des regelbasierten Ansatzes durchgeführt. Als Referenz dient das Metamodell der ECA-Regel aus Abschnitt 6.1.2.3. In einem ersten Schritt werden die Konstrukte der zu analysierenden Modellierungssprache der Referenz gegenübergestellt. Wie den ersten beiden Spalten von Tabelle 17 entnommen werden kann, ist die Sprache vollständig, d. h. der regelbasierte Ansatz stellt für alle Konstrukte der Referenz ein korrespondierendes Konstrukt zur Verfügung.

ModelIierungssprachen für das AvFe-Framework

222

Tabelle 17: Repräsentationsanalyse des regelbasierten Ansatzes Konstrukt des ECA-

Konstrukt des regelbasierten

Ergebnis der Repräsentati-

Metamodells

Ansatzes

onsanalyse

ECA-Regel

Business Rule

Eindeutig

Ereignis

Event

Konstruktüberladung

Bedingung

Condition

Eindeutig

Aktion

Action

Eindeutig

komplexes Ereignis

Event

Konstruktüberladung

Die Referenzkonstrukte ECA-Regel, Bedingung und Aktion werden eindeutig repräsentiert, wobei darauf hinzuweisen ist, dass die zweite Aktion des regelbasierten Ansatzes im Metamodell des AvFe-Frameworks nicht vorgesehen ist. Dieser eigentliche Konstruktüberschuss kommt in der Repräsentationsanalyse nicht zum Tragen, da die zweite Aktion nicht als eigenes Konstrukt modelliert wurde, sondern in der (1,2) Kardinalität zwischen Business Rule und Action verborgen wird. Das Konstrukt Event repräsentiert dagegen sowohl das Referenzkonstrukt Ereignis als auch das komplexe Ereignis. Wie im sprach basierten Metamodell dargestellt, sind komplexe Ereignisse als eigenständiges Konstrukt anzusehen, das über eigene Merkmale verfügt."'· Aus diesem Grund ist hier eine Konstruktüberladung festzustellen. Trotz des erkannten Defizits ist der regelbasierten Modellierungsansatz für die konzeptionelle Modellierung von ECA-Regeln geeignet. Zum einen ist die Sprache leicht nachzuvollziehen, was ein Vorteil gegenüber formalen Modellierungssprachen (bspw. Petri-Netze) ist, welche ggf. ohne Konstruktüberladung auskommen. Zum anderen ist die Modellierungssprache eindeutiger zu verwenden als andere semi-formale Modellierungssprachen - wie bspw. die EPK.",l

630 631

Vgl. Abschnitt 6.1.2.3. Vgl. Hoheisel (1999), S. 13 f.

Zusammenfassung

6.3

223

Zusammenfassung

In Kapitel 6 wurden Modellierungssprachen bestimmt, die zur Modellierung des AvFe-Frameworks verwendet werden können. Nach Definition der abstrakten Syntax in Abschnitt 6.1 wurden in Abschnitt 6.2 folgende Sprachen zur Modellierung der konzeptionellen Teilmodelle ausgewählt: •

Multidimensionale Daten auf Typebene werden in dieser Arbeit durch das MfR-Modell beschrieben.

•

Zweckregel-Hierarchien sind ein neuartiges und innovatives Artefakt, für

das bisher keine ModelIierungssprache existiert. Da sich die meisten sprachlichen Konstrukte einer Zweckregel-Hierarchie jedoch auf Konstrukte der Ausprägungsebene multidimensionaler Daten beziehen, wurde ein erweitertes MfR-Madell zur Modellierung von Zweckregel-Hierarchien vorgeschlagen. •

Zur Modellierung von fCA-Regeln wird in dieser Arbeit der regelbasierte Ansatz von HERBST verwendet.

Teil IV: Begründung

Gegenstand von Teil IV ist die (wissenschaftliche) Begründung des AvFeFrameworks und der dargestellten Modellierungssprachen. Zu diesem Zweck wird in Kapitel 7 ein Prototyp gemäß dem AvFe-Framework entwickelt, mit dem beispielhaft zwei Führungsentscheidungen eines Kreditinstituts automatisiert werden. Beide Führungsentscheidungen werden zunächst mithilfe konzeptioneller Modelle beschrieben, ehe die physische Implementierung dargestellt wird. In Kapitel 8 wird die Angemessenheit der entwickelten Artefakte mithilfe eines Konformitätstests überprüft. Das AvFe-Framework wird zu diesem Zweck den in Kapitel 3 formulierten Anforderungen gegenübergestellt. Die entwickelten Modellierungssprachen werden mit den Grundsätzen ordnungsmäßiger ModelIierung (GoM) auf Konformität geprüft. Die Arbeit endet in Kapitel 9 mit einem Fazit.

7

Prototyp

Gegenstand des vorliegenden Kapitels ist die Entwicklung eines Prototyps mithilfe des AvFe-Frameworks. Der Prototyp automatisiert zwei ausgewählte Führungsentscheidungen eines fiktiven Kreditinstituts - der GoodBonk AG. Das Kapitel ist folgendermaßen aufgebaut: In Abschnitt 7.1 wird zunächst das Kreditinstitut knapp vorgestellt, in welchem Führungsentscheidungen automatisiert werden. Anschließend wird in Abschnitt 7.2 die Führungsentscheidung "räumlich differenzierte Preispolitik für Konsumentenkredite" beschrieben und automatisiert. Gegenstand von Abschnitt 7.3 ist die Beschreibung und Automatisierung der Führungsentscheidung "Prüfung der Kreditwürdigkeit".

7.1

GoodBankAG

Die GoodBank AG ist ein regional agierendes Kreditinstitut, das gleichermaßen im Privat- und Firmenkundengeschäft aktiv ist. Die wesentlichen Prozesse der GoodBank AG können durch eine Prozesslandkarte beschrieben werden.'" Diese liegt in Form eines Wertschöpfungskettendiagramms (WKD) vor, welches (auszugsweise) in Abbildung 59 dargestellt ist.

632 633

633

Vgl. zu Prozesslandkarten und deren Integration in das ARIS-Framework Stähler (2005), 5 230 f. Nicht dargestellt wurden die Unterstützungsprozesse sowie einige Leistungsprozesse im Firmenkundengeschäft. Vgl. zum WKD IDS Scheer AG (2006), S. 4-127 ff.

J. Rommelspacher, Automatisierung von Führungsentscheidungen, DOI 10.1007/978-3-8348-8251-6_7, © Vieweg + Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

228

Prototyp

Abbildung 59: Prozesslandkarte GoodBank AG Manapll'MlntfunktlDn.n

Unternehmensfiihrunl

B

)unternehmens-

~-

) r

....

LeistunpproZMSII

• rlvatllllndlin

.

)DI"~m,,. hh"~"'''»' ~ kreditll!

>-

krwdt.

/:~1~1 en P

iIi

) ",,"",. ~ W,",.,,," ) verkehr gesehnt

11

.-

Sch~ldver-

)

schreibungen

L

> 0> 0

Flrll'lllnkund..

KUrzfrlst~r~ KKreditjeschLangfrlst:r~

Kreditgesch··

finanzierung

J' ,ma,». ,,,k-

SIchteinlagen

...

B

Risiko-

management

1ft

),Sichteinlagen,~

I", v"mOgo".) ) verwaltung

1ft

T'~;"-

einlagen

~~::"') } EmIßIo". verker:gesdlllf't!J

~

In der Prozesslandkarte wird zwischen Managementfunktionen und Leistungsprozessen differenziert. Letztere werden - wie in Kreditinstituten und Bankbetriebsiehre üblich - zum einen in Privat- und Firmenkundengeschäft und zum anderen in Aktiv-, Passiv- und Indifferenzgeschäft unterschieden.'" Die einzelnen Leistungsprozesse orientieren sich an dem Leistungsprogramm der GoodBank AG in Form der angebotenen Finanzdienstleistungen.'" Die im Folgenden zu automatisierenden Führungsentscheidungen werden bisher im Rahmen der Managementfunktion Vertrieb getroffen, wobei sich die Entscheidungen auf den Leistungsprozess Konsumentenkredit beziehen. In der oben dargestellten Prozesslandkarte sind diese beiden WKD-Symbole daher dunkelgrau schattiert. Nach der Vorstellung der GoodBank AG werden im Folgenden zwei Führungsentscheidungen dargestellt und automatisiert.

7.2

Räumlich differenzierte Preispolitik für Konsumentenkredite

Die GoodBank AG betreibt für Konsumentenkredite eine räumlich differenzierte Preispolitik, indem das Management der Bank für jede Filiale unterschiedli-

634

Vgl. Priewasser (2001).

635

Vgl. Priewasser (2001), S. 401 ff.

Räumlich differenzierte Preispolitik für Konsumentenkredite

229

ehe Mindestzinsen für die Konsumentenkredite vorgibt.

53

•

Dabei bietet jede

Filiale die folgenden standardisierten Konsumentenkredite an: •

Ratenkredit, Laufzeit 12 Monate

•

Ratenkredit, Laufzeit 18 Monate

•

Ratenkredit, Laufzeit 24 Monate

•

Ratenkredit, Laufzeit 36 Monate

•

Annuitätenkredit, laufzeit 48 Monate

637

Die in Abbildung 60 dargestellte Vertriebsstruktur der GoodBank AG besteht aus neun Filialen, welche zu den drei Vertriebsregionen Nord, Mitte und Süd zusammengefasst werden. Abbildung 60: Vertriebsstruktur der GoodBank AG

SCd

Mitte

'ili.I-103

K""o f-Ji:
M.1r ur~ Hli,I-IDB"

,ili1Ol-IO 5

' ili.I-IO l

Zur Preissteuerung verfügen die Führungskräfte über monatliche Vertriebsziele für jede Filiale und prüfen die tatsächliche Nachfrage nach Konsumentenkrediten. Je nachdem wie sich die Nachfrage nach einem Konsumentenkredit in einer Filiale im Verhältnis zum angestrebten Ziel entwickelt, werden die Mindestzinsen entsprechend verändert. Wenn die angestrebte Nachfrage unterschritten wird, so wird der Mindestzins entsprechend abgesenkt et vice versa. Darüber hinaus müssen die Mindestzinsen der Konsumentenkredite immer den marktüblichen Zinsen angepasst werden.

636

637

Es wird im Folgenden von Mindestzinsen gesprochen, da die Filialen je nach Bonität und Besicherung weitere Zinsaufschläge oder Gebühren für Konsumentenkredite verlangen. Diese Entscheidung obliegt allerdings den Mitarbeitern in den Filialen der GoodBank AG und ist im Weiteren nicht Gegenstand der Betrachtung. Ratenkredite werden durch gleichbleibende Monatsraten und Annuitätenkredite durch gleichbleibende jährliche Raten (die sogenannte Annuität) getilgt und verzinst. Vgl. Bitz, Stark (2008). S. 102 f.

230

Prototyp

Die dargestellte Führungsentscheidung wird im Folgenden automatisiert. Zu diesem Zweck wird in Abschnitt 7.2.1 die zur Vergabe von Konsumentenkrediten verwendete Datenbank beschrieben. Diese dient als Datenquelle eines zu implementierenden analytischen Informationssystems. Anschließend werden in Abschnitt 7.2.2 die konzeptionellen Modelle zur Automatisierung von Führungsentscheidungen im Rahmen des AvFe-Frameworks dargestellt, ehe in Abschnitt 7.2.3 die prototypische Implementierung demonstriert wird.

7.2.1

Datenbank zur Vergabe der Konsumentenkredite

Zur Vergabe von Konsumentenkrediten setzen die Mitarbeiter der GoodBank AG unternehmensweit die relationale Datenbank GoodBonk_OLTP ein.

638

Die

Datenbank besteht aus fünf Tabellen, welche samt ihrer Beziehungen in Abbildung 61 dargestellt sind. Abbildung 61: Relationenschema der Datenbank GoodBank_OLTP

I

Knldlt-ID

I

,------,.--------, Flllal-ID

FlIIal Bez Adl1!55e Tabelle Filiale

ID

An

I Zins

Typ Laufzeit Tabelle Kredit

Markt I

,----'n:1-------'

n:1

Gebühr

bot-ID Kunden-ID Kredithohe

Datum

Mindemins Vertr Gebühr Vertr.

Tabelle Nadlfrage

, -_ _ _ _ _ _ _ ". _ _ _ _ _ _ _ _.J Kunden-rD

Nsme

Vorname

Fllial-ID

verfEInkommen M

Tabelle Kunde

Die Tabelle Filiale enthält für jede Filiale die eindeutige Filial-ID, die FilialBezeichnung sowie die Adresse. In der Tabelle Kredit werden für die oben genannten standardisierten Konsumentenkredite Kredit-ID, Typ, Laufzeit und Marktzins gespeichert. Die Tabelle Angebot enthält die nach Filiale differen631

Die Datenbank wird auf einem Microsoft SOl Server 200S betrieben.

Räumlich differenzierte Preispolitik für Konsumentenkredite

231

zierten angebotenen Konsumentenkredite mit den Attributen Angebot-ID, Filial-ID, Kredit-ID, Mindestzins und Gebühr. Wenn Kunden dieses Angebot nachfragen, so wird in der Tabelle Nachfrage ein entsprechender Datensatz mit Attributwerten zu Antrag-ID, Angebot-ID, Kunden-ID, Kredithöhe und Datum gespeichert. Darüber hinaus sind noch Informationen über vertraglichen Mindestzins und vertragliche Gebühr erforderlich. Diese beiden Informationen sind in der Tabelle Nachfrage vorzuhalten, da sich Mindestzins und Gebühr bei einmal vergebenen Konsumentenkrediten nicht mehr ändern, in der Tabelle Angebot diese Werte jedoch häufig geändert werden. In der Tabelle Kunde sind darüber hinaus weitere Kundeninformationen wie Kunden-ID, Name, Vorname, Filial-ID und das monatlich verfügbare Einkommen hinterlegt. 7.2.2

Konzeptionelle Modelle zur Automatisierung der Führungsentscheidung

Im Folgenden werden in Anlehnung an das AvFe-Framework die konzeptionellen Modelle zur Automatisierung der dargestellten Führungsentscheidung konstruiert. Zunächst wird in Abschnitt 7.2.2.1 das konzeptionelle Modell eines Hypercubes entwickelt, mit dessen Hilfe Zweckregeln die Zielerreichung prüfen können. Anschließend werden in Abschnitt 7.2.2.2 ECA-Regeln eingeführt, welche die Anpassung der Mindestzinsen an sich ändernde Marktpreise automatisieren. Auch die "multidimensionale" Organisation dieser Regeln wird dargelegt. Abschließend wird in Abschnitt 7.2.2.3 das konzeptionelle Modell der Zweckregel-Hierarchie Preispolitik erstellt, welche die oben dargestellte Führungsentscheidung automatisiert. 7.2.2.1

Multidimensionale Daten zur Überprüfung der Zielerreichung

Zweckregeln überprüfen im Rahmen des AvFe-Frameworks mithilfe multidimensionaler Daten die Zielerreichung. Zur Automatisierung der oben dargestellten Führungsentscheidungen ist deshalb ein Hypercube zu entwickeln, welcher multidimensionale Informationen zum Vertrieb der GoodBank AG bereitstellt. Die Anforderungsanalyse ergibt, dass die Kennzahlen Anzahl (IST) und Anzahl (SOLL) erforderlich sind, um die Ziel erreichung der vertriebenen Konsumentenkredite prüfen zu können. Darüber hinaus werden die Kennzahlen Mindestzins

232

Prototyp

und Gebühr als notwendig betrachtet. Die quantifizierenden Informationen können in die Dimensionen Kunde, Vertrieb, Zeit und Produkt eingeordnet werden. Die Verdichtungsbeziehungen in den Dimensionen werden durch Dimensionsebenen dargestellt. Das konzeptionelle MER-Modell des Hypercubes GoodBankl ist in Abbildung 62 dargestellt. Abbildung 62: Konzeptionelles Modell des Hvpercubes GoodBankl

Zur Reduzierung der Komplexität wird im Folgenden angenommen, dass in dem dargestellten Hypercube nicht die Vertriebsinformationen aller Produkte, sondern lediglich Informationen zu vertriebenen Konsumentenkrediten gespeichert werden. Die Ist-Daten entstammen somit alle der oben dargestellten Datenbank GoodBank_OLTP. Für die Soll-Daten existiert dagegen bisher keine Datenquelle und diese sind manuell einzugeben. 7.2.2.2

ECA-Regeln und Aktivierungsmatrix

Die Mindestzinsen der angebotenen Konsumentenkredite werden zum einen räumlich nach Filialen differenziert und orientieren sich zum anderen an den marktüblichen Zinsen. Die räumliche Differenzierung stellt dabei ein Auf- oder

Räumlich differenzierte Preispolitik für Konsumentenkredite

233

Abschlag auf die marktüblichen Zinsen dar. Die räumlich differenzierten Mindestzinsen werden in der Tabelle Angebot der oben dargestellten Datenbank gespeichert. Die marktüblichen Zinsen werden dagegen in der Tabelle Kredit vorgehalten, welche in Tabelle 18 dargestellt ist. Tabelle 18: Tabelle Kredit der Datenbank GoodBank_OLTP Kredit-ID

Typ

laufzeit

1

Ratenkredit

12

5,00

2

Ratenkredit

18

5,10

3

Ratenkredit

24

5,20

4

Ratenkredit

36

5,30

S

Annuitätenkredit

48

5,40

Im Folgenden werden ECA-Regeln definiert, die für jede Filiale oder für die einzelnen Vertriebsregionen die Änderung des Marktpreises mit einem entsprechendem Auf- oder Abschlag weitergeben. Zur Veränderung des Auf- oder Abschlags wird die gewünschte ECA-Regel aktiviert und alle anderen ECARegeln dieser Filiale oder Vertriebsregion deaktiviert. In Abbildung 63 ist bspw. die ECA-Regel "Filiale9 -1" dargestellt. Abbildung 63: ECA Regel "Filiaie9-1"

ON

UPDATE Kredit

IF

Angebot.Kredit-ID =Kredit.Kredit-ID and Angebot.Filial-ID =9

00

UPDATE Angebot Angebot.Mindestzins =Kredit.Zins Markt - 0.1

Ist die Regel aktiviert, so wird sie nach einer UPDATE-Operation in der Tabelle Kredit ausgelöst und passt die Mindestzinsen in der Filiale Gießen (Filial-ID 9) den marktüblichen Zinsen an, wobei die marktüblichen Zinsen durch die oben

Prototyp

234

dargestellte Regel um 0,1 Prozentpunkte verringert werden.

53

'

Unter Annahme

der Daten aus Tabelle 18 wird in der Filiale Gießen bspw. der Ratenkredit über 12 Monate für 4,9 % monatlicher Mindestzins angeboten. Auch die anderen Konsumentenkredite werden für die Filiale Gießen entsprechend angepasst. Anhand der multidimensionalen Daten des oben dargestellten Hypercubes kann überprüft werden, ob die Vertriebsziele für Konsumentenkredite in der Filiale Gießen in einer bestimmten Zeit erreicht werden. Wenn der gewünschte Absatz an Konsumentenkrediten in der Filiale Gießen zu niedrig oder zu hoch ist, so senkt bzw. steigert die Zweckregel das Zinsniveau entsprechend.

640

Dies

erfolgt im Rahmen des AvFe-Frameworks durch Aktivieren und Deaktivieren von ECA-Regeln. Für jede Hypercube-Zelle, die von einer Zweckregel geprüft wird, ist deshalb eine entsprechende Aktivierungsmatrix zu erstellen. Die Aktivierungsmatrix für Konsumentenkredite in der Filiale Gießen ist in Tabelle 19 dargestellt. Tabelle 19: Aktlvlerungsmatrlx Konsumentenkredit_Flllale9

ZE < 0,9

0.9 s ZE s 0.95

1.OS :s ZE :s 1,1

l,l
Filiale9 + 2

0

0

0

1

Filiale9 + 1

0

0

1

0

Rliale9 + 0

0

1

0

0

Flllale9 - 1

1

0

0

0

In der Aktivierungsmatrix sind vier verschiedene Bereiche für die Kennzahl Zielerreichungsgrad (ZE) angegeben. Je nach Ausprägung der Kennzahl Zielerreichungsgrad kann in der Aktivierungsmatrix abgelesen werden, welche ECA-

&39

640

Mit der UPDATE-Operation wird u.a. der marktObliche Zins aktualisiert. Sowohl das Unter- als auch das Überschreiten des Zielwertes stellt hier ein Problem dar. Für Kreditinstitute kann das Überschreiten des Zielwertes bei Konsumentenkrediten problematisch sein, da die Kredite entsprechend zu refinanzieren sind.

Räumlich differenzierte Preispolitik für Konsumentenkredite

235

Regel zu aktivieren ist und wie hoch der Auf- oder Abschlag auf den Marktpreis tatsächlich ausfällt.'41

7.2.2.3

Zweckregel-Hierarchie Preispolitik

Bei der Automatisierung der Führungsentscheidung "räumlich differenzierte Preispolitik" wird eine Zweckregel-Hierarchie eingesetzt, um die vorgegebenen Absatzziele zu einem bestimmten Zeitpunkt zu erreichen. Als Kennzahlen zur Überprüfung der Zielerreichung werden die Kennzahlen Anzahl (IST) und Anzahl (SOLL) eingesetzt. Die beiden Kennzahlen werden beschrieben durch die

Hierarchieelemente Kunden, Konsumentenkredite und Gesamtvertrieb. Des Weiteren wird die Zweckregel-Hierarchie Ereignis jeweils am 1. eines Monats durch ein temporales Ereignis ausgelöst und betrachtet immer den vergangenen Monat. Wenn das vorgegebene Ziel einer Zweckregel nicht erreicht wird,

so versucht die Zweckregel, die Mindestzinsen anzuheben oder abzusenken durch Aktivieren und Deaktivieren von ECA-Regeln. Liegt für ein Entscheidungsproblem jedoch keine geeignete ECA-Regel vor, so ist das Problem zu allgemein und zu spezifizieren. Als Spezifizierungshierarchie wird im Folgenden die bereits oben dargestellte Hierarchie Vertriebsort verwendet. Wenn der Absatz des Gesamtvertriebs zu gering oder zu hoch ist, so erfolgt ein Drill-down auf die Dimensionsebene Region und es wird die Zielerreichung in allen Regionen entsprechend geprüft. Wenn auch auf dieser Ebene das Problem nicht gelöst werden kann, so erfolgt ein weiterer Drill-down auf die Dimensionsebene Filiale. Die beschriebene Zweckregel-Hierarchie Preispolitik ist übersichtsartig mithilfe des erweiterten MER-Modells in Abbildung 64 dargestellt.

641

Bei ZE< 0,9 wäre bspw. die ECA-Regel "Filiale9 - 1 u zu aktivieren und alle anderen Regeln zu deaktivieren. Die Regel legt einen Mindestzins fest, welcher den marktüblichen Zins um 0,1 Prozentpunkte unterschreitet.

236

Abbildung 64: ZWeckregel-Hierarchie Preispolitik

Prototyp

237

Räumlich differenzierte Preispolitik für Konsumentenkredite

7.2.3

Prototypische Implementierung mit Microsoft SQL Server 2008

Gegenstand des vorliegenden Abschnitts ist die Beschreibung der prototypischen Implementierung der oben anhand konzeptioneller Modelle dargestellten Führungsentscheidung. Zur Implementierung wird der Microsoft SQL Server 2008 verwendet.'" Die Gliederung des Abschnitts ist gleichartig wie der Aufbau des vorigen Abschnitts. Zunächst wird in Abschnitt 7.2.3.1 die Implementierung des Hypercubes GoodBank1 skizziert. Anschließend wird in Abschnitt 7.2.3.2 die Implementierung von ECA-Regeln sowie die Speicherung von Aktivierungsmatrizen in Konnektortabellen dargestellt, ehe in Abschnitt 7.2.3.3 die prototypische Implementierung einer Zweckregel-Hierarchie gezeigt wird. 7.2.3.1

Implementierung des Hypercubes GoodBank1

Der vorliegende Abschnitt beschreibt die physische Implementierung des Hypercubes GoodBank1, dessen konzeptionelles Modell in Abschnitt 7.2.2.1 konstruiert wurde. Die Datenhaltung erfolgt in der relationalen Data-Warehouse-Datenbank GoodBank_DW. Diese wird auf einem Microsoft SQL Server 2008 vorgehalten. Zur physischen Implementierung des ETL-Prozesses können die SQL Server Integration Services (5515) eingesetzt werden.'"

Die Data-Warehouse-

Datenbank fungiert in den zur Datenbereitstellung eingesetzten SQL Server Analysis Services (SSAS) als Datenquelle. Mithilfe der sogenannten Datenquellensicht wird die Struktur des Hypercubes dargestellt. Wie in Abbildung 65 ersichtlich, wird im vorliegenden Fall ein einfaches Star-Schema zur technischen Realisierung des Hypercubes verwendet.

642

643

Die Implementierung ist auch mit anderer Software möglich. Der Microsoft SQL Server 2008 wurde ausgewählt, weil der Verfasser die Software im Rahmen der Microsoft Developer Network Academlc Alliance (MSDNAA) kostenlos nutzen kann. Ausführliche Informationen zum Microsoft SQL Server finden sich bspw. unter http://www.microsoft.com/germany/sqIj200B/default.mspx. Vgl. Azevedo et al. (2009), S. 361 ff.

'38

Prototyp

__ -_ -_ __ ".. III_._fIo __ ____

Abbildung 65: Datenquellenslcht GoodBankl

----- -- ..... J1 '''~

• ___

~.-,., .... --- .•~ ""_ "
-

---

.,,--

........,,, "&

', '1',

...........'""::'1;:.

...

...

--;-.

-_.- :I .._.

-~

j'.-;::... ..-

-

Il,_

.

_. • ,-

-' --

--_. --I --_. .---

- ------,tI

-----.-._-.._._'---.------,----"~

.~

,

---

....... """""..........-~

~

~-

In Abbildung 65 ist auf der linken Seite zudem die Definition von quantifizierenden Kennzahlen (Measures) und qualifizierenden Dimensionen und Hierarchien erkennbar. Details zum Erstellen dieser Elemente sind der einschlägigen

literatur zu entnehmen.644 Nach der Erstellung des Hypercubes GoodBankl stellt dieser multidimensiona-

le Daten bereit, mit denen der Zustand eines Realitätsausschnitts beurteilt werden kann. Zu ergänzen Ist der Hypercube darOber hinaus noch um SollDaten. Dafür wird im vorliegenden Fall die SSAS-Funktion Berechnungen verwendet. Diese Funktion ermöglicht mithilfe der Sprache Multidimensional Expressions (MDX) die Definition von Kennzahlenwerten in Hypercube-Zellen, welche nicht unmittelbar durch die Quelldaten des Hypercubes definiert

li44

Vgl. bspw. Azevedo et al. (2009), S. 61 W.; Hartnath et al. (2009), S. 35 ff.

239

Räumlich differenzierte Preispolitik für Konsumentenkredite

sind.

64S

Die Werte können frei definiert werden, sie können aber auch von

Daten abgeleitet werden, die bereits im Hypercube enthalten sind. Das MDXSkript in Tabelle 20 überträgt bspw. Kennzahlenwerte aus dem Jahr 2007 in die korrespondierenden Zellen des Jahres 2008. Tabelle 20: MDX-Skript zur Berechnung von Kennzahlenwerten

Scope (Root (»; /*Definiert den Bereich, für den Soll-Daten zu vergeben sind*/ //Angabe der Dimensionen und Slice auf das Jahr 2008 Scope ([Dirn_Produkt]. [Kategorie] .&[Konsumentenkredit], [Dirn Vertrieb]. [Gesamtvertrieb] . [Gesamtvertrieb], [Dirn_Zeit] . [Jahr] .& [2008-01-01TOO: 00: 00], [Measures] • [Anzahl Soll]) ;

//Drill-Down zur Dimensionsebene Monat Scope [Dirn Zeit]. [Monat]. [Monat]; //Drill-Down zur Dimensionsebene Vertriebsregion Scope ([Dirn Vertrieb]. [Vertriebsregion] • [Vertriebsregion]): //Drill-Down zur Dimensionsebene Filiale Scope ([Dirn Vertrieb]. [Filiale-ID]. [FilialeID]) ;

I/Wendet eine Kalkulation auf den definierten Subcube an

This - ParallelPeriod ( [Dirn_Zeit]. [Jahr - Quartal -

Monat -

Da-

turn] • [Jahr] 1

*

1 :

End Scope: End Scope: End Scope; End Scope;

Im Rahmen des AvFe-Frameworks prüfen Zweckregeln die Zielerreichung durch einen Abgleich von Zustand und Ziel. SSAS stellt mit den Key Performance Indieators (KPls) eine Technologie zur Verfügung, die diesen Abgleich automatisch durchführt und den Status von Hypercube-Zellen speichert, welcher von der Zweckregel direkt abgefragt werden kann. KPls bestehen in der AnalysisServices-Terminologie aus Wertausdruck (realer Wert der KPI), Zielausdruck (Ziel der KPI), Status (Bewertung eines KPI, normiert von -1 bis + 1) und einem Trend (Auswertung im Zeitablauf).'"

645 646

Vgl. Azevedo et al. (2009), S. 211 ff. Vgl. Azevedo et al. (2009), S. 220 ff.

Prototyp

240

Das MDX-Skript in Tabelle 21 berechnet den Status durch Abgleich von Wertausdruck (KpiValue) und Zielausdruck (KpiGoal). Als Wertausdruck und Zielausdruck werden die Kennzahlen Anzahl (SOLL) bzw. Anzahl (IST) verwendet. Die oben dargestellten Klassen von Zielerreichungsgrade werden dabei durch ein numerisches Ranking von -1 bis + 1 repräsentiert. Tabelle 21: MDX-Skript zur Berechnung des KPI-Status

Case

liben KpiValue("Soll-Ist-Abgleich")/KpiGoal("Soll-Ist-Abgleich"»1.1 Then 1

liben KpiValue("Soll-Ist-Abgleich")/KpiGoal("Soll-Ist-Abgleich"»=-1.06 Then .5

liben

KpiValue("Soll-Ist-Abgleich"l/KpiGoal("Soll-Ist-Abgleich")<.96 Then -.5

liben KpiValue("Soll-Ist-Abgleich")/KpiGoal("Soll-Ist-Abgleich")<.9 Then -1 Else 0

End

7.2.3.2

Implementierung von ECA-Regeln und Speicherung der Aktivierungsmatrizen

ECA-Regeln werden im Rahmen des AvFe-Frameworks in den Datenquellen des Data-Warehouse-Systems gespeichert.'47 Im vorliegenden Fall ist dies die in Abschnitt 7.2.1 dargestellte relationale Datenbank GoodBank_OLTP, welche ebenfalls auf einem SQL Server 2008 betrieben wird. ECA-Regeln werden im Microsoft SQL Server 2008 als Trigger bezeichnet und können mithilfe der SQL-Variante T-SQL erstellt werden.'" Gegenüber konkurrierenden relationalen Datenbanksystemen sind die Trigger-Funktionalitäten des Datenbanksystems relativ stark beschränkt.

64 '

So können bspw. keine

komplexen Ereignisse und keine temporalen oder abstrakten Ereignisse als

648

Vgl. Abschnitt 5.2.1.4. Vgl. http://www.tsql.de/transact-sql/trigger/trigger

64!1

Ein Vergleich von Trigger-Mechanismen findet sich in Schlesinger, Achermann (1995).

647

Räumlich differenzierte Preispolitik für Konsumentenkredite

Auslöser verwendet werden.

6S

•

241

Da diese Funktionalitäten jedoch zur Realisie-

rung der beschriebenen ECA-Regeln nicht erforderlich sind, kann die Realisierung der ECA-Regel mit dem Microsoft SQL Server erfolgen. Zur Definition der oben dargestellten ECA-Regel "Filiale9-1" wird das T-SQLSkript in Tabelle 22 verwendet: Tabelle 22: T-SQL-Skript zur Definition einer ECA-Regel

CREATE TRIGGER [dbo]. [Filiale9 IJ ON [dbo]. [Kredit] After UPDATE AS UPDATE [GoodBank_OLTP]. [dbo] . [Angebot] SET [Mindestzins] - a. [Zins_Markt]- 0.1 from [GoodBank_OLTPJ. [dbo] • [Kredit] a, [GoodBank_OLTP] . [dbo] . [Angebot] b WHERE a. [Kredit-ID] = b. [Kredit-ID] and b. [Filial-ID] GO

5

Wenn die oben dargestellte ECA-Regel aktiviert ist, so wird diese bei einer Update-Operation in der Tabelle Angebot ausgelöst und aktualisiert entsprechend der Vorgaben die Mindestzinsen der Filiale Gießen. Die in Abschnitt 7.2.2.2 dargestellte Aktivierungsmatrix ist im Folgenden in einer Konnektortabelle zu speichern.'51 Die Konnektortabelle wird in der DataWarehouse-Datenbank angelegt und wird benannt nach den Hierarchieelementen der betroffenen Hypercube-Zelle.'52 Die oben dargestellte Aktivierungsmatrix wird etwa in der Tabelle KonsumentenkreditJiliale9 gespeichert. Damit die Tabelle von Zweckregeln leicht zu durchsuchen ist, werden die Informationen der Aktivierungsmatrix in der Konnektortabelle anders angeordnet. In der Spalte ZE werden die Werte des KPI-Status (-1; -0.5; 0.5; 1) gespeichert, für die ECA-Regeln existieren. Diese Werte repräsentieren Kennzahlenbereiche der Kennzahl Zielerreichungsgrad. In den Spalten trigAkt und trigDeakt werden die jeweils zu aktivierenden bzw. zu deaktivierenden ECA-Regeln gespeichert. Die Konnektortabelle Konsumen-

6SO

651 652

Vgl. Abschnitt 4.2.1. Vgl. Abschnitt 5.2.1.4. Vgl. Abschnitt 5.2.1.4.

242

Prototyp

tenkredit]iliale9, welche die Informationen der in Abschnitt 7.2.2.2 entwickelten Aktivierungsmatrix enthält, ist in Tabelle 23 dargestellt. Tabelle 23: Konnektortabelle KonsumentenkreditJiliale9

ZE

"IgAkt

trlgDea'"

1

IFiliale9 + 2]

IFiIi.le9 + 1], IFiIi.le9 + 0], IFiIi.le9 -1]

0.5

[Filiale9 + 1]

[Filiale9 + 0], [Filiale9 + 2], [Filiale9 -1]

-0.5

[Filiale9 + 0]

[Filiale9 + 1], [Filiale9 + 2], [Filiale9 -1]

-1

IFm.le9 - 1]

IFm.le9 + 0], IFm.le9 + 1], IFm.le9 + 2]

7.2.3.3

Implementierung der Zweckregel-Hierarchie Preispolitik

Die Grundidee bei der technischen Implementierung von ZweckregelHierarchien besteht darin, dass (mithilfe der Entwicklungsumgebung Visual Studio 2008) ein SSIS-Paket erstellt wird, welches vom SQL-Server-Agenten 653

jeweils am ersten Tag eines Monats ausgeführt wird. Im Folgenden wird das SSIS-Paket knapp beschrieben. Dabei wird zunächst der Datenfluss einer Zweckregel beispielhaft erläutert, ehe auf die Ablaufsteuerung einer Zweckregel-Hierarchie eingegangen wird. Der Datenfluss der Zweckregel Gesamtvertrieb ist in Abbildung 66 dargestellt. Die Zweckregel Gesamtvertrieb stellt den Ausgangspunkt der Zweckregel-Hierarchie dar, d. h. bei einem Entscheidungsproblem wird zuerst diese Zweckregel ausgeführt, ehe ggf. untergeordnete Zweckregeln ausgeführt werden.

653

Der SQL-Server-Agent ist ein Microsoft-Windows-Dienst des Microsoft SOl Servers, der geplante administrative Aufträge ausführt. Der Dienst kann einen Auftrag anhand eines Zeitplans, als Reaktion auf ein bestimmtes Ereignis oder bei Bedarf ausführen.

Mumllch differenzierte PreispolItIk fOr Konsumentenkredite

Abbildulll66: Datenflu$$ der Zweckrqel Gesamtvertrieb

Ausgangspunkt des Datenflusses Ist die Datenflussquelle Gesamtvertrfeb. Diese fragt mithilfe von MDX-Skripten Daten aus dem Hypercube GoodBankl ab. Das MDX-Skript in Tabelle 24 fragt den KPI-Status ab, der durch die Hierarchieelemente Konsumentenkredit, Gesamtvertrieb und den Monat Oktober 200S beschrieben wlrd.

654

Tabelle 24: MultidimensIonale MDX-Anfrage

Select

KPIStatus(~Soll-Ist-Abqleich")

on 0,

([Dirn_Produkt] _ [Kateqorie] .'[Konsumentenkredit], [Dirn Vertrieb] . [Gesamtvertrieb - Vertriebsreqion Filiale] _ [Gesamtvertrieb] ) on 1 froM [Good Bank DW] where [Dirn Zeit] _ [Monat] .'[2008-10-01TOO:OO:OO]

... Vgl. zur Abfrase von Hypercubes mit MDX: Azevedo et al. (2009), s. 735 ff.; Harlnath et al. 120(9), S. 67 ff. Da die Zeltdlmenslon entsprechend zu verändern Ist, muss dIs oben darse!rtellte MOX-Skript vor jeder AusfOhrung der 2weckregel neu berechnet werden.

-

Da. Erpbnil d_. AbfrIp IltAbbllduII&67 zu Imnlhmtn.

KC<1SL.
I Gesomtvorlrie!J

Um die Erpbn" .u......nan!U kOn"on ten

~

SoI-lsl-Atge
_rd.., dl_ mHhlH\t der

I

~n ..-

In entsprechende DotentypI!n konvertiert. Anschlle-

8end erfulst dlo OborprQful1ll der zr.lenk""' ....... rth dl& Kampononle ZlrlD'_"".

~.

urcl!lch 0 1111:.

Diese kDlIInlIliert, Db fQr die o..,.ewlhlten Ooten der Stotus

PI~

DIIta1

_rd.., van d... Kumpane"te nur _!plottet.

wenn .'" Ents
mit d... Zellen der Konlll!ktort.Ibele Ka .... mentenkn!dtt..GI!H_~ob wr"lohen und bei Oberelno1lrnrNJlII die entspredlencl ... Werte der Spolten ~

und ~DaId: der Konnoktorblbollo zurQck&eieben,

LI!II !IM Oberelnstlmm........., 50 ben!d'llE d. Sla1ptkompa ... nle SOL~ 1 ..... n T~I zum AtIII/I""'" und DllkIIIII..... dir tntIFAehernlen ECA-.....,n und speichert ...... n " einer VlI~lb"'n \hl ..: SQl.TfIaI.11. Eldlllort fIr
ta"......1Ota EC,f,.Raeo~ ... _

"tI

d'" Skr-.,mpo""nte 0rIIID0wtJJ. don Wert ."er ondere" VlIrllblen \hier: DrillDc>wnl) W" 0 .'" L Domlt wird

durd! MI-down 1'9115"'n.

"1'11- d•• SpllzIIIdo.....

_10 ....

N.chdom nun d... Datenfluss ."er zweda..,1 erI:olltl!rt wurde, wird d'" Abl'uflt
245

Rllumllch differenzierte PreIspolItIk fOr Konsumentenkredite

Abbildung 68: Ablaufsteuerung der ZWeckregel-Hlerarchle PreIspolitik

-==-;:...:.::-~

;;:;:..

J=-,

.,-I

'lJ=-- _

~';f

n-

Ef=3 ~ .rl--

• •

• •

~ Q -_. . . ,. -r'l -t.l _ _ rI~ t.l= ~ &;;.2::!l . • •

A

rp:::-~

-.-

"=-.-.

•

•

'lJ=... ..

I[,l;=-.-..· 1

A ., __

~~

I

.rJ_...

t.l- _

~:::....-,

....

I

•

~=--•

•

I.. =-.-. 1 1.. ==-.1

'(

~--

i

n---

~ -_

.

•

Jede Zweckregel ist eine Gruppierung und besteht aus einem Datenflusstask (z.B. Zweckregel Gesamtvertrieb) und einem Task SOl ausführen (trigger aktiveren_deaktivieren 1). Dabei enthält der Datenflusstask den oben dargestellten Datenfluss und der Task SQL ausführen aktiviert und deaktlvlert Trigger (ECARegeln). Dazu wird das oben berechnete und In einer Variablen gespeicherte TSQL-Skript verwendet. Untergeordnete ZWeckregeln werden In dem SSI5-Paket lediglich ausgeftlhrt, wenn für die übergeordnete Zweckregel keine geeignete ECA-Regel vorliegt. Um dies zu realisieren. werden Variablen eingesetzt. deren Werte auf 1 gesetzt werden, wenn ein Drill-down erforderlich ist. Ein Drill-down auf die Vertriebsregionen wird bspw. nur durchgeführt, wenn die Variable DriliDownl ungleich o ist.

246

Prototyp

Jede Zweckregel verwendet einen spezifischen MDX-Ausdruck zur Datenabfrage. Diese MDX-Ausdrücke sind wegen den Änderungen in der Zeitdimension für jedes Ausführungsdatum neu zu berechnen. Die Berechnung übernimmt im obigen SSIS-Paket der Task Skripttask_ MDX-Abfragen berechnen. Die Zweckregel-Hierarchie ist nun vollständig beschrieben. Im Folgenden werden zwei Probleme skizziert, die von der dargestellten Zweckregel-Hierarchie automatisch gelöst wurden: Im Juli 2008 ist in der Filiale Gießen ein deutlicher Absatzrückgang zu beobachten, der auf das Gesamtergebnis der GoodBank AG durchschlägt. •

Die Zweckregel-Hierarchie Preispolitik wird am 2008-08-01 ausgeführt und identifiziert das Problem.

•

Da sowohl für die Zweckregel Gesamtvertrieb als auch für die Zweckregel Vertriebsregion Mitte keine geeigneten ECA-Regeln vorliegen, werden die Zweckregeln Gießen, Marburg und Stadtallendorf ausgeführt.

•

In der Filiale Gießen werden die Mindestzinsen gesenkt.

•

Der Absatz stabilisiert sich, die Mindestzinsen verbleiben auf dem niedrigen Niveau. In der Vertriebsregion Süd sind im Oktober 2008 drastische Absatzrückgänge zu beobachten.

•

Die Zweckregel-Hierarchie Preispolitik wird am 2008-11-01 ausgeführt und identifiziert das Problem.

•

Da für den Gesamtvertrieb keine geeigneten ECA-Regeln vorliegen, findet ein Drill-down auf die Vertriebs regionen statt und die Zweckregel Vertriebsregion Süd stellt fest, dass der Absatz in der Vertriebsregion Süd deutlich zurückgegangen ist.

•

Die Zweckregel senkt die Mindestzinsen in der Vertriebsregion ab. Dies führt im November 2008 zu einem stark steigenden Absatz.

•

Daraufhin hebt die Zweckregel am 2008-12-01 die Mindestzinsen wieder an.

Prüfung der Kreditwürdigkeit

7.3

247

Prüfung der Kreditwürdigkeit

Bei der in Abschnitt 7.2 dargestellten und automatisierten Führungsentschei· dung wurde durch die Veränderung der Mindestzinsen die Nachfrage nach Konsumentenkrediten beeinflusst. Ausgeblendet wurde dabei die Fragestel· lung, ob die Kredite anschließend auch an die Kunden vergeben werden. Die Kreditvergabe hängt von deren Kreditfähigkeit (Geschäftsfähigkeit des Antrags· stellers) und der Kreditwürdigkeit ab. Letztere kann weiter differenziert wer· den in persönliche und wirtschaftliche Kreditwürdigkeit.

65S

Die persönliche

Kreditwürdigkeit bezieht sich auf subjektiv·persönliche Eigenschaften wie bspw. berufliche Qualifikation, Familienstand und Zuverlässigkeit bei bisheri· gen Kreditabwicklungen (sogenannte Schufa·Auskunft) und wird im Privatkun· dengeschäft oftmals mithilfe eines Punktbewertungssystems (Scoring·Modell) durchgeführt.

656

Die wirtschaftliche Kreditwürdigkeit orientiert sich an der

ökonomischen Leistungsfähigkeit des potenziellen Kreditnehmers. Im Rahmen der wirtschaftlichen Kreditwürdigkeit ist zu prüfen, ob der Kreditnehmer von dem frei disponiblen Einkommen und dem möglicherweise vorhandenen Vermögen den Kredit voraussichtlich zurückzahlen kann. Bisher wird die Kredit· würdigkeit von den Mitarbeitern der GoodBank AG manuell geprüft. Für jeden Typ von Konsumentenkredit der GoodBank AG werden jeweils Kre· ditsummen als Ziele vorgegeben, die zu erreichen sind. Diese sind für die GoodBank AG von großer Bedeutung, um die liquiden Mittel optimal zu nutzen. Zum Erreichen der vorgegeben Kreditsummen verändern Führungskräfte bisher manuell - den für die Prüfung der persönlichen Kreditwürdigkeit rele· vanten Score_Wert.

655 656

657

657

Vgl. Priewasser (2001), S. 408. Vgl. zu Scoring-Modellen Füser (2001); Priewasser (2001), S. 276 ff.; Schierenbeck (2003), S.3381. Wenn die Kreditsumme zu gering ist, wird der Score-Wert abgesenkt et vice versa. Zusätzlich sind die steigenden oder sinkenden Kreditausfallrisiken entsprechend zu steuern und der Score-Wert darf nur so weit abgesenkt werden, dass aus den zusätzlich vergebenen Kredite noch eine Nettoertragssteigerung resultiert, d.h. der zusätzliche Ertrag muss höher sein als die erwarteten Ausfälle. Eine alternative Vorgehenswelse zur Ermittlung des optimalen ScoreWerts besteht darin, basierend auf empirischen Daten den Gesamtgewinn aus dem Komsumentenkreditgeschäft zu optimieren. Vgl. für einen derartigen Ansatz Priewasser (2001), S. 276 I.

248

Prototyp

Die Führungsentscheidung wird im Folgenden konzeptionell beschrieben und automatisiert. Zu diesem Zweck werden zunächst in Abschnitt 7.3.1 die zur Prüfung der Kreditwürdigkeit verwendeten Daten dargestellt. Diese dienen als Datenquelle eines zu implementierenden analytischen Informationssystems. Anschließend werden in Abschnitt 7.3.2 die konzeptionellen Modelle zur Automatisierung von Führungsentscheidungen dargestellt, ehe in Abschnitt 7.3.3 die prototypische Implementierung demonstriert wird.

7.3.1

Daten zur Prüfung der Kreditwürdigkeit

Die Daten zur Prüfung der wirtschaftlichen Kreditwürdigkeit entstammen der 658 oben dargestellten Datenbank GoodBank_OLTp. Neben dem Zeitstempel sind Informationen zu Kunden-ID, Kredithöhe, Kredit-ID, Laufzeit und verfügbares Einkommen abzufragen. Die Daten zur Prüfung der persönlichen Kreditwürdigkeit werden von einem externen Dienstleister in Form eines Datenstrams geliefert. Der Datenstrom verfügt über Zeitstempel, Kunden-ID und einen Score-Wert von 0 bis 100, welcher die persönliche Kreditwürdigkeit abbilden soll. Ein kleiner Ausschnitt des Datenstroms des externen Dienstleisters ist in Tabelle 25 dargestellt.

651

Vgl. Abschnitt 7.2.1.

Prüfung der Kreditwürdigkeit

249

Tabelle 25: Daten zur Prüfung der persönlichen Kreditwürdigkeit

Timestamp

KundenlD

Score

2008-09-01 09:34

35

91

2008-09-01 09:45

227

86

2008-09-0110:28

274

62

2008-09-0110:38

495

67

2008-09-0112:26

530

89

2008-09-0114:02

121

68

2008-09-0114:16

493

95

2008-09-0114:26

267

65

2008-09-0114:28

714

84

7.3.2

Konzeptionelle Modelle zur Automatisierung der Führungsentscheidung

Im folgenden Abschnitt werden die konzeptionellen Modelle zur Automatisierung der Führungsentscheidung konstruiert. Zunächst wird in Abschnitt 7.3.2.1 das konzeptionelle Modell eines Hypercubes skizziert, der von Zweckregeln zur Prüfung der Zielerreichung verwendet werden kann. Anschließend werden in Abschnitt 7.3.2.2 ECA-Regeln eingeführt, welche die Prüfung der Kreditwürdigkeit automatisieren. Abschließend wird in Abschnitt 7.3.2.3 das konzeptionelle Modell einer Zweckregel-Hierarchie dargestellt. 7.3.2.1

Multidimensionale Daten zur Prüfung der Zielerreichung

Zur Überprüfung der Zielerreichung benötigen Zweckregeln multidimensionale Daten. Zur Prüfung der Kreditwürdigkeit ist dabei neben einer Zeitdimension lediglich eine Produktdimension notwendig, welche aus den Dimensionsebenen Produkt, Typ, Kategorie und Alle Produkte besteht. Außerdem sind die Kennzahlen Kreditsumme (IST) und Kreditsumme (SOLL) erforderlich. Das konzeptionelle MER-Modell des Hypercubes GoodBonk_KW ist Abbildung 69 zu entnehmen.

250

Prototyp

Abbildung 69: Konzeptionelles Modell des Hypercubes Goodbank_KW

Monat Kreditsumme (Isn ICredltsumme (sou.)

7.3.2.2

ECA-Regeln und Aktivierungsmatrix

Die Prüfung der Kreditwürdigkeit stellt im Sinne dieser Arbeit ein komplexes Ereignis dar, welches sich aus der persönlichen und der wirtschaftlichen Kreditwürdigkeit zusammensetzt. Da die Daten zur Prüfung der persönlichen Kreditwürdigkeit in einem Datenstrom eintreffen und auch die Daten zur Prüfung der wirtschaftlichen Kreditwürdigkeit über einen Zeitstempel verfügen und als Datenstrom aufgefasst werden können, kann die Prüfung der Kreditwürdigkeit mithilfe kontinuierlicher Anfragen eines CEP-Systems automatisiert werden. Für die automatische Verarbeitung sollten die Daten zu persönlicher und wirtschaftlicher Kreditwürdigkeit innerhalb kurzer Zeit (hier: 1 Stunde) eintreffen. Andernfalls werden die Daten manuell bearbeitet. Das auslösende komplexe Ereignis stellt somit eine Sequenz aus den Ereignissen persönliche Kreditwür-

digkeit und wirtschaftliche Kreditwürdigkeit dar. Dieses komplexe Ereignis ist im Ereignisteil (ON) der ECA-Regel in Abbildung 70 in CCL-Syntax dargestellt.

251

Prüfung der Kreditwürdigkeit

Abbildung 70: ECA-RegeIKreditl_70

ON

MATCHING [1 HOUR: wirtschaftliche_Kreditwuerdigkeit, persoenliche_Kreditwuerdigkeit] ON persoenliche_Kreditwuerdigkeit.KundenID =wirtschaftliche_Kreditwuerdigkeit.KundenID

IF

wlrtschaftllche_Kredltwuerdlgkelt.KredltID =1 AND ((wirtschaftliche_Kreditwuerdigkeit.Kredithoehe/wirtschaftliche_Kreditwuerdigkeit.LZ) Iwirtschaftliche_Kreditwuerdigkeit.verfEinkommen_M < 0.5) AND (persoenliche_Kredltwuerdlgkelt.Score > 70);

DO

INSERT INTO Kredit....lenehmigt

Ist die Regel aktiviert, so wird nach Eintreten des komplexen Ereignisses der Bedingungsteil überprüft. Die oben dargestellte Regel Kredit1JO bezieht sich auf Ratenkredit mit 12 Monaten Laufzeit (Kredit-ID 1). Darüber hinaus ist die persönliche Kreditwürdigkeit erfüllt, wenn der Score-Wert größer 70 ist. Die wirtschaftliche Kreditwürdigkeit ist in der oben dargestellten Regel erfüllt wenn: Kredithähe Laufzeit < 0,5 monatlIchesEInkommen

Sind sämtliche Bedingungen erfüllt, so erzeugt der Aktionsteil der ECA-Regel in der Tabelle Kredit--,!enehmigt einen Datensatz. Wenn die angestrebten Kreditsummen zu hoch oder zu niedrig sind, kann die Zweckregel den Score-Wert zur Prüfung der persönlichen Kreditwürdigkeit durch Aktivieren und Deaktivieren von ECA-Regeln entsprechend heben oder senken. Bspw. existieren für Ratenkredit mit 12 Monaten Laufzeit neben der oben dargestellten Regel noch die ECA-Regeln Kredit1_65, Kredit1_75 und Kredit1_80 mit den Score-Werten 65, 75 bzw. 80. Damit diese Regeln von Zweckregeln aktiviert und deaktiviert werden können, sind entsprechende Aktivierungsmatrizen in Konnektortabellen zu hinterlegen. Da die Aktivierungsmatrizen der in diesem Abschnitt beschriebenen ECA-Regeln gleichartig

252

Prototyp

aufgebaut sind wie die Aktivierungsmatrizen in Abschnitt 7.2.2.2, unterbleibt hier eine ausführliche Beschreibung. 7.3.2.3

Zweckregel-Hierarchie Kreditwürdigkeit

Bei der Automatisierung der Führungsentscheidung "Prüfung der Kreditwürdigkeit" wird eine Zweckregel-Hierarchie verwendet, um die angestrebten Kreditsummen zu erreichen. Als Kennzahlen zur Prüfung der Zielerreichung werden die Kennzahlen Kreditsumme (IST) und Kreditsumme (SOLL) verwendet. Die Kennzahlen werden durch die Hierarchieelemente Konsumentenkredite und vergangener Monat beschrieben. Wenn das vorgegebene Ziel der Zweckregel nicht erreicht wird, sucht die Zweckregel in der entsprechenden Aktivierungsmatrix nach ECA-Regeln, die zur Lösung des Problems geeignet sind. Ist jedoch für das Entscheidungsproblem keine ECA-Regel bekannt, wird das Problem von der Zweckregel-Hierarchie spezifiziert. Als Spezifizierungshierarchie verwendet die vorliegende Zweckregel-Hierarchie die Produkthierarchie. Die Zweckregel-Hierarchie Kreditwürdigkeit ist als erweitertes MER-Modell in Abbildung 71 dargestellt.

253

Prüfung der Kreditwürdigkeit

Abbildung 71: Zweckregel-Hierarchie Kreditwürdigkeit

vel'langener Monat

1. eines} } - - - - - - ' E ( Monats

Ratenkredit

Annultatenkredlt

48M

7.3.3

Prototypische Implementierung mit Corol8 und Microsoft SQL Server 2008

Im folgenden Abschnitt wird die prototypische Implementierung der oben mithilfe konzeptioneller Modelle dargestellten Führungsentscheidung demonstriert. Die Implementierung weist teilweise große Ähnlichkeiten mit der in Abschnitt 7.2.3 dargestellten Implementierung der Führungsentscheidung "räumlich differenzierte Preispolitik" auf. Um Redundanzen zu vermeiden, werden einige Details, die in Abschnitt 7.2.3 gleichartig gelöst wurden, im Folgenden nicht oder nur sehr knapp beschrieben. Der Aufbau des Abschnitts ist gleichartig wie der Aufbau des vorigen Abschnitts. Zu Beginn wird in Abschnitt 7.3.3.1 die Implementierung des Hypercubes GoodBank_KW skizziert. Anschließend wird die technische Realisierung der oben dargestellten ECA-Regeln mithilfe des CEP-Systems Coral8 dargelegt, ehe in Abschnitt 7.3.3.3 die Implementierung der ZweckregelHierarchie demonstriert wird.

254

Prototyp

7.3.3.1 Die

Implementierung des Hypercubes GoodBank_KW

Datenhaltung

erfolgt

mithilfe

der

Data-Warehouse-Datenbank

GoodBank_KW_DW, welche auf einem Microsoft SOl-Server vorgehalten wird.

Die Befüllung der Datenbank erfolgt im vorliegenden Fallbeispiel nicht durch einen klassischen ETL-Prozess, sondern durch das im folgenden Abschnitt beschriebene CEP_System.659 Der Aktionsteil der dort physisch implementierten ECA-Regeln schreibt Jeweils einen Datensatz In dIe Fakttabelle der Datenbank,

wenn das definierte komplexe Ereignis eintritt und die formulierten Bedingungen erfüllt sind. Die Data-Warehouse-Datenbank fungiert als Datenquelle eines

zur Datenbereitstellung eingesetzten SSAS-Paketes. Die logische Struktur der Data-Warehouse-Datenbank ist im rechten Teil der SSAS-Datenquellensicht ersichtlich, welche in Abbildung 72 dargestellt Ist.

.•.

Abbildung 72: Datenquellenslcht GoodBank_KW

...._.,_ _, <-_.. . __ .... . ,,_. .. -,._--, _,,_.-. . . .... ...._-~

--~<-

~

_~_.l_

.
••

."

---

,,,~

-_....

;ij::.....

,_

_'''''''JWM

,~~

'--~""-"""'"

''"-''''--

,'"-"".~

-

-~

-~ ~.

~­ ~ ~~ ~

IW VII. Hyde (2010), S. 52.

..

~

Prüfung der Kreditwürdigkeit

255

Im linken Teil der Abbildung ist die Definition von Kennzahlen, Dimensionen und Hierarchien des Hypercubes zu erkennen. Darüber hinaus wird der Hypercu be um Soll-Daten und KPls ergänzt. Die Definition von Soll-Daten und KPls erfolgt ebenso wie in Abschnitt 7.2.3.1 und wird daher hier nicht detailliert beschrieben. 7.3.3.2

Implementierung der ECA-Regeln mit Coral8

Die Implementierung der oben dargestellten ECA-Regeln erfolgt mit dem CEPSystem CoraI8.

660

Das System besteht zum einen aus der Entwicklungsumge-

bung Coral8 Studio und dem Coral8 Server. Mithilfe von Coral8 Studio werden Coral8-Projekte erstellt, die dann vom Coral8 Server ausgeführt werden. Projekte werden mithilfe der Sprache CCL erstellt und enthalten außer mehreren kontinuierlichen Anfragen mit Musteroperatoren auch Definitionen zu Dateninput, Datenoutput, Datenströmen und Fenstern.'" In Abbildung 73 ist der Datenfluss des Coral8-Projektes Kreditl_70 dargestellt. Auf der linken Seite sind mit GoodBonk_OLTP und Dienstleister der Dateninput sowie die daraus resultierenden Datenströme wirtschajtliche_Kreditwuerdigkeit und persoenli-

che_Kreditwuerdigkeit zu erkennen.

660

Ausführliche Informationen zu CoralS finden sich unter http://www.aleri.com. Eine Beschreibung und Bewertung der wesentlichen Funktionalitäten findet sich bspw. in Borck

(2007). 661

Die ausführliche Dokumentation zu CoralS findet sich unter http://www.aleri.com/WebHelp/coraIS_documentation.htm dokumentiert in Aleri (2009).

Die

Sprache

CCl

ist

auch

256

Prototyp

Abbildung 73; Datenfluss Coral8-ProJekt Kredltl_70

.... _----

r;

~.!III . " .

___________________--;1

~ . . . . . . . . ..

.,,~,

_.~ ""-.~" "~._"_.

In der Mitte sind drei Anfragen dargestellt, wobei die oberste Anfrage die ECA-

Regel aus Abbildung 70 technisch realisiert und den Datenstrom Kre-

dit_genehmigt generiert. Wenn das definierte Ereignismuster eintritt und die Bedingungen der ECA-Regel erfüllt sind, so werden die Daten in die Fakttabelle der Data-Warehouse-Datenbank geschrieben.662 In dem Coral8-Projekt werden

zwei weitere Anfragen formuliert, die den Datenstrom Kredicnichtgenehmigt befüllen, wenn Daten fehlen oder wenn die persönliche Kreditwürdigkeit nicht erfüllt Ist. Es empfIehlt sich eIne manuelle Nachbearbeitung dieser Daten, wo-

bei dies jedoch hier nicht implementiert wird. Coral8-Projekte können gestartet und gestoppt werden und eignen sich daher für einen Einsatz im Rahmen des AvFe-Frameworks. Damit die Projekte von Zweckregeln entsprechend gesteuert werden können, werden Aktivierungs-vgl. Abschnitt 7.3.3.1.

Prüfung der Kreditwürdigkeit

257

matrizen in den Konnektortabellen der Data-Warehouse-Datenbank gespeichert. Die Konnektortabelle Kreditl (Ratenkredit mit 12 Monaten Laufzeit) ist in Tabelle 26 dargestellt. Der Status in der Spalte ZE repräsentiert dabei jeweils Kennzahlenbereiche und in den Spalten trigAkt und trigDeakt sind die zu aktivierenden bzw. deaktivierenden ECA-Regeln dargestellt. Tabelle 26: Konnektortabelle Kreditl

2E

trIgAkt

-1

KreditC65

7.3.3.3

trlgDeakt

Implementierung der Zweckregel-Hierarchie Kreditwürdigkeit

Die Implementierung der Zweckregel-Hierarchie Kreditwürdigkeit erfolgt - wie schon die Implementierung der Zweckregel-Hierarchie Preispolitik - durch ein ssls-Paket, welches monatlich vom sQL-server-Agenten ausgeführt wird. Sowohl Datenfluss als auch Ablaufsteuerung entsprechen weitgehend der Darstellung in Abschnitt 7.2.3.3 und werden daher nicht ausführlich dargestellt. Der einzige erwähnenswerte Unterschied besteht darin, dass das Aktivieren und Deaktivieren von ECA-Regeln etwas aufwändiger ist, da die Regeln durch das proprietäre CEp-system Coral8 betrieben werden und eine Schnittstelle zu diesem System zu entwickeln ist. In der Ablaufsteuerung des ssls-Pakets enthält jede einzelne Zweckregel daher statt einem Task sQL ausführen einen

Skripttask. In Abbildung 74 ist dies im screenshot der Ablaufsteuerung der Zweckregel-Hierarchie Kreditwürdigkeit erkennbar.

258

Prototyp

Abbildung 74: Ablaufsteuerung der Zweckregel-Hierardlie Kreditwürdigkeit

------_ ., ..,.. · _ ·"l . . . ......... ... ... ..==-.;~..-;;~:;..:i;;--~ .I

IiI,, ·&

-=-' ':!

=---1 "'-- • ;'l-

.I_

;'l-

o

•

rI-

tgg="J • 1'1-

1'1-'

"'-1 .1-

I'" -'-' -'I J

1.1_

-

,-

.lI

.1_

~~

•

-

W::----

0

• • •

i'-

•

1",..,..-..1 I

1.1_

1 -

; ] -,

0

'W _ _ .

-

•

.1-

F::-----"'

-

----",,",

Der Skripttask nutzt die Tatsache, dass Coral8-Projekte mithilfe der Eingabeaufforderung gestartet und gestoppt werden können. Der Task aktiviert und deaktlvlert die entsprechenden Projekte, Indem die EIngabeaufforderung mit Parametern aufgerufen wird. Damit Ist die Darstellung des Prototyps abgeschlossen. Die Erkenntnisse der Prototyp-Entwicklung fließen in den Konformitätstest im folgenden Kapitel ein.

Konformitätstest

8

Im vorliegenden Kapitel wird mithilfe eines Konformitätstests die Angemessenheit des AvFe-Frameworks und der vorgeschlagenen Modeliierungssprachen geprüft, wobei das AvFe-Framework den zuvor formulierten Anforderungen gegenübergestellt wird und die Konformität der Modellierungssprachen mithilfe der GoM geprüft wird. Das AvFe-Framework stellt eine grundsätzliche Orientierung zur Verfügung, wie Führungsentscheidungen zu automatisieren sind, und wird im Folgenden den in Abschnitt 3.3.2 formulierten Anforderungen gegenübergestellt. Die technische Machbarkeit des Frameworks wurde bereits in Kapitel 7 bei der Entwicklung des Prototyps demonstriert und wird im Folgenden lediglich am Rande betrachtet. Ausgangspunkt des Konformitätstests für das AvFe-Framework ist die notwendige Anforderung (nA), weiche reaktive Komponenten bei dem verwendeten Informationssystem fordert. Ein Informationssystem, welches gemäß dem AvFe-Framework entwickelt wird, verfügt durch die integrierten ECA-Regeln über derartige reaktive Komponenten.'" Die Anforderungen hAl, hA2 und hA5 verlangen, dass Informationssysteme, welche Führungsentscheidungen automatisieren, alle Bestandteile einer Entscheidungssituation darstellen können. Die Forderung nach Zielen (hAl) wird im Rahmen des AvFe-Frameworks durch Zweckregeln erfüllt, wobei die dort enthaltenen Ziele mithilfe analytischer Informationssysteme multidimensional beschrieben werden."" Darüber hinaus können Zweckregel-Hierarchien die 6S

kausale Verkettung von Zielen (hA2) abbilden" Die Anforderung hA5 fordert, dass Informationen zu Handlungsalternativen entsprechend vorgehalten werden. Bei einem Informationssystem gemäß dem AvFe-Framework stellen ECARegeln, gleich ob diese in aktiven Datenbanksystemen, DSMS oder CEPSystemen realisiert werden, Handlungsalternativen dar. Informationen über

6S 664

665

Vgl. Abschnitt 5.2.1.4. Vgl. zu Zweckregeln Abschnitt 5.2.1.1 und zur Nutzung multidimensionalen Daten zur Prüfung der Zielerreichung Abschnitt 5.2.1.2. Vgl. Abschnitt 5.2.2.1.

J. Rommelspacher, Automatisierung von Führungsentscheidungen, DOI 10.1007/978-3-8348-8251-6_8, © Vieweg + Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

Konforrnitätstest

260

Handlungsalternativen werden gemäß dem AvFe-Framework in Aktivierungsmatrizen gespeichert.'" Es kann zusammenfassend festgestellt werden, dass Informationssysteme, die entsprechend dem AvFe-Framework realisiert werden, alle Bestandteile einer Entscheidungssituation enthalten. Die Anforderungen hA3 und hA4 zielen darauf ab, die Ziele von Führungskräften mit dem Zustand des Realitätsausschnitts vergleichen zu können. Zur Spezifizierung allgemeiner Probleme fordert hA3 die Existenz flexibler Bezugsobjekthierarchien und zur Konkretisierung unklarer Probleme die Anforderung hA4 multidimensionale Sichten auf Wert- und Mengengrößen. Der Forderung nach multidimensionalen Sichten genügt die Nutzung multidimensionaler Daten.'" Die Anforderung hA3 wird durch die Nutzung multidimensionaler Hierarchien durch Zweckregel-Hierarchien erfüllt.'" Die Anforderung hAG betont die strukturelle Dynamik des Realitätsausschnitts und fordert, dass ein Informationssystem, welches Führungsentscheidungen automatisiert, diese Dynamik beherrschen muss. Zweckregel-Hierarchien können strukturelle Dynamik in beträchtlichem Maße absorbieren, indem Zweckregeln revolvierend Ziel und Zustands eines Realitätsausschnitts miteinander vergleichen.'" Liegt ein bekanntes Problem vor, so werden ECA-Regeln entsprechend aktiviert und deaktiviert. Liegt dagegen kein bekanntes Problem vor oder kann das Problem nicht dauerhaft gelöst werden, so werden Führungskräfte persönlich informiert. Als Vorteil des AvFe-Frameworks ist zudem anzusehen, dass offengelegt wird, welchem Ziel ECA-Regeln dienen. Bei ausschließlicher Verwendung von ECA-Regeln ist dies nicht ersichtlich, da ECA-Regeln explizit keine Ziel beschreibung enthalten. Die Anforderungen hA7 und hA8 verlangen, dass Veränderungen im relevanten Realitätsausschnitt durch elementare und komplexe Ereignisse abgebildet werden. Derartige Ereignisse können Konditionalprogramme auslösen, welche die Dynamik in stabilen Systemen absorbieren können. Die Anforderungen werden von ECA-Regeln erfüllt, wobei das AvFe-Framework keine Bindung an

666 667 668

66i

Vgl. Abschnitt 5.2.1.3. Vgl. Abschnitt 5.2.1.2. Vgl. Abschnitt 5.2.2. Vgl. zur Absorption von Dynamik durch Programmhierarchien Abschnitt 5.1.2.

Konformitätstest

261

eine bestimmte Technologie vorsieht."o Im Prototyp wurden bspw. ECARegeln in einem aktiven Datenbanksystem und einem CEP-System realisiert. Zusammenfassend kann festgestellt werden, dass ein Informationssystem, welches gemäß dem AvFe-Framework entwickelt wird, vollständig konform mit den in Abschnitt 3.3.2 formulierten Anforderungen ist. Eine Führungsentscheidung, deren Bestandteile in der geschilderten Art und Weise vollständig beschrieben werden können, ist somit der Automatisierung zugänglich. Abschließend ist die Angemessenheit der ausgewählten und entwickelten Modellierungssprachen zu beurteilen. Die Prüfung erfolgt im Folgenden, indem die resultierenden Modelle mithilfe der wesentlichen Qualitätskriterien der GoM beurteilt werden:'" Der Grundsatz der Richtigkeit fordert, dass ein Modell den zu repräsentierenden Sachverhalt korrekt wiedergibt. Dies ist im vorliegenden Fall gewährleistet, da Metamodelle der Teilmodelle existieren und die Modellierungssprachen einer Repräsentationsanalyse unterzogen werden, um die Richtigkeit sicherzustellen. Der Grundsatz der Relevanz besagt, dass nur Sachverhalte modelliert werden, die für den Modellierungszweck (pragmatisch) relevant sind. Der intendierte Zweck besteht in dieser Arbeit erstens in der Erstellung konzeptioneller Modelle. Dies wird als besonders wichtig erachtet, da bei der Automatisierung von Führungsentscheidungen eine intensive Kommunikation mit Führungskräften notwendig ist, was durch die vorgestellten semi-formalen Modellierungsspraehen gewährleistet ist. Zweitens sollen die Modellierungssprachen zum Erstellen der Teilmodelle des AvFe-Frameworks dienen. Auch dies erfüllen die verwendeten Modellierungssprachen. Der Grundsatz der Wirtschaftlichkeit fordert, dass die Modellierungsaktivitäten in einem angemessenen Nutzen-Aufwand-Verhältnis stehen. Dies ist bei den vorgeschlagenen Modellierungssprachen nach Auffassung des Verfassers gewährleistet.

670 671

Vgl. Abschnitt 5.2.1.4. Vgl. ausführlich Becker et al. (1995); Schütte (1998), S. 111 ff.; Knapper bei Becker, Schütte (2004). s. 12011.

262

Konformitätstest

Der Grundsatz des systematischen Aufbaus zielt auf die Darstellung eines Sachverhaltes aus unterschiedlichen Sichten ab. Die Darstellung in mehreren Sichten oder vielmehr Teilmodellen gewährleisten die ModelIierungssprachen, allerdings stellen diese kein übergreifendes oder integrierendes Modell zur Verfügung. Die potenzielle Integration der Teilmodelle gewährleistet vielmehr das sprachbasierte Metamodell des AvFe-Frameworks. Wesentlich für den Grundsatz der Klarheit ist, dass der Modellnutzer ein Modell auch versteht. Die ausgewählten Modellierungssprachen ermöglichen dies, da diese semi-formal und im Wesentlichen intuitiv verständlich sind. Der Grundsatz der Vergleichbarkeit fordert, dass real existierende Modelle miteinander verglichen werden können. Dies wird im vorliegenden Fall durch die Verwendung eines Metamodells sichergestellt. Wenn sich alle verwendeten Modellierungssprachen auf dieses Metamodell beziehen, so sind die resultierenden Modelle entsprechend vergleichbar.

Fazit

9

Im vorliegenden Kapitel werden die wesentlichen Ergebnisse dieser Arbeit zusammengefasst und es wird auf potenzielle Weiterentwicklungen eingegangen. Das wichtigste Ergebnis dieser Arbeit ist das in Kapitel 6 entwickelte Framework zur Automatisierung von Führungsentscheidungen, welches mithilfe einer wissenschaftlichen Forschungsmethode hergeleitet und durch einen Konformitätstest begründet wurde. Das AvFe-Framework sowie die korrespondierenden Modellierungssprachen erfüllen die formulierten Anforderungen und ermöglichen somit die Automatisierung von strukturierten Führungsentscheidungen. Die Entwicklung des Prototyps in Kapitel 7 zeigt darüber hinaus, dass zum einen das Framework technisch implementiert werden kann und zum anderen die vorgeschlagenen Modellierungssprachen gute Dienste bei der Entwicklung derartiger Informationssysteme leisten. In dieser Arbeit wurden gewisse Fragestellungen bewusst ausgeblendet, weIche Ansatzpunkte einer Weiterentwicklung des Frameworks darstellen können: •

Nicht diskutiert wurde der parallele Einsatz mehrerer ZweckregelHierarchien. Dies ist erstens für mehrdimensionale Entscheidungsfelder und zweitens zum Vermeiden von Fehlsteuerungen zwischen untergeordneten Hierarchieelementen ein vielversprechender Ansatz.

•

Das Zielsystem von Fach- und Führungskräften beschränkt sich in Anforderung hA2 auf kausale Beziehungen zwischen Zielen. Nicht betrachtet werden dabei die potenzielle Interdependenz sowie die Präferenzrelation zwischen Zielen. Diese Merkmale des Zielsystems stellen Ansatzpunkte einer Weiterentwicklung dar.

•

Die Aktivierungsmatrizen verwenden lediglich eine ausgewählte Kennzahl. Zur Repräsentation eines Zustands des Realitätsausschnitts können mehrere Kennzahlen erforderlich sein. Dies wurde jedoch in der vorliegenden Arbeit nicht diskutiert.

J. Rommelspacher, Automatisierung von Führungsentscheidungen, DOI 10.1007/978-3-8348-8251-6_9, © Vieweg + Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

264

•

Fazit

Insgesamt wird die Interaktion zwischen Führungskräften und einem Informationssystem, welches nach dem AvFe-Framework entwickelt wird, nur am Rande betrachtet. Wenn Zweckregel-Hierarchien Probleme nicht selbstständig lösen können, so müssen Führungskräfte automatisch informiert werden. Vor einem produktiven Einsatz muss auch die Administration und Überwachung derartiger Systeme ausführlicher diskutiert werden.

•

Zur Implementierung und Pflege der vorgeschlagenen Informationssysteme benötigen die Mitarbeiter weitere Werkzeuge. Angesichts der Komplexität der in Unternehmen anzutreffenden Hierarchien in multidimensionalen Datenmodellen kann bspw. die Implementierung und pflege von Zweckregeln und Aktivierungsmatrizen durch Werkzeuge unterstützt werden.

•

Zu klären ist auch die Frage, wer für die automatisierten Führungsentscheidungen rechtlich verantwortlich ist. Damit eng verbunden ist das nicht diskutierte Problem, wie die automatisch getroffenen Entscheidungen protokolliert und gespeichert werden.

Zu betonen ist abschließend noch einmal, dass keinesfalls alle Führungsentscheidungen mithilfe des AvFe-Frameworks zu automatisieren sind, sondern dass die Arbeit vielmehr darauf abzielt, Führungskräfte von strukturierten Entscheidungen zu entlasten, sodass diese mehr Ressourcen für sem i- und unstrukturierte Entscheidungen aufwenden können. Trotz der genannten Ansatzpunkte für Weiterentwicklungen ist das AvFeFramework ein neuartiger und vielversprechender Ansatz zur Automatisierung von Führungsentscheidungen, welcher wesentliche Schwachpunkte bisheriger Ansätze überwindet. Durch die hierarchische Konstruktion von Zweckregeln und ECA-Regeln folgen letztere einem expliziten Ziel und die strukturelle Dynamik des Realitätsausschnitts kann durch revolvierenden Abgleich von Ziel und Zustand in beträchtlichem Maße absorbiert werden, was eine deutliche Weiterentwicklung darstellt.

Anhang

A

Entlty-Relationshlp-Modell •••••••••••••••••••••••.•••••••••••••••••• ••••••.•••••••••••••• 267

A.1

Sprachbaslertes Metamodell zur Definition der abstrakten Syntax ....... 267

A.2

Die konkrete Syntax des Entity-Relationship-Modells ............................ 269

B

Erelgn1saesteuerte Prozess ketten ••••••••••••••••••••••••••••••••••••••••••••••••••••• 271

B.1

Modellierungssprache ............................................................................ 271

8.1.1 Sprachbaslertes Metamodell zur Definition der abstrakten Syntax .............................................................................. 271 B.1.2 Die konkrete Syntax ereignisgesteuerter Prozessketten ...................276 B.2

Prozessorientiertes Metamodell zur Definition der Handlungsanleitung ................................................................................ 276

J. Rommelspacher, Automatisierung von Führungsentscheidungen, DOI 10.1007/978-3-8348-8251-6, © Vieweg + Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

A

Entity-Relationship-Modell

Das ER-Modell ist eine sem i-formale Modellierungssprache zur Beschreibung von Strukturen. Es wurde 1976 von CHEN entwickelt und ist insbesondere für die konzeptionelle Beschreibung von Datenstrukturen weit verbreitet.'72 Zunächst wird in Abschnitt A.l die abstrakte Syntax des ER-Modells in Form eines sprach basierten Metamodells dargestellt. In Abschnitt A.2 wird anschließend die konkrete Syntax des ER-Modells präsentiert, welche in dieser Arbeit verwendet wird. A.l

Sprachbasiertes Metamodell zur Definition der abstrakten Syntax

Ausgangspunkt der ER-Modellierung sind die zu beschreibenden konkreten Objekte der Realwelt (z. B. Kreditnehmer XV, GoodBank AG, Konto 0815), weiche im ER-Modell als Entitäten bezeichnet werden. Wenn Entitäten durch identische Merkmale (Attribute) beschrieben werden, so kann die Gesamtheit gleichartiger Entitäten zu Entitätstypen zusammengefasst werden.

673

Die zu-

sammengefassten Entitätstypen unterscheiden sich allerdings hinsichtlich der Attributwerte, wobei der mögliche Wertebereich (die Domäne) der Attribute üblicherweise beschränkt ist.'74 Wenn eine Entität durch ein Attribut exakt zu identifizieren ist, so wird dieses als Schlüsselattribut bezeichnet.'75 Entitäten sind miteinander verbunden durch konkrete Beziehungen. Werden dagegen - wie im ER-Modell üblich - Entitätstypen modelliert, so sind die gleichartigen Beziehungen zu Beziehungstypen zusammenzufassen, die ebenfalls Attribute besitzen können. Beziehungstypen repräsentieren dabei unterschiedliche Komplexitätsgrade, welche als min,max-Kardinalitäten an der verbindenden Kante zwischen Beziehungstypen und Entitätstypen notiert werden. In der Literatur werden verschiedene Ansätze zur Darstellung der Kardinalitäten diskutiert. Während CHEN vorschlägt, die Anzahl der verbundenen Entitäten zu annotieren, schlagen SeHLAGETER und STUeKY vor, die Anzahl der Beziehungen

." Vgl. ehen (19761, S. 91f. 673 Diese Abstraktion wird als Klassifikation bezeichnet. Vgl. Abschnitt 6.1.1. 674 Vgl. Vossen (20OS), S. 62. 675 Vgl. Vossen (2008), S. 64 f.

Entity-Relationship-Modell

268

darzustellen."76 Bei binären Beziehungstypen unterscheiden sich die Notationen lediglich in der Leserichtung der Kardinalitäten. Bei n-ären Beziehungstypen ist die Schlageter/Stucky-Notation jedoch als überlegen anzusehen und wird daher in dieser Arbeit verwendet."77 In Abbildung 75 sind die skizzierten Konstrukte des ER-Modells als sprach ba-

siertes Metamodell in Anlehnung an BECKER et al. dargestellt."78 Dabei werden Entitätstyp und Beziehungstyp durch eine Kante miteinander verbunden. Entitätstyp und Beziehungstyp sind nicht-disjunkte, totale (n,t) Spezialisierungen des Entitätstyps Typ. Durch diesen stehen die beiden in Verbindung mit dem Entitätstyp Attribut. Abbildung 75: Sprachbasiertes Metamodell des ER-Modells

Entitiihtyp

Ein Intitiltstyp darf ,"ch selb't nichl ~eneralisieTen/

we'i,li ' ier.n Altribut-Typ-luO

f----<"

Remil<:tiOlllyp-luO

Beliehunsstyp

Vgl. Becker et al. 120021, S. 78.

676 671

611

Vgl. ehen (1976), S. 18 f.; Schlageter, Stucky (1983), S. 50 ff. Vgl. Rauh, Stickel (1997), S. 89 ff.; Schütte (1998), S. 94 f. Vgl. Becker et al. (2002), S. 77 ff.

Generalisierung! Sre,i~lj5ierung

Die konkrete Syntax des Entity-Relationship-Modells

269

Darüber hinaus sind in dem Metamodell noch zwei Erweiterungen enthalten.

Restriktionen können an Entitätstypen oder Beziehungstypen annotiert werden, um in Textform spezielle Beschränkungen darstellen zu können. Zur Modellierung von Generalisierungen und Spezialisierungen von Entitätstypen wird zudem noch der Entitätstyp Generalisierung/Spezialisierung eingeführt. Eine selbstreferenzielle Generalisierung oder Spezialisierung ist durch eine Beschränkung allerdings ausgeschlossen. Wie im folgenden Abschnitt dargestellt, können vier verschiedene Typen der Spezialisierung unterschieden werden.'" A.Z

Die konkrete Syntax des Entity-Relationship-Modells

In Abbildung 76 ist die konkrete Syntax des ER-Modells dargestellt, die in dieser Arbeit verwendet wird. Das ER-Modell wird in dieser Arbeit zur Modellierung von Strukturen im Allgemeinen und sprachbasierten Metamodellen im Speziellen eingesetzt.

679

Vgl. ausführlich Becker et al. (2002), S. 77 ff.

270

Entity-Relationship-Modell

Abbildung 76: Die konkrete Syntax des ER-Modells

D

<> o

-min,max-

.. ~alt der Restriktion

Entitätstyp

Beziehungstyp

Attribut Kante mit Kardinalitäten

Restriktion

0,1

Nicht notwendig, maximal ein Beteiligter

1,1

Notwendig. maximal ein Beteiligter

O,n

Nicht notwendig, maximal unbegrenzt

1,n

Notwendig. maximal unbegrenzt

~ ~ ~ ~

Disjunlrte und totale Spezialisierung

Disjunkte und partielle Spezialisierung

Nicht-disjunkte und totale Spezialisierung

Nicht-disjunkte und partielle Spezialisierung

Ereignisgesteuerte Prozessketten

B

EPK ist eine sem i-formale ModelIierungstechnik zur (konzeptionellen) ModelIierung von (Geschäfts-)Prozessen, die von KELLER et al. entwickelt wurde.'"o Die Modellierungstechnik ist wesentlicher Bestandteil des ARIS-Frameworks und hat insbesondere im deutschsprachigen Raum große Verbreitung erfahren. Im Folgenden wird in Abschnitt B.1 zunächst die abstrakte und konkrete Syntax der Modellierungssprache dargestellt. Zur Darstellung der abstrakten Syntax wird dabei das sprachbasierte Metamodell der EPK präsentiert. In Abschnitt B.2 wird die Handlungsanleitung der EPK mithilfe des prozessbasierten Metamodells dargestellt. B.1

Modellierungssprache

B.1.1

Sprachbasiertes Metamodell zur Definition der abstrakten Syntax

Mit der EPK werden Prozesse modelliert, wobei Prozesse durch Aggregation (po) mehrerer Prazesselemente entsteht, die wiederum in Operatoren, Ereignisse, Funktionen und Prozessschnittstellen spezialisiert werden.'" Funktionen beschreiben die Aktivitäten und Aufgaben innerhalb eines Prozesses, werden ausgelöst durch Ereignisse und stellen wiederum Ereignisse bereit.

682

Zur Ver-

knüpfung von Ereignissen und Funktionen stehen logische Operatoren (AND, OR, XOR) zur Verfügung. Funktionen können durch einen Prozess detailliert

61KI 681

Vgl. Keller et al. (1992). Vgl. zu den Abstraktionsprinzipien

Aggregation

und

Generalisierung/Spezialisierung

Abschnitt 6.1.1. 682

Das in diesem Abschnitt dargestellte sprachbasierte Metamodell einer EPK orientiert sich an

Becker et al. (2002), S. 85 ff.; Becker et al. (2003b), S. 46 f. Ein Aspekt, der hier nicht dargestellt wird, ist die mehrfache Verwendung gleichnamiger Prozesselemente in einem Prozess. Becker et al. (2002), S. 86 unterscheiden zu diesem Zweck zwischen Funktion und Prozessfunktion. Rosemann (1996), S. 116 ff. trennt In seinem Metamodell zur Unterscheidung von prozessindividuellen und prozessübergreifenden Prozesselementen zwischen Struktur und Verhalten. Weitere Varianten für das sprachorientierte Metamodell der EPK findet sich in Scheer (1998a), S. 125 ff. oder Priemer (1995), 5. 250.

Ereignisgesteuerte Prozessketten

272

werden (sog. Funktionsverfeinerung). Mehrere (Teil-)Prozesse können durch

Prozessschnittstellen miteinander verbunden werden.'" Wenn mithilfe des ER-Modells (vgl. Kapitel A) ein sprachbasiertes Metamodell erstellt wird, so sind die skizzierten Konzepte als Entitätstypen darzustellen. Darüber hinaus sind die Beziehungen zwischen diesen zu definieren: Operatoren, Ereignisse, Funktionen und Prozessschnittstellen sind disjunkte und totale (d,t) Spezialisierungen des Entitätstyps Prozesselernent. Der Beziehungstyp detailliert zwischen den Entitätstypen Prozess und Funktion beschreibt die Funktionsverfeinerung. Die Aggregationsbeziehung zwischen Prozesselementen und Prozess wird durch den po-Beziehungstyp modelliert. Das skizzierte sprachbasierte Metamodell der EPK ist in Abbildung 77 dargestellt. Abbildung 77: Sprachbasiertes Metamodell der EPK

Prozess

,1

detailliert

0,1

Funktion

l,n Ereignis po

Vorgänger! Nachfolger

O,n

Operator

O,n 1,1

Prozesselement

d,t

Prozessschnittstelle

In der Abbildung ist zudem der rekursive Beziehungstyp Vorgänger/Nachfolger an den Entitätstyp Prozesselement angefügt, Damit wird dargestellt, dass die 683

Die Prozessschnittstellen sind in dem Metamodell von Becker et al. (2002) nicht enthalten. Die Berücksichtigung dieses Prozesselementes geht auf einen Vorschlag von Seel, Vanderhaegen (2005), S. 125 zurück.

Modellierungssprache

273

Prozesselemente zueinander in Beziehung stehen. Bei der EPK ist allerdings zu beachten, dass es sich um einen sogenannten bipartiten Graph handelt, in dem die Prozesselemente Funktion und Ereignis alternierend auftreten. Zur ModelIierung der Einschränkung bzgl. der möglichen Beziehungen zwischen Prozesselementen schlagen BECKER et al. vor, die Kardinalitäten zwischen den verschiedenen Prozesselementen zur Formulierung von Konsistenzregeln zu verwenden und diese in einer (ergänzenden) Tabelle darzustellen.'" So bedeuten etwa die Kardinalitäten (0,0), dass keine Beziehung zwischen den Prozesselementen möglich ist. Die genannten Konsistenzregeln finden sich in Tabelle 27.

684

Vgl. Becker et al. (2002), S. 88 f.

Ereignisgesteuerte Prozessketten

274

Tabelle 27: Beschränkungen der direkten Vorgänger-Nachfolger-Beziehung Vorganger

Nachfolger

Kardlnalltät

Vorgän-

Kardinalltät Nachfol-

ger

ger

Ereignis

Funktion

(0,1)

(0,1)

Ereignis

Ereignis

(0,0)

(0,0)

Funktion

Ereignis

(0,1)

(0,1)

Funktion

Funktion

(0,0)

(0,0)

Funktion

AND-Operator

(0,1)

(O,n)

Funktion

OR-Operator

(0,1)

(O,n)

Funktion

XOR-Qperator

(0,1)

(O,n)

Ereignis

AND-Operator

(0,1)

(O,n)

Ereignis

OR-Operator

(0,1)

(0,0)1 (2,n)

Ereignis

XOR-Qperator

(0,1)

(0,0)1 (2,n)

AND-Operator

Ereignis

(O,n)

(0,1)

AND-Operator

Funktion

(O,n)

(0,1)

AND-Operator

AND-Operator

(O,n)

(O,n)

AND-Operator

OR-Operator

(O,n)

(O,n)

AND-Operator

XOR-Operator

(O,n)

(O,n)

OR-Operator

Ereignis

(O,n)

(0,1)

OR-Operator

Funktion

(O,n)

(0,1)

OR-Operator

AND-Operator

(O,n)

(O,n)

OR-Operator

OR-Operator

(O,n)

(O,n)

OR-Operator

XOR-Operator

(O,n)

(O,n)

XOR-Operator

Ereignis

(O,n)

(0,1)

XOR-Operator

Funktion

(O,n)

(0,1)

XOR-Operator

AND-Operator

(O,n)

(O,n)

XOR-Operator

OR-Operator

(O,n)

(O,n)

XOR-Operator

XOR-Operator

(O,n)

(O,n)

Vgl. Becker et al. (2002), S. 89.

27S

Modellierungssprache

Wenn die EPK um die Annotation von Ressourcen an Prozesselemente erweitert wird, so wird diese Variante als erweiterte EPK (eEPK) bezeichnet.'" In Abhängigkeit von der verwendeten Spezialisierung des Ressourcentyps kommen unterschiedliche Beziehungstypen zwischen Prozesselementen und Ressourcen zum Einsatz. Dieser Sachverhalt wird durch den Entitätstypen Prozess-

Ressourcen-Beziehungstyp dargestellt, der zudem mit sich selbst in Beziehung steht und somit auch Hierarchien von Beziehungstypen abbilden kann. Mithilfe des Beziehungstyps PE-Ressourcen-ZuO wird die spezifische Beziehung zwischen Prozesselement und Ressource dargestellt. In Abbildung 78 ist das sprachbasierte Metamodell der eEPK nach BECKER et al. als ER-Modell dargestellt. Abbildung 78: Sprachbaslertes Metamodell der eEPK

8'

det
0.'

Funktion

~

Vorgänger Nachfolger

0.'

~ O,n

11

Or~,ni,ation,ooi<'kt

Operator

Anwendungssystemtyp

,

Fachl:tegriff

Proze"element I--~('.' 1----'-----1prozesS
Proze,,Re"ourcen-

Ressource

Beliehungstyp

Vgl. Becker et 01. (2002), S. 87.

6lI5

Vgl. Scheer (1998b), S. 49 ff.; Scheer, Thomas (2005), S. 1069 ff. Es existiert eine Vielzahl an Erweiterungen. Bspw. schlägt Rosemann (1996), S. 140 ff. die Integration von Entscheidungstabellen vor und Priemer (1995), S. 296 ff. führt einen Sequenzoperator ein.

276

Ereignisgesteuerte Prozessketten

B.1.2

Die konkrete Syntax ereignisgesteuerter Prozessketten

In Abbildung 79 ist die konkrete Syntax der Prozesselemente einer EPK dargestellt, die in dieser Arbeit verwendet wird. Damit die Darstellung nicht zu unübersichtlich wird, ist die konkrete Syntax der Ressourcen nicht enthalten. Die EPK in der dargestellten Notation wird dieser Arbeit zur Modellierung von Abläufen verwendet. Abbildung 79: Die konkrete Syntax der EPK

Prozess-

schnittstelle )

888

Funktion mit Verfeinerung

--Kontrollfluss------..

B.2

Prozessorientiertes Metamodell zur Definition der Handlungsanleitung

Im Gegensatz zu dem sprachorientierten Metamodell wurde das prozessorientierte Metamodell der EPK in der Literatur bisher nicht diskutiert und wird im Folgenden hergeleitet. Einleitend ist die Tatsache zu betonen, dass die zu modellierenden Prozesse in der betrieblichen Praxis üblicherweise eine außerordentliche Komplexität aufweisen. Zur Beherrschung dieser Komplexität ist eine schrittweise Detaillierung von Prozessmodellen zu empfehlen, d. h. die Modellierung beginnt mit einem recht allgemeinen Prozessmodell, das nach und nach verfeinert wird .... Wenn der zu modellierende Gegenstand sehr hoch aggregiert ist, so werden oftmals die wertschöpfenden Prozesse eines Unternehmens als Einstiegsebene ver-

686

Vgl. Häuslein (2004). S. 108 ff.; Scheer, Thomas (2005), S. 1075 f.; Krallmann et al. (2007),

S.97ff.

Prozessorientiertes Metamodell zur Definition der Handlungsanleitung

277

wendet.'" Zur Modellierung dieser werden statt der EPK häufig WKDs verwendet. Bei einer Verfeinerung wird dann jeder wertschöpfende Prozess durch ein EPK-Modell verfeinert.'" Um die schrittweise DetailIierung von EPK-Modellen zu realisieren, müssen zur Vorbereitung eine Einstiegsebene und ein Abbruchkriterium, das festlegt wann

die Verfeinerung endet, definiert werden. Des Weiteren ist auf jeder vorgesehen Hierarchieebene zu definieren, welche Modellierungssproche und welche Elemente der Sprache verwendet werden dürfen.'" Eine derartige Definition

findet sich in Tabelle 28. Tabelle 28: Modellierungssprachen und verwendete Elementtypen HIerarchieebene 1. Ebene

2. Ebene

3. Ebene

4. Ebene

Prozesse

Organisation

GB 080 GB 080 GB 080

Organisations einheit

Daten

Datencluster

Organisationseinheit

11 Stell. 1 1 P...o" 1

Vgl. Häuslei" (2004), S. 109.

6117

68B

689

Vgl. Häuslein (2004), S. 108. Ein Beispiel einer solchen schrittwelsen DetaIlIIerung enthält etwa Stähler (2005), S. 231. Eine derartige Verfeinerung wird in der Modellierungspraxis auch als Hinterlegung bezeichnet. Vgl. Häuslein (2004), S. 109.

278

Ereignisgesteuerte Prozessketten

Im Anschluss an diese Aktivität ist die EPK zu erstellen. Dabei sind zunächst die Ereignisse und Funktionen des Geschäftsprozesses zu erstellen. Anschließend ist der Kontrollfluss mithilfe entsprechender Operatoren darzustellen. Wenn es sich um eine eEPK handelt, so sind in einem weiteren Schritt die Ressourcen zu annotieren. Aufgrund der Integration der EPK in das ARIS-Framework heben KELLER et al. hervor, dass die Modelle der ARIS-Sichten (insbesondere Funktions-, Datenund Prozesssicht) auf Konsistenz zu prüfen und ggf. anzupassen sind."go Welche Modelle dabei zuerst zu entwickeln sind, ist eine Konstruktionsentscheidung des Modellierers. Unter anderem hängt diese Entscheidung davon ab, welche Modelle bei Beginn der Modellierung bereits existieren.

691

Nach der Modellerstellung ist zu prüfen, ob das Abbruchkriterium erfüllt ist. Ist es erfüllt, so ist die Modellierung beendet. Ist es dagegen nicht erfüllt, so ist der Modellierungsprozess zur Erstellung eines detaillierteren Prozessmodells erneut zu durchlaufen. Das skizzierte prozessorientierte Metamodell der EPK ist in Abbildung 80 dargestellt. Die eigentliche Erstellung der EPK und die Vorbereitungen zur Erstellung der EPK sind als Funktionsverfeinerungen modelliert.

690 691

Vgl. Keller et al. (1992), S. 17 ff. Priemer (1995). S. 251 berücksichtigt diese Abhängigkeiten und unterscheidet vier verschiedene Vorgehensweisen bei der Entwicklung von Prozessmodellen. Während der Top-

Down-Ansatz mit der Erstellung des Prozessmodells beginnt und aus diesem Daten- und

Funktionsmodell ableitet, beschreitet der Bottom-Up-Ansatz den gegensätzlichen Weg. Den Top-Down-Ansatz hält Priemer für besonders geeignet bei Neuentwicklung von Modellen, d. h. wenn keine Funktions- oder Datenmodelle existieren. Bei Existenz dieser Modelle hält er den Bottom-Up-Ansatz dagegen fOr Oberlegen. Weiter unterscheidet Prlemer den Inslde-OutAnsatz, bel dem die Modelle aller Sichten Iterativ entwickelt werden, wobei auf Jeder Iterationsstufe die Konsistenz zwischen den Sichten sicherzustellen ist. Der ReferenzmodellAnsatz verwendet dagegen ein existierendes Prozessmodell und konfiguriert dieses entsprechend den Anforderungen.

Prozessorientiertes Metamodell zur Definition der Handlungsanleitung

Abbildung 80: Prozessorientiertes Metamodell der EPK

279

Literaturverzeichnis Ackoff (1971)

Ackoff, R. L.: Towards a system of systems concepts. In: Management Science 17 (1971) 11, S. 661-671. Adam (1996) Adam, D.: Planung und Entscheidung: Modelle - Ziele - Methoden. Gabler, 4. Auflage, 1996. Adam, Johannwille (1998) Adam, D.; Johannwille, U.: Die Komplexitätsfalle. In: Adam, D. (Hrsg.): Komplexitätsmanagement. Gabler, 1998, S. 5-28. Albert (1978)

Albert, H.: Traktat über rationale Praxis. Mohr, 1978. Albert (1982) Albert, H.: Die Wissenschaft und die Fehlbarkeit der Vernunft. Mohr, 1982. Albert (1991) Albert, H.: Traktat über kritische Vernunft. Mohr, 5. Auflage, 1991. Albert (1994)

Albert, H.: Kritik der reinen Hermeneutik. Mohr, 1994. Aleri (2009)

Aleri: CoralS CCL reference -

version 5.6. Aleri, 2009. Verfügbar unter

http:!fwww.aleri.com!s~esfdefault/filesfassets/pdfs/5.6.5Docs!Coral8CcIReference.pdf. Abruf am 201(}'(l4-14. Alpar et al. (2008) Alpar, P.; Grob, H. L.; Weimann, P.; Winter, R.: Anwendungsorientierte Wirtschaftsinformatik. Vieweg, 5. Auflage, 2008. Anandarajan (2004)

Anandarajan, M.: Business intelligence techniques. Springer, 2004. Andersan (2006)

Anderson, c.: The lang tail - why the future of business is selling less of more. Hyperion, 2006.

Arasu et al. (2006)

Arasu, A.; Babu, S.; Widorn, J.: The CQl continuDU5 query language: semantic foundations and query execution. In: The VLDBJournal15 (2006) 2, 5.121-142.

J. Rommelspacher, Automatisierung von Führungsentscheidungen, DOI 10.1007/978-3-8348-8251-6, © Vieweg + Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2011

Literaturverzeichnis

282

Azevedo et al. (2009)

Azevedo, P.; Brosius, G.; Dehnert, S.; Neumann, B.; Scheerer, B.: Business Intelligence und Reporting mit Microsoft SQl Server 2008. Microsoft Press, 2009. Babcock et al. (2002)

Babcock, B.; Babu, S.; Datar, M.; Motwani, R.j Widorn, J.: Models and issues in data stream systems. In: Popa, L.; Abiteboul, S.; Kolaitis, P. (Hrsg.): Proceedings of 21st

symposium on principles of database systems (PODS 2002), Madison. ACM Press, 2002, S. 1-16. Bamberg et al. (2008) Bamberg, G.; Coenenberg, A. G.; Krapp, M.: Betriebswirtschaftliche Entscheidungslehre. Vahlen, 2008. Banville, Landry (1989) Banville, C.; Landry, M.: Can the field of MIS be disciplined? In: Communication of the ACM 32 (1989) 1, S. 48-60. Barros et al. (2007)

Barras, A.; Decker, G.; Großkopf, A.: Complex events in business processes. In: W. Abramowicz (Hrsg.): Business information systems. Proceeding of 10th international Conference (BIS 2007), Poznan. LNCS 4439, Springer, 2007, S. 29-40. Bartel et al. (2000)

Bartei, W.; Schwarz, S.; Strasser, G.: Der ETL-Prozess des Data Warehousing. In: Jung, R.; Winter, R. (Hrsg.): Data Warehousing Strategie: Erfahrungen, Methoden, Visionen. Springer, 2000, S. 43-60. Bauer, Günzel (2009)

Bauer, A.j Günzel, H.: Data Warehause Systeme - Architektur, Entwicklung, Anwendung. dpunkt, 3. Auflage, 2009. Bea et al. (2004)

Bea, F. X.i Friedl, B.i Schweitzer, M.: Allgemeine Betriebswirtschaftslehre. Band 1: Grundfragen. Fischer, 9. Auflage, 2004. Becker et al. (1995)

Becker, J.i Rosemann, M.i Schütte, R.: Grundsätze ordnungsmäßiger Modellierung. In: Wirtschaftsinformatik 37 (1995) 5, S. 435-445. Becker et al. (2001)

Becker, J.; Knackstedt, R.; Holten, R.; Hansmann, H.; Neumann, 5.: Konstruktion von Methodiken. Arbeitsbericht Nr. 77 des Instituts für Wirtschaftsinformatik, Münster, 2001. Verfügbar unter http://www.wi.unknuenster.delinst/arbber/abn.pdf. Abruf am 2010-04-14.

Uteraturverzeichnis

283

Becker et al. (2002) Becker, J.; Delfmann, P.; Knackstedt, R.; Kuropka, D.: Konfigurative ReferenzmodelIierung. In: Becker, J.; Knackstedt, R. (Hrsg.): Wissensmanagement mit Referenzmodellen. Physika, 2002, s. 25-144. Becker et al. (2003a) Becker, J.; Holten, R.; Knackstedt, R.; Niehaves, B.: Forschungsmethodische Positionierung in der Wirtschaftsinformatik - epistemologische, ontologische und linguistische Leitfragen. Arbeitsbericht Nr. 93 des Instituts für Wirtschaftsinformatik, Münster, 2003. Verfügbar unter http://www.wLuni-muenster.de/ inst/arbber/ab93.pdf, Abruf am 201(}'(l4-14. Becker et al. (2003b) Becker, J.; Delfmann, P.; Falk, T.; Knackstedt, R.: Multiperspektivische ereignisgesteuerte Prozesskette. In: Nüttgens, M.; Rump, F. J. (Hrsg.): Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten. Proceedings des GI-Workshops und Arbeitskreistreftens (EPK 2003), Bamberg. GI-Arbeitskreis Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, 2003, S. 45-60. Becker, Niehaves (2007) Becker, J.; Niehaves, B.: Epistemological perspectives on IS research: a framework for analysing and systematizing epistemological assumptions. In: Information Systems Journal 17 (2007) 2, s. 197-214. Becker, Pfeifter (2007) Becker, J.; Pfeiffer, D.: Konzeptionelle Modellierung - wissenschaftstheoretische Prämissen für eine pluralistische Forschung. In: Lehner, F.; Zelewski, S. (Hrsg.): Wissenschaftstheoretische Fundierung und wissenschaftliche Orientierung der Wirtschaftsinformatik. Gito, 2007, S. 1-17. Becker, Schütte (2004) Becker, J.; Schütte, R.: Handeisinformationssysteme. Redline Wirtschaft, 2. Auflage,2004. Beierle, Kern-Isberner (2006) Beierle, C.; Kern-Isberner, G.: Methoden wissensbasierter Systeme: Grundlagen, Algorithmen, Anwendungen. Vieweg, 3. Auflage, 2006. Benbasat, Weber (1996) Benbasat, I.; Weber, R.: Research commentary: rethinking "diversity" in information systems research. In: Information Systems Research 7 (1996) 4, S. 389-399. Benbasat, Zmud (2003) Benbasat, 1.; Zmud, R.: The identity crisis within the IS discipline: defining and communicating the discipline's core properties. In: MIS Quarterly 27 (2003) 2, 5.183-194.

284

Literaturverzeichnis

Bender (1957) Bender, K.: Die Führungsentscheidung im Betrieb. Poeschel, 1957. Berger, Bernhard-Mehlich (2006) Berger, U.; Bernhard-Mehlich, 1.: Die verhaltenswissenschaftliche Entscheidungstheorie. In: Kieser, A.; Ebers, M. (Hrsg.): Organisationstheorien. Kohlhammer, 6. Auflage, 2006, s. 169-214. Bichler (2006) Bichler, M.: Für Sie gelesen: Design Science in Information Systems Research. In: Wirtschaftsinformatik 4B (2006) 2, s. 133-135. Bitz, Stark (2008) Bitz, M.; Stark, G.: Finanzdienstleistungen. Oldenbourg, 8. Auflage, 2008. Blasehe (1980) Blasehe, 5.: Entscheidung. In: Mittelstraß, J. (Hrsg.): Enzyklopädie Philosophie und Wissenschaftstheorie - Band 1. Bibliographisches Institut, 1980, s. 553-554. Blasum (2006) Blasum, R.: Operational BI. Business Code, 2006. Verfügbar unter http://www.business-code.de/cms/uploads/media/BCD_Operational_BI_01.pdf, Abruf am 2010-04-14. Bode (1997) Bode, J.: Der Informationsbegriff in der Betriebswirtschaftslehre. In: Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung 49 (1997) 5, 5.449-468. Böhnlein, Ulbrich-vom Ende (2000) Böhnlein, M.; Ulbrich-vom Ende, A.: Grundlagen des Data Warehousing - ModelIierung und Architektur. Bamberger Beiträge zur Wirtschaftsinformatik Nr. 55, Bamberg, 2000. Borck (2007) Borck, J. R.: A sea ofCEP opportunity. In: InfoWorld 29 (2007) 14,

s. 30-31.

Bouattour et al. (2008) Bouattour, S.; Messaoud, R.; Boussaid, 0.; Abdallah, H.; Feki, J.: A framework for active data warehouses. The 2008 international Arab conference on information technology (ACIT' 2008), Hammamet, 2008. Verfügbar unter http://recherche.univ-lyon2.fr/eric/sites/eric/IMG/pdf/ACIT_OB_VersionFinale.pdf, Abruf am 2010-04-14. Bretzke (1980) Bretzke, W.: Der Problem bezug von Entscheidungsmodellen. Mohr, 1980.

Uteraturverzeichnis

285

Brobst (2004)

Brobst, S. A.: Twelve mistakes to avoid when constructing areal-time data warehouse. In: Schelp, J.; Winter, R. (Hrsg.): Auf dem Weg zur Integration Faetory. Pro-

ceedings der DW2004 - Data Warehousing und EAI, Friedrichshafen. Physica, 2004, S. 153-166. Bruckner, Tjoa (2001)

Bruckner, R. M.; Tjoa, A. M.: Managing time consistency for active data warehouse environments. In: Kambayashi, Y.; Winiwarter, W.; Arikawa, M. (Hrsg.): Data Warehousing and knowledge discovery. Proceedings of the third international conference (DaWaK 2001), München. LNCS 2114, Springer, 2001, S. 254-263. Bucher (2008)

Bucher, T.: Interaktionseffekte zwischen prozessorientierter Organisation und Informationslogistik. In: Dinter, B.; Winter, R. (Hrsg.): Integrierte Informationslogistik. Springer, 2008, S. 107-135. Bucklin et al. (1998)

Bucklin, R. E.; Lehmann, D. R.; Little, J. D.

c.: From decision support to decision au-

tomation: a 2020 vision. In: Marketing Letters 9 (1998) 3, S. 235-246. Bulos (1996)

Bulos, D.: A new dimension. In: Database Programming and Design 9 (1996) 6, S.33-37. Bunge (1977) Bunge, M.: Treatise on basic philosophy. Vol 3. Ontology I: the furniture of the world. Reidel, 1977. Bunge (1979)

Bunge, M.: Treatise on basic philosophy. Vol. 4. Ontology 11: a world of systems. Reidel, 1979. Cammert et al. (2004)

Cammert, M.; Heinz, c.; Krämer, J.; Seeger, B.: Anfrageverarbeitung auf Datenströmen. In: Datenbank-Spektrum 4 (2004) 11, S. 5-13.

Carnap (1960)

Carnap, R.: Einführung in die symbolische Logik: mit besonderer Berücksichtigung ihrer Anwendungen. Springer, 2. Auflage, 1960. Casati, Varzi (2006)

Casati, R.; Varzi, A.: Events. In: Zalta, E. N. (Hrsg.): The Stanford encyclopedia of philosophy (summer 2006 edition). 2006. Chakravarthy, Adaikkalavan (2009)

Chakravarthy, 5.; Adaikkalavan, R.: Provenance and impact of complex event processing (CEP): a retrospeetive view. In: it -Information Technology 51 (2009) 5, S.243-249.

286

Literaturverzeichnis

Chakravarthy, Mishra (1994) Chakravarthy, S.; Mishra, D.: Snoop: an expressive event specification language for active databases. In: Data & Knowledge Engineering 14 (1994) 1, S. 1-26. Chamoni, Gluchowski (2006) Chamoni, P.; Gluchowski, P.: Analytische Informationssysteme - Einordnung und Überblick. In: Chamoni, P.; Gluchowski, P. (Hrsg.): Analytische Informationssysterne. Springer, 3. Auflage, 2006, S. 3-22. Chamoni et al. (2004) Chamoni, P.; Gluchowski, P.; Philippi, J.; Schulze, K.: Empirische Bestandsaufnahme zum Einsatz von Business Intelligence. Business Intelligence Maturity Modell (biMM). In: Chamoni, P.; Deiters, W.; Granau, N.; Kutsche, R.; Loos, P.; MüllerMerbach, P.; Rieger, B.; Sandkuhl, K. (Hrsg.): Proceedings der Multikonferenz Wirtschaftsinformatik (MKWI 2004) - Band 2, Essen. Akademische Verlagsgesellschaft, 2004, S.111-124. Chamoni, Gluchowski (2004) Chamoni, P.; Gluchowski, P.: Integrationstrends bei Business-Intelligence-Systemen.ln: Wirtschaftsinformatik46 (2004) 2, S.119-128. Chandy(2oo5) Chandy, K. M.: Event-driven applications: where they apply and how there are built. Gartner application integration and web services summit, Orlando, 2005. Verfügbar unter http://haps.polsl.pl/images/9/98/Gartner05.pdf, Abruf am 2008-09-06. Chandy (2006) Chandy, K. M.: Event-driven applications: costs, benefits and design approaches. Gartner application integration and web services summit, San Diego, 2006. Verfügbar unter http://haps.polsl.pl/images/d/d1/Gartner_20060620.pdf, Abruf am 2008-09-06. Chandy, Olson (2008) Chandy, K. M.; Olson, M.: Federated event systems: The event web. 2008. Verfügbar unter http://complexevents.com/wp-contentjuploads/2008/05/chandyebi~v4.pdf, Abruf am 2010-04-15. Chen (1976) Chen, P. P.: The entity-relationship model-toward a unified view of data. In: ACM Transactions on Database Systems 1 (1976) 1, S. 9-36. Codd et al. (1993) Codd, E. F.; Codd, S. B.; Salley, C. T.: Providing OLAP (on-line analytical processing) to user-analysts: an IT mandate. E.F. Codd & Associates, 1993.

Uteraturverzeichnis

287

Cognos (2009)

Cognos: Business event management. Event and process-enabled business intelligence. 2009. Verfügbar unter http://download.boulder.ibm.com/ibmdl/pub/ software/data/sw-library/cognos/pdfs/whitepapers/wp_business_evenCmgmt.pdf, Abruf am 201G-04-15. Cyert, March (1963)

Cyert, R. M.; March, J. G.: A behavioral theory of the firm. Prentice-Hall, 1963. D'Aveni, Gunther (1994)

D'Aveni, R. A.; Gunther, R. E.: Hypercompetition: managing the dynamics of strategie maneuvering. Free Press, 1994. De Moliere (1984)

De Moli~re, F.: Prinzipien des Modellentwurfs - Eine modelltheoretische und gestaltungsorientierte Betrachtung. Dissertation an der Technischen Universität Darmstadt, 1984. Decker et al. (2007)

Decker, G.; Grosskopf, A.; Barros, A.: A graphical notation for modeling complex events in business processes. In: IEEE Computer Society (Hrsg.): Proceedings of the 11th international conference on enterprise distributed object computing conference (EDOC 2007), Annapolis. IEEE Computer Society, 2007, S. 27-36. Delfmann (2006)

Delfmann, P.: Adaptive Referenzmodellierung. Logos, 2006. Dinkelbach, Kleine (1996)

Dinkelbach, W.; Kleine, A.: Elemente einer betriebswirtschaftlichen Entscheidungslehre. Springer, 1996. Dinter, Bucher (2006)

Dinter, B.; Bucher, T.: Business performance management. In: Chamoni, P.; Gluchowski, P. (Hrsg.): Analytische Informationssysteme. Springer, 3. Auflage, 2006, S. 23-50. Dittmar, Schulze (2006)

Dittmar, C.; Schulze, K.: Der Reifegrad von Business-Intelligence-Lösungen: Seine Stärken kennen lernen. In: BI-Spektrum 1 (2006) 1, S. 27-31. Dittrich et al. (1995)

Dittrich, K. R.; Gatziu, S.; Geppert, A.: The active database management system manifesto: A rulebase of ADBMS features. In: Sellis, T. (Hrsg.): Rules in database systems. Proceedings of second international workshop (RIDS '95), Glyfada. LNCS

985, Springer, 1995, S. 3-20. Dittrich, Gatziu (2000) Dittrich, K. R.; Gatziu, S.: Aktive Datenbanksysteme. dpunkt, 2. Auflage, 2000.

Literaturverzeichnis

288

Dörner (1980) Dörner, D.: On the difficulties people have in dealing with complexity. In: Simulation & Gaming 11 (1980) 1, S. 87-106. Dörner (2003) Dörner, 0.: Die Logik des Mißlingens. Rowohlt, 2003. Dörner et al. (1999) Dörner, D.; Schaub, H.; Strohschneider, S.: Komplexes Problemlösen - Königsweg der Theoretischen Psychologie? In: Psychologische Rundschau 50 (1999) 4, S.198-205. Dörner, Schaub (1995) Dörner, 0.; Schaub, H.: Handeln in Unbestimmtheit und Komplexität. In: Organisationsentwicklung 14 (1995) 3, S. 34-47. Drepper (2003) Drepper, T.: Organisationen der Gesellschaft - Gesellschaft und Organisation in

der Systemtheorie Niklas Luhmanns. Westdeutscher Verla~ 2003. Dresbach (1999) Dresbach, S.: Epistemologische Überlegungen zu Modellen in der Wirtschaftsinformatik. In: Becker, J.; König, W.; Schütte, R.; Wendt, 0.; Zelewski, S. (Hrsg.): Wirtschaftsinformatik und Wissenschaftstheorie. Gabler, 1999, S. 71-94. Drucker (1954) Drucker, P. F.: The practice of management. Harper, 1954. Dutta et al. (1998) Dutta, S.; Wierenga, B.; Dalebout, A.: Designing management support systems using an integrative perspective. In: Communication of the ACM 40 (1998) 6, S.70-79. Eckerson (2004) Eckerson, W.: Gauge your data warehouse maturity. In: DM Review 14 (2004) 11, S.34-37. Eckert, Bry (2009) Eckert, M.; Bry, F.: Complex event processing (CEP). In: Informatik Spektrum 32 (2009) 2, S. 163-167. Elmasri, Navathe (1994) Elmasri, R.; Navathe, S.: Fundamentals of database systems. Pearson, 2. Auflage, 1994. Endl (2004) Endl, R.: Regelbasierte Entwicklung betrieblicher Informationssysteme. Eul, 2004.

Uteraturverzeichnis

289

Endl et al. (1998)

Endl, R.; Knolmayer, G.; Pfahrer, M.: Modeling processes and workflows by business rules. Proceedings of the 1st European workshop on workflow and process management, Zürich, 1998. Verfügbar unter http://citeseerx.ist.psu.edujviewdoc/download?doi=10.1.1.46.5OO4&rep=rep1&type=pdf Abruf am 201Q-CJ4.15. Essler (1980) Essler, W.: Metasprache. In: Speck, J. (Hrsg.): Handbuch wissenschaftstheoretischer Begriffe - Band 2. Vandenhoeck & Ruprecht, 1980, S. 428-429. Eversmann (2003)

Eversmann, L.: Wirtschaftsinformatik der "langen Frist". Deutscher UniversitätsVerlag, 2003. Felden (2005)

Felden, c.: Integration von Subsystemen in einem Active Data Warehouse. In: Ferstl, O. K.; Sinz, E.; Eckert, S.; Isselhorst, T. (Hrsg.): eEconomy, eGovernment, eSociety. Proceedings der Wirtschaftsinformatik 2005, Bamberg. Physika, 2005,

S. 1385-1404. Felden (2006)

Felden, C.: Personalisierung der Informationsversorgung im Unternehmen. Deutscher Universitäts-Verlag. 2006. Ferstl, Sinz (2006) Ferstl, O. K.; Sinz, E.: Grundlagen der Wirtschaftsinformatik. Oldenbourg, 5. Auflage,2006. Feyerabend (1976) Feyerabend, P.: Wider den Methodenzwang. Suhrkamp, 1976. Floyd, Klischewski (1998)

Floyd, C.; Klischewski, R.: Modellierung - ein Handgriff zur Wirklichkeit. In: Pohl, K.; Schürr, A.; Vossen, G. (Hrsg.): Proceedings des GI-Workshops Modellierung 1998,

Münster. CEUR Workshop Proceedings, 1998. Follesdal (1980) Follesdal, 0.: Semantik. In: Speck, J. (Hrsg.): Handbuch wissenschaftstheoretischer Begriffe - Band 3. Vandenhoeck & Ruprecht, 1980, S. 568-579. Frank (2001)

Frank, U.: Framework. In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. Springer, 4. Auflage, 2001, S. 203-204. Frank (2002)

Frank, U.: Forschung in der Wirtschaftsinformatik: Profilierung durch Kontemplation - Ein Plädoyer für den Elfenbeinturm. Arbeitsbericht Nr. 30 des Instituts für Wirtschaftsinformatik, Universität Koblenz-Landau, 2002.

290

Literaturverzeichnis

Frank (2003)

Frank, U.: Einige Gründe für eine Wiederbelebung der Wissenschaftstheorie. In: DBW - Die Betriebswirtschaft 63 (2003) 3, S. 278-292. Frank (2006)

Frank, U.: Towards a pluralistic conception of research methods in information systems research. leB Research Reports No. 7, Universität Duisburg-Essen, 2006. Frank (2007)

Frank, U.: Ein Vorschlag zur Konfiguration von Forschungsmethoden in der Wirtschaftsinformatik. In: Lehner, F.; Zelewski, S. (Hrsg.): Wissenschaftstheoretische Fundierung und wissenschaftliche Orientierung der Wirtschaftsinformatik. Gito, 2007, S. 155-184. Frank, van loak (2003)

Frank, U.; van laak, B.: Anforderungen an Sprachen zur Modellierung von Geschäftsprozessen. Arbeitsbericht Nr. 34 des Instituts für Wirtschaftsinformatik, Universität Koblenz Landau, 2003. Füser (2001)

Füser, K.: Intelligentes Scoring und Rating: Moderne Verfahren zur Kreditwürdigkeitsprüfung. Gabler, 2ool. Fuhrmann (1995) Fuhrmann, A.: Semantik, intensionale. In: Mittelstraß, J. (Hrsg.): Enzyklopädie Philosophie und Wissenschaftstheorie - Band 3. Metzler, 1995, S. 775-776. Funke (1999)

Funke, J.: Komplexes Problem lösen - ein Blick zurück und ein Blick nach vorne. In: Psychologische Rundschau 50 (1999) 4, S. 194-197. Funke (2006) Funke, J.: Komplexes Problem lösen. In: Funke, J. (Hrsg.): Denken und Problemlösen. Hogrefe, 2006, S. 345-446. Gabriel et al. (2000)

Gabriel, R.; Chamoni, P.; Gluchowski, P.: Data Warehouse und OLAP - Analyseorientierte Informationssysteme für das Management. In: Schmalen bachs Zeitschrift für betriebswirtschaftliche Forschung 52 (2000) 2, S. 74-93. Gabriel, Gluchowski (1998)

Gabriel, R.; Gluchowski, P.: Grafische Notationen für die semantische ModelIierung multidimensionaler Datenstrukturen in Management Support Systemen. In: Wirtschaftsinformatik 40 (1998) 6, S. 493-502. Galliers (1995)

Galliers, R. D.: A manifesto for information management research. In: British Journal of Management 6 (1995) 6 (Speciallssue), S. 45-52.

Uteraturverzeichnis

291

Galliers, Land (1987)

Galliers, R. D.; Land, F. F.: Choosing appropriate information systems research methodologies. In: Communications of the ACM 30 (1987) 11, s. 900-902. Ganslandt (1980)

Ganslandt, H. R.: Entscheidungstheorie. In: Mittelstraß, J. (Hrsg.): Enzyklopädie Philosophie und Wissenschaftstheorie - Band 1. Bibliographisches Institut, 1980, 5.554-556. Gatziu, Dittrich (1994)

Gatziu, S.; Dittrich, K.: Events in an active object-oriented database system. In: Paton, N.; Williams, M. (Hrsg.): Rules in Database Systems. Springer, 1994, s. 23-39. Gelhoet, Rieger (2005)

Gelhoet, M.; Rieger, B.: Mehrstufige Entscheidungsunterstützung durch Active Data Warehouses. In: Ferstl, O. K.; sinz, E. J.; Eckert, 5.; Isselhorst, T. (Hrsg.):

eEconomy, eGovernment, eSociety, Proceedings der Wirtschaftsinformatik 2005, Bamberg. Physika, 2005, 5.1405-1419. Gemünden (1983)

Gemünden, H.: "Echte Führungsentscheidungen " - empirische Beobachtungen zu Gutenbergs Idealtypologie. In: DBW - Die Betriebswirtschaft 43 (1983) 1, s. 49-64. Gerke (2003) Gerke, W.: Ethik in der Kapitalmarktkommunikation. In: Scherer, A. G.; Hütter, G.;

Maßmann, L. (Hrsg.): Ethik für den Kapitalmarkt? Orientierungen zwischen Regulierung und Laissez-faire. Rainer Hampp, 2003, s. 89-106. Gigerenzer, Goldstein (1996)

Gigerenzer, G.; Goldstein, D. G.: Reasoning the fast and frugal way: models of bounded rationality. In: Psychological Review 103 (1996) 4, s. 650-669. Gluchowski (2001)

Gluchowski, P.: Business Intelligence - Konzepte, Technologien und Einsatzbereiche. In: HMD- Praxis der Wirtschaftsinformatik (2001) 222, s. 5-15. Gluchowski et al. (2008) Gluchowski, P.; Gabriel, R.; Dittmar, C.: Management Support Systeme und Busi-

ness Intelligence. Springer, 2. Auflage, 2008. Gluchowski et al. (2009)

Gluchowski, P.; Kemper, H.; Seufert, A.: Innovative Prozess-Steuerung. In: BISpektrum 1 (2009) 4, s. s. 8-12. Gluchowski, Kemper (2006)

Gluchowski, P.; Kemper, H.: Quo Vadis Business Intelligence? In: BI-Spektrum 1 (2006) 1, s. 12-19.

292

Literaturverzeichnis

Goeken (2003) Goeken, M.: Die Wirtschaftsinformatik als anwendungsorientierte Wissenschaft. Fachbericht Nr. 01/03 des Instituts für Wirtschaftsinformatik, Philipps-Universität Marburg, 2003. Goeken (2006) Goeken, M.: Entwicklung von Data-Warehouse-Systemen. Deutscher UniversitätsVerlag, 2006. Goeken et al. (2006)

Goeken, M.; Burmester, L.i Rommelspacher, J.: Business Intelligence im HochschulControlling. In: WI5U - Das Wirtschaftsstudium 35 (2006) 11, 5. 1408-1414 und 5.1447. Golab, Özsu (2D03) Golab, L.; Özsu, M. T.: Issues in data stream management. In: ACM Sigmod Record 32 (2003) 2, 5. 5-14. GolfarelIi et al. (2D04)

GolfarelIi, M.; Rizzi, S.; Cella, 1.: Beyond data warehousing: what's next in business intelligence? In: Song, 1.; Davis, K. C. (Hrsg.): Proceedings of the seventh international workshop on data warehousing and OLAP (DOLAP 20D4), Washington. ACM, 2D04, 5. 1-6. Goorhuis (1994) Goorhuis, H.: Konstruktivistische Modellbildung in der Informatik. Dissertation an

der Universität Zürich, 1994. Grief, 5eidlmeier (2D05) Grief, J.; Seidimeier, H.: Modellierung von Flexibilität mit Ereignisgesteuerten Prozessketten (EPK).ln: Nüttgens, M.; Rump, F. (Hrsg.): Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten. Proceedings des GI-Workshops und Arbeitskreistreffens (EPK 2005), Heidelberg. GI-Arbeitskreis Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, 2005, S. 137-155. Grob, Coners (2008) Grob, H.; Coners, A.: Regelbasierte Steuerung von Geschäftsprozessen - Konzeption eines Ansatzes auf Basis von Process Mining. In: Wirtschaftsinformatik 50 (2008) 4, S. 268-281. Grochla (1969) Grochla, E.: Modelle als Instrumente der Unternehmensführung. In: Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung 21 (1969), 5.382-398. Gruber (1993) Gruber, T. R.: A translation approach to portable ontology specifications. In: Knowledge Acquisition 5 (1993) 2, 5. 199-220.

Uteraturverzeichnis

293

Gutenberg (1983)

Gutenberg. E.: Grundlagen der Betriebswirtschaft. Erster Band: Die Produktion. Springer, 1983. Habermas (1971)

Habermas, J.: Vorbereitende Bemerkungen zu einer Theorie der kommunikativen Kompetenz. In: Habermas, J.; Luhmann, N. (Hrsg.): Theorie der Gesellschaft oder Sozialtechnologie. Was leistet die Systemforschung. Suhrkamp, 1971, S. 101-141. Hackathorn (2002)

Hackathorn, R.: Current practices in active data warehousing. Bolder Technology Inc., 2002. Verfügbar unter http://www.bolder.com/pubs/NCR200211-ADW.pdf. Abruf am 2008-09-06. Häuslein (2004) Häuslein, A.: Systemanalyse. VDE, 2004. Harinath et al. (2009)

Harinath, S.; Ca roll, M.; Meenakshisundaram, S.; Zare, R.; Lee, D. G.: Professional Microsoft SQL Server Analysis Services 2008 with MDX. WHey, 2009. Harvey (2005) Harvey, H.: Languages and metamodels for modelling frameworks. In: Zerger, A.;

Argent, R. (Hrsg.): Proceedings of international congress on modelling and simulation (MODSIM 2005). Modelling and simulation society of Australia and New Zealand, 2005, S. 669-675. Hay, Healy (2000)

Hay, D.; Healy, K.: Defining business rules - what are they really? The Business Rules Group, 2000. Verfügbar unter http://www.businessrulesgroup.org/firsU,aper/BRG-whatisBR_3ed.pdf, Abruf am 2010-04-15. Hayes-Roth (1985) Hayes-Roth, F.: Rule-based systems. In: Communications of the ACM 28 (1985) 9, S. 921- 932. Heinen (1971)

Heinen, E.: Grundlagen betriebswirtschaftlicher Entscheidungen. Gabler, 2. Auflage,1971. Heinen (1991)

Heinen, E.: Industriebetriebslehre als entscheidungsorientierte Unternehmensführung. In: Heinen, E.; Dietel, B. (Hrsg.): Industriebetriebslehre - Entscheidungen im Industriebetrieb. Gabler, 9. Auflage, 1991, S. 1-71. Heinrich et al. (2007)

Heinrich, L. J.; Heinzl, A.; Roithmayr, F.: Wirtschaftsinformatik. Oldenbourg, 3. Auflage, 2007.

Literaturverzeichnis

294

Heinz, Greiner (2009) Heinz, C.i Greiner, T.: Business Activity Monitoring. In: HMD - Praxis der Wirtschaftsinformatik (2009) 268, S. 82-89. Herbst (1995)

Herbst, H.: A meta-model for business rules in systems analysis. In: livari, J.; Lyytinen, K.; Rossi, M. (Hrsg.): Advanced information systems engineering. Proceedings of the 7th international conference (CAiSE 195), Jyväskylä. LNCS 932, Springer, 1995,5.186-199.

Herbst (1997)

Herbst, H.: Business rule oriented conceptual modeling. Physica, 1997. Herbst, Knolmayer (1995)

Herbst, H.; Knolmayer, G.: Ansätze zur Klassifikation von Geschäftsregeln. In: Wirtschaftsinformatik 37 (1995) 2, 5.149-159. Herbst, Myrach (1996)

Herbst, H.; Myrach, T.: A repository system for business rules. In: Meersmann, R.; Mark, L. (Hrsg.): Proceedings cf the si>
Hesse, W.: Ontologies in the software engineering process. In: Lenz, R.; Hasenkamp, U.; Hasselbring, W.; Reichert, M. (Hrsg.): Proceedings des EAI-Workshops 2005, Marburg. Gito, 2005, S. 3-15. Hesse et al. (1994)

Hesse, W.; Barkow, G.; von Braun, H.; Kittlaus, H.; Scheschonk, G.: Terminologie in der Softwaretechnik.ln: Informatk Spektrum 17 (1994) 1, S. 39-47. Hevner et al. (2004)

Hevner, A. R.; March, S. T.; Park, J.; Ram, 5.: Design science in information system research. In: MIS Quarterly 28 (2004) 1, S. 75-105. Heym, Österle (1992)

Heym, M.; Österle, H.: A semantic data model for methodology engineering. Arbeitsbericht IM2000/CCRIM/20 des Instituts für Wirtschaftsinformatik, St. Gallen, 1992. Holtjann (2007)

Hoffjann, 0.: Journalismus und Public Relations: Ein Theorieentwurf der Intersystembeziehungen in sozialen Konflikten. VS Verlag, 2. Auflage, 2007. Hoheisel (1999)

Hoheisel, H.: Berücksichtigung temporaler Konstrukte bei der GeschäftsprozessModellierung. Swordies-Bericht Nr. 22, Universität Bern, 1999.

Uteraturverzeichnis

295

Hoheisel (2000)

Hoheisel, H.: Temporale Geschäftsprozessmodellierung. Deutscher UniversitätsVerlag, 2000. Holten (1999)

Holten, R.: Entwicklung von Führungsinformationssystemen. Deutscher Universitäts-Verlag, 1999. Holten (2000)

Holten,

R.:

Entwicklung einer Modellierungstechnik für

Data-Warehouse-

Fachkonzepte. In: Schmidt, H. (Hrsg.): Modellierung betrieblicher Informationssysteme. Proceedings der MoblS 2000, Siegen. Rundbrief der GI-Fachgruppe, 2000, S.3-21. Holten (2001a)

Holten, R.: Konstruktion domänenspezifischer Modellierungstechniken für die Modellierung von Fachkonzepten. Arbeitsbericht Nr. 78 des Instituts für Wirtschaftsinformatik, Münster, 2001. Holten (2001b)

Holten, R.: Metamodell. In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. Springer, 4. Auflage, 2001b, S. 300-301. Holthuis (1999)

Holthuis, J.: Der Aufbau von Data Warehouse-Systemen: Konzeption - Datenmodellierung - Vorgehen. Deutscher Universitäts-Verlag, 1999. Hyde (2010) Hyde, J.: Oata in flight. In: Communications ofthe ACM 53 (2010) 1, S. 48-52. lOS Scheer AG (2006) lOS Scheer AG: Methode ARIS 7.0. lOS Scheer, 2006. Inmon (2002) Inmon, W.: Building the Oata Warehouse. Wiley, 3. Auflage, 2002. Jablonski et al. (1997) Jablonski, S.; Böhm, M.; Schulze, W.: Workflow-Management. dpunkt, 1997. Jahnke et al. (1996)

Jahnke, B.i Groffmann, H.i Kruppa, 5.: On-line analytical processing. In: Wirtschaftsinformatik 38 (1996) 3, S. 321-324. Jukic et al. (2008) Jukic, N.; Jukic, B.; Malliaris, M.: Online analytical processing (OLAP) for decision support. In: Burstein, F.; Holsapple, C. W. (Hrsg.): Handbook on Oecision Support Systems 1. Springer, 2008, S. 259-276.

Literaturverzeichnis

296 Jung, Winter (2000)

Jung, R.; Winter, R.: Data Warehousing; Nutzungsaspekte, Referenzarchitektur und Vorghensmodell. In: Jung, R.; Winter, R. (Hrsg.): Data Warehousing Strategie: Er-

fahrungen, Methoden, Visionen. Springer, 2000, S. 3-20. Känel (1966)

Känel, W.: Operations Research und betriebswirtschaftliche Entscheidungen. von Decker, 1966. Kamlah, Lorenzen (1996) Kamlah, W.; Lorenzen, P.: Logische Propädeutik. Metzler, 3. Auflage, 1996. Kaplan, Norton (1992)

Kaplan, R. S.; Norton, D. P.: The balanced scorecard - measures that drive performance.ln: Harvard Business Review 83 (1992) 7, S. 71-79. Karagiannis, Kühn (2002)

Karagiannis, 0.; Kühn, H.: Metamodelling platforms. In: Bauknecht, K.; Min Tjoa, A.; Quirchmayer, G. (Hrsg.): E-commerce and web technologies. Proceedings of the third international conference, Aix-en-Provence. LNCS 2455, Springer, 2002, S.182-196. Karakasidis et al. (2005)

Karakasidis, A.; Vassiliadis, P.; Pitoura, E.: ETL queues for active data warehousing. Proceedings of the 2nd international workshop on information quality in information systems, Baltimore. ACM, 2005, S. 28-39. Keller et al. (1992)

Keller, G.; Nüttgens, M.; Scheer, A.: Semantische Prozessmodellierung auf der Grundlage "Ereignisgesteuerter Prozessketten" (EPK). Veröffentlichungen des Instituts für Wirtschaftsinformatik Nr. 82, Universität Saarbrücken, 1992. Kemper et al. (2006)

Kemper, H.; Mehanna, W.; Unger, C.: Business Intelligence - Grundlagen und praktische Anwendungen. Vieweg, 2. Auflage, 2006. Kemper, Baars (2006)

Kemper, H.; Baars, H.: Business Intelligence und Competitive Intelligence. In: HMD - Praxis der Wirtschaftsinformatik (2006) 247, S. 7-20. Kern (1964)

Kern, W.: Operations Research - Eine Einführung in die Optimierungs-Rechnung. Poeschel, 1964. Kimball, Ross (2002)

Kimball, R.; Ross, M.: The data warehouse toolkit: the complete guide to dimensional modeling. Wiley, 2002.

Uteraturverzeichnis

297

Klein, Poesch (2003)

Klein, U.; Poesch, A.: Handeln in Unternehmenskrisen. In: Wirtschaftspsychologie aktuell 10 (2003) 2, S. 64-68. Kobielus (2007)

Kobielus, J.: Complex event processing: still on the radar. In: Network World 24 (2007) 33, S. 42. Kock et al. (2002)

Kock, N.; Gray, P.; Hoving, R.; Klein, H.; Myers, M.; Rockart, J.: IS research relevance revisited: subtle accomplishment, unfulfilled promise, or serial hypocrisy? In: Communications of the AIS (2002) 8, S. 330-346. Kosiol (1961)

Kosiol, E.: Modellanalyse als Grundlage unternehmerischer Entscheidungen. In: Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung 13 (1961), S.318-334. Krallmann et al. (2007)

Krallmann, H.; Schönherr, M.; Trier, M.: Systemanalyse im Unternehmen. Oldenbourg, 5. Auflage, 2007. Kremar (2005)

Krcmar, H.: Informationsmanagement. Springer, 4. Auflage, 2005. Kuhn (1975)

Kuhn, T.: The structure of scientific revolutions. University of Chicago Press, 1975. Larkin, Si mon (1987)

Larkin, J. H.; Si mon, H. A.: Why a diagram is (sometimes) worth ten thousand words.ln: Cognitive Seience 11 (1987) 1, S. 65-100. Laudon, Laudon (2006)

Laudon, K. C.; Laudon, J. P.: Management information systems. Pearson, 9. Auflage,2006. Laux (2007)

Laux, H.: Entscheidungstheorie. Springer, 7. Auflage, 2007. Lehner et al. (1995)

Lehner, F.; Maier, R.; Hildebrand, K.: Wirtschaftsinformatik - theoretische Grundlagen. Hanser, 1995. Lehner, Meier (1994)

Lehner, F.; Meier, R.: Information in Betriebswirtschaftslehre, Informatik und Wirtschaftsinformatik. Forschungsbericht des Lehrstuhls für Wirtschaftsinformatik und Informationsmanagement, Universität Koblenz Landau, 1994.

298

Literaturverzeichnis

Leinfellner (1980)

Leinfellner, W.: Entscheidungstheorie. In: Speck, J. (Hrsg.): Handbuch wissenschaftstheoretischer Begriffe - Band 3. Vandenhoeck & Ruprecht, 1980. Lorenz (1980)

Lorenz, K.: Ereignis. In: Mittelstraß, J. (Hrsg.): Enzyklopädie Philosophie und Wissenschaftstheorie - Band 1. Bibliographisches Institut, 1980, S. 568. Lorenz (1995) Lorenz, K.: Semantik. In: Mittelstraß, J. (Hrsg.): Enzyklopädie Philosophie und Wissenschaftstheorie - Band 3. Metzler, 1995, S. 768-775. Lorenz (1996a) Lorenz, K.: Wahrheitstheorien. In: Mittelstraß, J. (Hrsg.): Enzyklopädie Philosophie

und Wissenschaftstheorie - Band 4. Metzler, 1996, S. 595-600. Lorenz (1996b) Lorenz, K.: Sprache. In: Mittelstraß, J. (Hrsg.): Enzyklopädie Philosophie und Wis-

senschaftstheorie - Band 4. Metzler, 1996, S. 49-53. Lorenz (1996c) Lorenz, K.: Syntax. In: Mittelstraß, J. (Hrsg.): Enzyklopädie Philosophie und Wissenschaftstheorie - Band 4. Metzler, 1996, 5.176-178. Lorenzen (1973)

Lorenzen, P.: Semantisch normierte Orthosprachen. In: Kambartei, F.j Mittelstraß, J. (Hrsg.): Zum normativen Fundament der Wissenschaften. Athenäum, 1973, 5.231-249. Lorenzen (1978)

lorenzen, P.: Konstruktive Wissenschaftstheorie und Praxis. In: Steinmann, H. (Hrsg.): Betriebswirtschaftslehre als normative Handlungswissenschaft. Zur Bedeutung der Konstruktiven Wissenschaftstheorie für die Betriebswirtschaftlehre. Gabler, 1978, S. 13-31. Lorenzen (1987)

Lorenzen,

P.:

Lehrbuch

der

konstruktiven

Wissenschaftstheorie.

BI-

Wissenschaftsverlag, 1987. Luckham (2002a)

Luckham, D.: The power of events. Addison-Wesley, 2002. Luckham (2002b)

Luckham, D.: Draft paper achieving instant insight into the real-time electronic enterprise. Standford University, 2002. Verfügbar unter http://complexevents.com/stanford/cep/instantinsightpaper.pdf, Abruf am 2010-04-15.

Uteraturverzeichnis

299

Luckham (2006) Luckham, D.: What's the difference between ESP and CEP? 2006. Verfügbar unter http://complexevents.com/?p=103, Abruf am 2006-08-01. Luckham (2007) Luckham, D.: SOA, EDA, BPM and CEP are all complementary. 2007. Verfügbar unter http://complexevents.com/wp-contentjuploads/2007/07/Soa_EDA_Part2.pdf, Abruf am 201G-OS-OS. Luckham (2008) Luckham, D.: Abrief overview of the concepts of CEP. 2008. Verfügbar unter http://oomplexevents.oom/wp-<xlntent/upioads/2OO8lO7/OYerview-<>f-oonceplS-
300

Literaturverzeichnis

March, Si mon (1958) March, J. G.; Siman, H. A.: Organizations. Wiley, 1958. March, Smith (1995) March, S. T.; Smith, G. F.: Design and natural science research on information technology. In: Decision Support Systems 15 (1995) 4, S. 251-266. Mattos (1989) Mattos, N. M.: Abstraction concepts: the basis for data and knowledge modeling. In: Battini, C. (Hrsg.): Entity-relationship approach: a bridge to the user. Proceedings of the 7th international conference on the entity-relationship approach (ER 1988), Rom. North-Holland, 1989, S. 473-492. Mattos, Michels (1990) Mattos, N. M.; Michels, M.: Modeling with KRISYS: the design process of OB applications reviewed. In: Lochovsky, F. H. (Hrsg.): Entity-Relationship approach to database design and querying. Proceedings of the 8th international conference on the entity-relationship approach (ER 1989), Toronto. North-Holland, 1990, S.159-173. Melchert, Winter (2004) Melchert, F.; Winter, R.: The enabling role of information technology for business performance management. In: Meredith, B.i Shanks, G.i Arnott, D.i Carlsson, S. (Hrsg.): Decision support in an uncertain and complex world. Monash Universitv, 2004, S. 535-546. Mertens (1994) Mertens, P.: Neuere Entwicklungen des Mensch-Computer-Dialoges in Berichtsund Beratungssystemen. In: Zeitschrift für Betriebswirtschaft 64 (1994) 1, S. 35-57. Mertens (1995) Mertens, P.: Wirtschaftsinformatik - Von den Moden zum Trend. In: König, W. (Hrsg.): Wettbewerbsfähigkeit, Innovation, Wirtschaftlichkeit, Proceedings der Wirtschaftsinformatik 1995, Frankfurt a.M .. Physika, 1995, S. 25-64. Mertens (2001) Mertens, P.: Management-Informationssystem, aktives (AMIS). In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. Springer, 4. Auflage, 2001, S. 289-290. Mertens (2002) Mertens, P.: Business Intelligence - Ein Überblick. In: Information Management & Consulting 17 (2002) Sonderheft, S. 65-73. Mertens (2005) Mertens, P.: Integrierte Informationsverarbeitung 1: Operative Systeme in der Industrie. Gabler, 15. Auflage, Nachdruck, 2005.

Uteraturverzeichnis

301

Mertens (2006) Mertens, P.: Moden und Nachhaltigkeit in der Wirtschaftsinformatik. In: HMD Praxis der Wirtschaftsinformatik (2006) 250, 5.109-118. Mertens et al. (2005) Mertens, P.; Bodendorf, F.; König, W.; Picot, A.; Schumann, M.; Hess, T.: Grundzüge der Wirtschaftsinformatik. Springer, 9. Auflage, 2005. Mertens, Meier (2009) Mertens, P.; Meier, M. C.: Integrierte Informationsverarbeitung 2: Planung - und Kontrollsysteme in der Industrie. Gabler, 10. Auflage, 2009. Michelson (2006) Michelson, B. M.: Event driven architecture overview. Patricia Seybold Group, 2006. Verfügbar unter http://soa.omg.orgfUploaded%20Docs/EDA/bda2-2-ll6cc.pdf, Abruf am 2008-02-02. MiIi, Manheim (1989) MiIi, F.j Manheim, M. l.: Introduction to the DSS minitrack on active DSS and symbiotic systems. In: IEEE Computer Society (Hrsg.): Proceedings of the 22nd Hawaii international conference on system science (HICSS 1989). IEEE Computer Society Press, 1989, 5. 24-32. Mittelstraß (1984) Mittelstraß, J.: Münchhausen-Trilemma. In: Mittelstraß, J. (Hrsg.): Enzyklopädie Philosophie und Wissenschaftstheorie - Band 2. Bibliographisches Institut, 1984, 5.945-946. Mohania et al. (2005) Mohania, M.; Swamini, D.; Gupta, S. K.; Bhowmick, S.; Dillon, T.: Event composition and detection in data stream management systems. In: Andersen, K.; Dobenhan, J.; Wagner, R. (Hrsg.): Database and expert systems applications. Proceedings of the 16th international conference, Koppenhagen. LNC5 3588, Springer, 2005, 5.756-765. Mucksch (2006) Mucksch, H.: Das Data Warehouse als Datenbasis analytischer Informationssysteme. In: Chamoni, P.; Gluchowski, P. (Hrsg.): Analytische Informationssysteme. Springer, 3. Auflage, 2006. Müller-Böling, Schreiterer (1999) Müller-Böling.. D.; Schreiterer, U.: Hochschulmanagement durch Zielvereinbarungen-Perspektiven eines neuen Steuerungsmodells. In: Fedrowitz, J.; Krasny, E.; Ziegele, F. {Hrsg.}: Hochschulen und Zielvereinbarungen - neue Perspektiven der Autonomie. Bertelsmann-Stiftung, 1999, S. 9-25.

Literaturverzeichnis

302 Mylopoulos (1998)

Mylopoulos, J.: Information modeling in the time of the revolution. In: Information Systems 23 (1998) 3-4, 5.127-155. Nguyen et al. (2oo5a)

Nguyen, T. M.; Schiefer, J.; Tjoa, A. M.: ZELESSA: sensing.. analysing and acting on continous event streams. In: Kotsis, G.; Taniar, D.; Bressan, S.; Ibrahim, I. K.; Mokhtar, S. (Hrsg.): Proceedings of the seventh international conference on information integration and web based applications & services (iiWAS 2005), Kuala Lumpur. Austrian Computer Society, 2005, 5.1101-1112. Nguyen et al. (2oo5b)

Nguyen, T.; Schiefer, J.; Tjoa, A.: Sense & response service architecture (SARESA): an approach towards a real-time business intelligence solution and its use for a fraud deteelion application. In: Song, 1.; Trujillo, J. (Hrsg.): Proceedings of the 8th international workshop on data warehousing and OLAP (DOLAP 2005), Bremen. ACM, 2005, S. 77-86. Nguyen et al. (2oo7a) Nguyen, T. M.; Schiefer, J.; Tjoa, A. M.: ZELESSA: an enabler for real-time sensing,

analysing and acting on continuous event streams. In: international Journal of Business Intelligence and Data Mining 2 (2007) 1, 5.105-141. Nguyen et al. (2oo7b)

Nguyen, T. M.; Tjoa, A. M.; Nemec, J.; Windisch, M.: An approach towards an event-fed solution for slowly changing dimensions in data warehouse with a detailed case study. In: Data & Knowledge Engineering 63 (2007) 1, S. 26-43. Oesterreich (1982)

Oesterreich, R.: Der Begriff "Effizienz-Divergenz" als theoretischer Zugang zu Problemen der Planung des Handeins und seiner Motivation. In: Hacker, W.; Volpert, W.; Cranach, M. (Hrsg.): Kognitive und motivationale Aspekte der Handlung. Huber, 1982, 5.110-122. Ortner (1997)

Ortner, E.: Methodenneutraler Fachentwurf: Zu den Grundlagen einer anwendungsorientierten Informatik. Teubner, 1997. Ortner (1998)

Ortner, E.: Normsprachliche Entwicklung von Informationssystemen. In: Pohl, K.; Schürr, A.; Vossen, G. (Hrsg.): Proceedings des GI-Workshops Modellierung 1998, Münster. CEUR Workshop Proceedings, 1998. Ortner (2002)

Ortner, E.: Sprachingenieurwesen Empfehlung zur inhaltlichen Weiterentwicklung der (Wirtschafts-)Informatik. In: Informatik Spektrum 25 (2002) 1, S. 39-51.

Uteraturverzeichnis

303

Ortner et al. (1990)

Ortner, E.; Rössner, J.; Söllner, B.: Entwicklung und Verwaltung standardisierter Datenelemente. In: Informatik Spektrum 13 (1990) 1, S. 17-30. Ortner, Schneider (2008)

Ortner, E.; Schneider, T.: Temporal and modallogic based event languages for the development of reactive application systems. First international workshop on complex event processing for the future internet, 2008. Verfügbar unter http://icep-fis08.f,i.de/papers/iCEP08_S.pdf,Abruf am 2010-04-16. Osterloh, Grand (1994) Osterloh, M.; Grand, S.: Modelling oder Mapping? Von Rede- und Schweigein-

strumenten in der betriebswirtschaftlichen Theoriebildung. In: Die Unternehmung 48 (1994) 4, S. 277-294. Osterloh, Grand (1995)

Osterloh, M.; Grand, S.: Modellbildung versus Frameworking: Die Positionen von Williamson und Porter. In: Wächter, H. (Hrsg.): Selbstverständnis betriebswirtschaftlicher Forschung und Lehre. Gabler, 1995, S. 3-26. Patig (2007)

Patig.. S.: Eine Theorie der Evolution von Modellierungssprachen. In: Lehner, F.; Zelewski, S. (Hrsg.): Wissenschaftstheoretische Fundierung und wissenschaftliche Orientierung der Wirtschaftsinformatik. Gito, 2007, S. 18-33. Paton, Dia, (1999) Paton, N. W.; Dia" 0.: Active database systems. In: ACM Computing Surveys 31 (1999) 1, S. 63-103. Pendse, Creeth (0.J.)

Pendse, N.; Creeth, R.: What is OLAP - an analysis of what the often misused OLAP term is supposed to mean. O.J. Verfügbar unter http://www.olapreport.com/fasmi.htm.Abrufam 201Q..04-16. Petöfi (1980)

Petöfi, J.: Sprache. In: Speck, J. (Hrsg.): Handbuch wissenschaftstheoretischer Begriffe - Band 3. Vandenhoeck & Ruprecht, 1980, S. 599-600. Plaichner (2008)

Plaichner, C.: Complex Event Processing: Betrug beim Glücksspiel aufspüren. In: digitalbusiness (2008) 7, S. 14-16. Pohl, Schürr (1998) Pohl, K.; Schürr, A.: Workshopbericht Modellierung '98. Universität Münster, 1998.

Verfügbar unter http://www.kuenstliche-intelligen•.de/fileadmin/template/main/archiv/98schuerr.pdf, Abruf am 2008-09-06.

304

Literaturverzeichnis

Polyzotis et al. (2007)

Polyzotis, N.; Skiadopoulos, S.; Vassiliadis, P.; Simitsis, A.; Frantzell, N. E.: Supporting streaming updates in an active data warehouse. In: IEEE Computer Society

(Hrsg.): Proceedings of the 23rd IEEE international conference on data engineering (ICDE 2007), Istanbul.IEEE Computer Society Press, 2007, S. 476-485. Popper (1994)

Popper, K. R.: Logik der Forschung. Mohr, 10. Auflage, 1994. Popper (1998) Popper, K. R.: Objektive Erkenntnis. Hoffmann und Campe, 4. Auflage, 1998. Popper (2000)

Popper, K. R.: Vermutungen und Widerlegungen: Das Wachstum der wissenschaftlichen Erkenntnis. Mohr, Einbändige Studienausgabe der Bände 1 u. 2., 2000. Popper (2004)

Popper, K. R.: Auf der Suche nach einer besseren Welt. Piper, 13. Auflage, 2004. Popper, Feyerabend (1992a) Popper, K. R.; Feyerabend, P. K.: Der lauber Platons. Francke, 7. Auflage, 1992. Popper, Feyerabend (1992b)

Popper, K. R.; Feyerabend, P. K.: Falsche Propheten. Francke, 7. Auflage, 1992. Porac, Thomas (1990) Parac, J. F.; Thomas, H.: Taxonomie mental models in competitor definition. In: The Academy of Management Review 15 (1990) 2, S. 224-240. Porter (1980) Porter, M. E.: Competitive strategy: techniques for analyzing industries and competitors. Free Press, 1980. Porter (1991) Porter, M. E.: Toward adynamie theory of strategy. In: Strategie Management Journal 12 (1991) Speciallssue Winter, S. 95-117. Porter (2008) Porter, M. E.: Wettbewerbsstrategie: Methoden zur Analyse von Branchen und Konkurrenten (Übersetzung aus dem Englischen). Campus, 11. Auflage, 2008. Priebe, Pernul (2001) Priebe, T.; Pernul, G.: Metadaten-gestützter Data-Warehouse-Entwurf mit ADAPTed UML. In: Buhl, H.; Huther, A.; Reitwiesner, B. (Hrsg.): Information Age Economie. Proceedings der Wirtschaftsinformatik 2001, Augsburg. Physika, 2001, S.73-87. Priemer (1995) Priemer, J.: Entscheidungen über die Einsetzbarkeit von Software Modelle. Pro-Universitate-Verlag, 1995.

an hand formaler

Uteraturverzeichnis

305

Priewasser (2001)

Priewasser, E.: Bankbetriebslehre. Oldenbourg, 7. Auflage, 2001. Propach, Reuse (2003)

Propach, J.; Reuse, 5.: Data Warehause: ein 5-Schichten-Modell. In: WISU - Das Wirtschaftsstudium 32 (2003) 1, S. 98-106. Putz-Osterloh (1987)

Putz-Osterloh, W.: Gibt es Experten für komplexe Probleme? In: Zeitschrift für Psychologie mit Zeitschrift für angewandte Psychologie 195 (1987) 1, S. 63-84. Raghavan (1991)

Raghavan, 5.: JANUS: a paradigm for active decision support. In: Decision Support Systems 7 (1991) 4, S. 379-395. Rao et al. (1994)

Raa, H. R.; Sridhar, R.; Narain, 5.: An active intelligent decision support system architecture and simulation. In: Decision Support Systems 12 (1994) 1, S. 79-91. Rauh, Stickel (1997) Rauh, 0.; Stickel, E.: Konzeptuelle Datenmodellierung. Teubner, 1997. Rechenberg (2003)

Rechenberg, P.: Zum Informationsbegriff der Informationstheorie. In: Informatik Spektrum 26 (2003) 5, S. 317-326. Reither (1981)

Reither, F.: Thinking and acting in complex situations: a study of experts' behavior. In: Simulation & Gaming 12 (1981) 2, S. 125-140. Resch, Oesterreich (1987)

Resch, M.; Oesterreich, R.: Bildung von Zwischenzielen in Entscheidungsnetzen. In: Zeitschrift für experimentelle und angewandte Psychologie 34 (1987) 2, S. 301-317. Riebel (1992)

Riebei, P.: Einzelerlös-, Einzelkosten- und Deckungsbeitragsrechnung als Kern einer ganzheitlichen Führungsrechnung. In: Männel, W. (Hrsg.): Handbuch Kostenrechnung. Gabler, 1992, S. 247-299. Riebel (1994)

Riebei, P.: Einzelkosten- und Deckungsbeitragsrechnung. Gabler, 7. Auflage, 1994. Rizvi (2005)

Rizvi, 5.: Complex event processing beyond active databases: streams and uncertainties. University of california at Berkeley, 2005. Verfügbar unter http://www.eecs.berkeley.edu/Pubs/TechRpts/200s/EECS-200s-26.pdf, Abruf am 2010-04-16.

306

Literaturverzeichnis

Rommelspacher (2008a)

Rommelspacher, J.: Ereignisgetriebene Architekturen. In: Wirtschaftsinformatik 50 (2008a) 4, S. 314-317. Rommelspacher (2008b)

Rommelspacher, J.: Modelling complex events with event-driven process chains. In: Hesse, W.; Oberweis, A. {Hrsg.}: Proceedings of the third European symposium on analysis, design, use and societal impact on information systems (AIS SIGSAND 2008b), Marburg. GI, 2008, s. 79-82. Rosemann (1996)

Rosemann, M.: Komplexitätsmanagement in Prozessmodellen. Gabler, 1996. Rosemann, Green (2002) Rosemann, M.; Green, P.: Developing a meta model for the Bunge-Wand-Weber ontological constructs. In: Information Systems 27 (2002) 2, S. 75-91. Rosemann, Vessey (2008)

Rosemann, M.; Vessey, 1.: Towards improving the relevance of information systems research to practice: the role of applicability checks. In: MIS Quarterly 32 (2008) 1, s. 1-22.

Russel (2007) Russel, A.: Vou can't do that with BI- or can you? In: sascom (2007) 3, s. 4-6. Sachs, Hauser (2002)

Sachs, S.; Hauser, A.: Das ABC der betriebswirtschaftlichen Forschung: Anleitung zum wissenschaftlichen Arbeiten. Versus, 2002. Sapia et al. (1999) Sapia, C.; Blaschka, M.; Höfling, G.; Dinter, B.: Extending the E/R model for the

multidimensional paradigm. In: Kambayashi, Y. (Hrsg.): Advances in database technologies. Proceedings of ER '98 workshops on data warehousing and data mining, mobile data access, and collaborative work support and spatio-temporal data management, Singapur. LNCS 1552, Springer, 1999, 5.105-116. Schaub (2006) Schaub, H.: Störungen und Fehler beim Denken und Problem lösen. In: Funke, J. (Hrsg.): Denken und Problemlösen. Hogrefe, 2006, S. 447-482. Scheer (1998a) Scheer, A.: ARIS - Modellierungsmethoden, Metamodelle, Anwendungen. Sprin-

ger, 3. Auflage, 1998. Scheer (1998b)

Scheer, A. W.: Wirtschaftsinformatik: Referenzmodelle für industrielle Geschäftsprozesse. Springer, 2. Auflage, 1998.

Uteraturverzeichnis

307

scheer (2002)

Scheer, A.: ARIS - Vom Geschäftsprozess zum Anwendungssystem. Springer, 4. Auflage, 2002. Scheer, Thomas (2005)

Scheer, A.; Thomas, 0.: Geschäftsprozessmodellierung mit der ereignisgesteuerten Prozesskette.ln: WlsU - Das Wirtschaftsstudium 34 (2005) 8-9, 5.1069-1078. schelp (2000)

Schelp, J.: ModelIierung mehrdimensionaler Datenstruleturen analyseorientierter Informationssysteme. Deutscher Universitäts-Verlag, 2000. schelp (2006)

Schelp, J.: "Real"-time data warehousing. In: Chamoni, P.; Gluchowski, P. (Hrsg.): Analytische Informationssysteme. Springer, 3. Auflage, 2006, S. 426-438. schelp, Chamoni (2000)

Schelp, J.; Chamoni, P.: Modellierung mehrdimensionaler Datenstrukturen mit Star Schemata. In: WlsU - Das Wirtschaftsstudium 29 (2000) 8-9, s. 1132-1138. Schiefer et al. (2007)

Schiefer, J.; Rozsnyai, S.; Rauscher, C.; Saurer, G.: Event-driven-rules for sensing and responding to business situations. In: Jacobsen, H.; Muhl, G.; Jaeger, M. A. (Hrsg.): Proceedings of the 2007 inaugural international conference on distributed event-based systems (DEBs 2007), Toronto. ACM, 2007, s. 198-205. Schiefer, seufert (2005)

Schiefer, J.; Seufert, A.: Management and controlling of time-sensitive business processes with sense & respond. In: IEEE Computer Society (Hrsg.): Proceedings of the international conference on computational intelligence for modelling control and automation (CIMCA 2005), Wien. IEEE Computer society Press, 2005, s. 77-82. schiemenz, schönert (2005)

Schiemenz, B.; Schönert, 0.: Entscheidung und Produktion. Oldenbourg, 3. Auflage,2005. schierenbeck (2003) schierenbeck, H.: Grundlagen, Marktzinsmethode und Rentabilitäts-Controlling. Gabler, 8. Auflage, 2003. schlageter, stucky (1983) schlageter, G.; stucky, W.: Datenbanksysteme. Teubner, 1983. schlesinger, Achermann (1995)

Schlesinger, M.; Achermann, F.: Vergleichende Gegenüberstellung von TriggerMechanismen von Ingres, Oracle und Sybase. Working Paper No. 62, Universität Bern, 1995. Verfügbar unter http://www.ie.iwi.unibe.ch/publikationen/berichte/resource/WNJ62.pdf, Abruf am 201G-04-16.

Literaturverzeichnis

308 Schneeweiß (1966)

Schneeweiß, H.: Das Grundmodell der Entscheidungstheorie. In: Statistical Papers 7 (1966) 3, S. 125-137. Schrefl, Thalhammer (2000)

Sehrefl, M.; Thalhammer, T.: On making data warehouses active. In: Kambayashi, V.; Mohania, M.; Tjoa, A. (Hrsg.): Data Warehousing and Knowledge Discovery. Proceedings of second international conference (DaWaK 2000), Landon. LNCS 1874, Springer, 2000, S. 3446.

Schütte (1998) Schütte, R.: Grundsätze ordnungsmäßiger Referenzmodellierung. Gabler, 1998. Schütte (1999)

Schütte, R.: Basispositionen der Wirtschaftsinformatik - ein gemäßigtkonstruktivistisches Programm. In: Becker, J.; König, W.; Schütte, R.; Wendt, 0.; Zelewski, S. (Hrsg.): Wirtschaftsinformatik und Wissenschaftstheorie - Bestandsaufnahme und Perspektiven. Gabler, 1999, S. 211-241. Schütte, Zelewski (1999)

Schütte, R.; Zelewski, S.: Wissenschafts-und erkenntnistheoretische Probleme beim Umgang mit Ontologien. In: König, W.; Wendt, O. (Hrsg.): Proceedings der Tagung Wirtschaftsinformatik und Wissenschaftstheorie '99, Frankfurt a.M. 1999, S.1-19. Schulze, Dittmar (2006)

Schulze, K.; Dittmar, C.: Business-Intelligence Reifegradmodelle. In: Chamoni, P.; Gluchowski, P. (Hrsg.): Analytische Informationssysteme. Springer, 3. Auflage, 2006, S. 71-87. Schwarz (2000)

Schwarz, S.: Integriertes Metadatenmanagement - Ein Überblick. In: Jun& R.; Winter, R. (Hrsg.): Data Warehousing Strategie: Erfahrungen, Methoden, Visionen. Springer, 2000, S. 101-116. Schweitzer (1967)

Schweitzer, M.: Methodologische und entscheidungstheoretische Grundfragen der betriebswirtschaftlichen Prozeßstrukturierung. In: Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung 19 (1967), S. 279-296. Schwemmer (1984) Schwemmer, 0.: Ontologie. In: Mittelstraß, J. (Hrsg.): Enzyklopädie Philosophie und Wissenschaftstheorie - Teil 2. 8ibliographisches Institut, 1984, S. 1077-1079. Seeger (2004) Seeger, B.: Datenströme.ln: Datenbank-Spektrum 4 (2004) 9, S. 30-33.

Uteraturverzeichnis

309

seel, Vanderhaegen (2005) Seel, C.; Vanderhaegen, D.: Meta-model based extensions of the EPC for interorganisational process modelling.ln: Nüttgens, M.; Rump, F. J. (Hrsg.): Proceedings des GI-Workshops Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten (EPK 2005), Hamburg. GI-Arbeitskreis Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, 2005, 5.117-136. seibt (2001) Seibt, D.: Anwendungssystem. In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. Springer, 4. Auflage, 2001, S. 46-47. Seidel (2001) Seidel, M.: Ethisch-normative Werturteile in der Betriebswirtschaftslehre. Tectum, 200l. shannon (1948) Shannon, C. E.: A mathematical theory of communication. In: Bell System Technical Journal 27 (1948) 3, S. 379-423. shim et al. (2002) Shim, J.; Warkentin, M.; Courtney, J. F.; Power, D. J.; Sharda, R.; Carlsson, C.: Past, present, and future cf decision support technology. In: Decision Support Systems 33 (2002) 2, 5.111-126. Si mon (1955) Si mon, H. A.: A behavioral model of rational choice. In: The Quarterly Jounal of Eeonomies 69 (1955) 1, S. 99-118. Si mon (1960) Si mon, H. A.: The new science of management decision. Harper & Row, 1960. Si mon (1977) Si mon, H. A.: The new science of management decision. Prentice-Hall, 1977. Si mon (1996) Si mon, H. A.: The seiences of the artifieial. MIT Press, 1996. sinz (2001) Sinz, E.: Modellierung. In: Mertens, P. {Hrsg.}: Lexikon der Wirtschaftsinformatik. Springer, 4. Auflage, 2001, S. 312-313. smith, smith (1977) Smith, J. M.; Smith, D. C. P.: Database abstractions: aggregation and generalization. In: ACM Transactions on Database Systems 2 (1977) 2, 5.105-133.

310

Literaturverzeichnis

Son et al. (2007)

San, B.; Lee, J.; Park, K.; Kim, C.; Kim, H.; Kim, S.: An efficient method to create business level events using complex event processing based on RFID standards. In: Obermaisser, R.; Nah, V.i Puschner, Po; Rammig. F. J. (Hrsg.): Software technologies tor embedded and ubiquitous systems. Revised papers of 5th IFIP international workshop (SEUS 2007), Santorini. LNCS 4761, Springer, 2007, S. 1-10. Stachowiak (1973) Stachowiak, H.: Allgemeine Modelltheorie. Springer, 1973. Stachowiak (1983) Stachowiak, H.: Modelle - Konstruktion der Wirklichkeit. Fink, 1983. Staehle (1999)

Staehle, W. H.: Management. Vahlen, 1999. Stähler (2005) Stähler, 0.: Softwareengineering mit ARIS und ORACLE beim E/D/E. In: Scheer, A.;

Jost, W.; Wagner, K. (Hrsg.): Von Prozessmodellen zu lauffähigen Anwendungen. Springer, 2005, 5. 223-244. Stahlknecht, Hasenkamp (2005) Stahlknecht, P.; Hasenkamp, U.: Einführung in die Wirtschaftsinformatik. Springer, 11. Auflage, 2005. Stefanov et al. (2005)

Stefanov, V.; List, B.; Schiefer, J.: Bridging the gap between data warehouses and business processes: a business intelligence perspective for event-driven process chains. In: IEEE Computer Society (Hrsg.): Proceedings of the 9th IEEE international

enterprise distributed object computing conference (EDOC 2005), Enschede. IEEE Computer Society Press, 2005, S. 3-14. Steinmann, Schreyögg (2005)

Steinmann, H.; Schreyögg, G.: Management - Grundlagen der Unternehmensführung. Gabler, 6. Auflage, 2005. Strahringer (1996)

Strahringer, S.: Metamodellierung als Instrument des Methodenvergleichs. Shaker, 1996. Strahringer (1998)

Strahringer, S.: Ein sprachbasierter Metamodellbegriff und seine Verallgemeinerung durch das Konzept des Metaisierungsprinzips. In: Pohl, K.; Schürr, S.; Vossen, G. (Hrsg.): Proceedings des GI-Workshops Modellierung 1998, Münster. CEUR Workshop Proceedings, 1998. Sturm (2005)

Sturm, R.: Entscheidungen und Entscheidungsmodelle. In: WISU - Das Wirtschaftsstudium 34 (2005) 1, S. 56-58.

Uteraturverzeichnis

311

Teubner (1999)

Teubner, R. A.: Organisations- und Informationssystemgestaltung. Deutscher Universitäts-Verlag, 1999. Thalhammer (2001)

Thalhammer, T.: Active data warehouses: complementing OLAP with analysis rules. Dissertation an der Johannes Keppler Universität Unz, 2001. Thalhammer et al. (2001)

Thalhammer, T.; Schrefl, M.; Mohania, M.: Active data warehouse: complementing OLAP with analysis rules. In: Data & Knowledge Engineering 39 (2001) 3, S.241-269. Thalhammer, Sehretl (2002)

Thalhammer, T.; Schrefl, M.: Realizing active data warehauses with off-the-shelf database teehnology. In: Software - Praetiee and Experienee 32 (2002) 12, S. 1193-1222. Thomas (2005)

Thomas, 0.: Das Modellverständnis in der Wirtschaftsinformatik: Historie, Uteraturanalyse und Begriffsexplikation. Veröffentlichungen des Instituts für Wirtschaftsinformatik Nr. 184, Universität Saarbrücken, 2005. Töpfer (2008) Töpfer, J.: Active enterprise intelligence. In: Töpfer, J.; Winter, R. (Hrsg.): Aetive en-

terprise intelligence. Springer, 2008, S. 1-28. Totok (2000)

Totok, A.: Modellierung von OLAP- und Data-Warehouse-Systemen. Deutscher Universitäts-Verlag, 2000. Trujillo, Lujan-Mora (2003)

Trujillo, J.; Lujan-Mora, S.: A UML based approach for modeling ETL processes in data warehouses. In: Song, 1.; Uddle, S. W.; Ung, T. W.; Scheuermann, P. (Hrsg.): Conceptual modeling - ER 2003. Proceedings of 22nd international conference on eoneeptual modeling, Chieago. LNCS 2813, Springer, 2003, S. 307-320. Tversky, Kahneman (1986)

Tversky, A.; Kahneman, D.: Rational choice and the framing of decisions. In: Journal of Business 59 (1986) 4, S. 251-278. Ulrieh (1968)

Ulrich, H.: Führungskonzeption und Unternehmensorganisation. In: Angehrn, 0.; Künzi, H. P. (Hrsg.): Beiträge zur Lehre von Unternehmung - Festschrift für Karl Käfer. Poesehel, 1968, S. 297-308. Unbehauen (1998)

Unbehauen, R.: Systemtheorie 2: Mehrdimensionale, adaptive und nichtlineare Systeme. Oldenbourg, 7. Auflage, 1998.

Literaturverzeichnis

312 Unbehauen (2002)

Unbehauen, R.: Systemtheorie 1: Allgemeine Grundlagen, Signale und lineare Systeme im Zeit- und Frequenzbereich. Oldenbourg.. 8. Auflage, 2002. Vassiliadis et al. (2002) Vassiliadis, P.; Simitsis, A.; Skiadopoulos, S.: Conceptual modeling for ETL

processes. In: Theodoratos, D. {Hrsg.}: Proceedings cf the 5th ACM international workshop on data warehousing and OLAP (DOLAP 2002), McLean. ACM, 2002, S.14-21. Verhoef et al. (1991) Verhoef, T. F.; ter Hofstede, A. H. M.; Wijers, G. M.: Structuring modelling knowledge for CASE shells. In: Andersen, R.; Bubenko Jr., J. A.; S.lvberg, A. (Hrsg.): Ad-

vanced information systems engineering. Proceedings of the third international conference (CAiSE '91), Trondheim. LNCS 498, Springer, 1991, S. 502-524. Vesset (2007) Vesset, D.: The next wave of business intelligence. In: sascom (2007) 1, S.5-6. vom Brocke (2003)

vom Brocke, J.: Referenzmodellierung. Logos, 2003. von Bertalanffy (1957)

von Bertalanffy, L.: Allgemeine Systemtheorie: Wege zu einer neuen mathesis universalis. In: Deutsche Universitätszeitung 12 (1957) 5/6, S. 8-12. von Bertalanffy (1968) von Bertalanffy, L.: General system theory. Braziller, 1968. Vossen (2008)

Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme. Oldenburg, 5. Auflage, 2008. Wagner (2002) Wagner, G.: How to design a general rule markup language. In: Tolksdorf, R.; Eck-

stein, R. (Hrsg.): Proceedings zum Workshop XML Technologien für das Semantic Web (XSW 2002), Berlin. GI, 2002, S. 19-37. Wand et al. (1995)

Wand, V.; Monarchi, D.; Parsons, J.; Woo, C.: Theoretical foundations for conceptual modeling in information systems development. In: Decision Support Systems 15 (1995) 4, S. 285-304. Wand, Weber (1993)

Wand, V.; Weber, R.: On the ontological expressiveness of information systems analysis and design grammars. In: Journal of Information Systems 3 (1993) 4, S.217-237.

Uteraturverzeichnis

313

VVand,VVeber(1995)

Wand, V.; Weber, R.: On the deep structure of information systems. In: Information Systems JournalS (1995) 3, S. 203-223. VVand, VVeber (2002)

Wand, V.; Weber, R.: Research commentary: information systems and conceptual modeling - a research agenda. In: Information Systems Research 13 (2002) 4, 5.363-376. VVedekind (1979) VVedekind, H.: Die Objekttypenmethode beim Datenbankentwurf - dargestellt am

Beispiel von Buchungs- und Abrechnungssystemen. In: Zeitschrift für Betriebswirtschaft 49 (1979) 5, S. 367-387. VVedekind (1980)

Wedekind, H.: Strukturveränderung im Rechnungswesen unter dem Einfluß der Datenbanktechnologie. In: Zeitschrift für Betriebswirtschaft 50 (1980) 6, S. 662-677. VVedekind (1981)

Wedekind, H.: Datenbanksysteme I - Eine konstruktive Einführung in die Datenverarbeitung in Wirtschaft und Verwaltung. Bibliographisches Institut, 1981. VVedekind, Ortner (1980)

Wedekind, H.; Ortner, E.: Systematisches Konstruieren von Datenbankanwendungen-Zur Methodologie der Angewandten Informatik. Hanser, 1980. VVilde, Hess (2007)

Wilde, T.; Hess, T.: Forschungsmethoden der Wirtschaftsinformatik. In: Wirtschaftsinformatik 49 (2007) 4, S. 280-287. VVinter (1991)

Winter, R.: Mehrstufige Produktionsplanung in Abstraktionshierarchien auf der Basis relationaler Informationsstrukturen. Springer, 1991. VVinter (2000)

Winter, R.: Zur Positionierung und Weiterentwicklung des Data Warehousing in der betrieblichen Applikationsarchitektur. In: Jung, R.; VVinter, R. (Hrsg.): Data VVarehousing Strategie: Erfahrungen, Methoden, Visionen. Springer, 2000, 5.127-139. VVittmann (1979)

Wittmann, W.: Wissen in der Produktion. In: Kern, W. (Hrsg.): Handwörterbuch der Produktionswirtschaft. Poeschel, 1979, Spalte 2261-2272. VVKVVI (1994)

WKWI: Profil der Wirtschaftsinformatik. Ausführungen der Wissenschaftlichen Kommission der VVirtschaftsinformatik. In: VVirtschaftsinformatik 36 (1994) 1, 5.80-81.

Literaturverzeichnis

314 Wyssusek et al. (2002)

Wyssusek, Bo; Schwartz, M.; Kremberg, B.; Mahr, S.: Erkenntnistheoretische Aspekte bei der Modellierung von Geschäftsprozessen. In: WISU - Das Wirtschaftsstudium 31 (2002) 2, S. 238·246. Young, O'Byrne (2000)

Young. S. 0.; O'Byrne, S. F.: EVA and value-based management: a practical guide to implementation. McGraw-HiII, 2000. Zachman (1987)

Zachman, J.: A framework for information systems architecture. In: IBM Systems Journal 26 (1987) 3, S. 277-293. Zeh (2003)

Zeh, T.: Data Warehousing als Organisationskonzept des Datenmanagements. Eine kritische Betrachtung der Data-Warehouse-Definition von Inmon. In: InformatikForschung und Entwicklung 18 (2003) 1, S. 32-38. Zelewski (1995)

Zelewski, S.: Petrinetzbasierte Modellierung komplexer Produktionssysteme: Eine Untersuchung des Beitrags von Petrinetzen zur Prozeßkoordinierung in komplexen Produktionssystemen, insbesondere Flexiblen Fertigungssystemen. Arbeitsberichte des Instituts für Produktionswirtschaft und Industrielle Informationswirtschaften, Leipzig, 1995. Zelewski (2007)

Zelewski, 5.: Kann Wissenschaftstheorie behilflich für die Publikationspraxis sein? In: Lehner, F.; Zelewski, S. (Hrsg.): Wissenschaftstheoretische Fundierung und wissenschaftliche Orientierung in der Wirtschaftsinformatik. Gito, 2007, S. 71-120. Zimmer, Unland (1999)

Zimmer, 0.; Unland, R.: On the semantics of complex events in active database management systems. In: IEEE Computer Society (Hrsg.): Proceedings of the 15th

international conference on data engineering (lCDE 1999), Sydney. IEEE Computer Society Press, 1999, S. 392-399. Zuboff (1985)

Zuboff, 5.: Automate/informate: the two faces of intelligent technology. In: arganizational Dynamics 14 (1985) 2, S. 5-18.