Agile Unternehmen durch Business Rules (eBook)

Markus Schacher: El. Ing. HTL, Nachdiplomstudium "Informatik" ETH Zürich, Mitinhaber der KnowGravity Inc., Zürich. Er berät Unternehmen bei der Anwendung des Business Rules Ansatzes sowie bei der Erstellung lösungs-neutraler Spezifikationen. Er ist Mitglied der Business Rules Group sowie Chairman der European Business Rules Conference. Patrick Grässle: Wirtschaftsinformatiker lic. oec. Universität Zürich, Mitinhaber der KnowGravity Inc., Zürich. Er ist als Berater und Trainer für Software Engineering tätig und ist Co-Autor eines bekannten UML-Buches.

Vorwort 6
Inhaltsverzeichnis 8
1 Einleitung 15
2 Vorstellung der Fallstudie „KnowBeer“ 19
Teil I Überblick – Der Business Rules Ansatz 23
3 Ausgangslage 25
3.1 Was ist das Problem? 25
3.2 Motivation: Sinnvolle Unternehmen 26
3.3 Agilität: Dynamische Unternehmen in 28
3.4 Compliance: Gesetzeskonforme Unternehmen 30
4 Der Business Rules Ansatz 31
4.1 Geschäftsregeln – Eine erste Annäherung 31
4.2 Grundkonzepte des Business Rules Ansatzes 33
4.3 Das Business Motivation Model 35
4.4 Forderungen des Business Rules Ansatzes 35
4.5 Typische Anwendungsgebiete des Business Rules Ansatzes 36
4.6 Postulate des Business Rules Manifests 37
4.6.1 Geschäftsregeln sind wichtig 38
4.6.2 Trennen der Geschäftsregeln von den Prozessen 39
4.6.3 Deklarativ und wohl definiert 40
4.6.4 Von, durch und für die Fachleute 41
5 Nutzen des Business Rules Ansatzes 43
5.1 Nutzen für das Unternehmen 43
5.2 Nutzen für Fachseite 44
5.3 Nutzen für die Informatik 44
Teil II Agile Unternehmen – Geschäftsanalyse 46
6 Unternehmenszweck 47
6.1 Ausgangslage: Wohin führt die Reise? 47
6.2 Lösungsansatz: Zweckdefinition 49
6.3 Schritt für Schritt: Formulierung von Vision und Zielen 51
6.4 Ergebnis: Die neue Ausrichtung von KnowBeer 52
6.5 Wie geht es weiter? 53
7 Unternehmenseinflüsse 55
7.1 Ausgangslage: Welchen Einflüssen ist ein Unternehmen ausgesetzt? 55
7.2 Lösungsansatz: Einflussanalyse 57
7.3 Schritt für Schritt: Einschätzung von Einflüssen 60
7.4 Ergebnis: Einflüsse auf KnowBeer und deren Einschätzung 62
Externe Einflüsse: 62
Interne Einflüsse: 62
7.5 Wie geht es weiter? 66
8 Geschäftsstrategie 67
8.1 Ausgangslage: Wie funktioniert das Geschäft? 67
8.2 Lösungsansatz: Strategiedefinition 70
8.3 Schritt für Schritt: Erarbeitung von Strategien und Taktiken 71
8.4 Ergebnis: Die Geschäftspolitik von KnowBeer 73
8.5 Wie geht es weiter? 75
9 Projekt-Definition 77
9.1 Ausgangslage: Was ist ein Projekt? 77
9.2 Lösungsansatz: Das Zachman Framework 80
9.3 Schritt für Schritt: Abgrenzung eines Projekts 84
9.4 Ergebnis: Der Projektauftrag „BEGIN“ 87
9.5 Wie geht es weiter? 89
10 Unternehmensvokabular 91
10.1 Ausgangslage: Was ist ein Kunde? 91
10.2 Lösungsansatz: Unternehmensvokabular 92
10.3 Schritt für Schritt: Erarbeitung eines Unternehmensvokabulars 101
10.4 Ergebnis: Das Unternehmensvokabular von KnowBeer 104
10.5 Wie geht es weiter? 109
11 Geschäftsprozesse 111
11.1 Ausgangslage: Was läuft hier eigentlich? 111
11.2 Lösungsansatz: Geschäftsprozessmodellierung 112
11.3 Schritt für Schritt: Skizzierung von Geschäftsprozessen 117
11.4 Ergebnis: Die wichtigsten Prozesse von KnowBeer 120
11.5 Wie geht es weiter? 123
12 Geschäftswissen 125
12.1 Ausgangslage: Was muss überhaupt geregelt werden? 125
12.2 Lösungsansatz: Direktiven 126
12.3 Schritt für Schritt: Formulierung von Regelungen 130
12.4 Ergebnis: Auszuarbeitende Regelungen von KnowBeer 133
12.5 Wie geht es weiter? 136
13 Geschäftsregeln 137
13.1 Ausgangslage: Wie hoch ist ein Rabatt? 137
13.2 Lösungsansatz: Geschäftsregeln 138
13.2.1 Klassifikation von Geschäftsregeln 140
13.2.2 Entscheidungstabellen 140
13.2.3 Formales Deutsch 143
Textschablone für Ableitungen 143
Textschablone für Prozessregeln: 145
Textschablone für Einschränkungen 147
Textschablone für Berechnungen 149
13.2.4 Vordefinierte Fakttypen und Aktionen 150
13.3 Schritt für Schritt: Formulierung von Geschäftsregeln 151
13.4 Ergebnis: Regelungen von KnowBeer 156
13.4.1 Übersicht 157
13.4.2 Durchsetzungsgrade 158
13.4.3 Regelung „Kreditlimite“ 158
13.4.4 Regelung „Rabattbestimmung“ 160
13.4.5 Regelung „Gratismuster“ 163
13.4.6 Regelung „Bevorzugter Kunde“ 164
13.4.7 Regelung „Verkaufskompetenzen“ 165
13.4.8 Regelung „Stückpreis“ 167
13.4.9 Regelung „Versandkosten“ 168
13.5 Wie geht es weiter? 169
14 Strukturierung 171
14.1 Ausgangslage: Wer hat hier noch die Übersicht? 171
14.2 Lösungsansatz: Die Rule Map und der Inferenzbaum 172
14.2.1 Die Rule Map 173
14.2.2 Der Inferenzbaum 174
14.3 Schritt für Schritt: Strukturierung von Regelungen 175
14.3.1 Entwurf von Rule Maps 175
14.3.2 Entwurf von Inferenzbäumen 177
14.4 Ergebnis: Die Regel-Zusammenhänge bei KnowBeer 178
14.5 Wie geht es weiter? 180
15 Prüfung 181
15.1 Ausgangslage: Was stimmt hier nicht? 181
15.2 Lösungsansatz: Verifikation & Validierung
15.2.1 Verifikation 183
15.2.2 Validierung 184
15.3 Schritt für Schritt: Prüfung von Regelungen 185
Verifikation einer Entscheidungstabelle 187
15.4 Ergebnis: Aktualisierte Regelungen von KnowBeer 191
15.5 Wie geht es weiter? 192
Teil III Agile IT – Die technische Umsetzung 195
16 Rule Management 197
16.1 Ausgangslage: Was gilt nun? 197
16.2 Lösungsansatz: Rule Management 199
16.2.1 Wahl der Umsetzungsstrategie 200
16.2.2 Verwaltung und Änderung von Geschäftsregeln 201
16.2.3 Knowledge Management 203
Dokumentation 204
Change-Management 205
Mitarbeiter-Ausbildung 206
Kontrolle 206
16.3 Schritt für Schritt: Aufsetzen des Rule Managements 206
16.4 Ergebnis: Der Änderungsprozess von KnowBeer 208
16.5 Wie geht es weiter? 213
17 IT-Anforderungsdefinition 215
17.1 Ausgangslage: Klare Anforderungen? 215
17.2 Lösungsansatz: Anforderungen an die Automatisierung 217
Anforderungen und Geschäftsregeln 217
Volatilität und Ausbreitungszeit 218
Prüfzeitpunkt 220
Einbettung der BR-Technologie in eine bestehende IT-Systemlandschaft 221
Anforderungen an das Rule Management Werkzeug 221
17.3 Schritt für Schritt: Erhebung der Anforderungen 221
17.4 Ergebnis: IT-Anforderungsdefinition 223
17.4.1 Anforderungen an die Umsetzung mittels Business Rules Technologie 223
17.4.2 Anforderungen an das Rule Management 225
17.5 Wie geht es weiter? 226
18 BR-Technologie 227
18.1 Ausgangslage: Was ist Business Rules Technologie? 227
18.2 Lösungsansatz: BR-Technologie 228
18.2.1 Rule Execution Technologie 229
18.2.2 Regel-Komplexität 230
18.2.3 Logische Schlussfolgerungen 231
18.2.4 „Wie“ und „Warum“ Erklärungen 235
18.2.5 Generische BRT Anforderungen 236
18.3 Schritt für Schritt: Auswahl der Business Rules Technologie 237
18.4 Ergebnis: Die BRT-Anforderungen von KnowBeer 240
18.5 Wie geht es weiter? 243
19 BR-Architektur 245
19.1 Ausgangslage: Regeln ohne Fakten? 245
19.2 Lösungsansatz: Architektur 247
19.2.1 Business Rules Architekturen 247
Service-Architektur 247
Schichten-Architektur 249
Datenbank-Architektur 250
Generator-Architektur 251
19.2.2 Anbindung des Faktenmodells 253
Push-Architektur 253
Pull-Architektur 254
19.3 Schritt für Schritt: Entwurf der BR-Architektur 255
19.4 Ergebnis: Die BR-Architektur von KnowBeer 257
19.5 Wie geht es weiter? 262
20 Implementation 263
20.1 Ausgangslage: Eine Schwierigkeit 263
20.2 Lösungsansatz: Implementationstechniken für Geschäftsregeln 264
20.2.1 Reale Regelsprachen 264
20.2.2 Aufruf einer Business Rule Engine 265
20.2.3 Implementation von Ableitungen in der Datenbank 265
20.2.4 Implementation von Einschränkungen in der Datenbank 266
20.2.5 Implementation von Prozessregeln in der Datenbank 267
20.3 Schritt für Schritt: Implementation der Regelungen 268
20.4 Ergebnis: Implementation von Regelungen bei KnowBeer 269
20.4.1 Regelung „Versandkosten“ 270
20.4.2 Regelung „Stückpreis“ 272
20.4.3 Regelung „Bevorzugter Kunde“ 274
20.4.4 Regelung „Rabattbestimmung“ 274
20.4.5 Regelung „Gratismuster“ 276
20.4.6 Regelung „Kreditlimite“ 277
20.5 Wie geht es weiter? 280
21 Erntezeit 281
21.1 Ausgangslage: Zwei Jahre später... 281
21.2 Lösungsansatz: Agilität 284
21.3 Schritt für Schritt: Evolution eines Unternehmens 285
21.4 Ergebnis: Abonnemente in KnowBeer 287
21.5 Wie geht es weiter? 292
Anhänge 293
A Business Rules Manifest 295
Die Prinzipien der Business Rules Unabhängigkeit 295
B Zusammenfassung des Entwicklungsprozesses 299
B.1 Phase „Geschäftsanalyse“ 299
B.2 Phase „Umsetzung“ 301
C Übersicht über die verwendeten Notationen 303
C.1 Faktenmodell-Notation 303
C.2 Aktivitätsdiagramm-Notation 304
C.3 Rule-Map-Notation 304
C.4 Inferenzbaum-Notation 305
D Muster & Checklisten
D.1 Formen von Entscheidungstabellen 307
Lookup-Tabelle 307
Folgerungstabelle 307
Bedingungstabelle 308
Geschachtelte Bedingungstabelle 308
D.2 Textschablonen für formales Deutsch 309
Textschablone für Ableitungen 309
Textschablone für Prozessregeln 309
Textschablone für Einschränkungen 310
Textschablone für Berechnungen 311
D.3 Konzept-Bibliothek 312
D.4 Fakttypen-Bibliothek 313
D.5 Anforderungen an Regel-Technologie 314
E Meta Modelle 321
E.1 Business Motivation Model 321
E.2 Geschäftsregeln 322
F Begriffsdefinitionen 323
G Business Rules Technologie 333
G.1 Rule Discovery Werkzeuge 333
G.2 Rule Management Werkzeuge 336
G.3 Rule Execution Werkzeuge 338
H Weitere Informationen 345
H.1 Business Rules Standards 345
H.2 Interessante Web-Links 346
I Literaturreferenzen 347
Index 349

3 Ausgangslage (S. 11-13)

3.1 Was ist das Problem?

Bevor wír Ihnen die Ideen und Lösungsansätze des Business Rules Ansatzes aufzeigen, möchten wir als erstes darlegen, welche Probleme der Business Rules Ansatz zu lösen versucht.

Vielleicht leiden Sie ja gar nicht unter diesen Problemen, dann brauchen Sie sich nicht mit dem Business Rules Ansatz zu beschäftigen. In diesem Falle wird Ihnen auch unser Buch nicht viel helfen. Wenn also die folgenden Aussagen auf Ihr Geschäft zutreffen, haben Sie genug gute Gründe, unser Buch nicht zu kaufen:

* Ihr Geschäft wird seit Jahren auf die gleiche Weise abgewickelt. Wenn sich doch einmal etwas ändert, haben Sie ausreichend Zeit, die Änderung vorzunehmen.

* Die Regeln, die für Ihr Geschäft gelten, sind gut dokumentiert, allen bekannt und sie werden eingehalten.

* Ihre Mitarbeiter wissen, warum einzelne Regeln bestehen. Regeln, die keinen Sinn mehr  machen, werden geändert.

* Ihre Informatik-Systeme müssen selten angepasst werden.

* Allfällige Anpassungen an Ihren Informatik-Systemen werden rasch und problemlos umgesetzt.

* Ihre Konkurrenz nimmt das Leben ebenso gemütlich wie Sie.

Falls Sie hingegen nicht ganz sicher sind, ob für Ihr Unternehmen alle diese Aussagen zutreffen, dann leiden Sie vermutlich unter einigen der Probleme, für die der Business Rules Ansatz eine Lösung anbietet.

Drei wichtige Probleme, mit denen sich der Business Rules Ansatz beschäftigt, sind:

*Fehlende Motivation: Das Wissen, warum die Dinge im Unternehmen so laufen, wie sie laufen, fehlt oder ist verloren gegangen.

*Fehlende Agilität: Das Unternehmen und ihre Systeme können nicht schnell genug an die sich ändernde Umwelt angepasst werden.

*Fehlende Compliance: Das Unternehmen hat Mühe zu belegen, dass es sich an Gesetze und Regelungen hält. Diese drei Probleme werden im Folgenden genauer erläutert.


3.2 Motivation: Sinnvolle Unternehmen

Das Verhalten eines Unternehmens ergibt sich aus dem Verhalten seiner Mitarbeiter und Systeme. Sowohl die Mitarbeiter als auch automatisierte Systeme fällen dauernd Entscheidungen, lassen etwas zu oder nicht, verlangen gewisse Handlungen. Mit anderen Worten, sie befolgen Regeln.

Eine äußerst wichtige, in der Praxis oft zu wenig gestellte Frage ist, warum eine Regel befolgt werden muss. Diese Frage aber ist der Schlüssel zu sinnvollen Regeln. Hinter einer sinnvollen Regel steckt eine Motivation, die Regel trägt etwas zur Erreichung der Unternehmensziele bei. Wir nennen solche Regeln auch motivierte Regeln. Eine unsinnige oder unmotivierte Regel andererseits

* trägt nichts zur Erreichung der Unternehmensziele bei oder behindert gar deren Erreichung, oder

* ist nicht mehr aktuell, d.h. der Grund für die Einführung der Regel besteht nicht mehr, oder

* ist nicht relevant, d.h. regelt sie etwas, das nur selten vorkommt und nicht sehr wichtig ist. (Es gilt immer: So wenige Regeln wie nötig, aber nicht weniger, denn jede Regel verursacht auch Kosten, z.B. durch ihre Verwaltung.)

Leider bleiben Regeln oft erhalten, obwohl sie unsinnig geworden sind. „Wir haben das schon immer so gemacht." ist eine häufige Antwort auf die Frage nach dem Warum. Besonders schlimm ist es, wenn eine Regel lediglich aufgrund technologischer Beschränkungen eingeführt wurde. Wird sie nicht als solche erkannt kann es passieren, dass sie beibehalten wird, obwohl der ursprüngliche Grund längst weggefallen ist. Ein typisches Beispiel dafür sind Beschränkungen alter IT-Systeme wie die maximale Anzahl Bestellpositionen, die auf neue IT-Systeme übernommen werden, ohne hinterfragt zu werden.