Xpert.press
Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.
Markus Schacher Patrick Grässle
Agile Unternehmen durch Business Rules Der Business Rules Ansatz
Mit 83 Abbildungen und 40 Tabellen
123
Markus Schacher Hätzlergasse 23 8048 Zürich Schweiz
[email protected]
Patrick Grässle Pünt-Str. 37 8604 Volketswil Schweiz
[email protected]
Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.
ISSN 1439-5428 ISBN-10 3-540-25676-8 Springer Berlin Heidelberg New York ISBN-13 978-3-540-25676-2 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany 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. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz: Druckfertige Daten der Autoren Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3142 YL – 5 4 3 2 1 0
Vorwort
Dieses Buch ist wichtig. Ich habe seine Entstehung verfolgt und nun, da es publiziert ist, bin ich mit dem Ergebnis sehr zufrieden. Drei Dinge mag ich speziell: Die Botschaft ist einfach und direkt, die Balance zwischen fachlichen und technologischen Aspekten ist gut getroffen und das verwendete Modell ist fundiert. Die durchgängige Fallstudie hilft sehr, die Botschaft dem Leser verständlich zu machen. Die Botschaft ist, dass der Business Rules Ansatz einem Unternehmen zu mehr Agilität verhelfen kann. Es ist jedoch nicht damit getan, Business Rules Technologie einzukaufen. Man benötigt einen durchgängigen Ansatz – den Business Rules Ansatz – welcher mit einer fachlichen Sicht beginnt und daraus die passenden Geschäftsregeln ableitet, egal, ob sie mit Hilfe von Business Rules Technologie automatisiert werden oder als organisatorische Richtlinien für die Mitarbeiter dienen. Nach einem Überblick über den Business Rules Ansatz zeigt Teil II die fachliche Sicht. Dies macht beinahe die Hälfte des Buches aus. Begonnen wird mit den Zielen des Unternehmens sowie den Einflussfaktoren, die auf das Unternehmen wirken. Ein Einflussfaktor kann extern sein, wie beispielsweise Gesetze oder Konkurrenten, oder intern wie beispielsweise die IT Infrastruktur oder Mitarbeiterqualifikation. Diese Einflussfaktoren sind der Grund für den Wunsch nach Agilität, denn sie verändern das Geschäftsumfeld. Das Unternehmen muss entscheiden, wie es sich verhalten soll, und muss sich dann so schnell wie möglich anpassen. Die Geschäftsperspektive dieses Buches ist: Man muss seine Einflussfaktoren kennen. Man benötigt einen guten Prozess, um die Auswirkungen der dadurch verursachten Änderungen einzuschätzen. Die Geschäftsprozesse und IT-Systeme müssen für schnelle Anpassungen vorbereitet sein. Diese auf expliziten Geschäftsregeln aufzubauen ist ein guter Ansatz. In Teil III geht es weniger um Business Rules Technologie als viel mehr darum, wie man Business Rules Technologie einsetzen
Vorwort
V
kann, um agile Unternehmen zu schaffen. Es wird eine Anleitung gegeben, welche die Möglichkeiten der Technologie den fachlichen Anforderungen gegenüber stellt. Für Leser, die weitergehende Informationen zu Business Rules Technologie benötigen, enthält Anhang G Referenzen auf die wichtigsten Anbieter von Business Rules Technologie. Das im Buch verwendete Modell ist das „Business Motivation Model“. Es wurde durch die „Business Rules Group“ entwickelt, erstmals im Jahre 2000 publiziert und 2005 aktualisiert. Das Modell wurde in einer großen Anzahl von Projekten erfolgreich eingesetzt. Zur Publikationszeit dieses Buches durchläuft es bei der Object Management Group den Prozess zur Annahme als De-facto-Standard. Zusammenfassend kann gesagt werden: Das Buch ist eine ausgezeichnete Einführung in den Business Rules Ansatz. Es baut auf dem Bekenntnis von KnowGravity zum Business Rules Ansatz auf. Dieses Bekenntnis manifestiert sich in der Mitarbeit in der Business Rules Group, in der Unterstützung bei der Organisation der jährlich stattfindenden European Business Rules Conference und in der Gründung der Business Rules User Group Schweiz. Agilität von Unternehmen ist jedoch nur ein Aspekt des Business Rules Ansatzes. Andere Einsatzmöglichkeiten sind: Compliance; Automatisierung von Kundeninteraktionen; Web Services; Verträge und Service Level Agreements; Modernisierung von „legacy IT“ – dies ist keine abschließende Liste. Es gibt noch vieles mehr, über das Markus und Patrick schreiben könnten, und ich werde sie dazu ermutigen. John Hall Gründungsmitglied der Business Rules Group Co-Chair der European Business Rules Conference Co-Chair der OMG Regulatory Compliance Alliance (ORCA)
VI
Vorwort
Inhaltsverzeichnis
1
Einleitung ........................................................................ 1
2
Vorstellung der Fallstudie „KnowBeer“ ...................... 5
Teil I: Überblick – Der Business Rules Ansatz 3
Ausgangslage............................................................... 11 3.1 Was ist das Problem? .......................................... 11 3.2 Motivation: Sinnvolle Unternehmen ..................... 12 3.3 Agilität: Dynamische Unternehmen in dynamischem Umfeld........................................... 14 3.4 Compliance: Gesetzeskonforme Unternehmen... 16
4
Der Business Rules Ansatz ........................................ 17 4.1 Geschäftsregeln – Eine erste Annäherung.......... 17 4.2 Grundkonzepte des Business Rules Ansatzes.... 19 4.3 Das Business Motivation Model........................... 21 4.4 Forderungen des Business Rules Ansatzes........ 21 4.5 Typische Anwendungsgebiete des Business Rules Ansatzes .................................................... 22 4.6 Postulate des Business Rules Manifests............. 23 4.6.1 Geschäftsregeln sind wichtig ................ 24 4.6.2 Trennen der Geschäftsregeln von den Prozessen ...................................... 25 4.6.3 Deklarativ und wohl definiert................. 26 4.6.4 Von, durch und für die Fachleute.......... 27
5
Nutzen des Business Rules Ansatzes ....................... 29 5.1 Nutzen für das Unternehmen............................... 29 5.2 Nutzen für Fachseite ............................................ 30 5.3 Nutzen für die Informatik ...................................... 30
Inhaltsverzeichnis
VII
Teil II: Agile Unternehmen – Geschäftsanalyse 6
Unternehmenszweck ................................................... 33 6.1 Ausgangslage: Wohin führt die Reise?................ 33 6.2 Lösungsansatz: Zweckdefinition.......................... 35 6.3 Schritt für Schritt: Formulierung von Vision und Zielen.................................................................... 37 6.4 Ergebnis: Die neue Ausrichtung von KnowBeer............................................................. 38 6.5 Wie geht es weiter?.............................................. 39
7
Unternehmenseinflüsse .............................................. 41 7.1 Ausgangslage: Welchen Einflüssen ist ein Unternehmen ausgesetzt?................................... 41 7.2 Lösungsansatz: Einflussanalyse.......................... 43 7.3 Schritt für Schritt: Einschätzung von Einflüssen............................................................. 46 7.4 Ergebnis: Einflüsse auf KnowBeer und deren Einschätzung........................................................ 48 7.5 Wie geht es weiter?.............................................. 52
8
Geschäftsstrategie....................................................... 53 8.1 Ausgangslage: Wie funktioniert das Geschäft?... 53 8.2 Lösungsansatz: Strategiedefinition...................... 56 8.3 Schritt für Schritt: Erarbeitung von Strategien und Taktiken......................................................... 57 8.4 Ergebnis: Die Geschäftspolitik von KnowBeer .... 59 8.5 Wie geht es weiter?.............................................. 61
9
Projekt-Definition ......................................................... 63 9.1 Ausgangslage: Was ist ein Projekt? .................... 63 9.2 Lösungsansatz: Das Zachman Framework......... 66 9.3 Schritt für Schritt: Abgrenzung eines Projekts ..... 70 9.4 Ergebnis: Der Projektauftrag „BEGIN“................. 73 9.5 Wie geht es weiter?.............................................. 75
10 Unternehmensvokabular............................................. 77 10.1 Ausgangslage: Was ist ein Kunde? ..................... 77 10.2 Lösungsansatz: Unternehmensvokabular ........... 78 10.2.1 Präzise Definitionen .............................. 81 10.2.2 Das Faktenmodell ................................. 81 10.3 Schritt für Schritt: Erarbeitung eines Unternehmensvokabulars .................................... 87
VIII
Inhaltsverzeichnis
10.4 Ergebnis: Das Unternehmensvokabular von KnowBeer............................................................. 90 10.5 Wie geht es weiter?.............................................. 95 11 Geschäftsprozesse ...................................................... 97 11.1 Ausgangslage: Was läuft hier eigentlich?............ 97 11.2 Lösungsansatz: Geschäftsprozessmodellierung............................ 98 11.3 Schritt für Schritt: Skizzierung von Geschäftsprozessen .......................................... 103 11.4 Ergebnis: Die wichtigsten Prozesse von KnowBeer........................................................... 106 11.5 Wie geht es weiter?............................................ 109 12 Geschäftswissen........................................................ 111 12.1 Ausgangslage: Was muss überhaupt geregelt werden?.............................................................. 111 12.2 Lösungsansatz: Direktiven ................................. 112 12.3 Schritt für Schritt: Formulierung von Regelungen ........................................................ 116 12.4 Ergebnis: Auszuarbeitende Regelungen von KnowBeer........................................................... 119 12.5 Wie geht es weiter?............................................ 122 13 Geschäftsregeln ......................................................... 123 13.1 Ausgangslage: Wie hoch ist ein Rabatt? ........... 123 13.2 Lösungsansatz: Geschäftsregeln....................... 124 13.2.1 Klassifikation von Geschäftsregeln ..... 126 13.2.2 Entscheidungstabellen........................ 126 13.2.3 Formales Deutsch ............................... 129 13.2.4 Vordefinierte Fakttypen und Aktionen. 136 13.3 Schritt für Schritt: Formulierung von Geschäftsregeln ................................................. 137 13.4 Ergebnis: Regelungen von KnowBeer............... 142 13.4.1 Übersicht ............................................. 143 13.4.2 Durchsetzungsgrade........................... 144 13.4.3 Regelung „Kreditlimite“........................ 144 13.4.4 Regelung „Rabattbestimmung“........... 146 13.4.5 Regelung „Gratismuster“..................... 149 13.4.6 Regelung „Bevorzugter Kunde“ .......... 150 13.4.7 Regelung „Verkaufskompetenzen“ ..... 151 13.4.8 Regelung „Stückpreis“......................... 153 13.4.9 Regelung „Versandkosten“ ................. 154 13.5 Wie geht es weiter?............................................ 155
Inhaltsverzeichnis
IX
14 Strukturierung ............................................................ 157 14.1 Ausgangslage: Wer hat hier noch die Übersicht? .......................................................... 157 14.2 Lösungsansatz: Die Rule Map und der Inferenzbaum ..................................................... 158 14.2.1 Die Rule Map ...................................... 159 14.2.2 Der Inferenzbaum ............................... 160 14.3 Schritt für Schritt: Strukturierung von Regelungen........................................................ 161 14.3.1 Entwurf von Rule Maps....................... 161 14.3.2 Entwurf von Inferenzbäumen.............. 163 14.4 Ergebnis: Die Regel-Zusammenhänge bei KnowBeer........................................................... 164 14.5 Wie geht es weiter?............................................ 166 15 Prüfung........................................................................ 167 15.1 Ausgangslage: Was stimmt hier nicht?.............. 167 15.2 Lösungsansatz: Verifikation & Validierung ........ 169 15.2.1 Verifikation .......................................... 169 15.2.2 Validierung .......................................... 170 15.3 Schritt für Schritt: Prüfung von Regelungen ...... 171 15.4 Ergebnis: Aktualisierte Regelungen von KnowBeer........................................................... 177 15.5 Wie geht es weiter?............................................ 178 Teil III: Agile IT – Die technische Umsetzung 16 Rule Management ...................................................... 183 16.1 Ausgangslage: Was gilt nun? ............................ 183 16.2 Lösungsansatz: Rule Management ................... 185 16.2.1 Wahl der Umsetzungsstrategie........... 186 16.2.2 Verwaltung und Änderung von Geschäftsregeln.................................. 187 16.2.3 Knowledge Management .................... 189 16.3 Schritt für Schritt: Aufsetzen des Rule Managements .................................................... 192 16.4 Ergebnis: Der Änderungsprozess von KnowBeer........................................................... 194 16.5 Wie geht es weiter?............................................ 199 17 IT-Anforderungsdefinition......................................... 201 17.1 Ausgangslage: Klare Anforderungen?............... 201 17.2 Lösungsansatz: Anforderungen an die Automatisierung ................................................. 203
X
Inhaltsverzeichnis
17.3 Schritt für Schritt: Erhebung der Anforderungen.................................................... 207 17.4 Ergebnis: IT-Anforderungsdefinition .................. 209 17.4.1 Anforderungen an die Umsetzung mittels Business Rules Technologie ... 209 17.4.2 Anforderungen an das Rule Management ....................................... 211 17.5 Wie geht es weiter?............................................ 212 18 BR-Technologie.......................................................... 213 18.1 Ausgangslage: Was ist Business Rules Technologie?...................................................... 213 18.2 Lösungsansatz: BR-Technologie ....................... 214 18.2.1 Rule Execution Technologie ............... 215 18.2.2 Regel-Komplexität............................... 216 18.2.3 Logische Schlussfolgerungen ............. 217 18.2.4 „Wie“ und „Warum“ Erklärungen......... 221 18.2.5 Generische BRT Anforderungen ........ 222 18.3 Schritt für Schritt: Auswahl der Business Rules Technologie........................................................ 223 18.4 Ergebnis: Die BRT-Anforderungen von KnowBeer........................................................... 226 18.5 Wie geht es weiter?............................................ 229 19 BR-Architektur............................................................ 231 19.1 Ausgangslage: Regeln ohne Fakten?................ 231 19.2 Lösungsansatz: Architektur................................ 233 19.2.1 Business Rules Architekturen ............. 233 19.2.2 Anbindung des Faktenmodells ........... 239 19.3 Schritt für Schritt: Entwurf der BR-Architektur ... 241 19.4 Ergebnis: Die BR-Architektur von KnowBeer .... 243 19.5 Wie geht es weiter?............................................ 248 20 Implementation........................................................... 249 20.1 Ausgangslage: Eine Schwierigkeit..................... 249 20.2 Lösungsansatz: Implementationstechniken für Geschäftsregeln ................................................. 250 20.2.1 Reale Regelsprachen ......................... 250 20.2.2 Aufruf einer Business Rule Engine ..... 251 20.2.3 Implementation von Ableitungen in der Datenbank..................................... 251 20.2.4 Implementation von Einschränkungen in der Datenbank.... 252
Inhaltsverzeichnis
XI
20.2.5
Implementation von Prozessregeln in der Datenbank..................................... 253 20.3 Schritt für Schritt: Implementation der Regelungen........................................................ 254 20.4 Ergebnis: Implementation von Regelungen bei KnowBeer........................................................... 255 20.4.1 Regelung „Versandkosten“ ................. 256 20.4.2 Regelung „Stückpreis“ ........................ 258 20.4.3 Regelung „Bevorzugter Kunde“ .......... 260 20.4.4 Regelung „Rabattbestimmung“........... 260 20.4.5 Regelung „Gratismuster“..................... 262 20.4.6 Regelung „Kreditlimite“ ....................... 263 20.5 Wie geht es weiter?............................................ 266 21 Erntezeit ...................................................................... 267 21.1 Ausgangslage: Zwei Jahre später... .................. 267 21.2 Lösungsansatz: Agilität ...................................... 270 21.3 Schritt für Schritt: Evolution eines Unternehmens.................................................... 271 21.4 Ergebnis: Abonnemente in KnowBeer............... 273 21.5 Wie geht es weiter?............................................ 278 Anhänge
XII
A
Business Rules Manifest........................................... 281
B
Zusammenfassung des Entwicklungsprozesses .. 285 B.1 Phase „Geschäftsanalyse“................................. 285 B.2 Phase „Umsetzung“ ........................................... 287
C
Übersicht über die verwendeten Notationen .......... 289 C.1 Faktenmodell-Notation....................................... 289 C.2 Aktivitätsdiagramm-Notation .............................. 290 C.3 Rule-Map-Notation ............................................. 290 C.4 Inferenzbaum-Notation ...................................... 291
D
Muster & Checklisten ................................................ 293 D.1 Formen von Entscheidungstabellen .................. 293 D.2 Textschablonen für formales Deutsch ............... 295 D.3 Konzept-Bibliothek ............................................. 298 D.4 Fakttypen-Bibliothek........................................... 299 D.5 Anforderungen an Regel-Technologie............... 300
E
Meta Modelle............................................................... 307
Inhaltsverzeichnis
E.1 E.2
Business Motivation Model ................................ 307 Geschäftsregeln ................................................. 308
F
Begriffsdefinitionen ................................................... 309
G
Business Rules Technologie .................................... 319 G.1 Rule Discovery Werkzeuge................................ 319 G.2 Rule Management Werkzeuge .......................... 322 G.3 Rule Execution Werkzeuge................................ 324
H
Weitere Informationen ............................................... 331 H.1 Business Rules Standards ................................. 331 H.2 Interessante Web-Links ..................................... 332
I
Literaturreferenzen..................................................... 333
Index.................................................................................... 335
Inhaltsverzeichnis
XIII
1
Einleitung
Der Business Rules Ansatz schafft agile Unternehmen, die sich schnell und kostengünstig an die sich stets ändernde Umwelt anpassen können. Dies wird erreicht, indem das Geschäftswissen, bestehend aus dem Unternehmensvokabular und den Geschäftsregeln, explizit gemacht und falls möglich automatisiert wird. Unternehmensvokabular Ö Transparenz
Geschäftsregeln Ö Flexibilität
Abb. 1.1 Der Business Rules Ansatz
Automatisierung Ö Effizienz
Die wesentlichen Vorteile, die der Business Rules Ansatz einem Unternehmen bringt, sind
Transparenz durch Unternehmensvokabular Die fachlichen Begriffe sind klar und einheitlich definiert, alle sprechen dieselbe Sprache und verstehen sich. Flexibilität durch Geschäftsregeln Die Art und Weise, wie das Unternehmen arbeitet, kann einfach und kontrolliert geändert werden. Effizienz durch Automation Die Geschäftsregeln werden wenn immer möglich automatisch ausgeführt.
Richtig eingesetzt kann der Business Rules Ansatz jedem Unternehmen nützen. Falsch verstanden und umgesetzt führt er nur zu Enttäuschungen. Wir möchten mit unserem Buch einen Beitrag zur sinnvollen und nachhaltigen Anwendung des Business Rules Ansatzes leisten.
1 Einleitung
1
Im Umfeld des Business Rules Ansatzes werden derzeit im Rahmen der OMG und ISO verschiedene Standards entwickelt. Dies zeigt, dass es sich beim Business Rules Ansatz nicht bloß um ein modisches Schlagwort handelt, sondern um eine Idee, die dabei ist, sich permanent zu etablieren. Da es sich beim Business Rules Ansatz um einen ganzheitlichen Ansatz handelt, richtet sich unser Buch an alle, die sich im weitesten Sinne mit der Umsetzung von Unternehmenspolitik beschäftigen. Dazu gehören Manager und Betriebswirtschafter, die dafür zu sorgen haben, dass ein Unternehmen so funktioniert wie das von Verwaltungsrat und Geschäftsleitung gewünscht wird. Dazu gehören aber auch Spezialisten wie beispielsweise Compliance- und RiskManager. Schließlich sprechen wir auch Personen aus Betrieb und Informatik an, die damit beschäftigt sind, das Unternehmen zu automatisieren sowie IT-Systeme zu bauen und zu betreiben, welche die Prozesse des Unternehmens unterstützen. Da unser Buch ein sehr breites Zielpublikum anspricht haben wir es entsprechend in drei Teile gegliedert:
Teil I: Überblick – Der Business Rules Ansatz gibt einen Überblick über den Business Rules Ansatz mit seinen Zielen, Grundideen und dem Nutzen, der er bringt. Er richtet sich an diejenigen Leser, die sich eine Vorstellung von Business Rules Ansatz verschaffen wollen, ohne dabei in die Details zu gehen. Teil II: Agile Unternehmen – Geschäftsanalyse führt den Leser vom Unternehmenszweck bis hin zu den Geschäftsregeln. Es wird aufgezeigt, wie in einem Business Rules Projekt vorgegangen werden kann, um am Ende eine Beschreibung des Unternehmenswissens zu erhalten. Das Geschäftswissen wird in Form von Geschäftsprozessen, einem Unternehmensvokabular sowie expliziten Geschäftsregeln festgehalten. Damit wird die Grundlage für ein motiviertes und agiles Unternehmen gelegt und zugleich die Möglichkeit zur Automatisierung, d.h. zur Umsetzung in IT-Systemen, geschaffen. Teil III: Agile IT – Technische Umsetzung zeigt verschiedene technische Möglichkeiten auf, wie Geschäftsregeln automatisiert werden können. Dabei werden auch die Vor- und Nachteile der verschiedenen Möglichkeiten besprochen. Anhand der Fallstudie wird die Umsetzung einzelner Geschäftsregeln konkret aufgezeigt.
Ergänzt werden diese drei Teile durch eine Einleitung, die Sie gerade lesen, eine Vorstellung der Fallstudie sowie verschiedene Anhänge.
2
1 Einleitung
Die durchgängige Fallstudie der fiktiven Firma KnowBeer dient als roter Faden durch das ganze Buch. Dank dieser Fallstudie kann der Leser an konkreten Beispielen nachvollziehen, wie Geschäftsregeln erarbeitet und schließlich automatisiert werden. Jedes Hauptkapitel der Teile II und III beginnt mit einem Dialog zwischen Mitarbeitern von KnowBeer. In diesen Dialogen werden aus Praxissicht Fragen aufgeworfen, auf die im Kapitel eingegangen wird. Das folgende Kapitel 2 führt in die Fallstudie KnowBeer ein1. Wie bedanken uns bei allen, die uns beim Schreiben den Buches unterstützt und geholfen haben. Unser Dank gilt zuerst unserer Firma KnowGravity2. KnowGravity ist der führende Anbieter von produktneutraler Business Rules Beratung im deutschsprachigen Raum, Mitglied der Business Rules Group3 und Ko-Organsiator der European Business Rules Conference4. Somit lag es nahe, dass KnowGravity unser Buchprojekt aktiv unterstützt hat. Speziell erwähnen möchten wir auch die anderen KnowBodies von KnowGravity, nämlich Rolf Gubser, Christian Bühler, Beat Bourquin und Christof Meili. Last but not least geht ein spezieller Dank an unsere Familien und alle anderen, denen wir die Zeit zum Schreiben des Buches gestohlen haben. Markus Schacher und Patrick Grässle Oktober 2005
1
Unter http://www.knowbeer.com sind weitere Informationen zu diesem Buch und der Fallstudie zu finden. 2 KnowGravity Inc. ist keine fiktive Fallstudie wie KnowBeer, sondern unsere real existierende Firma. Siehe http://www.knowgravity.com 3 Siehe http:// www.businessrulesgroup.org 4 Siehe http://www.eurobizrules.org
1 Einleitung
3
2
Vorstellung der Fallstudie „KnowBeer“
Wir verwenden in unserem Buch ein durchgehendes Fallbeispiel, um die Anwendung des Business Rules Ansatzes von der Vision des Unternehmens bis zum Programmcode zu illustrieren. Dazu haben wir nach einen Beispiel gesucht, das ohne spezielle Branchenkenntnisse verstanden werden kann. Diese Suche hat uns zum Bier geführt und haben wir uns die fiktive Firma KnowBeer ausgedacht. Die Firma KnowBeer5 ist eine Schweizer Bierhandelsfirma, die Gastronomiebetriebe mit Bieren aus verschiedenen Brauereien beliefert. Die Geschäftsidee von KnowBeer ist, dass der Kunde, beispielsweise ein Landgasthof, verschiedene Flaschenbiere von verschiedenen Brauereien aus einer Hand beziehen kann. Abb. 2.1 Geschäftsidee von KnowBeer
Löwenbräu
Löwen
Calanda
Frohe Aussicht
Hotel Flora
Wädi-Bräu
Zu den Kunden von KnowBeer gehören vor allem Hotels und Restaurants, aber auch Veranstalter von Anlässen wie beispielsweise Konzerten. Die Kunden verteilen sich über die ganze Schweiz sowie das angrenzende Ausland. Besonders viele Kunden hat KnowBeer in den großen Städten sowie in Tourismus-Regionen wie dem sonnigen Wallis oder Graubünden. Die Lieferanten sind kleine und mittelgroße schweizer Brauereien. 5
Siehe http://www.knowbeer.com
2 Vorstellung der Fallstudie „KnowBeer“
5
Die Büros von KnowBeer befinden sich an bester Adresse in Zürich. Im Geschäftsjahr 2004/2005 betrug der Jahresumsatz 3.500.000 Schweizer Franken. Die Kundenbestellungen haben einen durchschnittlichen Wert von 700 Franken, sie reichen normalerweise von ein paar hundert bis zu einigen tausend Franken. KnowBeer beschäftigt Ende 2005 25 Mitarbeiterinnen und Mitarbeiter, davon 13 im Verkauf. Ein paar von ihnen werden Sie in diesem Buch antreffen, daher möchten wir sie kurz vorstellen:
6
6
Bernd Oss (CEO) Bernd Oss, der Boss von KnowBeer, ist ein visionärer und dynamischer Geschäftsleiter. Er denkt in großen Zügen und neigt dazu, Details und mögliche Probleme zu ignorieren oder mindestens zu bagatellisieren. Monika Oney (Buchhalterin) Monika Oney ist die genaue und korrekte Buchhalterin von KnowBeer. Wie es sich für diesen Berufsstand geziemt ist sie eher vorsichtig und nicht sehr risikobereit. Benno Remser (Verkaufsleiter Ausland) Benno Remser ist ein langjähriger erfahrener Verkaufsmitarbeiter, der das Geschäft in- und auswendig kennt. Er neigt zu Zynismus und ist Neuerungen gegenüber eher skeptisch eingestellt. Tina Reiber (Verkaufsleiterin Inland/Projektleiterin) Tina Reiber ist eine junge, dynamische Person, die es in kurzer Zeit zur Verkaufsleiterin gebracht hat. Sie möchte aber noch höher hinaus und hat daher die Projektleitung für die Umgestaltung von KnowBeer übernommen. Dafür hat sie unser Buch über den Business Rules Ansatz gekauft6 und möchte das Gelesene in die Praxis umsetzen. Ruth Abatt (Leiterin Einkauf) Ruth Abatt ist eine engagierte Einkäuferin mit einem weit verzweigtem Beziehungsnetz. Sie ist immer aggressiv bestrebt, Vertragskonditionen und Kosten zu Gunsten von KnowBeer auszuhandeln. Dr. Daniel Enker (Analytiker/SW-Ingenieur) Dr. Enker ist mittleren Alters und genießt den Ruf eines typischen Akademikers. Er interessiert sich für alles Neue, ist aber etwas kompliziert und penetrant.
Siehe dazu http://de.wikipedia.org/wiki/Zeitreise
2 Vorstellung der Fallstudie „KnowBeer“
Herbert „Herbie“ Acker (Programmierer) Herbie Acker ist ein Java-Programmierer der sehr viel Wissen über Applikationen besitzt. Er hat gerne die Kontrolle über die IT-Systeme und hat Angst davor, Macht zu verlieren. Er hat etwas unterentwickelte kommunikative Fähigkeiten und läuft in Birkenstockfinken herum7. Abb. 2.2 Einige Mitarbeiter der KnowBeer M. Oney
B. Oss
R. Abatt
B. Remser
Dr. D. Enker
T. Reiber
H. Acker
Wir haben uns bemüht, mit KnowBeer eine möglichst realistische Fallstudie zu erstellen. Trotz unserer Feldstudien im Biermarkt kann es aber sein, dass für Marktkenner gewisse Aspekte der Fallstudie seltsam erscheinen. Wir bitten um Nachsicht.
7
Siehe dazu http://www.birkenstock.de/
2 Vorstellung der Fallstudie „KnowBeer“
7
3
Ausgangslage
3.1 Was ist das Problem? Bevor wir 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.
3 Ausgangslage
11
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 Bestellpositio-
12
3 Ausgangslage
nen, die auf neue IT-Systeme übernommen werden, ohne hinterfragt zu werden. Bevor man aber die Motivation für eine Regel hinterfragen kann, muss man sich der Regel erst mal bewusst sein: Die Regeln müssen explizit gemacht werden. Genau dies ist ein zentraler Aspekt des Business Rules Ansatzes.
?
?
Regel
Regel
Abb. 3.1 Motivierte und unmotivierte Regel
ist abgeleitet von
Regelung unterstützt
Ziel
Motiviert durch
Einfluss
?
Ist eine Regel erst mal explizit gemacht, kann ihre Motivation überprüft werden. Somit führt der Business Rules Ansatz zu Unternehmen, die sich ihrer Motive bewusst sind, d.h. die wissen, warum sie sich so verhalten, wie sie es tun. Ein derart motiviertes Unternehmen ist in der Lage, sich von altem Ballast zu befreien und ihr Verhalten in einem kontrollierten Prozess an die sich ständig ändernden Gegebenheiten anzupassen. Dies ist ein wichtiger Bestandteil des Rule Managements. Explizit gemachte Regeln bringen dem Unternehmen außerdem eine ganze Reihe weiterer Vorteile:
Explizite Regeln schützen das Unternehmen vor Wissensverlust. Selbst wenn wichtige Mitarbeiter das Unternehmen verlassen bleibt das explizit gemachte Wissen erhalten. Explizite Regeln können auf Konsistenz und Vollständigkeit geprüft werden. Es wird möglich, Konflikte zwischen verschiedenen Regeln oder Lücken in Regeln zu entdecken. Explizite Regeln ermöglichen ein konsistentes Verhalten des ganzen Unternehmens. Es kann beispielsweise verhindert werden, dass einem Kunden in verschiedenen Filialen unterschiedliche Verkaufskonditionen angeboten werden.
3.2 Motivation: Sinnvolle Unternehmen
13
3.3 Agilität: Dynamische Unternehmen in dynamischem Umfeld Abb. 3.2 Spannungsfeld des Unternehmens
automatisiert standardisiert günstig auszuführen
individuell flexibel günstig zu ändern
Unternehmen sind in der heutigen Zeit enormen Spannungen ausgesetzt. Auf der einen Seite muss standardisiert und automatisiert werden damit billig produziert werden kann. Auf der anderen Seite verlangt der Markt nach individualisierten Produkten und Dienstleitungen, die rasch und kostengünstig an neue Anforderungen angepasst werden können. Diese beiden Trends stehen in Konkurrenz zueinander und lassen sich nur schwer gleichzeitig befriedigen. Auf der Kostenseite sind die einfachen Maßnahmen oft bereits ergriffen, gleichzeitig wächst der Druck des Marktes und erfasst auch Märkte, in denen bis anhin noch komfortable Renditen möglich waren. Ein anschauliches Beispiel sind die Preispläne der Mobilfunkanbieter. Es vergeht kaum ein Monat, in dem nicht einer der Anbieter, ein neues, auf ein bestimmtes Kundesegment zugeschnittenes Verrechnungsmodell ankündigt. Und wenn das neue Produkt erfolgreich ist und hilft, den Marktanteil zu erhöhen, dann müssen die Konkurrenten nachziehen und vergleichbare oder bessere Produkte anbieten. Für das Marketing ist diese Flexibilität noch relativ einfach erfüllbar. Anders kann es aber bei Produktion und Verrechnung der Dienstleitung aussehen. Hier werden hoch automatisierte Systeme verwendet, und deren Anpassung kann unter Umständen sehr teuer sein. Die Berechnung des Preises, den der Kunde Ende Monat zu bezahlen hat, findet in der Regel in einem IT-System statt. Idealerweise wurde bei der Entwicklung darauf geachtet, dass eine gewisse Flexibilität eingebaut wird, z.B. indem der Minuten-Preis eines Anrufes vom Zeitpunkt, an dem er durchgeführt wurde, abhängig sein kann. Man kann aber sicher sein, dass im eigenen Marketing (oder bei der Konkurrenz) Ideen zu Preisgestaltung entwickelt werden, die diese eingebaute Flexibilität sprengen. Dies kann zu grundlegenden Änderungen oder gar einer Neuentwicklung der Preisberechung führen. Dass dabei die Informatik oft nicht so schnell ist, wie es der Markt erfordert, ist wohl bekannt. Allgemein kann festgestellt werden, dass die Anpassung der ITSysteme immer teurer und aufwändiger wird und daher oft nicht in
14
3 Ausgangslage
nützlicher Frist realisiert werden kann. Das Unternehmen ist in der IT-Falle gefangen und hat sich diese Falle sogar selbst gebaut. Es ist nicht mehr das Geschäft, das die IT bestimmt; es ist die IT, die das Geschäft bestimmt. Das Unternehmen hat sich selbst in ihren ITSystemen eingemauert. Diese Gefahr besteht nicht nur in offensichtlich dynamischen Märkten. Auch in Märkten, die bisher eher ruhig waren, nimmt der Änderungsdruck zu. Folgende Änderungen sind alle nur mit einer Anpassung der IT-Systeme möglich:
neue Produkte, z.B. ein neues Versicherungspaket einer Versicherung neue Preis- und Rabattmodelle, z.B. automatische Rabatte für gute Kunden zeitlich befristete Spezialkonditionen, z.B. Bündeln von Produkten neue Vertriebswege, z.B. der Verkauf über das Internet
Allen diesen Beispielen ist etwas gemein: Time-to-Market ist wichtig oder sogar entscheidend für den Erfolg. Gleichzeitig wird die Time-to-Market immer häufiger durch die Fähigkeit bzw. Unfähigkeit zur Anpassung der IT-Systeme bestimmt. Erschwerend kommt hinzu, dass die Geschwindigkeit und der Umfang der Änderungen generell immer mehr zunehmen. Abb. 3.3 illustriert diese Zunahme der Änderungen im Geschäftsumfeld, sowohl in ihrer Häufigkeit als auch ihrem Umfang. Dies geht einher mit ständig steigenden Kosten, um die IT-Systeme diesen Änderungen anzupassen. Resultat: • Steigende IT Kosten • Reduzierte Flexibilität • Chaotische Projektabwicklung
Kosten die IT am Business auszurichten
Abb. 3.3 Zunahme der Änderungen
Fähigkeit des Unternehmens auf Änderungen zu reagieren Zeit Änderungen im Geschäftsumfeld
Natürlich ist das Problem nicht neu, und es gibt verschiedene Versuche, damit umzugehen: Durch Anwendungs-Parameter, Konfigurationsdateien oder Steuerdaten werden IT-Systeme flexibilisiert. Aber diese Ansätze greifen zu kurz, denn mit ihnen kann nur auf vorhergesehene Änderungen und nur in einem beschränkten Rahmen reagiert werden.
3.3 Agilität: Dynamische Unternehmen in dynamischem Umfeld
15
3.4 Compliance: Gesetzeskonforme Unternehmen In verschiedenen Branchen, beispielsweise bei Banken und Versicherungen, wird es immer wichtiger, dass ein Unternehmen aufzeigen kann, dass sie sich an Gesetze und andere Regelungen von Aufsichtsbehörden hält8. Beurteilt werden dabei in erster Linie nicht Einzelfälle. Vielmehr wird geprüft, ob Regelungen und Prozesse etabliert sind, die ein konformes Verhalten des Unternehmens sicherstellen. Compliance- und Risk-Manager stehen vor der Aufgabe, den Beleg zu erbringen, dass das Unternehmen gesetzeskonform arbeitet. Mit undokumentierten Regeln ist diese Aufgabe gänzlich unmöglich. Dokumentierte, interpretationsfreie, vollständige und konsistente Regeln sind eine Grundvoraussetzung, um den Nachweis der Compliance zu erbringen. Wenn diese Regeln zumindest teilweise automatisiert werden können, ist es für das Unternehmen entsprechend einfacher, deren Einhaltung sicherzustellen.
8
Gute Beispiele für solche Regelungen sind die unter dem Begriff Basel II bekannten Eigenkapitalvorschriften für Banken (Siehe http://de.wikipedia.org/wiki/Basel_II) und der Sarbanes-Oxley Act (SOX), ein US-Gesetz zur Verbesserung der Unternehmensberichterstattung (Siehe http://de.wikipedia.org/wiki/SOX).
16
3 Ausgangslage
4
Der Business Rules Ansatz
Der Business Rules Ansatz setzt sich zum Ziel, die Probleme, die in Kapitel 3 aufgezeigt sind, zu lösen. Im Folgenden werden einige Grundideen des Business Rules Ansatz erläutert, um einen groben Überblick zu geben, wie diese Ziele erreicht werden können.
4.1 Geschäftsregeln – Eine erste Annäherung Im Zentrum des Business Rules Ansatzes steht der Begriff „Business Rule“, zu Deutsch „Geschäftsregel“. Um die folgenden Kapitel zu verstehen hilft es, eine erste Vorstellung zu haben, was eine Geschäftsregel ist (um eine genaue Vorstellung zu bekommen sollte man dann das ganze Buch lesen). Beginnen wir mit ein paar Beispielen von Geschäftsregeln:
Ein guter Kunde ist ein Kunde, der in den letzten 12 Monaten einen Umsatz von mehr als 500.000 Euro. Einem guten Kunden muss bei jedem Auftrag ein Rabatt von 5% gegeben werden. Aufträge von mehr als 1.000.000 Euro müssen vom Verkaufsleiter genehmigt werden. Ein Kunde, der von uns betrieben wird, darf keine neuen Aufträge erteilen. Wenn der Lagerbestand eines Artikels unter seinen minimalen Lagerbestand fällt, dann soll der Artikel beim Lieferanten nachbestellt werden.
Alle diese Regeln haben mit dem Geschäft zu tun, sie regeln Aspekte des Geschäfts. Ganz allgemein kann man daher sagen: Eine Geschäftsregel ist eine Direktive oder Guideline, die das Geschäftsverhalten beeinflussen oder leiten soll.
4 Der Business Rules Ansatz
17
Dabei wird letztlich immer ein unternehmerisches Ziel verfolgt, das somit die Motivation für die Geschäftsregel darstellt. Abb. 4.1 zeigt, dass es einschränkende Geschäftsregeln gibt, die wie stabile Leitplanken wirken, aber auch führende Geschäftsregeln, die wie eine Mittellinie auch missachtet werden können. Abb. 4.1 Geschäftsregeln zeigen den Weg
Ziel
Motivation einschränkende Geschäftsregeln führende Geschäftsregeln
Geschäftsregeln werden üblicherweise in drei Kategorien eingeteilt: Ableitungsregeln Geschäftsregeln, die eine neue Information aus bestehenden Informationen ableiten. Beispiele: – „Eine Person ist ein bevorzugter Kunde, falls ihr Umsatz in den vergangenen 12 Monaten mindestens 500 Euro ist und sie nicht auf der schwarzen Liste steht.“ Hier wird die Information „bevorzugter Kunde“ abgeleitet. – „Eine Person ist auf der schwarzen Liste, falls eine an sie gelieferte Bestellung nicht innerhalb 30 Tagen bezahlt wurde.“ Hier wird die Information „Person auf der schwarzen Liste“ abgeleitet Einschränkungen Aussagen über das Geschäft, die immer wahr sein müssen, wie Verbote oder Gebote. Beispiele: – „Ein Kunde darf seine Kreditlimite nie überschreiten.“ – „Jede aktive Bestellung darf nur aktive Produkte enthalten.“ Prozessregeln Geschäftsregeln, die Aktionen anstoßen, verhindern oder erlauben. Beispiele: – „Wenn ein neuer Kunde eine Bestellung aufgibt, muss seine Kreditwürdigkeit geprüft werden.“ – „Guinness muss empfohlen werden, falls Heineken bestellt wird.“
18
4 Der Business Rules Ansatz
Diese Beispiele machen eins klar: Wirklich jedes Unternehmen hat Geschäftsregeln, auch wenn sie nicht immer dokumentiert sind. Und: In jedem IT-System sind Geschäftsregeln umgesetzt.
4.2 Grundkonzepte des Business Rules Ansatzes Das Business Rules Big Picture in Abb. 4.2 zeigt die Einbettung der Geschäftsregeln in den Unternehmenskontext. beeinflusst Umsetzung durch Menschen mittels Knowledge Management Ansätzen Markt & Gesetze
treiben
Geschäfts- BR Externalisierung prozesse
Geschäftsregeln
Abb. 4.2 Das Business Rules Big Picture
BR Management
Umsetzung durch IT mittels Business Rules Technolgie beeinflusst
Geschäftsregeln sind einfach da. Es sind die Regeln, die bei der Abwicklung der Geschäftsprozesse eines Unternehmens gelten. Die Gestaltung der Geschäftsprozesse und der Geschäftsregeln ist von außen getrieben, beruht aber letztlich auf Entscheidungen des Unternehmens, wie auf diese Einflüsse reagiert werden soll (man kann die Gesetze des Staates, ja sogar die Regeln der Physik ignorieren, wenn man bereit ist, die Konsequenzen zu tragen). Die Geschäftsregeln sind oft undokumentiert, manchmal sogar unausgesprochen. Trotzdem gelten sie, und ihre Verletzung kann zu Problemen führen oder gar Sanktionen nach sich ziehen. Durch die Externalisierung werden die Geschäftsregeln explizit gemacht und dokumentiert. Erst dieser Schritt erlaubt es, die Geschäftsregeln zu verwalten:
Geschäftsregeln können kommuniziert, diskutiert und angepasst werden. Widersprüche zwischen verschiedenen Geschäftsregeln können erkannt werden. Lücken in den Geschäftsregeln können erkannt werden.
4.2 Grundkonzepte des Business Rules Ansatzes
19
An dieser Stelle setzt nun das Business Rules Management ein. Die Geschäftsregeln sind eine wertvolle Ressource des Unternehmens und sollen auch entsprechend behandelt werden. Der Umgang mit ihnen muss Gegenstand eines kontrollierten Prozesses sein. Damit die explizit gemachten Geschäftsregeln eingehalten werden können, müssen sie bekannt gemacht werden. Dies gilt einerseits für die Menschen, die die Geschäftsprozesse abwickeln, andererseits für die IT-Systeme, die die Abwicklung unterstützen oder selbst Geschäftsprozesse abwickeln. Bei den Menschen werden dazu Knowledge Management Ansätze verwendet, bei IT-Systemen Business Rules Technologie. Schließlich beeinflusst die Abwicklung des Geschäfts nach den Geschäftsregeln das Umfeld. Die Preisregeln eines Unternehmens beeinflussen beispielsweise das Kaufverhalten seiner Kunden. Auf diesen Treiber reagiert das Unternehmen seinerseits wieder mit angepassten Geschäftsregeln. Der Kreis hat sich geschlossen. Im Business Rules Ansatz gibt es einige zentrale Begriffe, die immer wieder verwendet werden. Diese Begriffe werden in den Teilen II und III des Buches ausführlich eingeführt und erklärt. Hier sollen sie ein erstes Mal kurz vorgestellt werden: Unternehmensvokabular Das Unternehmensvokabular umfasst alle geschäftlich relevanten Begriffe, ihre Definitionen sowie Verknüpfungen zwischen den Begriffen. Ein einheitliches, unternehmensweites Vokabular ist nicht nur unerlässlich, um bei der Kommunikation Missverständnisse zu vermeiden, es liefert auch die Bausteine, mit denen Geschäftsregeln formuliert werden können. Geschäftsregel Eine Geschäftsregel ist eine Direktive oder Guideline, die das Geschäftsverhalten beeinflussen oder leiten soll. Sie ist konkret und direkt umsetzbar. Volatilität Die Volatilität ist eine wichtige Eigenschaft einer Geschäftsregel. Sie besagt, wie häufig eine Geschäftsregel ändert und ist damit wichtig für die optimale Umsetzung der Geschäftsregel. Durchsetzung Die Durchsetzung ist ebenfalls eine Eigenschaft einer Geschäftsregel. Sie gibt an, wie mit der Verletzung einer Geschäftsregel umgegangen werden muss. Eine Geschäftregel muss nicht immer ein Gebot oder Verbot sein, es kann auch bloß eine Empfehlung sein.
20
4 Der Business Rules Ansatz
4.3 Das Business Motivation Model Hinter den Geschäftsregeln verbirgt sich mehr als es auf den ersten Blick den Anschein hat. Die Regeln sollen nicht in der Luft hängen sondern auf der soliden Grundlage der Unternehmensmotivation basieren. Das Business Motivation Model [BRG05] zeigt den ganzen „Unterbau“ der Geschäftsregeln, angefangen bei Vision und Mission eines Unternehmens über Strategien bis hin zur Beurteilung von Stärken und Schwächen. Somit sind, wie Abb. 4.3 zeigt, die Geschäftsregeln lediglich die Spitze des Eisberges. Das Business Motivation Model wird in Teil II eingeführt. Geschäftsregeln
(Business) Motivation
Abb. 4.3 Geschäftsregeln – die Spitze des Eisbergs
4.4 Forderungen des Business Rules Ansatzes Angesichts der immer rasanteren Entwicklung der letzten Jahre postuliert der Business Rules Ansatz folgende Forderungen:
Das Geschäftswissen soll als eine extrem wertvolle Ressource eines Unternehmens behandelt werden. Das Geschäftswissen soll innerhalb eines Unternehmens konsistent und nachweisbar angewandt werden können. Das Business, nicht die Technologie, soll die treibende Kraft für die IT-Entwicklung sein. Geschäftsaktivitäten sollen so weit wie möglich automatisiert werden, d.h. von IT-Systemen ausgeführt werden. Es soll möglichst einfach sein, Geschäftswissen einem Computer „beizubringen“, d.h. es soll dazu kein spezifisches IT Knowhow benötigt werden. Änderungen in der Geschäftspolitik sollen sofort umsetzbar sein.
Zugegebenermaßen ist die vollständige Erfüllung dieser Forderungen noch Zukunftsmusik. Sie geben aber die Richtung vor, in welcher sich der Business Rules Ansatz entwickelt.
4.3 Das Business Motivation Model
21
4.5 Typische Anwendungsgebiete des Business Rules Ansatzes Ein Blick ins Internet bringt verschiedene Bereiche zu Tage, in denen der Business Rules Ansatz bereits heute eingesetzt wird. Dabei fallen vor allem Anwendungen für die Kreditvergabe, Kreditkarten, Leasing, Versicherungen und Betrugserkennung auf. Auch Telefongesellschaften, welche Geschäftsregeln sowohl für Kundensysteme mit neuen und anpassbaren Produkten, als auch für die Optimierung der Verbindungen im eigenen Netz verwenden, sind im Internet präsent. Des Weiteren werden Geschäftsregeln im e-Commerce und in B2B-Anwendungen immer häufiger eingesetzt, die z.B. die Kreditlimite eines Kunden überwachen, seine Konditionen bestimmen oder ausstehende Dokumente reklamieren. Auch in CRM-Systemen findet man den Begriff häufig, zudem werden Geschäftsregeln in Berechtigungssystemen und natürlich in vielen weiteren Bereichen, wie z.B. Gepäcksystemen oder Zeit- und Portooptimierungen für Pakete, eingesetzt. Generell kann beobachtet werden, dass Geschäftsregeln vermehrt in erfolgreichen Projekten verwendet werden und die spezifischen Eigenschaften des Business Rules Ansatzes wie Flexibilität, einfache Änderbarkeit, usw., auch im Projektbebschrieb als von großem Nutzen herausgestrichen werden können. Die Bereiche in denen der Business Rules Ansatz zum Einsatz kommen, werden immer vielfältiger. Berücksichtiget man, dass im Augenblick verschiedene Werkzeughersteller Business Rules Technologie in ihre Werkzeuge aufnehmen und auch große Softwarehersteller wie Computer Associates, Oracle, Microsoft und IBM ihre Produkte mit dieser Technologie erweitern, kann getrost eine weitere Zunahme der Projekte erwartet werden. Es werden auch vermehrt Lösungen realisiert, die nicht mit einem „großen“ Business Rules Produkt arbeiten, sondern die Geschäftsregeln, strikt getrennt von der Infrastruktur, mittels traditioneller Programmiersprachen implementieren. Dabei ist es wichtig, dass bei der Umsetzung die Denkweise des Business Rules Ansatzes die zentrale Rolle spielt.
22
4 Der Business Rules Ansatz
4.6 Postulate des Business Rules Manifests Die Grundgedanken des Business Rules Ansatzes sind im Business Rules Manifest zusammengefasst [BRG04], das in Jahre 2003 von der Business Rules Group9 erarbeitet wurde. Die Business Rules Group hatte sich zuvor bereits über 10 Jahre mit dem Thema beschäftigt und dabei den Begriff „Business Rules“ geprägt. Sie kann als eigentliche „Erfinderin“ des Business Rules Ansatzes bezeichnet werden. Das Business Rules Manifest soll
die Essenz des Business Rules Ansatz, wie sie von der Business Rules Group gesehen wird, kurz und klar festzuhalten, die Unabhängigkeit der Geschäftsregeln in der Welt der Anforderungen und Modelle zu deklarieren und die Geburt einer neuen, revolutionären Art von Geschäftsarchitektur und IT-Plattform einzuläuten.
Inzwischen hat der Business Rules Ansatz ein große Akzeptanz erfahren und wird auch im Rahmen der Object Management Group (OMG)10 weiterentwickelt, z.B. im RFP „Business Semantics for Business Rules“. Seit 2004 sind Regeln auch ein Thema beim World Wide Web Consortium (W3C)11. Im Folgenden werden einige der wichtigsten Postulate aus dem „Business Rules Manifest“ der Business Rules Group erläutert. Eine vollständige deutsche Fassung des „Business Rules Manifest“ findet sich in Anhang A dieses Buches.
9
Die wichtigsten Stationen in der Geschichte der Business Rules Group waren: - 1989–1991: GUIDE Project „Modeling Extensions“ - 1992–1996: GUIDE Project „Business Rules“ - 1995: Publikation von „Defining Business Rules – What are they Really?“ [BRG00] - 1997: Gründung der Business Rule Group (BRG) als unabhängige Organisation - 2000: Publikation der ersten Version von „The Business Motivation Model ~ Business Governance in a Volatile World“ [BRG05] - 2003: Publikation von „Business Rules Manifesto“ [BRG03], [BRG04] 10 http://www.omg.org 11 http://www.w3c.org
4.6 Postulate des Business Rules Manifests
23
4.6.1 Geschäftsregeln sind wichtig Artikel 1. Primäre statt sekundäre Anforderungen 1.1. Regeln sind Elemente erster Klasse in der Anforderungs-Welt. 1.2. Regeln sind ein essentieller und eigenständiger Teil von Geschäfts- und Technologie-Modellen. Es gibt kein Geschäft, das nicht nach bestimmten Geschäftsregeln abgewickelt wird. Für legale Geschäfte gelten zumindest die Regeln des Staates, für illegale die Regeln der Unterwelt. Neben solchen von außen gegebenen Regeln sind es aber vor allem die selbst auferlegten Geschäftsregeln, die ein Geschäft so definieren, dass die Unternehmensziele erreicht werden können. Geschäftsregeln sollen explizit formuliert werden, aber nicht versteckt in anderen Modellen, wie beispielsweise einem Prozessmodell, sondern als eigenständige Elemente. Für die Praxis bedeutet das: Es wird eine (logisch) zentrale Regelverwaltung benötigt. Nun könnte man einwenden, dass in einem flexiblem Geschäft vieles ad hoc, ohne Geschäftsregeln abläuft: Es wird in jeder Situation neu entschieden, wie sich das Unternehmen bzw. seine Mitarbeiter verhalten sollen. Fragt ein Kunde beispielsweise nach Rabatt, so wird in der konkreten Situation entschieden, ob Rabatt gewährt wird und wie hoch er sein soll. Auch wenn es hier auf den ersten Blick keine Regeln zur Rabattberechnung gibt, so ist die Höhe des Rabatts in der Praxis kaum völlig frei wählbar. Es gelten beispielsweise folgende ungeschriebene Geschäftsregeln:
Der Rabatt soll nicht größer als 100% des Bruttopreises sein der Rabatt soll auf die Dauer nicht größer als die Handelsmarge sein
Es gilt also auch in diesem Fall: Geschäftsregeln sind wichtig.
24
4 Der Business Rules Ansatz
4.6.2 Trennen der Geschäftsregeln von den Prozessen Artikel 2. Separat von Prozessen statt in ihnen enthalten 2.1. Regeln sind explizite Einschränkungen für Verhalten und/oder bieten Unterstützung für Verhalten. 2.2. Regeln sind weder Prozesse noch Prozeduren und sollen auch nicht in diesen enthalten sein. 2.3. Regeln gelten über Prozess- und Prozedurgrenzen hinweg. Es sollte ein einziges, zusammenhängendes Regelwerk für Geschäftsaktivitäten existieren, das in allen relevanten Bereichen konsistent angewandt wird. Oft sind Geschäftsregeln in Prozessen versteckt, entweder als Bestandteil der Prozessbeschreibung, an die sich die Mitarbeiter halten müssen, oder umgesetzt im IT-System, das die Abwicklung der Prozesse automatisiert. Dabei wird außer Acht gelassen, dass die meisten Geschäftsregeln nicht einem Prozess gehören, d.h. nicht nur im Kontext genau einer Aktivität gültig sind, sondern eine generelle Gütigkeit besitzen. Werden die Prozesse erweitert oder geändert, kann praktisch garantiert werden, dass in einzelnen Aktivitäten wichtige Geschäftsregeln vergessen gehen. Im Business Rules Ansatz gelten immer alle Geschäftsregeln gleichzeitig. Dass nicht bei jeder Aktivität alle Geschäftsregeln geprüft werden müssen, sondern nur diejenigen, die an dieser Stelle relevant sind, ist lediglich eine Frage der Optimierung. Für die Praxis bedeutet dies: Geschäftsregeln aus Prozessmodellen und Beschreibungen entfernen und in eine (logisch) zentrale Regelverwaltung überführen. Dabei können im Prozessmodell Verweise auf die entfernten Geschäftsregeln hinterlegt werden. Beispiel: Bestellung entgegennehmen und prüfen, ob durch die Bestellung die Kreditlimite des Kunden eingehalten wird Diese Geschäftsregel steht an einer bestimmten Stelle in der Prozessbeschreibung als Teil einer bestimmten Aktivität. Der Zeitpunkt der Überprüfung ist durch den Prozess festgelegt. Die Geschäftsregel ist eng mit der Prozessbeschreibung gekoppelt. Trennt man die Geschäftsregel vom Prozess könnte sie etwa so lauten: Beispiel: Bestellung entgegennehmen Bei der Ausführung der Aktivität sind folgende Geschäftsregeln zu beachten:
4.6 Postulate des Business Rules Manifests
25
–
R27: Die Summe aller unbezahlten Bestellungen muss kleiner sein als die Kreditlimite eines Kunden.
Auf den ersten Blick ist dies eine kleine Änderung, ja eine Haarspalterei. Aber es wird etwas Entscheidendes erreicht: Die Geschäftsregel wird als etwas Eigenes, Eigenständiges erkannt und aus der Beschreibung der Aktivität herausgenommen. Gleichzeitig wird eine Beziehung zwischen der Aktivität und der Geschäftsregel hergestellt. Dies erlaubt es, die Geschäftsregel
losgelöst von einer Prozessbeschreibung zu betrachten dieselbe Geschäftsregel mit verschiedenen Aktivitäten zu verknüpfen
Bei genauerer Betrachtung findet man eine ganze Reihe weiterer Aktivitäten, in denen dieselbe Geschäftsregel möglicherweise auch überprüft werden muss:
Änderungen einer Bestellung Änderung der Kreditlimite Erhöhung der Preise
4.6.3 Deklarativ und wohl definiert Artikel 4. Deklarativ statt prozedural 4.1. Regeln sollten deklarativ in natürlich-sprachlichen Sätzen für die Fachabteilungen ausgedrückt werden. Artikel 5. Wohldefinierte Ausdrücke statt ad hoc Formulierungen 5.1. Geschäftsregeln sollten so formuliert sein, dass sie von den Fachabteilungen auf ihre Korrektheit validiert werden können. Geschäftsregeln müssen deklarativ und wohl definiert beschrieben sein. Deklarative Regeln beschreiben das was, während prozedurale Regeln oft das wie und das wann beschreiben. Die Geschäftsregel
Die Summe aller unbezahlten Bestellungen muss kleiner sein als die Kreditlimite eines Kunden
ist einfach und klar verständlich. Sie sagt nichts darüber aus, wann die Geschäftsregel geprüft wird und auch nicht, wie genau die Überprüfung abläuft. Wohl definiert bedeutet, dass die Geschäftsregeln auf einem definierten Vokabular basieren und strukturiert beschrieben werden. Es muss klar sein, was
26
4 Der Business Rules Ansatz
ein Kunde, eine Kreditlimite, eine unbezahlte Bestellung
ist. So klar, dass es darüber keine weiteren Diskussionen gibt. Die Geschäftsregeln selbst sollten so strukturiert wie möglich formuliert sein. Allerdings besteht in der Praxis oft ein Zielkonflikt zwischen der Forderung nach Strukturiertheit (bis hin zur Automatisierbarkeit) auf der einen und der Lesbarkeit in Form von natürlich-sprachlichen Sätzen. Mit Hilfe von Satz-Schablonen und Hilfsmitteln wie speziellen Editoren wird versucht, diesen Konflikt zu entschärfen.
4.6.4 Von, durch und für die Fachleute Artikel 9. Von, durch und für das Personal der Fachabteilungen statt der IT 9.1. Regeln sollen von den Leuten der Fachabteilungen stammen, die Wissensträger sind. 9.2. Fachabteilungen sollen Werkzeuge zur Verfügung haben, die sie bei der Formulierung, Validierung und Verwaltung von Geschäftsregeln unterstützen. Geschäftsregeln werden durch das Geschäft definiert und gelten für das Geschäft. Sie gehören dem Geschäft, nicht der Informatik. Werden Geschäftsregeln auf traditionelle Weise automatisiert, geschieht das in Form von Programmcode in einem IT-System. Aus der fachlichen Geschäftsregel werden ein paar Zeilen COBOL- oder Java-Code. Solcherart implementierte Geschäftsregeln
können von Fachvertretern nicht mehr verstanden werden, können nur durch Informatiker geändert werden, unterliegen oft einem längeren Release-Zyklus.
Kurz, sie gehören nicht mehr der Fachabteilung sondern der ITAbteilung. Dies hat oft Folge, dass sich die Fachabteilung nicht mehr um die Geschäftsregel kümmert, sich der Geschäftsregel nicht mehr bewusst ist. Im schlimmsten Fall führt dies zu Zombie-Regeln die nur noch im Programmcode des IT-Systems existieren und keinerlei Bezug mehr zu fachlichen Zielen haben. Die Motivation für diese Geschäftsregeln ist verloren gegangen. Dies gilt es zu verhindern indem die Fachabteilung nicht nur für die Geschäftsregel und ihre Motivation verantwortlich bleibt, sondern auch die Mittel bekommt, diese Verantwortung wahrzunehmen. Es müssen Werkzeuge zur Verfügung gestellt werden, die es den Fachvertretern erlauben, ihre Geschäftsregeln selber zu verwalten.
4.6 Postulate des Business Rules Manifests
27
5
Nutzen des Business Rules Ansatzes
5.1 Nutzen für das Unternehmen Der Business Rules Ansatz bringt dem Unternehmen eine ganze Reihe von Vorteilen:
motivierte Unternehmen mit sinnvollen Geschäftsregeln agile Unternehmen, die sich schnell an neue Gegebenheiten anpassen können Gesetzes-konforme Unternehmen die auch belegen können, dass sie das sind
Vor allem im Bereich der Automatisierung von Geschäftsregeln gibt es sowohl aus Sicht der Fachseite als auch der IT weitere Vorteile:
Das Geschäftsvokabular und die Geschäftsregeln sind die Grundlage für ein verbessertes Verständnis zwischen Fachseite und Informatik. Im Gegensatz zu anderen Ansätzen steht dabei die fachliche Sicht im Vordergrund. Die Fachseite kann durch Änderungen der Geschäftsregeln das Verhalten der IT-Systeme anpassen, ohne dass dafür die Informatikabteilung benötigt wird. Die Informatik kann sich vor den ständig ändernden Anforderungen der Fachseite schützen, indem sie der Fachseite Modifikationsmöglichkeiten für Geschäftsregeln bietet und die Verantwortung für die Pflege an die Fachseite delegiert.
In der Praxis geht der Anstoß zur Verwendung des Business Rules Ansatzes etwa zu gleichen Teilen von der Fachseite und der Informatik aus. Auch wenn am Ende das Unternehmen als ganzes profitiert, werden von den beiden Seiten unterschiedliche Argumente für den Business Rules Ansatz ins Feld geführt. Die folgenden beiden Kapitel bieten für beide Seiten ein angepasstes Argumentarium.
5 Nutzen des Business Rules Ansatzes
29
5.2 Nutzen für Fachseite Zuoberst steht die Vision: „Business drives IT“, d.h. nicht technologische Aspekte wie Plattformen, Datenbanken oder Programmiersprachen bestimmen die Entwicklung der IT im Unternehmen, sondern die Bedürfnisse der Fachseite. Dies wird erreicht, indem die Fachseite mit dem Business Rules Ansatz die Möglichkeit erhält, das Verhalten der IT-Systeme ihren Bedürfnissen anzupassen, ohne dass dafür von der Informatikabteilung die Programme angepasst werden müssen. Die Fachseite wird unabhängiger vom meist starren Zyklus neuer Releases. Man muss nicht mehrere Monate auf den nächsten Release warten, sondern kann Änderungen rasch umsetzen. Die Fachseite holt sich damit auch die Verantwortung für das Verhalten der IT-Systeme zurück. Eine Verantwortung, die in den letzten 20 Jahren immer mehr an die Informatik übergegangen war.
5.3 Nutzen für die Informatik Für die Informatik lautet die Vision: „IT satisfies Business“, d.h. die Fachseite ist mit ihrer IT zufrieden, denn die Bereitstellung der ITSysteme erfolgt schneller, richtiger und nachhaltiger. Dies wird erreicht, indem die Informatik mit dem Business Rules Ansatz die Möglichkeit erhält, die Verantwortung für das korrekte Verhalten der IT-Systeme an die Fachseite zurückzugeben. Die Informatik kann sich auf ihre Kernkompetenz konzentrieren und stellt die Infrastruktur zur Verfügung sowie Anwendungen, deren detailliertes Verhalten durch Geschäftsregeln gesteuert wird. Dies entlastet die Informatik ungemein, denn häufig ändernde Aspekte sind in Geschäftsregeln beschrieben und nicht in irgendeinem Programm. Es ist auch nicht mehr so schlimm, wenn die Fachseite bereits während der Entwicklung ihre Anforderungen ändert; dann soll sie eben die Geschäftsregeln selbst anpassen. Schließlich ist es nicht mehr so einfach für die Fachseite, der Informatik die Schuld für falsch funktionierende IT-Systeme zu geben. Die Informatik wird dank dem Business Rules Ansatz von der Last befreit, das aktuelle Fachwissen in allen IT-Systemen korrekt abzubilden. Sie hat somit mehr Ressourcen zur Verfügung, um nachhaltige IT-Systeme zu bauen.
30
5 Nutzen des Business Rules Ansatzes
6
Unternehmenszweck
In diesem Kapitel wird aufgezeigt, wie die strategische Ausrichtung eines Unternehmens oder eines Unternehmensbereiches systematisch erarbeitet und strukturiert werden kann.
6.1 Ausgangslage: Wohin führt die Reise?
Es herrscht Aufbruchstimmung bei KnowBeer. Bernd Oss, der CEO, hat die Verkaufsleiter Tina Reiber und Benno Remser, die ChefBuchhalterin Monika Oney sowie Ruth Abatt, die Leiterin des Einkaufs, zu einem Workshop zum Thema „KnowBeer im Jahre 2010“ eingeladen. Das Unternehmen hat zwar bisher ganz gut funktioniert, ist aber in den letzten zwei, drei Jahren mehr oder weniger auf der Stelle getreten. Neue Ideen sind gefragt: In welche Richtung soll sich KnowBeer entwickeln? Welches Image soll KnowBeer haben? Wie können angestrebte Ziele erreicht werden? Diese und andere Fragen hat der eingeladene externe Moderator zu Beginn des Workshops in den Raum gestellt. In einem Brainstorming werden erste Ideen gesammelt: B. Oss: M. Oney:
T. Reiber:
Wir müssen unsere Verkaufszahlen erhöhen, und das ist nur möglich, wenn wir vermehrt ins Ausland exportieren können. Wie seht ihr das? Ich habe da Bedenken! Für Lieferungen ist Ausland müssen wir die jeweiligen gesetzlichen Vorschriften wie Mehrwertsteuerverrechnung oder Deklarationsvorschriften ganz genau kennen und berücksichtigen. Zudem sind diese von Land zu Land unterschiedlich! Ich sehe das anders, wir sollten unser Angebot ausbauen. Wenn wir nicht nur Bier, sondern auch andere Getränke wie Weine oder Mineralwasser anbieten, können wir praktisch mit der heutigen Infrastruktur unseren Umsatz vervielfachen!
6 Unternehmenszweck
33
B. Remser:
R. Abatt:
B. Oss: B. Remser:
T. Reiber: M. Oney: B. Oss:
Aber dann betreten wir ein Feld auf dem bereits ein großer Konkurrenzdruck herrscht: Denken wir beispielsweise an Lebensmittelgeschäfte oder Großhändler. Sie sind mit ihrer ausgefeilten Logistik in der Lage, dieselben Produkte anzubieten wie wir, aber zu einem Preis, gegen den wir keine Chance haben. Ein wesentlicher Unterschied von uns zu einem Großhändler ist einerseits die Abnahmemenge und andererseits das Sortiment. Da unsere Abnahmemenge im Vergleich relativ klein und zudem unstetig ist, erhalten wir von unseren Lieferanten die schlechteren Konditionen. Auf der anderen Seite ist unser Sortiment wesentlich größer. Aber wir brauchen neue Kunden, nur so können wir wieder expandieren. Und ich denke, dass wir diese zumindest im angrenzenden Ausland suchen müssen. Ich wäre schon froh, wenn wir keine bestehenden Kunden verlieren würden. Sobald ein Kunde dasselbe Bier bei einem anderen Lieferanten zu günstigeren Konditionen erhält, wird gewechselt! Ich kann den Kunden verstehen – das liegt an unseren hohen Preisen. Unsere Preise resultieren zur Hauptsache aus hohen Lagerkosten sowie den Kosten, die uns durch verschiedene Lieferarten entstehen. Das stimmt absolut! Bei einigen von diesen verschiedenen Lieferarten stimmt das Preis/LeistungsVerhältnis überhaupt nicht. Ich denke da beispielsweise an unsere Express-Lieferungen, in der von unseren eigenen Fahrern einzelne Aufträge an die Kunden ausgeliefert werden. Zudem führen andere Lieferarten wieder zu Unzufriedenheiten bei den Kunden durch lange Lieferzeiten.
Nach einer längeren Diskussion stehen als Resultat dieser Brainstorming-Runde folgende Stichworte auf dem Flip Chart:
34
6 Unternehmenszweck
Neue Ideen - mehr Kunden durch geographische Expansion und erweitertes Marktsegment - bessere Kundenbindung durch entsprechende Preispläne und faire Preise - mehr Produkte, breites Angebot - KnowBeer als "Spezialitäten-Lieferant" Ö "exotische Biere" - schnellere und ökonomischere Lieferungen - tiefere Kosten durch Auslagerung des Lieferwesens an ein Cargo-Unternehmen - zentralisierte Lager - KnowBeer als "Service Provider" - verstärkte Expansion ins Ausland (lokale Niederlassungen)
Abb. 6.1 Neue Ideen aus dem Brainstorming
Nach dieser ersten Brainstorming-Runde schlägt Tina Reiber einen strukturierten Ansatz zur Erarbeitung der neuen Ausrichtung von KnowBeer vor. Im Buch „Agile Unternehmen durch Business Rules – Der Business Rules Ansatz“ hat sie vom „Business Motivation Model“ gelesen und will die darin geschilderten Ideen nun in die Praxis umsetzen.
6.2 Lösungsansatz: Zweckdefinition
Geschäftsregeln sind Teil der Geschäftspolitik und sollten daher eine solide Grundlage haben. Das heißt, sie sollten durch die Geschäftsstrategie motiviert sein. Im Januar 2005 hat die Business Rules Group ein Dokument mit dem Titel „The Business Motivation Model – Business Governance in a Volatile World“ [BRG05] publiziert. Darin wird ein systematischer Formalismus (das „Business Motivation Model“, kurz BMM) aufgezeigt, wie sich aus einer Vision und Geschäftszielen sowie verschiedenen externen und internen Einflüssen, denen ein Unternehmen ausgesetzt ist, konkrete Handlungsrichtlinien und Geschäftsregeln ableiten lassen.
6.2 Lösungsansatz: Zweckdefinition
35
Ein erstes wichtiges Thema aus dem „Business Motivation Model“ ist die Erarbeitung des Geschäftszweckes als die Ableitung von Zielen aus einer Vision. Diese Zusammenhänge werden durch das folgende Diagramm12 illustriert: Zweck
Abb. 6.2 Geschäftszweck
besteht aus
Vision
Ziel
konkretisiert qual. Ziel quantifiziert quant. Ziel
Ein Zweck ist etwas, was ein Unternehmen zu erreichen versucht und lässt sich auf verschiedenen Ebenen beschreiben:
Vision: Eine Aussage, wie das Unternehmen in Zukunft aussehen soll und welche Leistungen es für welche Anspruchsgruppen auf welche Art und Weise erbringen wird. Sie beschreibt einen ultimativen, zukünftigen Zustand des Unternehmens ohne Hinweis, wie dieser Zustand zu erreichen ist. Ziel: Ein gewünschter Zustand, den ein Unternehmen erreichen und/oder beibehalten möchte. Ziele lassen sich hierarchisch strukturieren, d.h. ein Ziel kann in Unter-Ziele aufgeteilt werden, wodurch eine Ziel-Hierarchie gebildet wird. Qualitatives Ziel: Ein Ziel, welches von einem Unternehmen langfristig erreicht werden soll und damit einen einzelnen Aspekt der Vision konkretisiert. Quantitatives Ziel: Ein Ziel, welches sich innerhalb eines definierten Zeitraums überprüfen lässt. Ein quantitatives Ziel kann ein qualitatives Ziel quantifizieren, d.h. es kann dadurch überprüfbar gemacht werden.
12
Dieses Diagramm verwendet eine einfache Version der Faktenmodell-Notation, welche im Kapitel 10.2.2 im Detail besprochen wird.
36
6 Unternehmenszweck
6.3 Schritt für Schritt: Formulierung von Vision und Zielen
Grundlage jedes Unternehmens sollte eine einzige, kohärente und kompakt formulierte Vision sein. Basierend auf dem „Business Motivation Model“ lassen sich in folgenden Schritten eine Vision sowie daraus qualitative und quantitative Ziele ableiten13: 1. Vision formulieren Die Vision wird durch einen prägnanten Satz repräsentiert, der beschreibt, was das Unternehmen (in ferner Zukunft) als Ganzes sein will. Eine Vision soll für das Unternehmen eine große Herausforderung darstellen, da sie einen Zustand beschreibt, der weit vom bestehenden entfernt ist und gerade noch realisierbar erscheint. Wie eine solche Vision systematisch erarbeitet werden kann, sprengt allerdings den Rahmen dieses Buches. Als Hinweis sei hier lediglich als Beispiel die Soft Systems Method aufgeführt [WIL01], in welcher eine solche Vision systematisch durch einen konsens-bildenden Prozess erarbeitet wird. 1. Qualitative Ziele formulieren Einzelne Aspekte der Vision werden durch eine Menge von qualitativen Zielen konkretisiert. Ein qualitatives Ziel muss so konkret formuliert sein, dass es sich durch ein oder mehrere quantitative Ziele überprüfbar machen lässt. Wie auch die Vision, ist ein qualitatives Ziel als gewünschter Zielzustand zu formulieren und nicht als Weg, wie dieser zu erreichen ist. Als Richtgröße sollten aus einer Vision fünf bis zehn qualitative Ziele abgeleitet werden können. 3. Quantitative Ziele formulieren Für jedes qualitative Ziel wird typischerweise mindestens ein quantitatives Ziel identifiziert, welches das jeweilige qualitative Ziel überprüfbar macht. Ein quantitatives Ziel soll – messbar sein, d.h. es sollten darin numerische Angaben wie „5% Umsatzsteigerung“ oder „200.000 Kunden“ gemacht werden – zeitgebunden sein, d.h. es sollte immer mit einer absoluten Zeitangabe (z.B. „bis Ende Jahr“) oder einer relativen Zeitangabe (z.B. „innerhalb 2 Jahren“) versehen sein. 13
Auf der Web Site von KnowGravity ist CASSANDRA erhältlich, ein Werkzeug, das unter anderem die Erstellung und Verwaltung eines Business Motivation Models unterstützt. http://www.knowgravity.com/cassandra
6.3 Schritt für Schritt: Formulierung von Vision und Zielen
37
Tipp:
Die Unterscheidung zwischen qualitativen und quantitativen Zielen ist nicht essentiell; es können auch lediglich Ziele im Allgemeinen formuliert werden, welche die Vision konkretisieren. Nach Möglichkeit sollten Ziele aber so formuliert sein, dass sie im Sinne quantitativer Ziele überprüfbar sind.
Mit der Dokumentation der Vision sowie der qualitativen und quantitativen Ziele ist somit die grobe Ausrichtung der Geschäftspolitik skizziert und explizit gemacht. Seitenblick: Falls zu einem früheren Zeitpunkt bereits einmal eine Zweckdefinition erfolgt ist, kann natürlich von diesen früheren Ergebnissen profitiert werden. Die damals formulierte Vision sowie die qualitativen und quantitativen Ziele müssen bei einem neuerlichen Vorhaben lediglich überprüft und gegebenenfalls ergänzt werden. Diese Anwendung des „Business Motivation Models“ wird im Teil III dieses Buches illustriert.
6.4 Ergebnis: Die neue Ausrichtung von KnowBeer
Am Ende des Workshops war Bernd Oss zufrieden mit dem Ergebnis: In einem halben Tag wurden auf der Basis des „Business Motivation Models“ die wesentlichen Eckpunkte der neuen Ausrichtung von KnowBeer explizit und überschaubar gemacht. Im Folgenden sind die Kernelemente zusammengefasst: Vision: KnowBeer ist ein finanziell erfolgreicher und Europaweit bevorzugter Lieferant von Spezialbieren für Restaurants jeglicher Größe. Diese Vision lässt sich durch folgende qualitativen Ziele konkretisieren: 1. Wir offerieren die größte Auswahl exotischer Bier-Sorten aus aller Welt. 2. Unsere Kunden erhalten unsere Lieferungen innerhalb nützlicher Zeit. 3. Unseren Kunden werden faire Konditionen angeboten. 4. Wir möchten Marktleader in unserem Produktsegment sein. 5. Wir werden als besonders gerecht gegenüber den Ländern der dritten Welt angesehen. 6. Wir werden nicht als umweltfeindlich angesehen.
38
6 Unternehmenszweck
Diese Ziele lassen sich wiederum durch folgende quantitative Ziele quantifizieren: 1. Wir führen bis in zwei Jahren aus jedem Land der Welt mindestens ein Bier (quantifiziert das qualitative Ziel 1). 2. Bis Ende Jahr beträgt die Lieferfrist für 90% der Kundenaufträge maximal eine Woche (quantifiziert das qualitative Ziel 2). 3. Innerhalb eines Kalenderjahres verlieren wir weniger als 5% unserer Kunden (quantifiziert das qualitative Ziel 3). 4. Unsere Preise bewegen sich per sofort im Bereich von ±5% gegenüber dem Markt-Durchschnitt (quantifiziert das qualitative Ziel 3). 5. Wir verdoppeln unsere Kundenbasis innerhalb der nächsten 2 Jahre (quantifiziert das qualitative Ziel 4). 6. Wir steigern unseren Umsatz um 50% innerhalb der nächsten 2 Jahre (quantifiziert das qualitative Ziel 4).
6.5 Wie geht es weiter?
Nachdem aus der Vision die zu erreichenden Ziele abgeleitet wurden, muss untersucht werden, welche internen und externen Einflüsse auf das Unternehmen wirken und somit die formulierten Ziele beeinflussen. Diese Einflüsse sollen nun beurteilt und als Chancen, Gefahren, Stärken oder Schwächen des Unternehmens klassifiziert werden. Auch in diesem Bereich bietet das „Business Motivation Model“ hilfreiche Unterstützung, wie wir im nächsten Kapitel sehen werden.
6.5 Wie geht es weiter?
39
7
Unternehmenseinflüsse
In diesem Kapitel wird aufgezeigt, wie die internen und externen Einflüsse auf ein Unternehmen identifiziert und ihre Folgen auf die Unternehmensziele beurteilt werden.
7.1 Ausgangslage: Welchen Einflüssen ist ein Unternehmen ausgesetzt? Bis heute hat KnowBeer ausschließlich den Schweizer Markt mit Spezialbieren versorgt. In einem so gesättigten Markt gibt es für Bernd Oss aber nur zwei Möglichkeiten, das stagnierende Geschäft auszubauen: Entweder das Angebot oder das Einzugsgebiet zu erweitern. Von der Konzentration auf Spezialbiere sind eigentlich alle Beteiligten überzeugt, aber für den Schritt ins Ausland ist hauptsächlich Bernd die treibende Kraft. Beim Mittagessen hat ihm Tina Reiber etwas mehr vom „Business Motivation Model“ erzählt. Sie hat ihm erklärt, dass damit auch die relevanten äußeren und inneren Einflüsse auf ein Unternehmen systematisch identifiziert sowie deren Auswirkungen auf das Unternehmen eingeschätzt werden. Bern Oss beschließt daher, ein weiteres Mal mit Monika Oney und Benno Remser, die beide nach wie vor skeptisch gegenüber seinen Plänen sind, zusammen zu sitzen und die Vor- und Nachteile noch einmal gegeneinander abzuwägen. Am Nachmittag des folgenden Tages treffen sie sich in Bernds Büro, wobei Bernd Oss zu seiner Verstärkung auch Tina Reiber eingeladen hat: B. Oss: B. Remser:
Können wir noch einmal die Vor- und Nachteile einer Expansion ins Ausland miteinander durchgehen? Also ich bin der Meinung, dass wir mit dem Schritt ins Ausland zwar unseren Markt vergrößern, aber auch auf eine verschärfte Konkurrenzsituation treffen, mit der wir nicht vertraut sind.
7 Unternehmenseinflüsse
41
M. Oney:
B. Remser:
M. Oney:
B. Remser:
T. Reiber:
B. Remser:
T. Reiber:
Ich habe das schon einmal gesagt: Für Lieferungen ins Ausland müssen wir die jeweiligen länderspezifischen Vorschriften für die Mehrwertsteuerverrechnung oder notwendige Deklarationsvorschriften genau kennen. Ansonsten laufen wir Gefahr, dass wir vermehrt mit unerwarteten Steuernachforderungen zu rechnen haben, die wir unseren Kunden nicht weiterverrechnen können. Das ist nicht so ein Problem. Beim Thema Mehrwertsteuer im europäischen Umfeld kenne ich mich ganz gut aus. Ich habe ja bereits heute schon Kunden in Deutschland, England und den Niederlanden. Aber warum kämpfen wir dann bereits heute gegen dieses Problem? Allein im letzten Jahr mussten wir einen vierstelligen Betrag an Steuern nachzahlen! Mich hat ja niemand gefragt! Wenn jeder ausländische Auftrag bei mir vorbeigekommen wäre, hätte ich genau sagen können, welche dieser Aufträge inkorrekt deklariert wurden! Das ist doch gerade ein sehr schönes Beispiel wie das „Business Motivation Model“ Einflüsse und deren Einschätzungen unterscheidet. Die internationalen Mehrwertsteuer-Gesetze sind ein externer Einfluss, dem unser Unternehmen ausgesetzt ist. Demgegenüber schätzen wir unsere bereits vorhandenen Kenntnisse im Umgang mit der Mehrwertsteuer als eine unserer Stärken ein. Können wir noch weitere solche externe Einflüsse identifizieren? Ich denke, die ausländische Konkurrenz wird auf unser Unternehmen einen ganz deutlichen Einfluss ausüben! Und wie schätzen wir diesen Einfluss ein? Ist das eher eine Gefahr oder eine Chance für unser Unternehmen? Können wir hier irgendwelche Stärken ausspielen oder müssen wir hier spezifische Schwächen berücksichtigen?
… Im weiteren Verlauf der Sitzung hat Tina Reiber die Diskussion anhand der Konzepte für die Einflussanalyse aus dem „Business Motivation Models“ strukturiert und versprochen, die gewonnenen Erkenntnisse in einem kurzen Dokument zusammenzufassen.
42
7 Unternehmenseinflüsse
7.2 Lösungsansatz: Einflussanalyse Mit der Einflussanalyse werden einerseits verschiedene potentielle Einflüsse auf ein Unternehmen identifiziert und andererseits deren Auswirkungen auf das Unternehmen eingeschätzt. Als Einfluss wird all das bezeichnet, was Auswirkungen auf die Ziele oder Tätigkeiten eines Unternehmens verursacht. Einflüsse sind aber wertfrei, d.h. sie sind einfach da, bis jemand eine Einschätzung vornimmt, was die tatsächlichen Auswirkungen dieser Einflüsse auf das Unternehmen sind. Einflüsse werden in zwei Hauptkategorien unterteilt: externe Einflüsse und interne Einflüsse. Externe Einflüsse stammen aus dem Umfeld des Unternehmens und lassen sich anhand ihres Ursprungs wiederum wie folgt unterteilen:
Kunde: Ein Individuum oder ein Unternehmen, welches sich für Produkte und/oder Dienstleistungen des eigenen Unternehmens interessiert, solche bestellt, erhalten oder bezahlt hat. Konkurrent: Ein Unternehmen, welches versucht, sich gegenüber dem eigenen Unternehmen auf dem Markt einen Vorteil zu verschaffen. Lieferant: Ein Individuum oder ein Unternehmen, welches das eigene Unternehmen mit Waren und/oder Dienstleistungen beliefert. Partner: Ein Unternehmen, welches mit dem eigenen Unternehmen Risiko, aber auch Gewinn teilt, weil dies für beide Beteiligten vorteilhaft ist. Umwelt: Die Gesamtheit aller Umweltbedingungen oder -einflüsse, welche auf die Existenz oder die Entwicklung des eigenen Unternehmens wirken. Technologie: Neue technologische Entwicklungen aber auch technologische Einschränkungen, welche der Betrieb des eigenen Unternehmens voraussetzt oder diesen ermöglicht. Vorschrift: Eine Anordnung, welche von einer Autorität wie einer Behörden oder der Geschäftsleitung dem eigenen Unternehmen vorgeschrieben wird.
7.2 Lösungsansatz: Einflussanalyse
43
Einfluss
Abb. 7.1 Unternehmenseinflüsse
externer Einfluss
interner Einfluss
Kunde
Infrastruktur
Konkurrent
Ressource
Lieferant
Annahme
Partner
Gewohnheit
Umwelt
Streitpunkt
Technologie
Managementvorrecht
Vorschrift
Unternehmenswert
expliziter Unternehmenswert impliziter Unternehmenswert
Interne Einflüsse sind Faktoren aus dem inneren des Unternehmens, welche potentiell dessen Ziele und Tätigkeiten beeinflussen. Dazu gehören:
44
Infrastruktur: Die dem Unternehmen zur Verfügung stehende Infrastruktur sowohl technischer Art wie IT-Systeme, Maschinen, Gebäude etc. als auch logistischer Art wie zur Verfügung stehende interne und externe Dienstleistungen. Ressource: Dem Unternehmen zur Verfügung stehende Ressourcen wie Mitarbeiter, Partner, Know-how, Materialien oder Finanzen. Annahme: Etwas, das als erwiesen angenommen wird, ohne, dass ein Beweis vorhanden ist. Gewohnheit: Eine im Unternehmen übliche Praxis. Streitpunkt: Ein aktueller Diskussionspunkt oder ein Thema, zu dem unterschiedliche Ansichten im Unternehmen bestehen. Managementvorrecht: Ein Recht oder ein Privileg, welches jemandem zusteht aufgrund von Besitzverhältnissen oder seiner Position im Unternehmen. Unternehmenswert: Ein Ideal oder eine Wertvorstellung, zu welcher sich das Unternehmen explizit bekennt (expliziter Unternehmenswert) oder die eine implizite Gewohnheit darstellt (impliziter Unternehmenswert).
7 Unternehmenseinflüsse
Tipp:
Die Unterscheidung zwischen internen und externen Unternehmenseinflüssen ist nicht essentiell. Die oben beschriebene Kategorisierung von Einflüssen soll als Checkliste verstanden werden, welche hilft, in einem Brainstorming alle relevanten Einflussfaktoren zu identifizieren, die auf die Erreichung der Ziele eines Unternehmens wirken.
Sind die potentiellen externen und internen Einflüsse einmal identifiziert, müssen sie beurteilt, d.h. in Bezug zum zu erreichenden Zweck eingeschätzt werden. Eine solche Einschätzung wird typischerweise von einer Organisationseinheit vorgenommen, wobei sie einen Einfluss entweder als Stärke, Schwäche, Chance oder Gefahr14 bezüglich eines Risikos oder eines Nutzens für das Unternehmen einstuft. Somit lassen sich folgende Konzepte unterscheiden:
Stärke: Ein Vorteil oder eine spezielle Fähigkeit des Unternehmens, welche sich positiv auf die Erreichung gewisser Ziele auswirkt. Schwäche: Eine Unzulänglichkeit des Unternehmens, welche sich negativ auf die Erreichung gewisser Ziele auswirkt. Chance: Eine Situation, welche das Unternehmen zu seinem Vorteil nutzen kann. Gefahr: Eine Situation, welche eine potentielle Gefahr für das Unternehmen darstellt. mögliche Auswirkung
Zweck Risiko
Abb. 7.2 Auswirkungen
Nutzen
bezüglich Vision
identifiziert
Ziel
Einschätzung beurteilt
Einfluss
Stärke gemacht durch Schwäche interner Einfluss
Chance
externer Einfluss
Gefahr
Organisationseinheit
14
Dabei handelt es sich um nichts anderes als die bereits seit längerem aus der Betriebswirtschaft bekannte Technik der SWOT-Analyse.
7.2 Lösungsansatz: Einflussanalyse
45
Eine Einschätzung identifiziert eine mögliche Auswirkung auf das Unternehmen. Eine solche mögliche Auswirkung kann den Anstoß geben, Direktiven aufzustellen, welche die Anwendung von Strategien und Taktiken lenken. Dabei lassen sich zwei Arten möglicher Auswirkungen unterscheiden:
Nutzen: Ein Gewinn ggf. zusammen mit einer Eintretenswahrscheinlichkeit. Risiko: Ein Schadensumfang ggf. zusammen mit einer Eintretenswahrscheinlichkeit.
Die Gegenüberstellung von sämtlichen Risiken und Nutzen in Bezug auf eine Strategie oder Taktik kann die Grundlage einer detaillierten Kosten/Nutzen-Analyse bilden.
7.3 Schritt für Schritt: Einschätzung von Einflüssen Interne und externe Einflüsse können die Fähigkeit eines Unternehmens, seine Ziele zu erreichen, sowohl positiv als auch negativ beeinflussen. Diese Einflüsse werden in folgenden Schritten analysiert: 1. Unternehmenseinflüsse identifizieren Die verschiedenen Kategorien von externen und internen Unternehmenseinflüssen werden auf ihre Relevanz in Bezug auf das eigene Unternehmen untersucht und konkretisiert. Dabei ist wichtig, dass diese Einflüsse lediglich benannt und ggf. beschrieben, aber (noch) nicht bewertet werden. Bei der Identifikation von Einflüssen kann es unter Umständen sinnvoll sein festzuhalten, wer den Einfluss identifiziert hat und wann er identifiziert wurde. Dies erleichtert die spätere Rückverfolgbarkeit. Es ist durchaus möglich, dass ein Unternehmenseinfluss mehr als einer Kategorie zugeordnet werden könnte. Beispielsweise kann die Tatsache, dass Kunden vermehrt bei Großhändlern einkaufen, sowohl der Kategorie „Kunde“ als auch der Kategorie „Konkurrenz“ zugeordnet werden. In einem solchen Fall sollte versucht werden, die beiden Aspekte zu trennen und als separate Einflüsse zu dokumentieren. In unserem Beispiel könnte somit „Kunden werden immer preisbewusster“ der Kategorie „Kunde“ und „Großhändler ziehen immer mehr Kunden an“ der Kategorie „Konkurrenz“ zugeordnet werden.
46
7 Unternehmenseinflüsse
2. Unternehmenseinflüsse einschätzen Nun werden die als relevant befundenen Unternehmenseinflüsse der Unternehmensvision und hauptsächlich den qualitativen Zielen gegenüber gestellt. Für jede paarweise Kombination aus Unternehmenseinfluss und qualitativem Ziel wird nun festgelegt, ob es sich dabei um eine Stärke, Schwäche, Chance oder Gefahr handelt. 3. Auswirkungen bestimmen Für jede Stärke und jede Chance kann nun versucht werden, den potentiellen Nutzen für das Unternehmen zu quantifizieren. Andererseits kann für jede Schwäche und jede Gefahr versucht werden, das daraus resultierende potentielle Unternehmensrisiko zu bestimmen. Falls sinnvoll, lassen sich zudem sowohl für Nutzen als auch für Risiken deren Eintrittswahrscheinlichkeiten abschätzen. 4. Kosten/Nutzen analysieren Schließlich werden die gefundenen Risiken und Nutzen den Zielen aus der Zweckdefinition gegenüber gestellt. Ist ein angestrebtes Ziel von vielen möglichen Auswirkungen betroffen, so empfiehlt sich hier eine genauere Abwägung von Risiken und Nutzen. Dies kann dazu führen, dass ein bereits formuliertes Ziel wieder verworfen werden muss, da die damit verbundenen Risiken zu hoch sind. Damit sind alle relevanten Unternehmenseinflüsse identifiziert und ihre Auswirkungen auf die Ziele des Unternehmens eingeschätzt. Seitenblick: Falls zu einem früheren Zeitpunkt bereits einmal eine Einflussanalyse vorgenommen wurde, kann natürlich von diesen früheren Ergebnissen profitiert werden. Die damals gefundenen externen und internen Unternehmenseinflüsse sowie deren Einschätzungen müssen lediglich auf ihre Aktualität überprüft und gegebenenfalls ergänzt werden. Diese Anwendung des „Business Motivation Models“ wird im Teil III dieses Buches illustriert.
7.3 Schritt für Schritt: Einschätzung von Einflüssen
47
7.4 Ergebnis: Einflüsse auf KnowBeer und deren Einschätzung Die Ergebnisse des Workshops zur Identifikation der Unternehmenseinflüsse wurden in folgendem Dokument kurz zusammengefasst:
Externe Einflüsse: E1 Kunde: Der ausländische Markt ist um ein vielfaches größer als der Schweizerische Markt. E2 Vorschrift: Die geltenden Export- und Import-Gesetze müssen eingehalten werden, insbesondere die Verrechnung der Mehrwertsteuer im internationalen Umfeld. E3 Konkurrenz: Brauereien gehen Restaurants direkt an und versuchen sie mit Exklusivverträgen an sich zu binden. E4 Konkurrenz: Großhändler offerieren Biere zu sehr günstigen Konditionen. E5 Lieferant: Cargo-Unternehmen bieten Gesamtlösungen für den Europa-weiten Versand von Gütern. E6 Umwelt: Lange Transportwege führen aufgrund immer höher werdenden Treibstoffpreisen zu hohen Kosten.
Interne Einflüsse: E7 Ressource: KnowBeer hat eine relativ hohe Fluktuationsrate beim Verkaufspersonal. E8 Management Vorrecht: Landesspezifische Verkäufer weisen eine hohe Eigenkompetenz auf. E9 Impliziter Unternehmenswert: Den Mitarbeitern von KnowBeer ist der Umweltschutz wichtig. Die folgende Tabelle stellt die gefundenen Einflüsse auf KnowBeer den qualitativen Zielen aus Kapitel 6 gegenüber und identifiziert die daraus resultierenden Einschätzungen.
48
7 Unternehmenseinflüsse
Ziel
Einfluss E1: Marktgröße
1. Wir
2. Unsere
3. Unseren
4. Wir
5. Wir wer-
6. Wir
offerieren die
Kunden
Kunden
möchten
den als be-
werden nicht
größte
erhalten
werden faire
Marktleader
sonders ge-
als umwelt-
Auswahl
unsere
Konditionen
in unserem
recht gegen-
feindlich
exotischer
Lieferungen
angeboten.
Produkt-
über den
angesehen.
Bier-Sorten
innerhalb
segment sein.
Ländern der
aus aller
nützlicher
dritten Welt
Welt.
Zeit.
angesehen.
A (Stärke)
B (Gefahr)
E2: Mehr-
C (Schwäche)
wertsteuer
D (Stärke)
E3:
E (Gefahr)
Brauereien E4: Großhändler
F (Chance)
E5: CargoE6: Transport-
I (Schwäche) J (Gefahr)
wege E7: Fluktuati-
J (Gefahr) K (Schwäche)
onsrate kompetenz
F (Chance)
H (Stärke)
Unternehmen
E8: Eigen-
G (Gefahr)
L (Chance)
L (Chance)
E9:
M (Chance)
Umweltschutz
Tabelle 7.1 Einschätzung der Einflüsse
Tabelle 7.1 zeigt auf einen Blick, welche Ziele für das Unternehmen eher einfacher (diejenigen mit vielen Chancen und Stärken, beispielsweise 1) und welche eher schwieriger (diejenigen mit vielen Gefahren und Schwächen, beispielsweise 3) zu erreichen sind. Die einzelnen Einschätzungen sind in der Tabelle mit Grossbuchstaben gekennzeichnet und in der unten stehenden Legende genauer beschrieben. Zudem sind zu jeder Einschätzung jeweils die potentiellen Auswirkungen (Nutzen und Risiken) auf KnowBeer kurz umrissen.
7.4 Ergebnis: Einflüsse auf KnowBeer und deren Einschätzung
49
A: Stärke: Mit unserer Fokussierung auf Spezialbiere sprechen wir viele potentielle Restaurants und andere Lokale an, die ihren Kunden etwas Besonderes bieten wollen. Nutzen: Ausbau des Umsatzes in der Schweiz um 15 bis 20% innerhalb 2 Jahren; der angestrebte deutsche, englische und holländische Markt hat ein Potential, welches dasjenige der Schweiz langfristig um ein Vielfaches übersteigt. B: Gefahr: Die Kunden im Ausland sind sehr preisbewusst, weshalb wir mit tieferen Margen rechnen müssen. Risiko: Wir benötigen eine Minimalmarge von 7% um unsere eigenen Aufwände zu decken. Wenn wir diese unterschreiten, zehren wir von unseren Reserven, was wir uns nur für einen sehr beschränkten Zeitraum leisten können. C: Schwäche: Wir haben immer wieder Rücksendung von Lieferungen ins Ausland wegen ungenügender Deklaration. Risiko: Die Rücksendungen verursachen uns bereits heute Kosten von einigen tausend Euro. Bei einer Expansion ins Ausland würde dieser Betrag um ein Vielfaches ansteigen. D: Stärke: Einige unserer Senior-Verkäufer sind Spezialisten bezüglich Verrechnung und Rückforderung der Mehrwertsteuer. Nutzen: Wenn das vorhandene Wissen allen betroffenen Mitarbeitern zur Verfügung stehen würde, könnten wir die Kosten durch Rücksendungen praktisch sofort auf Null reduzieren. E: Gefahr: Die Konkurrenz bindet ihre Kunden stärker an sich. Risiko: Für uns besteht das Risiko, bestehende Kunden an die Konkurrenz zu verlieren und es wird schwieriger, Kunden der Konkurrenz zu beliefern. F: Chance: Großhändler bieten (im Gegensatz zu uns) keine Beratung, führen nur ein sehr kleines Sortiment und können nur beschränkte Mengen liefern. Nutzen: Wenn wir in Zukunft nicht nur Produkte, sondern auch Dienstleistungen wie Beratung anbieten, kann dies einen substantiellen Zusatzumsatz generieren. G: Gefahr: Wir müssen unsere Preise sehr knapp kalkulieren. Risiko: Wir benötigen eine Minimalmarge von 7% um unsere eigenen Aufwände zu decken. Wenn wir diese unterschreiten, zehren wir von unseren Reserven, was wir uns nur für einen sehr beschränkten Zeitraum leisten können.
50
7 Unternehmenseinflüsse
H: Stärke: Wir arbeiten in diesem Bereich bereits seit mehreren Jahren mit einem bewährten Cargo-Partner zusammen. Nutzen: Durch langfristige Verträge mit Cargo-Lieferanten können wir gegenüber dem Direktversand mehr als 20% Kosten einsparen. I: Schwäche: Wir haben wenige Kontakte zu Herstellern, welche uns kosteneffektive Direktimporte erlauben würden. Risiko: Zwischenhändler kassieren in der Regel 50 bis 80% an Marge und beziehen ihre Produkte von den Produzenten zu Billigstpreisen. Selbst wenn wir nur von Zwischenhändlern, die sich zu fairen Konditionen bekennen, einkaufen, entstehen um 20 bis 50% höhere Kosten gegenüber Direktimporten. J: Gefahr: Aufgrund von Umweltschutzüberlegungen müssen Transporte minimiert werden. Risiko: Wenn wir allzu sorglos unsere Biere aus aller Welt importieren, kann dies wegen übermäßiger Energieverschwendung und Umweltverschmutzung zu einem schlechten Image führen. Dies wiederum kann zu einer Abwanderung umweltbewusster Kunden bewirken. K: Schwäche: Die hohe Fluktuationsrate beeinflusst die Qualität der Kundenbeziehung sowie die Konsistenz in der Abwicklung von Verkaufsgeschäften. Risiko: Unsere gegenwärtige Fluktuationsrate von gegen 20% führt dazu, dass rund 5% unserer Kunden unzufrieden mit der Konstanz und Konsistenz der Kundenbeziehung sind. L: Chance: Die landesspezifischen Verkäufer können die optimale Bearbeitung „ihres“ Marktes selber gestalten. Nutzen: Bei Berücksichtigung von landesspezifischen Gegeben- und Gepflogenheiten können mittels gezielter Sonderaktionen substantielle Mehrumsätze erreicht werden. M: Chance: Die Rücksichtnahme auf Belange des Umweltschutzes kann als Marketing-Argument verwendet werden. Nutzen: Wir können das Marktsegment der explizit umweltbewussten Kunden erschließen und dadurch Mehrumsätze generieren.
7.4 Ergebnis: Einflüsse auf KnowBeer und deren Einschätzung
51
7.5 Wie geht es weiter? Nachdem aus der Vision die zu erreichenden Ziele abgeleitet und die auf das Unternehmen einwirkenden Einflüsse identifiziert und eingeschätzt wurden, muss überlegt werden, wie mit diesen Einflüssen umgegangen werden soll. Im folgenden Kapitel wird aufgezeigt, wie basierend auf dem „Business Motivation Model“ Strategien und Taktiken gefunden werden können, um etwaige Stärken oder Chancen zu nutzen, beziehungsweise Schwächen und Gefahren zu reduzieren.
52
7 Unternehmenseinflüsse
8
Geschäftsstrategie
In diesem Kapitel wird aufgezeigt, wie die identifizierten und eingeschätzten Unternehmenseinfüße verwendet werden, um daraus Strategien und Taktiken zur Erreichung der Unternehmensziele zu erarbeiten.
8.1 Ausgangslage: Wie funktioniert das Geschäft?
Am Umtrunk am Freitagabend hat Bernd Oss von Tina Reiber noch mehr über das „Business Motivation Model“ gehört. Damit ließen sich nicht bloß die Unternehmensziele formulieren sowie Einflüsse identifizieren und einschätzen, sondern auch Strategien definieren, wie am Besten mit diesen Einflüssen umgegangen werden soll. Übers Wochenende ließ die Idee der Strategiedefinition Bernd keine Ruhe. Am Montagmorgen lässt Bernd einen möglicht baldigen Termin für einen weiteren Workshop finden, diesmal für die gemeinsame Ausarbeitung der Geschäftsstrategie im Hinblick auf die Expansion ins Ausland. Eingeladen werden wiederum Benno Remser und Monika Oney. Da dies sich bisher bewährt hat, soll Tina Reiber wieder die Moderation übernehmen. Bereits drei Tage später treffen sich alle Eingeladenen zu einem ganztägigen Strategie-Workshop. Als Vorbereitung hat Tina Reiber auf einem Flip Chart bereits die Ziele des Workshops und die Agenda formuliert.
8 Geschäftsstrategie
53
Abb. 8.1 Begrüßung zum StrategieWorkshop
Willkommen zum Strategie-Workshop
Ziele des Workshops - Wir wissen, wie wir unsere Ziele erreichen - Wir wissen, wie wir mit Einflüssen umgehen - Was wir als nächstes anpacken sollten Agenda - Was ist unsere Mission? - Welche Strategien verfolgen wir? - Welche Taktiken nutzen wir? - Kosten/Nutzen Analyse
Nach der Begrüßung und der Vorstellung der Ziele und des Ablaufs des Workshops wird fast eine Stunde über die Mission von KnowBeer gerungen. Danach steht folgendes Statement auf dem Flip Chart: Mission: KnowBeer verkauft verschiedenste Biersorten sowie Bier-bezogene Dienstleistungen an Restaurants in allen Ländern Europas. Nach einer kurzen Kaffeepause beginnt die eigentliche Diskussion zur Strategie von KnowBeer: T. Reiber:
B. Oss:
54
Vor zwei Wochen haben wir unsere Vision und dazu die zu erreichenden Ziele formuliert. Nun geht es darum zu überlegen, wie wir diese Ziele erreichen wollen. Beginnen wir mit dem Ziel „Wir offerieren die größte Auswahl exotischer Bier-Sorten aus aller Welt“: Welche Strategien können wir anwenden, um das Ziel zu erreichen? Wir müssen aus jedem Land der Welt mindestens ein Bier in unserem Sortiment haben!
8 Geschäftsstrategie
T. Reiber: B. Oss:
Achtung: Dies ist nicht eine Strategie, sondern ein anderes Ziel! Strategien beschreiben Tätigkeiten, wie Ziele zu erreichen sind. Dann müssen wir eben mit Brauereien aus der ganzen Welt Verträge abschließen, um unsere Produkte zu beziehen!
Nach einiger Zeit diskutiert man Werbemaßnahmen, um das Ziel „Wir möchten Marktleader in unserem Produktsegment sein“ zu erreichen. Monika Oney schlägt eine Serie von TV-Werbespots in Deutschland, England und Holland vor, um den Namen „KnowBeer“ auch im Ausland bekannt zu machen. B. Remser:
T. Reiber:
M. Oney: B. Remser:
T. Reiber: B. Remser: M. Oney: T. Reiber: B. Remser:
Hat jemand gestern Abend Fernsehen geschaut? Da lief ein Werbespot von FASTBeer, unserem Hauptkonkurrenten. Auch dabei scheint es sich um eine internationale Kampagne zu handeln, mit der sie den Slogan „Fassbier von FASTBeer“ propagieren. Da sind die uns also wieder einmal zuvorgekommen... Haben wir nicht die Konkurrenz als eine wichtige Einflussgröße auf unsere Ziele identifiziert? Wir müssen also eine andere Strategie finden, um unseren Namen bekannt zu machen. Hat jemand eine Idee? Wir könnten unsere potentiellen Kunden proaktiv angehen und ihnen günstige Erst-Angebote offerieren! Das ist doch viel zu aufwändig, jeden Kunden persönlich anzugehen! Ich schlage viel mehr vor, in großflächigen Aktionen Gratismuster exotischer Biere an Endverbraucher abzugeben. Dies sollte dann wiederum eine erhöhte Nachfrage bei unseren eigentlichen Kunden generieren. Wie stellst du dir solche Aktionen konkret vor? Wir könnten uns beispielsweise als Sponsoren an Rockkonzerten beteiligen und Gratismuster abgeben. Oder wir könnten solche Gratisaktionen auch in großen Einkaufszentren durchführen! Ja genau! Dies sind alles verschiedene Taktiken, um unsere Strategie der großflächigen Gratisaktionen zu implementieren! Solche Aktionen müssen wir aber auf jeden Fall mit unseren Lieferanten gemeinsam angehen, damit wir uns die Kosten teilen können. Andernfalls können wir uns solche Maßnahmen gar nicht leisten.
8.1 Ausgangslage: Wie funktioniert das Geschäft?
55
Zum Schluss des Workshops verspricht Tina Reiber wiederum, die gewonnenen Erkenntnisse in einem kurzen Strategiedokument zusammenzufassen.
8.2 Lösungsansatz: Strategiedefinition
In der Einflussanalyse wurden externe und interne Einflüsse des Unternehmens identifiziert und es wurde eingeschätzt, wie diese Einflüsse auf Vision und Ziele des Unternehmens wirken. In der Strategiedefinition wird nun erarbeitet, wie das Unternehmen auf diese Einflüsse am besten reagieren soll. Auch hier stellt das „Business Motivation Model“ wieder den Zusammenhang zwischen diesen Konzepten her. Abb. 8.2 Geschäftsstrategie
Einfluss
Einschätzung: eine Beurteilung, wie ein Einfluss die Anwendung eines Mittels zur beurteilt Erreichung eines Zwecks beeinflusst
Zweck
Einschätzung
bezüglich
beeinflusst
Mittel
Vision
Ziel unterstützt
erfüllt
Mission
Handlungsweise
Direktive
konkretisiert
Strategie
besteht aus
implementiert
Taktik
Um einen Zweck, ausgedrückt durch eine Vision sowie ihre unterstützenden Ziele, erreichen zu können, muss ein Unternehmen entsprechende Mittel anwenden. Ein Mittel ist somit eine Fähigkeit oder eine Methode, mit der sich ein Zweck erreichen lässt. Dabei kommen folgende Konzepte zur Anwendung:
56
Mission: Eine langfristige operationelle Aktivität eines Unternehmens, um eine Vision zu erfüllen. Sie beschreibt die Hauptfunktion des Unternehmens und wird durch eine Menge von Strategien konkretisiert. Handlungsweise: Eine Menge von Aktivitäten, die eine einzelne Dimension eines Unternehmens (Dinge, Prozesse, Orte, Leute, Timing oder Motivation) beeinflussen, um die Erreichung eines spezifischen Ziels zu unterstützen. Eine Handlungsweise kann
8 Geschäftsstrategie
in Form einer Strategie oder einer Taktik auftreten und sie kann seinerseits aus weiteren Handlungsweisen zusammengesetzt sein, wodurch eine hierarchische Struktur entsteht. Eine Handlungsweise wird durch eine Geschäftsaktivität realisiert. Strategie: Eine einzelne Komponente der Konkretisierung einer Mission, mit der die Erreichung eines oder mehrerer Ziele angestrebt wird. Taktik: Eine Implementierung einer Strategie, die auf die Erreichung eines oder mehrerer quantitativer Ziele ausgerichtet ist. Direktive: Dasjenige Wissen, das bei der Anwendung einer Handlungsweise (d.h. einer Strategie oder Taktik) zur Anwendung kommen muss, damit sie erfolgreich umgesetzt werden kann. Direktiven werden im Kapitel 12 weiter detailliert.
8.3 Schritt für Schritt: Erarbeitung von Strategien und Taktiken
Ist erst einmal eine gemeinsame und aussagekräftige Vision gefunden, lassen sich daraus basierend auf dem „Business Motivation Model“ in folgenden Schritten die Mission des Unternehmens sowie Strategien und Taktiken zu deren Umsetzung ableiten: 1. Mission formulieren Als erstes wird die Unternehmensmission als laufende operationelle Aktivität des Unternehmens zur Erreichung der Unternehmensvision formuliert. Somit beschreibt die Mission kurz und prägnant, was das Unternehmen eigentlich tut. Wie eine Vision, wird auch eine Mission relativ allgemein auf der Ebene des Gesamtunternehmens formuliert. Eine Mission sollte mindestens aus folgenden drei Komponenten zusammengesetzt sein: – einem Aktionsteil, z.B. „offerieren“, „produzieren“ oder ähnliches – einem Service- oder Produkt-Teil, z.B. „Bier“, „Mietwagen“ oder ähnliches – einem Markt- oder Kunden-Teil, z.B. „Hauseigentümer“, „Auto fahrende Biertrinker“ oder ähnliches 2. Strategien erarbeiten Ausgehend von einzelnen qualitativen Zielen werden Strategien formuliert, wie diese Ziele zu erreichen sind. Dazu sind die Einschätzungen der Einflussgrößen zu berücksichtigen, welche auf diese Ziele wirken. Eine Strategie ist mehr als bloß eine Fähigkeit oder Kompetenz eines Unternehmens. Sie ist ein Ansatz oder Weg, der vom Unternehmen als richtig akzeptiert wurde,
8.3 Schritt für Schritt: Erarbeitung von Strategien und Taktiken
57
um gewisse Ziele unter den gegebenen Einflüssen zu erreichen. Eine Strategie bildet eine einzelne Komponente des Planes, mit dem eine Mission umgesetzt wird und soll die Erreichung von Geschäftszielen unterstützen. Die Menge aller Strategien definiert somit den Plan, wie die Mission in die Praxis umgesetzt werden soll. Für jedes qualitative Ziel sollte mindestens eine Strategie identifiziert werden können, wie dieses zu erreichen ist. Da Strategien oft auf die Erreichung mehrerer Ziele hinwirken, ist es durchaus möglich, dass weniger Strategien definiert sind, als qualitative Ziele formuliert wurden. 3. Taktiken erarbeiten Zur Detaillierung von Strategien werden Taktiken gesucht, mit denen sich die formulierten Strategien realisieren lassen. Eine Taktik ist typischerweise auf die Erreichung eines quantitativen Ziels ausgerichtet, welches zur Überprüfung des Erfolgs der Taktik verwendet werden kann. Somit entspricht die Anzahl Taktiken mindestens der Anzahl qualitativer Ziele, d.h. es sollte eine Größenordnung von zehn bis zwanzig Taktiken gefunden werden können. 4. Kosten/Nutzen analysieren Schließlich werden die gefundenen Strategien und Taktiken den möglichen Auswirkungen (Risiken und Nutzen) aus der Einflussanalyse gegenüber gestellt. Ist eine Strategie oder Taktik von vielen möglichen Auswirkungen betroffen, so empfiehlt sich hier eine genauere Abwägung von Risiken und Nutzen. Dies kann dazu führen, dass eine Strategie oder Taktik wieder verworfen werden muss, da ihre Risiken zu hoch sind. Tipp:
Die Unterscheidung zwischen Strategie und Taktik ist oft schwierig. Generell sind Strategien allgemeiner und langfristiger formuliert als Taktiken. Es kann durchaus vorkommen, dass etwas das ursprünglich als Strategie formuliert wurde im Rahmen der weiteren Erarbeitung plötzlich eher als Taktik eingestuft wird und umgekehrt.
Mit der Dokumentation der Mission sowie den zu deren Umsetzung notwendigen Strategien und Taktiken ist die Geschäftspolitik nun in groben Zügen skizziert und explizit gemacht.
58
8 Geschäftsstrategie
Seitenblick: Falls zu einem früheren Zeitpunkt bereits einmal eine Strategiedefinition vorgenommen wurde, kann natürlich von diesen früheren Ergebnissen profitiert werden. Die damals formulierte Mission sowie die daraus abgeleiteten Strategien und Taktiken müssen bei einem neuerlichen Vorhaben lediglich überprüft und gegebenenfalls ergänzt werden. Diese Anwendung des „Business Motivation Models“ wird im Teil III dieses Buches illustriert.
8.4 Ergebnis: Die Geschäftspolitik von KnowBeer
Im Folgenden sind die wesentlichen Eckpunkte der Geschäftspolitik von KnowBeer als Ergebnis des Strategie-Workshops zusammengefasst: Mission: KnowBeer verkauft verschiedenste Biersorten sowie Bier-bezogene Dienstleistungen an Restaurants in allen Ländern Europas. Diese Mission lässt sich durch folgende Strategien konkretisieren (in Klammern sind jeweils die Ziele aus Kapitel 6 angegeben): 1. Wir schließen mit Brauereien aus der ganzen Welt Verträge ab, um unsere Produkte zu beziehen (unterstützt das qualitative Ziel 1). 2. Wir führen ein zentrales Lager in Deutschland, an dem alle von KnowBeer angebotenen Sorten vorrätig sind (unterstützt das qualitative Ziel 2). 3. Wir schließen Zusammenarbeitsverträge mit einem führenden Cargo-Unternehmen ab, welches ganz Europa bedient (unterstützt das qualitative Ziel 2). 4. Wir minimieren unsere Kosten (und damit auch diejenige für unsere Kunden), indem wir unsere Produkte im Direktvertrieb anbieten (unterstützt das qualitative Ziel 3). 5. Kunden, die ein großes Absatzvolumen haben, profitieren von Vergünstigungen (unterstützt das qualitative Ziel 3). 6. Wir gehen neue potentielle Kunden proaktiv an und bieten ihnen günstige Erst-Angebote (unterstützt das qualitative Ziel 4). 7. Wir versuchen, bisher noch nicht bediente europäische Länder neu zu erschließen (unterstützt das qualitative Ziel 4). 8. Wir geben in großflächigen Aktionen Gratismuster exotischer Biere aus aller Welt ab (unterstützt das qualitative Ziel 4).
8.4 Ergebnis: Die Geschäftspolitik von KnowBeer
59
Diese Strategien werden durch folgende Taktiken umgesetzt (in Klammern sind jeweils die implementierten Strategien sowie die Ziele aus Kapitel 6 angegeben): 1. Wir beobachten aktiv den weltweiten Biermarkt bezüglich Neuerscheinungen (implementiert Strategie 1 und verfolgt das quantitative Ziel 1). 2. Wir schließen Handelsverträge mit Brauereien von Spezialbieren aus der ganzen Welt ab (implementiert Strategie 1 und verfolgt das quantitative Ziel 1). 3. Der Lagerbestand des Zentrallagers soll pro Produkt auf den Durchschnittsbedarf von zwei Wochen ausgerichtet sein (implementiert Strategie 2 und verfolgt das quantitative Ziel 2). 4. Kundenlieferungen aus dem Zentrallager werden alle 2 Tage gebündelt versandt (implementiert Strategien 2, 3 sowie 4 und verfolgt das quantitative Ziel 2). 5. Die Zuverlässigkeit des Cargo Partners wird monatlich überprüft (implementiert Strategien 3 sowie 4 und verfolgt das quantitative Ziel 2). 6. Wir bieten unseren Kunden Rabattstaffelungen in Abhängigkeit der einzelnen Bestellmenge sowie auf der Basis des Jahresumsatzes, den wir mit ihnen machen (implementiert Strategie 5 und verfolgt das quantitative Ziel 3). 7. Wir umgehen Zwischenhändler und beziehen unsere Biere via Direktimporte (implementiert Strategie 1 und verfolgt die quantitativen Ziele 1 und 4). 8. Durch regelmäßige Vertreterbesuche in allen zu bedienenden Ländern treten wir mit potentiellen Kunden in Kontakt (implementiert Strategien 6 sowie 7 und verfolgt die quantitativen Ziele 5 und 6). 9. Erstkunden bieten wir 20% Sonderrabatt bei der ersten Bestellung (implementiert Strategie 6 und verfolgt die quantitativen Ziele 5 und 6). 10. Wir positionieren uns in unserer Werbung gegenüber der Konkurrenz als DIE Spezialisten für exotische Biere jeglicher Art (implementiert Strategie 6 und verfolgt das quantitative Ziel 1). 11. Wir beteiligen uns an Rockkonzerten als Sponsoren geben dafür Gratismuster exotischer Biere ab (implementiert Strategie 8 und verfolgt das quantitative Ziel 5). 12. Wir geben in großen Einkaufszentren Gratismuster exotischer Biere ab (implementiert Strategie 8 und verfolgt das quantitative Ziel 5). 13. Wir geben bei größeren Bestellungen Gratismuster noch wenig bekannter Biere ab (implementiert Strategie 8 und verfolgt das quantitative Ziel 3).
60
8 Geschäftsstrategie
Diese Strategien und Taktiken werden nun in einem Strategiepapier dokumentiert welches allen Mitarbeitern von KnowBeer zugesandt wird.
8.5 Wie geht es weiter?
Nun ist einerseits die Ausrichtung des Unternehmens durch die Vision sowie die zu erreichenden Ziele formuliert und andererseits sind Strategien und Taktiken identifiziert, wie diese Ziele unter den bestehenden Unternehmenseinflüssen am Besten zu erreichen sind. Damit ist es höchste Zeit, ein Projekt zu definieren, um den ganzen Plan in die Realität umzusetzen. Dies ist Inhalt des nächsten Kapitels.
8.5 Wie geht es weiter?
61
9
Projekt-Definition
In diesem Kapitel wird aufgezeigt, wie ein Projekt aufgesetzt werden kann, das das Unternehmen in die Lage versetzt, die Geschäftsstrategie umzusetzen. Die Durchführung des Projektes wird in den folgenden Kapiteln des Teils II (Konzeption) sowie im Teil III (technische und organisatorische Umsetzung) beschrieben.
9.1 Ausgangslage: Was ist ein Projekt?
Bernd Oss hat Tina Reiber mit der Leitung des Projekts „BEGIN: BEer Governance INternational“ beauftragt. Ausgangslage ist die neue Geschäftspolitik, die kürzlich von KnowBeer erarbeitet wurde. Das Ziel des Projektes soll sein, diese Geschäftspolitik zu konkretisieren und die Grundlage dafür zu erarbeiten, dass KnowBeer als Unternehmen entsprechend der neuen Geschäftspolitik umgestaltet werden kann. Diese Umgestaltung kann letztlich auch die Betriebsorganisation und die IT-Systeme umfassen. Bernd Oss hat Benno Remser und Ruth Abatt vorerst als weitere Projektmitglieder vorgeschlagen, in einer späteren Phase sollen auch Mitarbeiter der ITAbteilung dazu stoßen. Tina hat die Projektmitglieder zu einem Kick-off-Meeting eingeladen. Nach einer kurzen Einleitung durch Tina Reiber entbrennt sofort eine Diskussion über den Umfang des Projektes: B. Remser: R. Abatt: T. Reiber:
Mir ist einfach nicht ganz klar, was wir nun konkret tun sollen. Unsere Firma umgestalten, das kann alles Mögliche bedeuten. Also für mich tönt das auch etwas abgehoben. Ich für meinen Teil würde einfach versuchen, die Geschäftspolitik bei meiner Arbeit zu leben. So einfach ist das nun auch wieder nicht! Einige der Taktiken, die wir festgelegt haben, müssen schon noch etwas konkretisiert werden. Und es wird wohl niemand widersprechen, wenn ich behaupte, dass
9 Projekt-Definition
63
B. Remser:
T. Reiber
R. Abatt: T. Reiber:
nicht alle unsere internen Abläufe zur neuen Geschäftspolitik passen. Das stimmt! Wenn ich da an die Art und Weise denke, wie wir heute unsere ausländischen Kunden beliefern, das ist mit viel Handarbeit und Papierkram verbunden. Handarbeit, das ist ein gutes Stichwort. Schließlich sollten wir uns alle von routinemäßiger Handarbeit entlasten, wenn wir wachsen möchten. „Standardisierung“, „Automatisierung“ und „Flexibilität“ heißen da die Zauberworte. Dann ist das Ziel des Projektes die möglichst umfangreiche Automatisierung? So würde ich das nicht formulieren. Ich würde eher sagen, wir müssen uns vorstellen, wie unsere Firma idealerweise funktionieren sollte, damit die Geschäftspolitik am besten umgesetzt werden kann. Und diese Vorstellung müssen wir dann dokumentieren.
Abb. 9.1 Die Projektausgangslage
Projekt Kick-off BEGIN Ausgangslage - neue Geschäftspolitik Ziele des Projektes - Geschäftspolitik konkretisieren - KnowBeer so umgestalten, dass die Geschäftspolitik umgesetzt werden kann Termin - bis Ende Jahr Projektmitarbeiter - Tina Reiber (PL) - B. Remser - R. Abatt
64
9 Projekt-Definition
B. Remser: T. Reiber:
R. Abatt:
Das klingt ja schön und gut und ich hätte da auch schon ein paar Ideen dazu, aber wie sollen wir den diese Vorstellung aufschreiben? Ich habe ja bereits einmal das Buch „Der Business Rules Ansatz – Agile Unternehmen durch Business Rules“ erwähnt. Dort wird, sozusagen als Raster zur Beschreibung eines Unternehmens, das Zachman Framework verwendet. Das was?
Das Zachman Framework ist, wie Tina Reiber richtig sagt, ein Raster zur umfangreichen und vollständigen Beschreibung eines Unternehmens. Es kann als eine Art Checkliste verwendet werden die sicherstellt, dass alle wichtigen Dimensionen des Unternehmens bedacht wurden. Tina erklärt das den Teilnehmern der Sitzung und kommt dann wieder auf das Projekt zu sprechen: T. Reiber:
B. Remser: T. Reiber:
R. Abatt: T. Reiber:
Um im Zachman Framework zu bleiben: Unser Projekt BEGIN soll die Abgrenzung und das Unternehmensmodell, also die ersten beiden Zeilen des Frameworks, erarbeiten. Und das sollen wir für das ganze Unternehmen, mit Personalbüro, Buchhaltung und 1.-Hilfe-Station tun? Das dauert ja Jahre! Natürlich nicht! Der erste Schritt besteht ja gerade darin, das Projekt abzugrenzen. Wir halten fest, welche Bereiche des Unternehmens wir behandeln wollen und welche nicht. Das ist genau der Inhalt der Abgrenzung. Zu einer Projekt-Definition gehört aber noch etwas mehr als das. Hmm, das stimmt. Die Abgrenzung gemäß Zachman grenzt den Gegenstand des Projektes ein, sagt aber nichts über das Projekt selbst aus. Ich werde wohl am besten einen vollständigen Projektauftrag schreiben, obwohl das eigentlich unser Boss hätte tun sollen.
Am Ende des Kick-Off-Meetings herrscht Einigkeit darüber, dass sowohl der Gegenstand des Projektes als auch das Projekt selbst abgegrenzt werden müssen. Ersteres soll mit Hilfe des Zachman Frameworks geschehen, letzteres in einem Projektauftrag.
9.1 Ausgangslage: Was ist ein Projekt?
65
9.2 Lösungsansatz: Das Zachman Framework
Das Zachman Framework [ZAC87], [ZAC03] ist eine Matrix, in welcher verschiedene Dimensionen eines Unternehmens (die Kolonnen) aus unterschiedlichen Perspektiven (die Zeilen) beschreiben werden (siehe Abb. 9.6). Dabei dient das Framework als eine Art Checkliste, die sicher stellt, dass nicht vergessen geht. Orte Wo
Abb. 9.2 Die Dimensionen eines Unternehmens
Aufgaben Was Dinge Womit
Ressourcen Wer Ereignisse Wann Motive Warum
Abb. 9.2 zeigt die 6 Dimensionen, unter denen ein Unternehmen im Zachman Framework betrachtet wird:
66
Womit? Beschreibt die Dinge, die für die Abwicklung des Geschäfts wichtig sind. Diese Dinge werden auch Geschäftsobjekte genannt und sind gute Kandidaten für die spätere Umsetzung in geschäftsunterstützenden IT-Systemen. Was? Beschreibt die Aufgaben, welche ausgeführt werden müssen, um die Ziele des Geschäfts zu erreichen. Sie werden auch als Geschäftsaktivitäten bezeichnet. Wo? Beschreibt die Orte an denen Akteure die Geschäftsaktivitäten ausführen. Dabei kann es sich um geographische Orte sowohl innerhalb aus auch außerhalb des Unternehmens handeln. Auch das Internet kann eines dieser Orte sein. Sie werden auch Geschäftsorte genannt. Wer? Definiert die Ressourcen, welche die Geschäftsaktivitäten ausführen. Dies können sowohl Menschen oder IT-Systeme als auch abstraktere Ressourcen, wie zum Beispiel Organisationseinheiten sein.
9 Projekt-Definition
Wann? Definiert die Ereignisse, die als Reaktion Geschäftsaktivitäten auslösen. Sie werden auch Geschäftsereignisse genannt. Warum? Beschreibt die Motive, also Ziele sowie Mittel und Zweck des Geschäfts, und somit auch die Gründe für seine Existenz oder sein Tun.
Neben diesen Dimensionen, unter denen ein Geschäft betrachtet werden kann, unterscheidet das Zachman Framework auch 6 Perspektiven auf das Unternehmen. Diese sind in Abb. 9.3 dargestellt. Planer Fachverantwortlicher Analyst Designer Implementierer
Abgrenzung Unternehmensmodell Fachliches Systemmodel Technisches Systemmodel
Abb. 9.3 Die Perspektiven auf das Unternehmen
Systemkomponenten (Laufendes Unternehmen)
Abgrenzung Repräsentiert den Blickwinkel des Planers. Das heißt: Beschreibt den Bereich oder den Kontext innerhalb des Unternehmens, mit dem sich ein Vorhaben bzw. ein Projekt beschäftigt. Unternehmensmodell Repräsentiert den Blickwinkel des Fachverantwortlichen. Das heißt: Macht das Geschäft durch Beschreiben eines Unternehmensmodells auf einer konzeptioneller Stufe explizit. Fachliches Systemmodell Repräsentiert den Blickwinkel des Analysten auf ein (IT-) System. Das heißt: Definiert sowohl die Grenzen eines solchen Systems innerhalb des Geschäftes als auch seine Spezifikation in Form eines logischen Modells des Systems. Technisches Systemmodell Repräsentiert den Blickwinkel des Designers auf ein (IT-) Systems. Das heißt: Definiert seine Technologie und Architektur in Form eines technischen Modells des Systems. Systemkomponenten Repräsentiert den Blickwinkel des Implementierers eines IT Systems. Das heißt: Beschreibt die detaillierte Repräsentation der Komponenten, die benötigt und/oder von individuellen Zulieferern erstellt werden. Diese Information ist meistens auf die spezifische Komponente beschränkt und ist daher nicht im Gesamtkontext des ganzen Systems zu sehen.
9.2 Lösungsansatz: Das Zachman Framework
67
laufendes Unternehmen Steht für das laufende Unternehmen einschließlich aller laufenden Systeme, die aktuell das Geschäft abwickeln.
Ein Projekt, welches das Zachman Frameworks verwendet, erarbeitet zuerst die verschiedenen Dimensionen auf einer Zeile, bevor mit diesen Resultaten als Vorgabe die nächst tiefere Zeile angegangen wird. Dabei nimmt man auf jeder Zeile einen anderen Blickwinkel ein, sodass jeweils etwas anderes hervorgehoben wird. Die unterste Zeile repräsentiert dann ganz konkret das funktionierende Unternehmen. Abb. 9.4 Projektvorgehen
Abgrenzung Planer Unternehmensmodell
1. Teil des Projekts: Ganzheitliche Betrachtung (Gesamtsystem)
Fachverantwortlicher Fachliches Systemmodell Analyst Technisches Systemmodell Designer
2. Teil des Projekts: Betrachtung einzelner Systeme (IT-Systeme und organisatorische Systeme)
Systemkomponenten Implementierer Laufendes Unternehmen
wieder ganzheitliche Betrachtung
Abb. 9.4 zeigt dieses Vorgehen, sowie eine ganz wesentliche Unterscheidung zwischen den ersten beiden Zeilen einerseits und den Zeilen 3, 4 und 5:
68
In den ersten beiden Zeilen des Zachman Frameworks findet eine ganzheitliche Betrachtung des Unternehmens aus fachlicher Sicht statt. Diese Betrachtung ist möglichst technologie-neutral und lässt insbesondere die Aufteilung zwischen IT-Systemen und Betriebsorganisation außer Acht. Mit dem Übergang auf Zeile 3 ändert der Betrachtungsgegenstand. Nun wird ein einzelnes System betrachtet. Ab jetzt hat man es in der Praxis mindestens mit zwei Systemen zu tun: Einem IT-System, in dem Teile des Unternehmens automatisiert sind, und dem System der Betriebsorganisation, in dem die manuellen Tätigkeiten abgewickelt werden. Es ist aber auch möglich, dass mehrere völlig getrennte IT-Systeme existieren. Somit werden die Zeilen 3–5 des Zachman Frameworks für jedes die-
9 Projekt-Definition
ser Systeme einzeln erarbeitet. Erst in Zeile 6 finden sich die einzelnen Systeme wieder zu einem Ganzen, dem laufenden Unternehmen, zusammen. Abb. 9.5 Gesamtsystem und seine Bestandteile
Betriebsorganisation
Gesamtsystem
IT-System
Die erste Zeile des Zachman Frameworks dient vor allem dazu, das Arbeitsfeld abzustecken, also festzulegen, was behandelt werden soll und was ausgeschlossen wird („Scoping“). Dinge Womit
Ressourcen Wer
Ereignisse Wann
Motive Warum
Liste von Liste von Aufgaben Orten, in des Geschäfts denen das Geschäft abgewickelt wird
Liste von Organisationen, die für das Geschäft wichtg sind
Liste von Ereignissen, die für das Geschäft wichtig sind
Liste von Zielen und Einflüssen
z.B. z.B. GeschäftsGeschäftsprozessmodell geographie
z.B. Aufbauorganisation
z.B. Geschäftsereignismodell
z.B. Strategien, Taktiken und Direktiven
z.B. Logisches Datenmodel
z.B. Applikationsarchitektur
z.B. Systemverteilung
z.B. Benutzerrollen
z.B. z.B. SystemGeschäftsereignisse und regeln Zustände
z.B. Physisches Datenmodel
z.B. System Design
z.B. technische Architektur
z.B. Benutzerschnittstellen
z.B. Ablaufpläne
z.B. RegelArchitektur
Systemkomponenten z.B. Datendefinition Implementierer
z.B. Programm
z.B. NetzwerkArchitektur
z.B. Benutzerrechte
z.B. Job Control
z.B. Regelbasis
Laufendes Unternehmen
z.B. Funktionen
z.B. Netzwerk
z.B. Organisation
z.B. Plan
z.B. Geschäftspolitik
Abgrenzung Planer
Liste von Dingen, mit denen das Geschäft zu tun hat
Unternehmensmodell z.B. Faktenmodel Fachverantwortlicher Fachliches Systemmodel Analyst Technisches Systemmodel Designer
z.B. Daten
Aufgaben Was
Orte Wo
Abb. 9.6 Das Zachman Framework
Seitenblick: Der Betrachtungsgegenstand, den man bei der Erarbeitung des Zachman Frameworks wählt, muss nicht unbedingt das Unternehmen als ganzes sein. Oft wird auch nur ein Bereich oder eine Abteilung betrachtet. Es ist sogar möglich, ein Projekt als Betrachtungsgegenstand zu wählen und das Framework für das Projekt auszufüllen.
9.2 Lösungsansatz: Das Zachman Framework
69
9.3 Schritt für Schritt: Abgrenzung eines Projekts
Ein Projektauftrag definiert ein geplantes Projekt. In ihm sind verschiedenste Aspekte geregelt:
Ausgangslage Projektziele Projektabgrenzung Interne und externe Abhängigkeiten Lieferprodukte Lösungsidee Inhaltliche, technische und Projektmanagement-Risiken Projektorganisation (Auftraggeber, Projektteam, etc) und Informationswege Kosten und Mittelbereitstellung Phasen-, Vorgehens- und Terminplan
Die meisten dieser Aspekte sind in dieser oder ähnlicher Form in Projekthandbüchern oder Vorgehensmodellen geregelt und gelten auch für ein Business Rules Projekt. Daher soll nicht weiter darauf eingegangen werden. Interessant für uns ist die Projektabgrenzung, denn sie umfasst als zentralen Teil die Erarbeitung der Abgrenzung, also Zachman Zeile 1, in welcher der Betrachtungsgegenstand abgegrenzt wird. Im Folgenden wird die schrittweise Erarbeitung dieser Abgrenzung erläutert. Für das Zachman Framework gilt: Aller Anfang ist leicht, denn auf der Zeile 1 müssen noch keine Modelle erstellt werden sondern lediglich Auflistungen. Beginnen sollte man immer mit den Motiven. An zweiter Stelle folgt die Auflistung der Dinge und Aufgaben, mit denen man es zu tun haben. Schließlich gilt es noch, die Orte, Ressourcen und Ereignisse aufzulisten. Auflisten bedeutet zuerst einmal immer die Erstellung einer ungeordneten Liste. Die Liste kann auch etwas gegliedert werden, indem Hierarchien oder Kategorien eingeführt werden. Auf die Erstellung von Diagrammen sollte in der Zeile 1 des Zachman Frameworks verzichtet werden. Ein wichtiger Punkt bei allen Dimensionen der ersten Zeile ist die Relevanz, d.h. die Frage, was nun dazu gehört und was nicht. Dabei orientiert man sich am Betrachtungsgegenstand, also beispielsweise dem zukünftigen Unternehmen. In der Praxis hat es sich bewährt, mindestens auf der Zeile 1 die Grenze nicht allzu eng zu ziehen und im Zweifelsfalle Elemente aufzunehmen, die nicht ganz zum Betrachtungsgegenstand gehören, aber eng mit ihm verknüpft sind.
70
9 Projekt-Definition
Tipp:
In Fällen, bei denen unter den verschiedenen Beteiligten Uneinigkeit über den Betrachtungsgegenstand herrscht, kann es hilfreich sein, in einer Negativ-Liste Elemente aufzulisten, die nicht dazu gehören.
1. Motive auflisten Beginnen sollte man mit dem „Warum“, denn die Dimension der Motive bildet die Grundlage, an denen sich die anderen Dimensionen orientieren. Eigentlich sollten Ziele, Einflüsse oder Strategien in einem Unternehmen bekannt sein. (Ihre Erarbeitung ist in den In den Kapiteln 6 bis 8 beschrieben.) In diesem Fall reicht es aus, sie der Vollständigkeit halber nochmals in einer Liste zusammenzufassen. Andernfalls soll versucht werden, mindestens die für den Betrachtungsgegenstand relevanten Ziele und Einflüsse zu ermitteln. 2. Relevante Dinge auflisten Diese Liste ist die Antwort auf die Frage, „Womit“ wir es zu tun haben. Sie enthält Dinge, die für das Unternehmen wichtig sind. Dazu gehören alle physischen Dinge, die irgendeine Rolle spielen, beispielsweise Produkte, Verpackungen oder Kunden, aber auch eher ideelle Dinge wie Verträge (in Form einer mündlichen Vereinbarung) oder eine Lieferung. Im weiteren Sinn können natürlich auch Orte oder Ereignisse als relevante Dinge betrachtet werden, doch diese werden in ihrer eigenen Kolonne aufgelistet (siehe Schritte 4 und 6). Die relevanten Dinge sind der Keim, aus dem später das Faktenmodell gebildet wird, die in Zeile 2 des Zachman Frameworks dokumentiert werden (siehe dazu Kapitel 10). 3. Relevante Aufgaben auflisten Die Liste der relevanten Aufgaben des Unternehmens beantwortet die Frage, „Was“ getan wird. Damit sind Prozesse, Aktionen oder Aktivitäten gemeint, die im Rahmen der Geschäftstätigkeit des Unternehmens ausgeführt werden. Gute Quellen zur Ermittlung der Aufgaben sind allfällig vorhandene Prozessbeschreibungen und Workshops mit den Mitarbeitern. Auch aus anderen Dokumenten über das Unternehmen können aus den Verben mit ihren Objekten Kandidaten für Aufgaben abgeleitet werden. In der Dimension der Aufgaben spielt der Detaillierungsgrad eine besondere Rolle, denn beinahe jede Aufgabe lässt sich in Teilaufgaben zerlegen, und diese lassen sich wiederum weiter zerlegen. So kann es durchaus sein, dass in der Liste der Aufgaben verschiedene, unterschiedlich detaillierte Elemente nebeneinander stehen, beispielsweise „verkaufen“ und „Rabattkondi-
9.3 Schritt für Schritt: Abgrenzung eines Projekts
71
tionen prüfen“. Gesucht sind in der Zeile 1 des Zachman Frameworks vor allen „große“ Aufgaben und allenfalls ihre Teilaufgaben, nicht aber zu detaillierte kleine Teilaufgaben. Die Aufgaben sind der Keim, aus dem später Geschäftsaktivitäten im Geschäftsprozessmodell entstehen. Tipp:
Bei dieser Tätigkeit sollte darauf geachtet werden, die Abgrenzung zwischen den Aufgaben des Unternehmens und den Aufgaben, die durch die Kunden oder Lieferanten ausgeführt werden, nicht zu eng zu sehen. Vielmehr ist eine im Ansatz unternehmensübergreifende Betrachtungsweise hier sinnvoll, um Möglichkeiten innovativer Lösungen nicht von vornherein auszuschließen. Die Aktivität „bestellen“ wird traditionellerweise durch den Kunden selbst und somit außerhalb unseres Unternehmens ausgeführt. Es ist aber auch denkbar, dass ein System, das unser Unternehmen beim Kunden installiert, bei uns automatisch Nachbestellungen erstellt oder der Kunde ein Abonnement für Lieferungen abschließt.
4. Relevante Orte auflisten Hier wird die Frage beantwortet, „Wo“ das Unternehmen tätig ist. Neben Firmen-Standorten kann es sich auch um Orte handeln, an denen eine Dienstleistung erbracht oder an die ein Produkt geliefert wird. Dabei ist eine gewisse Typisierung durchaus wünschenswert, will man nicht jede einzelne Filiale oder jeden Kundenstandort, der beliefert wird, auflisten. Auch das Internet kann ein Ort sein, an dem beispielsweise verkauft wird. 5. Relevante Ressourcen auflisten Hier geht es um die Frage, „Wer“ die Verantwortung für die Aufgaben des Unternehmens übernimmt bzw. diese ausführt. In der Regel werden hier Organisationseinheiten oder wichtige Rollen des Unternehmens aufgelistet. Werden die Aufgaben unternehmensübergreifend betrachtet, so sollen auch unternehmensexterne Organisationen erscheinen. 6. Relevante Ereignisse auflisten Die Ereignisse sind es, die den Anstoß liefern, dass im Unternehmen etwas passiert. Sie beantworten die Frage nach dem „Wann“. Eigentlich sollte jeder Prozess durch ein Ereignis ausgelöst werden, und alle Ereignisse, die für das Unternehmen relevant sind, sollten zu einer Reaktion führen. Die Liste der relevanten Ereignisse soll in ihrer Breite alle denkbaren Arten von Ereignissen abdecken ohne dabei zu sehr ins Detail zu gehen.
72
9 Projekt-Definition
Tipp:
In der Zeile 1 des Zachman Frameworks ist es noch möglich, alle Zellen (mindestens ansatzweise) auszufüllen. Die folgenden Zeilen können kaum mehr vollständig erarbeitet werden. Der Aufwand für das detaillierte Ausfüllen aller Zellen wäre zu groß und in den meisten Fällen in keinem Verhältnis zum Nutzen. Das Zachmann Framework soll vielmehr als eine Art Checkliste verstanden werden die verhindert, dass wichtige Aspekte vergessen gehen. Mit guten Gründen kann aber jederzeit auf die Ausarbeitung einzelner Ergebnisse verzichtet werden. Als einzige Forderung gilt: Es sollte ein bewusstes Verzichten und nicht ein Vergessen sein.
9.4 Ergebnis: Der Projektauftrag „BEGIN“
T. Reiber hat, in Absprache mit ihrem Auftraggeber B. Oss, einen Projektauftrag zusammengestellt. Im Folgenden ist dieser Projektauftrag auszugsweise zusammengefasst: Ausgangslage und Ziele Nachdem KnowBeer eine neue Geschäftspolitik erarbeitet hat soll das Unternehmen im Projekt „BEGIN: BEer Governance INternational“ auf diese neue Geschäftspolitik ausgerichtet werden. Dabei werden die folgenden Ziele verfolgt: Die neue Geschäftspolitik soll konkretisiert werden. Die nötigen Grundlagen sollen erarbeiten werden, damit die neue Geschäftspolitik von KnowBeer umgesetzt werden kann (dies ist Gegenstand eines Folgeprojekts). Projekt- und Systemgrenzen Das Projekt soll sich auf die Erarbeitung der zweiten Zeile des Zachman Frameworks beschränken. Betrachtungsgegenstand sind die Bereiche Einkauf, Verkauf, Logistik und Debitorenbuchhaltung der Firma KnowBeer. Nicht zum Betrachtungsgegenstand gehören untern anderem die Finanz- und Kreditorenbuchhaltung und das Personalwesen.
9.4 Ergebnis: Der Projektauftrag „BEGIN“
73
Warum? Ziele15: – größte Auswahl exotischer Bier-Sorten – rasche Lieferung – faire Konditionen – Marktleader sein – Fairer Handel mit 3. Welt – umweltfreundlich Externe Einflüsse16: – großer ausländischer Markt – Export- und Import-Gesetze – Direktverkauf durch Brauereien – Großhändler – Logistikanbieter – Transportkosten Womit? Artikel, Dienstleistung, Bestellung, Rechnung, Lager Was? Kunden beraten, Bestellung bearbeiten, Lager führen, Debitoren überwachen, einkaufen Wo? Hauptsitz Zürich, Niederlassung München, Lager Wer? Verkäufer, Verkaufsleiter, Einkäufer, Buchhalter, Disponent, Kunde, Lieferant Wann? Kunde kontaktiert KnowBeer, Lieferung trifft ein, vereinbarter Liefertermin ist erreicht, Zahlung trifft ein, vereinbarter Zahlungstermin ist erreicht
Lieferergebnisse Dokumentation aller Dimensionen des Zachman Frameworks aus Zeile 2 Projektorganisation Auftraggeber: B. Oss Projektleiterin: T. Reiber Projektmitarbeiter: B. Remser, R. Abatt Vorgehens- und Terminpläne Die Ergebnisse des Projekts sollen bis Ende des Quartals erarbeitet werden. 15 16
74
vgl. dazu Kapitel 6.4 vgl. dazu Kapitel 7.4
9 Projekt-Definition
9.5 Wie geht es weiter?
Mit der Erarbeitung der Zeile 1 des Zachman Frameworks und der Formulierung des Projektauftrages ist das Projekt abgesteckt. In den restlichen Kapiteln des Teils 2 werden nun die einzelnen Dimensionen der Zeile 2 erarbeitet. Abb. 9.7 zeigt, welche Zellen in welchen Kapiteln behandelt werden. Dinge Womit
Aufgaben Was
Orte Wo
Ressourcen Wer
Ereignisse Wann
Motive Warum
Abgrenzung Planer
Kapitel 9
Kapitel 9
Kapitel 9
Kapitel 9
Kapitel 9
Kapitel 9
Kapitel 10
Kapitel 11
Kapitel 11
Kapitel 11
Kapitel 11
Kapitel 12-14
Unternehmensmodell Fachverantwortlicher
9.5 Wie geht es weiter?
Abb. 9.7 Abdeckung der Zellen des Zachman Frameworks durch die Kapitel
75
10 Unternehmensvokabular
In diesem Kapitel wird aufgezeigt, wie ein einheitliches Unternehmensvokabular geschaffen wird, welches einerseits Missverständnisse vermeidet und andererseits als Grundlage für die Formulierung von Regeln dienen wird.
10.1 Ausgangslage: Was ist ein Kunde? Am Donnerstag verfasst Tina Reiber einen Brief, der die Expansion von KnowBeer nach Deutschland ankündigt. Sie hat Adressen eingekauft, die eine gute Abdeckung bei Restaurants der gehobenen Klasse in ganz Deutschland versprechen. In der Kaffeepause am Nachmittag trifft Tina Reiber auf Benno Remser: T. Reiber:
B. Remser: T. Reiber: B. Remser:
T. Reiber: B. Remser:
Ich konzipiere gerade die Ankündigung unserer Expansion nach Deutschland und habe einen Brief formuliert, den wir unseren Kunden in Deutschland schicken werden. Könntest du bitte diesen Brief kurz durchlesen? Haben wir denn schon so viele Kunden in Deutschland? Nein, noch nicht, aber das möchten wir ja gerade mit diesem Brief ändern! Dann schicken wir diese Brief also gar nicht Kunden, sondern potentiellen Kunden! Bei uns ist jemand erst dann Kunde, wenn wir ihm bereits einmal etwas verkauft haben! Aber ist das nicht reine Wort-Klauberei? Ganz und gar nicht! Wir behandeln potentielle Kunden anders als tatsächliche Kunden. Bei den potentiellen Kunden liegt der Fokus auf einem Erstgeschäft, wogegen wir bei existierenden Kunden versuchen, sie an uns zu binden.
10 Unternehmensvokabular
77
T. Reiber:
B. Remser: T. Reiber: B. Remser: T. Reiber:
B. Remser: T. Reiber:
Heißt das, dass wir diesen beiden Arten von Kunden unterschiedliche Angebote und eventuell sogar unterschiedliche Rabatte geben? Ja genau! Das sind ganz unterschiedliche Prozesse, wie wir Prospects und Kunden behandeln! Was verstehst denn du unter „Prospect“? Das sind unsere potentiellen Kunden. Dann ist „Prospect“ ein Synonym für „potentieller Kunde“, was nicht dasselbe ist wie ein „Kunde“! Ich denke, es ist höchste Zeit, dass wir einmal Zusammensitzen und unsere Terminologie bereinigen. Wenn du meinst, dass das 'was bringt… Auf jeden Fall! Ich hatte bereits vor ein paar Wochen mit Ruth Abatt aus dem Einkauf ein ähnlich verwirrendes Gespräch über den Unterschied zwischen einem Auftrag und einer Bestellung. Auch da hat sich gezeigt, dass nicht alle dasselbe unter diesen Begriffen verstehen!
Am Abend beschließt Tina Reiber ein Vokabular aufzubauen, welches sämtliche für KnowBeer wichtigen Begriffe enthält und möglichst präzise definiert.
10.2 Lösungsansatz: Unternehmensvokabular Unsere Sprache ist ein grundlegendes Mittel zur Kommunikation. In der Sprache werden aus Worten ganze Sätze gebildet. Dabei ist es essentiell, dass die Bedeutung der verwendeten Worte allen an der Kommunikation beteiligten Teilnehmern klar ist – sonst sind Missverständnisse vorprogrammiert. Genau diese Idee bildet die Grundlage des Business Rules Ansatzes. Um Sätze, und damit auch Regeln, formulieren zu können, muss zuerst ein Grundwortschatz festgelegt werden. Zudem muss die Bedeutung der in diesem Grundwortschatz enthaltenen Worte möglichst präzise festgelegt werden. Beim Business Rules Ansatz werden im Wesentlichen zwei Arten von Konzepten unterschieden, für die möglichst eindeutige Begriffe definiert werden müssen (siehe Abb. 10.1):
78
10 Unternehmensvokabular
Objekttyp: Damit sind allgemeine (z.B. „Kunde“) oder individuelle (z.B. „Hr. Meier“) Konzepte gemeint, die für das Unternehmen in irgendeiner Weise wichtig sind. Mit anderen Worten, diejenigen Dinge, die typischerweise im Zachman Framework in der Dimension „Womit?“ zu finden sind. Grammatikalisch betrachtet sind Objekttypen durch Substantive benannt. Fakttyp: Damit sind mögliche, für das Unternehmen relevante elementare Aussagen über ein oder mehrere Objekttypen gemeint. Beispielsweise ist im Ausdruck „Bestellung gehört zu Kunde“ „gehört zu“ ein Fakttyp, der eine mögliche Aussage über die beiden Objekttypen „Bestellung“ und „Kunde“ macht17. Wenn sämtliche Objekttypen eines Fakttypen konkretisiert werden (z.B. „Bestellung #715 gehört zu Hr. Meier“), so muss eine Aussage entstehen. Eine Aussage charakterisiert sich dadurch, dass sie immer entweder wahr oder falsch ist. Demgegenüber ist beispielsweise eine Frage keine Aussage, da eine Frage an sich nie wahr oder falsch ist.
Seitenblick: Oft wird zwischen Fakten und Fakttypen unterschieden. Fakten sind Aussagen, die Tatsachen repräsentieren, wogegen Fakttypen mögliche Aussagen darstellen. Eine Tatsache ist allerdings immer eine subjektive Annahme eines Menschen oder eine in einem ITSystem gespeicherte (von ihm „angenommene“) Information. Mit anderen Worten: Ein Fakt ist ein von jemandem oder etwas als wahr angenommener Fakttyp. Ein weiterer Unterschied zwischen Fakten und Fakttypen liegt darin, dass die Objekttypen von Fakten, im Gegensatz zu denjenigen von Fakttypen, normalerweise konkret sind. Denn beispielsweise kann „Herr Meier wohnt in Zürich“ als wahre Tatsache angenommen werden, nicht aber „Person wohnt in Stadt“. Genau genommen kann ein Fakttyp nicht nur Aussagen über Objekttypen, sondern über Konzepte im Allgemeinen machen (siehe Abb. 10.1) Konzept
macht Aussage über
Abb. 10.1 Konzepte
Fakttyp
Objekttyp
17
Im weiteren Verlauf dieses Buches verwenden wir die Konvention, dass Fakttypen kursiv und Objekttypen unterstrichen dargestellt werden.
10.2 Lösungsansatz: Unternehmensvokabular
79
Objekttypen lassen sich weiter in Geschäftsobjekte und Werttypen unterscheiden (siehe Abb. 10.2): Geschäftsobjekte sind Objekttypen, die fachlich wichtige Konzepte in der Geschäftswelt repräsentieren. Typische Beispiele sind etwa „Kunde“ oder „Artikel“. Für Geschäftsobjekte kann immer ein Referenzierungsschema definiert werden, mit dem ein einzelnes Exemplar identifiziert werden kann. Ein einzelner Artikel kann etwa via seine Artikelnummer, ein einzelner Kunde via seine Kundennummer eindeutig identifiziert werden18. Werttypen sind Abstraktionen von Werten. Ein Wert ist ein Konzept, dessen Bedeutung identisch mit seinem Namen ist und das sich daher nicht verändern lässt. Beispielsweise kann die Bedeutung der Zahl „3“ nie auf den Wert 7 verändert werden oder der Text „Hallo Peter“ kann nie „Das Wetter ist schön“ bedeuten. Beispiele von Werttypen sind etwa „Anzahl“, „Betrag“, „Prozent“, „Datum“, „Dauer“, aber auch „Name“ oder „Beschreibung“. Objekttyp
Abb. 10.2 Objekttypen
Geschäftsobjekt
Werttyp
Die Bedeutung einzelner Objekttypen wird in präziser natürlicher Sprache (z.B. Deutsch) ausgedrückt. Demgegenüber wird die Bedeutung von Fakttypen in graphischer Form, dem so genannten Faktenmodell ausgedrückt. Diese beiden Techniken werden nun im Folgenden etwas genauer beschrieben. Seitenblick: Sowohl Objekttypen als auch Fakttypen sind immer in einer bestimmten Sprache formuliert. Damit ist einerseits eine Landessprache gemeint, andererseits ist die verwendete Terminologie auch abhängig vom Kontext ihrer Verwendung. So hat beispielsweise das Wort „Bank“ in der Finanzwelt eine andere Bedeutung als im Zusammenhang mit einem Erholungspark. Somit ist jedes Vokabular auf eine spezifische Zielgruppe ausgerichtet, die daher auch für jedes Vokabular explizit angegeben werden soll. 18
Selbst wenn kein so einfaches Referenzierungsschema wie eine Nummer vorliegt, kann ein Exemplar eines Geschäftsobjektes durch eine Umschreibung identifiziert werden: beispielsweise lässt sich ein potentieller Kunde meist auch durch seinen vollen Namen sowie seine aktuelle Wohnadresse eindeutig identifizieren.
80
10 Unternehmensvokabular
10.2.1 Präzise Definitionen Die Bedeutung eines Objekttyps wird in natürlicher Sprache festgehalten. Dabei wird allerdings eine von zwei Formen empfohlen, welche durch die ISO-Normen 704 [ISO00] bzw. 1087 [ISO00a] definiert sind:
Intensionale Definition: Eine Beschreibung eines Objekttyps, welche die Bedeutung eines Konzeptes durch einen allgemeineren Objekttyp sowie den differenzierenden Eigenschaften formuliert. Beispiel: Ein Mädchen ist eine ÖPerson, die weiblich und noch nicht volljährig ist. Extensionale Definition: Eine Beschreibung eines Objekttyps, die sämtliche untergeordneten Objekttypen explizit aufzählt. Beispiel: Person: Entweder eine ÖFrau, ein ÖMann, ein ÖMädchen oder ein ÖJunge.
Definitionen sollen möglichst auf bereits definierten Begriffen aufbauen, was oben jeweils durch das Zeichen Ö angedeutet wird. Zudem sind intensionale Definitionen den extensionalen Definitionen vorzuziehen. Extensionale Definitionen sind nur dann sinnvoll, wenn einige wenige untergeordneter Objekttypen existieren. In Ergänzung zu den eigentlichen Definitionen macht es in der Praxis Sinn, folgende Elemente pro Objekttyp zu dokumentieren:
zugelassene Synonyme (neben dem präferierten Namen des Konzepts) Beispiel-Exemplare des beschrieben Konzepts Quelle bzw. Verantwortlicher des Objekttyps bzw. der Definition Person, welche die letzte Änderung der Beschreibung vorgenommen hat, sowie der Zeitpunkt der Änderung
10.2.2 Das Faktenmodell Wir haben einfache Formen der Faktenmodell-Notation bereits in früheren Kapiteln dieses Buches kennen gelernt: Zur Illustration der Begriffe und Zusammenhänge aus dem „Business Motivation Model“. Nun kommen wir zur Hauptanwendung des Faktenmodells, nämlich zur Illustration wichtiger Unternehmenskonzepte sowie deren Zusammenhänge. Das Faktenmodell zeigt in graphischer Form sowohl die relevanten Objekttypen als auch die möglichen (und relevanten) elementaren Aussagen (die Fakttypen), die sich über die Objekttypen machen lassen. Die in diesem Buch verwendete Notation für das Faktenmo-
10.2 Lösungsansatz: Unternehmensvokabular
81
dell basiert im wesentlichen auf der Notation des Klassendiagramms der Unified Modeling Language (UML), wie sie von der Object Management Group (OMG) propagiert wird [OMG04]19. Ein Objekttyp wird im Faktenmodell als benanntes Rechteck dargestellt, wobei der Name des Objekttyps immer in Einzahl geschrieben wird (siehe Abb. 10.3). Dabei wird im Gegensatz zu anderen, mehr technisch orientierten Modellierungssprachen kein grundsätzlicher Unterschied zwischen Typen (z.B. „Person“) und Exemplaren (z.B. „Hans Meier“) gemacht. Abb. 10.3 Objekttypen im Faktenmodell
Konzept
Beispiele: Person
Artikel
Land
Hans Meier
Clausthaler
Schweiz
Name
Beschreibung
Anzahl
Über Konzepte können nun elementare Aussagen gemacht werden, die sich in Form verschiedener Fakttypen darstellen lassen. Dabei wird zwischen Fakttypen, die nur ein Konzept betreffen und Fakttypen unterschieden, die gleichzeitig mehrere Konzepte betreffen. Fakttypen, die lediglich ein Konzept betreffen, werden als einwertige Fakttypen bezeichnet und werden im Faktenmodell durch einen benannten Rhombus dargestellt, der mit dem entsprechenden Objekttyp verbunden ist (siehe Abb. 10.4). Der Name des Rhombus soll dabei zusammen mit dem Namen des Objekttyps einen einfachen Satztyp bilden, welcher entweder wahr oder falsch sein kann (beispielsweise „Person ist männlich“ oder „Artikel ist verfügbar“). Abb. 10.4 Einwertige Fakttypen
Konzept
Aussage über ein Konzept
Beispiele: Person
Artikel
Land
ist männlich
ist verfügbar
ist Insel
19
Für den Business Rules Ansatz wurden allerdings nicht unbeträchtliche Abweichungen und Vereinfachungen gegenüber der UML Originalnotation vorgenommen, um eine bessere Ausrichtung auf NichtInformatiker zu erreichen.
82
10 Unternehmensvokabular
Fakttypen, die genau zwei Konzepte betreffen, werden als Verbindungslinie zwischen den zwei entsprechenden Objekttypen dargestellt. Der Name des Fakttyps wird dabei an diese Verbindungslinie angehängt und ein kleines schwarzes Dreieck zeigt die korrekte Leserichtung an (siehe Abb. 10.5). Auch hier soll der Fakttyp zusammen mit den involvierten Objekttypen Grundlage für eine elementare Aussage bilden können, die entweder wahr oder falsch sein kann (beispielsweise „Person wohnt in Land“ oder „Person bestellt Artikel“). Konzept1
Aussage über zwei Konzepte
Konzept2
Beispiele: Person
Person
wohnt in
Abb. 10.5 Zweiwertige Fakttypen
Land
bestellt
Artikel
In seltenen Fällen sind auch elementare Aussagen denkbar, die mehr als zwei Konzepte betreffen. In diesen Fällen wird wie auch bei einwertigen Fakttypen der Rhombus zur Darstellung des (nun höherwertigen) Fakttyps verwendet. Dieser Rhombus verbindet alle involvierten Objekttypen, ggf. unter Verwendung von den Verbindungslinien zugeordnete Hilfsbezeichnungen, zu einem rudimentären Satz. Im Beispiel von Abb. 10.6 heißt dieser etwa „Person bestellt Anzahl von Artikel“. Oft ist es sinnvoll, ein solches Satzmuster in Form einer kleinen Notiz explizit anzugeben, um die Lesereihenfolge zu verdeutlichen. Konzept1
Konzept3 StatzTeil2
Abb. 10.6 Höherwertige Fakttypen
SatzTeil1 Konzept2
Beispiel: Person
Artikel von
(Person) bestellt (Anzahl) von (Artikel)
bestellt
Anzahl
10.2 Lösungsansatz: Unternehmensvokabular
83
Neben diesen beliebig benennbaren Fakttypen, definiert der Business Rules Ansatz noch einige weitere gebräuchliche Fakttypen über zwei Objekttypen. Der erste davon ist der Exemplar-Fakttyp. Er besagt, dass ein Konzept ein Exemplar eines anderen Konzeptes (seinem Typ) ist. Der Exemplar-Fakttyp wird durch einen gestrichelten Pfeil vom Exemplar zum Typ dargestellt (siehe Abb. 10.7). Wie aus den Beispielen ersichtlich, kann ein einzelner Objekttyp (hier „Clausthaler“) sowohl die Rolle eines Exemplars (gegenüber „Artikel“) als auch die Rolle eines Typs (gegenüber „Flasche #1273“) einnehmen. Abb. 10.7 ExemplarFakttyp
Konzept1
Konzept2
allgemeiner Objekttyp ...
individueller Objekttyp
Beispiele: Person
Hans Meier
Artikel
Clausthaler
Flasche #1273
Der Exemplar-Fakttyp macht eine Aussage darüber, dass ein Konzept (z.B. „Hans Meier“) Mitglied einer Menge gleichartiger Konzepte (z.B. „Person“) ist. Dies ist in Abb. 10.8 illustriert. Abb. 10.8 Exemplare
Menge (z.B. „Person“)
Mitglied (z.B. „Hans Meier“)
Eine weitere, oft vorkommende elementare Aussage wird durch den Spezialisierungs-Fakttyp abgebildet. Er besagt, dass ein Objekttyp eine Spezialisierung eines anderen Objekttyps ist und wird durch einen Pfeil mit großer weißer Spitze vom spezielleren Objekttyp zum generelleren Objekttyp dargestellt (siehe Abb. 10.9).
84
10 Unternehmensvokabular
Konzept1
Konzept2
genereller Objekttyp ...
spezieller Objekttyp
Abb. 10.9 SpezialisierungsFakttyp
Beispiele: Mann Person Frau Bier Produkt Artikel
Wein Service
Dabei ist es nicht unüblich, dass eine solche Spezialisierung von Objekttypen über mehrere Stufen hinweg zieht (beispielsweise „Artikel“/„Produkt“/„Bier“) in Abb. 10.9). Auch der Spezialisierungs-Fakttyp kann mittels Mengen illustriert werden (siehe Abb. 10.10). In diesem Beispiel sind „Frau“ und „Mann“ Teilmengen der Menge „Person“. Jede Frau ist somit Mitlied der Menge „Frau“ als auch Mitglied der Menge „Person“. Es ist durchaus möglich, dass sich die Teilmengen einer Übermenge auch überschneiden: In unserem Beispiel überschneidet sich die Teilmenge „blonde Person“ als weitere Spezialisierung von „Person“ mit den anderen beiden Teilmengen „Frau“ und „Mann“.
Frau
Mann
Ursi Heidi
Person
Abb. 10.10 Spezialisierungen
Hans Fritz
blonde Person
Schließlich kann mit Hilfe des Rollen-Fakttyps ausgedrückt werden, dass ein Objekttyp eine Rolle repräsentiert, die ein Konzept spielt. Dieser Fakttyp wird durch einen gestrichelten Pfeil mit einer großen weißen Spitze vom Objekttyp, welcher die Rolle repräsentiert zum Objekttyp, welcher die Rolle spielt, dargestellt (siehe Abb. 10.11). Im Zusammenhang mit Rollen ist es nicht unüblich, dass ein einzelnes Konzept (z.B. eine „Person“) mehrere Rollen gleichzeitig spielt (z.B. „Kunde“ und „Mitarbeiter“). Im Zusammenhang mit der Faktenmodellierung ist die Arität eines Fakttypen ein wichtiger Begriff: Er bezeichnet die Anzahl der Objekttypen eines Fakttypen. Einwertige Fakttypen weisen somit die Arität 1, zweiwertige Fakttypen die Arität 2, etc. auf.
10.2 Lösungsansatz: Unternehmensvokabular
85
Abb. 10.11 Rollen-Fakttyp
Konzept1
«ist Rolle von»
Konzept2
Rolle des anderen Objektyps
Frame Box «ist Rolle von»
Kunde
«ist Rolle von»
Mitarbeiter
Person
Produkt
«ist Rolle von»
Erzeugnis
«ist Rolle von»
Wertgegenstand
Seitenblick: Den Lesern, die mit klassischer Daten- oder Objektmodellierung vertraut sind, werden parallelen zwischen diesen Modellierungstechniken und der Faktenmodell-Notation auffallen. Bei genauerer Betrachtung sind allerdings wesentliche Unterschiede auszumachen. Die Faktenmodell-Notation (und der Business Rules Ansatz überhaupt) basiert auf der Prädikatenlogik, in der Aussagen über Dinge gemacht werden. Das Faktenmodell soll als Vokabular für die spätere Formulierung von Regeln dienen und beschreibt daher die Bedeutung von Worten (die Semantik) und nicht irgendwelche Informations-, Daten- oder gar Programmstrukturen. In klassischen Modellierungsansätzen werden Entitätstypen oder Klassen mit Attributen und Beziehungen dargestellt. Dabei werden Attribute als Bestandteile dieser Entitätstypen oder Klassen betrachtet und Beziehungen als Zusammenhänge zwischen zwei Entitätstypen oder Klassen. In der Faktenmodell-Notation wird diese Unterscheidung nicht gemacht: Beides sind (potentielle) Elementaraussagen über Dinge. Aus diesem Grund sind Objekttypen im Faktenmodell immer elementar, d.h. sie besitzen keine innere Struktur. Was in der klassischen Modellierung als Attribut „Geburtsdatum“ einer „Person“ modelliert würde, wird daher im Faktenmodell genau wie auch eine „normale“ Beziehung als zweiwertiger Fakttyp „Person hat Geburtsdatum Datum“ dargestellt. Mit dieser Notation lassen sich in einem Faktenmodell sämtliche für das Unternehmen relevanten Dinge (bzw. deren Objekttypen) sowie sämtliche möglichen Elementaraussagen über diese Dinge übersichtlich darstellen20. Was nun noch bleibt, ist die präzise Festlegung der Bedeutung der einzelnen Objekttypen des Faktenmodells. 20
86
Anhang C enthält eine Zusammenfassung der Faktenmodell-Notation.
10 Unternehmensvokabular
10.3 Schritt für Schritt: Erarbeitung eines Unternehmensvokabulars Im Zachman Framework ist das Unternehmensvokabular in der Zeile Unternehmensmodell in der Spalte Womit? angesiedelt. Die Erstellung eines unternehmensweiten Vokabulars ist eine nicht zu unterschätzende Aufgabe. Aus diesem Grund sind folgende Schritte für die Erarbeitung und Verwaltung eines Unternehmensvokabulars zu empfehlen: 1. Werkzeug zur Verwaltung des Unternehmensvokabulars festlegen In einem realen Unternehmen kann das relevante Vokabular leicht mehrere Hundert oder noch mehr Objekttypen umfassen. Daher empfiehlt es sich, schon von Beginn weg ein elektronisches Hilfsmittel zur Erfassung des Unternehmensvokabulars einzusetzen. Dies muss nicht unbedingt eine ausgeklügelte Software sein. Ein Textsystem oder ein Tabellenkalkulationsprogramm leisten in einer initialen Phase schon gute Dienste. Auch für die graphische Darstellung des Faktenmodells kann man sich mit einem einfachen Graphikprogramm behelfen. In einem nächsten Schritt kann dann immer noch ein spezialisiertes Repository21 oder ein CASE-Tool22 zum Einsatz kommen. 2. Themenbereiche identifizieren Da ein Unternehmensvokabular rasch sehr groß werden kann, macht es Sinn, dieses in verschiedene Themenbereiche wie Verkauf, Einkauf, Buchhaltung, etc. aufzuteilen. Diese Themenbereiche lassen sich dann einerseits einzeln als Teilvokabulare bearbeiten und andererseits verschiedenen Verantwortlichen zuteilen. 3. Relevante Objekttypen identifizieren Nun können die Objekttypen für die dem Unternehmen bzw. den untersuchten Unternehmensbereich wichtigen Dinge identifiziert werden. Dabei kann folgende Unterscheidung hilfreich sein: – Allgemeine Konzepte, d.h. unternehmensrelevante Konzepte, die eine wahrnehmbare Menge von Dingen mit gemeinsamen Eigenschaften (ein Typ von Dingen) repräsentieren. 21
Eine unternehmensweite Datenbank zur Verwaltung von strukturierten Unternehmensdaten. 22 CASE: Computer Aided Software Engineering: ein Werkzeug, das die Anwendung gängiger Software Engineering Ansätze unterstützt.
10.3 Schritt für Schritt: Erarbeitung eines Unternehmensvokabulars
87
–
Typische Beispiele solcher Objekttypen sind etwa „Kunde“, „Artikel“ oder „Vertrag“. Dabei ist zu beachten, dass Namen dieser Objekttypen für das Unternehmensvokabular immer in Einzahl formuliert werden. Individuelle Konzepte, d.h. unternehmensrelevante Konzepte, die genau ein einzeln identifizierbares Ding (ein Exemplar) repräsentieren. Typische Beispiele solcher Objekttypen sind etwa „Hans Meier“, „Clausthaler“ oder „Schweiz“. Individuelle Konzepte sind in der Praxis für das Unternehmensvokabular weniger wichtig als allgemeine Konzepte. Tipp:
Eine der wichtigsten Quellen für die Identifikation von Objekttypen ist die „Womit?“-Dimension des Zachman Frameworks. Alles, was bei der Abgrenzung dieser Dimension zugeordnet wurde, ist offenbar für das Unternehmen wichtig.
Bei der Identifikation dieser Objekttypen ist darauf zu achten, dass nur die im Unternehmen gebräuchlichsten Begriffe in das Unternehmensvokabular aufzunehmen sind. Sind beispielsweise die Begriffe „Kunde“, „Auftraggeber“ und „Käufer“ in Gebrauch, so soll lediglich der gängigste Begriff (z.B. „Kunde“) in das Unternehmensvokabular übernommen und die anderen Begriffe als gültige Synonyme deklariert werden. 4. Relevante Fakttypen identifizieren Sind die relevanten Objekttypen einmal identifiziert, kann untersucht werden, welche elementaren Aussagen über diese Objekttypen und welche Zusammenhänge zwischen diesen Objekttypen wichtig sind. Dabei kann wie folgt vorgegangen werden: – Identifikation der relevanten einwertigen Fakttypen, d.h. für das Unternehmen wichtige Aussagen über einen einzelnen Objekttyp. Diese können beispielsweise in folgender textueller Form dokumentiert werden: „
“, also zum Beispiel „Kunde ist präferiert“. – Identifikation der relevanten zweiwertigen Fakttypen, d.h. Sätze, die über genau zwei Objekttypen eine für das Unternehmen wichtige Aussage machen. Als Hilfsmittel kann dazu eine Matrix erstellt werden, die jeden Objekttyp jedem anderen Objekttyp gegenüber stellt. Ein solcher zweiwertiger Fakttyp kann beispielsweise in folgender textueller Form dokumentiert werden: „ “, also zum Beispiel „Kunde bezahlt Bestellung“. – Höherwertige Fakttypen können weniger systematisch identifiziert werden – sie ergeben sich fallweise. Sobald eine
88
10 Unternehmensvokabular
Aussage mehr als zwei Objekttypen beinhaltet und keiner dieser Objekttypen weggelassen werden kann, ohne dass dadurch die Bedeutung der Aussage verändert wird, liegt ein höherwertiger Fakttyp vor. Als Beispiel kann in der Aussage „Artikel hat Rabatt ab Anzahl“ keiner der drei Objekttypen weggelassen werden: „Artikel“ ist das Subjekt des Satzes, „Anzahl“ macht ohne „Rabatt“ keinen Sinn und der „Rabatt“ wäre nicht mehr abhängig von der Menge, falls „Anzahl“ weggelassen würde. Tipp:
Dinge, welche in der klassischen Daten- oder Objektmodellierung als Attribute modelliert würden spielen im Faktenmodell lediglich eine untergeordnete Rolle. Sie werden nur dann ins Faktenmodell aufgenommen, wenn sie zur späteren Formulierung von Regeln notwendig sind.
5. Faktenmodell erstellen Die in den vorherigen Schritten gefundenen Objekttypen und Fakttypen können sofort im Faktenmodell abgebildet werden. Mit anderen Worten: Schritt 4 kann auch parallel zu Schritt 3 ausgeführt werden. Es empfiehlt sich das Faktenmodell auf mehr als ein Diagramm zu verteilen, damit die Übersichtlichkeit gewahrt bleibt. Eine solche Aufteilung sollte thematisch motiviert sein, beispielsweise ein Diagramm für den Verkaufsbereich, eines für den Einkaufsbereich, etc. 6. Relevante Objekttypen definieren Ist das Faktenmodell einmal einigermaßen ausgearbeitet, lassen sich die darin abgebildeten Objekttypen präzise definieren. Dabei sollen möglichst alle Interessierten konsultiert werden. Es gilt, einen Konsens darüber zu finden, ob der verwendete Begriff wirklich die gebräuchlichste Bezeichnung für das Konzept ist und welche Synonyme zugelassen sein sollen. Tipp:
Es geht hauptsächlich darum, unternehmens- oder fachspezifische Objekttypen präzise zu definieren. Begriffe, die zum Allgemeingut einer Umgangssprache gehören, müssen daher nicht im Unternehmensvokabular definiert werden. Oft genügt als Definition auch ein simpler Verweis auf ein allgemein bekanntes Wörterbuch.
Ergänzend zu den Definitionen der Objekttypen kann es unter Umständen Sinn machen, im Unternehmensvokabular auch die identifizierten Fakttypen zu beschreiben. Dies wird insbesondere dann wichtig, wenn eine der folgenden Bedingungen gegeben ist:
10.3 Schritt für Schritt: Erarbeitung eines Unternehmensvokabulars
89
das Faktenmodell liegt nicht in Form von graphischen Diagrammen vor, das Faktenmodell soll in verschiedene Sprachen übersetzt werden, die Bedeutung gewisser komplexer Fakttypen ist nicht offensichtlich.
Mit der initialen Erstellung ist ein Unternehmensvokabular keineswegs abgeschlossen. Ein Unternehmensvokabular muss ständig gepflegt werden, da neue Erkenntnisse gewonnen werden oder weil sich die Unternehmensterminologie über Jahre hinweg verändern kann. Aus diesem Grund sind die oben beschriebenen Schritte als langfristiger Prozess und nicht als einmalige Aktion zu verstehen.
10.4 Ergebnis: Das Unternehmensvokabular von KnowBeer In einer Reihe intensiver Workshops wurden verschiedene Themenbereiche des Unternehmensvokabulars von KnowBeer erarbeitet. Dazu zählen (mit den jeweiligen Verantwortlichen in Klammern):
Verkauf (Tina Reiber) Einkauf (Ruth Abatt) Produktmanagement (Bernd Oss) Buchhaltung (Monika Oney) Logistik (Ludwig Ager) Personalwesen (Gertrud Elisabeth Halt) Geschäftsleitung (Bernd Oss)
Stellvertretend sei hier lediglich das Teilvokabular für den Verkaufsbereich von KnowBeer aufgeführt. Tabelle 10.1 Vokabular „Verkauf“
90
Vokabular „Verkauf“ Zielgruppe
Mitarbeiter von KnowBeer
Sprache
Deutsch
Verantwortlich
Verkauf/T. Reiber
10 Unternehmensvokabular
Das folgende Faktenmodell zeigt die im Verkaufsbereich von KnowBeer wichtigen Konzepte23. Dauer
Person
Organisation
hat Alkoholgehalt
Prozent
Betrag «ist Rolle von»
«ist Rolle von»
Produkt
hat Kreditlimite
hat Geschäftsbeziehung seit Kunde
Service
hat Zahlungsprobleme
hat Jahresumsatz
Abb. 10.12 Das Faktenmodell der Verkaufsabteilung von KnowBeer
hat Stückpreis Anzahl
(Bestellung) beinhaltet (Anzahl) von (Artikel) mit Rabatt (Prozent)
Artikel
ist bevorzugt
hat Minimalrabatt
von beinhaltet
Betrag
Anzahl
ab
gehört zu mit Rabatt hat Bruttopreis Bestellung
hat Rabatt
Prozent
hat Nettopreis hat Lieferdatum
hat Destination
ist express
(Artikel) hat Minimalrabatt (Prozent) ab (Anzahl)
Land
hat Bestelldatum
hat Versandkosten Datum
Betrag
Die folgenden Beispiele zeigen schließlich den entsprechenden Ausschnitt der Definitionen der Objekttypen von KnowBeer: Ein ÖProdukt oder ein ÖService, welches KnowBeer zum Verkauf anbietet. Synonym(e): Leistung Beispiel(e): (siehe ÖProdukt oder ÖService) Verantw.: Produktmanagement/B. Oss
Artikel
Ein ÖVertrag zwischen einem ÖKunden mit KnowBeer zwecks Lieferung eines oder mehrerer ÖArtikel gegen Entgelt. Synonym(e): Auftrag Beispiel(e): Der mündliche Auftrag des Restaurants Krone über 200 Flaschen „Green King IPA F66“ zu einem Gesamtpreis von 328 €. Verantw.: Verkauf/T. Reiber
Bestellung
23
Die Tatsache, dass gewisse Objekttypen mehr als einmal im Faktenmodell erscheinen (z.B. "Betrag") hat keine besondere Bedeutung – sie dient lediglich der Vereinfachung des Layouts des Diagramms.
10.4 Ergebnis: Das Unternehmensvokabular von KnowBeer
91
Eine Zahl mit genau zwei Nachkommastellen, welche einen Geldbetrag in Euro (€) repräsentiert. Synonym(e): ––– Beispiel(e): ––– Verantw.: Buchhaltung/M. Oney
Betrag
Die Rolle einer ÖPerson oder einer ÖOrganisation, welche gegen Entgelt von KnowBeer ÖArtikel bezieht. Synonym(e): Auftraggeber, Besteller, Käufer Beispiel(e): Restaurant Krone, Frau Heidi Müller (eine Kundin) Verantw.: Verkauf/B. Remser
Kunde
Land (siehe http://de.wikipedia.org/wiki/Staat). Synonym(e): Staat, Nation Beispiel(e): Schweiz, Deutschland, England, Holland Verantw.: Logistik/L. Ager Eine juristische Person, mit der KnowBeer eine Geschäftsbeziehung unterhält oder unterhalten möchte. Synonym(e): Betrieb, Gesellschaft, Firma Beispiel(e): Restaurant Krone, Brauerei Hopfen & Malz, Finanzamt Frankfurt Verantw.: Logistik/L. Ager
Organisation
Eine natürliche Person, mit der KnowBeer eine Geschäftsbeziehung unterhält oder unterhalten möchte. Synonym(e): Mensch, Einzelperson Beispiel(e): Frau Heidi Müller (eine Kundin), Herr Anton Schmitt (unser Steuerberater), Tina Reiber (unsere Mitarbeiterin) Verantw.: Logistik/L. Ager
Person
Ein ÖArtikel, welcher ein physischer, abzählbarer Gegenstand ist. Synonym(e): Ware, Artikel (in Zukunft aber nicht mehr zu verwenden, da „Artikel“ eine andere Bedeutung hat!) Beispiel(e): Green King IPA F66, Clausthaler F33, Amstel Malt F50, Cardinal Lager F100 Verantw.: Produktmanagement/B. Oss
Produkt
92
10 Unternehmensvokabular
Ein ÖArtikel, welcher eine durch KnowBeer erbrachte Dienstleistung ist. Synonym(e): Dienstleistung Beispiel(e): Bierberatung, Bierdegustation, Degustationskurs Verantw.: Produktmanagement/B. Oss
Service
Im Folgenden sind zudem sämtliche im Faktenmodel des Verkaufsbereichs von KnowBeer verwendeten Fakttypen aufgelistet: … beinhaltet … von … mit Rabatt … Form: ÖBestellung beinhaltet Anzahl von ÖArtikel mit Rabatt Prozent Arität: 4 Verantw.: Verkauf/T. Reiber … gehört zu … Form: ÖBestellung gehört zu ÖKunde Arität: 2 Verantw.: Verkauf/T. Reiber … ist bevorzugt Form: ÖKunde ist bevorzugt Arität: 1 Verantw.: Verkauf/T. Reiber … hat Alkoholgehalt … Form: ÖProdukt hat Alkoholgehalt ÖProzent Arität: 2 Verantw.: Produktmanagement/B. Oss … hat Bestelldatum … Form: ÖBestellung hat Bestelldatum ÖDatum Arität: 2 Verantw.: Verkauf/T. Reiber … hat Bruttopreis … Form: ÖBestellung hat Bruttopreis ÖBetrag Arität: 2 Verantw.: Verkauf/B. Remser … hat Destination … Form: ÖBestellung hat Destination ÖLand Arität: 2 Verantw.: Verkauf/T. Reiber
10.4 Ergebnis: Das Unternehmensvokabular von KnowBeer
93
… hat Geschäftsbeziehung seit … Form: ÖKunde hat Geschäftsbeziehung seit Dauer Arität: 2 Verantw.: Verkauf/B. Remser … hat Jahresumsatz … Form: ÖKunde hat Jahresumsatz ÖBetrag Arität: 2 Verantw.: Verkauf/B. Remser … hat Kreditlimite … Form: ÖKunde hat Kreditlimite ÖBetrag Arität: 2 Verantw.: Verkauf/B. Remser … hat Lieferdatum … Form: ÖBestellung hat Lieferdatum ÖDatum Arität: 2 Verantw.: Verkauf/T. Reiber … hat Minimalrabatt … ab … Form: ÖArtikel hat Minimalrabatt Prozent ab Anzahl Arität: 3 Verantw.: Verkauf/T. Reiber … hat Nettopreis … Form: ÖBestellung hat Nettopreis ÖBetrag Arität: 2 Verantw.: Verkauf/B. Remser … hat Rabatt … Form: ÖBestellung hat Rabatt Prozent Arität: 2 Verantw.: Verkauf/B. Remser … hat Stückpreis … Form: ÖArtikel hat Stückpreis ÖBetrag Arität: 2 Verantw.: Einkauf/R. Abatt … hat Versandkosten … Form: ÖBestellung hat Versandkosten ÖBetrag Arität: 2 Verantw.: Verkauf/B. Remser
94
10 Unternehmensvokabular
… hat Zahlungsprobleme … Form: ÖKunde hat Zahlungsprobleme Anzahl Arität: 2 Verantw.: Verkauf/B. Remser … ist express Form: Arität: Verantw.:
ÖBestellung ist express 1 Verkauf/T. Reiber
Dieses Unternehmensvokabular wurde in einer ersten Version in Deutsch formuliert. Im Hinblick auf die Auslandexpansion von KnowBeer wurde es anschließend ins Englische übersetzt für die Zielgruppen der englischen und holländischen Mitarbeiter von KnowBeer.
10.5 Wie geht es weiter? Mit einem Unternehmensvokabular ist die Grundlage für die Formulierung von Regeln geschaffen, welche das Verhalten eines Unternehmens steuern und beeinflussen. Bevor wir nun aber beginnen, Regeln aufzustellen, müssen wir uns bewusst werden, was im Unternehmen eigentlich getan wird oder getan werden müsste. Dazu müssen wir uns zumindest ansatzweise über die relevanten Geschäftsprozesse bewusst werden. Genau darüber wird im folgenden Kapitel gesprochen.
10.5 Wie geht es weiter?
95
11 Geschäftsprozesse
In diesem Kapitel wird aufgezeigt, wie Geschäftsprozesse und Geschäftsaktivitäten dokumentiert und klare Verantwortlichkeiten zugeteilt werden können. Außerdem werden Geschäftsaktivitäten als ausgezeichnete Quelle für Geschäftswissen präsentiert.
11.1 Ausgangslage: Was läuft hier eigentlich?
Monika Oney ist auf dem Weg zu Benno Remsers Büro als sie ihn im Pausenraum bei der Espresso-Maschine sieht. Sie betritt den sonst leeren Pausenraum und beschließt, die Angelegenheit hier zur Sprache zu bringen: M. Oney: B. Remser: M. Oney:
B. Remser:
M. Oney B. Remser:
Gut, dass ich dich treffe, Benno! Ich bin gerade auf dem Weg zu dir. Hallo Monika, was gibt’s denn? Es geht um einen deiner Kunden, den „Gasthof zum schwarzen Räuber“ im Schwarzwald. Er hat vor einiger Zeit eine große Lieferung Wädenswiler Bio Hanf-Bier erhalten und immer noch nicht bezahlt. Und nun höre ich, dass der Gasthof geschlossen wurde. Dabei war es nicht das erste Mal, dass wir Probleme mit diesem Kunden hatten. Diese letzte Bestellung hättest du gar nicht annehmen dürfen! Moment mal! Das stimmt nicht! Ich durfte diese Bestellung nicht nur annehmen, ich musste es sogar. Es liegt nämlich nicht im meiner Kompetenz zu entscheiden, ob ein Kunde weiter beliefert werden soll oder nicht. Das darfst und musst nur du tun. Jetzt willst du mir das Problem in die Schuhe schieben? Ich bin für diesen Verlust sicher nicht verantwortlich. #@!!Ø*
11 Geschäftsprozesse
97
Nachdem sich die Gemüter wieder etwas beruhigt haben beschließen beide, gemeinsam zu Bernd Oss zu gehen. Er soll den Streit schlichten. Sie erläutern ihm die Situation, woraufhin die Diskussion munter weitergeht: B. Oss:
M. Oney: B. Remser: B. Oss:
M. Oney: B. Oss: M. Oney: B. Oss:
Ist es denn nicht so, dass die Logistik eine Lieferung gar nicht nur ausliefern soll, wenn die Kreditwürdigkeit durch die Buchhaltung geprüft worden ist? Ich habe doch erst kürzlich ein entsprechendes E-Mail verschickt. Also ich habe dieses E-Mail sicher nicht erhalten! Ich würde mich bestimmt daran erinnern. Ich kann mich im Moment auch nicht erinnern. Mir wird langsam klar, dass hier nichts klar ist. Du hast Recht, Benno. Die Verantwortung für etwas so wichtiges wie die Prüfung der Kreditwürdigkeit von Kunden sollte klar geregelt sein, und zwar nicht nur in einem E-Mail. Ich bin aber sicher, dass ich das E-Mail geschrieben habe. Und wie verhindern wir, dass so etwas nächste Woche wieder passiert? Nun, für den Moment möchte ich, dass alle Bestellungen über 5.000 Euro von dir freigegeben werden müssen bevor sie ausgeliefert werden. Macht Sinn. Vor allem aber müssen wir unsere wichtigsten Prozesse dokumentieren und die Verantwortlichen festlegen. Dies scheint mir gut ins Projekt BEGIN zu passen, ich werde morgen mit Tina Reiber sprechen.
Als B. Oss am nächsten Tag mit T. Reiber spricht, rennt er offenen Türen ein. Die Dokumentation, wer für was verantwortlich ist, ist ein wichtiger Bestandteil des Zachman Frameworks das, im Projekt BEGIN als eine Art Leitfaden verwendet wird.
11.2 Lösungsansatz: Geschäftsprozessmodellierung
Auch wenn über Geschäftsprozesse bereits viel geschrieben worden ist24, soll dieses Thema hier angesprochen werden. Allerdings etwas
24
Auf http://www.amazon.de findet man unter Stichwort „Geschäftsprozesse“ über 100 Bücher
98
11 Geschäftsprozesse
anders als üblich, denn unsere Erfahrungen mit der Modellierung von Geschäftsprozessen waren nicht immer erfreulich. In der Praxis werden Geschäftsprozesse in vielen Unternehmen dokumentiert. Allzu oft haben diese dokumentierten Prozesse aber wenig Ähnlichkeit mit den tatsächlich ablaufenden Prozessen. Dies hat verschiedene Gründe:
Geringer Praxisbezug der Dokumentation Die Prozessbeschreibungen werden als Soll-Prozesse von Mitarbeitern einer Fachstelle beschrieben, mit wenig oder keinem Bezug zur betrieblichen Praxis. Zu hoher Detaillierungsgrad der Dokumentation Die Dokumentation der Geschäftsprozesse ist in Teilen so detailliert, dass sie gar nicht mehr vollständig sein kann. Nicht nachgeführte Dokumentation Die Erstellung der detaillierten Dokumentation ist so teuer, dass für die Pflege kein Geld mehr zur Verfügung steht.
Eine theoretische, umfangreiche aber bereits veraltete Prozessbeschreibung mit wenig Bezug zur Realität kann nützlich sein, um ein Zertifikat zu erlagen, für unsere Zwecke ist sie aber ungeeignet. Wir schlagen deshalb vor einen „leichtgewichtigen Ansatz“ vor, in dem die Geschäftsprozesse so einfach wie möglich beschrieben werden und insbesondere auf die Dokumentation von Entscheidungen und Varianten in Prozessdiagrammen verzichtet wird. Im Zachman Framework decken die Geschäftsprozesse in der Zeile Unternehmensmodell die Spalten Was?, Wer? und Wann? ab. Wir verwenden zur Beschreibung dieser drei Dimensionen die folgenden Begriffe (siehe Abb. 11.1): Ort befindet sich an Teil von
Organisationseinheit
verwendet
Geschäftsereignis
ausgelöst durch
verantwortlich für
Geschäftsobjekt
löst aus
Geschäftsaktivität
realisiert
Handlungsweise
Abb. 11.1 Geschäftsaktivität, Organisationseinheit und Geschäftsereignis
Geschäftsprozess Voraussetzung für
Teil von
Taktik
Strategie
Geschäftsaktivität (Was wird gemacht?): Beschreibt eine Aktivität oder Tätigkeit, die ausgeführt werden soll. Beispiele dafür sind das Erfassen einer Bestellung oder das Verschicken von Rechnungen. Eine Geschäftsaktivität kann Teil einer anderen Geschäftsaktivität sein oder selbst aus Geschäftsaktivitäten be-
11.2 Lösungsansatz: Geschäftsprozessmodellierung
99
stehen. Wichtig ist außerdem die Tatsache, dass die Ausführung einer Geschäftsaktivität eine Voraussetzung für die Ausführung einer weiteren Geschäftsaktivität sein kann. Organisationseinheit (Wer führt es aus?): Beschreibt die für die Ausführung einer Geschäftsaktivität verantwortliche Instanz. Meist sind hier Einheiten der Organisation, beispielsweise Abteilungen, Gruppen oder einzelne Stellen, gemeint, sehr selten individuelle Personen. Eine Organisationseinheit kann Teil einer anderen Organisationseinheit sein oder selbst aus Organisationseinheit bestehen. Geschäftsereignis (Wann wird es angestoßen?): Beschreibt das Ereignis, das die Ausführung einer Geschäftsaktivität auslöst. Der Grundgedanke, der dahinter steckt, besagt, dass nichts ohne Anstoß ausgeführt wird, wobei der Anstoß durchaus auch darin bestehen kann, dass es wieder einmal Zeit ist, etwas zu tun. Viele Geschäftsereignisse kommen von außerhalb des Unternehmens, beispielsweise wenn ein Kunde anruft oder eine Zahlung eintrifft.
Diese wenigen Grundelemente reichen bereits aus, um Geschäftsprozesse in einer angemessenen Detaillierung zu beschreiben. Die Verwendung der beiden Begriffe Geschäftsaktivität und Geschäftsprozess bedarf einer Klärung: Eine Geschäftsaktivität ist ein einzelner Schritt in einem Ablauf. Ein Geschäftsprozess besteht aus einer Menge von Einzelschritten, eben Geschäftsaktivitäten. Allerdings kann etwas, was auf einer Ebene eine Geschäftsaktivität ist und somit Teil eines Prozesses ist, auf einer anderen Ebene selbst ein Geschäftsprozess sein, der aus weiteren Einzelschritten besteht. Abb. 11.2 zeigt diesen Zusammenhang auf. Abb. 11.2 Geschäftsprozess und Geschäftsaktivitäten
100
Geschäftsprozess
Geschäftsaktivitäten
Geschäftsprozess
Geschäftsaktivitäten
11 Geschäftsprozesse
Als Notation zur Modellierung der Geschäftsprozesse verwenden wir eine vereinfachte Variante des Aktivitätsdiagramms aus der UML. Abb. 11.3 zeigt einen sehr einfachen Geschäftsprozess, der lediglich aus einer einzigen Geschäftsaktivität besteht. Der Geschäftsprozess hat zudem einen Anfangspunkt und einen Endpunkt. Beginn
Abb. 11.3 Ein sehr einfacher Geschäftsprozess
Geschäftsaktivität
Ende
Etwas komplizierter ist der Geschäftsprozess in Abb. 11.4. Er enthält bereits alle Elemente, die wir verwenden werden. Anstelle des Anfangspunktes steht nun das empfangene Geschäftsereignis, das den Geschäftsprozess auslöst. Der Geschäftsprozess besteht aus drei Geschäftsaktivitäten, wobei die Geschäftsaktivität 1 Voraussetzung für die Geschäftsaktivitäten 2 und 3 ist. Die Bedeutung dieser Voraussetzung ist für das Verständnis unserer Geschäftsprozesse sehr wichtig: Die Geschäftsaktivität 1 ist Voraussetzung für die Geschäftsaktivität 2. Das bedeutet, dass zuerst die Geschäftsaktivität 1 in irgendeiner Weise ausgeführt werden muss, bevor die Geschäftsaktivität 2 ausgeführt werden kann. Voraussetzung bedeutet nicht, dass auf den Abschluss der Geschäftsaktivität 1 zwangläufig die Ausführung der Geschäftsaktivität 2 folgen muss. Seitenblick: Der optimale Formalisierungsgrad eines Prozessmodells hängt stark vom Charakter des beschriebenen Prozesses ab. Stark standardisierte, häufig ausgeführte Prozesse lassen sich gut als starre Abfolge von Geschäftsaktivitäten darstellen. Die Reihenfolge im Modell entspricht tatsächlich der Reihefolge, in der die Aktivitäten in der Realität ausgeführt werden. Es gibt wenige bis keine Freiheitsgrade, daher lassen sich solche Prozesse sehr gut durch Workflow-Management-Systeme unterstützen oder automatisieren. In kreativen Prozessen andererseits, die vom Ausführenden viel Fachwissen verlangen, laufen die Geschäftsaktivitäten kaum in einer festen Reihenfolge ab. Da der Ausführende hat viele Freiheiten hat lassen sich solche Prozesse nur schlecht als fixe Abfolge beschreiben.
11.2 Lösungsansatz: Geschäftsprozessmodellierung
101
Die hier verwendeten Modelle stellen einen Kompromiss zwischen diesen beiden Extremen dar. Es werden zwar gewisse Abhängigleiten modelliert, aber die Bedeutung ist eher im Sinn von „üblicherweise“ zu verstehen. Ausnahmen und Abweichungen sind jederzeit möglich. Abb. 11.4 Die AktivitätsdiagrammNotation
Organisationseinheit 1 Organisationseinheit 2
Organisationseinheit 3
empfangenes Geschäftsereignis Voraussetzung für
Geschäftsaktivität 1
Voraussetzung für
Geschäftsaktivität 2
Voraussetzung für
Geschäftsaktivität 3
gesendetes Geschäftsereignis
Ende
Somit ist im Geschäftsprozess in Abb. 11.4 nicht ersichtlich, ob nach der „Geschäftsaktivität 1“ entweder „Geschäftsaktivität 2“ oder „Geschäftsaktivität 3“ ausgeführt wird oder ob in gewissen Fällen sogar beide Geschäftsaktivitäten ausgeführt werden. Mit Hilfe von Geschäftsregen vom Typ „Prozessregel“ können (siehe Kapitel 13) können solche Aspekte dokumentiert werden. Außerdem zeigt das Aktivitätsdiagramm, welche Organisationseinheiten für die Ausführung der Geschäftsaktivitäten zuständig sind. Die Geschäftsaktivitäten sind so genannten „Schwimmbahnen“ zugeteilt, welche die Organisationseinheiten repräsentieren: Die „Geschäftsaktivitäten 1“ und „3“ der Schwimmbahn der „Organisationseinheit 2“, und die „Geschäftsaktivität 2“ der Schwimmbahn der „Organisationseinheit 3“. Zudem ist noch ersichtlich, dass die „Organisationseinheiten 2“ und „3“ der „Organisationseinheit 1“ untergeordnet sind. Seitenblick: Normalerweise werden in Geschäftsprozessmodellen auch Konstrukte für Entscheidungen und Synchronisation paralleler Abläufe verwendet. Auf diese Konstrukte verzichten wir bewusst zu Gunsten des unverbindlicheren Konstrukts „Voraussetzung für“. Denn hinter den Entscheidungen stecken Geschäftsregeln, und diese Regeln gehören im Business Rules Ansatz nicht einer einzelnen Geschäftsaktivität oder einem Geschäftsprozess, sondern
102
11 Geschäftsprozesse
sie sind etwas Eigenständiges, das unabhängig vom Geschäftsprozess existiert. Dies führt zu schlanken Geschäftsprozessmodellen, die allerdings auch weniger Informationen zeigen, als übliche Modelle. Ihre Erstellung ist aber viel weniger aufwändig, daher sind sie auch einfacher aktuell zu halten. Am Ende eines Geschäftsprozesses steht in der Regel das Auslösen eines Geschäftsereignisses. Endet ein Prozess nicht mit einem Ereignis, so wird er durch den schwarzen Punkt mit dem Kreis beendet.
11.3 Schritt für Schritt: Skizzierung von Geschäftsprozessen
Die Beschreibung der Geschäftsprozesse betrifft gleich mehrere Dimensionen im Zachman Framework: “Was“, „Wer“ und „Wann“ (und teilweise auch „Wo“). Im Vordergrund steht dabei die Antwort nach dem „Was“, d.h. nach den Aufgaben des Unternehmens. Für eine verständliche und möglichst klare Beschreibung der Geschäftsprozesse ist es wichtig, das Unternehmensvokabular zu verwenden (siehe dazu Kapitel 10). Nötigenfalls muss das Unternehmensvokabular um fehlende Konzepte ergänzt werden. Wird das Vokabular nicht konsequent verwendet, werden genau diejenigen Probleme vergrößert, die man eigentlich beheben möchte: Es wird eine nur scheinbar klare Beschreibung erstellt, in der viel Interpretationsspielraum und Potential für Missverständnisse und Konflikte steckt. 1. Wichtige Geschäftsprozesse identifizieren Wichtige Geschäftsprozesse, wie sie hier verwendet werden, sind nichts weiter als die Kern- oder Hauptprozesse des Unternehmens. Sie sind umfangreich und beschreiben die großen Aufgaben des Unternehmens. Ein Unternehmen wie KnowBeer hat eher 10 als 100 solche Prozesse. Eine gute Quelle zur Identifikation der Geschäftsprozesse sind die Listen, die auf der Zeile Abgrenzung des Zachman Frameworks erstellt wurden (siehe dazu Kapitel 9). Die Beantwortung der folgenden Fragen hilft, mögliche Geschäftsprozesse zu finden: – Was sind die primären (wertschöpfenden) Aufgaben des Unternehmens? – Was sind die wichtigsten sekundären (unterstützenden) Aufgaben des Unternehmens? – Was lösen die Geschäftsereignisse im Unternehmen aus? – Welche Aufgaben erfüllen die Organisationseinheiten?
11.3 Schritt für Schritt: Skizzierung von Geschäftsprozessen
103
Aber nicht alles, was so gefunden wird, ist ein wichtiger Geschäftsprozess. Es kann durchaus sein, dass diese erste Liste auch untergeordnete Geschäftsprozesse enthält. Ein häufiges Merkmal wichtiger Geschäftsprozesse ist, dass sie durch Ereignisse von außen angestoßen werden und mit dem Auslösen von Ereignissen enden. 2. Wichtige Geschäftsaktivitäten identifizieren Für jeden Geschäftsprozess können nun die wichtigsten Geschäftsaktivitäten gesucht werden. Dabei kann immer nach dem gleichen Schema vorgegangen werden: Hat man eine Geschäftsaktivität gefunden, so können zu dieser Geschäftsaktivität die einzelnen (Teil-)Aktivitäten aufgelistet werden. Über Reihenfolge und Abhängigkeiten muss man sich noch keine Gedanken machen. Es reicht aus, mit einer strukturierten Liste (siehe dazu Abb. 11.5) von Geschäftsaktivitäten zu beginnen. Abb. 11.5 Strukturierte Liste von Geschäftsaktivitäten
104
Geschäftsaktivitäten Produkte verkaufen - Verfügbarkeit prüfen - Kreditwürdigkeit prüfen - Kunden-Geschichte prüfen - Externe Bonitätsprüfung - Kunde einstufen - Offerte erstellen - Ware liefern - Rechnung stellen - Mahnen - Produkte einkaufen - Vertrag abschliessen - Ware bestellen - Ware prüfen - Rechnung bezahlen …
11 Geschäftsprozesse
3. Abhängigkeiten modellieren Die Geschäftsaktivitäten eines Geschäftsprozesses können zueinander in Beziehung stehen. Das Resultat, das in einer Geschäftsaktivität erarbeitet wird, kann Voraussetzung für eine weitere Geschäftsaktivität sein. Diese Abhängigkeiten werden nun dokumentiert. Hierfür reicht eine strukturierte Liste nicht mehr aus, es ist nun notwendig, ein Aktivitätsdiagramm zu erstellen. Die Abhängigkeiten sollen für jeden einzelnen Geschäftsprozess modelliert werden. Zu beachten ist dabei die Bedeutung von „Voraussetzung für“, wie sie oben erläutert wurde. 4. Verantwortlichkeiten zuordnen Das Aktivitätsdiagramm erlaubt es, die einzelnen Geschäftsaktivitäten verschiedenen Verantwortlichen zuzuteilen. Als Verantwortliche werden üblicherweise nicht einzelne Personen sondern ganze Organisationseinheiten modelliert. Für jede am Geschäftsprozess beteiligte Organisationseinheit wird eine „Schwimmbahn“ im Aktivitätsdiagramm eingeführt (siehe beispielsweise die Schwimmbahn „Verkauf“ in Abb. 11.8). Die einzelnen Geschäftsaktivitäten werden dann der entsprechenden Schwimmbahn zugeteilt. Es kann vorkommen, dass aufgrund der Zuteilung eine Geschäftsaktivität aufgeteilt werden muss. 5. Organisationsstruktur definieren Die Organisationseinheiten, die für Geschäftsaktivitäten verantwortlich sind, werden in einem Organigramm dargestellt. Diese Struktur wird dann um die restlichen Organisationseinheiten, die nicht an den modellierten Geschäftsprozessen beteiligt sind, ergänzt. Wo nötig kann die Organisationsstruktur bis auf die Eben von Stellen- bzw. Funktionsbeschreibungen verfeinert werden. Tipp:
Schritte 4 und 5 können auch in umgekehrter Reihenfolge ausgeführt werden.
Seitenblick: Die hier aufgeführten Schritte beschreiben ein Top-downVorgehen. Dieses Vorgehen eignet sich, wenn nur eine sehr grobe Übersicht benötigt wird oder wenn das ganze Geschäftsprozessmodell nicht zu umfangreich ist. Wenn man hingegen eine detailliertere Beschreibung erstellen will, oder bei einem umfangreichen Geschäftsprozessmodell, sollte eher das so genannte Middle-out-Vorgehen benutzt werden. Man beginnt mit den Geschäftsereignissen und modelliert die Prozesse, die diese Ereignisse abarbeiten. Erst zum Schluss werden die so gefundenen Prozesse zu den übergeordneten Kernprozessen zusammengefasst.
11.3 Schritt für Schritt: Skizzierung von Geschäftsprozessen
105
11.4 Ergebnis: Die wichtigsten Prozesse von KnowBeer
Als Startpunkt für die Dokumentation der Geschäftsprozesse hat Bernd Oss als erstes ein Organigramm sowie eine Liste der Hauptprozesse von KnowBeer („Prozesslandkarte“) erstellt. Danach wurden die Leiter der einzelnen Unternehmensbereiche beauftragt, ihre Geschäftsprozesse zu beschreiben und mit ihren Mitarbeitern zu validieren. Stellvertretend sind hier die Geschäftsprozesse „Produkt verkaufen“ und „Produkt beschaffen“ beschrieben. Abb. 11.6 Das Organigramm von KnowBeer
KnowBeer
Hauptsitz Zürich
Niederlassung München
…
… Einkauf
Verkauf
Team 1
Buchhaltung
Team 2
Verkaufsleiter
Verkaufsleiter
Verkäufer
Verkäufer
Lager
Logistik
IT
Die Hauptprozesse wurden von B. Oss bewusst als eine reine Liste von Geschäftsprozessen dokumentiert. Die Zuordnung zu Organisationseinheiten und Geschäftsereignissen soll erst auf einem detaillierteren Level sichtbar werden.
106
11 Geschäftsprozesse
Im Scope vom Projekt „BEGIN“ - Produkte beschaffen - Produkte und Services verkaufen - Produkte liefern - Debitorenbuchhaltung führen Ausserhalb des Scopes von Projekt „BEGIN“ - Geschäft leiten - Angebot definieren - Services erbringen - Personal bereitstellen - Finanzbuchhaltung führen
Abb. 11.7 Die Hauptprozesse von KnowBeer
T. Reiber hat, zusammen mit B. Remser, den Verkaufsprozess für Produkte dokumentiert und die Verantwortlichkeiten festgehalten. Der Verkaufsprozess für Dienstleistungen wird hier nicht gezeigt. Speziell am Verkaufsprozess ist, dass neben den betroffenen Organisationseinheiten von KnowBeer auch der Kunde als „Organisationseinheit“ mit eigener Schwimmbahn dokumentiert ist. Dies hilft, den Verkaufsprozess als ganzes besser zu verstehen. Man hat sich bei KnowBeer zudem entschlossen, bei Bedarf aus dem Verkaufsprozess zwei Ereignisse auszulösen: Wünscht der Kunde bei der Erstellung der Offerte ein Produkt, dass nicht im Sortiment ist, wird das Ereignis „neues Produkt“ ausgelöst. Es stößt einen Prozess zur Produktevaluation im Einkauf an. Und wird beim prüfen der Verfügbarkeit festgestellt, das von einem Produkt zu wenig an Lager ist, dann wird das Ereignis „Nachbestellung“ ausgelöst. Dieses Ereignis stößt dann den Beschaffungsprozess an.
11.4 Ergebnis: Die wichtigsten Prozesse von KnowBeer
107
Abb. 11.8 Der Verkaufsprozess von KnowBeer
Kunde
KnowBeer Logistik
Verkauf
Anfrage stellen
Offerte erstellen
neues Produkt
Bestellung bestätigen
Buchhaltung
Kreditwürdigkeit prüfen
Nachbestellung
Verfügbarkeit prüfen
Ware liefern
Rechnung stellen
Rechnung bezahlen
Der Beschaffungsprozess von KnowBeer wurde von R. Abatt zusammen mit ihrem Team erarbeitet. Abb. 11.9 Der Beschaffungsprozess von KnowBeer
KnowBeer
Lieferant Einkauf
Buchhaltung
Nachbestellung
Vertrag abschliessen
Ware bestellen Ware liefern Ware prüfen
mangelhafte Qualität Rechnung stellen Rechnung prüfen
108
11 Geschäftsprozesse
Rechnung bezahlen
11.5 Wie geht es weiter?
Mit den dokumentierten Geschäftsaktivitäten sind nun einerseits die Tätigkeiten des Unternehmens explizit gemacht und andererseits die Zuständigkeiten festgelegt. Die Geschäftsaktivitäten sind aber auch ein Ausgangspunkt, um Regelungen und Regeln zu finden, welche diese Geschäftsaktivitäten steuern oder zumindest beeinflussen. Dies ist Gegenstand der nächsten zwei Kapitel.
11.5 Wie geht es weiter?
109
12 Geschäftswissen
In diesem Kapitel wird aufgezeigt, was das Geschäftswissen eines Unternehmens ausmacht. Ferner wird gezeigt, dass Direktiven in Form von Regelungen und Geschäftsregeln beim Geschäftswissen eine zentrale Rolle spielen. Schließlich wird aufgezeigt, wie sich solche Regelungen systematisch finden und dokumentieren lassen.
12.1 Ausgangslage: Was muss überhaupt geregelt werden? Es regnet nun schon seit drei Tagen und das Wochenende kommt immer näher. Am Freitag treffen sich Tina Reiber und Benno Remser zum gemeinsamen Mittagessen: T. Reiber: B. Remser: T. Reiber:
B. Remser:
T. Reiber:
B. Remser:
Hoffentlich hört dieser Regen bald auf, ich möchte am Wochenende in die Berge fahren! Nach den Erfahrungen der letzten paar Tage sehe ich da aber eher schwarz! Aber in den Wetterprognosen haben sie eine Besserung angekündigt. Am Sonntag soll's sogar den ganzen Tag sonnig sein! Wer glaubt schon den Wetterfröschen? Ich hab' da eine ganz einfache Regel: „das Wetter morgen ist dasselbe wie heute!“ – und die trifft in fast 80% der Fälle zu! Die Meteorologen haben aber viel ausgefeiltere Modelle. Mit diesen umfangreichen Regelwerken sind sie so viel ich weiß in der Lage, das Wetter des folgenden Tages mit einer Wahrscheinlichkeit um 90% vorauszusagen. Aber lohnt sich dieser gigantische Aufwand für ein bloß 10% besseres Ergebnis?
12 Geschäftswissen
111
T. Reiber:
B. Remser:
T. Reiber:
B. Remser:
Es ist doch überhaupt interessant, dass sich mit Regeln die Zukunft vorhersagen lässt. Auch bei uns gibt es solche Regeln: in vielen Fällen bestellt ein Kunde Produkte aus unserem „Exotik-Sortiment“, wenn er unser Bier-Seminar besucht hat und ein Lokal in einer Region führt, in dem eine hohe Konkurrenzdichte herrscht. Ich nutze diese Art von Verkaufswissen ganz bewusst und gezielt – schon seit Jahren. Bei unseren jungen Verkäufern ist dieses Wissen allerdings noch weit weniger verbreitet, da es ihnen an der entsprechenden Erfahrung mangelt. Genau deswegen versuchen wir dieses Wissen explizit zu machen – das ist die Kernidee des Business Rules Ansatzes. Es gibt ja nicht nur Regeln für Prognosen. Es gibt auch Regeln, die sagen, was in unserem Unternehmen zu tun ist und was nicht. Über diese Art von Regelungen in unsrer Firma werden wir uns am Workshop nächsten Dienstag Gedanken machen. Na, da bin ich ja 'mal gespannt!
Wider Erwarten wird das Wetter am Wochenende schließlich ganz angenehm und die Regel von Benno Remser erweist sich zumindest in diesem Fall als falsch. Für den Workshop am kommenden Dienstag nimmt sich Tina Reiber vor, ganz bewusst auf Regeln und Regelungen einzugehen, welche eine steuernde Wirkung auf das Unternehmen haben. Außerdem möchte sie versuchen, die an diesem Workshop gefundenen Regelungen mit den Erkenntnissen aus der Strategie-Definition in Einklang zu bringen und bei deren Formulierung so weit wie möglich das Unternehmensvokabular zu berücksichtigen.
12.2 Lösungsansatz: Direktiven Wie wir im Kapitel 9 gesehen haben, werden in der Kolonne „Warum?“ des Zachman Frameworks die Gründe festgehalten, warum in einem Unternehmen etwas so und nicht anders gemacht wird. Dazu zählen einerseits die Definition von Zweck und Mitteln eines Unternehmens, wie in Kapitel 6 und 8 beschrieben, andererseits auch Direktiven.
112
12 Geschäftswissen
Das „Business Motivation Model“ zeigt uns aber auch, dass Direktiven Mittel sind, Handlungsweisen zu entwickeln, um trotz der Auswirkungen verschiedener Einflüsse und deren Einschätzungen, gesetzte Ziele zu erreichen (siehe Abb. 12.1). Mittel
mögliche Auswirkung
motiviert durch
Handlungsweise
beeinflusst
Direktive
unterstützt
Abb. 12.1 Direktiven
Ziel
spielt Rolle von
formuliert auf Basis
motiviert durch
Vorschrift
Einschätzung
Betrachten wir Direktiven etwas genauer. Grundsätzlich lassen sich zwei Arten von Direktiven unterscheiden (siehe Abb. 12.2):
Regelung: Eine Anweisung, welche die Art und Weise vorschreibt, wie gewisse Geschäftsaktivitäten auszuführen sind, um positive Auswirkungen auf das Unternehmen zu maximieren und negative Auswirkungen zu minimieren. Regelungen können hierarchisch aufgebaut sein, d.h. sie lassen sich aus weiteren Regelungen zusammensetzen. Regelungen bilden die Grundlage für die Ableitung von einzelnen Geschäftsregeln. Geschäftsregel: Eine konkrete Vorschrift oder ein konkretes Verbot, welches bei der Ausführung einer Geschäftsaktivität beachtet werden muss. Eine Geschäftsregel ist atomar, wohl strukturiert, auf der Basis des Unternehmensvokabulars formuliert. Im Vergleich zu einer Regelung ist eine Geschäftsregel typischerweise atomar, d.h. nicht in weitere Komponenten zerlegbar, ohne ihre Eigenständigkeit zu verlieren.
Direktiven betreffen oder leiten also Geschäftsaktivitäten. Als Elemente der „Warum?“-Dimension des Zachman Frameworks stellen Direktiven und Geschäftsregeln also den Zusammenhang mit der „Was?“-Dimension des Zachman Frameworks her. Neben der unterschiedlichen Granularität gibt es einen Hauptunterschied zwischen Regelungen und Geschäftsregeln: Geschäftsregeln sind wesentlich präziser formuliert als Regelungen, d.h. ihre Formalität ist bedeutend höher. Geschäftsregeln konkretisieren somit Regelungen, damit sie anwendbar werden25. Wir werden daher im Kapitel 13 den Aspekt der Formalität von Geschäftsregeln noch einmal gesondert betrachten. 25
Solange eine Regelung nicht durch Geschäftsregeln konkretisiert wurde, bleibt sie informal und daher nicht direkt anwendbar.
12.2 Lösungsansatz: Direktiven
113
Abb. 12.2 Regelungen und Geschäftsregeln
Direktive
Teil von
Formalität
betrifft
Regelung
Geschäftsaktivität
konkretisiert Geschäftsregel
leitet
Direktiven, d.h. Regelungen und Geschäftsregeln, stellen essentielle Bestandteile des Wissens dar, wie ein Geschäft abgewickelt werden soll. Regelungen und Geschäftsregeln bauen auf Konzepten aus dem Unternehmensvokabular auf. Somit sind auch Objekttypen und Fakttypen wesentliche Wissenselemente eines Unternehmens (siehe Abb. 2.1). Abb. 12.3 Wissenselemente
Wissenselement
Konzept
Modellregel
Direktive
Formalität Objekttyp
Regelung
Fakttyp
Geschäftsregel
Schließlich kann noch eine dritte Kategorie von Wissenselementen identifiziert werden: Modellregeln. Damit sind Regeln gemeint, die einen bestimmten Aspekt eines Geschäfts beschreiben, ohne dass sie ihn selber beeinflussen können. Beispielsweise kann versucht werden, aufgrund von Erfahrungen das Kundenverhalten zu prognostizieren. Somit sind Modellregeln beobachtende Regeln, die ein Modell des beobachteten Systems (z.B. des Kunden) repräsentieren. Modellregeln werden verwendet, um das Verhalten dieses Systems möglichst genau vorherzusagen. Im Gegensatz dazu sind Direktiven beeinflussende Regeln, da sie die Abwicklung des Geschäfts direkt beeinflussen und steuern sollen. Im Zusammenhang mit Modellregeln wird auch die Frage nach deren Durchsetzung interessant. Die Verletzung einer Direktive kann bestraft werden. Wird hingegen eine Modellregel verletzt, so macht eine Bestrafung schlicht keinen Sinn: Schließlich kann ein Kunde nicht bestraft werden, wenn er sich nicht so verhält wie prognostiziert und auch das Wetter zeigt sich unbeeindruckt, wenn dessen Prognose falsch war. Werden also Modellregeln verletzt, so ist an der Regel zu zweifeln und nicht am geregelten Subjekt (einer Firma oder einem Kunden).
114
12 Geschäftswissen
Seitenblick: Modellregeln spielen in zwei eigenen Disziplinen eine zentrale Rolle: Die Predictive Analysis ist die Wissenschaft, wie mittels statistischer Ansätze aufgrund historischer Informationen das zukünftige Verhalten des Betrachtungsgegenstandes (z.B. der Kunden eines Unternehmens) vorhergesagt werden kann. Die zweite Hauptanwendung von Modellregeln ist die Diagnostik. Dabei werden Regeln verwendet, um ein möglichst genaues Modell eines Systems zu bilden und damit Ursachen von Fehlern und Störfällen im System zu finden. Typische Anwendungsgebiete sind die medizinische Diagnostik, aber auch beispielsweise die Überwachung von Finanz-Transaktionen bezüglich der Einhaltung der Geldwäschereigesetze. Für beide Disziplinen, Predictive Analysis und Diagnostik, existieren heute ausgereifte Techniken und Software Systeme, die aber den Rahmen dieses Buches sprengen würden. Direktiven (d.h. sowohl Regelungen als auch Geschäftsregeln) lassen sich weiter verfeinern, indem sie in eine der folgenden drei Gruppen der Deontischen Logik26 klassifiziert werden (siehe Abb. 12.4):
Verpflichtung: Eine Direktive, die vorschreibt, was in welchen Situationen (obligatorisch) zu tun ist. Beispielsweise muss bei Neukunden in KnowBeer immer eine erfolgreiche Kreditwürdigkeitsprüfung erfolgt sein, bevor die erste Lieferung von Waren erfolgen kann. Verbot: Eine Direktive, die gewisse Tätigkeiten oder Situationen verbietet. In KnowBeer ist es beispielsweise aufgrund gesetzlicher Auflagen verboten, alkoholische Getränke ohne Bewilligung in islamische Länder zu liefern. Erlaubnis: Eine Direktive die klarstellt, was getan werden darf, obwohl es vielleicht nicht offensichtlich ist. Beispielsweise ist es in KnowBeer erlaubt Pakete mit verschiedenen einzelnen Flaschen zu verkaufen (obwohl es unüblich ist).
26
Die Deontische Logik ist eine Spezialisierung der formalen Logik, die sich mit Gesetzgebungen befasst. Wir werden im Kapitel 13 genauer darauf eingehen.
12.2 Lösungsansatz: Direktiven
115
Abb. 12.4 Deontische Direktiven
Direktive
Formalität Regelung
Geschäftsregel
Verwendung Verpflichtung
Verbot
Erlaubnis
Eine Erlaubnis kann auch in Form einer Ausnahme auftreten. Ein solches Beispiel ist die Direktive, dass alkoholische Getränke nach Bahrain verkauft werden dürfen (obwohl es sich dabei um ein islamisches Land handelt). Diese Direktive setzt somit eine andere Direktive (ein Verbot) zumindest teilweise außer Kraft. Die Formulierung solcher Ausnahmen kann dann sehr ökonomisch sein, wenn nur wenige Ausnahmen einer anderen Direktive vorliegen. Seitenblick: Wie in Abb. 12.4 ersichtlich, können Direktiven gleichzeitig nach zwei Kriterien (auch Kategorisierungsschemata genannt) spezialisiert werden: Nach ihrer Formalität, aber auch nach ihrer Verwendung. Dabei handelt es sich um ein fortgeschrittenes Konzept der Faktenmodell-Notation, welches in der Praxis nicht ungebräuchlich ist.
12.3 Schritt für Schritt: Formulierung von Regelungen Wie bereits oben erläutert, treten Direktiven in zwei verschiedenen Formalisierungsgraden auf: Als informale Regelungen sowie als präzise Geschäftsregeln, die aus Regelungen abgeleitet sind. Diese Unterscheidung spielt auch eine Rolle beim Vorgehen zur Identifikation und Formulierung von Direktiven. In diesem Kapitel wird erläutet, wie Regelungen formuliert werden. Kapitel 13 behandelt dann die Formulierung von Geschäftsregeln. 1. Regelungen identifizieren Für die Identifikation potentieller Regelungen und Geschäftsregeln stehen verschiedene der bisher erarbeiten Ergebnisse zur Verfügung, die sich als Quellen von Direktiven nutzen lassen: – Externe Quellen: Dazu zählen in erster Linie gesetzliche Vorgaben sowie Verträge, die mit externen Partnern des Unternehmens abgeschlossen wurden. Beide Arten dieser Regel-Quellen haben den Vorteil, dass sie typischerweise in bereits gut strukturierter Form vorliegen. In dieser ersten Phase der Identifikation relevanter Regelungen und Ge-
116
12 Geschäftswissen
–
–
–
–
schäftsregeln kann man sich auf die Entscheidung beschränken, welche dieser Gesetze und Verträge bei der Abwicklung des Geschäfts zu beachten sind. Handlungsweisen: Direktiven sind im Gegensatz zu Handlungsweisen (Strategien und Taktiken) konkrete Anweisungen bzw. Vorschriften für Personen, die Geschäftsaktivitäten ausführen. Hauptsächlich durch die Präzisierung von Taktiken lassen sich diese systematisch in konkrete Regelungen und Geschäftsregeln umformulieren. Dadurch wird es bei der Abwicklung von Geschäftsaktivitäten erst möglich, sie zu beachten. Auch hier geht es in dieser ersten Phase lediglich um die Identifikation der zu präzisierenden Taktiken. Faktenmodell: Aussagen im Faktenmodell können an bestimmte Bedingungen geknüpft sein oder müssen immer garantiert werden. Als einfaches Beispiel muss in KnowBeer eine Bestellung immer zu genau einem Kunden gehören. Ein komplexeres Beispiel ist die Aussage, dass auf einer Bestellung mindestens 3% Rabatt zu geben sind, falls 20 oder mehr Stück desselben Artikels bestellt werden. Geschäftsaktivitäten: Aus Aufgabenbeschreibungen von Geschäftsaktivitäten kann oft Wissen in Form von Geschäftsregeln extrahiert werden. In vielen Fällen ist es dabei so, dass dieselben Regeln in verschiedenen Geschäftsaktivitäten relevant sind. Genau aus diesem Grund müssen diese Regeln aus den Geschäftsaktivitäten separiert und zentral abgelegt werden. Dadurch werden diese Geschäftsregeln einerseits wieder verwendbar und andererseits konsistent, da sie in jeder Situation einheitlich angewandt werden. Beispielsweise kommen bei KnowBeer in den Geschäftsaktivitäten „Offerte erstellen“ und „Rechnung stellen“ dieselben Mehrwertsteuer-Regeln zur Anwendung. Geschäftsprozesse: Die Ausführung bestimmter Geschäftsaktivitäten kann an Bedingungen geknüpft sein (Aktivierung bzw. Deaktivierung von Geschäftsaktivitäten). Beispielsweise darf bei KnowBeer nur dann eine Bestellung an einen Kunden ausgeliefert werden, wenn sie bezahlt worden ist. Außerdem können Abhängigkeiten zwischen Geschäftsaktivitäten von Bedingungen gesteuert sein (Workflow). In KnowBeer müssen beispielsweise Bestellungen, die einen bestimmten Mindestwert überschreiten, durch einen Vorgesetzten geprüft werden.
12.3 Schritt für Schritt: Formulierung von Regelungen
117
2. Regelungen beschreiben Die gefundenen Regelungen sollen unter Verwendung des Unternehmensvokabulars kurz und prägnant beschrieben werden. Aus einer solchen Beschreibung soll ersichtlich sein, ob es sich bei der Regelung um eine Verpflichtung, ein Verbot oder eine Erlaubnis handelt. Jede einzelne Regelung kann nun in Beziehung zu anderen Ergebnissen gesetzt werden. Die wichtigsten dieser Beziehungen sollen Auskunft über folgende Fragen geben: – Woher stammt die Regelung, bzw. woher wurde sie hergeleitet? – Wer ist für die Regelung inhaltlich zuständig? – Welche Geschäftsaktivitäten werden durch die Regelung beeinflusst bzw. gesteuert? – Aus welchen „kleinen“ Regelungen setzt sich eine „große“ Regelung zusammen? Wie im Kapitel 13 erläutert, werden Regelungen später durch spezifische Geschäftsregeln konkretisiert, wodurch sie ausführbar und überprüfbar werden. Eine Regelung ist im Allgemeinen so formuliert, dass sie nicht direkt umgesetzt werden kann. Beispielsweise kann eine Regelung besagen, dass Verkäufer einen Bonus erhalten, der sich aus dessen Umsatz und Dienstalter zusammensetzt. Erst spezifische Geschäftsregeln legen aber fest, wie ein solcher Bonus konkret zu berechnen ist. 3. Unternehmensvokabular aktualisieren In den Beschreibungen der Regelungen tauchen oft Begriffe auf, die nicht im Unternehmensvokabular enthalten sind. Daher ist es sinnvoll, nach Abschluss der Formulierung der Regelungen das Unternehmensvokabular mit den neu gefundenen Objektund Fakttypen zu aktualisieren. Tipp:
118
Regelungen werden am besten im Rahmen eines breit abgestützten Workshops erarbeitet. Zu einem solchen Workshop werden idealerweise folgende Teilnehmer eingeladen: Projektsponsor, Projektleiter, Business Analytiker sowie interessierte Fachvertreter aus den betroffenen Bereichen. Ein solcher Workshop wird vorzugsweise auf einen Vormittag angesetzt, damit die Ergebnisse am Nachmittag gleich verarbeiten werden können.
12 Geschäftswissen
12.4 Ergebnis: Auszuarbeitende Regelungen von KnowBeer Tina Reiber hat einige Tage benötigt, um das Ergebnis des Workshops zur Identifikation von Regelungen zu strukturieren und zusammenzufassen. Die folgende Tabelle zeigt, welche Regelungen im Rahmen des Projekts BEGIN genauer betrachtet werden sollen. Außerdem ist auch dokumentiert, woher eine Regelung stammt und wer dafür verantwortlich ist. In der zweiten Kolonne der Tabelle ist neben der Beschreibung der Regelung auch die deontische Klasse der Regelung (Verpflichtung, Verbot oder Erlaubnis) angegeben. Zudem sind in der Beschreibung die verwendeten Begriffe aus dem Unternehmensvokabular kursiv dargestellt. Schließlich sind in der hintersten Kolonne der Tabelle die Geschäftsaktivitäten angegeben, die von der Regelung betroffen sind bzw. durch die Regelung gesteuert werden. Id 1
Regelung
Quelle/Verantwortlich
Steuert Aktivität
Verpflichtung: Die Bestimmung der
Faktenmodell/
Offerte
gültigen Kreditlimite eines Kunden
Buchhaltung
erstellen,
erfolgt in einer einheitlichen und
Tabelle 12.1 Regelungen in KnowBeer
Ware liefern
nachvollziehbaren Art und Weise. 2
Verpflichtung: Die Prüfung der Kredit- Geschäftsprozess
Kredit-
würdigkeit eines Kunden erfolgt in einer
„Einzelverkauf“/
würdigkeit
einheitlichen und nachvollziehbaren Art
Buchhaltung
prüfen
Risiko „Kostenstei-
Lieferanten
und Weise. 3
4
Verpflichtung: Die Auswahl von
Lieferanten erfolgt in einer einheitlichen gerung durch Zwi-
suchen,
und nachvollziehbaren Art und Weise.
schenhändler“/
Lieferanten
Einkauf
evaluieren
Verpflichtung: Die Festlegung, wann
Strategie und Taktik Verfügbarkeit
und wie ein nicht an Lager befindliches
„Lagerführung“/
Produkt vom Lieferanten nachbestellt
Einkauf
prüfen
wird, erfolgt in einheitlicher und nachvollziehbarer Art und Weise. 5
Verpflichtung: Die Bestimmung des
Faktenmodell/
Konditionen
offiziellen Stückpreises eines Artikels
Einkauf
aushandeln
erfolgt in einer einheitlichen und nachvollziehbaren Art und Weise.
12.4 Ergebnis: Auszuarbeitende Regelungen von KnowBeer
119
Id 6
Regelung
Quelle/Verantwortlich
Steuert Aktivität Salär auszahlen
Verpflichtung: Verkäufer erhalten
Risiko „Kundenun-
einen umsatz- und dienstalterabhäng-
zufriedenheit wegen
igen Bonus dessen Höhe in einer
Fluktuations-
einheitlichen und nachvollziehbaren Art
rate“/Personalwesen
und Weise bestimmt wird. 7
Erlaubnis: Seniorverkäufer erhalten
Risiko „Kundenun-
hohe, einheitliche und nachvollziehbare
zufriedenheit wegen erstellen
Kompetenzen.
Fluktuations-
Verpflichtung: Die Bestimmung, wie
Strategie
und womit Produkte an den Kunden
„Direktvertrieb“/
versandt werden, erfolgt in einheitlicher
Logistik
Offerte
rate“/Personalwesen 8
Ware liefern
und nachvollziehbarer Art und Weise. 9
Verpflichtung: Das notwendige
Risiko „Kostenstei-
Offerte
Wissen für den Verand von Waren in
gerung durch Rück-
erstellen,
sämtliche von uns belieferten Länder
sendungen“/
Ware liefern
muss bei uns im Haus sein (setzt sich
Logistik
aus Regelungen 10 und 11 zusammen). 10
11
Verpflichtung: Die Deklaration der ins
Risiko „Kostenstei-
Ausland gelieferten Waren erfolgt
gerung durch Rück-
korrekt und in einheitlicher Art und
sendungen“/
Weise.
Logistik
Verpflichtung: Die Bestimmung des
Taktik „Ausliefer-
Zeitpunkts einer Lieferung an einen
ungen“/Logistik
Ware liefern
Ware liefern
Kunden erfolgt in einer einheitlichen und nachvollziehbaren Art und Weise. 12
13
Verbot: Ins Ausland gelieferte Waren
Einfluss
Offerte
dürfen nicht den Einfuhrgesetzen des
„Vorschrift“/
erstellen,
jeweiligen Landes widersprechen.
Rechtsabteilung
Ware liefern
Verpflichtung: Die Bestimmung der
Geschäftsaktivität
Offerte
Konditionen einer Bestellung eines
„Offerte erstellen“/
erstellen,
Kunden erfolgt in einheitlicher und
Verkauf
Rechnung
nachvollziehbarer Art und Weise (setzt
stellen
sich aus Regelungen 14, 15 und 16 zusammen). 14
120
Verpflichtung: Die Bestimmung, ob
Faktenmodell/
Offerte
ein Kunde bevorzugte Konditionen
Verkauf
erstellen,
erhält, erfolgt in einer einheitlichen und
Rechnung
nachvollziehbaren Art und Weise.
stellen
12 Geschäftswissen
Id
Regelung
Quelle/Verantwortlich
Steuert Aktivität
15
Verpflichtung: Die Bestimmung des
Risiko „Reserven-
Offerte
auf eine Bestellung eines Kunden
verbrauch durch
erstellen,
gegebenen Rabatts erfolgt in einheit-
mangelnde Kosten-
Rechnung
licher und nachvollziehbarer Art und
deckung“/ Verkauf
stellen
Taktik
Offerte
Weise. 16
Verpflichtung: Die Abgabe von
Gratismustern bei einer Bestellung eines „Gratismuster“
erstellen,
Kunden erfolgt in einheitlicher und
Rechnung
nachvollziehbarer Art und Weise. 17
stellen
Verpflichtung: Die Verrechnung der
Strategie
Offerte
Versandkosten gegenüber dem Kunden
„Direktvertrieb“/
erstellen,
erfolgt in einheitlicher und
Verkauf
Rechnung
nachvollziehbarer Art und Weise.
stellen
Bei der Beschreibung dieser Regelungen sind einige im Unternehmensvokabular fehlende Begriffe aufgetaucht. Dazu zählen:
Lager (ein neuer Objekttyp) Ware (als Synonym von „Produkt“) bei uns im Haus (als Synonym von KnowBeer) Ausland (als Rolle von „Land“) Seniorverkäufer (eine Spezialisierung eines „Verkäufers“) Kompetenz (ein neuer Objekttyp, vermutlich mit einigen interessanten Spezialisierungen) Deklaration (ein neuer Objekttyp, vermutlich mit einigen interessanten Spezialisierungen) Kondition (ein neuer Objekttyp mit den Spezialisierungen „Lieferfrist“ und „Rabatt“) kreditwürdig (einwertiger Fakttyp zum Objekttyp „Kunde“) bestellt nach (zweiwertiger Fakttyp zwischen „Produkt“ und „Lieferant“, ev. sogar dreiwertiger Fakttyp, falls die Nachbestellung durch einen spezifischen Mitarbeiter erfolgt) Einfuhrgesetz (entweder ein neuer Objekttyp oder sogar eine eigenständige Regelung)
12.4 Ergebnis: Auszuarbeitende Regelungen von KnowBeer
121
12.5 Wie geht es weiter? Nun sind mit den gefundenen Regelungen und dem aktualisierten Unternehmensvokabular die Voraussetzungen geschaffen, die Regelungen mittels verschiedener Geschäftsregeln zu konkretisieren. Im Gegensatz zu den relativ informal formulierten Regelungen werden Geschäftsregeln wesentlich formaler und damit präziser beschrieben. Genau dies ist der Schwerpunkt des nächsten Kapitels.
122
12 Geschäftswissen
13 Geschäftsregeln
Geschäftsregeln konkretisieren Regelungen und machen diese dadurch bei der Ausführung von Geschäftsaktivitäten anwendbar. In diesem Kapitel wird aufgezeigt, welche Arten von Geschäftsregeln unterschieden werden können und welche Möglichkeiten bestehen, Geschäftsregeln in präziser, aber dennoch verständlicher Weise zu formulieren.
13.1 Ausgangslage: Wie hoch ist ein Rabatt? Da Tina Reiber ihren größten Kundenauftrag dieses Jahres abgeschlossen hat, beschließt sie, sich wieder einmal ein Mittagessen in der Kantine zu gönnen. An der Kasse trifft sie auf Benno Remser und sie setzen sich zusammen an einen Tisch: T. Reiber:
B. Remser: T. Reiber:
B. Remser:
T. Reiber:
Ich habe heute Morgen meinen größten Kundenauftrag in diesem Jahr abgeschlossen: Die RestaurantKette „Speis und Trank“ hat bei uns ein Abonnement für drei verschieden Biersorten mit garantiertem Mindestumsatz von 220.000 Euro pro Jahr bestellt. Gratuliere! Habt ihr den Mindestumsatz vertraglich vereinbart? Selbstverständlich! Und es ist wahrscheinlich, dass der tatsächliche Umsatz je nach Sommer noch gut und gerne 30.000 Euro höher sein wird! Nach meiner Erfahrung wird der Mindestumsatz allerdings oft zum tatsächlichen Umsatz, da sich diese Restaurant-Besitzer häufig überschätzen, speziell nach einem solchen warmen Sommer wie im letzten Jahr. Übrigens: Handelt es sich bei den 220.000 Euro um den Brutto- oder den Nettoumsatz? Brutto – davon müssen selbstverständlich noch die 8% Volumenrabatt abgezogen werden.
13 Geschäftsregeln
123
B. Remser: T. Reiber:
B. Remser:
T. Reiber:
Habt ihr diese 8% auch für den Betrag vereinbart, der die 220.000 Euro übersteigt? Nein, übersteigt der tatsächliche Umsatz den Minimalumsatz, dann gelten 10% Rabatt – ich will ja den Kunden animieren, möglichst viel Umsatz zu machen! Aber das heißt, dass der Kunde im Fall eines tatsächlichen Bruttoumsatzes von 218.000 Euro – lass mich rechnen – 200.560 Euro bezahlen muss und bei einem tatsächlichen Bruttoumsatz von 222.000 Euro lediglich 199.800 Euro! Wenn er also mehr bestellt, bezahlt er weniger! Hmm, das stimmt… irgendetwas kann mit unserer Rabattpolitik nicht stimmen!
Nach längerer Diskussion am Mittagstisch beschließen T. Reiber und B. Remser, am folgenden Tag zusammen zu sitzen und gemeinsam eine einheitliche Rabattpolitik zu formulieren.
13.2 Lösungsansatz: Geschäftsregeln Wie bereits in Kapitel 12.2 eingeführt, ist eine Geschäftsregel eine einzelne Direktive, welche eine geschäftsrelevante Vorschrift oder ein geschäftsrelevantes Verbot darstellt und daher bei der Ausführung von Geschäftsaktivitäten beachtet werden muss. Im Gegensatz zu einer Regelung ist eine Geschäftsregel sofort und ohne weitere Erklärungen oder Interpretationen anwendbar. Für eine Geschäftsregel sind folgende Eigenschaften essentiell:
124
Geschäftsregeln müssen so präzise sein, dass sie eineindeutig sind und keinen Interpretationsspielraum offen lassen. Geschäftsregeln müssen für Mitarbeiter von Fachabteilungen verständlich sein, es darf kein spezielles Sprachwissen für deren Interpretation notwendig sein. Geschäftsregeln müssen deklarativ formuliert sein, d.h. sie sollen lediglich beschreiben was gelten soll, nicht aber, wie es zu erreichen ist.
13 Geschäftsregeln
Seitenblick: Die Unterscheidung, ob eine Formulierung prozedural oder deklarativ ist, ist nicht ganz einfach. Dazu muss die Frage gestellt werden, ob bei der Formulierung der Geschäftsregeln innerhalb einer Regelung die Reihenfolge relevant ist. Bekommen beispielsweise zwei Geschäftsregeln eine andere Bedeutung, wenn ihre Reihenfolge umgedreht wird, so liegt eine prozedurale Formulierung vor. So ist zum Beispiel die folgende Formulierung prozedural, da eine andere Reihenfolge dieser Anweisungen zu einem anderen Preis führen würde: Der Preis einer Bestellung errechnet sich in folgenden Schritten: 1. Reduktion des aktuellen Preises der Bestellung um den Kundenrabatt in Prozent 2. Addition der Versandkosten zum aktuellen Preis der Bestellung, falls diese eine Destination im Ausland hat. Demgegenüber ist die folgende Formulierung deklarativ: 1. Der Nettopreis einer Bestellung ergibt sich aus dem Bruttopreis minus Kundenrabatt in Prozent. 2. Der Endpreis einer Bestellung ergibt sich aus dem Nettopreis plus Versandkosten, falls die Bestellung eine Destination im Ausland hat. 3. Der Endpreis einer Bestellung entspricht dem Nettopreis, falls die Bestellung eine Destination im Inland hat. Die drei Geschäftsregeln könnten auch in beliebig anderer Reihenfolge formuliert werden, ohne dass sich deren Bedeutung ändert. Der Vorteil deklarativer Formulierungen liegt darin, dass sie viel einfacher gewartet werden können: Es können Geschäftsregeln sukzessive hinzugefügt oder entfernt werden, ohne Rücksicht auf deren Position innerhalb einer Regelung. In der deklarativen Form steht jede einzelne Geschäftsregel innerhalb einer Regelung für sich alleine. Geschäftsregeln können auf verschiedene Art und Weise dokumentiert werden. Weiter unten werden wir einige Möglichkeiten zur präzisen Formulierung von Geschäftsregeln betrachten. Zuvor müssen wir allerdings noch die verschiedenen Typen von Geschäftsregeln einführen.
13.2 Lösungsansatz: Geschäftsregeln
125
13.2.1 Klassifikation von Geschäftsregeln Wie Abb. 13.1 zeigt, können Geschäftsregeln weiter in folgende Kategorien unterteilt werden:
Abb. 13.1 Geschäftsregeln
Einschränkung:: Eine Aussage über das Geschäft, welche immer wahr sein muss. Zum Beispiel gibt es bei KnowBeer die Regel, dass der Gesamtbetrag aller offenen Bestellungen eines Kunden zu keinem Zeitpunkt die Kreditlimite des Kunden überschreiten darf. Ableitung:: Eine Herleitung neuer fachlicher Information aufgrund bekannter fachlicher Information. Beispielsweise lässt sich eine Regel formulierten, die besagt, wie ein Kundenrabatt bei einer Bestellung aufgrund verschiedenster bekannter Informationen über den Kunden bestimmt wird. Prozessregel: Eine Anweisung die besagt, dass in gewissen Situationen gewisse Aktionen ausgeführt werden müssen, dürfen oder aber nicht ausgeführt werden dürfen. Beispielsweise darf bestellte Ware erst an einen Kunden ausgeliefert werden, nachdem die Zahlung eingegangen ist.
Geschäftsregel
Durchsetzung von
Taktik
Einschränkung
Ableitung
Prozessregel
Eine Geschäftsregel ist mit einem Durchsetzungsgrad versehen. Dieser besagt, welche Folgen die Zuwiderhandlung gegen die Geschäftsregel hat, bzw. unter welchen Voraussetzungen eine Zuwiderhandlung zulässig ist. In der Praxis kann oft eine Taktik für die Durchsetzung einer Geschäftsregel definiert werden.
13.2.2 Entscheidungstabellen Entscheidungstabellen sind eine Darstellungsform zur Beschreibung von Entscheidungsprozessen. Solche Tabellen sind bereits seit mehreren Jahrzehnten bekannt. Entscheidungstabellen fassen in sehr kompakter Art und Weise alle relevanten Bedingungen eines Themas (z.B. einer Regelung) und die daraus zu schließenden Folgerungen zusammen.
126
13 Geschäftsregeln
Im Verlaufe der Jahre sind verschiedene Formen von Entscheidungstabellen mit verschiedenen Vor- und Nachteilen entstanden. Wir beschränken uns im Hauptteil des Buches lediglich auf eine Form, weitere Varianten von Entscheidungstabellen sind im Anhang D.1 zu finden. Eine Entscheidungstabelle weist folgende Struktur auf: Regel
1
2
3
4
...
n
Bedingung Kriterium 1
Wert 1-1
x
Wert 1-2 Kriterium 2
Wert 2-1
x x
x
…
x
x
Wert 2-2
x
Wert 2-3
Tabelle 13.1 Entscheidungstabelle
x
x x
…
Folgerung Kriterium X
Wert X-1
x
Wert X-2 Kriterium Y
Wert Y-1 Wert Y-2
…
x x
x
x x
x x
…
Eine solche Entscheidungstabelle repräsentiert eine ganze Menge von einzelnen Regeln der Form wenn dann oder, etwas detaillierter betrachtet wenn dann
und und und und
Jeder dieser Regeln ist durch eine einzelne Kolonne dargestellt (1, 2, … n). Sowohl Teil-Bedingungen und als auch Teil-Folgerungen bestehen aus Kriterien und ihren möglichen Werten, die aus dem Faktenmodell stammen. Durch Kreuze in den Regel-Kolonnen kann nun festgelegt werden, welche Kombination von Teil-Bedingungen zu welcher Kombination von Teil-Folgerungen führt. Die in einer Regel relevanten Teil-Bedingungen und TeilFolgerungen (jeweils durch Kreuze markiert) sind als logische „UND“-Verknüpfungen zu verstehen. Demgegenüber sind die einzelnen Werte eines Kriteriums als logische „ODER“-Verknüpfung zu verstehen. Beispielsweise lässt sich Kolonne 2 aus obiger Entscheidungstabelle auch als folgende Regel darstellen:
13.2 Lösungsansatz: Geschäftsregeln
127
wenn dann
Kriterium 1 ist Wert 1-2 und Kriterium 2 ist Wert 2-1 oder Wert 2-3 Kriterium X ist Wert X-2 und Kriterium Y ist Wert Y-1
Die folgende Tabelle zeigt ein einfaches Beispiel einer Entscheidungstabelle die festlegt, welches Freizeitprogramm an einem freien Sonntag zur Anwendung kommen soll: Tabelle 13.2 Entscheidungstabelle „Freizeitprogramm“
Regel
1
2
3
4
5
6
7
Bedingung Tageszeit
Vormittag
Wetter
x
x
Nachmittag
x
Abend
x
Regen
x
x x
x x
x
x
Bedeckt
x
x
x
Sonnig
x
x
x
x
Folgerung Tätigkeit
Schlafen
x
Spazieren Kino
x x
x
x
Fernsehen Alternative
Schlafen
x
Spazieren
x
Kino Fernsehen
x x
x
x
Auch hier können die einzelnen Kolonnen wieder als Regeln formuliert werden, was im Falle der Kolonne 2 so aussehen würde: wenn dann
Tageszeit ist Nachmittag oder Abend und Wetter ist Regen Tätigkeit ist Kino und Alternative ist Fernsehen
Obwohl in erster Linie für Ableitungen verwendet, eignen sich Entscheidungstabellen grundsätzlich für alle Arten von Geschäftsregeln. Einerseits kann die Folgerung auch direkt als Aufforderungen zu Aktivitäten verstanden werden (wie in obigem Beispiel) um damit Prozessregeln auszudrücken. Andererseits können die ausgefüllten Kolonnen als (ausschließlich) erlaubte Kombination von Kriterien interpretiert werden um damit Einschränkungen auszudrücken. So wäre es beispielsweise nach dieser Interpretation nicht erlaubt, am Vormittag ins Kino zu gehen.
128
13 Geschäftsregeln
13.2.3 Formales Deutsch Eine weitere mögliche Darstellungsform für Geschäftsregeln ist das „formale Deutsch“27. Dabei handelt es sich um eine textuelle Darstellungsform, die weitgehend ohne Vorkenntnisse lesbar, aber trotzdem präzise und unmissverständlich ist. Sie basiert einerseits auf Textschablonen für verschiedene Arten von Regeln und andererseits auf einem Satz vordefinierter Schlüsselworte und Fakttypen. Diese Textschablonen sehen wie folgt aus:
Textschablone für Ableitungen Die Textschablone für eine Ableitung in formalem Deutsch weist folgende Struktur auf: : , falls alle folgenden Bedingungen erfüllt sind: „UND“ Verknüpfung … . stellt eine Bezeichnung dar, die eine eindeutige Identifikation der Geschäftsregel innerhalb einer Regelung erlaubt. Sowohl als auch die bis sind Aussagen, die Begriffe aus dem Faktenmodell verwenden. Soll für eine Folgerung eine einzelne Aussage nicht erfüllt sein, lässt sich die Phrase „ist nicht wahr“ hinter die Bedingung anhängten. Seitenblick: Diese Regeln haben die Struktur „ falls “. Vor allem in der Programmierung ist aber auch eine andere Struktur üblich: „wenn dann “. Obwohl die beiden Formen semantisch identisch sind, ziehen wir in diesem Buch die Erstere vor. Wir denken, dass sie eher dem natürlichen Denkprozess entspricht und die zweite Form sich bereits zu stark an IT-Lösungen (oder gar Programmiersprachen) orientiert. Das folgende Beispiel zeigt eine Ableitung, mit welcher der Rabatt einer Bestellung bestimmt wird:
27
Oder selbstverständlich auch jede andere natürliche Sprache
13.2 Lösungsansatz: Geschäftsregeln
129
r1: Bestellung hat Rabatt 10%, falls alle folgenden Bedingungen erfüllt sind: Bestellung hat Destination „Schweiz“ ist nicht wahr Bestellung hat Bruttopreis BP BP größer als 500 €. Dieses Beispiel zeigt auch die Verwendung von Platzhaltern28. Ein Platzhalter steht an Stelle eines Objekttyps und ist typischerweise in Grossbuchstaben geschrieben. Mittels Platzhalter lassen sich mehrere Teile einer Regel untereinander durch gemeinsame Werte verbinden: In obigem Beispiel repräsentiert der Platzhalter „BP“ einen beliebigen Bruttopreis einer Bestellung, der aber mindestens 500 € sein muss. In dieser Form stellt die Bedingung eine logische „UND“Verknüpfung dar. Soll eine logische „ODER“-Verknüpfung dargestellt werden, so ist lediglich der Text der ersten Zeile zu ersetzen. : , falls mindestens eine der folgenden Bedingungen erfüllt ist: „ODER“ Verknüpfung … . Seitenblick: Wie wir bereits bei den Entscheidungstabellen gesehen haben, ist die Klassifikation einer Regel als Ableitung oder als Einschränkung fließend. Dies wird im folgenden Beispiel offensichtlich: r1: Bestellung hat Rabatt höchstens 10%, falls alle folgenden Bedingungen erfüllt sind: Bestellung hat Destination „Schweiz“ Bestellung hat Bruttopreis BP BP größer als 500 €. Der einzige Unterschied zur vorherigen Regel r1 liegt darin, dass es nun „Bestellung hat Rabatt höchstens 10%“ heißt statt „Bestellung hat Rabatt 10%“. Damit sagt sie dem Leser nicht mehr, wie viel Rabatt genau zu geben ist, sondern schränkt lediglich seine persönliche Wahl des Rabatts ein.
28
Platzhalter werden oft auch als Variable bezeichnet. Um eine Verwechslung mit dem Konzept einer Variablen einer Programmiersprache zu vermeiden, bleiben wir aber beim Begriff Platzhalter.
130
13 Geschäftsregeln
Textschablone für Prozessregeln: Prozessregeln kommen in zwei Varianten vor: Bedingungs/AktionsRegeln29 und Ereignis/Bedingungs/Aktions-Regeln30. Bedingungs/ Aktions-Regeln besagen,
welche Aktionen ausgeführt werden müssen (Verpflichtung) welche Aktionen nicht ausgeführt werden dürfen (Verbot) welche Aktionen ausgeführt werden dürfen (Erlaubnis)
falls eine bestimmte Bedingung erfüllt ist. Diese drei Formen stellen wiederum Alternativen aus der deontischen Logik dar, wie wir sie bereits im Kapitel 12.2 kennen gelernt haben. Bedingungs/AktionsRegeln können auf Basis der folgenden Textschablone in formalem Deutsch formuliert werden: : Falls alle folgenden Bedingungen erfüllt sind: „UND“ Verknüpfung … . Dann müssen/dürfen folgende Aktivitäten (nicht) ausgeführt werden: „UND“ Verknüpfung … .
Auch hier ist die Bezeichnung der Regel für deren eindeutigen Identifikation innerhalb der Regelung und bis sind Aussagen, die auf Begriffe aus dem Faktenmodell basieren. bis < Aktion n> sind entweder Geschäftsaktivitäten aus dem Geschäftsprozessmodell oder Aktionen, welche Fakten hinzufügen oder entfernen (siehe dazu auch Kapitel 13.2.4). Je nachdem, ob im einleitenden Text zu den Aktionen „müssen“ oder „dürfen“ verwendet wird und je nachdem ob das in Klammern stehende „nicht“ weggelassen wird, entstehen die drei oben genannten deontischen Alternativen. Das folgende Beispiel zeigt eine Prozessregel, welche die Nachbestellung eines Produktes im Einkauf veranlasst:
29
Bedingungs/Aktions-Regeln werden oft auch Produktionsregeln bezeichnet. 30 Ereignis/Bedingungs/Aktions-Regeln werden oft auch als „ECARegeln“ bezeichnen (aus dem Englischen für „Event/Condition/Action Rule“)
13.2 Lösungsansatz: Geschäftsregeln
131
r1: Falls alle folgenden Bedingungen erfüllt sind: Produkt hat Anzahl an Lager Anzahl kleiner oder gleich 50 Dann müssen folgende Aktivitäten ausgeführt werden: Ware bestellen(Produkt, 200). Für eine Ereignis/Bedingungs/Aktions-Regel müssen zusätzlich die Geschäftsereignisse spezifiziert werden, bei welchen die Regel zur Anwendung kommen soll. Daher weist die Textschablone für Ereignis/Bedingungs/Aktions-Regeln die folgende, erweiterte Struktur auf: : Falls eines der folgenden Ereignisse eintritt: <Ereignis 1> „ODER“ <Ereignis 2> Verknüpfung … <Ereignis n> Und alle folgenden Bedingungen erfüllt sind: „UND“ Verknüpfung … . Dann müssen/dürfen folgende Aktionen (nicht) ausgeführt werden: „UND“ Verknüpfung … . In dieser Form stellen <Ereignis 1> bis <Ereignis n> einzelne Geschäftsereignisse dar, von denen jedes einzelne die Prozessregel auslösen kann. Deshalb sind sie durch eine „ODER“-Verknüpfung verbunden. Das folgende Beispiel zeigt eine Prozessregel, welche bei jedem Kundenkontakt eine Prüfung ausstehender Zahlungen fordert und falls vorhanden den Kunden an die ausstehenden Zahlungen erinnert: r1: Falls eines der folgenden Ereignisse eintritt: Kundenanfrage neue Bestellung Bestellungsänderung Und alle folgenden Bedingungen erfüllt sind: Kunde hat ausstehende Zahlung für Bestellung Dann müssen folgende Aktionen ausgeführt werden: informiere(Kunde, „Zahlung für Bestellung ausstehend“) merke(Kunde wurde erinnert)
132
13 Geschäftsregeln
Die zweite Aktion in dieser Regel („merke(Kunde wurde erinnert)“) verändert die Faktenbasis: Wir merken uns, dass wir den Kunden informiert haben, indem wir sagen, dass das Faktum wurde erinnert für diesen Kunden nun wahr ist.
Textschablone für Einschränkungen Einschränkungen sind Bedingungen, die aus der Perspektive eines einzelnen Objekttyps formuliert sind und immer erfüllt sein müssen. Folgende Textschablone kann zur einheitlichen Formulierung von Einschränkungen verwendet werden: : Für jeden müssen immer alle folgenden Bedingungen erfüllt sein: „UND“ Verknüpfung … . Selbstverständlich lassen sich Einschränkungen auch mittels einer „ODER“-Verknüpfung formulieren: : Für jeden muss mindestens immer eine der folgenden Bedingungen erfüllt sein: „ODER“ Verknüpfung … . Das folgende Beispiel zeigt eine Einschränkung, die den Gesamtwert einer Bestellung einschränkt: r1: Für jede Bestellung müssen alle folgenden Bedingungen immer erfüllt sein: Bestellung hat Nettopreis NP mindestens eine der folgenden Bedingungen ist erfüllt: Bestellung ist express ist nicht wahr alle folgenden Bedingungen sind erfüllt: Bestellung ist express NP weniger als 1.000 € Dieses Beispiel zeigt außerdem einen Fall, in dem eine aus „UND“und „ODER“-Verknüpfungen geschachtelte Bedingungen zur Anwendung kommt. In diesem Beispiel könnte die Zeile „Bestellung ist express“ sogar ersatzlos gestrichen werden: Würde sie allerdings weggelassen, so wäre die Regel dadurch schwerer verständlich.
13.2 Lösungsansatz: Geschäftsregeln
133
Seitenblick: In Bedingungen ist die Formulierung von gewissen Aussagen manchmal etwas schwerfällig, insbesondere, wenn numerische Objekttypen involviert sind. Um beispielsweise den Maximalwert einer Bestellung zu begrenzen, müssten die folgenden Bedingungen formuliert werden: Bestellung hat Nettopreis NP NP weniger als 2.000 € Durch die Verwendung der funktionalen Form lassen sich solche Bedingungen jedoch wesentlich vereinfachen: Bestellung hat Nettopreis weniger als 2.000 € Diese Form erhält man durch folgende Schritte aus der ersten Form: Weglassen des zweiten Objekttyps beim zweiwertigen Fakttyp der ersten Aussage ÖBestellung hat Nettopreis, was den Wert der Bestellung ergibt. Dieser neue Ausdruck wird als Ganzes anstelle des ersten Objekttyps der zweiten Aussage gesetzt ÖBestellung hat Nettopreis weniger als 2.000 € Es wurden nur noch die wirklichen Objekttypen unterstrichen ÖBestellung hat Nettopreis weniger als 2.000 € Neben den allgemeinen Textschablonen für Einschränkungen sind auch Textschablonen für Kardinalitäts-Einschränkungen gebräuchlich. Diese haben folgende Form:
134
:
Jede(r/s) genau ein(e/er/en/em)
:
Jede(r/s) mindestens ein(e/er/en/em)
:
Jede(r/s) mindestens
:
Jede(r/s) höchstens ein(e/er/en/em)
:
Jede(r/s) höchstens
13 Geschäftsregeln
Die folgenden Beispiele zeigen einige typische KardinalitätsEinschränkungen aus KnowBeer: r1:
Jede Bestellung gehört zu genau einem Kunden
r2:
Jede Lieferung bezieht sch auf mindestens eine Bestellung
r3:
Jeder Kunde hat mindestens zwei Betreuer
r4:
Jeder Artikel hat höchstens einen Preis
r5:
Jedes Produkt hat höchstens zwei Lieferanten
Seitenblick: Kardinalitäts-Einschränkungen sind auch aus anderen Modellierungstechniken wie der Unified Modeling Language (UML) oder der Datenmodellierung bekannt. In diesen Techniken werden sie in graphischer Form als Eigenschaften von Beziehungen dargestellt. Im Gegensatz dazu werden beim Business Rules Ansatz Elemente des Vokabulars (wie das Faktenmodell) sowie Regeln (wie Einschränkungen) strikte auseinander gehalten.
Textschablone für Berechnungen Eine spezielle Form des formalen Deutsch, die insbesondere für Ableitungen sinnvoll ist, sind Berechnungen. Damit sind einerseits numerische Berechnungen wie die Bestimmung des Gesamtpreises einer Bestellung, aber auch nicht-numerische „Berechnungen“, wie die Bildung des vollen Namens eines Kunden aus dessen Vor- und Nachname. Eine Berechnung lässt sich auf der Basis der folgenden Textschablone präzise formulieren: : , wobei … . Die eigentliche Berechnung wird mittels spezifiziert und das Ergebnis als zweiter Objekttyp von interpretiert. Damit die in der Formel verwendeten Elemente auch in der für Formeln üblichen Schreibweise verwendet werden können, werden in den darauf folgenden Aussagen Platzhalter „gefüllt“, die sich dann in der verwenden lassen. Diese Platzhalter können wiederum sprechende Namen haben, oder auch lediglich Abkürzungen. Abkürzungen haben den Vorteil, dass Formeln kompakter werden.
13.2 Lösungsansatz: Geschäftsregeln
135
Als einfaches Beispiel sei hier die Berechnung des Verkaufspreises eines Artikels mit Rabatt aufgezeigt: r1: Artikel hat Verkaufspreis EP * 1.20 * (100 - R) / 100, wobei Artikel hat Einstandspreis EP Artikel hat Rabatt R
In gewissen Fällen kann die zur Berechnung zu verwendende Formel von Bedingungen abhängig sein. In diesen Situationen kann die folgende Textschablone verwendet werden: : , wobei … < Platzhalter > falls alle folgenden Bedingungen erfüllt sind: „UND“ Verknüpfung … . Somit ließe sich das obige Beispiel auch folgendermaßen erweitern: r1: Artikel hat Verkaufspreis EP * 1.20 * (100 - R) / 100, wobei Artikel hat Einstandspreis EP Artikel hat Rabatt R falls alle folgenden Bedingungen erfüllt sind: Artikel ist Standardartikel. r2: Artikel hat Verkaufspreis EP * 1.25, wobei Artikel hat Einstandspreis EP falls alle folgenden Bedingungen erfüllt sind: Artikel ist Standardartikel ist nicht wahr.
13.2.4 Vordefinierte Fakttypen und Aktionen Wie bereits in den bisherigen Beispielen ersichtlich, kommen in Bedingungen von Regeln oft auch Fakttypen vor, die nicht aus dem Faktenmodell stammen. Beispielsweise kommt der Fakttyp kleiner oder gleich in der Bedingung
Anzahl kleiner oder gleich 50
in keinem Teil des Faktenmodells von KnowBeer vor, da der Fakttyp kleiner oder gleich nicht KnowBeer-spezifisch ist. Man kann eine ganze Reihe solcher vordefinierter Fakttypen definieren, etwa „Datum früher als Datum“ oder „Werttyp zwischen Werttyp und
136
13 Geschäftsregeln
Werttyp“. Im Anhang D.4 ist eine Liste solcher vordefinierter Fakttypen zu finden. Eine ähnliche Situation liegt bei Aktionen in Prozessregeln vor. Wenn dort nicht Geschäftsaktivitäten aus dem Geschäftsprozessmodell referenziert werden, so können auch Aktionen aus den folgenden vordefinierten Aktionen verwendet werden:
merke Deklariert die als wahr, zum Beispiel merke Bestellung #715 gehört zu Hr. Meier merke ist nicht wahr Deklariert die als falsch, zum Beispiel merke Bestellung #715 hat Destination USA ist nicht wahr vergiss Deklariert die als unbekannt, zum Beispiel vergiss Bestellung #715 hat Destination USA informiere <wen> über Schickt die Information an <wen>, zum Beispiel informiere Benutzer über „Kunde hat Kreditlimite überschritten!“
Insbesondere bei der Formulierung von Aktionen ist nicht um jeden Preis eine absolute Formalität anzustreben. Solange die korrekten Namen von Geschäftsaktivitäten verwendet werden und sonstige verwendete Begriffe nicht im Widerspruch zum Unternehmensvokabular stehen, dürfen Aktionen auch informal beschrieben werden. Seitenblick: Der Unterschied zwischen der Aktion „merke ist nicht wahr“ und der Aktion „vergiss “ ist sehr subtil. Im ersten Fall merken wir uns, dass die Aussage falsch ist. Hier wird die so genannte Open World Semantik vorausgesetzt: Wir können unterscheiden, ob eine Aussage wahr ist, ob sie falsch ist, oder dass wir nichts darüber wissen (dreiwertige Logik). Im zweiten Fall wissen wir nach dem Ausführen der Aktion nicht mehr, ob die Aussage wahr oder falsch ist. Hier genügt die so genannte Closed World Semantik, in der wir automatisch annehmen, dass etwas falsch ist, wenn wir nichts darüber wissen (zweiwertige Logik).
13.3 Schritt für Schritt: Formulierung von Geschäftsregeln Es gibt zwei Hauptphasen, in denen Geschäftsregeln formuliert werden: Einerseits müssen Geschäftsregeln erstmalig bei der Externalisierung des Geschäftswissens dokumentiert werden. Andererseits
13.3 Schritt für Schritt: Formulierung von Geschäftsregeln
137
muss dieses externalisierte Geschäftswissen ständig gepflegt und neuen Gegebenheiten angepasst werden. Der Prozess zur Identifikation und Formulierung von Geschäftsregeln ist in beiden Fällen derselbe und kann in folgende Schritte unterteilt werden: 1. Regelungen priorisieren Grundlage zur Formulierung von Geschäftsregeln bilden die für das Unternehmen als „relevant“ eingestuften Regelungen. Um einen „Big Bang“-Ansatz zu vermeiden, sollten diese identifizierten Regelungen priorisiert und zu handhabbaren Gruppen zusammengestellt werden. Bei der Auswahl der auszuarbeitenden Regelungen sind der Nutzen und die Wichtigkeit der Regelungen zu beachten: – Compliance: Sind für das Unternehmen plötzlich neue innere oder äußere Einflussfaktoren wichtig? Gibt es beispielsweise neue Compliance-Anforderungen für das Unternehmen? In diesen Fällen müssen oft neue Regelungen erarbeitet und eingeführt werden, um mit den neuen Einflussfaktoren richtig umzugehen. – Agilität: Muss das Unternehmen schneller auf veränderte Markteinflüsse reagieren? Typische Bespiele sind hier die Bereitstellung flexibler Angebotspakete und Preisstrategien als Reaktion auf die Konkurrenz. In solchen Fällen muss versucht werden, diese Regelungen so weit zu formalisieren, dass sie sich mittels Business Rules Technologie (siehe Teil III dieses Buches) flexibel automatisieren lassen. – Motivation: Führt fehlendes Wissen bei Mitarbeitern zu größeren, ev. finanziellen Problemen oder Argumentierungs-Schwierigkeiten? In diesen Fällen sind diese Regelungen ebenfalls wichtige Kandidaten zur detaillierteren Ausarbeitung damit geschäftskritische Entscheidungen fundiert getroffen und auch begründet werden können. – Welche der Regelungen sind bereits vorhanden bzw. bereits in Kraft? Diese müssen selbstverständlich nur bei Unklarheiten oder sonstigen Mängeln neu formuliert oder aktualisiert werden. Außerdem lassen sich bereits in diesem frühen Stadium diejenigen Personen bestimmen, welche die Regelungen im Detail ausarbeiten sollen. 2. Regelungen klassifizieren Nachdem die zu detaillierenden Regelungen festgelegt sind, werden sie nach den darin enthaltenen Regeltypen klassifiziert:
138
13 Geschäftsregeln
Ableitungen: Für jede Regelung, die Ableitungen enthält, soll bestimmt werden, welche Fakttypen (gemäß Faktenmodell) durch die Regelung abgeleitet werden. Im Falle von KnowBeer könnte dies beispielsweise für die Regelung 15 (Rabattbestimmung) der Fakttyp „Bestellung hat Rabatt“ sein. – Einschränkungen: Für jede Regelung, die Einschränkungen enthält, soll festgelegt werden, was genau durch die Regelung überwacht wird. So könnte beispielsweise die Regelung 15 (Rabattbestimmung) auch gleichzeitig die Einhaltung von Rabatt-Grenzen überwachen. – Prozessregeln: Für jede Regelung, die Prozessregeln enthält, soll spezifiziert werden, welche Geschäftsaktivitäten durch diese Regelung ausgelöst, ermöglicht oder verhindert werden. Außerdem, welche Fakten durch die Regelung verändert werden. Dieselbe Regelung 15 (Rabattbestimmung) könnte daher beispielsweise die Geschäftsaktivität „Ware liefern“ verhindern, falls der Rabatt einer Bestellung nicht innerhalb der zulässigen Grenzen ist. Bei einem großen Teil der Regelungen dürfte es sich erfahrungsgemäß um Ableitungen handeln.
–
3. Durchsetzungsgrade bestimmen Basierend auf den vorgängigen Regelungs-Klassifizierungen lassen sich die notwendigen Durchsetzungsgrade festlegen. Insbesondere bei Einschränkungen ist zu überlegen, welche Konsequenzen Verletzungen dieser Regelungen haben, bzw. unter welchen Voraussetzungen Verletzungen zulässig sind. Typische Beispiele solcher Durchsetzungsgrade sind etwa (gemäß [OMG05]): – Strikte Durchsetzung: Bei Verletzung der Geschäftsregel kommt immer eine Strafe zur Anwendung. – Aufgeschobene Durchsetzung: Die Befolgung der Geschäftsregel wird strikt durchgesetzt, allerdings kann dies verzögert sein bis Ressourcen mit den notwendigen Fähigkeiten zur Verfügung stehen. – Vorgängige Autorisierung: Die Geschäftsregel wird durchgesetzt, allerdings sind Ausnahmen möglich, falls diese vorgängig autorisiert wurden. – Nachträgliche Rechtfertigung: Wird die Geschäftsregel verletzt und kann diese Verletzung nachträglich nicht gerechtfertigt werden, kommt eine Strafe zur Anwendung. – Mit Begründung: Die Geschäftsregel darf verletzt werden, allerdings muss eine solche Verletzung begründet werden.
13.3 Schritt für Schritt: Formulierung von Geschäftsregeln
139
Empfehlung: Die Geschäftsregel stellt eine reine Empfehlung dar, die nicht durchgesetzt wird. Diese Liste von Durchsetzungsgraden kann als Ausgangslage für eine eigene Liste dienen. Selbstverständlich müssen nicht alle diese Durchsetzungsgrade verwendet werden und es dürfen auch eigene hinzugefügt werden. –
4. Grundlagen identifizieren Jede Regelung basiert auf Informationen aus dem Faktenmodell, welche als Grundlagen in den Regeln verwendet werden. Insbesondere bei Ableitungen lohnt sich die Überlegung, auf welchen Fakttypen die Ableitung basiert, bevor mit der eigentlichen Formulierung der Geschäftsregeln begonnen wird. Für die Bestimmung des Rabatts auf eine Kundenbestellung könnten beispielsweise folgende Fakttypen als Grundlagen verwendet werden: „Bestellung gehört zu Kunde“, „Kunde ist bevorzugt“ und „Bestellung beinhaltet Anzahl von Artikel mit Rabatt Prozent“. 5. Werkzeug zur Verwaltung des Regelkatalogs festlegen Das Geschäftswissen ist ein sehr wertvolles Gut und soll entsprechend behandelt werden. Es empfiehlt sich, schon von Beginn weg ein elektronisches Hilfsmittel zur Erfassung und Verwaltung der Regelungen und Geschäftsregeln einzusetzen. Wenn möglich sollte ein solches Hilfsmittel mindestens folgende Anforderungen erfüllen: – Unterstützung verschiedener Formalismen für die Erstellung und Pflege von Geschäftsregeln (Entscheidungstabellen, formales Deutsch, etc.) – Integration des Unternehmensvokabulars, sodass sich Begriffe aus dem Unternehmensvokabular zur Formulierung von Regeln verwenden lassen und Vokabular-Änderungen konsistent an alle betroffenen Regeln propagiert werden. – Strukturierungs- und Gruppierungsmöglichkeiten für Geschäftsregeln, sodass für deren Verwaltung handhabbare Einheiten gebildet werden können. – Flexible Suchmöglichkeiten nach verschiedenen Kriterien (beispielsweise nach Verwendung bestimmter Fakttypen). – Funktionen zur Publikation der Regelungen, z.B. via Intranet. Die Business Rules Technologie bietet dazu die Gruppe der Business Rules Management Werkzeuge (siehe auch Teil III dieses Buches). Im schlimmsten Fall kann auch eine Textverarbeitungssoftware verwendet werden, welche zumindest einige dieser Anforderungen einigermaßen erfüllt. Problematisch kann die Verwendung eines Werkzeugs zur Geschäftsprozessmodellie-
140
13 Geschäftsregeln
rung als Regelkatalog sein. Diese Werkzeuge dokumentieren Regeln typischerweise als Teil von Geschäftsaktivitäten. Dies widerspricht dem Grundsatz des Business Rules Ansatzes, der die Separierung von Geschäftsregeln von den Geschäftsprozessen postuliert, damit die Regeln widerverwendbar bleiben. 6. Geschäftsregeln erarbeiten Geschäftsregeln können aus verschiedenen Situationen erarbeitet werden. Entweder liegen Sie bereits in irgendeiner Form vor, oder sie müssen aus den Regelungen neu erarbeitet werden. Liegen sie bereits vor, müssen sie auf einheitliche Art (neu-) formuliert und mit dem Unternehmensvokabular abgestimmt werden. Mögliche Quellen für bereits existierende Geschäftsregeln sind unter anderem Arbeitsanweisungen, Richtlinien, Personalhandbücher, aber auch bestehende IT-Applikationen, die bereits heute eine große Anzahl von Geschäftsregeln automatisieren. Bei der Wiederverwendung bereits bestehender Regelungen ist immer darauf zu achten, dass auch diese kritisch hinterfragt werden: Oft sind ältere Geschäftsregeln aufgrund organisatorischer oder technischer Limitationen entstanden, die heute gar nicht mehr zutreffend sind. Solche „Legacy“-Regeln sollten daher nicht mehr in den Regelkatalog übernommen werden sondern nur essentielle Geschäftsregeln, die auch tatsächlich der aktuellen Geschäftsmotivation entsprechen. 7. Unternehmensvokabular aktualisieren Durch die explizite Formalisierung von Geschäftsregeln entstehen oft neue Erkenntnisse über Begriffe, Objekttypen oder Fakttypen, die in dieser Form noch nicht im Unternehmensvokabular enthalten sind. Aus diesem Grund sollte nach jeder Aktualisierung von Regelungen auch das Unternehmensvokabular überprüft und ggf. auf den neuesten Stand gebracht werden. Seitenblick Bei der Suche nach Geschäftsregeln können (neben weiteren) zwei Quellen unterschieden werden: Produktbeschreibungen enthalten Geschäftsregeln, die Eigenschaften von Produkten beschreiben (z.B. Preis- und Rabattpläne von Artikeln, Produktoptionen oder Regeln zur möglichen Kombination von Produkten). Arbeitsabläufe (Workflows) enthalten Geschäftsregeln, die unabhängig von Produkten festlegen, wann welche Geschäftsaktivitäten zu tun oder zu unterlassen sind.
13.3 Schritt für Schritt: Formulierung von Geschäftsregeln
141
Der Unterschied zwischen diesen beiden Quellen liegt darin, dass Geschäftsregeln, die Produkte beschreiben, typischerweise in wesentlich größerer Zahl auftreten als Geschäftsregeln, die Arbeitsabläufe beschreiben. Außerdem beziehen sich produktorientierte Regeln oft auf spezifische Exemplare (z.B. „Carlsberg, Flasche“). Bei der Formulierung von Geschäftsregeln geht es nicht unbedingt darum, sämtliche Regeln in einem Schritt zu finden und zu formulieren. Vielmehr basiert der Business Rules Ansatz darauf, dass Geschäftsregeln permanent aktualisiert und gepflegt werden müssen. Viel wichtiger, vor allem im Hinblick auf die spätere Automatisierung der Geschäftsregeln, ist ein stabiles Faktenmodell. Aus diesem Grund ist es bei der Suche nach Geschäftsregeln wichtig, möglichst verschiedenartige Regeln zu suchen, auch wenn diese noch nicht bis ins letzte Detail ausgearbeitet sind. Durch ein möglichst breites Spektrum von Geschäftsregeln werden verschiedenste Anforderungen an das Faktenmodell gestellt, sodass dieses bereits sehr früh möglichst umfassend und stabil wird.
13.4 Ergebnis: Regelungen von KnowBeer Nach einer ganzen Reihe von Workshops mit teilweise heftigen Diskussionen hatte Tina Reiber eine beachtliche Menge von Geschäftsregeln für die wichtigsten Regelungen zusammengetragen. Insbesondere im Zusammenhang mit der Festlegung der verschiedenen Durchsetzungsgrade der Regelungen kamen erste Fragen nach der möglichen Automatisierung mittels IT auf. Tina Reiber erläuterte, dass gerade die möglichst umfassende Automatisierung eines der Hauptziele des Projektes BEGIN sei. Daher sei nach Abschluss dieses fachlich orientierten Projektes vorgesehen, ein IT-orientiertes Projekt zu starten, welches sich um die technischen Belange kümmern soll31. Um die im Folgenden gezeigten Regelungen einfach lesen zu können, sollte in jedem Fall das Faktenmodell von KnowBeer, das in Kapitel 10 erarbeite wurde, beigezogen werden (siehe Abb. 13.2).
31
142
Das IT-orientierte Projekt ist Gegenstand von Teil III dieses Buches.
13 Geschäftsregeln
Dauer
Person
Organisation
hat Alkoholgehalt
Prozent
Betrag «ist Rolle von»
«ist Rolle von»
Produkt
hat Kreditlimite
hat Geschäftsbeziehung seit Kunde
Service
hat Zahlungsprobleme
Abb. 13.2 Faktenmodell der Verkaufsabteilung von KnowBeer
hat Jahresumsatz hat Stückpreis
Anzahl
(Bestellung) beinhaltet (Anzahl) von (Artikel) mit Rabatt (Prozent)
Artikel
ist bevorzugt
hat Minimalrabatt
von beinhaltet
Betrag
Anzahl
ab
gehört zu mit Rabatt hat Bruttopreis
hat Rabatt
Bestellung
Prozent
hat Nettopreis hat Lieferdatum
hat Destination
ist express
(Artikel) hat Minimalrabatt (Prozent) ab (Anzahl)
Land
hat Bestelldatum
hat Versandkosten Datum
Betrag
13.4.1 Übersicht Als erstes wurden gemeinsam die identifizierten Regelungen (siehe Kapitel 12.4) durchgegangen, nach ihrer Dringlichkeit priorisiert, die Priorisierung begründet sowie Verantwortliche für die weitere Ausarbeitung der Regeln festgelegt. Das Ergebnis ist in der folgenden Tabelle zusammengefasst (die bei den Regelungen angegebenen Nummern (Id) beziehen sich auf die in Kapitel 12.4 verwendete Nummerierung der Regelungen): Prio Regelung (Id) H
Kreditlimite (1, 2)
Begründung
Verantwortlich
Verminderung des Verlustrisikos
M. Oney
Tabelle 13.3 Regelungen in KnowBeer
durch ungedeckte Kredite. H
Rabattbestimmung (15)
Vermeidung von Verlusten durch
T. Reiber
zu hohe Rabatte. H
Gratismuster (16)
Möglichst rasche Positionierung
B. Remser
auf den neuen Märkten. M
Bevorzugter Kunde (14)
Gleichbehandlung aller Kunden
T. Reiber
um ungute Gefühle zu vermeiden. M
Verkaufskompetenzen (7) Vermeidung von Kompetenzstreitigkeiten im Verkaufsbereich.
(Personalwesen)
13.4 Ergebnis: Regelungen von KnowBeer
143
Prio Regelung (Id) T
Stückpreis (5)
Begründung
Verantwortlich
Korrekte Berücksichtigung der
R. Abatt
Beschaffungskosten. T
Versandkosten (17)
Korrekte Berücksichtigung der
(Logistik)
Versandkosten.
Bei einigen der ursprünglich identifizierten Regelungen zeigte sich, dass sie sich nur sehr schwer konkretisieren ließen. Dies trifft beispielsweise auf die Regelungen „Lieferantenauswahl“ (3) und „Ausfuhrrestriktionen“ (12) zu. Aus diesem Grund wurde auf ihre detaillierte Ausarbeitung verzichtet.
13.4.2 Durchsetzungsgrade Es wurde beschlossen, Durchsetzungsgrade nicht für jede Geschäftsregel einzeln festzulegen, sondern pauschal pro Regelung. Nach einer ersten Analyse der Regelungen wurden folgende Durchsetzungsgrade für KnowBeer definiert:
Strikte Durchsetzung: Bei Verletzung der Regelung kommt immer eine Strafe zur Anwendung. Vorgängige Autorisierung: Die Regelung wird durchgesetzt, allerdings sind Ausnahmen möglich, falls diese vorgängig nachweisbar autorisiert wurden. Nachträgliche Rechtfertigung: Wird die Regelung verletzt und kann diese Verletzung nachträglich nicht gerechtfertigt werden, kommt eine Strafe zur Anwendung. Qualifizierte Verletzung: Nur berechtigte bzw. explizit dafür qualifizierte Mitarbeiter dürfen der Regelung zuwider handeln. Empfehlung: Die Regelung stellt eine reine Empfehlung dar, die nicht durchgesetzt wird.
Diese Durchsetzungsgrade sind abschließend. Es wurde festgelegt, dass für jede auszuarbeitende Regelung genau einer dieser Durchsetzungsgrade zu spezifizieren ist.
13.4.3 Regelung „Kreditlimite“ Aus den Regelungen 1 und 2 (gemäß Kapitel 12.4) wurden einerseits Geschäftsregeln zur Bestimmung der Kreditlimite eines Kunden ausgearbeitet (alles Ableitungen) und andererseits eine Geschäftsregel zur Einhaltung dieser Kreditlimite (eine Einschränkung) formuliert.
144
13 Geschäftsregeln
Regelung „Kreditlimite“
Tabelle 13.4 Regelung „Kreditlimite“
Legt fest, wie die Kreditlimite eines Kunden bestimmt wird, in-
Beschreibung
nerhalb der ein Kunde offene Rechnungen haben darf. Ableitungen
Kunde hat Kreditlimite Betrag
Einschränkungen
Einhaltung der Kreditlimite
Aktionen
(keine)
Durchsetzung
Strikte Durchsetzung
Grundlagen
Kunde hat Jahresumsatz Betrag
Kunde hat Geschäftsbeziehung seit Dauer
Kunde hat Zahlungsprobleme
Vokabular
Buchhaltung & Verkauf
Verantwortlich
Buchhaltung/M. Oney
Aufgrund der einfachen Bedingungen konnte die Bestimmung der Kreditlimite durch eine Entscheidungstabelle beschrieben werden: Regel
1
2
3
4
5
6
x
x
7
8
9
x
x
10
11 12
Bedingung Kunde hat
<200k €
Jahresumsatz
200…500k € >500k €
x
Kunde hat
< 6 Monaten
Geschäfts-
6…12 Monaten
beziehung seit
> 12…24 Mon.
Tabelle 13.5 Entscheidungstabelle „Kreditlimite“
x
x x
x x
x x
> 24 Monaten
x x
x
Kunde hat
0
Zahlungs-
1
x
probleme
>1
x
x
x
x
x
x
x
x
x
x
x
x x
x
x
x
x
x
x
x
x x
x
x
x
x
x
x
Folgerung Kunde hat
0€
Kreditlimite
500 € 1.000 € 2.000 €
x
x
x
x
Die einzige Schwierigkeit daran war das Kriterium hat Geschäftsbeziehung seit, welches nicht im Faktenmodell enthalten ist. Dieser Fakttyp wurde im Rahmen der Regelung „Bevorzugter Kunde“ (Kapitel 13.4.6) als Ableitung definiert und konnte so für die Bestimmung der Kreditlimite wieder verwendet werden. Die Einschränkung, dass der offene Betrag aller ungelieferten Bestellungen eines Kunden seine Kreditlimite nicht übersteigen darf, wurde in formalem Deutsch formuliert:
13.4 Ergebnis: Regelungen von KnowBeer
145
r1: Für jeden Kunden müssen immer alle folgenden Bedingungen erfüllt sein: Kunde hat Kreditlimite KL S ist Summe von NP in Bestellung gehört zu Kunde Bestellung hat Nettopreis NP Bestellung hat Lieferdatum „undefiniert“. S ist weniger oder gleich KL. Diese Einschränkung ist in verschiedenen Situationen zu überwachen, beispielsweise bei der Erfassung neuer Bestellungen, bei der Änderung bestehender offener Bestellungen oder bei der Änderung der Kreditlimite eines Kunden.
13.4.4 Regelung „Rabattbestimmung“ Die Regelung 15 definiert, wie der Endpreis einer Kundenbestellung bestimmt werden soll. Dabei wurden verschiedene Eigenschaften der Bestellung wie die Stückpreise der bestellten Artikel, Bestellumfang oder der Kundenstatus berücksichtigt. Die Preisberechnungen wurden als Einschränkungen des zulässigen Preisrahmens spezifiziert, sodass dem zuständigen Verkäufer ein gewisser Entscheidungsspielraum offen gelassen wird. Durch die Festlegung der Durchsetzung „qualifizierte Verletzung“ darf ein Verkäufer selbst diesen Spielraum überschreiten, sofern er mit den entsprechenden Kompetenzen ausgestattet ist (sie Regelung „Verkaufskompetenzen“, Kapitel 13.4.7). Tabelle 13.6 Regelung „Rabattbestimmung“
146
Regelung „Rabattbestimmung“ Beschreibung
Legt fest, wie der Gesamtpreis einer Bestellung eines Kunden bestimmt wird und welche Rabatte dabei zulässig sind.
Bestellung hat Rabatt Prozent
Bestellung hat Bruttopreis Betrag
Bestellung hat Nettopreis Betrag
Einschränkungen
Einhaltung der Rabattgrenzen
Aktionen
(keine)
Durchsetzung
Qualifizierte Verletzung
Grundlagen
Bestellung gehört zu Kunde
Bestellung hat Versandkosten Betrag
Bestellung beinhaltet Anzahl von Artikel mit Rabatt Prozent
Artikel hat Stückspreis Betrag
Kunde ist bevorzugt
Ableitungen
Vokabular
Verkauf
Verantwortlich
Verkauf/T. Reiber
13 Geschäftsregeln
Die folgenden Berechnungen wurden in formalem Deutsch spezifiziert und legen fest, in welchem Preisrahmen eine Kundenbestellung liegen muss. Dabei kamen je nach Eigenschaften der Bestellung verschiedene Berechnungsformeln zur Anwendung – es liegen also bedingte Berechnungen vor. Diese Bedingungen basieren unter anderem auf den Fakttyp „Bestellung ist vielfältig“, welcher durch eine eigene Geschäftsregel (r5) beschrieben ist. r1: Bestellung hat Rabatt (BP - NP) / BP * 100, wobei Bestellung hat Bruttopreis BP Bestellung hat Nettopreis NP
r2: Bestellung hat Nettopreis zwischen BP * 0.90 + VK und BP * 0.95 + VK, wobei Bestellung hat Bruttopreis BP Bestellung hat Versandkosten VK falls mindestens eine der folgenden Bedingungen erfüllt ist: Bestellung ist vielfältig falls alle folgenden Bedingungen erfüllt sind: BP mehr als 500 € Bestellung gehört zu Kunde Kunde ist bevorzugt. r3: Bestellung hat Nettopreis zwischen BP * 0.93 + VK und BP * 0.97 + VK, wobei Bestellung hat Bruttopreis BP Bestellung hat Versandkosten VK falls alle folgenden Bedingungen erfüllt sind: Bestellung ist vielfältig ist nicht wahr BP weniger oder gleich 500 € Bestellung gehört zu Kunde Kunde ist bevorzugt. r4: Bestellung hat Nettopreis zwischen BP * 0.95 + VK und BP + VK, wobei Bestellung hat Bruttopreis BP Bestellung hat Versandkosten VK falls alle folgenden Bedingungen erfüllt sind: Bestellung ist vielfältig ist nicht wahr Bestellung gehört zu Kunde Kunde ist bevorzugt ist nicht wahr.
13.4 Ergebnis: Regelungen von KnowBeer
147
r5: Bestellung hat Bruttopreis BP, wobei BP ist Summe von Artikelpreis in Bestellung beinhaltet Anzahl von Artikel mit Rabatt R Artikel hat Stückpreis SP Artikelpreis ist Anzahl * SP * (100 - R) / 100. r6: Bestellung ist vielfältig, falls alle folgenden Bedingungen erfüllt sind: X ist unterschiedliche Anzahl von A in Bestellung beinhaltet … von A mit Rabatt … X mehr als 10. Zur Bestimmung des Mengenrabatts auf einzelne Artikel wurde der Fakttyp „Bestellung beinhaltet N von A mit Rabatt R“ verwendet. Dieser Fakttyp wurde nicht in formalem Deutsch, sondern durch eine einfache Lookup-Tabelle spezifiziert: Tabelle 13.7 Mengenrabatt
Bestellung beinhaltet Anzahl von Artikel mit Rabatt R Anzahl Artikel Rabatt R 1…5
Belhaven Scottish Ale, Flasche 35cl
0%
Belhaven St. Andrews Ale, Flasche 35cl Belhaven Wee Heavy Ale, Flasche 50cl 6…10
(dito)
2%
11…20
(dito)
4%
21…50
(dito)
6%
>50
(dito)
8%
Corona Extra, Flasche 33cl
2%
1…10
Dos Equis Amber, Flasche 33cl 11…50
(dito)
>50
(dito)
3% 4%
1…20
(alle anderen)
0%
21…50
(alle anderen)
2%
>50
(alle anderen)
3%
Diese Tabelle kann sehr einfach den jeweils aktuellen MarketingBedürfnissen angepasst werden, um beispielsweise ein neues Produkt durch einen Sonderrabatt zu propagieren.
148
13 Geschäftsregeln
13.4.5 Regelung „Gratismuster“ Zur Förderung exotischer Biere sollen gemäß Regelung 16 Gratismuster noch unbekannter Biere an Kunden abgegeben werden. Dies wurde durch eine Prozessregel formuliert, die bestimmt, wann einem Kunden welches Produkt in welcher Stückzahl abgegeben werden soll. Regelung „Gratismuster“ Beschreibung
Legt fest, welche und wie viele Gratismuster bei einer Bestellung eines Kunden abzugeben sind.
Ableitungen
Bestellung beinhaltet Anzahl von Artikel mit Rabatt Prozent
Einschränkungen
(keine)
Aktionen
Ergänzung von Bestellungen
Durchsetzung
Strikte Durchsetzung
Grundlagen
Bestellung gehört zu Kunde
Bestellung hat Bruttopreis Betrag
Bestellung beinhaltet Anzahl von Artikel mit Rabatt Prozent
Kunde ist bevorzugt
Vokabular
Verkauf
Verantwortlich
Verkauf/B. Remser
Tabelle 13.8 Regelung „Gratismuster“
Die Prozessregel wurde in formalem Deutsch formuliert, da die Bestimmung des abzugebenden Artikels ein komplexer logischer Ausdruck ist, der sich schlecht mittels Entscheidungstabelle ausdrücken lässt. Dieser Ausdruck bestimmt einen beliebigen Artikel, der diesem Kunden noch nie geliefert wurde. r1: Falls eines der folgenden Ereignisse eintritt: vereinbarter Liefertermin Und alle folgenden Bedingungen erfüllt sind: Bestellung hat Bruttopreis mehr als 200 € Bestellung gehört zu Kunde P ist ein Produkt Es existiert keine andere Bestellung, für die gilt andere Bestellung gehört zu Kunde andere Bestellung beinhaltet … von P mit Rabatt … Dann müssen folgende Aktionen ausgeführt werden: Merke (Bestellung beinhaltet 2 von P mit Rabatt 100%)
13.4 Ergebnis: Regelungen von KnowBeer
149
13.4.6 Regelung „Bevorzugter Kunde“ Die Regelung 14 bestimmt, wann eine Kunde bevorzugt behandelt werden soll. Dies konnte im Wesentlichen durch eine einzige Geschäftsregel (einer Ableitung) festgelegt werden. Tabelle 13.9 Regelung „Bevorzugter Kunde“
Regelung „Bevorzugter Kunde“ Beschreibung
Legt fest, wann ein Kunde bevorzugt behandelt werden muss.
Ableitungen
Kunde ist bevorzugt
Kunde hat Geschäftsbeziehung seit Dauer
Einschränkungen
(keine)
Aktionen
(keine)
Durchsetzung
Strikte Durchsetzung
Grundlagen
Kunde hat Jahresumsatz Betrag
Kunde hat Zahlungsprobleme
Bestellung gehört zu Kunde
Bestellung hat Lieferdatum Datum
Vokabular
Buchhaltung & Verkauf
Verantwortlich
Verkauf/T. Reiber
r1: Kunde ist bevorzugt, falls alle folgenden Bedingungen erfüllt sind: Kunde hat Jahresumsatz mehr als 500k € Kunde hat Geschäftsbeziehung seit mehr als 24 Monaten Kunde hat Zahlungsprobleme 0. In der zweiten Bedingung dieser Geschäftsregel wurde die funktionale Form verwendet, sie hätte auch wie folgt formuliert werden können:
Kunde hat Geschäftsbeziehung seit Dauer Dauer mehr als 24 Monate
Die Geschäftsregel r1 basiert auf dem Fakttyp hat Geschäftsbeziehung seit, welcher durch eine separate (und wieder verwendbare) Geschäftsregel ausgedrückt wird: r2: Kunde hat Geschäftsbeziehung seit M Monaten, wobei M ist Maximum von Dauer in Bestellung gehört zu Kunde Bestellung hat Lieferdatum LD Dauer ist (heute – LD) / 30.
150
13 Geschäftsregeln
13.4.7 Regelung „Verkaufskompetenzen“ Regelung 7 soll die Kompetenzen der Mitarbeiter im Verkaufsbereich unmissverständlich festgelegen. Dabei kam es zu teilweise sehr heftigen Diskussionen, da einerseits nicht klar war, welche Kompetenzen überhaupt zu unterscheiden sind und andererseits, welche Kriterien bei der Vergabe von Kompetenzen eine Rolle spielen. Insbesondere wurde die Frage diskutiert, ob das Kriterium „Geschlecht“ in der Kompetenzregelung zu berücksichtigen ist. Die folgende Zusammenfassung zeigt, dass man sich bei KnowBeer entschieden hat, Kompetenzen unabhängig vom Geschlecht der Mitarbeiter zu regeln: Regelung „Verkaufskompetenzen“ Beschreibung
Legt fest, welche Kompetenzen einem Mitarbeiter im Bereich des Verkaufs zugeordnet sind.
Ableitungen
Mitarbeiter hat Kompetenz Kompetenz
Einschränkungen
Einhaltung der Kompetenzen
Aktionen
(keine)
Durchsetzung
Strikte Durchsetzung
Grundlagen
Mitarbeiter hat Funktion Funktion
Mitarbeiter hat Dienstalter Dauer
Vokabular
Personalwesen
Verantwortlich
Personalwesen
Tabelle 13.10 Regelung „Verkaufskompetenzen“
Für die Formalisierung der Kompetenzregelung wurde eine geringfügig erweiterte Form einer Entscheidungstabelle verwendet. Dabei wurden in den Teil-Folgerungen nicht nur binäre, sondern parametrisierte Kriterien aufgenommen und die jeweiligen Werte der Parameter durch die individuellen Regeln festgelegt. Interessant an dieser Regelung ist auch, dass sich deren Folgerung auf eine andere Regelung bezieht (Regelung 15, siehe Kapitel 13.4.4), ja diese teilweise sogar außer Kraft setzen. Dabei kam auch der KnowBeerspezifische Durchsetzungsgrad „qualifizierte Verletzung“ zur Anwendung, wie er bereits im Kapitel 13.4.2 eingeführt wurde.
13.4 Ergebnis: Regelungen von KnowBeer
151
Tabelle 13.11 Entscheidungstabelle „Verkaufskompetenzen“
Regel
1
2
3
x
x
x
4
5
x
x
Bedingung Mitarbeiter hat
Verkäufer
Funktion
Verkaufsleiter
Mitarbeiter hat
< 1 Jahr
Dienstalter
1…5 Jahre
x
x x
> 5 Jahre
x x
x
Folgerung Mitarbeiter hat
Marketingaktionen bis
Kompetenz
Budget X € initiieren Kundenbesuche bis
0€
5k €
10k €
50k €
10k €
10k €
10k €
DA 0€
Budget X € pro Jahr Preisnachlass bis X%
1k € * 1k € * DA
0%
0%
2%
5%
10%
20 €
50 €
100 €
200 €
500 €
1k €
5k €
10k €
50k €
unlim.
unter Minimum gemäß Regelung 15 Gratismuster bis X € pro Bestellung abgeben Bestellungen bis max. X € alleine visieren DA = Dienstalter in Jahren (parametrisiertes Kriterium)
Als Lesebeispiel besagt etwa Regel 2 in obiger Tabelle, dass ein Verkäufer mit 4 Dienstjahren... Marketingaktionen bis zu 4.000 € initiieren darf ein Budget von 4.000 € für Kundenbesuche hat keinen Preisnachlass gegenüber Regelung 15 gewähren darf pro Bestellung Gratismuster bis maximal 50 € abgeben darf für Bestellungen unter 5.000 € keine Zweitunterschrift benötigt.
152
13 Geschäftsregeln
13.4.8 Regelung „Stückpreis“ Regelung 5 soll den offiziellen Stückpreis eines Artikels aus dessen Einstandspreis ableiten. Regelung „Stückpreis“ Beschreibung
Legt fest, wie der offiziell ausgewiesene Stückpreis eines Artikels ohne irgendwelche Rabatte oder sonstige Abzüge bestimmt wird.
Ableitungen
Artikel hat Stückpreis Betrag
Einschränkungen
(keine)
Aktionen
(keine)
Durchsetzung
Vorgängige Autorisierung
Grundlagen
Artikel hat Einstandspreis Betrag
Artikel hat Herkunftsland Land
Artikel ist Standardartikel
Land ist EU-Mitglied
Vokabular
Einkauf
Verantwortlich
Einkauf/R. Abatt
Tabelle 13.12 Regelung „Stückpreis“
Hier kamen drei verschiedene Berechnungsformeln zur Anwendung (ausgedrückt durch drei verschiedene Geschäftsregeln), welche in formalem Deutsch formuliert wurden: r1: Artikel hat Stückpreis EP * 1.20, wobei Artikel hat Einstandspreis EP falls alle folgenden Bedingungen erfüllt sind: Artikel hat Herkunftsland Land Land ist EU-Mitglied Artikel ist Standardartikel. r2: Artikel hat Stückpreis EP * 1.30, wobei Artikel hat Einstandspreis EP falls alle folgenden Bedingungen erfüllt sind: Artikel hat Herkunftsland Land Land ist EU-Mitglied ist nicht wahr Artikel ist Standardartikel. r3: Artikel hat Stückpreis EP * 1.50, wobei Artikel hat Einstandspreis EP falls alle folgenden Bedingungen erfüllt sind: Artikel ist Standardartikel ist nicht wahr.
13.4 Ergebnis: Regelungen von KnowBeer
153
13.4.9 Regelung „Versandkosten“ Die Bestimmung der Versandkosten einer Kundenbestellung (Regelung 17) wurde durch eine einfache Entscheidungstabelle als Ableitung formuliert. Tabelle 13.13 Regelung „Versandkosten“
Regelung „Versandkosten“ Legt fest, welche Versandkosten für eine Kundenbestellung ver-
Beschreibung
rechnet werden. Ableitungen
Bestellung hat Versandkosten Betrag
Einschränkungen
(keine)
Aktionen
(keine)
Durchsetzung
Nachträgliche Rechtfertigung
Grundlagen
Bestellung hat Stückpreis Betrag
Bestellung hat Destination Land
Bestellung beinhaltet Anzahl von Artikel mit Rabatt Prozent
Bestellung ist express
Land ist EU-Mitglied
Vokabular
Logistik
Verantwortlich
Logistik
Da in der Bestimmung der Versandkosten lediglich die gelieferten physischen Produkte, nicht aber allfällige Dienstleistungen eine Rolle spielen, wurde in der obigen Entscheidungstabelle der Fakttyp „Bestellung hat Produktpreis BP“ verwendet. Dieser Fakttyp wurde wiederum durch eine Ableitung in formalem Deutsch bestimmt. Tabelle 13.14 Entscheidungstabelle „Versandkosten“
Regel
1
2
3
4
x
x
x
x
5
6
7
8
x
x
x
x
9
10
11
12
x
x
x
x
Bedingung Bestellung hat < 100 € Produktpreis
100 € … 300 € > 300 €
Bestellung hat Schweiz Destination
x
x
ist EU-Mitglied x (sonst)
Bestellung ist
nein
express
ja
x x
x
x x x
x
x
x x
x x
x
x x
x
x
x x
x x
x x
x
x
x
x
Folgerung Bestellung hat 0 € Versand-
5€
kosten
10 € 20 € 50 €
154
13 Geschäftsregeln
x x
x x
x
x x
x
x x
x x
r1: Bestellung hat Produktpreis PP, wobei PP ist Summe von Artikelpreis in Bestellung beinhaltet Anzahl von Artikel mit Rabatt R Artikel ist ein Produkt Artikel hat Stückpreis SP Artikelpreis ist Anzahl * SP * (100 - R) / 100.
13.5 Wie geht es weiter? Jetzt, da einige der wichtigen Regelungen von KnowBeer ausformuliert sind, wird klar, dass zwischen einigen dieser Regelungen gewisse Abhängigkeiten bestehen. Um diese Zusammenhänge übersichtlich darzustellen, bietet sich das Konzept der Rule Map an, die eine Art Landkarte über alle Regelungen eines Unternehmens darstellt. Dies ist Gegenstand des folgenden Kapitels.
13.5 Wie geht es weiter?
155
14 Strukturierung
In diesem Kapitel wird aufgezeigt, wie die Regelungen eines Unternehmens strukturiert und übersichtlich dargestellt werden können. Damit steht dem Unternehmen eine Art Landkarte zur Verfügung die einerseits aufzeigt, welche Regelungen im Unternehmen existieren, und andererseits, welche Zusammenhänge zwischen diesen bestehen.
14.1 Ausgangslage: Wer hat hier noch die Übersicht? Am Ende des Workshops zur Erarbeitung der VersandkostenRegelung kommt Benno Remser mit besorgter Miene auf Tina Reiber zu: B. Remser:
T. Reiber: B. Remser:
T. Reiber: B. Remser: T. Reiber:
Jetzt haben wir zwar eine ganze Menge von Regelungen im Detail erarbeitet, aber so langsam verliere ich die Übersicht! Wie meinst du das? Welche Regelungen haben wir eigentlich schon formuliert und noch schlimmer – wie hängen diese zusammen? Wenn ich eine Regelung ändere, auf welche anderen Regelungen hat dies einen Einfluss? Aha, du sprichst die Impact Analyse an! Kann schon sein – aber was meinst du damit? Alle unsere Geschäftsregeln bilden untereinander ein Netzwerk von Abhängigkeiten. Wenn man nun an einem Ort etwas ändert, hat das unter Umständen einen Einfluss auf andere Stellen. Stellt man diese Abhängigkeiten graphisch dar, sieht man sehr einfach, welche Änderungen auf welche anderen Elemente Einfluss haben. Diese Untersuchung nennt man „Impact Analyse“.
14 Strukturierung
157
B. Remser: T. Reiber:
B. Remser: T. Reiber:
Aha, aber wird so ein Netzwerk in der Praxis nicht riesengroß und unübersichtlich? Nicht, wenn man solche Diagramme thematisch ordnet und dadurch klein hält. Außerdem gibt’s noch ein weiteres Diagramm, die „Rule Map“, die wie eine Landkarte alle Regelungen eines Unternehmens aus der Vogelperspektive darstellt. Na ja, ich bin immer noch skeptisch! Am besten zeige ich dir ganz konkret was ich meine. Mit unserem Werkzeug zur Regelverwaltung können wir solche Darstellungen fast vollautomatisch erzeugen!
Am Nachmittag sitzen Tina Reiber und Benno Remser zusammen und versuchen die Zusammenhänge zwischen den bisher erarbeiteten Regelungen darzustellen und zu verstehen.
14.2 Lösungsansatz: Die Rule Map und der Inferenzbaum Bevor wir nun auf zwei Diagramme zur Darstellung von Zusammenhängen zwischen Regelungen bzw. Geschäftsregeln eingehen, müssen noch zwei wichtige Arten von Fakttypen unterschieden werden:
158
Deklarierte Fakttypen: Damit sind Fakttypen gemeint, die ein Unternehmen als Tatsachen mitbekommt, die es „weiß“. Da es sich dabei um durch das Unternehmen festgestellte Tatsachen handelt, können deklarierte Fakttypen auch nicht weiter erklärt werden. Beispielsweise repräsentiert der Fakttyp „Bestellung hat Destination Land“ die Tatsache (den Fakt), dass Bestellung #715 die Destination „Holland“ hat. Warum? Einfach, weil es der Kunde so wollte – es gibt keine weitere Erklärung dazu. Deklarierte Fakttypen müssen vom Unternehmen in irgendeiner Form aufgezeichnet werden, damit sie nicht vergessen gehen. Abgeleitete Fakttypen: Damit sind Fakttypen gemeint, die Informationen repräsentieren, welche ein Unternehmen selber aus anderen Informationen herleiten kann. Diese Herleitungen erfolgen auf der Basis von bewussten Ableitungsregeln die besagen, wie die abgeleiteten Informationen aus anderen Informationen (deklarierten oder abgeleiteten Fakttypen) bestimmt werden können. „Bestellung hat Nettopreis Betrag“ ist beispielsweise ein abgeleiteter Fakttyp, da er sich durch die Regelung „Rabattbestimmung“ (siehe Kapitel 13.4.4) jederzeit herleiten
14 Strukturierung
lässt. Im Gegensatz zu deklarierten Fakttypen müssen abgeleitete Fakttypen nicht aufgezeichnet werden, da sich ihre Aussagen immer wieder herleiten lassen.
14.2.1 Die Rule Map Die Rule Map ist ein Diagramm, das aufzeigt, welche Regelungen existieren, welche Fakttypen diese Regelungen verwenden, welche Geschäftsaktivitäten durch die Regelungen kontrolliert werden und welche Regelungen von welchen Geschäftsereignissen betroffen sind. Sie dient als Landkarte, die einen Blick auf alle relevanten Regelungen eines Unternehmens aus der Vogelperspektive zeigt. Die Notation der Rule Map ist nicht standardisiert, daher existieren zurzeit verschiedenste Varianten. In diesem Buch verwenden wir die Notation wie sie in Abb. 14.1 dargestellt ist. In der Praxis muss allerdings auf die Möglichkeiten des jeweils verwendeten Werkzeugs zur Regelverwaltung Rücksicht genommen werden. «Ableitungen» Regelung «deklariert» deklarierter Fakttyp
Abb. 14.1 Die Rule-MapNotation
«abgeleitet» abgeleiteter Fakttyp
«Prozessregeln» eine andere Regelung «Geschäftsereignis» Geschäftsereignis «Geschäftsaktivität» Geschäftsaktivität
Regelungen werden in der Rule Map als Rechteck mit welliger Unterseite dargestellt. Neben dem Namen der Regelung kann zusätzlich die Art der Regelung («Ableitungen», «Einschränkungen», oder «Prozessregeln») angegeben werden. Fakttypen werden wie auch im Faktenmodell durch einen Rhombus dargestellt. Um abgeleitete Fakttypen von deklarierten Fakttypen zu unterscheiden, ist der abgeleitete Fakttyp zusätzlich durch zwei Linien gekennzeichnet. Eine Geschäftsaktivität wird als abgerundetes Rechteck und ein Geschäftsereignis durch ein Blitzsymbol dargestellt. Diese Grundelemente der Rule Map lassen sich durch Pfeile miteinander verbinden. So kann einerseits gezeigt werden, welche deklarierten Fakttypen eine Regelung verwendet, um daraus abgeleite-
14.2 Lösungsansatz: Die Rule Map und der Inferenzbaum
159
ten Fakttypen zu erzeugen. Andererseits lässt sich zeigen, welches Geschäftsereignis welche Regelung aktiviert und welche Geschäftsaktivitäten dann von dieser Regelung betroffen sind. Dabei ist zu beachten, dass der Bezug zu Geschäftsereignissen und Geschäftaktivitäten nur für Prozessregeln sinnvoll ist. Seitenblick: In der Praxis kann die Anzahl Regelungen in einem Unternehmen sehr groß werden. Daher ist es sinnvoll, nicht unbedingt eine einzige Rule Map für das ganze Unternehmen zu erstellen. Vielmehr sollte man mehrere kleinere Rule Map Diagramme erstellen, die nach thematischen Kriterien gruppiert sind (beispielsweise Rule Map „Verkauf“, Rule Map „Einkauf“, etc.).
14.2.2 Der Inferenzbaum Der Inferenzbaum ist ein Diagramm, welches den direkten Zusammenhang zwischen verschiedenen Fakttypen aufzeigt. Er kann beispielsweise verwendet werden um aufzuzeigen, wie ein abgeleiteter Fakttyp zustande kommt. Umgekehrt lässt sich damit auch aufzeigen, auf welche abgeleiteten Fakttypen ein deklarierter Fakttyp direkt oder indirekt einwirkt. Der Inferenzbaum stellt somit die Schlussfolgerungskette dar, die aufzeigt, welche Fakttypen von welchen anderen Fakttypen abhängen. In Abb. 14.2 ist die Notation des Inferenzbaums zusammengefasst. Wie die Rule Map enthält er deklarierte Fakttypen, die durch einen Rhombus dargestellt werden, und abgeleitete Fakttypen, die zusätzlich durch zwei Linien gekennzeichnet sind. Schlussfolgerungen werden als Pfeile zwischen den Fakttypen dargestellt.
«abgeleitet» abgeleiteter Fakttyp
«abgeleitet» noch ein abgeleiteter Fakttyp
vorwärts
«deklariert» noch ein deklarierter Fakttyp
«abgeleitet» ein anderer abgeleiteter Fakttyp
«deklariert» ein anderer deklarierter Fakttyp
160
14 Strukturierung
«deklariert» deklarierter Fakttyp
rückwärts
Abb. 14.2 Die Inferenzbaum-Notation
Werden die in einem Inferenzbaum durch die Pfeile dargestellten Schlussfolgerungen konsequent von unten nach oben dargestellt, so lässt sich das Diagramm in zwei Richtungen lesen:
Vorwärts: Von unten nach oben gelesen, zeigt der Inferenzbaum welche deklarierten Fakttypen (eher unten auf dem Diagramm) welche abgeleiteten Fakttypen (eher oben auf dem Diagramm) beeinflussen. Damit lässt sich aufzeigen, welche abgeleiteten Fakttypen von einem einzigen deklarierten Fakttypen abgeleitet werden. Rückwärts: Von oben nach unten gelesen, zeigt der Inferenzbaum welche abgeleiteten Fakttypen (eher oben auf dem Diagramm) aus welchen deklarierten Fakttypen (eher unten auf dem Diagramm) abgeleitet werden. Auf diese Art lassen sich Begründungen für abgeleitete Fakttypen erzeugen.
Wir werden im Teil III dieses Buches noch einmal auf diese Unterscheidung bei der Leserichtung von Fakttypen-Abhängigkeiten zurückkommen. Seitenblick: In der Praxis ist es sehr aufwändig, Inferenzbäume zu zeichnen. Nach Möglichkeit sollen daher die technischen Mittel eines Werkzeugs zur Verwaltung von Geschäftsregeln genutzt werden. Diese sind oft in der Lage, solche Abhängigkeitsgraphen automatisch zu generieren. Steht diese Möglichkeit nicht zur Verfügung, so empfiehlt sich, lediglich die komplexen bzw. kritischen Zusammenhänge mittels Inferenzbäumen darzustellen.
14.3 Schritt für Schritt: Strukturierung von Regelungen Der Entwurf von Rule Maps und Inferenzbäumen wird im Folgenden getrennt erläutert, da beide in unterschiedlichen Situationen verwendet werden und ihre Erstellung typischerweise durch unterschiedliche Hilfsmittel unterstützt wird.
14.3.1 Entwurf von Rule Maps Die Rule Maps zeigen die Regelungen eines Unternehmens aus der Vogelperspektive. Da sie wichtiger Bestandteil der RegelVerwaltung ist, sollten sie selbst dann erstellt werden, wenn kein geeignetes Werkzeug zur automatischen Erstellung zur Verfügung steht. In solchen Fällen kann auch ein Zeichnungsprogramm (bei-
14.3 Schritt für Schritt: Strukturierung von Regelungen
161
spielsweise Microsoft Visio) gute Dienste leisten. Rule Maps lassen sich etwa in folgenden Schritten entwerfen: 1. Rule Maps identifizieren Da Rule Maps der Übersicht dienen sollen, dürfen sie nicht zu groß werden. Als Richtlinie sollen daher etwa 7±2 Regelungen auf einer einzelnen Rule Map dargestellt werden. Liegen wesentlich mehr Regelungen vor, empfiehlt sich, mehrere thematisch gruppierte Diagramme zu erstellen. Als Aufteilungskriterien könnten etwa Verantwortlichkeitsbereiche (z.B. „Verkauf“, „Einkauf“, etc.), Geschäftsprozesse („Einzelverkauf“, „Zahlungsüberwachung“, etc.) oder Geschäftsobjekte (z.B. „Mitarbeiter“, „Produkte“, etc.) dienen. Dabei ist es durchaus erlaubt und sinnvoll, dass sich einzelne Diagramme teilweise überlappen. 2. Grundlagen und Ergebnisse identifizieren Für jede Regelung sind deren Grundlagen und Ergebnisse zusammenzutragen. Zu den Grundlagen zählen deklarierte und abgeleitete Fakttypen sowie Geschäftsereignisse (bei Prozessregeln). Die Outputs von Regelungen umfassen hauptsächlich abgeleitete Fakttypen und bei Prozessregeln auch Geschäftsaktivitäten. In Sonderfällen können auch deklarierte Fakttypen Output von Regelungen sein. Dies ist immer dann der Fall, wenn eine Prozessregel die Faktenbasis verändert (siehe Kapitel 13.2.4 oder Beispiel „Gratismuster“ in Kapitel 13.4.5). 3. Rule Maps entwerfen Nun können die einzelnen Rule Maps gezeichnet (oder noch besser: generiert) werden. Müssen Rule Maps von Hand erstellt werden, können auch gewisse Details weggelassen werden. Beispielsweise können unwichtige (oder im Extremfall sogar alle) Fakttypen weggelassen und nur die Abhängigkeiten zwischen den Regelungen aufgezeigt werden. Da Rule Maps der Übersicht dienen, sollte auf ein möglichst übersichtliches Layout geachtet werden (z.B. möglichst wenig Überschneidungen von Pfeilen). Die so erstellten Rule Maps sind ein wichtiges Kommunikationsinstrument und sollen daher allen betroffenen Stellen zur Kenntnis gebracht werden. Da gewisse Regelungen und Geschäftsregeln eines Unternehmens oft ändern, ist der entsprechenden Pflege und Aktualisierung der Rule Maps ausreichend Beachtung zu schenken.
162
14 Strukturierung
14.3.2 Entwurf von Inferenzbäumen Der manuelle Entwurf von Inferenzbäumen lohnt sich nur in Ausnahmefällen. Wenn immer möglich sollten Inferenzbäume mit Hilfe eines Werkzeugs zur Regel-Verwaltung automatisch erstellt werden. Ist dies nicht möglich, so können sie in folgenden Schritten von Hand entworfen werden: 1. Zu untersuchender Fakttyp festlegen Zuerst muss die Frage gestellt werden, was von Interesse ist: Wie eine auf einem Fakttyp basierende Aussage zustande kommt oder in welche Aussagen ein Fakttyp einfließt? Im ersten Fall ist eine Rückwärts-Schlussfolgerungskette, ausgehend von einem abgeleiteten Fakttyp von Interesse (z.B. „Bestellung hat Nettopreis Betrag“ und wie dieser Betrag genau zustande kommt). Im zweiten Fall ist eine Vorwärts-Schlussfolgerungskette, typischerweise ausgehend von einem deklarierten Fakttyp von Interesse (z.B. „Artikel hat Herkunftsland Land“ und was alles vom Herkunftsland abhängt). 2. Abhängige Fakttypen identifizieren Nun müssen sämtliche Regelungen durchgegangen und je nach Fragestellung die folgende Abhängigkeiten gesucht werden: – Rückwärts-Schlussfolgerungskette: Es müssen diejenigen Ableitungsregeln gefunden werden, die den gesuchten Fakttypen herleiten. Danach sind für diejenigen Fakttypen, welche diese Ableitungsregeln in ihren Bedingungen verwenden, diejenigen Ableitungsregeln zu suchen, die sie herleiten etc. Dieser Prozess muss so lange wiederholt werden, bis nur noch deklarierte Fakttypen gefunden werden. – Vorwärts-Schlussfolgerungskette: Es müssen diejenigen Ableitungsregeln gefunden werden, die den gesuchten Fakttypen in ihrer Bedingung haben. Danach sind für die Fakttypen, die durch diese Ableitungsregeln hergeleitet werden, wiederum diejenigen Ableitungsregeln zu suchen, deren Bedingungen darauf basieren etc. Dieser Prozess muss so lange wiederholt werden, bis keine weiteren Ableitungsregeln mehr gefunden werden. Neben Ableitungsregeln müssen grundsätzlich auch Einschränkungen und Prozessregeln in analoger Weise berücksichtigt werden. Allerdings beschränkt sich der Prozess in diesen Fällen auf eine einzige Stufe, da sie keine Fakttypen herleiten.
14.3 Schritt für Schritt: Strukturierung von Regelungen
163
3. Inferenzbaum aufzeichnen Schließlich kann der Inferenzbaum von oben nach unten (Rückwärts-Schlussfolgerung) bzw. von unten nach oben (Vorwärts-Schlussfolgerung) aufgezeichnet werden.
14.4 Ergebnis: Die Regel-Zusammenhänge bei KnowBeer Nach einer eingehenden Analyse der bisher erarbeiteten Regelungen hat Tina Reiber die in Abb. 14.3 gezeigte Rule Map für den Bereich „Verkauf“ von KnowBeer erstellt. Die Regelung „Gratismuster“ (in der Rule Map oben rechts) zeigt eine Spezialität: Sie verwendet den deklarierten Fakttyp „Bestellung beinhaltet Anzahl von Artikel mit Rabatt Prozent“ (dargestellt als „beinhaltet“) sowohl als Grundlage, als auch als Ergebnis. Dies rührt daher, dass dieser Fakttyp durch Prozessregeln in der Regelung „Gratismuster“ verändert wird (es werden Gratismuster zur Bestellung hinzugefügt). Die Regelung “Zahlungsüberwachung” (in der Rule Map ganz oben) kommt beim selben Geschäftsereignis „vereinbarter Liefertermin“ zur Anwendung wie die Regelung „Gratismuster“. Im Gegensatz zu „Gratismuster“ kontrolliert „Zahlungsüberwachung“ aber eine Geschäftsaktivität: Sie verhindert die Auslieferung einer Bestellung, falls die Ware noch nicht bezahlt worden ist.
164
14 Strukturierung
«Prozessregeln» Zahlungsüberwachung
«Geschäftsaktivität» Ware liefern
«Geschäftsereignis» vereinbarter Liefertermin
«deklariert» bezahlte
«Ableitungen» bevorzugter Kunde
Abb. 14.3 Rule Map „Verkauf“
«Ableitungen» «Prozessregeln» Gratismuster «abgeleitet» ist bevorzugt
«deklariert» gehört zu «deklariert» hat Lieferdatum
«abgeleitet» hat Bruttopreis «Ableitungen» «Einschränkungen» Rabattbestimmung
«abgeleitet» hat Geschäftsbeziehung seit
«deklariert» beinhaltet «deklariert» hat Jahresumsatz «abgeleitet» hat Nettopreis
«Ableitungen» «Einschränkungen» Kreditlimite
«abgeleitet» hat Stückpreis
«abgeleitet» hat Versandkosten
«deklariert» hat Zahlungsprobleme «Ableitungen» Versandkosten «deklariert» hat Einstandspreis
«deklariert» ist express
«abgeleitet» hat Kreditlimite
«Ableitungen» Stückpreis
«deklariert» hat Funktion «deklariert» hat Dienstalter
«deklariert» ist EU-Mitglied «deklariert» hat Destination
«Ableitungen» «Einschränkungen» Verkaufskompetenzen
«deklariert» hat Herkunftsland «abgeleitet» hat Kompetenz
«deklariert» ist Standardartikel
Neben der Rule Map „Verkauf“ hat Tina Reiber auch einen Inferenzbaum erstellt. Er zeigt, wie die Bestimmung des Nettopreises einer Kundenbestellung zustande kommt (siehe Abb. 14.4 . Im Inferenzbaum ist zu sehen, dass nicht nur die Einstandspreise oder die Herkunft der bestellten Produkte etc. in den Nettopreis der Kundenbestellung einfließen, sondern beispielsweise auch die Zahlungsmoral des Kunden, dessen deklarierter Jahresumsatz sowie die Dauer der Geschäftsbeziehung mit diesem Kunden.
14.4 Ergebnis: Die Regel-Zusammenhänge bei KnowBeer
165
Abb. 14.4 Inferenzbaum „Nettopreis“
«abgeleitet» hat Nettopreis
«abgeleitet» ist bevorzugt
«abgeleitet» hat Versandkosten
«deklariert» hat Jahresumsatz
«deklariert» beinhaltet
«deklariert» hat Zahlungsprobleme
«abgeleitet» hat Stückpreis
«deklariert» hat Destination
«abgeleitet» hat Geschäftsbeziehung seit
«deklariert» ist Standardartikel
«deklariert» ist express
«deklariert» ist EU-Mitglied
«deklariert» gehört zu
«deklariert» hat Lieferdatum
«deklariert» hat Herkunftsland
«deklariert» hat Einstandspreis
14.5 Wie geht es weiter? Nun, da die einzelnen Regelungen im Detail ausgearbeitet und auch die Zusammenhänge zwischen diesen Regelungen bekannt sind, könnten diese eigentlich in Kraft gesetzt werden. Es macht allerdings Sinn, dass die Regelungen geprüft werden, bevor sie in Kraft treten. Dazu gehören zwei Abklärungen:
Entsprechen die Regelungen der Intension, wie sie durch das „Business Motivation Model“ formuliert worden ist? Sind die Regelungen in sich konsistent, d.h. weisen sie keine Lücken oder Widersprüche auf?
Die Beantwortung dieser beiden Fragestellungen ist Gegenstand des nächsten Kapitels.
166
14 Strukturierung
15 Prüfung
In diesem Kapitel wird aufgezeigt, wie sich einerseits gefundene Geschäftsregeln auf ihre fachliche Korrektheit und andererseits wie sich ganze Regelungen auf ihre Vollständigkeit und Widerspruchsfreiheit überprüfen lassen. Diese Überprüfung ist nicht nur vor der ersten Inkraftsetzung der Regelungen notwendig, sondern muss auch bei jeder Aktualisierung von Regelungen erneut durchgeführt werden.
15.1 Ausgangslage: Was stimmt hier nicht? Benno Remser ist immer noch skeptisch, ob die erarbeiteten Regelungen wirklich richtig und auch praktikabel sind. Deshalb schaut er sie in aller Ruhe noch einmal kritisch an, was seine Skepsis nicht wirklich reduziert. Nachdem er sich einen kräftigen Kaffee geholt hat, geht er zu Tina Reiber: B. Remser:
T. Reiber:
B. Remser:
T. Reiber:
Hallo Tina! Ich habe mir kürzlich die Regelung zur Bestimmung der Kreditlimite noch einmal angeschaut und mich gefragt, warum die Kreditlimiten dort eigentlich so tief sind. Weil wir in der Vergangenheit mehrere Male Verluste durch nicht bezahlte Rechnungen erlitten haben. Du erinnerst dich sicher noch an den Fall „Gasthof zum schwarzen Räuber“ – allein mit diesem Kunden haben wir über fünftausend Euro verloren! Erinnere mich nicht daran, ich habe den heftigen Streit mit Monika noch nicht vergessen! Aber haben wir die Verringerung des Kreditrisikos auch explizit als Ziel formuliert? Gute Frage! Eigentlich müsste jede Regelung, ja sogar jede einzelne Geschäftsregel auf ein explizites Ziel zurückzuführen sein. Man nennt dies auch die „Motivationskette“ einer Regelung.
15 Prüfung
167
B. Remser: T. Reiber: B. Remser:
T. Reiber:
Und haben wir das im Falle der Kreditvergabe gemacht? Ich fürchte nein! Wir müssen dies unbedingt nachholen und von Bernd Oss überprüfen lassen. Ich habe mir auch die Entscheidungstabellen zu den Kreditlimiten genauer angeschaut und dabei ist mir noch etwas aufgefallen. Was denn?
Benno Remser legt die Entscheidungstabelle, wie sie Tina ausgearbeitet hat, auf den Tisch: Tabelle 15.1 Entscheidungstabelle „Kreditlimite“
Regel
1
2
3
4
5
6
x
x
7
8
9
x
x
10
11 12
Bedingung Kunde hat Jah-
<200k €
resumsatz
200…500k € >500k €
Kunde hat Ge-
< 6 Monaten
schäfts-
6…12 Monaten
beziehung seit
> 12…24 Mon.
x x x
x x
x x
> 24 Monaten
x x
x
Kunde hat Zah- 0 lungsprobleme
x
x
1
x
>1
x
x
x
x
x
x
x
x
x
x
x x
x
x
x
x
x
x
x
x x
x
x
x
x
x
x
Folgerung Kunde hat
0€
Kreditlimite
500 € 1.000 € 2.000 €
B. Remser:
T. Reiber: B. Remser:
T. Reiber: B. Remser: T. Reiber:
168
15 Prüfung
x
x
x
x
Wie groß ist die Kreditlimite wenn ein Kunde 300.000 Euros Jahresumsatz macht, die Geschäftsbeziehung erst seit 8 Monaten besteht und bisher noch keine Zahlungsprobleme aufgetreten sind? Hmm… da sprechen ja die Regeln 4, 7, und 10 gleichzeitig an! Ja genau – und die widersprechen sich sogar! Und wie groß ist die Kreditlimite, wenn die Geschäftsbeziehung seit mehr als 24 Monaten besteht aber mehr als ein Zahlungsproblem aufgetreten ist? Lass mich mal sehen… da spricht ja überhaupt keine Regel an! Irgendetwas stimmt hier nicht ganz! Ich denke, wir haben noch nicht alle Hausaufgaben gemacht. Als erstes werde ich mich hinsetzen und un-
B. Remser:
T. Reiber:
sere Regelungen auf ihre Konsistenz und Vollständigkeit überprüfen. Und danach müssen wir noch einmal in einem Workshop die Motivation aller unserer Regelungen durchgehen und absegnen. Und vergiss nicht, speziell auch Bernd Oss dazu einzuladen! Schließlich muss er hinter der ganzen Sache stehen.
15.2 Lösungsansatz: Verifikation & Validierung Regelungen sowie die dazu gehörenden Geschäftsregeln sind die Ergebnisse der Geschäftsanalyse. Für die Überprüfung von Ergebnissen jeglicher Art sind grundsätzlich zwei Techniken bekannt:
Verifikation: Dabei werden verschiedene Ergebnisse oder Teilergebnisse gegeneinander verglichen, um Widersprüche oder Lücken aufzuspüren. Validierung: Dabei wird Überprüft, ob ein Ergebnis oder Teilergebnis mit der ursprünglichen Intension des Auftraggebers übereinstimmt, d.h. ob es fachlich korrekt ist
Für die Verifikation sind in gewissen Fällen mechanische Verfahren denkbar, die sich vollständig automatisieren lassen und so automatisch Fehler in diesen Ergebnissen ausweisen können. Bei der Validierung ist keine vollständige Automatisierung möglich, da dabei immer die Intension im Kopf des Auftraggebers als Maßstab dient und diese (zumindest heute noch) jedem automatischen Zugriff verwehrt bleibt.
15.2.1 Verifikation Für die Verifikation von Regelungen können folgende Ergebnisse beigezogen werden:
Geschäftsprozessmodelle: Jede Regelung sollte sich mindestens einer Geschäftsaktivität zuordnen lassen. Ist dies nicht möglich, so muss die jeweilige Regelung grundsätzlich in Frage gestellt werden. Unternehmensvokabular: Jede Geschäftsregel innerhalb einer Regelung sollte auf der Basis des Unternehmensvokabulars oder vordefinierter Objekt- und Fakttypen (siehe auch Kapitel 13.2.4) formuliert sein. Ist dies nicht möglich, so muss das Unternehmensvokabular entsprechend erweitert werden.
15.2 Lösungsansatz: Verifikation & Validierung
169
Regelungen: Verschiedene Regelungen sind via Grundlagen und Ableitungen miteinander verbunden. Basiert eine Regelung auf abgeleiteten Fakttypen, so müssen diese Grundlage entweder durch diese Regelung selber oder durch eine andere Regelung abgeleitet werden. Ist dies nicht der Fall, so muss eine entsprechende neue Regelung vorgesehen werden. Geschäftsregeln: Die Geschäftsregeln innerhalb einer Regelung dürfen sowohl keine Widersprüche als auch, insbesondere bei Ableitungsregeln, keine Lücken aufweisen. Ist dies nicht gewährleistet, müssen die Geschäftsregeln entsprechend umformuliert oder erweitert werden.
Werden Geschäftsprozesse, Unternehmensvokabular, Regelungen und Geschäftsregeln in einem integrierten Werkzeug verwaltet, dann können diese Verifikationen weitgehend automatisiert werden. Speziell für die Verifikation von Geschäftsregeln innerhalb einer Regelung sind ausgeklügelte Verfahren bekannt, die deren Konsistenz und Vollständigkeit automatisch überprüfen lassen. Im Kapitel 15.3 wird beispielsweise ein solches Verfahren für die Verifikation von Entscheidungstabellen genauer erläutert.
15.2.2 Validierung Bei der Validierung von Regelungen muss nachgewiesen werden, dass diese Regelungen auch der Intention des Unternehmens entsprechen. Am einfachsten kann dies mit Hilfe des „Business Motivation Models“ erfolgen, welches bereits in verschiedenen Kapiteln des Teil II verwendet wurde. Im „Business Motivation Model“ ist festgelegt, dass Direktiven (Regelungen und Geschäftsregeln) Unternehmensziele unterstützen sollen und durch Einschätzungen sowie deren mögliche Auswirkungen motiviert sind. Diese Zusammenhänge bilden so genannte Motivationsketten. Eine Motivationskette ist in der Lage, eine Serie von „Warum“ Fragen zu beantworten. Wird beispielsweise die Regelung „Rabattbestimmung“ (siehe Kapitel 13.4.4) in Frage gestellt, so kann sie damit begründet werden, dass sie das qualitative Ziel „Unseren Kunden werden faire Konditionen angeboten.“ unterstützt. Und die „Warum“ Frage nach diesem Ziel lässt sich damit beantworten, dass dieses die Vision „KnowBeer ist ein finanziell erfolgreicher und Europa-weit bevorzugter Lieferant von Spezialbieren für Restaurants jeglicher Größe.“ konkretisiert. In Abb. 15.1 ist der relevante Ausschnitt aus dem „Business Motivation Model“ dargestellt. Darin sind verschiedene „Motivationsketten“ für Direktiven zu sehen, beispielsweise:
170
15 Prüfung
Direktive unterstützt qualitatives Ziel konkretisiert Vision Direktive unterstützt quantitatives Ziel quantifiziert qualitatives Ziel konkretisiert Vision Direktive motiviert durch Einschätzung gemacht durch Organisationseinheit Direktive motiviert durch Einschätzung bezüglich quantitativem Ziel quantifiziert qualitatives Ziel konkretisiert Vision Direktive motiviert durch Einschätzung beurteilt Einfluss Direktive motiviert durch Einschätzung beurteilt Einfluss identifiziert mögliche Auswirkung (Nutzen oder Risiko) Direktive motiviert durch mögliche Auswirkung (Nutzen oder Risiko) Vision
Zweck
externer Einfluss Einfluss
konkretisiert
Abb. 15.1 Motivation
interner Einfluss beurteilt qual. Ziel Stärke bezüglich Ziel
quantifiziert
Schwäche Chance
quant. Ziel Gefahr
unterstützt
Direktive
motiviert durch
Einschätzung gemacht durch
Teil von
Formalität
motiviert durch
Organisationseinheit
identifiziert Regelung
konkretisiert Geschäftsregel
mögliche Auswirkung
Nutzen
Risiko
Auf dieser Basis sollte es einem Unternehmen möglich sein, für jede Direktive eine Begründung in Form einer Motivationskette abzugeben. Ist dies nicht möglich, so muss entweder die Direktive grundsätzlich in Frage gestellt oder aber eine entsprechende Motivationskette aufgebaut werden.
15.3 Schritt für Schritt: Prüfung von Regelungen Bevor Regelungen in Kraft gesetzt werden, sollten sie sowohl verifiziert als auch validiert werden. Damit werden gleichzeitig die sie konkretisierenden Geschäftsregeln geprüft. Es macht keinen Sinn, nur einzelne Geschäftsregeln zu verifizieren oder zu validieren, sie
15.3 Schritt für Schritt: Prüfung von Regelungen
171
können nur im Rahmen der ganzen Regelung sinnvoll geprüft werden. Bevor Regelungen validiert werden, sollten sie verifiziert, d.h. auf ihre Vollständigkeit und innere Konsistenz überprüft werden. Eine formale Verifikation ist vor allem bei produktorientierten Geschäftsregeln (siehe auch Seitenblick in Kapitel 13.3) wichtig, da die Geschäftsregeln oft in großer Zahl vorliegen. Sind sie unvollständig oder inkonsistent, ist damit die gesamte Produktbeschreibung lückenhaft oder widersprüchlich. Die Prüfung von Regelungen kann in folgenden Schritten erfolgen: 1. Regelungen mit anderen Ergebnissen abgleichen Wie bereits in Kapitel 15.2.1 erläutert, kommen für die Verifikation von Regelungen verschiedene Verfahren in Betracht. Folgende Teilschritte sollten ausgeführt werden: – Abgleich aller Regelungen mit den Geschäftsprozessmodellen: Es soll nachgewiesen werden, dass alle Regelungen mindestens eine Geschäftsaktivität betreffen. – Abgleich aller Geschäftsregeln innerhalb aller Regelungen mit dem Unternehmensvokabular: Es soll sichergestellt werden, dass alle in den Geschäftsregeln verwendeten Fakttypen im Faktenmodell zu finden sind. – Abgleich verschiedener Regelungen über abgeleitete Fakttypen: Es soll sichergestellt werden, dass alle benötigten abgeleiteten Fakttypen durch genau eine Regelung produziert werden. 2. Regelungen verifizieren Je nach Komplexität der Geschäftsregeln kann die Aufdeckung von Lücken und Widersprüchen innerhalb einer einzelnen Regelung relativ einfach oder aber auch kaum lösbar sein. Am einfachsten ist die formale Verifikation bei Entscheidungstabellen (dazu folgt auf der nächsten Seite ein Beispiel). Kommen komplexere Formen von Geschäftsregeln zur Anwendung (sind beispielsweise Variabeln im Spiel) so ist die Prüfung auf Vollständigkeit und Widerspruchsfreiheit – wenn überhaupt – nur noch mit hoch spezialisierten Werkzeugen möglich. 3. Regelungen validieren Für die Validierung, d.h. die Überprüfung, ob die Regelungen der Intention des Unternehmens entsprechen, sind wiederum verschiedene Verfahren denkbar: – Erstellung von Motivationsketten, wie sie im Kapitel 15.2.2 beschrieben sind.
172
15 Prüfung
–
–
Simulation von Regelungen, d.h. ihre Ausführung zu Testzwecken durch die Verwendung einer Business Rules Engine. Wir werden im Teil III noch auf dieses Verfahren zurückkommen. Die Validierung durch Walkthroughs und/oder Reviews. In einem Walkthrough werden alle Geschäftsregeln einer Regelung im Team durchgegangen und ihre Intension geprüft. Bei Reviews werden die Regelungen an Fachvertreter verteilt. Diese überprüfen die Intension der Geschäftsregeln und liefern dazu ihr Feedback.
Schließlich sei noch einmal daran erinnert, dass diese Prüfungen nicht nur bei der initialen Erstellung von Regelungen zur Anwendung kommen sollen, sondern auch nach jeder Aktualisierung oder Erweiterung von Regelungen.
Verifikation einer Entscheidungstabelle Der 2. Schritt „Regelungen verifizieren“ soll an einem Beispiel etwas detaillierter erläutert werden. Bei der Verifikation von Regelungen werden die einzelnen Geschäftsregeln einer Regelung einander gegenübergestellt, um festzustellen, ob Widersprüche oder Lücken vorhanden sind. Wie wir im Kapitel 13.2 gesehen haben, können Regelungen in unterschiedlicher Art und Weise formuliert werden. Lässt sich eine Regelung durch eine Entscheidungstabelle beschreiben, so kann ihre Verifikation in mechanischer Weise und mit einer 100%igen Abdeckung erfolgen (eine so genannte formale Verifikation). Für einfache Entscheidungstabellen kann diese Überprüfung manuell vorgenommen werden. Sobald die Größe einer Entscheidungstabelle ein gewisses Maß überschreitet, ist der Einsatz eines spezialisierten Werkzeuges unabdingbar. Im Folgenden wird anhand eines einfachen Beispiels aufgezeigt, wie
sich in einer Einscheidungstabelle Lücken und Widersprüche aufdecken lassen diese Lücken und Widersprüche korrigiert werden können eine Entscheidungstabelle optimiert werden kann, d.h. die Anzahl Regeln minimiert werden kann, ohne die Semantik der Entscheidungstabelle zu verändern.
Als Beispiel wird eine vereinfachte Version der Entscheidungstabelle zur Bestimmung der Kreditlimite eines Kunden verwendet (Siehe Tabelle 15.2).
15.3 Schritt für Schritt: Prüfung von Regelungen
173
Tabelle 15.2 Entscheidungstabelle „Kreditlimite“
Regel
1
resumsatz
>500k €
Kunde hat Ge-
0…12 Monaten
x
schäfts-
> 12…24 Mon.
beziehung seit
> 24 Monaten
Kunde hat
nein
Zahlungsprobl.
ja
2
3
4
5
6
x
x
x
Bedingung Kunde hat Jah-
<500k € x x
x x
x
x
x
x x
x
Folgerung Kunde hat
0€
Kreditlimite
1.000 €
x
x x
2.000 €
x
x
x
Als erstes muss die Entscheidungstabelle expandiert werden, d.h. so erweitert werden, dass sie jede mögliche Kombination von Werten aus ihren Teil-Bedingungen enthält. Dies kann ziemlich umfangreich werden, da die Anzahl Werte pro Teil-Bedingung miteinander multipliziert werden müssen. Selbst im vorliegenden einfachen Beispiel ergibt dies 2 × 3 × 2 = 12 Kombinationen was 12 einzelnen Regeln entspricht (gegenüber von 6 in der Ausgangsversion). Tabelle 15.3 zeigt die expandierte Version der ursprünglichen Kreditlimitenregelung. Zur besseren Unterscheidung wurden in der erweiterten Tabelle die einzelnen Regeln durch Buchstaben statt durch Nummern gekennzeichnet. Im Folgerungsteil von Tabelle 15.3 wurden zudem die Regel-Nummern der ursprünglichen Entscheidungstabelle statt einfacher Kreuze eingetragen. Tabelle 15.3 Entscheidungstabelle „Kreditlimite“ – expandiert
Regel
a
b
c
d
e
f
x
x
x
x
x
x
x
x
g
h
i
j
k
l
x
x
x
x
x
x
x
x x
x x
x
Bedingung Kunde hat
<500k €
Jahresumsatz
>500k €
Kunde hat
0…12 Monaten
Geschäfts-
> 12…24 Mon.
beziehung seit
> 24 Monaten
Kunde hat
nein
Zahlungsprobl.
ja
x
x x
x
x x
x
x x
x x
x x
x x
x
Folgerung Kunde hat
0€
Kreditlimite
1.000 € 2.000 €
174
15 Prüfung
1
1
1 2
1 2
3
6
4
3
5
In der expandierten Version fällt auf, dass für die Kriterienkombinationen der Regeln „d“ und „f“ keine Folgerung vorliegt, d.h. in der ursprünglichen Entscheidungstabelle offenbar eine Lücke vorliegt. Außerdem ist zu sehen, dass in der Kriterienkombination der Regel „g“ mehr als eine ursprüngliche Regel anspricht: sowohl Regel „1“ als auch Regel „6“ – es liegt also ein Widerspruch vor. Lücken müssen nun gefüllt und Widersprüche aufgelöst werden. Dies sind bewusste Entscheidungen, da hier eine fachliche Fragestellung vorliegt. In Tabelle 15.4 ist die so bereinigte Version der expandierten Entscheidungstabelle ersichtlich. Regel
a
b
c
d
e
f
x
x
x
x
x
x
x
x
g
h
i
j
k
l
x
x
x
x
x
x
x
x x
x x
x
Bedingung Kunde hat
<500k €
Jahresumsatz
>500k €
Kunde hat
0…12 Monaten
Geschäfts-
> 12…24 Mon.
beziehung seit
> 24 Monaten
Kunde hat
nein
Zahlungsprobl.
ja
x
x x
x
x x
x
x x
x x
x x
Tabelle 15.4 Entscheidungstabelle „Kreditlimite“ – bereinigt
x x
x
Folgerung Kunde hat
0€
Kreditlimite
1000 € 2000 €
x
x
x
x
x
x x
x
x x
x
x
Werden nun die einzelnen Regeln so sortiert, dass jeweils diejenigen nebeneinander liegen, welche dieselbe Folgerung liefern, lassen sich ihre Teil-Bedingungen bequemer miteinander vergleichen. In Tabelle 15.5 ist nun beispielsweise zu sehen, dass bei den Regeln „a“ und „b“ das Kriterium „Kunde hat Zahlungsprobleme“ keine Rolle spielt. Damit kann eine von beiden Regeln ganz eliminiert und in der verbleibenden Regel das Kriterium „Kunde hat Zahlungsprobleme“ entfernt werden. Dieselbe Situation (mit demselben Kriterium) liegt auch bei den Regeln „k“ und „l“ vor.
15.3 Schritt für Schritt: Prüfung von Regelungen
175
Tabelle 15.5 Entscheidungstabelle „Kreditlimite“ – sortiert
Regel
a
b
d
x
x
x
h
c
f
g
i
x
x
x x
x
x
x
e
j
k
l
x
x
x
x
x
x
x
x
Bedingung Kunde hat
<500k €
Jahresumsatz
>500k €
Kunde hat
0…12 Monaten
Geschäfts-
> 12…24 Mon.
beziehung seit
> 24 Monaten
Kunde hat
nein
Zahlungsprobl.
ja
x
x x
x
x
x x
x
x x
x
x
x
x
x
x
x
x
x
x
x
Folgerung Kunde hat
0€
Kreditlimite
1000 €
x
x
x
x
x x
2000 €
x
x
x
Damit sieht die Entscheidungstabelle wie in Tabelle 15.6 aus: Statt 12 haben wir nun nur noch 10 Regeln und haben gleichzeitig sowohl Lücken als auch Widersprüche eliminiert. Tabelle 15.6 Entscheidungstabelle „Kreditlimite“ – optimiert
Regel
1
2
x
x
3
4
5
6
7
x
x
x x
x
x
x
8
9
10
x
x
Bedingung Kunde hat
<500k €
Jahresumsatz
>500k €
Kunde hat
0…12 Monaten
Geschäfts-
> 12…24 Mon.
beziehung seit
> 24 Monaten
Kunde hat
nein
Zahlungsprobl.
ja
x x
x
x
x x
x x
x
x
x
x x
x
x
x
x
x
x
Folgerung Kunde hat
0€
Kreditlimite
1.000 € 2.000 €
x
x
x
x
x x
x
x
Seitenblick: Die Prüfung auf Vollständigkeit und Widerspruchsfreiheit ist bei Regelungen, die Variabeln in ihren Kriterien enthalten, wesentlich komplexer. Dies rührt daher, dass die Wahrheitswerte dieser Kriterien nur dann bestimmbar sind, wenn konkrete Daten vorliegen. Betrachten wir beispielsweise die folgende Geschäftsregel aus Kapitel 13.4.8:
176
15 Prüfung
r2: Artikel hat Stückpreis EP * 1.30, wobei Artikel hat Einstandspreis EP falls alle folgenden Bedingungen erfüllt sind: Artikel hat Herkunftsland L L ist EU-Mitglied ist nicht wahr Artikel ist Standardartikel. Der Wahrheitswert dieser Bedingung kann nur bestimmt werden, falls alle Artikel von KnowBeer sowie deren Eigenschaften wie Herkunftsland etc. bekannt sind. Somit lassen sich ohne diese Daten auch weder Lücken noch Widersprüche aufdecken. Spezialisierte Verifikationswerkzeuge verwenden in solchen Fällen heuristische Ansätze, mit denen sie Testdaten „erfinden“ um mit möglichst großer Wahrscheinlichkeit Schwachstellen in Regeln aufzudecken.
15.4 Ergebnis: Aktualisierte Regelungen von KnowBeer Tina ist noch einmal in Ruhe die bisher erarbeiteten Entscheidungstabellen durchgegangen. Da bei hat sich gezeigt, dass lediglich die Regelung „Kreditlimite“ Widersprüche und Lücken aufwies. Durch die Bereinigung dieser Probleme konnte die Anzahl von Geschäftsregeln in dieser Regelung sogar von 12 auf 8 reduziert werden. Die bereinigte Version dieser Entscheidungstabelle sieht nun so aus: Regel
1
2
3
4
5 x
6
7
8
Bedingung Kunde hat Jah-
<200k €
x
resumsatz
200…500k €
x
x
>500k €
x
x
Kunde hat
< 6 Monaten
Geschäfts-
6…12 Monaten
beziehung seit
> 12…24 Mon.
x
x
x
x
> 24 Monaten
x
x
x
x
x
x
x
x
x x
x
Kunde hat Zah- 0 lungsprobleme
Tabelle 15.7 Korrigierte Entscheidungstabelle „Kreditlimite“
x
1
x
>1
x
x
x
x
x
x
x
x
Folgerung Kunde hat
0€
Kreditlimite
500 € 1.000 € 2.000 €
x
x
x x
x x
15.4 Ergebnis: Aktualisierte Regelungen von KnowBeer
177
Eine andere Sache war die Validierung der Regelung „Kreditlimite“. Hier hat sich gezeigt, dass diese Regelung in keiner Weise in den explizit formulierten Geschäftszielen verankert war. Trotzdem waren sich alle Beteiligten einig, dass eine solche Regelung für das Geschäft essentiell ist. Aus diesem Grund hat man nun auch diesen Teil der Geschäftsstrategie explizit gemacht und konnte die folgende Motivationskette für die Regelung „Kreditlimite“ aufbauen:
Die Regelung „Kreditlimite“ („Verpflichtung: Die Bestimmung der gültigen Kreditlimite eines Kunden erfolgt in einer einheitlichen und nachvollziehbaren Art und Weise.“) existiert, da… … M. Oney (Buchhaltung) am 7.9.2005 die folgende Einschätzung gemacht hatte: „Kreditrisiko: Wir hatten in den vergangenen Jahren große Debitorenverluste.“ Diese Einschätzung erfolgte… … im Hinblick auf das quantitative Ziel „Das unternehmensweite Kreditrisiko soll 40.000 € pro Jahr nicht überschreiten.“ … unter dem Einfluss „Die Zahlungsmoral von Kunden ist in den vergangenen Jahren kontinuierlich gesunken.“ … sowie unter Berücksichtigung der möglichen Auswirkung (Nutzen) „Wenn wir die Debitorenverluste im Vergleich zum Vorjahr halbieren, können wir den Gewinn um rund 30.000 € steigern.“
15.5 Wie geht es weiter? Damit ist das Projekt BEGIN abgeschlossen und alle für das Unternehmen relevanten Regelungen sind ausgearbeitet, verifiziert und validiert. Nun gilt es, diese Regelungen zu operationalisieren, was auf zwei Arten erfolgen kann:
178
Die Regelungen werden so weit wie möglich automatisiert, d.h. sie werden in diejenigen IT-Systeme eingebaut, die Geschäftsprozesse des Unternehmens unterstützen bzw. automatisieren. Die Möglichkeiten zur Automatisierung von Regelungen mittels IT-Systemen ist der Schwerpunkt des Teils III dieses Buches. Diejenigen Regelungen, welche sich nicht automatisieren lassen oder aus anderen Gründen nicht automatisiert werden sollen, werden als Arbeitsanweisungen allen betroffenen Mitarbeitern des Unternehmens zugänglich gemacht. Außerdem müssen für diese Regelungen Kontrollmechanismen etabliert werden, welche die Einhaltung bzw. die Durchsetzung dieser Regelungen gewährleisten.
15 Prüfung
Sind Regelungen erst einmal in Kraft gesetzt (entweder durch ITSysteme oder durch Arbeitsanweisungen), müssen sie permanent gepflegt und an neue Herausforderungen des Unternehmens angepasst werden. Dabei kann weitestgehend auf den bisherigen Vorarbeiten aufgesetzt werden und so der Nutzen aus dem bisherigen Aufwand „geerntet“ werden.
15.5 Wie geht es weiter?
179
16 Rule Management
Nun, da alle relevanten Regelungen ausgearbeitet, verifiziert und validiert sind, gilt es, diese zu operationalisieren. In diesem Kapitel wird aufgezeigt, auf welche Arten diese Operationalisierung erfolgen kann und was dabei beachtet werden muss. Außerdem müssen die Voraussetzungen geschaffen werden, dass die Regelungen permanent gepflegt und an neue Herausforderungen des Unternehmens angepasst werden können.
16.1 Ausgangslage: Was gilt nun? Zur Feier des erfolgreichen Abschlusses des Projekts „BEGIN“ findet in den Räumlichkeiten von KnowBeer eine kleine Party statt. Es werden Biere aus aller Welt gereicht. Tina Reiber, die erfolgreiche Projektleiterin, unterhält sich mit Bern Oss und Daniel Enker, dem IT-Verantwortlichen: T. Reiber: B. Oss:
T. Reiber:
D. Enker:
T. Reiber: D. Enker:
Ich bin froh, dass wird das ganze zu einem erfolgreichen Abschluss bringen konnten. Dazu gratuliere ich dir auch herzlich! Aber was machen wir jetzt mit all unseren Regeln? Und vor allem: Wer kontrolliert deren Einhaltung? Dafür können wir keine neuen Mitarbeiter einstellen. Natürlich nicht! Wir müssen die Ausführung der Geschäftsregeln soweit wie möglich automatisieren. Das wäre dann etwas für euch in der IT, Daniel. Nun ja, ich habe mir diese Regelungen mal etwas genauer angeschaut. Da gibt es schon Dinge, mit denen kann ich ehrlich gesagt nicht viel anfangen. Wie meinst du denn das? Wir haben uns solche Mühe gegeben, dass es für alle klar und eindeutig ist. Ja verstehen kann ich die Regeln schon. Aber wie sollen wir in der IT beispielsweise prüfen, ob ein Verkaufsmitarbeiter sein Budget für Marketingaktio-
16 Rule Management
183
B. Oss: T. Reiber: D. Enker: T. Reiber:
B. Oss:
T. Reiber:
nen nicht überschreitet? Uns stehen ja die notwendigen Zahlen nicht zur Verfügung. Das kann ja gar nicht gehen. Soll das heißen, dass wir Regeln aufgestellt haben, die sich nicht überprüfen lassen? Nein, aber Daniel hat schon Recht, die Überprüfung kann etwas aufwändig sein. Aufwändig? Ich würde eher sagen unmöglich! Jetzt übertreibst du aber! Trotzdem, du hast schon Recht, alle unsere Regelungen werden wir wohl nie automatisieren können. Schließlich haben wir ja auch verantwortungsbewusste Mitarbeiter, und zu den Führungsaufgaben der Vorgesetzten gehört auch die Kontrolle. Dann braucht es aber auch Anleitungen und Checklisten für die Mitarbeiter in denen sie die Regeln, die sie einhalten oder überprüfen sollen, nachschlagen können. Ja, genau wie ein Teil der Regelungen in unserem ITSystem umgesetzt wird, muss der andere Teil ebenfalls umgesetzt werden, und zwar in unserer Betriebsorganisation.
Den Beteiligten wird klar: Damit Regelungen effizient durchgesetzt werden können, sollen diese so weit als möglich automatisiert werden. Dabei gibt es allerdings Grenzen, denn verschiedene Gründe können gegen eine Automatisierung sprechen. So sind beispielsweise nicht alle Fakten einfach zugänglich und lassen sich nicht automatisch beschaffen. Regelungen, die man nicht in IT-Systemen automatisieren kann oder will, müssen auf eine andere Art umgesetzt werden: In Arbeitsanweisungen, Stellenbeschreibungen oder Checklisten. Doch wenden wir uns wieder dem Gespräch zu: B. Oss: T. Reiber:
B. Remser:
B. Oss:
184
… zu entscheiden, welche Regeln wir automatisieren wollen. Ich denke auch, dass das ein wichtiger nächster Schritt ist. Wir sollten für jede Regelung festhalten, ob sie automatisiert werden soll. Wenn du schon dabei bist, hätte ich gleich noch ein paar Anpassungen für die Rabatte. FASTBeer, unser Konkurrent, hat da gerade eine Aktion laufen. Du kannst doch jetzt nicht einfach unsere Regeln anpassen, die wurden geprüft und von mir abgenommen.
16 Rule Management
T. Reiber:
Doch, doch, wenn einer den Marktdurchblick hat, ist es Benno. Wenn er die Regeln anpassen will, sollte er das tun können. B. Oss: Dann darf bei uns jeder die Regeln ändern? T. Reiber: Das natürlich nicht! Wir müssen wohl festlegen, wer was wann ändern darf. Aber das schauen wir uns am Montag an, jetzt wird gefeiert. Prost! D. Enker (zu sich selbst murmelnd): Das kann ja heiter werden! Die ändern die Regeln bereits bevor wir mit der Umsetzung begonnen haben. Direktiven, also Regelungen und Geschäftsregeln eines Unternehmens, basieren auf den Zielen des Unternehmens und der Einschätzung von internen und externen Einflüssen. Das hat zur Folge, dass die Direktiven eines Unternehmens möglicherweise für eine kurze Zeit korrekt sind, aber sie stellen lediglich eine Momentaufnahme dar. In einem dynamischen Umfeld32 ändern sich die Einflüsse auf das Unternehmen ständig und somit verlieren die Direktiven mit der Zeit ihre Motivation (siehe Kapitel 15.2.2). Sie sind nicht mehr zweckmäßig. Dieser Problematik kann sich leider niemand entziehen. Will das Unternehmen erfolgreich bleiben, müssen die Einflüsse regelmäßig neu eingeschätzt und die Direktiven entsprechend angepasst werden. Dies soll im Rahmen eines kontrollierten Prozesses geschehen, dem Rule Management Prozess.
16.2 Lösungsansatz: Rule Management Im Rule Management geht es darum, die Geschäftsregeln und Regelungen als wertvolles Gut zu behandeln. Dazu gehört:
32
die Unterstützung verschiedener Umsetzungsstrategien für die Regelungen, der bewusste Umgang mit den Regelungen in einem kontrollierten Änderungsprozess, das Sammeln von Feedback aus der Anwendung der Regelungen.
eine Art weißer Schimmel
16.2 Lösungsansatz: Rule Management
185
16.2.1 Wahl der Umsetzungsstrategie Soll eine Regelung oder Geschäftsregel dem Rule Management unterstellt werden, muss zuerst eine Umsetzungsstrategie festgelegt werden. Dies geschieht am besten auf Ebene der Regelung und nicht für einzelne Geschäftsregeln. Es muss entscheiden werden, auf welche Art die Regelung angewendet werden soll. Grundsätzlich lassen sich zwei Möglichkeiten unterscheiden:
Abb. 16.1 Umsetzung von Geschäftsregeln
Umsetzung durch Menschen mittels Knowledge Management Ansätzen (KMA), die „Anordnung“ der Geschäftsregeln (siehe Kapitel 16.2.3) Umsetzung durch IT mittels Business Rules Technologie (BRT), die „Automatisierung“ der Geschäftsregeln (siehe Kapitel 17–20)
Umsetzung durch Menschen mittels Knowledge Management Ansätzen GeschäftsRegeln
BR Management
Umsetzung durch IT mittels Business Rules Technolgie
Bei der Umsetzung mittels Knowledge Management Ansätzen sind die Mitarbeiter die „Regelprozessoren“. Sie haben bei ihrer Arbeit die Geschäftsregeln zu beachten und manchmal auch die Einhaltung der Geschäftsregeln durch andere Mitarbeiter zu überprüfen. So wurde bis vor kurzem in allen Unternehmen gearbeitet, denn es gab gar keine Alternative dazu. Bei der Umsetzung von Geschäftsregeln mittels Business Rules Technologie werden die IT-Systeme des Unternehmens so gestaltet, dass sie die Geschäftsregeln automatisch überprüfen oder ausführen. Dies hat zur Folge, dass Regelverstöße automatisch festgestellt und allenfalls verhindert werden, je nach Grad der gewünschten Durchsetzung. Auch Aktionen können in IT-Systemen auf Grund von Geschäftsregeln automatisch ausgelöst werden.
186
16 Rule Management
16.2.2 Verwaltung und Änderung von Geschäftsregeln Dass Geschäftsregeln geändert und an neue Verhältnisse angepasst werden müssen, ergibt sich aus ihrer Herleitung von Zielen und Einflüssen. Diese Änderungen sollen kontrolliert im Rahmen eines Änderungsmanagements stattfinden. Das Änderungsmanagement für Geschäftsregeln muss dabei eine ganze Reihe von Gesichtspunkten berücksichtigen:
Aktualisierung der Regelungen Die Regelungen sind ein wertvolles Gut des Unternehmens und müssen gepflegt werden. Dafür gibt es verschiedene Ansätze: – Feedback aus der Anwendung der Geschäftsregeln Im täglichen Geschäft, dort, wo die Geschäftsregeln zur Anwendung kommen, kann oft am besten erkannt werden, wenn eine Geschäftsregel irgendwie „nicht stimmt“. Es müssen Möglichkeiten bereitgestellt werden, wie solches Feedback gesammelt und ausgewertet werden kann. – Anforderungen aus dem Führungsprozess des Unternehmens Es gehört zu den normalen Aufgaben der Führung, die Geschäftsregeln nach denen das Geschäft abgewickelt wird, zu optimieren und an neue Gegebenheiten anzupassen. – Regelmäßige Überprüfung der Motivation Auch wenn Regelungen ständig angepasst werden lohnt es sich trotzdem, in regelmäßigen Abständen, beispielsweise jährlich, die vorhandenen Regelungen und insbesondere ihre Motivation, d.h. ihre Existenzberechtigung aufgrund von Zielen, Einflüssen und Einschätzungen, zu überprüfen. Prüfung Wird eine Regelung geändert, muss man sich über die Konsequenzen der Änderung bewusst sein. Die Überprüfung der neuen Regelung hilft, diese Konsequenzen abzuschätzen. Die Überprüfung von Regeln mittels Verifikation und Validierung ist in Kapitel 15 ausführlich beschrieben. Es müssen aber auch diejenigen Anwendungen getestet werden, die von indirekt von geänderten Regelungen betroffen sind. In KnowBeer wäre das beispielsweise die Auftragserfassung im System „myTBQ“. Eine Prüfung ist besonders in zwei Fällen wichtig: – Wenn die Regelung komplex ist, denn dann sind die Konsequenzen nicht mehr offensichtlich abzuschätzen, und die Änderung kann zu Überraschungen führen.
16.2 Lösungsansatz: Rule Management
187
Wenn die Konsequenzen schwerwiegend sind, beispielsweise bei der Preisermittlung, denn dann kann bereits ein kleiner Fehler zu großen Verlusten führen. Freigabe Die Freigabe einer Geschäftsregel bewirkt, dass die Geschäftsregel in Kraft gesetzt wird. Die Freigabe ist eng verknüpft mit der Änderung der Geschäftsregel. Trotzdem soll sie als eigener Schritt behandelt werden. Für die Freigabe müssen allenfalls gewisse Voraussetzungen erfüllt sein, beispielsweise ein Prüfung der Geschäftsregel. Auch kann hier das Vier-AugenPrinzip zum tragen kommen. Zeit Es muss festgelegt werden, zu welchem Zeitpunkt neue oder geänderte Geschäftsregeln freigegeben und in Kraft gesetzt werden dürfen. Im einfachsten Fall ist dies jederzeit möglich, doch fachliche Gründe können hier zu Einschränkungen führen, beispielsweise wenn publizierte Preise bis zu einem gewissen Datum garantiert werden müssen. Dann muss die neue Regelung auf einen bestimmten Stichtag hin eingeführt werden. Außerdem müssen die Anforderungen an Versionierung und Historisierung geklärt werden. Wenn beispielsweise Entscheide, die vor 2 Jahre durch das IT-System gefällt wurden, rekonstruiert werden, benötigt man die damals gültigen Geschäftsregeln und Daten. Ausbreitung Die Abläufe für die Ausbreitung freigegebener Regelungen müssen sowohl für den Bereich des Knowledge Management als auch die Automatisierung geregelt werden. Dazu gehört beispielsweise die Erstellung und Verteilung von Handbüchern, aber auch die technische Inkraftsetzung automatisierter Regelungen. Zudem darf nicht vergessen werden, dass auch automatisierte Regelungen den Mitarbeitern mindestens in groben Zügen bekannt sein sollten damit sie das Verhalten des IT-Systems verstehen können. Idealerweise soll ein IT-System sein Verhalten erklären können, beispielsweise aufgrund welcher Geschäftsregel eine Bestellung nicht erfasst werden kann. Oft ist das aber in der Praxis nicht möglich. Aktivitäten Die Aktivitäten des Rule Managements müssen festgelegt werden. Der Bereich möglicher Aktivitäten reicht vom simplen Verwalten von Geschäftsregeln bis hin zu sehr spezialisierten Aktivitäten, mit denen lediglich bestimmte Regelparameter geändert werden können. –
188
16 Rule Management
Berechtigungen Nicht jeder Mitarbeiter soll das Recht haben, alle Aktivitäten der Rule Managements auszuführen. Für die Änderung einer Regelung können beispielsweise verschiedene abgestufte Berechtigungen definiert werden: – Zahlenwerte von Geschäftsregeln (im Rahmen eine Wertebereichs) ändern – Bedingungen von Geschäftsregeln ändern – Geschäftsregel neu hinzufügen – Geschäftsregel löschen Diese Berechtigungen können verschiedenen Mitarbeitern gewährt werden, und zwar auf der Ebene der Regelung, der Geschäftsregel oder gar auf einzelnen Elementen von Geschäftsregeln. Werkzeugunterstützung Die meisten der genannten Aspekte der Verwaltung von Geschäftsregeln lassen sich ohne geeignete Werkzeugunterstützung nur schwer realisieren. Es muss ein geeignetes Werkzeug für das Verwalten und Ändern von Geschäftsregeln bereitgestellt werden. Seitenblick: Die hier aufgeführten Gesichtspunkte gelten grundsätzlich für alle Regelungen, unabhängig davon, wie sie umgesetzt werden. Allerdings sind Regelungen, die mittels Knowledge Management umgesetzt werden, meist weniger formal und stellen daher etwas andere Anforderungen an ihre Verwaltung. Idealerweise werden aber alle Regelungen gemeinsam verwaltet.
16.2.3 Knowledge Management Alle Geschäftsregeln, die nicht automatisiert werden, müssen durch einen Knowledge Management Prozess „implementiert“ werden. Es ist nicht damit getan, dass die Geschäftsregeln ausgedruckt und an die Mitarbeiter verteilt werden. Vielmehr muss das Knowledge Management so funktionieren, dass alle betroffenen Mitarbeiter
die Geschäftsregeln, die sie beachten müssen, kennen und verstehen, im Zweifelsfall eine Geschäftsregel nachlesen können, über Regeländerungen informiert sind.
Außerdem muss die Einhaltung der Geschäftsregeln überprüft werden können. Um diese Ziele zu erreichen muss dass Knowledge Management
16.2 Lösungsansatz: Rule Management
189
geeignete Darstellungsformen und Medien verwenden, um Geschäftsregeln zu kommunizieren, Hilfen bereitstellen, um relevante Geschäftsregeln zu suchen, einen geeigneten Aktualisierungs-Prozess definieren, die betroffenen Mitarbeiter im Verständnis und in der Umsetzung der Geschäftsregeln ausbilden.
Dokumentation Für die Dokumentation muss eine Darstellungsform gewählt werden, die dem Leser gerecht wird. Die in Teil II verwendete Darstellung ist möglicherweise nicht für jedermann geeignet. Oft besteht ein gewisser Konflikt zwischen einer korrekten, präzisen Darstellung, die aber nicht von allen auf Anhieb verstanden wird, und einer einfach lesbaren, aber etwas ungenauen Darstellung. Man sollte versuchen, die Mitarbeiter an die präzise Darstellung zu gewöhnen. Idealerweise wird eine Darstellungsform verwendet, die direkt aus dem Rule Management Werkzeug erstellt werden kann. Müssen die Regelung von Hand für die Dokumentation übersetzt werden dann kann man davon ausgehen, dass die Dokumentation über kurz oder lang nicht mehr den aktuellen Stand widerspiegelt. Ein wichtiger Punkt ist außerdem die Wahl eines geeigneten Mediums. Im Folgenden sind einige Medien mit ihren Eigenschaften aufgelistet:
Flyer – brauchen keine spezielle Hardware zum Lesen – können überall mitgenommen, aufs Pult gelegt oder an die Wand gehängt werden – können leicht verloren gehen – bieten bei einer größeren Anzahl eine schlechte Übersicht – Updates sind schwierig sicherzustellen (wenn der alte Flyer an der Wand hängt, wird er nicht ersetzt) Handbücher – brauchen keine spezielle Hardware zum Lesen – können mitgenommen werden, bleiben aber oft im Gestell – bieten einigermaßen gute Übersicht dank Inhaltsverzeichnis und Index – Updates sind aufwändig33 Elektronische Dokumente (z.B. PDF, E-Mails) – benötigen Computer zum Lesen, oder müssen ausgedruckt werden (und werden dann zu Flyern oder Handbüchern)
33
Wer je in einem größeren Unternehmen gearbeitet hat erinnert sich sicher an die Stunden, die er mit dem Ersetzen von Seiten im Mitarbeiter-Ordner der Personalabteilung verbracht hat.
190
16 Rule Management
– – –
können nur bedingt mitgenommen werden bieten relative gute Suchmöglichkeiten Update ist einfach, wenn die Dokumente auf einen Server abgelegt sind – Kopien auf der lokalen Festplatte und Ausdrucke können den Update erschweren Intranet-Site – benötigen Computer zum lesen, sind in der Regel nicht zum Ausdruck geeignet – können nur bedingt mitgenommen werden – Update ist einfach – können gut durchsucht werden Dokument Management System – benötigen Computer und teilweise spezielle Software zum lesen – können nur bedingt mitgenommen werden – Update ist einfach – können gut durchsucht werden
Grundsätzlich müssen Geschäftsregeln so dokumentiert sein, dass die Mitarbeiter sie finden und bei Bedarf nachschlagen können. Je mehr Geschäftsregeln es gibt, desto wichtiger wird das einfache Auffinden. Insbesondere Geschäftsregeln für selten auftretende Geschäftsfälle können leicht vergessen gehen. In den meisten Berufen sind sich die Mitarbeiter nicht gewohnt, ihre Arbeit nach dem Handbuch zu verrichten. Sie arbeiten, wie sie es im Kopf haben. Seitenblick: Eine bekannte Ausnahme sind Piloten, die so ausgebildet werden, dass sie auch routinemäßige Aufgaben gemäß einer Checkliste durchführen. Ändern sich die Geschäftsregeln, muss einfach die Checkliste angepasst werden, und die Änderung ist sofort umgesetzt. Wo nicht „nach Handbuch“ gearbeitet wird, ist es viel schwieriger Änderungen umzusetzen, da immer die Gefahr besteht, dass die Arbeit „auswendig“ nach den alten Geschäftsregeln verrichtet wird.
Change-Management Bei Regeländerungen muss sichergestellt werden, dass die Dokumentation überall angepasst wird. Dies ist mit einer elektronischen Dokumentation, beispielsweise auf dem Intranet, einfacher als mit gedruckten Handbüchern. Auf jeden Fall sollte immer bekannt sein, wo Exemplare der Dokumentation existieren, die angepasst werden müssen. Das ist keine leichte Aufgabe, denn nicht immer weiß man, wer alles mit inoffiziellen Kopien und Ausdrucken arbeitet.
16.2 Lösungsansatz: Rule Management
191
Mitarbeiter-Ausbildung Die Mitarbeiter müssen mit den Geschäftsregeln, die sie bei ihrer Arbeit zu beachten haben, bekannt gemacht werden. Sie müssen die Geschäftsregeln verstehen und sie müssen erkennen, in welchen Fällen welche Geschäftsregel zur Anwendung kommt.
Kontrolle Der Verstoß gegen Geschäftsregeln kann durch das Knowledge Management nicht verhindert, sondern allenfalls im Nachhinein bei einer Kontrolle festgestellt werden. Nicht immer können die Konsequenzen des Regelverstoßes rückgängig gemacht werden. Durch Sanktionen kann der Mitarbeiter möglicherweise dazu gebracht werden, die Geschäftsregel in Zukunft einzuhalten. Allerdings sind Sanktionen nicht die effizienteste Art, einen Mitarbeiter zur Regeleinhaltung zu motivieren. Ein Mitarbeiter ist eher bereit, sich an eine Geschäftsregel zu halten, wenn er versteht, warum die Regel benötigt wird bzw. was mit ihr erreicht werden soll.
16.3 Schritt für Schritt: Aufsetzen des Rule Managements Beim Aufsetzen des Rule Managements handelt es sich nicht um einen starren Prozess, vielmehr sollen, unter Beachtung der in Kapitel 16.2 diskutierten Gesichtspunkte, verschiedene Dinge geregelt werden. Auf die wichtigsten Punkte wird in den folgenden Schritten eingegangen. 1. Umsetzung definieren Die Umsetzung wird für eine Regelung als ganzes definiert. Ist das nicht möglich, kann eine Regelung auch in zwei Regelungen aufgeteilt werden. Bei der Wahl der Umsetzungsstrategie sollte man der Automatisierung den Vorzug geben, denn die automatische Ausführung der Geschäftsregeln ist schneller, weniger Fehleranfällig und in der Regel billiger. Es gibt aber einige Aspekte, die gegen die Automatisierung einer Regelung sprechen können: – Aufwand: Die Automatisierung einer Regelung setzt voraus, dass dem IT-System alle Fakten gemäß dem Faktenmodell in irgendeiner Form zugänglich sind. Die automatische Beschaffung dieser Fakten kann aufwändig und teuer sein. In einzelnen Fällen ist es auch möglich, dass die Beschaffung der Fakten problemlos, die Automatisierung der Regelung selbst (mit der gewählten Technologie) aber nicht wirtschaftlich ist.
192
16 Rule Management
Umsetzbarkeit: Es gibt Regelungen, die sich nicht automatisieren lassen, weil sie nicht konkretisiert werden können. Dies ist dann der Fall, wenn zwar die Grundlagen der Regelung bekannt sind, aber die Art und Weise, in der aus diesen Grundlagen die Ergebnisse abgeleitet werden, nicht beschrieben werden kann. – Umgehung: Was bei der Umsetzung durch Knowledge Management einfach ist, nämlich die Umgehung einer Geschäftsregel in einer Ausnahmesituation, ist bei der Automatisierung erst mal nicht möglich. Um trotzdem diese Art der Flexibilität zu erreichen, muss die „Umgehung“ der Geschäftsregel in die Geschäftsregel eingebaut werden. Beispielsweise können für spezielle Mitarbeiter andere Geschäftsregeln gelten die es erlauben, dass diese Mitarbeiter die Ausnahmefälle behandeln. Aufgrund der genannten Aspekte wird für jede Regelung entschieden und dokumentiert, ob sie mittels Business Rules Technologie oder mittels Knowledge Management Ansätzen umgesetzt werden soll. –
2. Aktivitäten des Rule Managements definieren Basierend auf den Kriterien aus Kapitel 16.2.2 werden die Aktivitäten für das Rule Management definiert. Dabei kann mit folgender Liste, welche die Grundfunktionalität des Rule Managements abdeckt, begonnen werden: – Regelung verwalten: Erstellen, Ändern und Löschen von Regelungen und ihren Geschäftsregeln. – Regelung prüfen: Feststellen, ob eine Regelung korrekt, vollständig und konsistent ist und bei ihrer Umsetzung zum gewünschten Effekt führt. – Regelung freigeben: Verfügen, dass eine Regelung und ihre Geschäftsregeln auf einen Termin hin in Kraft gesetzt werden. – Angeordnete Regelung in Kraft setzen: Aktualisierung der Dokumentation und Information der betroffenen Mitarbeiter. – Automatisierte Regelung in Kraft setzen: Aktualisierung der in den IT-Systemen automatisierten Geschäftsregeln. Diese Aktivitäten müssen basierend auf den konkreten Anforderungen an das Rule Management ergänzt und verfeinert werden. Eine Verfeinerung macht beispielsweise dann Sinn, wenn für verschiedene Benutzergruppen unterschiedliche Änderungsmöglichkeiten benötigt werden.
16.3 Schritt für Schritt: Aufsetzen des Rule Managements
193
Seitenblick: Die Aktivitäten des Rule Managements müssen letztlich durch ein Werkzeug, und sei es eine Textverarbeitung, unterstützt werden. Das bedeutet, dass aus ihnen Anforderungen an das Rule Management Werkzeug abgeleitet werden können. Umgekehrt gilt: Ist das Werkzeug bereits festgelegt macht es wenig Sinn, Aktivitäten zu definieren, die durch das Werkzeug nicht unterstützt werden. 3. Verantwortlichkeiten im Rule Management definieren Die Verantwortlichkeiten im Rule Management werden üblicherweise mit Hilfe von Rollen definiert. Die Rollen werden den Aktivitäten zugeteilt. In einem zweiten Schritt werden die Rollen den entsprechenden Mitarbeitern vergeben. Dies geschieht meist auf der Ebene der Regelung. So kann beispielsweise M. Oney die Rolle der Verantwortlichen für die Regelung Kreditlimite innehaben, während sie für alle anderen Regelungen keine Rolle im Rule Management hat.
16.4 Ergebnis: Der Änderungsprozess von KnowBeer Es wurde beschlossen, die Art der Umsetzung auf der Ebene der Regelung festzulegen und nicht auf der Ebene einzelner Geschäftsregeln. Außer der Regelung der Verkaufskompetenzen sollen alle Regelungen, die den Verkauf betreffen, automatisiert werden. Die Regelung der Verkaufskompetenzen enthält Folgerungen wie beispielsweise das Budget für Marketingaktionen, deren Einhaltung nur mit erheblichen Kosten automatisch überprüft werden kann. Daher soll sie vorerst nicht automatisiert werden. Die beschlossene Umsetzung ist in einer erweiterten Version der Tabelle 13.3 festgehalten.
194
16 Rule Management
Prio Regelung H
Kreditlimite
Begründung Verminderung des Ver-
Umsetzung
Verantwortlich
BRT
M. Oney
BRT
T. Reiber
BRT
B. Remser
BRT
T. Reiber
KMA
(Personal-
lustrisikos durch unge-
Tabelle 16.1 Umsetzung der Regelungen von KnowBeer
deckte Kredite. H
Rabattbestimmung
Vermeidung von Verlusten durch zu hohe Rabatte.
H
Gratismuster
Möglichst rasche Positionierung auf den neuen Märkten.
M
Bevorzugter Kunde
Gleichbehandlung aller Kunden um ungute Gefühle zu vermeiden.
M
Verkaufskompetenzen
Vermeidung von Kompetenzstreitigkeiten im
wesen)
Verkaufsbereich. T
Stückpreis
Korrekte Berücksichti-
BRT
R. Abatt
BRT
(Logistik)
gung der Beschaffungskosten. T
Versandkosten
Korrekte Berücksichtigung der Versandkosten.
KMA: Umsetzung mittels Knowledge Management Ansätzen BRT: Umsetzung mittels Business Rules Technologie
B. Remser hat die Verkaufskompetenzen auf einem Flyer zusammengefasst und im Intranet von KnowBeer publiziert (siehe Abb. 16.2). Alle Verkaufsmitarbeiter wurden zudem per E-Mail informiert.
16.4 Ergebnis: Der Änderungsprozess von KnowBeer
195
KnowBeer
Abb. 16.2 Flyer „Verkaufskompetenzen“
Regelung „Verkaufskompetenzen“ Verkäufer und Verkaufsleiter haben, abhängig von ihrem Dienstalter, unterschiedliche Kompetenzen, und zwar für • das Budget • den speziellen Preisnachlass • die Abgabe von Gratismuster • die Visierung von Bestellungen Die Details können der folgenden Tabelle entnommen werden.
Jeder ist für die Einhaltung selbst verantwortlich! Mit Stichproben muss gerechnet werden. Regel
1
2
3
x
x
x
4
5
x
x
Bedingung Mitarbeiter hat Funktion
Verkäufer
Mitarbeiter hat Dienstalter
< 1 Jahr
Verkaufsleiter x
1…5 Jahre
x x
> 5 Jahre
x x
x
Folgerung Mitarbeiter hat Kompetenz
Marketingaktionen bis Budget X€ initiieren
0€
1k€ * DA
5k€
10k€
50k€
Kundenbesuche bis Budget X€ pro Jahr
0€
1k€ * DA
10k€
10k€
10k€
Preisnachlass bis X% unter Minimum gemäss Regelung 15
0%
0%
2%
5%
10%
Gratismuster bis X€ pro Bestellung abgeben
20€
50€
100€
200€
500€
1k€
5k€
10k€
50k€
unlim.
Bestellungen bis max. X€ alleine visieren DA = Dienstalter in Jahren
Gültig ab 1.1.2006, bis auf Widerruf. (BR)
Um die Verantwortlichkeiten zuordnen zu können, wurden für das Regelmanagement von KnowBeer die folgenden Aktivitäten festgelegt:
196
Regelung verwalten Hinzufügen, Ändern und Löschen von einzelnen Geschäftsregeln einer Regelung. Regelung anpassen Verändern von Zahlenwerten in den Geschäftsregeln, ohne das sonst etwas in der Geschäftsregel geändert wird. Regelung freigeben Freigeben einer Regelung für die Inkraftsetzung auf einen bestimmten Termin hin.
16 Rule Management
Angeordnete Regelung in Kraft setzen Ausbreitung einer neuen oder geänderten Regelung in der Betriebesorganisation. Automatisierte Regelung in Kraft setzen Ausbreitung einer neuen oder geänderten Regelung in den ITSystemen. Es wird angestrebt, dass diese Ausbreitung mit minimalem Aufwand möglichst automatisch geschieht. Feedback sammeln Sammeln und Auswerten der Erfahrungen, die mit der Anwendung der Regelungen im Unternehmen gemacht werden.
Abb. 16.3 zeigt diese Aktivitäten im Rule Management Prozess von KnowBeer: Regelung verwalten
Regelung anpassen
Abb. 16.3 Rule Management Prozess von KnowBeer
Regelung prüfen
Regelung freigeben
Angeordnete Regelung in Kraft setzen
Automatisierte Regelung in Kraft setzen
Feedback sammeln
Ein Mitarbeiter muss für jede Aktivität, die er ausführen will, berechtigt sein. Die Berechtigung wird auf der Stufe der Regelung erteilt. Die geplanten Berechtigungen in KnowBeer wurden in der folgenden Tabelle dargestellt:
16.4 Ergebnis: Der Änderungsprozess von KnowBeer
197
Tabelle 16.2 Berechtigungen im Rule Management
Regelung
Anpassen
Verwal- Freigeten ben
Durch KM ausbreiten
Durch IT ausbreiten
Kreditlimite
M. Oney
D. Enker
M. Oney
B. Remser
(IT)
Rabattbestimmung
T. Reiber
T. Reiber
T. Reiber
B. Remser
(IT)
Gratismuster
B. Remser
D. Enker
B. Remser
B. Remser
(IT)
Bevorzugter Kunde
T. Reiber
D. Enker
T. Reiber
B. Remser
(IT)
Verkaufs-
(Personal-
D. Enker
(Personal-
B. Remser
-
kompetenzen
wesen)
Stückpreis
R. Abatt
D. Enker
R. Abatt
B. Remser
(IT)
Versandkosten
(Logistik)
D. Enker
(Logistik)
B. Remser
(IT)
wesen)
Die Berechtigungen in Tabelle 16.2 spiegeln einige Grundentscheide wider, die durch die Leitung von KnowBeer gefällt wurden: Vorerst sollen nur die Verantwortlichen einer Regelung die Kompetenz haben, Anpassungen vorzunehmen. In einer späteren Phase könnte diese Kompetenz an einen erweiterten Personenkreis übertragen werden. D. Enker wurde als Regelverwalter bestimmt. Er soll im Regelverwaltungswerkzeug die Geschäftsregeln erfassen und pflegen. Eine Ausnahme bildet die Rabattbestimmung, wo T. Reiber die Verwaltung übernimmt. Es ist vorgesehen, diese Kompetenz später generell an die Verantwortlichen für die Regelungen abzugeben. Die Freigabe erfolgt immer durch die Verantwortlichen der Regelung. B. Remser wird der Knowledge Manager von KnowBeer. Er ist für die Inkraftsetzung der Regelungen zuständig, die nicht automatisiert werden. Er muss außerdem alle Betroffenen auch über diejenigen Regelungen informieren, die mit Business Rules Technologie umgesetzt werden. Die IT soll dafür sorgen, dass die Regelungen automatisiert werden können. Dies wird im Rahmen eines IT-Projekts realisiert. Für das Sammeln des Feedbacks sind die jeweiligen Verantwortlichen der Regelungen zuständig. Ein weiterer Auftrag an die IT lautet, für das Rule Management ein geeignetes Werkzeug bereit zu stellen, da mit Microsoft Word die Prozesse des Rule Management nicht genügend unterstützt werden können.
198
16 Rule Management
16.5 Wie geht es weiter? Die eine Regelung, die mittels Knowledge Management Ansätzen umgesetzt wird, wurde bereits an die betroffenen Mitarbeiter kommuniziert. Auf Seite der IT muss als nächstes ein Werkzeug für das Rule Management beschafft und die Automatisierung der Regelungen umgesetzt werden. Zu diesem Zweck wird das Projekt „FIT“ („Flexible IT“) gestartet. In diesem Projekt sollen die bestehenden IT-Systeme so erweitert und ergänzt werden, dass sie in der Lage sind, die Regelungen flexibel umzusetzen.
16.5 Wie geht es weiter?
199
17 IT-Anforderungsdefinition
In diesem Kapitel wird aufgezeigt, wie Anforderungen an die ITUnterstützung zur Umsetzung der Geschäftsregeln erstellt werden können.
17.1 Ausgangslage: Klare Anforderungen? KnowBeer hat vor zwei Jahren die flexible verkaufsunterstützende Standardapplikation „myTBQ“ des ERP-Anbieters „TBQ – Total Business Quality“ angeschafft. Deren Funktionalität lässt sich wie folgt zusammenfassen:
Kundenverwaltung mit konfigurierbaren Kundeneigenschaften flexibel konfigurierbarer Produktkatalog Bestellwesen mit einfacher Preis- und Rabattberechnung Schnittstelle zu verschiedenen Buchhaltungssystemen bidirektional erweiterbar via API basiert auf der Microsoft .NET Plattform mit SQL 2005 Server
Dieses Standardpaket wurde durch den Integrator und ITHauslieferant „4get-IT“34 auf die Bedürfnisse von KnowBeer maßgeschneidert und installiert. Daneben wurde „Calcus“ als Buchhaltungs-Software installiert und durch „4get-IT“ mit „myTBQ“ integriert. Nun stellt sich für die Verantwortlichen von KnowBeer die Frage, wie die zur Automatisierung vorgesehenen Regelungen in dieser IT-Umgebung umgesetzt werden sollen. B. Oss und D. Enker halten zu diesem Zweck eine Besprechung ab: B. Oss:
34
Nun Daniel, die Anforderungen sind klar. Ich denke, du bist die geeignete Person, um sie umzusetzen.
Siehe http.//www.4get-IT.com
17 IT-Anforderungsdefinition
201
D. Enker: B. Oss: D. Enker:
B. Oss: D. Enker:
B. Oss: D. Enker:
B. Oss: D. Enker:
B. Oss:
Der Aufgabe bin ich sicherlich gewachsen, aber für mich sind die Anforderungen ganz und gar nicht klar. Das verstehe ich nicht, wir haben doch unsere Geschäftsregeln dokumentiert. Das habt ihr wohl, nur: Eine Geschäftsregel ist keine Anforderung, sondern eben einfach eine Geschäftsregel. Eine Anforderung wäre beispielsweise, dass eine bestimmte Geschäftsregel automatisch durchgesetzt werden soll. Aber das ist nicht mal der entscheidende Punkt. Für die Umsetzung der Geschäftsregeln in unseren IT-Systemen fehlen uns wichtige Informationen. Geschieht denn die Umsetzung nicht mit einer dieser Rule Engines? Das ist eine Möglichkeit, aber es gibt auch noch verschiedene Andere. Und genau um für jede Regelung die richtige Art der Umsetzung zu wählen brauchen wir weitere Angaben. An was denkst du dabei? Erinnerst du dich an das Gespräch an den Abschlussparty, als es um das Ändern von Geschäftsregeln ging? Du hast gemeint, Benno Remser sei der Richtige, um die Rabatt-Regeln zu ändern. Ihr habt von Änderungen gesprochen, noch bevor auch nur eine Geschäftsregel überhaupt automatisiert worden ist. Das hat mir zu denken gegeben. Um die beste Möglichkeit zur Umsetzung der Geschäftsregeln zu wählen, müssen wir unbedingt wissen, wie häufig sie ändern. Wie nennen das die „Volatilität“ einer Geschäftsregel. Das habt ihr sicher schnell abgeklärt. Wie müssen das richtig angehen, es geht ja nicht nur um die Volatilität. Es gilt auch noch andere Aspekte zu beachten, beispielsweise wann eine Geschäftsregel überprüft werden soll. Nein, wir müssen zuerst eine Zusammenstellung der Anforderungen haben bevor wir mit der Umsetzung beginnen können. Wenn du meinst, dann beauftrage ich dich hiermit, die Anforderungen zu dokumentieren.
Als guter Vorgesetzter kann D. Enker delegieren und reicht den Auftrag, die Anforderungen zu dokumentieren, an seinen Mitarbeiter H. Acker weiter:
202
17 IT-Anforderungsdefinition
D. Enker:
H. Acker:
D. Enker:
H. Acker: D. Enker:
Hast du den Auftrag verstanden, Herbie? Du erstellst ein Dokument, in dem die Anforderungen an die Umsetzung der Geschäftsregeln mit BR-Technologie festgehalten sind. Alles klaro! Und dann holen wir uns ein paar neue Tools ins Haus und bauen eine regelbasierte Verkaufsapplikation. Das ist genau das, was wir nicht tun werden. Wir befinden uns nicht auf einer „grünen Wiese“. Wir haben viel Zeit und Geld in die Einführung und Integration von „myTBQ“ und „Calcus“ investiert. Diese Investitionen müssen wir schützen! Das kannst du gleich mal als erste Anforderung notieren. Schade! Eine saubere neue Anwendung zu entwickeln wäre doch viel interessanter. So ist nun mal die Realität. Aber keine Angst, wir werden uns sicherlich mit einigen neuen und interessanten Dingen beschäftigen. Am Ende aber soll KnowBeer einen Nutzen davon haben.
Nach diesem Gespräch macht sich H. Acker mit mäßiger Motivation daran, die Anforderungen zusammenzutragen.
17.2 Lösungsansatz: Anforderungen an die Automatisierung Die Automatisierung von Geschäftsregeln in einem realen Umfeld erfordert, dass die vorhandenen IT-Systeme durch zusätzliche Funktionalität erweitert werden. Dies findet im Rahmen eines ITProjektes statt. Insofern kommen hier die üblichen Verfahren aus Projektmanagement und Software Engineering zu Anwendung. Die benötige zusätzliche Funktionalität wird in Form von Anforderungen spezifiziert, wobei es einige spezielle Aspekte zu beachten gilt, die im Folgenden erläutert werden.
Anforderungen und Geschäftsregeln Das Verhalten von IT-Systemen wird normalerweise in Form von Anforderungen und Modellen beschrieben. Bei den Anforderungen wird zwischen funktionalen und nicht-funktionalen Anforderungen unterschieden. Wie passen nun die Geschäftsregeln in diese Bild? Soll eine Geschäftsregel automatisiert werden, entsteht aus ihr eine Anforderung an das IT-System. Die Anforderung besteht allerdings nicht in der Geschäftsregel selbst sondern darin, dass die Geschäftsregel durch
17.2 Lösungsansatz: Anforderungen an die Automatisierung
203
das IT-System automatisiert werden soll. Es besteht also zwischen Anforderungen und Geschäftsregeln ein enger Zusammenhang. Trotzdem sind Geschäftsregeln und Anforderungen nicht dasselbe. Die Anforderungen zur Automatisierung von Geschäftsregeln bilden einen wichtigen Teil der funktionalen Anforderungen. Daneben gibt es aber auch weitere, nicht auf Geschäftsregeln basierende Anforderungen. Die Anforderungen an die Automatisierung richten sich pauschal an die IT als ganzes. Konkret umgesetzt aber werden die Anforderungen in den einzelnen Anwendungen oder Komponenten. Es muss daher für jede Anforderung die Frage beantwortet werden, welche Anwendung oder Komponente von ihr betroffen ist. Eine einzelne Anforderung kann dabei durchaus mehrere Anwendungen betreffen. Dies gilt insbesondere für die Anforderungen zur Automatisierung der Regelungen. Wenn KnowBeer beispielsweise neben der Anwendung „myTBQ“ auch eine Internet-Anwendung zum Erfassen von Bestellungen einführen würde, dann müsste die Regelung zur Kreditlimite in beiden Anwendungen automatisiert werden. Abb. 17.1 zeigt schematisch, wie für verschiedene Anwendungen aus einem Teil der Geschäftsregeln unterschiedliche Anforderungen an die Automatisierung entstehen. Abb. 17.1 Regelungen und Anforderungen
Anforderung zur Automatisierung App2 App3
App1
RegelKatalog
Volatilität und Ausbreitungszeit Unter der Volatilität versteht man die erwartete Häufigkeit von Änderungen einer Direktive, also einer Regelung oder Geschäftsregel. Eine hohe Volatilität einer Regelung bedeutet, dass sie häufig geändert wird, eine tiefe Volatilität, dass sie selten geändert wird. Die Volatilität bezieht sich auf eine ganze Regelung oder auf einzelne Geschäftsregeln, nicht aber auf die von ihr als Grundlagen verwendeten Informationen. Die Ermittlung der Volatilität einer Regelung ist eine wichtige Grundlage, um eine geeignete Art der Umsetzung wählen zu können. Eine flexible Umsetzung einer Regelung hat ihren Preis, meist
204
17 IT-Anforderungsdefinition
in Form einer gewissen Komplexität und einer schlechteren Laufzeit-Effizienz. Daher möchte man Reglungen nicht flexibler als nötig umsetzen. Eine Geschäftsregel, die garantiert nie ändert, kann direkt in einem Programm kodiert oder gar in einer HardwareKomponente umgesetzt werden. Eine Geschäftsregel hingegen, die täglich ändern kann, muss auf eine sehr flexible Weise umgesetzt werden. Die Volatilität einer Regelung oder Geschäftsregel ist eine Aussage über die Zukunft. Sie ist daher oft sehr spekulativ und entsprechend ungenau. Eine hohe Genauigkeit ist aber gar nicht nötig, viel mehr geht es um die Angabe einer Größenordnung. Typische Angaben zur Volatilität sind:
stündlich (ein mal pro Stunde) täglich (ein mal pro Tag) wöchentlich (ein mal pro Woche) monatlich (ein mal pro Monat) jährlich (ein mal pro Jahr) nie
In einem Business Rules Projekt spielt die Volatilität eine zentrale Rolle, denn es geht primär darum, die geforderte Flexibilität in die IT-Systeme einzubauen. Bestehende, eher unflexibel IT-Systeme sollen so geändert und erweitert werden, dass Änderungen im Rhythmus der Volatilität einfach, rasch und günstig durchgeführt werden können. Ein weiterer Aspekt einer Regeländerung ist die maximale Ausbreitungszeit, d.h. die Geschwindigkeit der Änderung. Sie wird gemessen ab der Freigabe einer geänderten Regelung bis zum Zeitpunkt, an dem die Regelung in Kraft gesetzt ist, d.h. auf den operativen Systemen wirkt. Übliche Werte sind:
innerhalb x Minuten innerhalb x Stunden innerhalb x Tagen
In der Praxis kann sowohl der Zeitpunkt der Freigabe als auch der Zeitpunkt der Inkraftsetzung fix sein. Müssen beispielsweise die Preise jeweils am Stichtag des 1. Januars geändert werden, so ist dieser Stichtag fix. Die Ausbreitungszeit besagt, wann die Preise spätestens freigegeben werden müssen, damit sie rechtzeitig in Kraft gesetzt sind. Oft muss die Regeländerung aber einfach innerhalb einer bestimmten Frist nach der Freigabe in Kraft sein. Muss die Regeländerung „per sofort“ in Kraft gesetzt werden, kann dies erhebliche Anforderungen an die Umsetzung stellen.
17.2 Lösungsansatz: Anforderungen an die Automatisierung
205
Prüfzeitpunkt Idealerweise stellt man sich wohl vor, dass alle Geschäftsregeln immer sofort geprüft werden. Das ist technisch nicht immer einfach umsetzbar. Vor allem bei Einschränkungen kann es sein, dass ihre sofortige Überprüfung zu lange dauert und den Betrieb aufhalten würde. Seitenblick: Bei der Automatisierung der Geschäftsregel muss der Prüfungszeitpunk sorgfältig gewählt werden. „Sofort“ bedeutet dann nicht unbedingt sofort. So kann beispielsweise bei der Bearbeitung einer Bestellung die Kreditlimite zwischenzeitlich überschritten sein wenn zuerst neue Positionen hinzugefügt werden bevor andere gelöscht werden. Dies muss möglich sein. Die Geschäftsregel wird erst dann „sofort“ überprüft, wenn die ganze Bestellung gespeichert wird. Etwas vereinfacht kann man sagen, dass die Geschäftsregeln während Transaktionen nicht gelten und frühestens am Ende der Transaktion geprüft werden. In solchen Fällen muss dann die Geschäftsregel im Nachhinein, z.B. über Nacht, geprüft werden. Aber auch das kann zu Problemen führen, wenn der Schaden, der durch die Verletzung der Geschäftsregel entstand, nicht mehr korrigiert werden kann. Verletzt beispielsweise eine neu erfasste Bestellung die Kreditlimite des Kunden, so kann die Bestellung am nächsten Tag storniert werden. Werden hingegen Produkte exportiert, obwohl beispielsweise eine Bewilligung nicht vorlag, ist es am nächsten Tag zu spät. Die Ware ist bereits weg. Zum Zeitpunkt der Anforderungsdefinition weiß man natürlich noch nicht, ob solch ein kritischer Fall vorliegt. Besteht zumindest ein Verdacht, dass die Umsetzung problematisch sein könnte, lohnt es sich, mit den Anwendern zu sprechen. Dabei kann man erstens die Erwartungshaltung auf Seiten der Anwender etwas dämpfen und zweitens abklären, wie lange die Ausführung der Regelung verzögert werden kann. Seitenblick: D. Enker konnte bei seiner Bestellung des Buches „Der Business Rules Ansatz“ bei Amazon.de ein interessantes Verhalten feststellen: Nach der erfassten Bestellung erhielt er sofort per E-Mail eine Bestellbestätigung zugeschickt. Ein paar Stunden später erhielt er ein zweites E-Mail das ihm mitteilte, dass seine Kreditkarten-Angaben nicht korrekt seien. Offensichtlich wurde die Kreditkarte nicht bei der Erfassung der Bestellung geprüft, sondern erst etwas später.
206
17 IT-Anforderungsdefinition
Einbettung der BR-Technologie in eine bestehende IT-Systemlandschaft Heutzutage ist es selten, dass ein IT-System neu erstellt wird, ohne in andere IT-Systeme eingebunden zu sein. Gerade bei der Einführung von BR-Technologie muss man davon ausgehen, dass bereits vorhandene IT-Systeme erweitert, ergänzt oder einfach weiterverwendet werden. Daher gehören zu den Anforderungen auch Aussagen über die bestehende IT-Systemlandschaft.
Anforderungen an das Rule Management Werkzeug Das Rule Management Werkzeug dient der Unterstützung des Rule Management Prozesses, wie er in Kapitel 16 beschrieben wurde. Es geht um die Frage, welche Funktionalität das Werkzeug den verschiedenen Benutzern zur Verfügung stellen soll. Für die Dokumentation der funktionalen Anforderungen haben sich Anwendungsfälle bewährt, denn sie beschreiben die Funktionalität des Werkzeugs von außen gesehen, ohne auf innere Abläufe einzugehen. Ein wichtiger Aspekt ist auch, durch welche Benutzer die einzelnen Anwendungsfälle ausgeführt werden können. Je nach Funktion und Qualifikation dieser Benutzer ergeben sich ganz unterschiedliche Anforderungen an Benutzerfreundlichkeit des Rule Management Werkzeug. Dabei geht es um Themen wie die Darstellung der Geschäftsregeln oder die Unterstützung beim Schreiben von Geschäftsregeln.
17.3 Schritt für Schritt: Erhebung der Anforderungen Die folgenden Schritte zeigen auf, wie die Anforderungen an die BR-Technologie für die Umsetzung von Geschäftsregeln sowie für das Rule Management erhoben werden können. Geht es nicht nur um die Einführung von BR-Technologie in bestehende IT-Systeme, sondern um ein neues IT-System, das BRTechnologie verwendet, dann müssen natürlich vor allem auch alle „normalen“ Anforderungen, die nichts mit BR-Technologie zu tun haben, erhoben werden. 1. Volatilität ermitteln Für jede zu automatisierende Regelung wird ihre Volatilität festgehalten, also die erwartete Änderungshäufigkeit. Ausgangspunkt dafür sind die in der Vergangenheit beobachteten Änderungsintervalle. Wichtiger aber ist eine Betrachtung in die
17.3 Schritt für Schritt: Erhebung der Anforderungen
207
Zukunft. Dabei kann die Motivation der Regelung, also ihre Herleitung aus Einflüssen und Einschätzungen, helfen: Wie schnell ändern sich diese Einflüsse auf das Unternehmen, und wie häufig werden sie neu eingeschätzt? 2. Ausbreitungszeit ermitteln Parallel zur Volatilität gilt es für jede Regelung festzuhalten, wie schnell sie nach ihrer Freigabe in Kraft gesetzt sein muss. Dabei kann man sich meist nicht auf die Vergangenheit abstützen, denn da waren Änderungen zu langsam. Vielmehr muss aus unternehmerischer Sicht überlegt werden, nach welcher Zeit die Regelung spätestens umgesetzt sein muss bzw. wie früh vor der Inkraftsetzung eine Regelung freigegeben werden kann. Tipp:
Für die Schritte 1 und 2 muss nochmals intensiv mit den Regelverantwortlichen und ihren Fachspezialisten gesprochen werden. Nur sie können diese Anforderungen beurteilen. Achtung: Übertriebene Angaben zur Volatilität und Forderungen zur gewünschten Ausbreitungszeit schränken die Lösungsmöglichkeiten ein und machen das Ganze teurer. Es passt beispielsweise schlecht zusammen, wenn im Unternehmen über neue Rabattarten 6 Monate diskutiert wird, ihre Einführung aber in ein paar Tagen geschehen soll.
3. Anforderungen aus den Regelungen ableiten Für jede Regelung, die automatisiert werden soll, kann eine Anforderung erstellt werden. Diese Anforderung besteht in der Verpflichtung, die Regelung gemäß ihrer Spezifikation zu automatisieren. Besonders zu beachten sind dabei die Rubriken Ableitungen, Einschränkungen, Aktionen und Durchsetzung. 4. Umgebung beschreiben Die zukünftige IT-Systemumgebung beschreiben. Es wird festgelegt, welche Anwendungen weiterhin verwendet werden sollen und welche allenfalls ersetzt werden können. Es wird für jede einzelne Anforderung zur Automatisierung aufgelistet, welche Anwendungen fachlich von den zu automatisierenden Regelungen betroffen sein könnten.
208
17 IT-Anforderungsdefinition
5. Anwendungsfälle für Rule Management Werkzeug festlegen Die wichtigsten Anwendungsfälle modellieren, welche den Benutzern des Rule Management Werkzeuges zur Verfügung stehen müssen. Dies geschieht basierend auf dem Rule Management Prozess, wobei für jede Aktivität überlegt wird, wie diese durch ein Werkzeug unterstützt werden könnte.35 6. Anforderungen an Rule Management Werkzeug skizzieren Erste funktionale und nicht-funktionale Anforderung an das Rule Management Werkzeug festhalten. Dabei geht es um eine erste Liste benutzernaher Anforderungen. Eine systematische Ermittlung der Anforderungen an das Werkzeug findet später statt (siehe Kapitel 18). Seitenblick: Die Business Rules Technologie ermöglicht das einfache Anpassen von Regelungen. Dies gilt allerdings nur, wenn sich die Änderungen im Rahmen des bestehenden Faktenmodells (siehe Kapitel 10) bewegen. Wird für die geänderte Regelung ein erweitertes Faktenmodell benötigt, ist Schluss mit der einfachen Anpassung. Aus diesem Grund ist ein zukunftssicheres Faktenmodell wichtig, welches auch mögliche zukünftige Geschäftsregeln unterstützt. Falls nicht bereits geschehen lohnt es sich, das Faktenmodell in einem Brainstorming auf denkbare und noch undenkbare Varianten der Zukunft zu testen.
17.4 Ergebnis: IT-Anforderungsdefinition Herbie Acker hat sich mächtig ins Zeug geworfen und unter Mithilfe von D. Enker, T. Reiber und den Regelverantwortlichen verschiedene Anforderungen gesammelt und dokumentiert. Diese sind im Folgenden auszugsweise wiedergegeben.
17.4.1 Anforderungen an die Umsetzung mittels Business Rules Technologie Für die zu automatisierenden Regelungen wurden die folgenden Angaben zur Volatilität und Ausbreitungszeit ermittelt:
35
Eine gute Anleitung zur Anwendungsfall-Modellierung findet sich in „UML 2.0 projektorientiert“ [GRA04]
17.4 Ergebnis: IT-Anforderungsdefinition
209
Tabelle 17.1 Volatilität und Ausbreitungszeit
Regelung
Umsetzung
Volatilität
Ausbreitungszeit
Kreditlimite Rabattbestimmung
BRT
Halbjährlich
30 Tage
BRT
Täglich
6 Stunden
Gratismuster
BRT
Wöchentlich
24 Stunden
Bevorzugter Kunde
BRT
Jährlich
30 Tage
Stückpreis
BRT
Monatlich
24 Stunden
Versandkosten
BRT
Halbjährlich
30 Tage
BRT: Umsetzung mittels Business Rules Technologie
Es wurde auch versucht, zusammen mit den Regelverantwortlichen abzuschätzen, wie häufig die Regelungen ausgeführt werden. Dabei hat sich gezeigt, dass die meisten Regelungen bei jeder Bestelländerung ausgeführt werden (was nicht verwundern kann, handelt es doch ausschließlich um Regelungen aus dem Verkauf). Für die zukünftige Entwicklung wurde von einem guten Wachstum von KnowBeer ausgegangen. Tabelle 17.2 Häufigkeit der Regelausführung
Regelung
Ausführungshäufigkeit
Ist Erwartet Erwartet Vorjahr Nächstes in 5 Jahr Jahren
Kreditlimite
Pro Bestelländerung
23.000
27.500
56.000
Rabattbestimmung
Pro Bestelländerung
23.000
27.500
56.000
Gratismuster
Pro Bestellung
Bevorzugter Kunde Pro Bestelländerung
21.000
25.000
53.000
23.000
27.500
56.000
Stückpreis
Pro Bestelländerung
23.000
27.500
56.000
Versandkosten
Pro Bestelländerung
23.000
27.500
56.000
Tabelle 17.3 zeigt die Anforderungen an die Automatisierung: Tabelle 17.3 Anforderungsliste zur Automatisierung
Id
Anforderung
Art
A01
Automatisierung der Regelung „Kreditlimite“
F
A02
Automatisierung der Regelung „Rabattbestimmung“
F
A03
Automatisierung der Regelung „Gratismuster“
F
A04
Automatisierung der Regelung „Bevorzugter Kunde“
F
A05
Automatisierung der Regelung „Stückpreis“
F
A06
Automatisierung der Regelung „Versandkosten“
F
A07
Die vorhandene Standartsoftware „myTBQ“ muss
NF
weiter verwendet werden A08
Die vorhandene Standartsoftware „Calcus“ muss wei- NF ter verwendet werden
A09
Das Mengengerüst muss bewältigt werden können
NF
A10
Bei Ableitungen soll der Benutzer herausfinden kön-
F
nen, die die Ableitung zustande gekommen ist.
210
17 IT-Anforderungsdefinition
Id
Anforderung
Art
A11
Wird eine Einschränkung verletzt soll der Benutzer
F
erfahren, welche Geschäftsregel er verletzt hat. A12
Regeländerungen dürfen den Betrieb der Anwendun-
NF
gen „myTBQ“ und „Calcus“ nicht unterbrechen. F = funktionale Anforderung NF = nicht-funktionale Anforderung
Auf eine Auflistung der von den einzelnen Regelungen betroffenen Anwendungen konnte verzichtet werden: Von allen Regelungen ist die Anwendung „myTBQ“ betroffen. Von der Regelung „Kreditlimite“ könnte, abhängig von der Art der Umsetzung, auch die Anwendung „Calcus“ betroffen sein. Dies muss später noch geklärt werden
17.4.2 Anforderungen an das Rule Management Basierend auf dem Rule Management Prozess von KnowBeer (siehe Abb. 16.3) wurden das folgende Anwendungsfall-Diagramm erstellt: Abb. 17.2 Anwendungsfälle des Rule Managements
Regelung mittels Automatisierung in Kraft setzen
Rule Manager
Regelung verwalten
Regelung mittels Knowledge Management in Kraft setzen Knowledge Manager
Regelung anpassen Feedback sammeln Verantwortlicher
Regelung prüfen
Alle
Regelung freigeben
17.4 Ergebnis: IT-Anforderungsdefinition
211
Außerdem wurden folgende Anforderungen an das Rule Management ermittelt: Tabelle 17.4 Anforderungsliste zum Rule Management
Id
Anforderung
Art
AR01
Regelsprache, die es erlaubt, Regeln in deutscher
NF
AR02
Regeleditor mit Templates und Anbindung an Fak-
Sprache zu formulieren F
tenmodell AR03
Möglichkeit, Regeln als Entscheidungstabellen zu
F
erfassen AR04
Versionierung von Geschäftsregeln und Regelungen
F
AR05
Inkraftsetzung und Außerkraftsetzung von Regelun-
F
gen auf ein bestimmtes Datum hin AR06
Export von Geschäftsregeln und Entscheidungstabel-
F
len F = funktionale Anforderung NF = nicht-funktionale Anforderung
17.5 Wie geht es weiter? Basierend auf den Anforderungen an die IT-Unterstützung kann sich die Informatik nun daran machen, eine geeignete Lösung zu finden. Als erstes geht es um die Frage, welche Möglichkeiten zur Umsetzung dieser Anforderungen die Technologie überhaupt zur Verfügung stellt. Zur Beurteilung dieser Möglichkeiten müssen ihre Vorund Nachteile bekannt sein. Das nächste Kapitel gibt einen Überblick über die Business Rules Technologie und liefert die Grundlage zur Evaluation von Lösungen.
212
17 IT-Anforderungsdefinition
18 BR-Technologie
In diesem Kapitel wird aufgezeigt, was Business Rules Technologie ist und welche Eigenschaften bei deren Evaluation zu berücksichtigen sind.
18.1 Ausgangslage: Was ist Business Rules Technologie? Herbert Acker kommt aufgeregt ins Büro seines Chefs, Dr. Daniel Enker: H. Acker:
D. Enker: H. Acker: D. Enker: H. Acker: D. Enker:
H. Acker: D. Enker:
H. Acker:
Hallo Daniel! Ich habe eben eine ganz coole Rule Engine aus dem Internet 'runtergeladen: FreeRules! Ganz kostenlos! Und welche Eigenschaften weist sie auf? Sie ist komplett in Java implementiert und ausgesprochen schnell! Und wie sieht die Regelsprache aus? Regeln können direkt in Java formuliert werden – wir müssen kaum umlernen! Da bin ich aber ganz anderer Meinung! Die Zielgruppe unserer Geschäftsregeln sind die Fachvertreter unserer Firma. Glaubst du wirklich, dass Benno Remser seine neue Preispolitik in Java schreiben wird? Das nicht, aber wir können sie für ihn implementieren! Ich glaub’ du hast ’s noch immer nicht begriffen! Wichtigster Grundsatz des Business Rules Ansatzes ist „Business First!“. Aber die wissen ja schon lange nicht mehr, wie das Geschäft wirklich funktioniert! Gerade gestern ist Tina Reiber zu mir gekommen und hat mich wieder einmal gefragt, wie unser Rabattsystem funktioniert.
18 BR-Technologie
213
D. Enker:
H. Acker:
D. Enker:
H. Acker: D. Enker:
H. Acker: D. Enker:
Genau das soll sich in Zukunft ändern. In Zukunft soll das Rabattsystem Sache der Verkäufer sein, Unsere Aufgabe ist es, eine entsprechende Infrastruktur bereit zu stellen. Aber ist das noch interessant für uns? Nur noch Infrastruktur bereitstellen und nichts mehr selber entwickeln? Ganz so schlimm wird’s nicht kommen. Wir müssen ja zuerst eine flexible IT-Architektur konzipieren und dürfen geeignete Business Rules Technologie evaluieren. Heißt das, dass wir noch andere Engines als FreeRules ansehen müssen? Nicht nur das! Einerseits ist Business Rules Technologie mehr als nur Business Rule Engines und andererseits müssen wir Lösungen evaluieren, welche die Anforderungen unseres Geschäfts optimal erfüllen. Dies kann sogar so weit gehen, dass wir gewisse Komponenten selber entwickeln werden! Super! Ich melde mich freiwillig, um die flexibelste Rule Engine zu entwickeln, die die Welt je sah! Langsam, langsam! Zuerst müssen wir uns überlegen, wie wir die Anforderungen an die von uns geforderte IT-Unterstützung am besten erfüllen können!
18.2 Lösungsansatz: BR-Technologie Der Business Rules Ansatz wird in der Zwischenzeit durch eine ganze Familie von IT-Standardprodukten unterstützt. Die Business Rule Engines sind nur ein Mitglied dieser Familie. Im Sinne einer ganzheitlichen Betrachtung unterscheiden wir folgende Arten von Business Rules Technologie:
214
Rule Execution Technologie: Damit sind Technologien gemeint, welche die Ausführung von Geschäftsregeln im operationellen Betrieb ermöglichen. Einerseits zählen dazu die eigentlichen so genannten Business Rule Engines. Andererseits sind heutige Datenbank- und Workflow-Management-Systeme ebenfalls in der Lage, gewisse Typen von Geschäftsregeln effizient auszuführen. Selbst „handgestrickte“, ausprogrammierte Lösungen lassen sich zu dieser Klasse von Business Rules Technologie zählen. Wir werden im Kapitel 18.2.1 noch genauer auf die verschiedenen Möglichkeiten zur Ausführung von Geschäftsregeln eingehen.
18 BR-Technologie
Rule Management Technologie: Damit sind Werkzeuge gemeint, welche die Verwaltung von Geschäftsregeln ermöglichen, nicht jedoch deren automatische Ausführung im operationellen Betrieb. Insbesondere im Falle von Business Rule Engines sind in der Praxis die Kategorien „Rule Management Technologie“ und „Rule Execution Technologie“ oft vermischt, da eine Business Rule Engine ohne die Möglichkeiten der Pflege der Regeln wenig Sinn macht. Dieser Umstand führt dazu, dass es heute leider noch relativ wenig „reine“ Rule Management Werkzeuge auf dem Markt gibt, die als „Frontend“ für verschiedene Rule Execution Technologien dienen können. Rule Discovery Technologie: Damit sind Werkzeuge gemeint, die das Auffinden von Geschäftsregeln unterstützen. Dazu zählen einerseits „ganz alte“ Ansätze wie Werkzeuge für Reverse Engineering von Code aus Legacy-Applikationen. Andererseits gehören dazu auch innovative neue Ansätze wie die Erkennung von Mustern in großen Datenbeständen (z.B. Kundentransaktionen) und die Ableitung von Regeln daraus.
Zur Business Rules Technologie im Weiteren Sinn könnte auch noch die Knowledge Management Technologie gezählt werden, welche die Sammlung, Bereitstellung und Verteilung von Wissen zwischen Menschen ermöglicht. In diesem Buch werden wir allerdings nicht weiter auf diesen Aspekt eingehen.
18.2.1 Rule Execution Technologie Für die automatische Ausführung von Geschäftsregeln mittels Rules Execution Technologien: lassen sich verschiedene Lösungsansätze unterscheiden:
Business Rule Engine: Dies sind Software-Komponenten, welche auf die effiziente und flexible Ausführung von Geschäftsregeln spezialisiert sind. Dazu werden der Business Rule Engine sämtlichen relevanten Unternehmensdaten in einer Form zur Verfügung gestellt, dass sie diese als Faktenbasis für die Ausführung der Regeln verwenden kann. Diese Regel-Ausführung wird dann typischerweise von einer „normalen“ IT-Applikation als Service angestoßen. Datenbank: Heutige Datenbank Managementsysteme weisen Eigenschaften auf, mit denen sie sich auch sehr gut zur Ausführung von Geschäftsregeln qualifizieren. Beispielsweise können mit Hilfe geeigneter SQL-Views Ableitungen auf großen Datenmengen gebildet werden. Ein Teil der Einschränkungen lassen sich durch Datenbank-Constraints realisieren. Schließlich
18.2 Lösungsansatz: BR-Technologie
215
lassen sich mittels Stored Procedures und Trigger zumindest ein Teil der Prozessregeln sowie komplexe Einschränkungen realisieren. Insbesondere dann, wenn sehr große Datenmengen zu bearbeiten sind, kann diese datenbankorientierte Technologie unschlagbare Vorteile aufweisen. Konfiguration: Ist in einer Applikation eine für den Endbenutzer zugängliche Flexibilität gefordert, so wurden schon immer Mechanismen realisiert, um die Applikation konfigurierbar zu machen. Oft bauen solche Konfigurationsmechanismen auf Konfigurations-Dateien oder Konfigurationstabellen in Datenbanken auf und bieten eine einfache Benutzerschnittstelle zur Pflege der Konfiguration. Ausprogrammierung: Die weitaus häufigste Art zur Implementation von Geschäftsregeln ist deren Ausprogrammierung in einer konventionellen Programmiersprache. Dies ist nichts anderes, als die klassische Implementation der Geschäftslogik einer Applikation. Das muss nicht notwendigerweise eine schlechte Lösung sein: Ändern diese Regeln sehr selten und ist ihr Inhalt für kaum jemanden von Interesse, so wäre jede andere Lösung ein unnötiger Aufwand!
Mit der Einführung von Rule Execution Technologie geht oft auch ein gewisser Terminologie-Wechsel einher. Die Begriffe und Konzepte aus der technologieneutralen Geschäftsanalyse müssen auf die Begriffe und Konzepte der verwendeten Produkte der Rule Execution Technologie abgebildet werden. Ein typisches solches Beispiel ist die Bezeichnung einer Menge von Geschäftsregeln, die wir bisher Regelung genannt haben. Business Rule Engines verwenden hierfür Begriffe wie Ruleset, Policy oder schlicht Module.
18.2.2 Regel-Komplexität Geschäftsregeln können nicht nur unterschiedlich groß, sondern auch unterschiedlich komplex sein. Damit ist der logische Formalismus gemeint, der zur Ausführung der Regeln benötigt wird. Hierbei lassen sich drei Stufen von Regel-Komplexität unterscheiden:
216
Einfache Aussagelogik: Geschäftsregeln sind aus einfachen Ja/Nein-Kriterien aufgebaut, die durch die logischen Operatoren „UND“, „ODER“ und „NICHT“ verknüpft werden. Beispiel: WENN es regnet UND ich bin draußen DANN werde ich nass.
18 BR-Technologie
Aussagelogik mit Funktionen: Geschäftsregeln sind aus Funktionen, d.h. Kriterien mit Argumenten, aufgebaut, die durch die logischen Operatoren „UND“, „ODER“ und „NICHT“ verknüpft werden. Beispiel: WENN es heute regnet UND ich bin heute draußen DANN werde ich heute nass. In diesem Beispiel fungiert „heute“ als ein Argument zu den drei Kriterien „es regnet“, „ich bin draußen“ und „ich werde nass“. Es kann beliebig geändert (parametrisiert) werden (z.B. auf „morgen“), wodurch dieselben Kriterien (Funktionen) vielseitig einsetzbar werden. Prädikatenlogik: Geschäftsregeln sind aus Prädikaten mit logischen Variabeln aufgebaut, die durch die logischen Operatoren „UND“, „ODER“ und „NICHT“ verknüpft werden und deren Variabeln durch die Quantoren „FÜR ALLE“ und „ES GIBT EIN“ quantifiziert sind. Beispiel: FÜR ALLE Datum GILT, DASS WENN es regnet an diesem Datum UND ich bin draußen an diesem Datum DANN werde ich nass an diesem Datum.“ In diesem Beispiel fungiert „Datum“ als eine logische Variable, welche die drei Kriterien „es regnet“, „ich bin draußen“ und „ich werde nass“ über einen beliebigen, aber gemeinsamen Wert verbindet. Durch den „FÜR ALLE“ Quantor wird die Regel für jedes beliebige Datum gültig gemacht und ersetzt somit eine unendliche Anzahl Regeln in einfacher Aussagelogik. Die Kriterien werden in diesem Falle als Prädikate bezeichnet.
Nicht jede Business Rule Engine unterstützt die höchste Stufe der Prädikatenlogik. Daher ist dies ein wichtiges Evaluationskriterium.
18.2.3 Logische Schlussfolgerungen Eine der Hauptaufgaben der Rule Execution Technologie ist das Ziehen von Schlüssen, auch Inferenz genannt. Dabei wird aus vorhandener Information sowie einer Regel neue Information abgeleitet. Schlussfolgerungsregeln lassen sich in verschiedene Richtungen verwenden. Nehmen wir als Beispiel die folgenden zwei einfachen Regeln: r1: wenn dann r2: wenn dann
es regnet und ich bin draußen werde ich nass. es kalt ist und ich bin draußen friere ich.
18.2 Lösungsansatz: BR-Technologie
217
Wenn ich beispielsweise weiß, dass es regnet und dass ich draußen bin, so kann ich aufgrund der Regel r1 den Schluss ziehen, dass ich nass werde36. Dies wird Vorwärts-Inferenz genannt Die Initiative erfolgt vorwärts von der Bedingung der Regel zu deren Folgerung. Wenn ich aber wissen will, ob ich friere, so muss ich aufgrund der Regel r2 klären, ob es kalt ist und ob ich bin draußen bin. Da in diesem Fall die Initiative von der Folgerung der Regel zurück zur Bedingung geht, wird dieses Vorgehen Rückwärts-Inferenz: genannt. Inferenzen erstrecken sich oft über mehrere Stufen. Zur Illustration fügen wir noch zwei weitere Regeln zu den oben aufgeführten Regeln hinzu: r3: wenn dann r4: wenn dann
ich nass werde öffne ich den Schirm. ich friere oder nass werde ziehe ich den Mantel an.
Diese vier Regeln bilden ein Netzwerk von Regeln und Aussagen, welches in Abb. 18.1 dargestellt ist. Abb. 18.1 InferenzNetzwerk
ich öffne den Schirm
ich werde nass
? es regnet
r1
!
r3
? Ich bin draussen
oder
r2 ich friere
?
!
r4
ich ziehe den Mantel an
es ist kalt
Legende:
?
Grundlage
Aussage
!
Ergebnis
rx
Regel
Falls nun bekannt ist, dass es regnet und dass ich draußen bin, können diese Tatsachen in das Regel-Netzwerk einspeisen werden und es liefert via Vorwärts-Inferenz die Empfehlung, sowohl den Schirm zu öffnen als auch den Mantel anzuziehen (Abb. 18.2). Die Vorwärts-Inferenz erzeugt somit aus einer gegebenen Menge Grundlagen sämtliche daraus ableitbaren Ergebnisse.
36
Diese Art von Schlussfolgerung wird in der formalen Logik als „Modus Ponens“ bezeichnet.
218
18 BR-Technologie
Vorwärts-Inferenz
Tatsachen
es regnet
ich öffne den Schirm
ich werde nass
? r1
r3
Abb. 18.2 VorwärtsInferenz
!
? Ich bin draussen
oder
r2
r4
ich friere
?
! ich ziehe den Mantel an
es ist kalt
Ist man jedoch lediglich an der Frage interessiert, ob der Schirm geöffnet werden soll, so kann dem Regel-Netzwerk diese Frage als Hypothese präsentiert werden worauf es via Rückwärts-Inferenz die Frage stellt, ob es regnet und ob ich draußen bin (Abb. 18.3). Die Rückwärts-Inferenz versucht also, eine gegebene Hypothese mittels Regeln auf vermutete Tatsachen zurück zu führen. Abb. 18.3 RückwärtsInferenz
Rückwärts-Inferenz
es regnet
ich öffne den Schirm
ich werde nass
? r1
r3
! Hypothese
? Ich bin draussen
?
oder
r2 ich friere
r4
! ich ziehe den Mantel an
es ist kalt
Ob ein Regel-Netzwerk via Vorwärts- oder Rückwärts-Inferenz verwendet wird, hängt von verschiedenen Faktoren ab. VorwärtsInferenz wird dann sinnvoll eingesetzt, wenn
Abfragen der Ergebnisse (Outputs) häufiger erfolgen als Änderungen an den Grundlagen (Inputs) typischerweise viele Ergebnisse (Outputs) aus den selben Grundlagen (Inputs) abgeleitet werden sollen relativ wenige Grundlagen (Inputs) für die Ableitung der Ergebnisse (Outputs) zu berücksichtigen sind diese Grundlagen (Inputs) relativ einfach zu beschaffen sind (da sie beispielsweise alle schon vorhanden sind).
Demgegenüber ist die Verwendung der Rückwärts-Inferenz dann sinnvoll, wenn
18.2 Lösungsansatz: BR-Technologie
219
Änderungen an den Grundlagen (Inputs) häufiger erfolgen als Abfragen der Ergebnisse (Outputs) typischerweise pro Fall nur wenige, spezifische Ergebnisse (Outputs) aus den Grundlagen (Inputs) abzuleiten sind viele Grundlagen (Inputs) für die Ableitung der benötigten Ergebnisse (Outputs) zu berücksichtigen sind diese Grundlagen (Inputs) aufwändig zu beschaffen sind (beispielsweise von Benutzer zu erfragen).
Die meisten kommerziell verfügbaren Business Rule Engines unterstützen die Vorwärts-Inferenz, einige die Rückwärts-Inferenz und nur ganz wenige beides. Business Rule Engines, die lediglich Vorwärts-Inferenz unterstützen, basieren meist auf dem Formalismus der Produktionsregeln (siehe auch Kapitel 13.2.3). Diese weisen die Form wenn dann . auf, wobei die in den meisten Fällen eine Veränderung der Faktenbasis bewirkt. Zur effizienten Ausführung von Regeln ist es wichtig, dass eine Business Rule Engine keine unnötige Arbeit leistet. Dazu wurde bereits 1979 von Charles L. Forgy der so genannte RETE-Algorithmus entwickelt. Durch diesen Algorithmus wird sichergestellt, dass keine Aussage in einem Regel-Netzwerk unnötigerweise mehr als einmal berechnet wird. Insbesondere für die Vorwärts-Inferenz ist der RETE-Algorithmus essentiell, da hier sehr viele Ergebnisse und Zwischenergebnisse aus denselben Grundlagen abgeleitet werden. Im Gegensatz dazu ist bei der Rückwärts-Inferenz der RETEAlgorithmus unnötig, da hier lediglich diejenigen Ergebnisse berechnet werden, die als Hypothesen verlangt werden. Seitenblick: Originiellerweise scheint die Vorwärts-Inferenz eher die Domäne der Amerikaner und die Rückwärts-Inferenz eher die Domäne der Europäer zu sein. Dies rührt vermutlich daher, dass die beiden amerikanischen und europäischen Urahnen von Regel-Sprachen jeweils lediglich einen dieser beiden Ansätze unterstützten: Die Programmiersprache OPS5 entstand Ende der 70er Jahre des letzten Jahrhunderts an der Carnegie-Mellon Universität in Pittsburgh, PA und basierte vollständig auf der Vorwärts-Inferenz. Demgegenüber entstand die Programmiersprache PROLOG bereits 1972 an der Universität von Marseille und basierte vollständig auf der Rückwärts-Inferenz.
220
18 BR-Technologie
18.2.4 „Wie“ und „Warum“ Erklärungen Eine Eigenschaft, die Business Rule Engines von klassischen Programmiersprachen unterscheidet, ist die Fähigkeit, ihre Entscheidungen zu begründen. Diese Begründungen können in zwei Arten auftreten:
„Wie“-Erklärung: Wurde ein Ergebnis abgeleitet, so lässt sich ihr Weg durch das Regel-Netzwerk als Erklärung verwenden. Beispielsweise kann die Empfehlung „den Schirm zu öffnen“ folgendermaßen begründet werden: Durch die Regel „r3“, sowie die Feststellung „ich werde nass“, die von Regel „r1“ aus den Grundlagen „es regnet“ und „ich bin draußen“ abgeleitet wurde. „Wie“-Erklärungen können sowohl bei Vorwärts als auch bei Rückwärts-Inferenzen angewandt werden. „Warum“-Erklärung: Ist im Rahmen einer Rückwärts-Inferenz eine Grundlage (Input) erforderlich, so lässt sich, ausgehend von der Hypothese, der Weg durch das Regel-Netzwerk als Erklärung verwenden. So kann beispielsweise die Frage, ob „es regnet“ mit der Regel „r1“ und der Schlussfolgerung „ich werde nass“ sowie der Regen „r3“ und schließlich der Hypothese „ich öffne den Schirm“ begründet werden. „Warum“-Erklärungen sind nur bei Rückwärts-Inferenz möglich, da nur hier überhaupt die Möglichkeit zu pro-aktiven Fragen besteht. Seitenblick: Im Gegensatz zu den heutigen konventionellen ProgrammierParadigmen orientieren sich Business Rule Engines stärker an der bereits 1945 von John von Neumann entwickelten „Von Neumann Architektur“. Wesentlichste Eigenschaft dabei ist, dass Programme und Daten nicht in separaten Speichern, sondern in einem einzigen gemeinsamen Speicher abgelegt sind. Mit anderen Worten: Programme und Daten werden gleichbehandelt. Im Falle von Business Rule Engines heißt dies, dass Regeln sowohl als Programm (da sie Verhalten steuern) als auch als Daten betrachtet werden können (die in einem dynamischen Repository abgelegt sind). Dies führt dazu, dass Business Rule Engines einige Eigenschaften aufweisen, die in konventionellen ProgrammierParadigmen nicht zu finden sind: Business Rule Engines können ihr „Programm“ (die Regelbasis) auf Konsistenz und Widerspruchsfreiheit prüfen. Business Rule Engines können getroffene Entscheidungen begründen, da sie „wissen“ welche Programmteile (die Regelbasis) zur Anwendung gekommen sind.
18.2 Lösungsansatz: BR-Technologie
221
Business Rule Engines können ihr „Programm“ (die Regelbasis) verändern oder erweitern, da sie die Regeln wie gewöhnliche Daten manipulieren können. Nicht in allen kommerziell erhältlichen Business Rule Engines sind diese Eigenschaften gleich stark ausgeprägt und es lässt sich damit auch grober Unfug betreiben (Stichwort „selbstmodifizierende Regelbasen“). Grundsätzlich öffnen diese Möglichkeiten aber in Zukunft den Weg zu lernenden, adaptiven oder gar „selbstbewussten“ IT-Systemen.
18.2.5 Generische BRT Anforderungen Neben den klassischen funktionalen und nicht-funktionalen Anforderungen an ein IT-System lässt sich im Zusammenhang mit dem Business Rules Ansatz ein separater Bereich von Anforderungen unterscheiden. Für diejenigen Bereiche eines IT-Systems, für die eine hohe Transparenz sowie eine hohe Volatilität gefordert wird, muss eine technische Lösung gefunden werden. Da Business Rules Technologie als generische Middleware, d.h. eine allgemein verwendbare Infrastruktur-Technologie, verstanden wird, können sowohl funktionale als auch nicht-funktionale Anforderungen an eine solche Middleware separat betrachtet werden. Im Anhang D.5 sind Checklisten für mögliche Anforderungen an diese drei Technologie-Klassen zusammengestellt. Außerdem sind allgemeine Anforderungen aufgeführt, die alle drei TechnologieKlassen betreffen. Solche generischen Anforderungskataloge müssen selbstverständlich auf die spezifischen Anforderungen eines konkreten IT-Systems angepasst und die einzelnen Anforderungen mit einer individuellen Gewichtung versehen werden. Tipp
222
Im Rahmen einer Evaluation von BR Technologie ist „sehen“ mehr Wert als „glauben“. Stellen Sie daher eine zwar kleine, aber möglichst repräsentative Fallstudie aus dem vorgesehenen Anwendungsgebiet als Aufgabenstellung zusammen und lassen Sie diese durch die in Frage kommenden Lieferanten als kostenlose Machbarkeitsstudie realisieren und erläutern. Dies ermöglicht einen direkten Vergleich (Benchmark) der Möglichkeiten der evaluierten Produkte in einem bekannten Umfeld.
18 BR-Technologie
18.3 Schritt für Schritt: Auswahl der Business Rules Technologie Die verwendete Business Rules Technologie soll gezielt auf die Bedürfnisse der Anwendung ausgerichtet sein. Für deren Auswahl können folgende Schritte empfohlen werden: 1. Regelungsspezifische BRT-Anforderungen identifizieren Die funktionalen Anforderungen an die Business Rules Technologie werden hauptsächlich von den zu automatisierenden Regelungen bestimmt. Aus diesem Grund sollen die zu automatisierenden Regelungen mindestens bezüglich Regel-Semantik und Regel-Repräsentation sowie Performance- und Mengenangaben analysiert werden. Aus diesen Untersuchungen ergeben sich in erster Linie Anforderungen an die notwendige Rule Execution Technologie. Daneben sind aber auch regelungsspezifische Anforderungen an Rule Management Technologie und ggf. sogar an Rule Discovery Technologie zu bestimmen. 2. Umsetzungsstrategie skizzieren Aufgrund der im vorherigen Schritt identifizierten BRTAnforderungen lassen sich nun erste Lösungsansätze zur Automatisierung der Regelungen skizzieren. Dabei wird die jeweils optimalste Rule Execution Technologie vorgeschlagen. Oft sind einfachere Lösungen wie Datenbank-Funktionalität, Konfigurationstabellen oder gar ausprogrammierte Geschäftsregeln nicht nur performanter, sondern auch günstiger als eine ausgewachsene Business Rule Engine (siehe auch Kapitel 18.2.1). Dies ist vor allem in denjenigen Situationen der Fall, wo die Kernanforderungen des Business Rules Ansatzes wie die Transparenz, die Verständlichkeit oder die rasche Änderbarkeit der Fachlogik nicht essentiell sind. Es kann durchaus vorkommen, dass für eine bestimmte Regelung mehr als eine Technologie in Frage kommt oder gar eine Kombination verschiedener Technologien notwendig ist. Beispielsweise eignen sich Business Rule Engines hervorragend für Ableitungen, tun sich in der Regel aber eher schwer mit Einschränkungen. Einschränkungen lassen sich aber wiederum sehr gut durch die Datenbank-Technologie realisieren. Bei der Ausarbeitung dieser Lösungsansätze ist immer auch das bestehende IT-Umfeld zu berücksichtigen: Gewisse Lösungsansätze lassen sich einfacher in bestehende Legacy-Applikationen integrieren als andere.
18.3 Schritt für Schritt: Auswahl der Business Rules Technologie
223
3. BRT-Anforderungskatalog zusammenstellen Sind einmal alle regelungsspezifischen BRT-Anforderungen zusammengetragen und entsprechende Umsetzungsstrategien skizziert, kann ein Anforderungskatalog erstellt werden, der als Grundlage für die Evaluation konkreter BRT-Produkte dient. Dieser enthält typischerweise zusätzliche Anforderungen wie Plattform-Anforderungen oder kommerzielle Anforderungen an den Lieferanten. Schließlich sind die so identifizierten Anforderungen mit einer projektspezifischen Gewichtung zu versehen. 4. BRT evaluieren Nun können auf dem Markt verfügbare BRT-Produkte gesucht werden, welche die gestellten Anforderungen möglichst optimal erfüllen. Dies kann entweder in informaler Weise (im „Selbststudium“) oder aber in Form eines formalen RFI (Request for Information) oder RFQ (Request for Quotation) Prozesses erfolgen. Wird der formalere Weg einer Evaluation in Betracht gezogen, so dient mindestens der Anforderungskatalog als Grundlage. Oftmals ist es zudem sinnvoll, eine BenchmarkFallstudie zu definieren, welche eine konkrete Aufgabenstellung beinhaltet, mit der potentielle Anbieter die Machbarkeit nachweisen können (siehe auch Tipp in Kapitel 18.2.5). Kommen in der erarbeiteten Umsetzungsstrategie nicht nur kommerzielle BRT-Produkte in Betracht, so werden in Schritt 4 ggf. Machbarkeitsabklärungen bezüglich der gewählten Mechanismen notwendig. Insbesondere bei gemischten Ansätzen, bei denen neben einer Business Rule Engine auch andere Mechanismen (Datenbank, Konfiguration, etc.) vorgesehen sind, ist auf folgende Punkte zu achten: – Eignet sich die gewählte Regel-Repräsentation für die betroffenen Fachvertreter? SQL-Statements sind beispielsweise kaum eine geeignete Form, um Geschäftsregeln durch einen Versicherungsspezialisten pflegen zu lassen. In solchen Fällen muss eine entsprechende Pflege-Applikation bereitgestellt werden. – Wenn Geschäftsregeln in verschiedenen Technologien automatisiert sind, so ist ihre zentrale Verwaltung problematisch. Entweder man findet sich mit dezentralen Ablagen der Geschäftsregeln ab, oder es wird eine Rule Management Technologie benötigt, welche zentral definierte Geschäftsregeln für verschiedene Zielsysteme exportieren (ausbreiten) kann. Zudem muss sichergestellt werden, dass dasselbe Faktenmodell sowohl dem Rule Management als auch zur Rule Execution zur Verfügung steht. In der Praxis ist dies heute mit erheblichem Entwicklungsaufwand verbunden.
224
18 BR-Technologie
5. Pilotprojekt durchführen Ist eine formale Evaluation erfolgt, so müssen die eingegangenen Offerten beurteilt bzw. bewertet werden. Sind Eigenlösungen vorgeschlagen, so ist spätestens jetzt ihre Machbarkeit zu beweisen. In beiden Fällen empfiehlt sich die Durchführung eines im Umfang begrenzten Pilotprojektes, bevor ein grandioses Konzept grandios scheitert. Seitenblick: Oft wird die Business Rules Technologie mit der Expertensystem Technologie aus den 80er Jahren des letzten Jahrhunderts verglichen. Zwischen diesen beiden Technologien gibt es zwar Parallelen, aber auch Unterschiede. Expertensystem Technologie ersetzt typischerweise einen menschlichen Experten, automatisiert einige wenige, aber komplexe Entscheidungen (z.B. Medizinalbereich oder technische Störungssuche), arbeitet mit relativ kleinen Datenmengen, bietet oft komplexe Formalismen zur Wissensrepräsentation (Frames, Unsicherheiten, etc.), läuft typischerweise auf hochspezialisierten, geschlossenen Umgebungen und/oder in eingebetteten Lösungen, verwendet eher technische Regel-Sprachen (auf Programmierer-Ebene). Die Business Rules Technologie demgegenüber wird typischerweise für Automatisierung von Geschäftsprozessen eingesetzt, automatisiert eine große Menge von (relativ) einfachen Geschäftsentscheidungen, arbeitet mit sehr großen Datenmengen, betrachtet die Performance als wichtiger als eine flexible Wissensrepräsentation, bietet Produkte, die sich als offene Middleware-Plattformen in eine existierende Umgebung integrieren lassen, verwendet eher Regel-Sprachen, die für Fachexperten verständlich sind.
18.3 Schritt für Schritt: Auswahl der Business Rules Technologie
225
18.4 Ergebnis: Die BRT-Anforderungen von KnowBeer Basierend auf der generischen Anforderungs-Checkliste hat Tina Reiber diejenigen Anforderungen zusammengestellt, welche für KnowBeer relevant sind. Dabei hat sie die Anforderungen, die themenabhängig sind, in einer Matrix den bisher erarbeiteten Regelungen (ausgenommen der Regelung „Verkaufskompetenzen“, die nicht automatisiert wird) gegenübergestellt37:
Stückpreis
Versandkosten x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Gratismuster
x
Regeltypen
Einschränkungen
x
x
(EF1.1)
Ableitungen
x
x
x
x
x
Funktionen
x
x
Variabeln
x
x
Prozessregeln Bedingungen
Logische Operatio-
(EF1.2)
nen
Bevorzugter Kunde
Rabattbestimmung
Anforderung
Kreditmimite
Regelung
Tabelle 18.1 AnforderungsMapping
x x
Interaktive Abfragen (EF2.3)
x
Erklärungskomponente (EF2.6)
x
x x
Aufruf
Abfragen/Tag
1k
1k
500
2k
1k
1k
(ENF1.1)
Datenänderung/Tag
10k
10k
10k
10k
10k
10k
Anzahl Regeln (ENF1.3)
~20
~20
1
2
~5
~20
Antwortzeiten (ENF2.1)
< 2s
< 1s
< 1s
< 1s
< 1s
< 10s
x
x
x
x
Regel-
Strukturierte Sprache
x
x
repräsent.
Entscheidungstabellen
x
x
(MF3)
Berechnungen
x
x
x x
x
Aufgrund dieser Analyse wurde an einer Sitzung von Tina Reiber, Daniel Enker und Herbert Acker folgende technische Umsetzung der Regel-Ausführung skizziert:
Kreditlimite: Aufruf einer Business Rule Engine zur Bestimmung der Kreditlimite sowie Durchsetzung der Kreditlimite via DB-Constraints und/oder DB-Trigger
37
Die in der Tabelle gezeigten (Kürzel EF1.1 etc.) beziehen sich auf die Checkliste im Anhang D dieses Buches
226
18 BR-Technologie
Rabattbestimmung: Bestimmung des Bestellpreis-Bereiches durch Aufruf einer Business Rule Engine und der RabattFunktionalität von „myTBQ“ Gratismuster: Prozessregel durch DB-Trigger Bevorzugter Kunde: Ableitung, welche Kunden bevorzugt sind, mittels SQL-View Stückpreis: Bestimmung des aktuellen Stückpreises durch Aufruf einer Business Rule Engine; Änderung nur durch berechtigte Personen Versandkosten: Bestimmung der Versandkosten durch Aufruf einer Business Rule Engine
Seitenblick: Die oben aufgeführten Lösungsansätze zur technischen Umsetzung sind mit Absicht vielseitig gestaltet. Dies erfolgte aus didaktischen Gründen, damit sich im weiteren Verlauf dieses Buches auch verschiedene technische Umsetzungen illustrieren lassen. In der Praxis ist eine möglichst homogene Umsetzung anzustreben, auch wenn dies nicht immer machbar ist. Sämtliche Regelungen (auch diejenigen, welche zurzeit nicht automatisiert werden) sollen zentral verwaltet werden. Dazu wurde das Rule Management System „RegulationMaster“38 beschafft, welches folgende Eigenschaften aufweist:
Unterstützung des Unternehmensvokabulars via UML-basiertes Faktenmodell und verknüpfbaren Definitionen Unterstützung von Regeln in Form von Entscheidungstabellen Unterstützung beliebiger textueller Regelsprachen mittels konfigurierbarem syntaxgesteuertem Regel-Editor Unterstützung der Versionierung von Regelungen und einzelnen Geschäftsregeln mit Gültigkeitsdatum Einfache Möglichkeiten für die Geschäftsprozessmodellierung Ausgereifte Möglichkeiten zur Verifikation von Entscheidungstabellen Verschiedene konfigurierbare Reports und Auswertungen (u. a. auch Verwendungsnachweis für Objekt- und Fakttypen) Import und Export des Unternehmensvokabulars via XMI Möglichkeiten für flexibles Web-Deployment
38
Da wir als Autoren dieses Buches herstellerneutral sind und sich der BRT-Markt noch in heftiger Bewegung befindet, handelt es sich bei den durch KnowBeer beschafften Systemen um fiktive Produkte, die (unseres Wissens) so nicht auf dem Markt existieren.
18.4 Ergebnis: Die BRT-Anforderungen von KnowBeer
227
Selektiver Export von Regelungen als Text oder im FOL RuleML39 Format (Version 0.9) Geographisch verteilbares Repository mit MehrbenutzerUnterstützung und Autorisierungs-Mechanismen Automatisierbar via API
Leider weist „RegulationMaster“ zurzeit keine Möglichkeiten zur Validierung von Regelungen auf. Durch die Integration mit einer (noch zu evaluierenden) Business Rule Engine lässt sich dieser Mangel allerdings relativ einfach beheben. Ebenso sind die Generatoren für die vorgesehenen SQL-Views, -Constraints und -Trigger zu entwickeln. Für die Evaluation der Business Rule Engine wurde folgender spezifischer Anforderungskatalog (siehe Tabelle 18.2) erstellt40. Mit der eigentlichen Evaluation wird aber noch zugewartet, bis einige Architektonische Fragen geklärt sind. Tabelle 18.2 Anforderungen an eine Business Rule Engine
Id
Anforderung
F01
Es müssen Einschränkungen, Ableitungen und Prozessregeln unter-
Prio H
stützt werden. [EF1.1] F02
Es müssen prädikatenlogische Ausdrücke unterstützt werden. [EF1.2]
H
F03
Es müssen Datenbank-Aktualisierungen durch Regeln unterstützt
M
werden. [EF1.3] F04
Regeln müssen beliebig verkettet werden können. [EF1.7]
H
F05
Regeln müssen zu Gruppen strukturiert werden können. [EF1.9]
M
F06
Es muss Vorwärts-Inferenz unterstützt werden. [EF2.1]
H
F07
Es muss Rückwärts-Inferenz unterstützt werden. [EF2.2]
M
F08
Bei der Ausführung von Regeln müssen Fakten interaktiv nachgefragt
M
werden können. [EF2.3] F09
Es müssen „Wie“ Erklärungen automatisch generiert werden. [EF2.6]
H
F10
Erklärungen müssen in verschiedenen Landessprachen generiert wer-
T
den können. [EF2.7] F11
Die zur Anwendung gekommenen Regeln müssen protokolliert wer-
T
den. [EF4.2] NF01
Die Business Rule Engine muss auf unserer Windows/.NET Plattform
H
lauffähig sein (Server und Benutzungsschnittstelle). [A1.1, A1.2] NF02
Die Business Rule Engine muss mindestens 1.000 Mal pro Stunde
H
aufgerufen werden können [ENF1.1]
39
Ein möglicher Kandidat für ein zukünftiges Standardformat für die Repräsentation von Regeln auf der Basis von XML. Siehe auch Anhang H dieses Buches. 40 Die in der Tabelle gezeigten (Kürzel EF1.1 etc.) beziehen sich auf die Checkliste im Anhang D dieses Buches.
228
18 BR-Technologie
Id NF03
Anforderung
Prio
Die Business Rule Engine muss mindestens 1.000 gleichzeitig aktive
H
Regeln verarbeiten können. [ENF1.3] NF04
Die Antwortzeit der Business Rule Engine darf in keinem Fall 1s ü-
H
berschreiten. [ENF2.1] K01
Der BRT-Lieferant muss eine Zusammenarbeit mit unserem Hauslie-
H
feranten „4get-IT“ eingehen. [A2.5] K02
Die jährlichen Lizenz- und Wartungskosten dürfen 5.000 Euro nicht
M
überschreiten. [A2.6] Legende zur Kolonne „Prio“ (Priorität):
H:
Hoch, d.h. Muss-Anforderung
M:
Mittel, d.h. Wunsch-Anforderung
T:
Tief, d.h. „Nice to have“-Anforderung
Die Anforderung F07 wurde aufgenommen, da die Datenaktualisierungen bei den in Frage kommenden Regelungen durchwegs häufiger vorkommen als deren Abfragen. Außerdem sind in gewissen Fällen auch interaktive Benutzerabfragen gefordert.
18.5 Wie geht es weiter? Nun sind die Anforderungen an die für das Geschäft optimale Business Rules Technologie identifiziert und erste Lösungsskizzen zur Automatisierung der Geschäftsregeln formuliert. Eventuell sind sogar erste Machbarkeitsstudien oder Prototypen entstanden. Bevor nun aber voller Elan Business Rule Engines und Business Management Umgebungen installiert und in den produktiven Betrieb überführt werden, sind einige wichtige architektonische Überlegungen anzustellen. Die Erfahrung hat nämlich gezeigt, dass die methodisch sauber identifizierten und formulierten Geschäftsregeln, wie wir sie bisher kennen gelernt haben, noch einiges „durchmachen“ müssen, bis sie in einer realen technischen Umgebung produktiv im Einsatz stehen. Worauf man beim Einsatz von Business Rules Technologie aus architektonischer Sicht achten muss, um unliebsame Überraschungen zu vermeiden, ist Gegenstand des nächsten Kapitels.
18.5 Wie geht es weiter?
229
19 BR-Architektur
In diesem Kapitel wird aufgezeigt, welche Möglichkeiten für die Gestaltung einer leistungsfähigen Business Rules Architektur denkbar sind und worauf beim Architektur-Entwurf zu achten ist.
19.1 Ausgangslage: Regeln ohne Fakten? Mehr als zwei Wochen hat sich nun Herbert Acker mit den DemoVersionen zweier in Frage kommender kommerzieller Business Rule Engines befasst. Er hat sämtliche Tutorials durchgearbeitet und auch bereits erste Prototypen gebaut. Allerdings bleiben noch einige konzeptionelle Fragen offen. Darum wendet er sich an seinen Chef, Daniel Enker, um die Sache zu diskutieren: H. Acker: D. Enker: H. Acker:
D. Enker: H. Acker:
D. Enker: H. Acker:
D. Enker: H. Acker:
Hallo Daniel! Wie kommen die Daten in die Engine? Bitte? Ich habe nun einiges mit den Rule Engines gemacht, aber eines ist mir nicht klar geworden: Wie kommen die Daten aus einer Datenbank in die Rule Engine? Ich nehme an, du meinst, wie die Fakten zu den Regelungen kommen? Mag schon sein, aber diese Beispiele, die ich durchgearbeitet habe, haben relativ wenig mit der Realität zu tun. Da wird die Rule Engine in einem kleinen Demoprogramm aufgerufen, das gleich einen Beispielkunden und seine Bestellung im Speicher kreiert. Und was ist daran nicht gut? Wir haben unsere Kunden in einer Datenbank und können sie nicht einfach so ad hoc im Memory kreieren! Das ist doch alles bloß Spielzeug! Ich denke, da auch andere Firmen diese Technologie einsetzen, kann’s wohl nicht so schlimm sein! Dann zeig du mir, wie wir damit eine performante Lösung hinkriegen!
19 BR-Architektur
231
D. Enker:
Die Lösung muss ja auch noch mit „myTBQ“ zusammenarbeiten. Ich denke, da müssen wir uns einmal mit „4get-IT“ zusammensetzen und eine Architektur ausarbeiten!
Die verkaufsunterstützende Standardapplikation „myTBQ“ basiert auf einer relationalen Datenbank, in der diejenigen Informationen abgelegt sind, die als Fakten in den Regelungen verwendet werden. Da „myTBQ“ mit dieser Datenbank arbeitet, dürfen allfällige Änderungen keinesfalls bestehende Elemente ändern, sondern lediglich zusätzliche Elemente einführen. Dies ist eine zentrale technische Rahmenbedingung für das Projekt „FIT“. Aus diesem Grund hat Daniel Enker die Struktur der Datenbank analysiert und deren Schema in Abb. 19.1 dargestellt. Abb. 19.1 Die Datenbank von „myTBQ“
TKundentypen KTId Bezeichnung
TKunden KNr Name * Typ Ansprechperson Strasse PLZ Ort * Land Telefon Fax Email Kreditlimite Jahresumsatz Zahlungsprobleme Bemerkungen Status
232
TLänder LId Bezeichnung MwSt-Satz1 MwSt-Satz2 MwSt-Satz3
TLieferanten LNr Firmenname Ansprechperson Strasse PLZ Ort * Land Telefon Fax Email Bemerkungen Status
TLager
TArtikeltypen ATId Bezeichnung
LNr Bezeichnung Strasse PLZ Ort * Land Telefon Fax Email Bemerkungen Status
TArtikel ANr * Lieferant Bezeichnung * Typ Einheit Stückpreis Beschreibung Status
TBestand * Lager * Artikel Bestand Reorder Bemerkungen Status
TBestellungen
TBestellzeilen
TArtikeleigenschaftstypen
BNr * BTId * Kunde Bestelldatum Wunschdatum Express Lieferdatum Bruttopreis Versandkosten Rabatt Nettopreis Bezahlt Bemerkungen Status
* Bestellung * Artikel Menge Rabatt
ETId Bezeichnung Typ
19 BR-Architektur
TRabatte * Artikel Min Max Rabatt
TArtikeleigenschaften
TBestelltypen BTId Bezeichnung
* Artikel * Eigenschaft Wert
Die Tabellen für die konfigurierbaren Kunden- und Bestellungseigenschaften (analog zu Artikeleigenschaften) werden in diesem Schema nicht gezeigt.
19.2 Lösungsansatz: Architektur Sollen Geschäftsregeln durch eine Business Rule Engine automatisiert werden, so müssen verschiedene architektonische Überlegungen angestellt werden. Die Erfahrung zeigt, dass mit einer falsch gewählten Architektur sehr viel mehr Performance verloren gehen kann, als mit einer vermeintlich „langsamen“ Technologie.
19.2.1 Business Rules Architekturen Im Zusammenhang mit der Automatisierung von Geschäftsregeln lassen sich grundsätzlich verschiedene Makro-Architekturen unterscheiden:
Service-Architektur Schichten-Architektur Datenbank-Architektur Generator-Architektur
Diese Architekturen werden im Folgenden etwas genauer erläutert.
Service-Architektur Die Service-Architektur wird von den meisten Business Rule Engines als Standard-Architektur angenommen, da sie relativ einfach zu realisieren ist. In dieser Architektur (siehe Abb. 19.2) wird die Business Rule Engine immer dann aus der Host-Applikation aufgerufen, wenn eine Entscheidung gefällt werden soll. Dazu holt die HostApplikation via SQL-Schnittstelle alle für die Entscheidung notwendigen Informationen und stößt dann via Rule Service API die Evaluation der gewünschten Regelung in der Business Rule Engine an. Business Rules Engine
Host-Applikation
Rule Service API Geschäftsregeln
Abb. 19.2 ServiceArchitektur
SQL DBMS Datenbank
19.2 Lösungsansatz: Architektur
233
Die Service-Architektur weist verschiedene Vorteile auf, welche sie für einen raschen Einstieg prädestiniert:
Sie ist einfach in eine bestehende Umgebung integrierbar, da die Business Rule Engine eine eigenständige Komponente außerhalb der bestehenden Applikationen darstellt. Durch den sukzessiven Einbau von entsprechenden Service-Aufrufen lässt sich die Business Rule Engine schrittweise in die bestehenden Applikationen integrieren. Diese Architektur bietet eine gute Unterstützung für Ableitungsregeln. Wann immer in der Host-Applikation eine (komplexe) Entscheidung getroffen werden muss, wird einfach die Business Rule Engine aufgerufen. Bietet die Business Rule Engine eine Erklärungskomponente, so ermöglicht der situative Aufruf der Business Rule Engine eine gute Transparenz: Bei Bedarf kann unmittelbar nach dem Aufruf für die Entscheidung ein weiterer Aufruf an die Business Rule Engine abgesetzt werden, um die Begründung für die getroffene Entscheidung zu erfragen. Es sind viele kommerzielle Produkte verfügbar, welche diese Architektur unterstützen.
Die Service-Architektur hat aber aufgrund ihrer Einfachheit auch Grenzen: Da für eine Entscheidung sämtliche dazu notwendigen Grundlagen an die Business Rule Engine übergeben werden müssen, kann dies zu Performance-Einbussen führen. Dies ist insbesondere dann problematisch, wenn große Datenmengen zu transferieren sind, da dies bei jedem Aufruf erneut erfolgen muss. Benötigt eine geänderte Geschäftsregel zusätzliche Grundlagen, muss der Aufruf der Business Rule Engine in der HostApplikation angepasst werden. Dies kann aufwändig sein. Geschäftsregeln können umgangen bzw. ignoriert werden, da die Business Rule Engine nicht aufgerufen werden muss. So kann eine Host-Applikation beispielsweise einen Rabatt selber berechnen, obwohl dazu in der Business Rule Engine eine Regelung vorhanden wäre. Da in dieser Architektur die Business Rule Engine nur bei Bedarf aufgerufen wird, ist sie weniger gut für Einschränkungen geeignet. Wird die Business Rule Engine nämlich nicht aufgerufen, so hat sie auch keine Chance, allfällige Einschränkungen zu überwachen. Prozessregeln sind relativ schwierig realisierbar, da die auszulösenden oder zu kontrollierenden Aktionen in der HostApplikation via „Call-Back“-Mechanismus zu realisieren sind.
234
19 BR-Architektur
Schichten-Architektur Bei der Schichten-Architektur (siehe Abb. 19.3) fungiert die Business Rule Engine als „Wächter“ der Datenbank. Dazu wird eine Schicht zwischen die Datenbank und die Host-Applikation eingezogen über welche jeder Datenbankzugriff erfolgen muss. In dieser Zwischenschicht sitzt die Business Rule Engine, kontrolliert jeden einzelnen Zugriff und weist ihn gegebenenfalls zurück. Abb. 19.3 SchichtenArchitektur
Host-Applikation
Business Object API Business Rules Engine Geschäftsregeln
SQL DBMS Datenbank
Im Vergleich zur Service-Architektur hat die Schichten-Architektur einen wesentlich größeren Einfluss auf die bestehende Applikationslandschaft, bietet aber auch Vorteile:
Sie bietet eine gute Unterstützung sowohl für Ableitungen als auch für Einschränkungen. Einschränkungen können nur schwer umgangen werden, da der Weg zu den Daten nur via die Business Rule Engine erfolgen kann. Dadurch schützen Einschränkungen die Daten und garantieren damit ihre Konformität mit den Geschäftsregeln Ableitungen lassen sich transparent integrieren, da Geschäftsobjekte auf der Ebene über der Business Rule Engine auch Eigenschaften aufweisen können, die durch Ableitungen aus der Datenbank ermittelt wurden. Ein Geschäftsobjekt „Kunde“ kann beispielsweise Eigenschaften wie „Name“ und „Kreditlimite“ aufweisen, von denen „Name“ direkt aus der Datenbank bezogen wird (deklarierter Fakttyp) die „Kreditlimite“ aber durch eine Regelung abgeleitet wird (abgeleiteter Fakttyp).
Demgegenüber weist die Schichten-Architektur aber auch wesentliche Nachteile auf:
Das von der Business Rule Engine bereit gesellte „Business Object API“ ist typischerweise ein proprietärer ZugriffsMechanismus auf die Datenbank.
19.2 Lösungsansatz: Architektur
235
Zudem ist ein solches „Business Object API“ oft als Servicebasierte Schnittstelle konzipiert, welche eine viel geringere Flexibilität aufweisen als eine SQL-basierte Schnittstelle. Prozessregeln sind relativ schwierig realisierbar, da die auszulösenden oder zu kontrollierenden Aktionen in der HostApplikation via „Call-Back“-Mechanismus zu realisieren sind. Auch in dieser Architektur kann die Performance problematisch sein, da jeder einzelne Datenbankzugriff über diese Zwischenschicht gehen muss, selbst wenn die Business Rule Engine nichts dazu zu sagen hat.
Datenbank-Architektur In der Datenbank-Architektur wird auf den Einsatz einer Business Rule Engine völlig verzichtet. An ihre Stelle tritt die Funktionalität einer modernen relationalen Datenbank. Dazu zählt einerseits die Definition von Views, mit denen sich auch komplexe Ableitungen realisieren lassen. Andererseits können mittels Constraints, Triggern und Stored Procedures auch komplexe Einschränkungen direkt in einer Datenbank realisiert werden. Insbesondere Views lassen sich selbst im laufenden Betrieb einer Datenbank hinzufügen oder gar ändern, was einen kurzen Änderungszyklus ermöglicht. Abb. 19.4 DatenbankArchitektur
Host-Applikation
SQL DBMS
Datenbank
Geschäftsregeln
Die Automatisierung von Geschäftsregeln durch die Bordmittel einer relationalen Datenbank bietet folgende Vorteile:
236
Geschäftsregeln können praktisch nicht umgangen werden, da kein Weg an der Datenbank vorbei führt. Datenbanken bieten eine äußerst starke Unterstützung von Einschränkungen. So sind sie beispielsweise in der Lage, jede Transaktion zurück zu weisen, die eine Geschäftsregel verletzen würde. Die erreichbare Performance ist sehr gut, da die Geschäftsregeln sehr nahe bei den Daten sind. Außerdem weisen moderne Datenbankmanagementsysteme hoch entwickelte Mechanismen wie Caching oder eine Query-Kompilation mit Optimierung auf.
19 BR-Architektur
Diesen Vorteilen stehen allerdings auch ein paar substantielle Nachteile gegenüber:
Obwohl SQL von Natur aus eine deklarative Sprache ist, hat sie als Regelsprache einen sehr technischen Charakter, der NichtInformatikern kaum zugemutet werden kann. Prozessregeln sind kaum realisierbar, da in den meisten Fällen ein „Call-Back“ aus der Datenbank zurück an die HostApplikation notwendig wäre. Die zurzeit aktiven Geschäftsregeln sind nicht transparent, da sie nur sehr schwer zugänglich sind (lediglich als Meta-Daten der Datenbank). Der Ansatz eignet sich nur für moderne relationale Datenbanken – ältere, typischerweise Host-basierte Datenbanken bieten keine solchen Mechanismen.
Generator-Architektur In der Generator-Architektur (siehe Abb. 19.5) existieren zur Laufzeit einer Applikation keine Geschäftsregeln mehr im eigentlichen Sinne, die Architektur einer einzelnen Applikation ist völlig konventionell41. Die Geschäftsregeln sind aber nach wie vor in einer fachlich orientierten Form formuliert und in einem Repository abgelegt. Applikation Benutzungsschnittstelle Benutzungsschnittstellen-Code
Abb. 19.5 GeneratorArchitektur
Fachlogik Regel-Compiler Applikationslogik-Code
Datenbank-Code
DBMS
Datenbank
Geschäftsregeln
Aus diesem Repository erzeugt dann ein Regel-Compiler konventionellen Programmcode für verschiedene Komponenten einer Applikation, z.B.
41
z.B. eine „Three-Tier“ Architektur mit Datenbank, ApplikationslogikServer und Web-Interface.
19.2 Lösungsansatz: Architektur
237
VBScript Code zur Prüfung von Feld-Inhalten im WebInterface, Java Code, welcher die fachliche Logik implementiert, SQL-Code, welcher Geschäftsregeln mittels Views, Constraints und Stored Procedures implementiert.
Dieser generative statt interpretative Ansatz bietet einige bestechende Vorteile:
Aufgrund der Tatsache, dass in der Generator-Architektur keine Geschäftsregeln zur Laufzeit interpretiert werden, sondern ganz „normaler“ Programmcode zur Ausführung gelangt, kann eine sehr gute Performance erwartet werden. Da die Generierung von Programmcode aus den zentralen Geschäftsregeln automatisch erfolgt, ist die redundante Implementation von Regeln (z.B. auf dem Server und dem Client) kein Problem. Im Gegenteil, dadurch lässt sich sowohl die Performance als auch der Bedienkomfort weiter verbessern. Je nach Art und Leistungsfähigkeit des Regel-Compilers lässt sich Programmcode für alle Arten von Geschäftsregeln erzeugen.
Diesen großen Vorteilen stehen leider aber auch einige gewichtige Nachteile gegenüber:
Jede Änderung der Geschäftsregeln erfordert eine Neugenerierung der Applikation. Damit ist die Anpassungsgeschwindigkeit an neue Bedürfnisse beschränkt und muss unter Umständen gar mit dem normalen IT-Releasezyklus abgestimmt werden. Geschäftsregeln können umgangen bzw. ignoriert werden, da Applikationen auch ohne diese Generator-Architektur gebaut werden können. Die aktiven Geschäftsregeln sind nicht mehr in einer transparenten Form vorhanden, wodurch beispielsweise keine situativen Erklärungen mehr möglich werden. Da substantielle Teile einer Applikation automatisch generiert werden, ist diese Architektur nur schwer in einer bestehenden Umgebung verwendbar. Es existieren erst wenige kommerzielle Produkte auf dem Markt, die auf der Generator-Architektur basieren.
Der oben beschriebene Generator-Ansatz entspricht weitgehend der Model Driven Architecture (MDA, siehe [OMG03]) der Object Management Group (OMG). MDA hat ebenfalls zum Ziel, fachliche und lösungsneutrale Spezifikationen möglichst automatisch in lauffähigen Programmcode zu transformieren.
238
19 BR-Architektur
19.2.2 Anbindung des Faktenmodells Speziell in der Service-Architektur stellt sich die Frage, wie die Business Rule Engine effizient zu den benötigten Fakten gemäß dem Faktenmodel kommt. Dazu bieten sich zwei Möglichkeiten an: die Push-Architektur und die Pull-Architektur.
Push-Architektur Bei der Push-Architektur werden sämtliche benötigten Fakten an die Business Rule Engine transferiert, bevor diese eine Entscheidung treffen kann. Das folgende Beispiel illustriert diesen Vorgang (siehe Abb. 19.6): 1. Eine Verkaufsapplikation soll die Daten eines Kunden anzeigen und liest diese dazu aus der Datenbank. 2. Um zu bestimmen, ob der Kunde präferiert ist, müssen als Fakten seine Bestellungen sowie die bestellten Artikel nachgeladen werden. 3. Nun können sämtliche relevanten Fakten an die Business Rule Engine übermittelt werden. 4. Jetzt erst kann die Business Rule Engine angefragt werden, ob der Kunde präferiert ist. 5. Im letzten Schritt antwortet nun die Business Rule Engine auf die gestellte Frage. Applikation
3
Business Rule Engine
Abb. 19.6 Push-Architektur
P ist ein präferierter Kunde, falls sein Jahresumsatz größer als 2000€ ist
4 Ist Herr Meier ein präferierter Kunde?
5 Ja
1 Kunden
2 Bestellungen
Artikel
Die Übertragung der notwendigen Fakten (Schritt 3) erfolgt heute oft in Form eines XML-Dokuments. Obwohl viele kommerzielle Business Rule Engines diese Variante als Standard-Architektur vorschlagen, weist sie drei gravierende Nachteile auf:
19.2 Lösungsansatz: Architektur
239
Die Aufbereitung und Übertragung der Grundlagen (Schritt 3) kann sehr zeitintensiv sein. Oft benötigt dieser Teil des Vorganges ein Vielfaches der Zeit, welche die Abarbeitung der Geschäftsregeln erfordert. Der Inhalt bzw. der Umfang der Fakten wird durch die aufrufende Applikation bestimmt. Werden die Geschäftsregeln derart erweitert, dass zusätzliche Fakten benötigt werden, müssen sämtliche aufrufenden Applikationen entsprechend angepasst werden. Umgekehrt ist die Datenmenge der Fakten, die an die Business Rule Engine transferiert wird, unabhängig von der jeweiligen Situation. Obwohl die Geschäftsregeln vielleicht nicht immer sämtliche Fakten benötigen, werden sie trotzdem immer vollständig transferiert. Werden die Fakten mittels XML transferiert, so wirkt sich zusätzlich der Overhead von XML negativ auf die Performance aus.
Diese Probleme der Push-Architektur werden zumindest teilweise durch die Pull-Architektur behoben.
Pull-Architektur In der Pull-Architektur wird beim Aufruf der Business Rule Engine nur die zu entscheidende Frage gestellt, aber keine weiteren Fakten übermittelt. Aufgrund der ansprechenden Geschäftsregeln holt sich dann die Business Rule Engine selbständig diejenigen Fakten, die sie für die Entscheidung benötigt. Das folgenden Beispiel (Abb. 19.7) illustriert wiederum diesen Vorgang: 1. Eine Verkaufsapplikation soll die Daten eines Kunden anzeigen und liest diese dazu aus der Datenbank. 2. Nun stellt sie der Business Rule Engine die Frage, ob der Kunde präferiert ist. 3. Um zu bestimmen, ob der Kunde präferiert ist, muss die Business Rule Engine den Jahresumsatz des Kunden wissen. Deswegen muss sie dessen Bestellungen sowie die bestellten Artikel nachladen. 4. Im letzten Schritt liefert die Business Rule Engine der aufrufenden Applikation die Antwort auf die gestellte Frage. Als Variante besteht oft auch die Möglichkeit, dass im Schritt 3 die Business Rule Engine die notwendigen Fakten nicht (nur) aus der Datenbank, sondern via „Call-Back“ direkt aus dem Speicherbereich der aufrufenden Applikation anfordern kann.
240
19 BR-Architektur
Applikation
Business Rule Engine
2
Abb. 19.7 Pull-Architektur
P ist ein präferierter Kunde, falls sein Jahresumsatz größer als 2000€ ist
Ist Herr Meier ein präferierter Kunde?
4 Ja
3 1 Kunden
Bestellungen
Artikel
Die Pull-Architektur eliminiert die in der Push-Architektur genannten Probleme weitgehend. Die Kehrseite der Pull-Architektur ist allerdings, dass die Business Rule Engine ein flexibler „on-demand“ Zugriff auf sämtliche Unternehmensdaten gewährt werden muss. Dies kann einerseits ein Sicherheitsproblem darstellen und andererseits einer technischen Architektur zuwiderlaufen, die beispielsweise die Unternehmensdaten durch eine Service-Schicht kapselt. Zudem erlauben viele kommerziell erhältliche Business Rule Engines einen Pull-Zugriff auf die Grundlagen, falls überhaupt, nur auf relativ umständliche Art und Weise.
19.3 Schritt für Schritt: Entwurf der BRArchitektur Die Gestaltung einer leistungsfähigen IT-Architektur, welche auch die für den Business Rules Ansatz typischen Forderungen nach Flexibilität und Transparenz erfüllt, ist eine zentrale Aufgabe. Dazu zählen folgende Tätigkeiten: 1. Regelverwaltung implementieren Wo die Geschäftsregeln bearbeitet und abgelegt werden ist eine zentrale Frage. Wird eine kommerzielle Business Rule Engine beschafft, so ist meistens eine Komponente enthalten, die diese Funktionen bietet. Allerdings haben solche Rule Management Komponenten einen großen Nachteil: Sie sind typischerweise auf eine einzige Business Rules Engine ausgerichtet (nämlich die Eigene). Sollen aber verschiedene RegelausführungsTechnologien zur Anwendung kommen, so muss nach einer eigenständigen Rule Management Lösung gesucht werden. Dies führt allerdings zu entsprechendem Integrationsaufwand, da die Regeln für verschiedene Technologien zu exportieren sind.
19.3 Schritt für Schritt: Entwurf der BR-Architektur
241
2. Regeltechnologien wählen Hier stellt sich die Frage, mit welchen Technologien die Geschäftsregeln automatisiert werden sollen. Bei der Wahl einer Technologie können folgende Heuristiken hilfreich sein: – Ist die Volatilität der Regelungen hoch, so ist eine interpretative Technologie, wie eine Business Rule Engine oder auch bloß eine Konfigurationstabelle in der Datenbank eine sinnvolle Lösung. – Weisen die Regelungen eine mittlere Volatilität auf, so ist ein generativer Lösungsansatz in Betracht zu ziehen. Dieser kann entweder Programmcode für die Datenbank oder aber auch Teile der Fachlogik generieren. – Ist die Volatilität der Regelungen tief, so macht es wenig Sinn, ausgeklügelte flexible Mechanismen einzusetzen. In solchen Fällen ist die konventionelle Ausprogrammierung die pragmatischste Lösung. 3. Makro-Architektur wählen Unabhängig von der gewählten Regeltechnologie ist auch die Makro-Architektur festzulegen: – Sobald in den zu automatisierenden Regelungen Einschränkungen eine wesentliche Rolle spielen, ist eine Schichtenoder gar Datenbank-Architektur angebracht. Die Datenbank-Architektur bietet insbesondere dann Vorteile, wenn Einschränkungen einer existierenden Applikation „aufgezwungen“ werden müssen. – Spielen Ableitungen eine wesentliche Rolle bei den zu automatisierenden Regelungen, so bietet sich die ServiceArchitektur an. Müssen diese Ableitungen für sehr große Datenmengen (beispielsweise für die Klassifikation von Millionen von Kunden in verschiedene Typen) ausgeführt werden, so ist auch die Datenbank-Architektur wieder eine Überlegung wert. Schließlich muss auch in Betracht gezogen werden, dass Automatisierung verschiedener Arten von Regelungen eine Kombination von Makro-Architekturen notwendig sein kann. 4. Architektur optimieren Kommt die Service-Architektur zum Einsatz, so muss festgelegt werden, wie die Business Rule Engine zu den Fakten kommt. Ist die Datenmenge der von den Regelungen benötigten Fakten gering, so eignet sich die Push-Architektur gut, da sie einfach zu realisieren ist. Ist die benötigte Datenmenge jedoch groß oder gar je nach Aufruf unterschiedlich, muss geklärt werden inwiefern die gewählte Technologie die Pull-Architektur unterstützt.
242
19 BR-Architektur
5. Faktenmodell-Ausschnitte stabilisieren Ein absolut essentieller Schritt, der die Zukunftssicherheit einer technischen Lösung verbessert, ist die kritische Betrachtung der Faktenmodell-Ausschnitte, die von den jeweiligen Regelungen benötigt werden. Diese Betrachtung beinhaltet die Überlegung, welche Fakttypen mit welcher Wahrscheinlichkeit für welche Regelungen in Zukunft relevant werden könnten. Da nachträgliche Änderungen an der technischen Anbindung des Faktenmodells relativ aufwändig sind, macht es Sinn, bereits heute absehbare Erweiterungen frühzeitig zu berücksichtigen. Auf der anderen Seite geht es hier aber auch nicht darum, die FaktenmodellAusschnitte um Faktoren aufzublähen. Dies würde lediglich zu komplexeren Schnittstellen und größerem zu transferierendem Datenvolumen führen, insbesondere dann, wenn eine ServiceArchitektur zur Anwendung kommt.
19.4 Ergebnis: Die BR-Architektur von KnowBeer Als erstes wurde mit dem Integrator „4get-IT“ vereinbart, wer welche Aufgaben im Projekt „FIT/Verkauf“ übernimmt: 4get-IT
Definition der in der Rule Engine
Rule Engine in „myTBQ“
realisierten Regeln in Zusammenar-
Verwendung der neuen SQL-Views in „myTBQ“
KnowBeer
Einbau der Aufrufe an die Business
beit mit den Fachvertretern
Überprüfung der durch den SQL-
Realisation eines Generators, wel-
Generator erzeugten SQL-Views
cher SQL-Views aus den Regeln des
Implementation der Einschränkun-
„RegulationMaster“ erzeugt
gen, welche in der Datenbank imp-
Tabelle 19.1 Aufgabenteilung für die technische Realisation
lementiert sind Gemeinsame Aufgaben:
Entwurf der Gesamtarchitektur
Spezifikation der durch die Regelungen benötigten Faktenmodell-Ausschnitte
Spezifikation der durch die Regelungen benötigten SQL-Views
Abb. 19.8 zeigt die Business Rules Architektur von KnowBeer, wie sie im Rahmen des Projekts „FIT/Verkauf“ in Zusammenarbeit mit dem Integrator „4get-IT“ ausgearbeitet wurde.
19.4 Ergebnis: Die BR-Architektur von KnowBeer
243
Abb. 19.8 KnowBeer BRArchitektur
RuleFX RegelVerwalter
RegulationMaster
RuleFX Rules
RuleFX RB
Entscheidung()
.NET
Entscheidung()
myTBQ - FIT RegulationMaster Repository
myTBQ
Rule Adapter
SQL Generator
Verkäufer
MS SQL Server 2005
SQL Views SQL Scripts
myTBQ DB
SQL Triggers
Die ausgearbeitete BR-Architektur ist eine Kombination aus einer Service-Architektur (Aufruf der Business Rule Engine via .NET), einer Datenbank-Architektur sowie einer Generator-Architektur (zur Generierung der SQL-Codes aus den Geschäftsregeln im RegulationMaster Repository). Aufgrund der für die Regel-Ausführung identifizierten Anforderungen (siehe Kapitel 18.4) und der oben beschriebenen Überlegungen zur BR-Architektur wurde die Business Rule Engine „RuleFX“42 beschafft. Ihre Eigenschaften lassen sich wie folgt zusammenfassen:
Import von Regeln im FOL RuleML Format (Version 0.9) Weitgehende Unterstützung der prädikatenlogische Repräsentation von Regeln Aufruf- und Management-Schnittstelle, die sich an JSR-94 (Stateful- und Stateless-Sessions) orientiert Fakten-Daten müssen via Push-Schnittstelle in XML oder via API an die Engine übertragen werden (kein Direktzugriff auf eine Datenbank möglich)
42
Da wir als Autoren dieses Buches Hersteller-neutral sind und sich der BRT-Markt noch in heftiger Bewegung befindet, handelt es sich bei den durch KnowBeer beschafften Systemen um fiktive Produkte, die (unseres Wissens) so nicht auf dem Markt existieren.
244
19 BR-Architektur
Erklärungen zu Schlüssen können via API abgefragt werden Lauffähig auf der Windows/.NET Plattform Hohe Effizienz (bis 10 Mio. Regeln pro Sekunde) und relativ geringer Ressourcenbedarf (< 10 MByte im RAM) Hat kostengünstige Entwicklungs- und Laufzeitlizenzen
Abb. 19.9 zeigt den minimalen Ausschnitt des Faktenmodells, der für die Regelung „Rabattbestimmung“ benötigt wird:
Kunde
ist bevorzugt
(Bestellung) beinhaltet (Anzahl) von (Artikel) mit Rabatt (Prozent)
Betrag hat Stückpreis Artikel von
gehört zu
beinhaltet
hat Versandkosten
Betrag
Abb. 19.9 Minimales Faktenmodell „Rabattbestimmung“
Anzahl
mit Rabatt hat Bruttopreis Bestellung
Prozent
hat Nettopreis
Vom Fakttyp „Bestellung beinhaltet Anzahl von Artikel mit Rabatt Prozent“ soll lediglich der Teil „Bestellung beinhaltet Anzahl von Artikel“ aus der Datenbank gelesen werden. Der Rabatt soll nicht aus der Datenbank von „myTBQ“ (siehe Abb. 19.10) genommen, sondern durch die Regelung „Rabattbestimmung“ abgeleitet werden. TKunden KNr Name * Typ Ansprechperson Strasse PLZ Ort * Land Telefon Fax Email Kreditlimite Jahresumsatz Zahlungsprobleme Bemerkungen Status
TArtikel
TBestellungen BNr * Kunde Bestelldatum Wunschdatum Express Lieferdatum Bruttopreis Versandkosten Rabatt Nettopreis Bezahlt Bemerkungen Status
ANr * Lieferant Bezeichnung * Typ Einheit Stückpreis Beschreibung Status
Abb. 19.10 DB-Ausschnitt „Rabattbestimmung“
TBestellzeilen * Bestellung * Artikel Menge Rabatt
Das folgende Beispiel zeigt die Fakten zu einer einzelnen Bestellung in XML, wie sie der Business Rule Engine zur Rabattbestimmung übergeben werden:
19.4 Ergebnis: Die BR-Architektur von KnowBeer
245
<policy> Rabattbestimmung <arg1> 283 <arg1> 715 <arg2> 283 <arg1> 715 <arg2> 20 <arg1> 715 <arg2> 850 <arg1> 715 <arg2> 200 <arg3> 1397 <arg4> 2 <arg1> 715 <arg2> 150 <arg3>
246
19 BR-Architektur
1123 <arg4> 0 <arg1> 1397 <arg2> 2.4 <arg1> 1397 <arg2> 2.8
Im Sinne der Zukunftssicherheit des Faktenmodells, wurde diese Minimalversion allerdings etwas ausgebaut (siehe Abb. 19.11). Dadurch lassen sich in Zukunft weitere, auch komplexere Regeln zur Rabattbestimmung realisieren. Dauer ist bevorzugt hat Geschäftsbeziehung seit Betrag «ist Rolle von» Kunde
hat Stückpreis
hat Jahresumsatz
Abb. 19.11 Erweitertes Faktenmodell „Rabattbestimmung“
Artikel
hat Kreditlimite hat Zahlungsprobleme von gehört zu beinhaltet
hat Versandkosten
Betrag
Anzahl
mit Rabatt hat Bruttopreis Bestellung
Prozent
hat Nettopreis hat Destination Organisation
hat Nationalität
(Bestellung) beinhaltet (Anzahl) von (Artikel) mit Rabatt (Prozent)
Land Bar Restaurant
ist vom Typ
Organisationstyp Hotel Privat
19.4 Ergebnis: Die BR-Architektur von KnowBeer
247
19.5 Wie geht es weiter? In diesem Kapitel wurde aufgezeigt, dass es nicht eine einzige „richtige“ Architektur geben kann. Vielmehr müssen verschiedene Faktoren berücksichtigt werden um daraus einen möglichst optimalen Kompromiss zu finden. Sind diese architektonischen Überlegungen einmal angestellt und gegebenenfalls durch eine Machbarkeitsstudie untermauert, kann es an die technische Realisation gehen. Dies ist der Fokus des nächsten Kapitels.
248
19 BR-Architektur
20 Implementation
In diesem Kapitel werden konkrete Implementations- und Programmiertechniken aufgezeigt, die bei der technischen Realisation von Regelungen angewandt werden können.
20.1 Ausgangslage: Eine Schwierigkeit Herbert Acker hat begonnen, die ersten Geschäftsregeln zu implementieren. Bei der Implementation der Regelung „Gratismuster“ in der Datenbank sind allerdings Probleme aufgetreten: H. Acker:
D. Enker: H. Acker:
D. Enker: H. Acker: D. Enker:
H. Acker:
D. Enker:
Du Daniel, ich habe versucht, die Regelung „Gratismuster“ als Trigger in der Datenbank zu implementieren. Dabei ist mir etwas aufgefallen. Was denn? Wir haben zusammen mit Benno Remser definiert, dass beim vereinbarten Liefertermin Gratismuster zu einer Bestellung hinzugefügt werden sollen. Es scheint allerdings ziemlich schwierig zu sein, den vereinbarten Liefertermin in der Datenbank festzustellen und automatisch darauf zu reagieren. Könnten wir diese Regel nicht etwas anpassen, sodass sie einfacher zu implementieren ist? Ach du meine Güte! Kennst du denn die „Goldene Regel“ nicht? Nein, was ist denn das schon wieder? Der mit dem Gold bestimmt die Regeln! Wenn unser Verkauf die Regel so formuliert hat, so wird das schon seine Gründe haben! Aber das würde ja heißen, dass der Verkäufer gar nicht mitbekommt, wenn er seinem Kunden ein Geschenk macht, sondern lediglich der Packer! Hmm, das stimmt. Ich denke, wir müssen das noch einmal zusammen mit Benno Remser klären!
20 Implementation
249
20.2 Lösungsansatz: Implementationstechniken für Geschäftsregeln Die einzelnen Regelungen zu automatisieren heißt, sie dem Rechner „beizubringen“. Dabei sind verschiedene Aspekte der technischen Implementation zu beachten. In diesem Kapitel werden die folgenden Themen genauer beleuchtet: Wie werden die Geschäftsregeln in die reale, durch die gewählte Technologie bereitgestellte, Regelsprache übersetzt? Wie sieht ein typischer Aufruf einer Business Rule Engine aus? Wie sehen Implementationen von Ableitungen, Einschränkungen und Prozessregeln in der Datenbank aus?
20.2.1 Reale Regelsprachen Im Teil II haben wir verschiedene Darstellungsformen von Geschäftsregeln kennen gelernt. Solange man diese Regeln nur dokumentieren will, bestehen keine Restriktionen bezüglich ihrer Darstellung. Sollen sie aber ausgeführt werden, so muss man sich an die Darstellungsformen der gewählten Business Rule Engine halten. Leider hat sich bis heute noch kein einheitlicher Standard etabliert, sodass Geschäftsregeln in der Praxis immer produktspezifisch formuliert werden müssen. Typische Unterschiede produktspezifischer Sprachen sind etwa
verschiedene Varianten von Entscheidungstabellen, wie sie beispielsweise im Anhang dieses Buches zu finden sind die Verwendung englischer statt deutscher Schlüsselwörter (z.B. „If“ statt „Falls“ oder „and“ statt „und“) die Verwendung der „If Then “ Form für Regeln anstelle von „ falls “ die Verwendung produktspezifischer Kriterien in Regelbedingungen die Verwendung produktspezifischer Aktionen in Regelfolgerungen.
Neben diesen Unterschieden kann auch die Art und Weise, wie das Faktenmodell in die Regelsprache eingebunden ist, sehr unterschiedlich sein. Viele kommerzielle Business Rule Engines bieten dazu ein relativ einfaches Modell: Sie erlauben lediglich, ein Implementations-Element (z.B. ein Attribut oder eine Operation einer Klasse) mit einem fachlich(eren) Namen zu bezeichnen. So könnte beispielsweise die Operation „GetName()“ der Klasse „CKunde“ in der Regelsprache „Name des Kunden“ genannt werden.
250
20 Implementation
20.2.2 Aufruf einer Business Rule Engine Wie im Kapitel 19.2.1 beschrieben, wird bei der Service-Architektur die Business Rule Engine aus einer Host-Applikation aufgerufen. Ein solcher Aufruf erfolgt typischerweise in mehreren Schritten: 1. Business Rule Engine instanzieren bzw. Verbindung mit der Business Rule Engine herstellen 2. Gewünschte Regelbasis in die Business Rule Engine laden und gegebenenfalls aktivieren 3. Aktuelle Fakten in die Business Rule Engine transferieren (push) 4. Business Rule Engine aufrufen, wodurch die Regeln ausgeführt werden 5. Gewünschtes Ergebnis aus der Business Rule Engine lesen. Schritte 1 und 2 sind vorbereitende Aktionen, wogegen die Schritte 3 bis 5 für jeden Aufruf wiederholt werden. In Kapitel 20.4.1 ist ein konkretes Beispiel dieser Schritte zu finden.
20.2.3 Implementation von Ableitungen in der Datenbank Auf der Ebene einer relationalen Datenbank sind Fakttypen nichts anderes als Tabellen, die ausschließlich aus Fremdschlüsseln oder Werttypen bestehen (siehe Kapitel 10.2). So könnte beispielsweise der Fakttyp „Kunde wohnt in Land“ durch eine Tabelle mit den zwei Fremdschlüsseln „KNr“ und „LNr“ dargestellt werden. Tabelle 20.1 illustriert weitere Beispiele von Darstellungen von binären, unären und sogar höherwertigen Fakttypen als Tabellen. Fakttyp Kunde wohnt in Land
Tabelle wohnt_in(KNr: Key, LNr: Key)
Bestellung hat Preis Betrag
hat_Rabatt(BNr: Key, Zahl: Number)
Bestellung ist express
ist_express(BNr: Key)
Bestellung beinhaltet Anzahl
beinhaltet_von(BNr: Key, Anzahl: Num-
von Artikel
ber, ANr: Key)
Tabelle 20.1 Fakttypen als Tabellen
Seitenblick: Diese Implementation basiert auf der Closed World Semantik (siehe auch Kapitel 13.2.4): Ist beispielsweise eine Bestellung in der Tabelle „ist_express“ enthalten, so wird sie als Expressbestellung betrachtet; ist sie nicht darin enthalten, als normale Bestellung. Wäre die Open World Semantik verlangt, so müsste die Tabelle durch eine „Wahrheitskolonne“ erweitert werden: ist_express(BNr: Key, Wahr: Boolean)
20.2 Lösungsansatz: Implementationstechniken für Geschäftsregeln
251
Interessant wird die Sache dann, wenn diese Tabellen nicht physische Tabellen, sondern abgeleitete Views auf physische Tabellen sind. So kann beispielsweise der abgeleitete Fakttyp „Bestellung hat Nettopreis Betrag“ durch die folgende SQL-View implementiert werden: CREATE VIEW hat_Nettopreis AS SELECT BNr, (Preis - Rabatt) AS Betrag FROM Bestellungen;
Diese View leitet den Nettopreis einer Bestellung durch eine einfache Berechnung aus deren Preis und Rabatt ab. Nun könnte für jeden abgeleiteten Fakttyp, der die Bestellung als Subjekt hat, eine eigene View definiert werden. Für Fakttypen, die Aussagen über zwei oder mehr Objekttypen machen, ist dies auch zwingend notwendig. Binäre Fakttypen, die eine Wertaussage über einen Objekttypen machen (z.B. „Bestellung hat Preis Betrag“), können aber zu einer einzigen Tabelle (oder View) zusammengefasst werden. Hierbei werden die abgeleiteten Kolonnen nach den jeweiligen Fakttypen benannt: CREATE VIEW Bestellungsableitungen AS SELECT BNr, (Preis - Rabatt) AS hat_Nettopreis, (Rabatt / Preis * 100) AS hat_Discount FROM Bestellungen;
Komplexere Ableitungen, die auf Grundlagen aus anderen Tabellen basieren, lassen sich mit entsprechenden Subqueries realisieren. Beispiele dazu sind in Kapitel 20.4 zu finden. Die aus der Perspektive des Business Rules Ansatzes wichtige Forderung nach Flexibilität wird von SQL-Views erfüllt: Views können auch im laufenden Betrieb einer Datenbank hinzugefügt oder verändert werden ohne die Applikationen, die auf der Datenbank basieren, zu beeinträchtigen.
20.2.4 Implementation von Einschränkungen in der Datenbank Für die Implementation von Einschränkungen ist eine Datenbank der ideale Ort, da kein Weg zu den Daten am Datenbank Managementsystem vorbei führt. Daher sind in der Datenbank implementierte Einschränkungen prädestinierte Mittel, um Geschäftsregeln zur Wahrung der Datenqualität zu realisieren. Eine moderne relationale Datenbank bietet verschiedene Mechanismen, um Einschränkungen zu automatisieren:
252
20 Implementation
Table Constraints ermöglichen die Implementation von einfachen Einschränkungen. Die Implementation von Triggern erlaubt die Prüfung von komplexen Einschränkungen, die mehr als eine Tabelle betreffen. Durch Stored Procedures können zudem Einschränkungen zentral an einer Stelle formuliert und durch verschiedene Trigger aufgerufen werden.
Das folgende Beispiel illustriert die Implementation zweier Einschränkungen durch Table Constraints: ALTER TABLE Bestellungen ADD CONSTRAINT gueltiger_Status CHECK (bezahlt OR Status <> 'geliefert'), ADD CONSTRAINT gueltiger_Preis CHECK (Nettopreis =< Bruttopreis);
Leider sind in SQL die durch Constraints geprüften Bedingungen auf eine einzige Tabelle beschränkt. Umfasst eine Einschränkung Fakten aus mehr als einer Tabelle, muss daher auf den TriggerMechanismus der Datenbank zurückgegriffen werden. Dazu muss für jede betroffene Tabelle ein Trigger erstellt werden, der die folgende Struktur aufweist: CREATE TRIGGER ON FOR INSERT, UPDATE, DELETE AS IF NOT (<Einschränkung>) THEN BEGIN RAISERROR ROLLBACK TRANSACTION END
Diese Lösung weist aber noch einen kleinen Schönheitsfehler auf: Dieselbe <Einschränkung> muss in jeden Trigger unverändert kopiert werden, was eine Redundanz darstellt. Dieser Mangel lässt sich durch die Auslagerung der <Einschränkung> in eine View oder eine Stored Procedure beheben.
20.2.5 Implementation von Prozessregeln in der Datenbank Werden Prozessregeln in der Datenbank implementiert, so lässt sich dies ähnlich wie bei Einschränkungen durch Trigger realisieren. Der einzige Unterschied dabei ist, dass nicht die Transaktion zurückgewiesen, sondern eine beliebige Aktion ausgelöst werden muss. Dabei ist zu berücksichtigen, welche Arten von Aktionen sich aus der Datenbank auslösen lassen. Das folgende Beispiel zeigt einen Trigger im SQL Server 2005, der ein E-Mail auslöst:
20.2 Lösungsansatz: Implementationstechniken für Geschäftsregeln
253
CREATE TRIGGER Lieferung ON Bestellungen FOR UPDATE AS IF (SELECT Lieferdatum IS NULL FROM DELETED) AND UPDATE(Lieferdatum) THEN BEGIN EXEC master..xp_sendmail 'T.Reiber', 'Bestellung wurde ausgeliefert!';
20.3 Schritt für Schritt: Implementation der Regelungen Die Implementation der Regelungen ist ein relativ mechanischer Prozess: Jede einzelne zu automatisierenden Geschäftsregel muss in eine lauffähige Form übersetzt werden. Im Gegensatz zur konventionellen Applikationsentwicklung ist diese Phase beim Business Rules Ansatz jedoch nie zu Ende, da davon ausgegangen wird, dass Geschäftsregeln sowieso immer ändern. Die Implementation der Regelungen ist somit ein Prozess, der parallel zum operationellen Betrieb stattfindet und folgende Schritte umfasst: 1. Geschäftsregeln mit Fachseite formulieren Geschäftsregeln sollen ja so weit wie möglich durch Vertreter der Fachseite formuliert werden. Wie dieses Kapitel gezeigt hat, ist die Darstellung der Geschäftsregeln in einem gewissen Maß abhängig von der gewählten Technologie. Daher ist es sinnvoll, die Verantwortlichen der Regelungen zumindest am Anfang bei der Formulierung der Regelungen zu begleiten. 2. Geschäftsregeln durch IT programmieren Diejenigen Regelungen, welche aufgrund der gewählten Umsetzung eine eher technische Darstellungsform aufweisen (z.B. Regeln in der Datenbank) sollen auch durch Leute aus der IT implementiert werden. Die Ausgangsform auch für diese Regelungen soll aber trotzdem eine für die Fachvertreter verständliche Darstellung sein. Diese dient dann als Spezifikation für die Ausprogrammierung der Regel. Falls die so zu übersetzenden Geschäftsregeln immer von gleichartiger Struktur sind, kann es sich eventuell sogar lohnen, diesen Transformationsprozess zu automatisieren. Dies ist dann ganz im Sinne der Model Driven Architecture, wie sie beispielsweise bei KnowBeer durch den SQL Generator realisiert wurde (siehe Kapitel 19.4). 3. Geschäftsregeln testen Wie bei jeder automatisierten Funktionalität üblich, soll die Funktionalität getestet werden, bevor sie produktiv gesetzt wird. Im Bezug auf den Business Rules Ansatz heißt dies, dass die implementierten Regelungen unbedingt durch die Fachvertreter
254
20 Implementation
validiert und abgenommen werden müssen. Dies gilt unabhängig davon, ob sie durch die Fachseite oder die IT realisiert wurden und soll auch nach Abschluss des IT-Projektes bei jeder Regeländerung zur Gewohnheit werden. 4. Rule Management Prozess testen Mit der Implementation der ersten Regelungen bietet sich auch gleich eine ideale Gelegenheit, den Rule Management Prozess erstmals durchzuspielen.
20.4 Ergebnis: Implementation von Regelungen bei KnowBeer Im Folgenden ist aufgezeigt, wie Daniel Enker zusammen mit Herbert Acker und dem Integrator „4get-IT“ die verschiedenen Regelungen automatisiert haben. Ein wichtiger Grundsatz dabei war, dass die bestehende Applikation „myTBQ“ so wenig wie möglich verändert werden sollte. Seitenblick: Die unten beschriebenen Implementationen sind mit Absicht sehr unterschiedlich gestaltet. Dies erfolgte aus didaktischen Gründen, damit sich sowohl unterschiedliche Lösungsansätze als auch verschiedene technische Aspekte der Implementation illustrieren lassen. In der Praxis ist natürlich eine möglichst homogene Implementation anzustreben, auch wenn dies nicht immer machbar ist. In den folgenden Kapiteln werden verschiedene Aspekte der technischen Implementation von Regelungen illustriert. Zum besseren Verständnis sei hier deshalb eine kurze Übersicht gegeben: Kapitel 20.4.1 Regelung „Versandkosten“: Umsetzung einer Entscheidungstabelle in die technische Regelsprache einer Business Rule Engine sowie Aufruf der Business Rule Engine als Service. Kapitel 20.4.2 Regelung „Stückpreis“: Erweiterung einer bestehenden relationalen Datenbank um fehlende deklarierte Fakttypen sowie die Abbildung des benötigten Faktenmodells auf die Datenbank. Kapitel 20.4.3 Regelung „Bevorzugter Kunde“: Umsetzung der fachlichen Regelsprache in SQL sowie Implementation einer komplexen Ableitung als SQL-View. Kapitel 20.4.4 Regelung „Rabattbestimmung“: Umsetzung der fachlichen Regelsprache in die technische Regelsprache einer Business Rule Engine sowie Implementation einer berechtigungsabhängigen Einschränkung mittels Business Rule Engine.
20.4 Ergebnis: Implementation von Regelungen bei KnowBeer
255
Kapitel 20.4.5 Regelung „Gratismuster“: Implementation einer Prozessregel durch einen Datenbank-Trigger, deren Abschwächung in Form einer ausprogrammierten Lösung mit Aufruf der Business Rule Engine sowie Implementation eines binären Fakttyps als SQL-View. Kapitel 20.4.6 Regelung „Kreditlimite“: Darstellung von Ableitungsregeln in einem Werkzeug zur Erarbeitung von Entscheidungstabellen sowie Umsetzung einer komplexen Einschränkung in der Datenbank.
20.4.1 Regelung „Versandkosten“ Die Implementation der Entscheidungstabelle der Regelung „Versandkosten“ erfolgt durch die Transformation in die Regelsprache von „RuleFX“, die über den syntaxgesteuerten Editor des „RegulationMaster“ erfasst wird. Es zeigt sich, dass die Mächtigkeit dieser Regelsprache eine Reduktion der Zahl von Regeln von ursprünglich 12 in der Entscheidungstabelle auf lediglich fünf Regeln erlaubt43: Rule r1: If not $Bestellung ist_express and $Bestellung hat_Destination $Land and $Bestellung hat_Produktpreis $PP and $PP >= 100 and $PP =< 300 and ($Land = "Schweiz" or $Land ist_EU_Mitglied) Then $Bestellung hat_Versandkosten 0. Rule r2: If not $Bestellung ist_express and $Bestellung hat_Destination $Land and $Bestellung hat_Produktpreis $PP and ( ($PP < 100 or $PP > 300 ) and ($Land = "Schweiz" or $Land ist_EU_Mitglied) or $PP >= 100 and $PP =< 300 and not ($Land = "Schweiz" or $Land ist_EU_Mitglied) ) Then $Bestellung hat_Versandkosten 5.
43
Der Fakttyp „Land ist EU-Mitglied“ wird in Kapitel 20.4.2 eingeführt.
256
20 Implementation
Rule r3: If $Bestellung hat_Destination $Land and $Bestellung hat_Produktpreis $PP and ( $PP > 300 and not ($Land = "Schweiz" or $Land ist_EU_Mitglied) and not $Bestellung ist_express or $PP >= 100 and $PP =< 300 and ($Land = "Schweiz" or $Land ist_EU_Mitglied) and $Bestellung ist_express or $PP < 100 and ( ($Land = "Schweiz" or $Land ist_EU_Mitglied) and $Bestellung ist_express or not ($Land = "Schweiz" or $Land ist_EU_Mitglied) and not $Bestellung ist_express ) ) Then $Bestellung hat_Versandkosten 10. Rule r4: If $Bestellung ist_express and $Bestellung hat_Destination $Land and $Bestellung hat_Produktpreis $PP and ( $PP > 300 and ($Land = "Schweiz" or $Land ist_EU_Mitglied) or $PP =< 300 and not ($Land = "Schweiz" or $Land ist_EU_Mitglied) ) Then $Bestellung hat_Versandkosten 20. Rule r5: If $Bestellung ist_express and $Bestellung hat_Produktpreis $PP and $PP > 300 and $Bestellung hat_Destination $Land and not ($Land = "Schweiz" or $Land ist_EU_Mitglied) Then $Bestellung hat_Versandkosten 50. Rule r6: If sum_of $AP in ( $Bestellung beinhaltet $N von $Artikel mit_Rabatt $R and $Artikel ist_Produkt and $Artikel hat_Stueckpreis $SP and $AP is $N * $SP * (100 - $R) / 100 ) is $PP Then $Bestellung hat_Produktpreis $PP.
Die Regelung „Versandkosten“ wurde durch einen Aufruf der Rule Engine aus dem Rule-Adapter automatisiert. Der folgende Aus-
20.4 Ergebnis: Implementation von Regelungen bei KnowBeer
257
schnitt aus dem Rule-Adapter Code zeigt, in welchen Schritten dies in Visual Basic realisiert wurde: ... 'Verschiedene Variabeln deklarieren Dim Engine As RuleFXEngine Dim FactSet As RuleFXFactSet Dim Facts As RuleFXFacts Dim Connection As SQLConnection Dim Versandkosten AS Double ... 'Instanz der Rule Engine kreieren und mit Repository 'verbinden Engine = new _ RuleFXEngine("S:\RuleFX\Repositories\KnowBeer.REP") ... 'Regelung "Versandkosten" in Rule Engine aktivieren Engine.ActivateRuleSet("Versandkosten V1.2") 'Fakten aus DB laden und in Faktenset ablegen FactSet = New RuleFXFactSet FactSet.AddFromDB( _ "SELECT hat_Produktpreis, ist_express, " _ "hat_Destination FROM VVersandkosten " _ " WHERE BNr = " & BNr, Connection) 'Fakten in Rule Engine pushen Engine.LoadFactSet(FactSet) ' Rule Engine aufrufen und Ergebnis lesen Engine.ExecuteRules Versandkosten = FactSet.GetArgs( _ "Bestellung hat_Versandkosten Betrag", 1, 2) ...
Der „GetArgs“-Aufruf auf der letzten Zeile oben liefert vom ersten (und einzigen) Faktum des durch die Business Rule Engine abgeleiteten Fakttyps „Bestellung hat Versandkosten Betrag“ das zweite Argument. Dabei handelt sich um nichts anderes als die gesuchten Versandkosten.
20.4.2 Regelung „Stückpreis“ Bei der Realisation der Regelung „Stückpreis“ zeigt sich, dass nicht alle durch die Regelung benötigten Fakten vorhanden sind. Folgende Fakttypen wurden ursprünglich als Grundlage für die Bestimmung des Stückpreises festgelegt:
258
Artikel hat Einstandspreis Betrag Artikel hat Herkunftsland Land Artikel ist Standardartikel Land ist EU–Mitglied
20 Implementation
Beispielsweise ist in der Datenbank von „myTBQ“ (siehe Abb. 19.1) lediglich der offizielle Stückpreis eines Artikels abgelegt, nicht jedoch sein Einstandspreis. Außerdem stellt sich die fachliche Frage, was mit „Herkunftsland“ genau gemeint ist: In „myTBQ“ ist lediglich das Standortland des Lieferanten eines Artikels in der Datenbank abgelegt. Importiert er aber selber ein Bier aus einem anderen Land, so kann das ursprüngliche Herkunftsland des Artikel unterschiedlich zum Standortland des Lieferanten sein. Nach Abklärungen mit dem Einkauf stellte sich heraus, dass tatsächlich das ursprüngliche Herkunftsland des Artikel und nicht das Standortland des Lieferanten zu berücksichtigen sei. Die Klärung der Bedeutung des Begriffs „Standardartikel“ ergab, dass damit der Wert „normal“ im Datenbankfeld „Status“ gemeint ist, diese Information also vorliegt. Tipp:
Bei der Abbildung des „gewünschten“ Faktenmodells auf real existierende Applikationen ist die Überprüfung der Semantik der vorhandenen Informationen durchaus üblich und sinnvoll. Dazu müssen oft Leute von der betroffenen Fachseite beigezogen werden, um die notwendige Klärung zu schaffen.
Schließlich ist in der „myTBQ“-Datenbank nicht festgelegt, ob ein Land zur EU gehört oder nicht. Somit ist also lediglich eine der geforderten vier Grundlagen aus „myTBQ“ verfügbar. Aus diesem Grund wurde beschlossen, dass die „myTBQ“-Datenbank wie folgt erweitert wird:
Die Tabelle „TArtikel“ wird um die Kolonnen „Einstandspreis“ und „Herkunftsland“ (als Fremdschlüssel zur Tabelle „TLänder“) erweitert. Die Tabelle „TLänder“ wird um die Kolonne „EU-Mitglied“ erweitert.
Somit lässt sich das Faktenmodell für die Regelung „Stückpreis“ wie folgt auf die erweiterte Datenbank von „myTBQ“ abbilden: Fakttyp
Datenbank
Bemerkungen
Artikel hat Stückpreis Betrag
TArtikel.Stückpreis
bestehend
Artikel hat Einstandspreis Betrag
TArtikel.Einstandspreis
neu
Artikel hat Herkunftsland Land
TArtikel.Herkunftsland
neu
Artikel ist Standardartikel
TArtikel.Status = „normal“
bestehend
Land ist EU–Mitglied
TLänder.EU-Mitglied
neu
Tabelle 20.2 FaktenmodellAbbildung „Stückpreis“
Selbstverständlich müssen nun die neuen Kolonnen erst abgefüllt werden, bevor die Regelung „Stückpreis“ in Kraft gesetzt werden
20.4 Ergebnis: Implementation von Regelungen bei KnowBeer
259
kann. Die Regelung selber wird durch ein kleines, eigenständiges Programm realisiert, welches nur dem für die Regelung verantwortlichen Einkauf zur Verfügung steht. Dieses Programm liest für jeden Artikel die notwendigen Fakten aus der Datenbank, wendet darauf durch Aufruf der Business Rule Engine die Regelung „Stückpreis“ an und speichert den abgeleiteten Stückpreis wieder zurück in die Datenbank.
20.4.3 Regelung „Bevorzugter Kunde“ Die Implementation der Regeln r1 und r2 der Regelung „Bevorzugter Kunde“ erfolgt mittels einfacher SQL-View: CREATE VIEW VKunden AS SELECT TKunden.*, /* Regel r1 aus "Bevorzugter Kunde" */ (Jahresumsatz > 500000 AND Geschäftsbeziehung > 24 AND Zahlungsprobleme = 0) AS bevorzugt, /* Regel r2 aus "Bevorzugter Kunde" */ (SELECT max((now() - Lieferdatum) / 30) FROM TBestellungen WHERE Kunde = KNr) AS Geschäftsbeziehung, FROM TKunden;
Diese zwei abgeleiteten Kolonnen können selbstverständlich mit den abgeleiteten Kolonnen aus der View zur Überwachung der Kreditlimite (siehe Kapitel 20.4.6) kombiniert werden.
20.4.4 Regelung „Rabattbestimmung“ Die Implementation der Regeln r1 bis r6 der Regelung „Rabattbestimmung“ erfolgt direkt in der Regelsprache von „RuleFX“. Dabei ist zu beachten, dass die Regelsprache von „RuleFX“ leider die eher technisch orientierte englische Syntax If Then anstelle der ursprünglichen fachorientierten Syntax falls verwendet. Dies ist eine Konzession an die verwendete Regeltechnologie, die aus pragmatischen Gründen eingegangen werden muss.
260
20 Implementation
Rule r1: If $Bestellung hat_Bruttopreis $BP and $Bestellung hat_Nettopreis $NP and $Rabatt is ($BP - $NP) / $BP * 100 Then $Bestellung hat_Rabatt $Rabatt. Rule r2: If $Bestellung hat_Bruttopreis $BP and $Bestellung hat_Versandkosten $VK and $Min is $BP * 0.90 + $VK and $Max is $BP * 0.95 + $VK and ( $Bestellung ist_vielfaeltig or $BP > 500 and $Bestellung gehoert_zu $Kunde and $Kunde ist_bevorzugt) Then $Bestellung hat_Nettopreis_zwischen $Min und $Max. Rule r3: If $Bestellung hat_Bruttopreis $BP and $Bestellung hat_Versandkosten $VK and $Min is $BP * 0.93 + $VK and $Max is $BP * 0.97 + $VK and not $Bestellung ist_vielfaeltig and $BP =< 500 and $Bestellung gehoert_zu $Kunde and $Kunde ist_bevorzugt Then $Bestellung hat_Nettopreis_zwischen $Min und $Max. Rule r4: If $Bestellung hat_Bruttopreis $BP and $Bestellung hat_Versandkosten $VK and $Min is $BP * 0.95 + $VK and $Max is $BP + $VK and not $Bestellung ist_vielfaeltig and $Bestellung gehoert_zu $Kunde and not $Kunde ist_bevorzugt Then $Bestellung hat_Nettopreis_zwischen $Min und $Max. Rule r5: If sum_of $AP in ( $Bestellung beinhaltet $N von $Artikel mit_Rabatt $R and $Artikel hat_Stueckpreis $SP and $AP is $N * $SP * (100 - $R) / 100 ) is $BP Then $Bestellung hat_Bruttopreis $BP. Rule r6: If set_of $Artikel in $Bestellung beinhaltet $N von $Artikel mit_Rabatt $R is $alle_Artikel and cardinality_of $alle_Artikel is $C and $C > 10 Then $Bestellung ist_vielfaeltig.
20.4 Ergebnis: Implementation von Regelungen bei KnowBeer
261
Was nun noch fehlt ist die Bestimmung des Rabatts eines einzelnen Artikels in einer Bestellung, d.h. der Fakttyp „Bestellung beinhaltet Anzahl von Artikel mit Rabatt R“. Dazu kann die bestehende Tabelle „TRabatt“ in „myTBQ“-Datenbank verwendet werden, für die „myTBQ“ auch bereits eine Benutzungsschnittstelle zur Bewirtschaft zur Verfügung stellt. Mit anderen Worten: „myTBQ“ unterstützt bereits die durch die Lookup-Tabelle geforderte Flexibilität! Für die Regelung „Rabattbestimmung“ wurde von fachlicher Seite die Durchsetzung „Qualifizierte Verletzung“ festgelegt. Dies heißt, dass nur Mitarbeiter und Mitarbeiterinnen die Regelung verletzen dürfen, die dazu berechtigt sind. Da die gewählte Business Rule Engine keine einfache Identifikation des aktuellen Benutzers erlaubt, wurde beschlossen, diese Aufgabe programmtechnisch im Rule-Adapter zu lösen. Durch den Aufruf von „Bestellung hat Nettopreis zwischen Min und Max“ kann die erlaubte Bandbreite des Nettopreises einer Bestellung von der Business Rule Engine abgefragt werden. Diese Bandbreite kann dann in der aufrufenden Applikation mit dem tatsächlichen, durch den Verkäufer festgelegten Nettopreis verglichen werden. Liegt der tatsächliche Nettopreis außerhalb der gültigen Grenzen, so kann die aufrufende Applikation beispielsweise den Abschluss der Transaktion verhindern oder ein E-Mail an den Vorgesetzten des Verkäufers absenden.
20.4.5 Regelung „Gratismuster“
Die Automatisierung dieser Regelung als ECA-Prozessregel44 in Form eines Datenbank-Triggers erwies sich zwar als möglich, aber relativ schwerfällig: CREATE TRIGGER TGratisregel ON TBestellungen FOR UPDATE AS /* EVENT */ IF (SELECT Lieferdatum IS NULL FROM DELETED) AND UPDATE(Lieferdatum) THEN BEGIN /* CONDITION */ DECLARE @ANr_Empfehlung int, @BNr_aktuell int, @KNr_aktuell int SELECT @BNr_aktuell = BNr, @KNr_aktuell = KNr FROM INSERTED
44
262
Event/Condition/Action-Regel
20 Implementation
SELECT TOP(1) @ANr_Empfehlung = ANr FROM TArtikel WHERE Typ = 1 AND NOT EXISTS (SELECT * FROM TBestellungen, TBestellzeilen WHERE BNr = Bestellung AND ANr = Artikel AND Kunde = @KNr_aktuell) /* ACTION */ IF NOT @ANr_Empfehlung IS NULL THEN BEGIN /* Gratismuster hinzufügen */ INSERT (@BNr_aktuell, @ANr_Empfehlung, 2, 100) INTO TBestellzeilen END END
Einerseits war trotz der deklarativen Aspekte von SQL relativ viel traditionelle, prozedurale Programmierung notwendig. Andererseits ist das Ereignis „vereinbarter Liefertermin“ auch von fachlicher Seite problematisch: Bis zu diesem Zeitpunkt weiß weder der Verkäufer noch der Kunde von den kostenlos offerierten Produkten. Nach Rücksprache mit Benno Remser wurde daher diese Regelung lediglich als Ableitung in der Business Rule Engine realisiert. Diese kann dann bereits bei der Erstellung einer neuen Bestellung aufgerufen werden, um ein Gratismuster vorzuschlagen. Da für die Bestimmung des noch nie bestellten Artikels ein Datenbankzugriff mit potentiell hohen Datenmengen notwendig ist, wurde diese Funktion allerdings als abgeleiteter binärer Fakttyp „Kunde hat noch nicht Artikel“ in der Datenbank realisiert: CREATE VIEW VKunde_hat_noch_nicht_Artikel AS /* Ableitung von Regel r1 aus "Gratismuster" */ SELECT KNr, ANr AS Empfehlung FROM TKunden, TArtikel WHERE TArtikel.Typ = 1 AND NOT EXISTS (SELECT * FROM TBestellungen, TBestellzeilen WHERE BNr = Bestellung AND ANr = Artikel AND Kunde = KNr);
Dieser neue Fakttyp kann dann der Business Rule Engine wie ein deklarierter Fakttyp zur Verfügung gestellt werden, um gegebenenfalls (in Zukunft) weitere Ableitungen vorzunehmen.
20.4.6 Regelung „Kreditlimite“ Die Regelung „Kreditlimite“ bestimmt die aktuelle Kreditlimite eines Kunden (als Ableitung) und garantiert, dass diese Kreditlimite unter keinen Umständen überschritten wird (eine Einschränkung). Ihre Implementation erfolgt in folgenden drei Schritten:
20.4 Ergebnis: Implementation von Regelungen bei KnowBeer
263
1. Implementation eines Rulesets zur Bestimmung der Kreditlimite und Speicherung dieser in der Kolonne „Kreditlimite“ der Kunden-Tabelle. 2. Realisation einer auf der Kunden-Tabelle basierenden Datenbank-View: Diese bestimmt einerseits die Summe der zurzeit offenen Beträge des Kunden und testet andererseits, ob diese Summe die aktuelle Kreditlimite überschreitet. 3. Realisation von Triggern, die bei Änderungen über die oben beschriebene View prüfen, ob die Kreditlimite überschritten ist, und dann gegebenenfalls ein Rollback der laufenden Transaktion auslösen. Da sich für die Formulierung der Geschäftsregeln zur Bestimmung der Kreditlimite eine Entscheidungstabelle bewährt hat, wurde diese Regelung auch als Entscheidungstabelle im „RegulationMaster“ erfasst (siehe Abb. 20.1). Allerdings verwendet „RegulationMaster“ eine geringfügig andere Darstellung, als sie ursprünglich im Rahmen des Projektes „BEGIN“ zum Einsatz kam. Abb. 20.1: Entscheidungstabelle „Kreditlimite“ im „Regulation Master“
Da der „RegulationMaster“ Entscheidungstabellen im RuleMLFormat exportieren und die Business Rule Engine „RuleFX“ dieses Format direkt importieren kann, ist dieser Teil der Regelung damit schon erledigt. Etwas schwieriger wird die Implementation der Einschränkung, welche die Einhaltung der Kreditlimite garantiert. Die folgende View realisiert die dazu notwendigen Ableitungen „Offen“ und „OK“: CREATE VIEW VKreditlimite AS SELECT KNr, /* Ableitung von Regel r1 aus "Kreditlimite" */ (SELECT sum(Nettopreis) FROM TBestellungen WHERE Kunde = KNr And Lieferdatum Is NULL) AS Offen, Offen < Kreditlimite AS OK FROM TKunden;
264
20 Implementation
Da SQL keine Constraints auf Views zulässt, muss diese Einschränkung auf eine andere Weise realisiert werden45. Sobald „OK“ falsch wird, d.h. die Kreditlimite überschritten wird, muss ein Rollback der laufenden Transaktion ausgelöst werden. Nun stellt sich allerdings die Frage, wann genau diese Bedingung überprüft werden soll. Einfach gesagt: Immer dann, wenn die Gefahr besteht, dass die Kreditlimite überschritten werden könnte. In unserem Fall gibt es genau zwei Möglichkeiten: Entweder die Summe der offenen Bestellungen eines Kunden vergrößert sich aufgrund einer neuen oder geänderten Bestellung oder die Kreditlimite für einen Kunden wird herabgesetzt.
Diese beiden Situationen lassen sich durch je einen Trigger feststellen, die auf die Kunden-Tabelle bzw. die Bestellungs-Tabelle gesetzt werden. Beide prüfen den Wert von „OK“ und lösen gegebenenfalls ein Rollback aus, falls dieses falsch ist: CREATE TRIGGER TKreditlimitteK ON TKunden FOR UPDATE AS DECLARE @KNr_aktuell int IF UPDATE(Kreditlimitte) THEN BEGIN SELECT @KNr_aktuell = KNr FROM INSERTED IF NOT (SELECT OK FROM VKreditlimitte WHERE KNr = @KNr_aktuell) THEN BEGIN RAISERROR (50001, 16, 1, 'r1') ROLLBACK TRANSACTION END END
45
SQL Server 2005 und andere DBMS bieten zwar die Möglichkeit, berechnete Kolonnen in einer physischen Tabelle zu definieren und durch eine Table Constraint überwacht zu lassen. Dies ist aber einerseits auf einfache Ableitungen aus derselben Tabelle beschränkt. Andererseits ist diese Funktionalität nicht Standard SQL und wird beispielsweise von Oracle 10g nicht unterstützt. Aus diesem Grund zeigen wir hier einen zwar etwas umständlicheren, aber allgemeingültigeren Weg.
20.4 Ergebnis: Implementation von Regelungen bei KnowBeer
265
CREATE TRIGGER TKreditlimitteB ON TBestellungen FOR UPDATE AS DECLARE @KNr_aktuell int IF UPDATE(Nettopreis) THEN BEGIN SELECT @KNr_aktuell = KNr FROM INSERTED IF NOT (SELECT OK FROM VKreditlimitte WHERE KNr = @KNr_aktuell) THEN BEGIN RAISERROR ('Kreditlimitte überschritten!', 16, 1) ROLLBACK TRANSACTION END
Als Alternative hätte die Überprüfung der Kreditlimite auch gleich in den beiden Triggern erfolgen können. In diesem einfachen Fall würde dies sogar zu weniger und effizienterem Code führen. Allerdings wäre dann die eigentliche Geschäftsregel (die Einschränkung) redundant implementiert, was zu einem erhöhten Wartungsaufwand führen würde.
20.5 Wie geht es weiter? In diesem Kapitel wurde aufgezeigt, wie sich Regelungen auf verschiedene Arten automatisieren lassen:
Durch die Verwendung einer Business Rule Engine lassen sich hauptsächlich Ableitungen und Prozessregeln sehr flexibel (d.h. einfach änderbar) und verständlich automatisieren. Mittels Views, Triggern und Stored Procedures lassen sich nicht nur Ableitungen, sondern auch Einschränkungen an eine relationale Datenbank delegieren. Dabei leidet zwar die Verständlichkeit der Regeln, aber deren Änderbarkeit reduziert sich nur geringfügig. Erfordert eine Regelung weder eine besondere Verständlichkeit noch eine rasche Änderbarkeit, so kann sie auch konventionell ausprogrammiert werden. Dies hat vor allem den Vorteil, dass dadurch eine sehr performante Implementation entsteht.
Nun sind wir an einem Punkt angelangt, an dem mit einigem Aufwand aus der Unternehmensvision Strategien und Taktiken erarbeitet und diese als Direktiven in IT-Systemen automatisiert wurden. Ein Vorteil dieses Ansatzes ist die durchgängige Motivationskette vom Code zurück bis zur Unternehmensvision. Ein anderes Versprechen ist aber noch nicht eingelöst: Wie wird durch diesen Ansatz die Agilität eines Unternehmens erhöht? Dies ist Gegenstand des nächsten und letzten Kapitels dieses Buches.
266
20 Implementation
21 Erntezeit
In diesem Kapitel wird aufgezeigt, wie sich die initialen Aufwände für den Business Rules Ansatz auszahlen. Bestehende Regelungen können nun einfach und rasch neuen Situationen angepasst werden. Außerdem können neue Bereiche vom erarbeiteten Unternehmenswissen profitieren und auf der bestehenden technischen Infrastruktur aufbauen.
21.1 Ausgangslage: Zwei Jahre später... Das Projekt „FIT/Verkauf“ wurde vor gut einem Jahr erfolgreich abgeschlossen und danach die analogen Projekte „FIT/Einkauf“ und „FIT/Buchhaltung“ in Angriff genommen. Die Regelung „Rabattbestimmung“ hat sich nur beschränkt bewährt: Die Konzeption bot als bloße Einschränkung auf einen Rabattbereich den Verkäufern zu wenig konkrete Hilfe bei der Rabattfestlegung. Sie wurde daher in eine Ableitung geändert, die einen konkreten Rabatt vorschlägt, der jedoch im Rahmen der Einschränkung durch einen Verkäufer übersteuert werden kann. Die ursprüngliche Regel r1 wurde durch folgende Regel ersetzt: r1a: Bestellung hat Rabatt 100 - (Min + Max) / 2 / BP * 100, wobei Bestellung hat Bruttopreis BP Bestellung hat Nettopreis zwischen Min und Max. Ferner zeigte sich, dass die Festlegung des Rabatts auf einzelne Artikel nur auf der Basis des bestellten Artikels und der bestellten Menge zu simpel ist. Da dies eine Beschränkung des in „myTBQ“ eingebauten Rabatt-Mechanismus’ war, wurde beschlossen, auch die Artikelrabattierung in die Business Rule Engine auszulagern. Dazu wurde die Möglichkeit des „RegulationMaster„ ausgenutzt, RegelTemplates zu definieren. Damit lassen sich Fachanwendern RegelVorlagen zur Verfügung stellen, an denen lediglich an vordefinierten
21 Erntezeit
267
Stellen Änderungen vorgenommen werden können. Für die Artikelrabattierung hat Herbert Acker folgendes Template erstellt: rx: Bestellung beinhaltet Anzahl von Artikel mit Rabatt , falls alle folgenden Bedingungen erfüllt sind: Artikel ist einer von [, , …] Anzahl ist zwischen <Min> und <Max> Bestellung hat Destination Bestellung gehört zu Kunde Kunde ist vom Typ Heute ist zwischen und . Verkäuferinnen und Verkäufer können nun selber nach Belieben solche Geschäftsregeln definieren. Durch das Template sind sie dabei allerdings eingeschränkt: Sie können nur
neue Geschäftsregeln nach diesem Template anlegen, die Werte der in spitzen Klammern gesetzten Teile festlegen und auch dies nur innerhalb vorgegebener Wertebereiche, ganze Zeilen aus den Bedingungen entfernen, auf diesem Template basierende Geschäftsregeln wieder löschen.
Das folgende Beispiel zeigt eine nach diesem Template erstellte Geschäftsregel: r17: Bestellung beinhaltet Anzahl von Artikel mit Rabatt 5%, falls alle folgenden Bedingungen erfüllt sind: Artikel ist einer von [„Corona Extra, Flasche 33cl“, Dos Equis Amber, Flasche 33cl“] Anzahl ist zwischen 50 und 100 Bestellung hat Destination „Deutschland“ Bestellung gehört zu Kunde Kunde ist vom Typ „Restaurant“ Heute ist zwischen 15.6.2006 und 31.6.2006. Diese Geschäftsregeln wurden auch bereits mehrmals geändert, um die eine oder andere Zielgruppe anzusprechen oder den Verkauf verschiedener Produkte zu fördern. Alle Erweiterungen waren ohne Änderungen des ursprünglich erarbeiteten Unternehmensvokabulars möglich. Nun steht aber eine größere Änderung an. Bernd Oss trifft sich deswegen mit Benno Remser und Tina Reiber:
268
21 Erntezeit
B. Oss:
B. Remser: T. Reiber: B. Remser:
B. Oss: T. Reiber: B. Oss:
B. Remser
T. Reiber
B. Remser: B. Oss T. Reiber:
Ich habe gehört, dass uns seit Anfang Jahr unser Konkurrent „FASTBeer“ immer mehr Kunden abjagt. Habt Ihr eine Vorstellung, wie er das bewerkstelligt? Ich hab’s schon lange gesagt: Die zielen ganz genau auf uns! Wie soll das gehen? Immer wenn wir ein neues Bier mit Erfolg auf den Markt bringen, nimmt es auch „FASTBeer“ in ihr Angebot auf. Und um uns zu ärgern gehen sie mit dem Preis gleich etwas unter unsere Preise. Wenn’s sein muss, legen sie sogar 'was drauf, damit unsere Kunden zu ihnen wechseln. Aber können wir denn nicht einfach unsere Kunden mit längerfristigen Verträgen an uns binden? Woran denkst du? Wir könnten beispielsweise Bier-Lieferungen im Abonnement einführen. Ein Lokal hat sowieso einen mehr oder weniger regelmäßigen Bedarf an Bier. Wenn wir ein Abonnement zu Sonderkonditionen anbieten würden, hätten wir eine Absatzgarantie und die Kunden müssten nicht jeden Monat erneut bestellen. Somit gäbe es auch keinen Grund mehr, zur Konkurrenz zu wechseln! Das Problem ist nur, dass „myTBQ“ keine solchen Abonnemente unterstützt. Und ich will mich nicht schon wieder mit einer neuen Softwarte-Lösung herumschlagen müssen! Nur keine Panik auf der Titanic! Ich weiß, dass „myTBQ“ heute keine Abonnemente, aber wir können es leicht erweitern, sodass damit auch Abonnemente abgewickelt werden können! Hat das wieder mit diesem Business Rules Ansatz zu tun? Das klingt ja interessant! Wie lange denkst du, dass das dauert, Tina? Ich schätze, das ist in ein, zwei Wochen erledigt. Das aufwändigste daran ist, dass wir uns Gedanken zu einer soliden Strategie machen müssen!
Sofort wird eine Arbeitsgruppe gebildet, die das heutige Konzept der Einzelbestellungen in Richtung langfristige Kundenverträge erweitert.
21.1 Ausgangslage: Zwei Jahre später...
269
21.2 Lösungsansatz: Agilität Wird der Business Rules Ansatz in einem Unternehmen erst einmal gelebt, so kann es rascher auf neue Situationen reagieren – es wird agiler. Dies rührt daher, dass viele der geleisteten Initialaufwände ein Fundament bilden, auf das später aufgebaut werden kann:
Geschäftsziele sind explizit definiert und externe sowie interne Einflüsse auf diese Ziele sind identifiziert. Strategien und Taktiken basieren auf Einschätzungen, wie sich die Einflüsse auf die Geschäftsziele auswirken. Mit dem Unternehmensvokabular wurde eine einheitliche Terminologie geschaffen, welche nicht nur vom Personal, sondern auch in den IT-Systemen verwendet wird. Direktiven in Form von Regelungen und Geschäftsregeln legen präzise fest, wie Geschäftsprozesse abzuwickeln sind. Durch einen etablierten Rule Management Prozess besteht ein Feedback-Mechanismus, mit dem Änderungen im operationellen Betrieb erfasst werden können und der zur kontinuierlichen Adaption von Regelungen genutzt wird. Ein etablierter Knowledge Management Prozess sorgt dafür, dass alle Mitarbeiterinnen und Mitarbeiter wissen, was sie wissen müssen. Die weitestgehende Automatisierung von Regelungen und Geschäftsregeln erlaubt eine hohe Effizienz in der Abwicklung des Geschäfts. Eine flexible technische Implementation volatiler Regelungen in den IT-Systemen ermöglicht ihre rasche Adaption an neue Gegebenheiten.
Muss sich ein Unternehmen neuen Herausforderungen stellen, kann es auf dieses Fundament aufbauen. Zur systematischen Einschätzung von neuen Einflüssen auf ein Unternehmen kann wiederum das „Business Motivation Model“ dienen, welches bereits in den Kapiteln 6 bis 8 erläutert wurde. Der Hauptunterschied in dessen Anwendung liegt nun darin, dass das Unternehmen bereits ausgearbeiteten Strategien folgt und diese bloß noch den veränderten Gegebenheiten anpassen muss. Statt eine Vision auszuarbeiten und daraus Ziele abzuleiten müssen lediglich die neuen Einflüsse identifiziert und ihre Auswirkungen auf die bereits vorhandenen Ziele eingeschätzt werden. Aus diesen Einschätzungen lassen sich dann Strategien, Taktiken und schließlich entsprechende Regelungen ableiten. Diese repräsentieren letztlich die Reaktion des Unternehmens auf die veränderte Situation.
270
21 Erntezeit
Zur Inkraftsetzung der neuen oder geänderten Regelungen muss wieder geprüft werden, was sich automatisieren lässt und was mittels Knowledge Management ökonomischer umgesetzt werden kann. Bei der technischen Umsetzung sollte weitgehend auf den bestehenden Implementationen aufgebaut werden können. Sind die Faktenmodelle tragfähig genug konzipiert, so sind lediglich die Geschäftsregeln anzupassen.
21.3 Schritt für Schritt: Evolution eines Unternehmens Sind die Mechanismen des Business Rules Ansatzes erst einmal etabliert, so können dieselben Techniken auf Veränderungen angewandt werden, wie sie bei der erstmaligen Ausarbeitung zur Anwendung kamen. Die folgenden Schritte zeigen, wie der der Prozess des Business Rules Ansatzes im „Eilzugstempo“ durchlaufen wird, um systematisch auf Veränderungen zu reagieren: 1. Umfeld beobachten Das Umfeld, in dem sich ein Unternehmen bewegt, sollte permanent unter Beobachtung stehen. Es geht darum, neue interne und externe Einflüsse auf das Unternehmen zu identifizieren, aber auch die Relevanz bereits bekannter Einflüsse kritisch zu hinterfragen. In seltenen Fällen verändern sich auch die Ziele eines Unternehmens. In solchen Situationen können die Techniken wie sie im Kapitel 6.3 beschrieben wurden, zur Anwendung kommen. 2. Einflüsse analysieren Sind neue für das Unternehmen relevante Einflüsse aufgetaucht, müssen ihre Auswirkungen auf die gegebenen Ziele untersucht werden. Dies kann in ähnlicher Weise erfolgen, wie im Kapitel 7.3 beschrieben wurde. Und wiederum sind Strategien und Taktiken zu suchen, wie mit diesen Einflüssen umgegangen werden soll (siehe dazu Kapitel 8.3). Sind bereis früher identifizierte Einflüsse für das Unternehmen nicht mehr relevant, so sind auch die darauf basierenden Strategien und Taktiken zu hinterfragen. 3. Unternehmensvokabular aktualisieren Werden durch die Reaktion auf ein verändertes Umfeld neue Begriffe und Konzepte eingeführt, so sind diese im Unternehmensvokabular nachzutragen. Dies ist bereits im Kapitel 10.3 detailliert beschrieben.
21.3 Schritt für Schritt: Evolution eines Unternehmens
271
4. Geschäftsprozesse anpassen Resultieren grundsätzlich neue Strategien oder Taktiken aus den vorhergehenden Schritten, so ist der Einfluss auf die Geschäftsprozesse des Unternehmens zu untersuchen. Da Geschäftsprozesse und Geschäftsaktivitäten im Business Rules Ansatz eher leichtgewichtig beschrieben sind (siehe Kapitel 11), sind die Auswirkungen auf sie im Normalfall eher klein. 5. Neue Direktiven ausarbeiten Neue Strategien und Taktiken müssen durch entsprechende Direktiven umgesetzt werden. Es sind Regelungen zu formulieren oder zu aktualisieren, die das Verhalten in den einzelnen Geschäftsaktivitäten festlegen. Diese Regelungen werden wie üblich durch Geschäftsregeln konkretisiert. Die dazu anwendbaren Techniken sind in den Kapiteln 12 und 13 beschrieben. Bei solchen Änderungen muss immer geprüft werden, ob die Neuerungen mit den bestehenden Regelungen immer noch in Einklang stehen. Dazu können insbesondere die Verifikations-Techniken verwendet werden, die im Kapitel 15 beschrieben sind. 6. Neue Direktiven umsetzen Schließlich müssen die neuen Direktiven in Kraft gesetzt werden. Dabei muss wieder entschieden werden, welche der Regelungen mittels Knowledge Management publiziert und welche mittels IT-Systemen automatisiert werden (siehe Kapitel 16). Aufgrund der Vorarbeiten sind die meisten IT-Systeme bereits so flexibel gestaltet, dass sich neue Geschäftsregeln sehr rasch umsetzen lassen. Im Idealfall sollten daher die meisten neuen automatisierten Direktiven ohne strukturelle Änderungen an den IT-Systemen auskommen. Ist dies einmal doch nicht der Fall, so müssen die notwendigen Anpassungen an der technischen Infrastruktur als IT-Projekt abgewickelt werden. Die Details dazu sind in den Kapiteln 17 bis 20 erläutert. Seitenblick: Ein ähnliches Vorgehen, wie es oben geschildert wurde, kann bei Firmenfusionen und -akquisitionen zur Anwendung kommen. Falls beide betroffenen Firmen zumindest Ansatzweise dem Business Rules Ansatz gefolgt sind, müssen Ziele, Einflüsse und Strategien abgeglichen sowie Unternehmensvokabulare harmonisiert werden. Darauf lassen sich dann Direktiven für das neue konsolidierte Unternehmen ableiten.
272
21 Erntezeit
21.4 Ergebnis: Abonnemente in KnowBeer Im Folgenden ist zusammengefasst, wie in KnowBeer auf das verstärkte Preisbewusstsein der Kunden reagiert hat. Erste Aufgabe war, dieses Preisbewusstsein explizit als neuen Einfluss auf KnowBeer zu identifizieren und seine Auswirkungen auf die Ziele von KnowBeer einzuschätzen. Daraus wurde die Strategie langfristiger Verträge abgeleitet, welche in Form von Abonnementen und Rahmenverträgen konkretisiert werden soll. Im Folgenden ist dieser Prozess kurz dokumentiert: Einfluss (neu): Die Kunden sind heute sehr preisbewusst. Sie kaufen Produkte dort ein, wo sie am günstigsten sind. Qualitatives Ziel (ursprüngliches Ziel 4): Wir möchten Marktleader in unserem Produktsegment sein. Quantitatives Ziel (ursprüngliches Ziel 4; in Frage gestellt): Unsere Preise bewegen sich per sofort im Bereich von ±5% gegenüber dem Markt-Durchschnitt. Einschätzungen (neu): Gefahr: Sobald Kunden ein Produkt aus unserem Sortiment bei unserer Konkurrenz zu einem günstigeren Preis erhalten, bestellen sie nicht mehr bei uns. Schwäche: Wir haben bisher keine Möglichkeit, Kunden langfristig an uns zu binden. Qualitatives Ziel (neu): Wir müssen die Loyalität unserer Kunden erhöhen. Strategie (neu): Wir bieten unseren Kunden langfristige Verträge an, durch die sie zu für sie guten Konditionen an uns gebunden werden. Taktiken (neu): Wir offerieren unseren Kunden Bestellungen als Abonnemente, in denen regelmäßige Lieferungen zu guten Konditionen vereinbart werden. Wir offerieren unseren Kunden Rahmenverträge, in denen umsatzabhängige Rabattstaffelungen vereinbart werden. In einer Sitzung der Geschäftsleitung wurden Rahmenverträge als weniger effizient als Abonnemente erachtet. Daher wurde beschlossen, dass das Angebot von Abonnementen priorisiert behandelt und erst in einer zweiten Phase das Thema Rahmenverträge noch einmal aufgebracht werden sollte.
21.4 Ergebnis: Abonnemente in KnowBeer
273
Um das Konzept der Abonnemente auszuarbeiten, wurde als erstes das Unternehmensvokabular erweitert: Abb. 21.1: Abonnemente
gehört zu
Kunde
Bestellung
hat Bestelldatum
Datum
hat Lieferdatum :Vertragstyp
Vertragstyp
beginnt am
Einzelbestellung
Abonnement
endet am
Seitenblick In diesem Faktenmodell kam die so genannte PowertypeNotation zur Anwendung, der wir bisher noch nicht begegnet sind. Sie besagt, dass das Spezialisierungskriterium einer „Bestellung“ der „Vertragstyp“ ist, wobei „Einzelbestellung“ und „Abonnement“ Spezialisierungen einer „Bestellung“ und gleichzeitig Exemplare von „Vertragstyp“ sind. Neben dem Faktenmodell wurden auch die entsprechenden Definitionen im Unternehmensvokabular ergänzt: Eine ÖBestellung, welche in einem zeitlich begrenzten Rahmen die regelmäßige ÖLieferung von ÖProdukten vereinbart. Synonym(e): ––– Beispiel(e): Der „Goldene Ochsen“ bestellt vom 1. Mai 2006 bis zum 31. Oktober 2006 monatlich 300 33cl Flaschen „San Miguel“. Verantw.: Verkauf/T. Reiber
Abonnement
Einzelbestellung Eine ÖBestellung, in welcher eine einmalige ÖLieferung von ÖProdukten vereinbart wird. Synonym(e): Bestellung (sollte in Zukunft aber nicht mehr verwendet werden) Beispiel(e): ––– Verantw.: Verkauf/T. Reiber Die Art einer ÖBestellung. Ist entweder eine ÖEinzelbestellung, ein ÖAbonnement oder ein ÖRahmenvertrag (später). Synonym(e): ––– Beispiel(e): ––– Verantw.: Verkauf/T. Reiber
Vertragstyp
274
21 Erntezeit
Im Folgenden sind zudem neuen Fakttypen rund um Abonnemente definiert: … beginnt am … Form: ÖAbonnement beginnt am Datum Arität: 2 Verantw.: Verkauf/T. Reiber … endet am … Form: ÖAbonnement endet am Datum Arität: 2 Verantw.: Verkauf/T. Reiber Schließlich wurde eine Regelung „Abonnemente“ definiert, die sich wie folgt zusammenfassen lässt: Regelung „Abonnemente“ Beschreibung
Legt die Abwicklung und die Preise von Abonnementen fest.
Ableitungen
Abonnement hat Rabatt Prozent
Einschränkungen
(keine)
Aktionen
Erzeugung von wiederholten Bestellungen
Durchsetzung
Nachträgliche Rechfertigung
Grundlagen
Abonnement beginnt am Datum
Abonnement endet am Datum
Kunde hat Jahresumsatz Betrag
Kunde hat Geschäftsbeziehung seit Dauer
Kunde hat Zahlungsprobleme
Vokabular
Verkauf
Verantwortlich
Verkauf/T. Reiber
Tabelle 21.1 Regelung „Abonnemente“
Für diese Regelung wurde folgende Prozessregel ausformuliert, die eine bestehende Abonnementsbestellung automatisch erneuert: r1: Falls eines der folgenden Ereignisse eintritt: vereinbarter Liefertermin Und alle folgenden Bedingungen erfüllt sind: Bestellung ist vom Typ „Abonnement“ Bestellung beginnt am Datum1 Bestellung endet am Datum2 heute zwischen Datum1 und Datum2 Dann müssen folgende Aktionen ausgeführt werden: Kopiere Bestellung zu neue Bestellung Merke neue Bestellung hat Bestelldatum Datum Merke neue Bestellung hat Lieferdatum neues Lieferdatum wobei neues Lieferdatum ist Datum + 30
21.4 Ergebnis: Abonnemente in KnowBeer
275
Für die Rabattierung von Abonnementen konnte die bereits bestehende Regelung „Rabattbestimmung“ erweitert werden. Dazu musste lediglich der Typ einer Bestellung entsprechend berücksichtigt werden: r1a: Bestellung hat Rabatt 100 - (Min + Max) / 2 / BP * 100, wobei Bestellung ist vom Typ „Abonnement“ ist nicht wahr Bestellung hat Bruttopreis BP Bestellung hat Nettopreis zwischen Min und Max46. r1b: Bestellung hat Rabatt 105 - (Min + Max) / 2 / BP * 100, wobei Bestellung ist vom Typ „Abonnement“ Bestellung beginnt am Beginn Bestellung endet am Ende (Ende - Beginn) kleiner als 12 Monate Bestellung hat Bruttopreis BP Bestellung hat Nettopreis zwischen Min und Max.
r1c: Bestellung hat Rabatt 110 - (Min + Max) / 2 / BP * 100, wobei Bestellung ist vom Typ „Abonnement“ Bestellung beginnt am Beginn Bestellung endet am Ende (Ende - Beginn) größer oder gleich 12 Monate Bestellung hat Bruttopreis BP Bestellung hat Nettopreis zwischen Min und Max. Da vorgesehen war, die neuen Abonnemente vollständig automatisiert umzusetzen, stellte sich die Frage, wie die zusätzlich nötigen Fakttypen in „myTBQ“ abgebildet werden können. Glücklicherweise ist „myTBQ“ so konzipiert, dass sich installationsspezifische Eigenschaften von Kunden, Artikeln und Bestellungen konfigurieren lassen. In Abb. 21.2 sind die dazu notwendigen Konfigurationstabellen ersichtlich.
46
Der Fakttyp „ hat Nettopreis zwischen <Min> und <Max>“ legt den zulässigen Preisbereich der Bestellung fest.
276
21 Erntezeit
TArtikeleigenschaften
TArtikeleigenschaftstypen
ANr * Lieferant Bezeichnung * Typ Einheit Stückpreis Beschreibung Status
* Artikel * Eigenschaft Wert
ETId Bezeichnung Typ
TBestellungen
TBestelleigenschaften
TBestelleigenschaftstypen
BNr * BTId * Kunde Bestelldatum Wunschdatum Express Lieferdatum Bruttopreis Versandkosten Rabatt Nettopreis Bezahlt Bemerkungen Status
* Bestellung * Eigenschaft Wert
BEId Bezeichnung Typ
TArtikel
Abb. 21.2: „myTBQ“ Konfiguration
TArtikeltypen ATId Bezeichnung
TKunden
TBestelltypen BTId Bezeichnung
TKundentypen KTId Bezeichnung
TKundeneigenschaftstypen
TKundeneigenschaften
KEId Bezeichnung Typ
* Kunde * Eigenschaft Wert
KNr Name * Typ Ansprechperson Strasse PLZ Ort * Land Telefon Fax Email Kreditlimite Jahresumsatz Zahlungsprobleme Bemerkungen Status
In den Bestelleigenschaften lassen sich problemlos die neuen „beginnt am“ und „endet am“ Daten eines Abonnements unterbringen. In der Tabelle „TBestelltypen“ lässt sich zudem der neue Typ „Abonnement“ einführen. Schließlich wurde die Prozessregel zur automatischen Erneuerung von Abonnementsbestellung als Datenbank-Trigger implementiert, wie dies für die Prozessregel der Regelung „Gratismuster“ siehe Kapitel 20.4.5 beschrieben wurde. Da die Rabattierung von Bestellungen bereits seit längerem über die Business Rule Engine läuft, konnte Tina Reiber die entsprechenden Geschäftsregeln gleich selber anpassen. Zuvor musste allerdings Herbert Acker dafür sorgen, dass die neuen Fakttypen der Business Rule Engine auch tatsächlich zur Verfügung stehen.
21.4 Ergebnis: Abonnemente in KnowBeer
277
21.5 Wie geht es weiter? Zur Feier des Abschlusses hat Tina Reiber ihren Chef, Bernd Oss auf einem Plakat verewigt, welches seither im Büro der ITVerantwortlichen Daniel Enker und Herbert Acker hängt:
Who rules? e ss Busin
The Business rules! Somit sind wir am Ende dieses Buches angelangt. KnowBeer sammelt jetzt weiter Erfahrungen mit dem Business Rules Ansatz und wird uns sicher wertvolle Tipps für die zweite Auflage dieses Buches liefern können47.
47
Falls Sie als Leser selber praktische Erfahrungen oder Feedback zu den im Buch vermittelten Themen haben, sind wir als Autoren sehr daran interessiert. Bitte senden Sie uns ein E-Mail an [email protected] oder [email protected]!
278
21 Erntezeit
Anhänge A
Business Rules Manifest........................................... 281
B
Zusammenfassung des Entwicklungsprozesses... 285
C
Übersicht über die verwendeten Notationen .......... 289
D
Muster & Checklisten................................................. 293
E
Meta Modelle............................................................... 307
F
Begriffsdefinitionen ................................................... 309
G
Business Rules Technologie .................................... 319
H
Weitere Informationen ............................................... 331
I
Literaturreferenzen..................................................... 333
279
A
Business Rules Manifest
Die Prinzipien der Business Rules Unabhängigkeit The Business Rules Group48
Artikel 1. Primäre statt sekundäre Anforderungen 1.1. Regeln sind Elemente erster Klasse in der Anforderungs-Welt. 1.2. Regeln sind ein essentieller und eigenständiger Teil von Geschäfts- und Technologie-Modellen. Artikel 2. Separat von Prozessen statt in ihnen enthalten 2.1. Regeln sind explizite Einschränkungen für Verhalten und/oder bieten Unterstützung für Verhalten. 2.2. Regeln sind weder Prozesse noch Prozeduren und sollen auch nicht in diesen enthalten sein. 2.3. Regeln gelten über Prozess- und Prozedurgrenzen hinweg. Es sollte ein einziges, zusammenhängendes Regelwerk für Geschäftsaktivitäten existieren, das in allen relevanten Bereichen konsistent angewandt wird.
48
Copyright, 2003, 2004, 2005. Business Rules Group., Version 2.0, 1. November 2003. Editor Ronald G. Ross. BusinessRulesGroup.org, Übersetzung: M. Schacher, KnowGravity Inc., © 2004. Die Berechtigung zur unbeschränkten Vervielfältigung und Verteilung dieses Dokuments ist nur unter Einhaltung folgender Bedingungen gegeben: (a) Das Copyright sowie diese Autorisierungsnotiz bleiben enthalten. (b) Die Business Rules Group wird klar als Autor des Dokuments ausgewiesen. (c) Kein Teil dieses Dokuments, inklusive Titel, Inhalt, Copyright und Autorisierungsnotiz, darf in irgendeiner Weise verändert, abgekürzt oder erweitert werden.
A Business Rules Manifest
281
Artikel 3. Bewusstes Wissen statt Nebenprodukt 3.1. Regeln basieren auf Fakten und Fakten basieren auf Konzepten, die durch Begriffe repräsentiert werden. 3.2. Begriffe repräsentieren Geschäftskonzepte; Fakten sind Feststellungen über diese Konzepte; Regeln schränken diese Fakten ein und unterstützen sie. 3.3. Regeln müssen explizit sein. Es dürfen keine impliziten Annahmen über Konzepte oder Fakten als Regeln vorausgesetzt werden. 3.4. Regeln sind die Grundlage dessen, was eine Organisation über sich weiß, d.h. die Grundlage des Geschäftswissens. 3.5. Regeln müssen entwickelt, geschützt und verwaltet werden. Artikel 4. Deklarativ statt prozedural 4.1. Regeln sollten deklarativ in natürlich-sprachlichen Sätzen für die Fachabteilungen ausgedrückt werden. 4.2. Kann etwas nicht ausgedrückt werden, dann ist es keine Regel. 4.3. Eine Menge von Sätzen ist nur dann deklarativ, wenn damit keine Sequenz impliziert wird. 4.4. Jeder Regel-Satz, der andere Konstrukte als Begriffe und Fakten benötigt, impliziert Annahmen über eine System-Implementation. 4.5. Eine Regel ist etwas anderes als ihre Durchsetzung. Eine Regel und ihre Durchsetzung sind separate Aspekte. 4.6. Regeln sollen unabhängig von den Verantwortlichkeiten (wer, wo, wann, wie) ihrer Durchsetzung formuliert werden. 4.7. Ausnahmen zu Regeln werden durch weitere Regeln ausgedrückt. Artikel 5. Wohldefinierte Ausdrücke statt ad-hoc Formulierungen 5.1. Geschäftsregeln sollten so formuliert sein, dass sie von den Fachabteilungen auf ihre Korrektheit validiert werden können. 5.2. Geschäftsregeln sollten so formuliert sein, dass sie untereinander auf Konsistenz verifiziert werden können. 5.3. Formale Logik, wie z.B. die Prädikatenlogik, ist das Fundament für die Formulierung von Regeln auf der Basis von Geschäftsbegriffen sowie für die Technologie, welche Geschäftsregeln implementiert.
282
A Business Rules Manifest
Artikel 6. Regel-basierte Architektur statt indirekte Implementation 6.1. Eine Business Rules Applikation ist für die Umsetzung von sich laufend ändernden Geschäftsregeln konzipiert. Die Plattform einer solchen Applikation sollte solche Änderungen unterstützen. 6.2. Geschäftsregeln direkt auszuführen – z.B. in einer Rule Engine – ist eine bessere Implementations-Strategie als die Regeln in eine prozedurale Form zu transformieren.. 6.3. Ein Business Rules System muss immer in der Lage sein, seine getroffenen Entscheidungen oder ausgelösten Aktionen zu begründen. 6.4. Regeln basieren auf Wahrheitswerten. Wie ein solcher Wahrheitswert bestimmt und aktualisiert wird, bleibt dem Benutzer verborgen. 6.5. Der Zusammenhang zwischen Regeln und Ereignissen ist im Allgemeinen „viele-zu-viele“. Artikel 7. Regel-gesteuerte Prozesse statt ausnahmebasierte Programmierung 7.1. Regeln definieren die Grenze zwischen akzeptierten und unakzeptierten Geschäftsaktivitäten. 7.2. Regeln benötigen oft eine selektive Behandlung von festgestellten Regel-Verletzungen. Eine solche Ausnahmebehandlung ist eine Aktivität wie jede andere. 7.3. Zum Erreichen einer maximalen Konsistenz und Wiederverwendbarkeit soll die Bearbeitung von unakzeptierten Geschäftsaktivitäten von akzeptierten Geschäftsaktivitäten trennbar sein. Artikel 8. Für das Geschäft statt für die Technologie 8.1. Regeln betreffen Geschäftspraktiken und -richtlinien; daher sind Geschäftsregeln durch Geschäftsziele motiviert und durch verschiedene Einflüsse gestaltet. 8.2. Regeln sollen die Fachabteilungen immer etwas kosten. 8.3. Die Kosten für die Durchsetzung von Geschäftsregeln müssen sowohl gegenüber Geschäftsrisiken abgewogen werden als auch gegenüber Geschäftschancen, die sonst verpasst würden. 8.4. „Mehr Regeln“ ist nicht besser. Üblicherweise sind wenige „gute Regeln“ besser. 8.5. Ein effektives System basiert auf einer kleinen Anzahl Regeln. Zusätzliche, differenzierende Regeln können später hinzugefügt werden, womit das System „smarter“ wird.
A Business Rules Manifest
283
Artikel 9. Von, durch und für das Personal der Fachabteilungen statt der IT 9.1. Regeln sollen von den Leuten der Fachabteilungen stammen, die Wissensträger sind. 9.2. Fachabteilungen sollen Werkzeuge zur Verfügung haben, die sie bei der Formulierung, Validierung und Verwaltung von Geschäftsregeln unterstützen. 9.3. Fachabteilungen sollen Werkzeuge zur Verfügung haben, die ihnen bei der Verifikation der Konsistenz von Geschäftsregeln untereinander Hilfe bieten. Artikel 10. Verwaltung von Geschäftslogik statt Hardware/Software Plattformen 10.1. Regeln sind ein vitales Gut einer Organisation. 10.2. Langfristig sind Geschäftsregeln wichtiger für eine Organisation als Hardware-/Software-Plattformen. 10.3. Geschäftsregeln sollten so organisiert und verwaltet werden, dass sie sich einfach auf neue Hardware-/Software-Plattformen migrieren lassen. 10.4. Regeln, sowie die Fähigkeit diese effektiv zu ändern, sind fundamental für die Verbesserung der Anpassungsfähigkeit einer Organisation.
284
A Business Rules Manifest
B
Zusammenfassung des Entwicklungsprozesses
In diesem Anhang sind die einzelnen Schritte des Entwicklungsprozesses unseres Buches, aufgeteilt nach Phasen, kurz zusammengefasst.
B.1 Phase „Geschäftsanalyse“ Definition einer Vision und Formulierung von Zielen (Kapitel 6.3) Vision formulieren (genau eine) Qualitativen Ziele formulieren (5 bis 10) Quantitativen Ziele formulieren (5 bis 15) Einschätzung von Einflüssen (Kapitel 7.3) Unternehmenseinflüsse identifizieren Unternehmenseinflüsse einschätzen Auswirkungen bestimmen Kosten/Nutzen analysieren Erarbeitung von Strategien und Taktiken (Kapitel 8.3) Mission formulieren (genau eine) Strategien erarbeiten (5 bis 10) Taktiken erarbeiten (10 bis 20) Kosten/Nutzen analysieren Abgrenzung eines Projekts (Kapitel 9.3) Motive auflisten Relevante Dinge auflisten Relevante Aufgaben auflisten Relevante Orte auflisten Relevante Ressourcen auflisten Relevante Ereignisse auflisten
B Zusammenfassung des Entwicklungsprozesses
285
Erarbeitung eines Unternehmensvokabulars (Kapitel 10.3) Werkzeug zur Verwaltung des Vokabulars festlegen Themenbereiche identifizieren Relevante Objekttypen identifizieren Relevanten Fakttypen identifizieren Faktenmodell erstellen Relevanten Objekttypen definieren Skizzierung von Geschäftsprozessen (Kapitel 11.3) Wichtige Geschäftsprozesse identifizieren (5 bis 20) Wichtige Geschäftsaktivitäten identifizieren (7 ± 2 pro Geschäftsprozess) Abhängigkeiten modellieren Verantwortlichkeiten zuordnen Organisationsstruktur definieren Formulierung von Regelungen (Kapitel 12.3) Regelungen identifizieren Regelungen beschreiben Unternehmensvokabular aktualisieren Formulierung von Geschäftsregeln (Kapitel 13.3) Regelungen priorisieren Regelungen klassifizieren Durchsetzungsgrade bestimmen Grundlagen identifizieren Werkzeug zur Verwaltung des Regelkatalogs festlegen Geschäftsregeln erarbeiten Unternehmensvokabular aktualisieren Strukturierung von Regelungen (Kapitel 14.3) Entwurf von Rule Maps (Kapitel 14.3.1) – Rule Maps identifizieren – Grundlagen und Ergebnisse identifizieren – Rule Maps entwerfen Entwurf von Inferenzbäumen (Kapitel 14.3.2) – Zu untersuchender Fakttyp festlegen – Abhängige Fakttypen identifizieren – Inferenzbaum aufzeichnen Prüfung von Regelungen (Kapitel 15.3) Regelungen mit anderen Ergebnissen abgleichen Regelungen verifizieren Regelungen validieren
286
B Zusammenfassung des Entwicklungsprozesses
B.2 Phase „Umsetzung“ Aufsetzen des Rule Managements (Kapitel 16.3) Umsetzung definieren Aktivitäten des Rule Managements definieren Verantwortlichkeiten im Rule Management definieren Erhebung der Anforderungen (Kapitel 17.3) Volatilität ermitteln Ausbreitungszeit ermitteln Anforderungen aus Regelungen ableiten Umgebung beschreiben Anwendungsfälle für das Rule Management Werkzeug festlegen Anforderungen an das Rule Management Werkzeug skizzieren Auswahl der Business Rules Technologie (Kapitel 18.3) Regelungsspezifische BRT-Anforderungen identifizieren Umsetzungsstrategie skizzieren BRT-Anforderungskatalog zusammenstellen BRT Evaluieren Pilotprojekt durchführen Entwurf der BR-Architektur (Kapitel 19.3) Regelverwaltung implementieren Regeltechnologie wählen Makro-Architektur wählen Architektur optimieren Faktenmodell-Ausschnitte stabilisieren Implementation der Regelungen (Kapitel 20.3) Geschäftsregeln mit Fachseite formulieren Geschäftsregeln durch IT programmieren Geschäftsregeln testen Rule Management testen Evolution des Unternehmens (Kapitel 21.3) Umfeld beobachten Einflüsse analysieren Unternehmensvokabular aktualisieren Geschäftsprozesse anpassen Neue Direktiven ausarbeiten Neue Direktiven umsetzen
B.2 Phase „Umsetzung“
287
C
Übersicht über die verwendeten Notationen
In unserem Buch werden verschiedene grafische Notationen verwendet. Diese sind hier als Übersicht zusammengefasst.
C.1 Faktenmodell-Notation (Konzept1) SatzTeil1 (Konzept2) SatzTeil1 (Konzept3)
Abb. C.1 Die FaktenmodellNotation
höherwertiger Fakttyp mit Notitz für Satzmuster
genereller Objekttyp ...
Aussage über Konzept3
Konzept3
Konzept1 StatzTeil2
SatzTeil1 Konzept2
Aussage über zwei Konzepte
Konzept6 «ist Rolle von»
spezieller Objekttyp
Konzept4
allgemeiner Objekttyp ...
Konzept5
individueller Objekttyp
Konzept7
Rolle des anderen Objektyps
Die Faktenmodell-Notation ist in Kapitel 10.2.2 erklärt.
C Übersicht über die verwendeten Notationen
289
C.2 Aktivitätsdiagramm-Notation Abb. C.2 Die AktivitätsdiagrammNotation
Organisationseinheit 1 Organisationseinheit 2
Organisationseinheit 3
empfangenes Geschäftsereignis
Voraussetzung für
Geschäftsaktivität 1
Voraussetzung für
Geschäftsaktivität 2
Voraussetzung für
gesendetes Geschäftsereignis
Geschäftsaktivität 3
Ende
Die Aktivitätsdiagramm-Notation ist in Kapitel 11.2 erklärt.
C.3 Rule-Map-Notation Abb. C.3 Die Rule-MapNotation
«Ableitungen» Regelung «deklariert» deklarierter Fakttyp
«abgeleitet» abgeleiteter Fakttyp
«Prozessregeln» eine andere Regelung «Geschäftsereignis» Geschäftsereignis «Geschäftsaktivität» Geschäftsaktivität
Die Rule-Map-Notation ist in Kapitel 14.2.1 erklärt.
290
C Übersicht über die verwendeten Notationen
C.4 Inferenzbaum-Notation «abgeleitet» noch ein abgeleiteter Fakttyp
rückwärts
vorwärts
«abgeleitet» abgeleiteter Fakttyp
Abb. C.4 Die Inferenzbaum-Notation
«deklariert» noch ein deklarierter Fakttyp
«abgeleitet» ein anderer abgeleiteter Fakttyp
«deklariert» ein anderer deklarierter Fakttyp
«deklariert» deklarierter Fakttyp
Die Inferenzbaum-Notation ist in Kapitel 14.2.2 erklärt.
C.4 Inferenzbaum-Notation
291
D
Muster & Checklisten
In diesem Anhang sind verschiedenste, in eigenen Projekten wiederverwendbare Informationen in Form von Mustern und Checklisten zusammengestellt.
D.1 Formen von Entscheidungstabellen Lookup-Tabelle Die einfachste Form der Entscheidungstabelle ist die LookupTabelle: Kriterium 1
Kriterium 2
…
Folgerung
Wert 11
Wert 21
…
Wert X
Wert 12
Wert 22
…
Wert Y
…
…
…
…
Folgerungstabelle Bei einer Folgerungstabelle stehen in den Inhaltszellen verschiedene Folgerungen. Eine Folgerungstabelle mit zwei Kriterien hat folgende Struktur: Kriterium 1 Kriterium 2
Wert 11
Wert 12
Wert 13
Wert 21
Folgerung 1
Folgerung 2
Folgerung 3
Wert 22
Folgerung 4
Folgerung 5
Folgerung 6
…
…
…
…
Für drei Kriterien können mehrere obiger Folgerungstabellen mit je einem Titel mit dem Wert des entsprechenden dritten Kriteriums erstellt werden. Die einzelnen Folgerungen können auch von komplexer Struktur sein, wie beispielsweise verschiedene Berechnungsformeln.
D Muster & Checklisten
293
Bedingungstabelle In einer Bedingungstabelle repräsentieren die Inhaltszellen TeilBedingungen, welche zu den Teil-Folgerungen führen. Diese Form der Entscheidungstabelle haben wir im Buch verwendet. Regel
1
2
3
4
...
n
Bedingung Kriterium 1
Wert 11
x
Wert 12 Kriterium 2
x x
Wert 21
x
Wert 22
x
Wert 23 …
x
x x
x x
…
Folgerung Kriterium X
Wert X1
x
Wert X2
x
Kriterium Y
Wert Y1
x
Wert Y2 …
x
x
x x x
…
Geschachtelte Bedingungstabelle In der geschachtelten Bedingungstabelle werden die Wertebereiche der einzelnen Kriterien ineinander geschachtelt dargestellt: Bedingung Kriterium 1
Wert11
Kriterium 2
Wert21 Wert22
Kriterium 3
Wert12 Wert23
Wert21
Wert22
Wert23
W31 W32 W31 W32 W31 W32 W31 W32 W31 W32 W31 W32
…
Folgerung Kriterium X
Wert X1
x
Wert X2 Kriterium Y
Wert Y1 Wert Y2
…
294
…
D Muster & Checklisten
x x x
x
x
x x x
x x
x
x x
x x
x x
x x
x x
x
x
D.2 Textschablonen für formales Deutsch Textschablone für Ableitungen Ableitungen lassen sich auf der Basis der folgenden Textschablone in formalem Deutsch verfassen: : , falls alle folgenden Bedingungen erfüllt sind: „UND“ Verknüpfung … . Anstelle der „UND“-Verknüpfung kann auch eine „ODER“Verknüpfung treten: : , falls mindestens eine der folgenden Bedingungen erfüllt ist: „ODER“ Verknüpfung … .
Textschablone für Prozessregeln Prozessregeln in der Form von Bedingungs/Aktions-Regeln lassen sich auf der Basis der folgenden Textschablone in formalem Deutsch verfassen: : Falls alle folgenden Bedingungen erfüllt sind: „UND“ Verknüpfung … . Dann müssen/dürfen folgende Aktivitäten (nicht) ausgeführt werden: „UND“ Verknüpfung … .
D.2 Textschablonen für formales Deutsch
295
Liegen Prozessregeln in Form von Ereignis/Bedingungs/AktionsRegeln vor, kann die folgende Textschablone verwendet werden: : Falls eines der folgenden Ereignisse eintritt: <Ereignis 1> „ODER“ <Ereignis 2> Verknüpfung … <Ereignis n> Und alle folgenden Bedingungen erfüllt sind: „UND“ Verknüpfung … . Dann müssen/dürfen folgende Aktivitäten (nicht) ausgeführt werden: „UND“ Verknüpfung … .
Textschablone für Einschränkungen Einschränkungen lassen sich auf der Basis der folgenden Textschablone in formalem Deutsch verfassen: : Für jeden müssen immer alle folgenden Bedingungen erfüllt sein: „UND“ Verknüpfung … . Kardinalitäts-Einschränkungen, d.h. Mengenbeschränkungen in Aussagen lassen sich auf der Basis der folgenden Textschablone in formalem Deutsch verfassen:
296
D Muster & Checklisten
:
Jede(r/s) genau ein(e/er/en/em)
:
Jede(r/s) mindestens ein(e/er/en/em)
:
Jede(r/s) mindestens
:
Jede(r/s) höchstens ein(e/er/en/em)
:
Jede(r/s) höchstens
Textschablone für Berechnungen Berechnungen (numerische, aber auch nicht-numerische) lassen sich auf der Basis der folgenden Textschablone in formalem Deutsch verfassen: : , wobei … falls alle folgenden Bedingungen erfüllt sind: „UND“ Verknüpfung … . Oft entfällt auch der Bedingungsteil in Berechnungen.
D.2 Textschablonen für formales Deutsch
297
D.3 Konzept-Bibliothek Objekttypen sind, wie auch Fakttypen, Konzepte. Bei der Formulierung eines Faktenmodells kann auf die folgenden, generischen (d.h. immer wieder auftretenden) Objekttypen aufgebaut werden: Konzept
Abb. D.1 Vordefinierte Konzepte Objekttyp
Fakttyp
«ist Rolle von» Geschäftsobjekt
Werttyp
Prädikat Funktion
Zahl
Text
Zeitpunkt
Menge
Einheit
«ist Rolle von»
«ist Rolle von»
«ist Rolle von»
Anzahl
Name
Datum
Bag
"m"
Prozent
Beschreibung
Uhrzeit
Set
"kg"
Betrag phys. Grösse
"s" hat Einheit
"A" "K" "mol"
Dauer
"cd"
Der Unterschied zwischen Bag und Set liegt darin, dass in einem Bag dasselbe Element auch mehrmals vorkommen kann. Im Gegensatz dazu darf in einem Set ein Element höchstens einmal auftreten. Unter Einheit sind die sieben SI-Einheiten [BIPM] zu verstehen: Länge in Metern, Masse in Kilogramm, Zeit in Sekunden, elektrische Stromstärke in Ampère, thermodynamische Temperatur in Kelvin, Substanzmenge in Mol sowie die Lichtstärke in Candela. Anwendungsspezifische Objekttypen können als Spezialisierungen von „Geschäftsobjekt“ betrachtet werden, anwendungsspezifische Werttypen als weitere Rollen obiger Werttypen.
298
D Muster & Checklisten
D.4 Fakttypen-Bibliothek Bei der Formulierung eines Faktenmodells kann auf die folgenden, generischen (d.h. immer wieder auftretenden) Fakttypen aufgebaut werden: Konzept
Konzept
Anzahl
Fakttyp
gleich
ist Anzahl von in
ungleich (Werttyp) zwischen (Werttyp) und (Werttyp)
(Anzahl) ist unterschiedliche Anzahl von (Objekttyp) in (Fakttyp)
zwischen
ist unterschiedliche Anzahl von Objekttyp
Abb. D.2 Vordefinierte Fakttypen
und Werttyp Werttyp
Fakttyp
Werttyp größer als
in
größer oder gleich (Werttyp) ist Minimum von (Werttyp) in (Fakttyp)
kleiner als
ist Minimum von Werttyp
kleiner oder gleich Konzept
Menge
Werttyp
Fakttyp
ist eine(r/s) von Menge
in
Menge ist enthalten in
Werttyp
(Werttyp) ist Maximum von (Werttyp) in (Fakttyp)
Funktion ist
Datum
Menge
Fakttyp
früher als
in ist heute
ist jetzt
(Menge) ist die Menge von (Objekttyp) in (Fakttyp)
ist die Menge von Objekttyp
trifft nicht zu Bezieht sich auf eine ganze Regelung
Objekttyp
von Geschäftsregeln
Menge
Werttyp
Datum später als
Geschäftsregel
ist Maximum von
Fakttyp
in
treffen ncht zu
keine andere Regel trifft zu
(Objekttyp) ist der/die/das erste von (Objekttyp) in (Fakttyp)
ist der/die/das erste von Objekttyp
D.4 Fakttypen-Bibliothek
299
D.5 Anforderungen an Regel-Technologie Anforderungen an Business Rules Technologie lassen sich in die drei Klassen unterteilen, welche im Kapitel 18.2 beschrieben sind: Rule Execution Technologie Rule Management Technologie Rule Discovery Technologie Im Folgenden sind Checklisten für generische Anforderungen an diese drei Klassen tabellarisch zusammengestellt. Zusätzlich sind in einer vierten Tabelle allgemeine Anforderungen ersichtlich, welche alle drei Technologie-Klassen betreffen. Solche generischen Anforderungskataloge müssen selbstverständlich auf die spezifischen Anforderungen eines konkreten IT-Systems maßgeschneidert und die einzelnen Anforderungen mit einer individuellen Gewichtung versehen werden. Tabelle D.1 zeigt eine Checkliste möglicher generischer Anforderungen an die Klasse der Rule Execution Technologie. Tabelle D.1 Rule Execution Anforderungen
Id
Anforderung
EF
Funktionale Anforderungen
EF1 EF1.1
Regel-Semantik Welche Regel-Typen werden benötigt? - Einschränkungen - Ableitungen - Prozessregeln (Event/Condition/Action oder bloß Condition/Action)
EF1.2
Welche Art von Bedingungen wird benötigt? - einfache UND/ODER/NICHT Verknüpfungen von Ja/NeinKriterien - Kriterien mit parametrisierten Argumenten (Funktionen) - Bedingungen mit Platzhaltern (logische Variabeln) mit „für alle…“ und „es existiert…“ Operatoren (Prädikatenlogik)
EF1.3
Welche Aktions-Typen werden für Prozessregeln benötigt? - Datenbank-Aktualisierungen - allgemeine eingebaute Aktionen - API-Aufrufe
EF1.4
Wie komplex sind die einzelnen Regeln: einige wenige oder duzende von Kriterien in einer Bedingung?
EF1.5
Werden unsichere Regeln benötigt, d.h. Regeln, welche Aussagen mit einer gewissen Wahrscheinlichkeit versehen?
EF1.6
Werden fuzzy Regeln benötigt, d.h. Regeln, welche stufenlose Wahrheiten (z.B. Halbwahrheiten) repräsentieren?
EF1.7
Müssen Regeln beliebig tief verkettet werden können (via Fakttypen und/oder via Aktionen)?
300
D Muster & Checklisten
Id EF1.8
Anforderung Müssen sich Regeln priorisieren lassen, damit allfällige Widersprüche zwischen Regeln aufgelöst werden können?
EF1.9
Müssen Regeln zu Gruppen strukturiert, d.h. modularisiert werden können?
EF2
Regel-Ausführung
EF2.1
Ist Vorwärts-Inferenz notwendig?
EF2.2
Ist Rückwärts-Inferenz notwendig?
EF2.3
Müssen bei der Ausführung der Regeln Fakten interaktiv vom Benutzer nachgefragt werden?
EF2.4
Müssen bei der Ausführung der Regeln Fakten von Datenbanken
EF2.5
Müssen bei der Ausführung von Regeln ganze Rule Sets aktiviert oder
EF2.6
Ist eine eingebaute Erklärungskomponente notwendig (Wie bzw.
EF2.7
Ist eine Mehrsprachigkeit für die Erklärungskomponente erforderlich,
nachgeladen werden? deaktiviert werden können? Warum Erklärungen) d.h. sind die in den Erklärungen angezeigten Fakten und Regeln in verschiedenen Landesprachen darzustellen? EF2.8
Ist eine Mandantenfähigkeit erforderlich, d.h. müssen beispielsweise dieselben Fakten je nach Mandant unterschiedlich abgeleitet werden?
EF3 EF3.1
Autorisierung Muss der Aufruf der Business Rule Engine autorisiert, d.h. nur für ausgewählte Benutzer zugelassen werden?
EF3.2
Dürfen gewissen Fakten nur bei entsprechend autorisierten Benutzern in die Entscheidungsfindung einfließen?
EF3.3
Dürfen gewisse Regeln oder ganze Regelungen nur bei entsprechend autorisierten Benutzern zu Anwendung kommen?
EF4 EF4.1
Reporting Monitoring: Muss der aktuelle Zustand der Business Rules Engine sowie Betriebsstatistiken im laufenden Betrieb abgefragt werden?
EF4.2
Logging: Müssen die zur Anwendung gelangten Regeln sowie andere Ereignisse protokolliert und vielfältig ausgewertet werden können?
EF4.3
Müssen die aktiven, d..h. zur Zeit tatsächlich in Produktion befindlichen Regeln abgefragt werden können?
ENF ENF1 ENF1.1 ENF1.2
Nicht-funktionale Anforderungen Mengengerüst Wie häufig werden Services der Business Rules Engine aufgerufen? Wie hoch ist das Datenvolumen, welches durchschnittlich bei einem Aufruf der Business Rules Engine zu berücksichtigen ist?
ENF1.3
Wie hoch ist die Anzahl der Regeln?
D.5 Anforderungen an Regel-Technologie
301
Id ENF1.4
Anforderung Wie viele parallele Verbindungen (Sessions) mit der Business Rules Engine sind zu erwarten (d.h. wie viele Benutzer arbeiten gleichzeitig) mit der Business Rules Engine?
ENF2
Performance
ENF2.1
Welche Antwortzeit ist von der Business Rules Engine gefordert?
ENF2.2
Ist eine Hochverfügbarkeit (7 x 24 Betrieb) gefordert?
ENF3 ENF3.1
Integration & Standards Welche Aufrufstandards werden von der Business Rules Engine unterstützt (z.B. JSR-94)?
ENF3.2
Verwendet die Business Rules Engine ein standardisiertes Regelformat (z.B. RuleML)?
ENF3.3
Über welche (standardisierten) Schnittstellen soll die Business Rules Engine auf Datenbanken (Fakten) zugreifen?
ENF3.4
Ist eine Integration mit einem Workflow Management System erforderlich?
Tabelle D.2 zeigt eine Checkliste möglicher generischer Anforderungen an Rule Management Technologie: Tabelle D.2 Rule Management Anforderungen
Id
Anforderung
MF
Funktionale Anforderungen
MF1
Wird die gesamte bei der Ausführung benötigte Regel-Semantik unterstützt (siehe EF1 in Tabelle D.1)?
MF2 MF2.1
Faktenmodell Kann ein Faktenmodell als Grundlage für die Formulierung von Regeln erstellt werden?
MF2.2
Können Definitionen für Objekt- und Fakttypen erfasst und aufeinander aufgebaut werden?
MF2.3
Kann das Faktenmodell graphisch dargestellt werden (z.B. in der UML- oder ORM-Notation)?
MF3
Regel-Repräsentation
MF3.1
Werden Regeln in strukturierter natürlicher Sprache unterstützt?
MF3.2
Werden Entscheidungstabellen unterstützt?
MF3.3
Werden Entscheidungsbäume unterstützt?
MF3.4
Werden komplexe Berechnungen unterstützt?
MF3.5 MF4 MF4.1
Werden andere Regel-Repräsentationen unterstützt? Regel-Verwaltung Wird die Versionierung von Regeln oder ganzen Regelungen unterstützt?
MF4.2
Müssen Regeln mit einem Gültigkeitsdatum (von, bis) versehen werden können?
302
D Muster & Checklisten
Id MF4.3
Anforderung Ist eine Mandantenfähigkeit erforderlich, d.h. müssen beispielsweise Regeln oder Regelungen von Mandanten gemeinsam genutzt werden, gleichzeitig aber auch kleinere Unterschiede aufweisen können?
MF4.4
Sind Mittel für die Validierung von Regeln und Regelungen vorhanden (Testdaten, Regressionstests, Debugging, etc.)?
MF4.5
Sind Mittel für die formale Verifikation von Regeln und Regelungen vorhanden (Prüfung auf Vollständigkeit und Widerspruchsfreiheit)?
MF4.6
Können Regel-Templates sowie Regel- Parametrisierungen für verschiedene Benutzergruppen definiert werden?
MF4.7
Kann der Zugriff auf die Regeln und Regelungen mit einer Autorisierung versehen werden (lesender/schreibender/ausführender Zugriff)?
MF4.8
Besteht eine technische Unterstützung zur Entgegennahme und Ablage von Feedback zur Regel-Anwendung im operationellen Betrieb?
MF5 MF5.1
Reporting Müssen Regeln flexibel und nach verschiedenen Kriterien gesucht und betrachtet werden können (Browsing)?
MF5.2
Muss ein automatischer Verwendungsnachweis für Fakttypen erbracht werden können?
MF5.3
Muss eine automatische Impact-Analyse für Fakttypen erbracht werden können?
MF5.4
Müssen frei konfigurierbare Reports über die Regelbasis erstellt werden können?
MF6 MF6.1
Regel-Inkraftsetzung Können Regeln und Regelungen im Inter- bzw. Intranet publiziert werden?
MF6.2
Können einzelne Regelungen aktiviert/deaktiviert, d.h. gezielt in den operationellen Betrieb überführt bzw. aus diesem entfernt werden?
MF6.3
Kann die Inkraftsetzung bzw. Außerkraftsetzung von Regeln und Regelungen zeitgesteuert erfolgen (z.B. per Gültigkeitsdatum)
MF6.4
Kann der Deployment-Prozess konfiguriert, d.h. flexibel automatisiert werden?
MNF MNF1 MNF1.1
Nicht-funktionale Anforderungen Mehrsprachigkeit Kann dieselbe Regel gleichzeitig in mehreren Sprachen erfasst bzw. dargestellt werden?
MNF1.2
Kann derselbe Fakttyp gleichzeitig in mehreren Sprachen erfasst bzw. dargestellt werden?
MNF1.3
Kann die Regel- oder Faktensprache jederzeit gewechselt werden („Hot Change“)?
MNF2 MNF2.1
Mehrbenutzerbetrieb Wird gleichzeitiges Ändern von Regeln oder Regelungen verhindert (pessimistisches Locking)?
D.5 Anforderungen an Regel-Technologie
303
Id MNF2.2
Anforderung Wird gleichzeitiges Ändern von Regeln oder Regelungen festgestellt und gemeldet (optimistisches Locking)?
MNF2.3
Wird automatisch ein Änderungsnachweis (wer/wann/was/warum) geführt (Change Tracking)?
MNF3
Wie bequem lässt sich das Werkzeug bedienen (Useability)?
MNF4
Integration
MNF4.1
Kann das Faktenmodell aus einem externen Werkzeug übernommen werden (z.B. via XMI aus einem UML CASE Tool)?
MNF4.2
Besteht eine Integrationsmöglichkeit mit einem Business Process Modelling Werkzeug?
MNF4.3
Können Regeln aus einem Rule Discovery Werkzeug übernommen/importiert werden?
MNF4.4
Können Regeln in verschiedene Rule Execution Technologie exportiert werden? Wenn ja, welche?
MNF4.5
Können für die Validierung Testdaten (Fakten) aus operationellen Datenbanken übernommen werden?
MNF4.6
Kann das Rule Management Werkzeug über eine API (Application Programming Interface) „ferngesteuert“ werden?
MNF5 MNF5.1
Standards Verwendet die Business Rules Engine ein standardisiertes Regelformat (z.B. RuleML)?
MNF5.2
Über welche (standardisierten) Schnittstellen soll die Business Rules Engine auf Datenbanken (Fakten) zugreifen?
Tabelle D.3 zeigt eine Checkliste möglicher generischer Anforderungen an Rule Discovery Technologie: Tabelle D.3 Rule Discovery Anforderungen
Id
Anforderung
DF
Funktionale Anforderungen
DF1 DF1.1
Datenquellen Können Regeln aus Programmcode extrahiert werden (Reverse Engineering)?
DF1.1.1
Können Zusammenhänge aus Datenstrukturen (z.B. Datenbanken, Copy-Strecken, etc.) extrahiert werden?
DF1.1.2
Können Zusammenhänge aus Programmstrukturen extrahiert werden? Welche Programmiersprachen werden unterstützt?
DF1.2 DF1.1.1
Müssen Regeln aus Datenbeständen extrahiert werden (Data Mining)? Können Zusammenhänge aus großen historischen Datenbanken extrahiert werden?
DF1.1.2
Können Zusammenhänge aus allgemeinen unstrukturierten Dokumenten extrahiert werden?
DF2
304
Funktionalität
D Muster & Checklisten
Id DF2.1
Anforderung Welche Zusammenhänge lassen sich extrahieren? - Clustering, d.h. Gruppierung von gleichartigen Konzepten - Entscheidungsbäume oder Entscheidungstabellen - allgemeine Regeln der Aussage- oder Prädikatenlogik - statistische Daten wie Häufigkeiten und Wahrscheinlichkeiten
DF2.2
Welche Data Mining Algorithmen werden unterstützt? - Warenkorb-Analyse - Neuronale Netzwerke - Regel-Induktion, z.B. ID3)
DF2.3
Müssen die gefundenen Zusammenhänge und Regeln interaktiv verfeinert werden können?
DNF
Nicht-funktionale Anforderungen
DNF1
Können auch sehr große Datenmengen (Quellcode oder Datenbanken) verarbeitet werden?
DNF2 DNF2.1
Integration Können Regeln in verschiedene Rule Execution Technologie exportiert werden? Wenn ja, welche?
DNF2.2
Kann das Rule Discovery Werkzeug über eine API (Application Programming Interface) „ferngesteuert“ werden?
DNF3 DNF3.1
Standards Über welche (standardisierten) Schnittstellen kann auf Datenbanken zugegriffen werden?
DNF3.2
Wird ein standardisiertes Regelformat verwendet (z.B. PMML oder RuleML)?
DNF4
Wie bequem lässt sich das Werkzeug bedienen (Useability)?
Schließlich ist in Tabelle D.4 eine Checkliste zusammengestellt, welche die allgemeinen generischen Anforderungen an Business Rules Technologie aufzeigt: Id
Anforderung
A1
Plattform
A1.1
Welche Plattformen werden für die Client-Seite (Benutzungsschnitt-
Tabelle D.4 Allgemeine Anforderungen
stelle) unterstützt? A1.2
Welche Plattformen werden für die Server-Seite (Datenhaltung und Funktionalität) unterstützt?
A1.3
Befindet sich das Produkt bereits bei uns im Hause (kann ein positives Argument zur Reduktion der Trainings- Wartungs-, Support- und Lizenz-Aufwände sein)?
A2 A2.1
Lieferant Wie groß ist der Lieferant (Umsatz, Niederlassungen, Mitarbeiter im Bereich BRT)?
D.5 Anforderungen an Regel-Technologie
305
Id A2.2
Anforderung Wie groß ist der Marktanteil des Lieferanten im Bereich BRT?
A2.3
Wie lange existiert der Lieferant bereits, wie lange das BRT-Produkt?
A2.4
Welcher Support bietet der Lieferant an (Schulung, Hotline, Consulting, Implementation, etc.)?
A2.5
Welche Reaktionszeit für Support-Leistung ist gefordert?
A2.6
Arbeitet der Lieferant mit Partnern/Integratoren zusammen, welche Professional Services zum BRT-Produkt anbieten?
A2.7
Wie hoch sind die Kosten des BRT-Produkts (einmalig, wiederkehrend, Support)?
A2.8
Welche Lizenz-Pakete bietet der Lieferant an (Pilot-Lizenz, an CPU gebunden, an Transaktionsvolumen gebunden, Site-Lizenz, etc.)?
306
D Muster & Checklisten
E
Meta Modelle
E.1 Business Motivation Model definiert durch
Zweck
Abb. E.1 Das Business Motivation Model
Mittel
erfüllt
Mission besteht aus
realisiert
Vision
ermöglicht
besteht aus
Handlungsweise
Ziel unterstützt konkretisiert
bezüglich
konkretisiert qual. Ziel
formuliert auf Basis Strategie
Taktik
Stärke Schwäche
quantifiziert
implementiert quant. Ziel Durchsetzung von
Chance
beeinflusst
Gefahr
Geschäftsaktivität
beeinflusst leitet Geschäftsregel
motiviert durch
Direktive
Einschätzung
Formalität verantwortlich für
konkretisiert
Formalität
motiviert durch
betrifft identifiziert Regelung
definiert durch
mögliche Auswirkung
Teil von gemacht durch Organisationseinheit
Teil von
Nutzen
Risiko
beurteilt
externer Einfluss
Einfluss
spielt Rolle von
Vorschrift interner Einfluss Kunde Konkurrent Infrastruktur
© Copyright 2005, The Business Rules Group
Lieferant Ressource Partner Annahme Technologie Streitpunkt Umwelt Gewohnheit expliziter Unternehmenswert Unternehmenswert impliziter Unternehmenswert Managementvorrecht
E Meta Modelle
307
Das „Business Motivation Model“ zeigt, wie Geschäftsregeln aus der Unternehmensvision sowie externen und internen Einflüssen abgeleitet werden. Das Modell „endet“ aber bei der Geschäftsregel, d.h. sagt nichts Genaueres darüber aus.
E.2 Geschäftsregeln Das folgende Meta Modell zeigt „alles von der Geschäftsregel abwärts“, allerdings lediglich von der fachlichen Seite. Somit stellt es die logische Ergänzung zum „Business Motivation Model“. Wissenselement
Konzept
Abb. E.2 Geschäftsregeln Objekttyp
Mittel
unterstützt
Modellregel
Fakttyp
Ziel
macht Aussage über
Verbot Werttyp
Erlaubnis Vorschrift
externer Einfluss
spielt Rolle von
Direktive
Verpflichtung Verwendung
Teil von
Formalität
konkretisiert
Regelung
betrifft
motiviert durch
Geschäftsregel
Einschätzung motiviert durch
leitet
Ableitung Teil von
mögliche Auswirkung
Voraussetzung für
Einschränkung Geschäftsaktivität
kontrolliert
Durchsetzung von
Prozessregel
Geschäftsprozess realisiert
Taktik formuliert auf Basis
verwendet löst aus
beeinflusst ausgelöst durch
Geschäftsobjekt
Geschäftsereignis
verantwortlich für
Organisationseinheit
Handlungsweise
Für ein technisches Meta Modell zu Geschäftsregeln sei hier lediglich auf den kommenden Standard „Production Rule Representation“ der Object Management Group OMG verwiesen (siehe auch Anhang H.1).
308
E Meta Modelle
F
Begriffsdefinitionen
In diesem Anhang sind die wichtigsten Begriffe des Business Rules Ansatzes definiert. Bei den englischen Originalbegriffen ist angegeben, wenn sie sich auf die Standards BMM [BRG05] und SBVR [OMG05] beziehen. Abgeleiteter Fakttyp Ein ÖFakttyp, der Information repräsentiert, die ein Unternehmen selber aus anderen Informationen herleiten kann. Diese Herleitung erfolgt durch explizite ÖAbleitungen. Englisch: Derived Fact Type Beispiel(e): „Bestellung hat Rabatt Prozent“ Eine ÖGeschäftsregel, die neue Information aufgrund bekannter Information herleitet. Eine Ableitung besagt, wie die neue Information aus anderen Informationen (Ödeklarierten oder Öabgeleiteten Fakttypen) bestimmt wird. Synonym(e): Ableitungsregel Englisch: Derivation
Ableitung
Ein Öinterner Einfluss, der sich auf etwas bezieht, das als erwiesen angenommen wird, ohne dass ein Beweis vorhanden ist. Englisch: Assumption (BMM) Beispiel(e): „Das Umsatzwachstum ist 20% pro Jahr“
Annahme
Eine ÖEinschätzung einer Situation, die das Unternehmen zu seinem Vorteil nutzen kann. Englisch: Opportunity (BMM) Beispiel(e): „Die Konzentration der Konkurrenz auf eigene Marken ist eine Chance für unsere MarkenDiversifikation“
Chance
F Begriffsdefinitionen
309
Deklarierter Fakttyp Ein ÖFakttyp, den ein Unternehmen als Tatsache mitbekommt und daher weiß. Da es sich dabei um eine durch das Unternehmen festgestellte Tatsache handelt, muss sie auch nicht weiter erklärt werden. Englisch: Declared Fact Type Beispiel(e): „Bestellung gehört zu Kunde“ Direktive
Englisch: Einfluss Englisch: Einschätzung Englisch:
Ein ÖMittel, welches dasjenige Wissen repräsentiert, das bei der Anusführung einer ÖHandlungsweise (d.h. einer ÖStrategie oder ÖTaktik) zur Anwendung kommen muss, damit sie erfolgreich umgesetzt werden kann. Directive (BMM) Etwas, das im Unternehmen ohne Auftrag oder spürbare Kraft einen Effekt bewirkt. Influencer (BMM) Eine Beurteilung eines ÖEinflusses auf den ÖZweck oder die ÖMittel eines Unternehmens. Assessment (BMM)
Einschränkung Eine ÖGeschäftsregel, die eine Aussage über das Geschäft macht, welche immer wahr sein muss. Englisch: Constraint Erlaubnis
Englisch:
Eine ÖDirektive, die klarstellt was getan werden darf, obwohl es vielleicht nicht offensichtlich ist. Permission (SBVR)
Expliziter Unternehmenswert Ein ÖUnternehmenswert, der explizit gemacht wurde. Englisch: Explicit Corporate Value (BMM) Beispiel(e): „Unser Unternehmen ist schützt die Umwelt“ Externer Einfluss Ein ÖEinfluss, der sich außerhalb des Unternehmens befindet, aber dessen ÖZweck und ÖMittel beeinflusst. Englisch: External Influencer (BMM) Fakttyp
Englisch:
310
Ein ÖKonzept, welches eine mögliche, für das Unternehmen relevante elementare Aussage über ein oder mehrere ÖObjekttypen darstellt. Fact Type (SBVR)
F Begriffsdefinitionen
Gefahr
Eine ÖEinschätzung einer Situation, die eine potentielle Bedrohung für das Unternehmen darstellt. Synonym(e): Bedrohung Englisch: Threat (BMM) Beispiel(e): „Die Kunden im Ausland sind sehr preisbewusst, weshalb wir mit tieferen Margen rechnen müssen“
Geschäftsaktivität Eine Aktivität oder Tätigkeit, die ausgeführt werden muss, um ein fachliches ÖZiel zu erreichen Synonym(e): Aufgabe Englisch: Business Process (BMM) Beispiel(e): „Bestellung entgegen nehmen“, „Rechnung stellen“ Geschäftsereignis Ein Ereignis, welches die Ausführung einer ÖGeschäftsaktivität auslöst. Englisch: Business Event Beispiel(e): „Liefertermin“, „Jahresende“ Geschäftsobjekt Ein ÖObjekttyp, der ein fachlich wichtiges ÖKonzept aus der Geschäftswelt repräsentiert. Englisch: Business Object Beispiel(e): „Kunde“, „Artikel“ Geschäftsregel Eine konkrete ÖVorschrift oder ein konkretes ÖVerbot, welches bei der Ausführung einer ÖGeschäftsaktivität beachtet werden muss. Englisch: Business Rule (BMM) Gewohnheit
Ein Öinterner Einfluss, der eine im Unternehmen übliche Praxis repräsentiert. Englisch: Habit (BMM) Beispiel(e): „Beförderungen erfolgen typischerweise alle zwei Jahre“
Handlungsweise Ein ÖMittel, das einen Ansatz oder Plan zur Beeinflussung einer Dimension eines Unternehmens (Dinge, Aufgaben, Orte, Ressourcen, Ereignisse oder Motive) repräsentiert, um ein spezifisches ÖZiel zu erreichen. Englisch: Course of Action (BMM)
F Begriffsdefinitionen
311
Impliziter Unternehmenswert Ein ÖUnternehmenswert, der nicht explizit deklariert wurde, aber von einigen oder allen Personen im Unternehmen verstanden wird. Englisch: Implicit Corporate Value (BMM) Beispiel(e): „Mitarbeiter unterstützen einander“ Ein Öinterner Einfluss, der sich auf die dem Unternehmen zur Verfügung stehende Infrastruktur bezieht. Dazu zählen sowohl technischer Element wie IT-Systeme, Maschinen, Gebäude etc. als auch logistische Elemente wie zur Verfügung stehende interne und externe Dienstleistungen. Englisch: Infrastructure (BMM) Beispiel(e): „Die dem Unternehmen zur Verfügung stehenden Niederlassungen“
Infrastruktur
Interner Einfluss Ein ÖEinfluss innerhalb des Unternehmens, der dessen ÖZweck und ÖMittel beeinflusst. Englisch: Internal Influencer (BMM) Konkurrent
Englisch: Konzept Englisch: Kunde
Englisch: Lieferant
Englisch:
312
Ein Öexterner Einfluss, der sich auf einen Mitbewerber auf dem Markt bezieht, der versucht, sich gegenüber dem eigenen Unternehmen einen Vorteil zu verschaffen oder bereits einen solchen innehat. Competitor (BMM) Ein ÖWissenselement, welches eine spezifische Kombination von Eigenschaften aufweist. Concept (SBVR) Ein Öexterner Einfluss, der sich auf ein Individuum oder ein Unternehmen bezieht, das sich für Produkte und/oder Dienstleistungen des eigenen Unternehmens interessiert, solche bestellt, erhalten oder bezahlt hat. Customer (BMM) Ein Öexterner Einfluss, der sich auf ein Individuum oder ein Unternehmen bezieht, welches das eigene Unternehmen mit Waren und/oder Dienstleistungen beliefert. Supplier (BMM)
F Begriffsdefinitionen
Managementvorrecht Ein Öinterner Einfluss, der ein Recht oder ein Privileg repräsentiert, welches jemandem aufgrund von Besitzverhältnissen oder seiner Position im Unternehmen zusteht. Englisch: Management Prerogative (BMM) Beispiel(e): „Das Management muss keine Spesenabrechnung erstellen“ Ein ÖMittel, das eine langfristige operationelle Aktivität eines Unternehmens darstellt, um eine ÖVision zu erfüllen. Sie beschreibt die Hauptfunktion des Unternehmens und wird durch eine Menge von ÖStrategien konkretisiert. Englisch: Mission (BMM) Beispiel(e): „KnowBeer verkauft verschiedenste Biersorten sowie Bier-bezogene Dienstleistungen an Restaurants in allen Ländern Europas“
Mission
Mittel
Englisch:
Eine Vorrichtung, Fähigkeit, Regime, Verfahren, Einschränkung, Agentur, Instrument oder eine Methode, die aufgerufen, aktiviert oder durchgesetzt werden kann, um einen ÖZweck zu erreichen. Means (BMM)
Ein ÖWissenselement, das eine Regel darstellt, die einen bestimmten Aspekt eines Geschäfts beschreibt, ohne dass sie ihn selber beeinflusst. Englisch: Model Rule Beispiel(e): „92% der Kunden, die Produkt X gekauft haben, kaufen auch Produkt Y“
Modellregel
Mögliche Auswirkung Eine Beurteilung, die eine ÖEinschätzung qualifiziert oder quantifiziert. Englisch: Potential Impact (BMM) Eine Ömögliche Auswirkung, die einen Gewinn für das Unternehmen repräsentiert, ggf. zusammen mit einer Eintretenswahrscheinlichkeit. Englisch: Potential Reward (BMM) Beispiel(e): „Durch langfristige Verträge mit CargoLieferanten können wir gegenüber dem Direktversand mehr als 20% Kosten einsparen“
Nutzen
F Begriffsdefinitionen
313
Ein allgemeines (z.B. „Kunde“) oder individuelles (z.B. „Hr. Meier“) ÖKonzept, das für das Unternehmen in irgendeiner Weise wichtig ist. Englisch: Object Type (SBVR) Beispiel(e): „Kunde“, „Hr. Meier“, „Prozent“, „Datum“
Objekttyp
Organisationseinheit Die für die Ausführung einer ÖGeschäftsaktivität verantwortliche Instanz. Englisch: Organization Unit (BMM) Beispiel(e): Abteilungen, Gruppen, einzelne Stellen, sehr selten individuelle Personen Partner
Englisch: Prozessregel
Englisch:
Ein Öexterner Einfluss, der dich auf ein Unternehmen bezieht, welches mit dem eigenen Unternehmen Risiko, aber auch Gewinn teilt, weil dies für beide Beteiligten vorteilhaft ist. Partner (BMM) Eine ÖGeschäftsregel die besagt, dass in gewissen Situationen gewisse ÖGeschäftsaktionen ausgeführt werden müssen, dürfen oder aber nicht ausgeführt werden dürfen. Process Rule
Qualitatives Ziel Ein ÖZiel, welches von einem Unternehmen langfristig erreicht werden soll und damit einen einzelnen Aspekt der ÖVision konkretisiert. Englisch: Goal (BMM) Beispiel(e): „Wir möchten Marktleader in unserem Produktsegment sein“ Quantitatives Ziel Ein ÖZiel, welches sich innerhalb eines definierten Zeitraums überprüfen lässt. Ein quantitatives Ziel kann ein Öqualitatives Ziel quantifizieren, d.h. es kann dadurch überprüfbar gemacht werden. Englisch: Objective (BMM) Beispiel(e): „Wir steigern unseren Umsatz um 50% innerhalb der nächsten 2 Jahre“
314
F Begriffsdefinitionen
Eine ÖDirektive, welche die Art und Weise vorschreibt, wie gewisse ÖGeschäftsaktivitäten auszuführen sind, um positive Auswirkungen auf das Unternehmen zu maximieren und negative Auswirkungen zu minimieren. Englisch: Business Policy (BMM) Beispiel(e): (sie Kapitel 12 und 13)
Regelung
Ein Öinterner Einfluss, der sich auf die dem Unternehmen zur Verfügung stehende Einsatzmittel wie Mitarbeiter, Partner, Know-how, Materialien oder Finanzen bezieht. Englisch: Resource (BMM) Beispiel(e): „Unsere Mitarbeiter sind schlecht ausgebildet“
Ressource
Eine Ömögliche Auswirkung, die einen möglichen Verlust, eine Verletzung, einen Nachteil oder einen Schaden repräsentiert, ggf. zusammen mit einer Eintretenswahrscheinlichkeit. Englisch: Risk (BMM) Beispiel(e): „Unsere gegenwärtige Fluktuationsrate von gegen 20% führt dazu, dass rund 5% unserer Kunden unzufrieden mit der Konstanz und Konsistenz der Kundenbeziehung sind“
Risiko
Eine ÖEinschätzung einer Unzulänglichkeit des Unternehmens, die sich negativ auf die Erreichung seiner ÖZiele auswirkt. Englisch: Weakness (BMM) Beispiel(e): „Unsere hohe Fluktuationsrate beeinflusst die Qualität der Kundenbeziehung“
Schwäche
Eine ÖHandlungsweise, mit der eine konkreten Umsetzung einer ÖMission, mit der die Erreichung eines oder mehrerer ÖZiele angestrebt wird. Englisch: Strategy (BMM) Beispiel(e): „Wir schließen mit Brauereien aus der ganzen Welt Verträge ab, um unsere Produkte zu beziehen“
Strategie
F Begriffsdefinitionen
315
Eine ÖEinschätzung eines Vorteils oder einer speziellen Fähigkeit des Unternehmens, die sich positiv auf die Erreichung seiner ÖZiele auswirkt. Englisch: Strength (BMM) Beispiel(e): „Mit unserer Fokussierung auf Spezialbiere sprechen wir viele potentielle Restaurants an“
Stärke
Ein Öinterner Einfluss, der sich auf einen aktuellen Diskussionspunkt oder ein Thema bezieht, zu dem unterschiedliche Ansichten im Unternehmen bestehen. Englisch: Issue (BMM) Beispiel(e): „Ob die Auslandexpansion von KnwoBeer der richtige Schritt ist“
Streitpunkt
SWOT-Analyse Ein Werkzeug des strategischen Managements das sowohl eine innerbetriebliche StärkenSchwächen-Analyse als auch eine externe Chancen-Risiko-Analyse betrachtet, um im Hinblick auf die zu erreichenden ÖZiele eine ganzheitliche ÖStrategie für die weitere Entwicklung des Geschäfts ableiten zu können. Englisch: SWOT Analysis Eine ÖHandlungsweise, mit der eine Implementierung einer ÖStrategie angestrebt wird, die auf die Erreichung eines oder mehrerer Öquantitativer Ziele ausgerichtet ist. Englisch: Tactic (BMM) Beispiel(e): „Wir beobachten aktiv den weltweiten Biermarkt bezüglich Neuerscheinungen“
Taktik
Ein Öexterner Einfluss, der sich auf neue technologische Entwicklungen aber auch technologische Einschränkungen bezieht, die der Betrieb des Unternehmens voraussetzt oder diesen ermöglicht. Englisch: Technology (BMM) Beispiel(e): „Das Internet als Verkaufskanal“
Technologie
316
F Begriffsdefinitionen
Ein Öexterner Einfluss, der sich auf die Gesamtheit aller äußeren Bedingungen oder Einflüsse bezieht, welche auf die Existenz oder die Entwicklung des eigenen Unternehmens wirken. Englisch: Environment (BMM) Beispiel(e): „Die Mietkosten im Stadtzentrum sind sehr hoch“
Umwelt
Unternehmenswert Ein Öinterner Einfluss, der ein Ideal oder eine Wertvorstellung repräsentiert, zu welchem sich das Unternehmen explizit bekennt oder das eine implizite Gewohnheit des Unternehmens darstellt. Englisch: Corporate Value (BMM) Verbot Englisch:
Eine ÖDirektive, die gewisse Tätigkeiten oder Situationen verbietet. Prohibition (SBVR)
Verpflichtung Eine ÖDirektive, die vorschreibt, was in welchen Situationen (obligatorisch) zu tun ist. Englisch: Obligation (SBVR) Ein ÖZweck, der eine Aussage, wie das Unternehmen in Zukunft aussehen soll repräsentiert, und beschreibt, welche Leistungen es für welche Anspruchsgruppen auf welche Art und Weise erbringen wird. Sie beschreibt einen ultimativen, zukünftigen Zustand des Unternehmens ohne Hinweis, wie dieser Zustand zu erreichen ist. Englisch: Vision (BMM) Beispiel(e): „KnowBeer ist ein finanziell erfolgreicher und Europa-weit bevorzugter Lieferant von Spezialbieren für Restaurants jeglicher Größe“
Vision
Ein Öexterner Einfluss, der sich auf eine Anordnung bezieht, die von einer Autorität wie einer Behörden oder der Geschäftsleitung dem eigenen Unternehmen vorgeschrieben wird. Englisch: Regulation (BMM) Beispiel(e): „Mehrwertsteuergesetz“, „Basel II“, „Sarbanes Oxley Act“
Vorschrift
F Begriffsdefinitionen
317
Ein ÖKonzept, dessen Bedeutung per Definition identisch mit seinem Namen ist und das sich daher nicht verändern lässt. Englisch: Knowledge Element Beispiel(e): Zahl, Name, Datum
Werttyp
Wissenselement Ein Bestandteil des für ein Unternehmen wichtigen Wissens. Dazu gehören ÖKonzepte, ÖDirektiven und ÖModellregeln. Englisch: Knowledge Element Ziel
Englisch: Zweck Englisch:
318
Ein gewünschter Zustand, den ein Unternehmen erreichen und/oder beibehalten möchte. Ziele lassen sich hierarchisch strukturieren, d.h. ein Ziel kann in Unterziele aufgeteilt werden, wodurch eine Zielhierarchie gebildet wird. Desired Result (BMM) Etwas, das erreicht werden soll. End (BMM)
F Begriffsdefinitionen
G
Business Rules Technologie
In diesem Anhang sind sowohl die wichtigsten kommerziellen als auch die kostenlosen Werkzeuge rund um den Business Rules Ansatz in alphabetischer Reihenfolge zusammengestellt. Da der Markt sich stark in Bewegung befindet, erheben wir keinen Anspruch auf Vollständigkeit der Liste.
G.1 Rule Discovery Werkzeuge Hersteller: Produkt: Web Site: Kurzbeschreibung:
ASG Software Solutions ASG-Alliance http://www.asg.com Bietet verschiedene Analysen der Datenstrukturen in existierendem Programmcode, um dessen Funktionsweise besser zu verstehen.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Cognos Scenario http://www.cognos.com Ein relativ einfaches Data Mining Werkzeug, das ohne Expertenwissen verwendet werden kann. Auf der Basis von Entscheidungsbäumen können Klassifikationen, Segmentierungen und Faktorenanalysen durchgeführt werden.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Computer Associates CleverPath Predictive Analysis Server http://www.ca.com Ein Data Mining Werkzeug, das verschiedene Data Mining Strategien (neurale Netze, Clustering, Entscheidungsbäume, etc.) unterstützt. Die generierten Regeln lassen sich in CleverPath Aion Business Rules Expert importieren.
G Business Rules Technologie
319
320
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Fair Isaac Model Builder for Decision Trees http://www.fairisaac.com Ein Data Mining Werkzeug, das statistische Datenextraktion und flexible Datenanalyse auf der Basis von Entscheidungs-, Klassifikations- und Regressionsbäumen oder die automatische Segmentierung unterstützt. Die resultierenden Modelle lassen sich in die Business Rule Engine Blaze Advisor exportieren, wo sie sich zusammen mit dessen Regeln kombinieren lassen.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
KnowGravity Inc. CASSANDRA/BMM http://www.knowgravity.com Ein einfaches Hilfsmittel, welches eine strukturierte Erfassung des Business Motivation Models (BMM) erlaubt. Das BMM von KnowBeer ist als Beispiel unter http://www.knowbeer.com zu finden.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Logic Programming Associates Ltd DataMite http://www.lpa.co.uk Eine Prolog-Bibliothek auf Windows Basis, die via API verschiedene Data Mining Funktionen zur Verfügung stellt. Diese können zu einer dedizierten Applikation kombiniert werden. Dieses Produkt lässt sich mit den Produkten CBR Toolkit, Flex und VisiRule derselben Firma zu komplexen wissensbasierten Systemen kombinieren.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Oracle Oracle 10g Data Mining http://www.oracle.com Ein Data Mining Werkzeug, das als Erweiterung der Datenbank Oracle 10g angeboten wird. Bietet Funktionen wie Klassifikation, Selektivitäts-Analyse, Clustering, Warenkorbanalyse oder Scoring sowie ein Java-API zur Integration in dedizierte Lösungen, ist jedoch nicht als eigenständige Applikation verwendbar.
G Business Rules Technologie
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Refactive Refactive Re-engineering Toolset http://www.refactive.com Bietet umfassende Services zur Extraktion von Geschäftsregeln aus bestehendem Programmcode auf der Basis eigener Reverse Engineering Technologie.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
SAS Enterprise Miner http://www.sas.com Eines der umfassendsten Data Mining Werkzeuge auf dem Markt. Es bietet vielfältigste Funktionen zur Datenanalyse und dies sowohl in Form einer interaktiven Oberfläche als auch via ein Java-API zur Integration in dedizierte Lösungen.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Transoft evolveIT http://www.transoft.com Ein Analyseprogramm, welches fachliche Zusammenhänge in COBOL-Applikationen sichtbar und navigierbar macht. Zudem lassen sich damit automatisch für Fachvertreter verständliche Dokumentationen generieren.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Trinity Millenium Group, Inc TMGi-BRH/TGMi-SAT http://www.tringroup.com Extrahiert und klassifiziert Geschäftsregeln aus den Analyseergebnissen bestehenden Programmcodes und kann diese Regeln wieder in ein für eine Business Rule Engine lesbares Format transformieren.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
University of Waikato WEKA http://www.cs.waikato.ac.nz/~ml/weka/ Eine OpenSource Kollektion von Data Mining Algorithmen in Java, die verschiedene Algorithmen zur Bildung von Entscheidungs- oder Klassifikationsbäumen, Regel-Sets und Entscheidungstabellen anbietet.
G.1 Rule Discovery Werkzeuge
321
G.2 Rule Management Werkzeuge
322
Hersteller: Produkt: Web Site: Kurzbeschreibung:
ARTiSAN Software Tools ARTiSAN Studio http://www.artisansw.com Ein UML/SysML-basiertes, sehr weitgehend konfigurierbares CASE-Werkzeug mit verteiltem unternehmensweitem Repository. Vorkonfiguration für den Business Rules Ansatz erhältlich. Wurde bei der Erstellung dieses Buches verwendet.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Business Rules Solutions RuleTrack http://www.brsolutions.com Ein einfaches, Datenbank-basiertes Werkzeug zur Verwaltung von Geschäftsregeln. Unterstützt eine ganzheitliche Sicht ähnlich dem Zachman Framework sowie BMM und erlaubt eine Traceability von Geschäftsregeln zu ITSystemen.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
IBM Requisite Pro http://www.ibm.com Ein flexibel konfigurierbares Requirements Management Werkzeug, welches sich auch zur Verwaltung von Geschäftsregeln eignet. Erlaubt die Integration mit den UML-Werkzeugen von IBM, die für die Faktenmodellierung verwendet werden können.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
LibRT Valens http://www.librt.com Ein Werkzeug, welches auf die Validierung und formale Verifikation von Geschäftsregeln spezialisiert ist. Ist nur als Add-On zu anderen BRT-Produkten erhältlich (z.B. CA, Fair Isaac und andere)
G Business Rules Technologie
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Pulinco TopEase http://www.pulinco.com Enterprise Management System mit Schwerpunkt „Geschäftsprozessmodellierung“. Unterstützt auch die Separierung von Geschäftsregeln von den Geschäftsprozessen.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
RuleArts RuleXpress http://www.rulearts.com Ein Werkzeug zur bequemen Erfassung, Validierung, Verifikation und Visualisierung von Geschäftsregeln durch Fachanwender.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
RuleBurst RuleBurst Studio/RuleBurst Interactive http://www.ruleburst.com Erlaubt die Definition von Geschäftsregeln in strukturierter Sprache durch Fachvertreter mittels Microsoft Word. Bietet verschiedene Visualisierungen von Regeln sowie den Export in verschiedenen Regelformaten anderer Business Rule Engines.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Telelogic DOORS http://www.telelogic.com Ein flexibel konfigurierbares Requirements Management Werkzeug, welches sich auch zur Verwaltung von Geschäftsregeln eignet. Erlaubt die Integration mit verschiedenen UMLWerkzeugen, die für die Faktenmodellierung verwendet werden können.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Telelogic System Architect http://www.telelogic.com Ein weitgehend konfigurierbares „MultiMethoden“-CASE-Werkzeug mit zentralem Repository und Unterstützung des Zachman Frameworks.
G.2 Rule Management Werkzeuge
323
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Unisys RuleModeler http://www.unisys.com Ein Werkzeug zur Erfassung von Geschäftsregeln in strukturiertem Englisch, basierend auf dem SBVR-Standard [OMG05]. Bietet eine aktive Unterstützung beim Erstellen der Regeln und erlaubt die Generierung verschiedener Software-Komponenten (inkl. Datenbank) aus den Regeln (Generator-Architektur).
Hersteller: Produkt: Web Site:
University of Leuven, Belgium Prologa http://www.econ.kuleuven.be/tew/academic/ infosys/research/prologa/prologa.htm Kurzbeschreibung: Ein Werkzeug, welches die bequeme Erfassung, Optimierung, Validierung und Verifikation von Entscheidungstabellen erlaubt. Außerdem lässt sich damit aus den Tabellen Programmcode für verschiedene Programmiersprachen erzeugen. Prologa wurde in diesem Buch verwendet als Beispiel der technischen Umsetzung im Kapitel 20 verwendet.
G.3 Rule Execution Werkzeuge
324
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Computer Associates CleverPath Aion Business Rules Expert http://www.ca.com Eine Business Rule Engine, die auf IBMMainframe, Unix und Windows-Plattform lauffähig ist und vielfältige Mechanismen zur Wissensverarbeitung bietet (Vorwärts- und Rückwärts-Inferenz, Frames, Vererbung etc.). Allerdings orientiert sich die Regelsprache eher an einer Programmiersprache.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Corticon Corticon Business Rules Modeling Studio http://www.corticon.com Eine Modellierungsumgebung für Geschäftsregeln, die stark auf Fachvertreter ausgelegt ist und Regeln an den eigenen Corticon Business Rules Server exportieren kann. Bietet eine starke Unterstützung von Entscheidungstabellen.
G Business Rules Technologie
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Expert Solutions International Logist http://www.esi-knowledge.com Eine Business Rule Engine, welche auf Unix und Windows-Plattform lauffähig ist und eine ausgesprochen starke Orientierung auf Business-Leute aufweist. Zudem bietet diese Engine als eine der wenigen eine flexible und gut verständliche Erklärungskomponente.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Fair Isaac Blaze Advisor http://www.fairisaac.com Eine Business Rule Engine, die auf Unix und Windows Plattform (J2EE- und .NETUmgebung) lauffähig ist sowie Cobol-Code für IBM Mainframe-Umgebung produzieren kann. Blaze Advisor bietet vielfältige Mechanismen zur Wissensrepräsentation (textuelle Regeln, Entscheidungsbäume, Entscheidungstabellen und Score Cards) sowie eine enge Integration mit den analytischen Werkzeugen von Fair Isaac. Fair Isaac hat zudem im September 2005 „RulesPower“ mit dem sehr schnellen RETE III Algorithmus übernommen.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Haley HaleyAuthority/HaleyRules http://www.haley.com Eine Windows- und J2EE-basierte, hoch performante Business Rule Engine, welche auf strukturiertes Englisch spezialisiert ist und sowohl Vorwärts- wie auch Rückwärts-Inferenz unterstützt.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
ILOG JRules http://www.ilog.com Eine J2EE- und .NET-basierte Business Rule Engine mit hoher Leistung, umfangreicher Funktionalität sowie umfassendem Toolset, inkl. Rule Management. Unterstützt die Definition von Geschäftsregeln mittels Microsoft Word und Excel. Wird durch dedizierte Engines für Optimierungsprobleme ergänzt.
G.3 Rule Execution Werkzeuge
325
326
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Innovations Softwaretechnologie GmbH Visual Rules http://www.innovations.de Ein Werkzeug, welches sich an Fachabteilungen ausrichtet und aus komfortabel editierbaren Entscheidungsbäumen effizienten Cobol- und Java-Code erzeugt (Generator-Architektur). Unterstützt „Hot Deployment“ für Java.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Logic Programming Associates Ltd Flex & VisiRules http://www.lpa.co.uk Eine Business Rule Engine, die auf WindowsPlattform lauffähig ist und vielfältige Mechanismen zur Wissensverarbeitung bietet (Vorwärts- und Rückwärts-Inferenz, Frames, Vererbung, Fuzzy-Logik etc.). Die Regelsprache ist ein strukturiertes Englisch und wird durch ein graphisches Front End auf Basis von Entscheidungsbäumen unterstützt.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Microsoft BizTalk Server 2006 http://www.microsoft.com Ein EAI-Tool (Enterprise Application Integration), mit dem applikationsübergreifende Geschäftsprozesse integriert werden können. Dazu wurde eine einfache Business Rule Engine integriert, die es erlaubt, Entscheidungen im Ablauf eines Geschäftsprozesses zu automatisieren. In der neuesten Version lässt sich die Business Rule Engine auch einzeln verwenden.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
NESS USoft http://www.ness.com Eine Business Rule Engine, die auf Unix- und Windows-Plattform (J2EE) lauffähig ist und eine enge Integration mit einer relationalen Datenbank (Oracle, DB2 und weitere) aufweist. Die Regelsprache basiert auf SQL und wird in den produktspezifischen SQL-Dialekt transformiert, weswegen eine außerordentlich hohe Performance bei der Verarbeitung großer Datenmengen möglich wird.
G Business Rules Technologie
Hersteller: Produkt: Web Site: Kurzbeschreibung:
(Open Source) Drools http://www.drools.org Eine Java-basierte Business Rule Engine, welche Vorwärts-Inferenz unterstützt. Sie verwendet eine XML-basierte Regelsprache, die sich aus verschiedenen domänenspezifischen Sprachen (DSLs) erzeugen lässt. Die verfügbaren DSLs sind allerdings eher technisch orientiert.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
(Open Source) Mandarax http://www.mandarax.com Eine Java-basierte Business Rule Engine, welche Rückwärts-Inferenz unterstützt und sich stark an Prolog orientiert. Mandarax bietet aufgrund seiner Pull-Architektur eine gute Einbindung relationaler Datenbanken. Regeln können im RuleML-Format eingelesen werden.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
(Open Source) NxBRE http://www.nxbre.org Eine .NET-basierte Business Rule Engine, welche Vorwärts-Inferenz unterstützt. Regeln können in graphischer Form in Microsoft Visio erfasst, aber auch im RuleML-Format eingelesen werden.
Hersteller: Produkt: Web Site:
Oracle Oracle Business Rules http://www.oracle.com/technology/products/ias/ business_rules/index.html Kurzbeschreibung: Java-basierte Business Rule Engine, welche ein XML-basiertes Rule Repository bietet und gut in die Oracle-Umgebung integriert ist. Oracle Business Rules wurde von der Business Rules Engine Jess abgeleitet, was heißt, dass sie lediglich Vorwärts-Inferenz unterstützt.
G.3 Rule Execution Werkzeuge
327
328
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Pega Systems PegaRULES http://www.pega.com Eine Rule Engine, die auf Unix- und WindowsPlattform lauffähig ist und schwerpunktmäßig auf die Abwicklung von Geschäftsprozessen (Workflow-Automatisierung) spezialisiert ist. PegaRULES bietet für die Regelverarbeitung sowohl Vorwärts wie auch Rückwärts-Inferenz sowie ein auf einer relationalen Datenbank basiertes Regel-Repository.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Resolution EBS iR Engine /iR Manager http://www.resolutionebs.com Eine Business Rule Engine auf Windows-Basis mit ausgezeichneter Unterstützung von Einschränkungen auf der Ebene der Benutzungsschnittstelle sowie komfortablem eigenem Regeleditor.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
RuleBurst RuleBurst Engine/RuleBurst Rule Server http://www.ruleburst.com Eine Business Rule Engine für J2EE- und .NET-Plattformen, welche sowohl Vorwärtsals auch Rückwärts-Inferenz unterstützt. Bietet eine konfigurierbare Regelsyntax sowie eine Erklärungskomponente.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Sandia National Laboratories Jess http://herzberg.ca.sandia.gov/jess/index.shtml Eine Java-basierte Business Rule Engine, welche sowohl Vorwärts- als auch (in beschränkter Form) Rückwärts-Inferenz unterstützt. Die Regelsprache orientiert sich an der Programmiersprache Lisp und ist daher eher technisch orientiert.
G Business Rules Technologie
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Sapiens eMerge http://www.sapiens.com Eine vollständige integrierte regelbasierte Entwicklungsumgebung für transaktionsorientierte Systeme unter Unix, OS/400 und OS/390. Bietet ein zentrales Regel-Repository und eine eigene Business Rules Engine.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Transparentlogic Maestro http://www.transparentlogic.com Eine .NET-basierte Business Rule Engine, welche mit eigenem Editor für Entscheidungstabellen ausgestattet ist und graphische Darstellung von Daten- und Entscheidungsflüssen bietet.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Versata Logic Suite http://www.versata.com Eine vollständige Java-Entwicklungsumgebung welche auf der Generator-Architektur basiert, d.h. Geschäftsregeln in Programmcode transformiert. Bietet durch die Integration einer Business Rule Engine auch den dynamischen, interpretativen Ansatz für Geschäftsregeln.
Hersteller: Produkt: Web Site: Kurzbeschreibung:
Yasu Technologies QuickRules http://www.yasutech.com Eine J2EE- und .NET-basierte Business Rule Engine, die Vorwärts-Inferenz unterstützt. Bietet Entscheidungstabellen und eine textbasierte Sprache zur Formulierung von Regeln (auch über ein Web-Interface).
G.3 Rule Execution Werkzeuge
329
H
Weitere Informationen
H.1 Business Rules Standards
Die folgenden existierenden oder kommenden Standards sind im Zusammenhang mit dem Business Rules Ansatz relevant: JSR-94 Der Aufruf-Standard (API) für Business Rules Engines, der vom Java Community Process entwickelt wurde. Siehe auch [JCP03]. OMG-BMM Das „Business Motivation Model“, welches sich im RFC (Request for Comment) Prozess der OMG befindet. Siehe auch [BRG05], [OMG05a]. OMG-BSBR Die Submission „Semantics of Business Vocabulary and Business Rules (SBVR)“ des Business Rules Teams, welches sich in der FTF (Finalization Task Force) Prozess der OMG befindet. Siehe auch [OMG05]. OMG-PRR Der RFP (Request for Proposal) der OMG, welcher Standards für die technische Repräsentation von Geschäftsregeln sucht. OMG-MDA Der Architekturansatz der OMG, nach dem möglichst viel aus möglichst fachlichen Modellen generiert werden soll. Siehe auch [OMG03]. RuleML Ein immer mehr beachtetes XML-Format für eine einheitliche Formulierung verschiedener Regel-Arten.
H Weitere Informationen
331
H.2 Interessante Web-Links Auf den folgenden Internet Adressen (in alphabetischer Reihenfolge) sind interessante, nicht-kommerzielle Informationen rund um den Business Rules Ansatz zu finden. http://www.brportal.org Das erste deutschsprachige Portal zum Thema „Business Rules“. http://www.brcommunity.com Ein sehr aktives internationales Portal der „Business Rules Community“. http://www.businesrulesforum.com Die Web Site der jährlich stattfindenden amerikanischen Konferenz zum Thema „Business Rules“. http://www.businessrulesgroup.org Die Web Site der Business Rules Group, welche die ursprünglichen De Facto Standards zum Thema „Business Rules“ schuf. http://www.eurobizrules.com Die Web Site der jährlich stattfindenden amerikanischen Konferenz zum Thema „Business Rules“ http://www.iso.org Die Web Site der International Standards Organisation welche unter anderem verschiedene auch für den Business Rules Ansatz relevante Standards publiziert. http://www.knowbeer.com Die Web Site zu diesem Buch mit vielen ergänzenden Informationen, Beispielen und Tools. http://www.omg.org Die Web Site der Object Management Group, der Eigentümerin der UML sowie anderer Standards, die sich seit 2003 auch stark mit der Standardisierung im Zusammenhang mit Business Rules engagiert. http://www.ruleml.org Die Web Site des RuleML Konsortiums. http://www.w3c.com Die Web Site des W3C Konsortiums, welches sich mit Regeln hauptsächlich im Zusammenhang mit dem „Semantic Web“ befasst.
332
H Weitere Informationen
I
Literaturreferenzen
[BIPM]
Bureau International des Poids et Mesures, http://www.bipm.org
[BRG00]
The Business Rules Group: Defining Business Rules – What are they Really? (Final Report, revision 1.3), http://www.businessrulesgroup.org, 2000
[BRG03]
The Business Rules Group: The Business Rules Manifesto – The Principles of Rules Independence (Version 2), http://www.businessrulesgroup.org, 2003
[BRG04]
The Business Rules Group: Business Rules Manifest – Die Prinzipien der Business Rules Unabhängigkeit (Version 2), http://www.businessrulesgroup.org, 2004
[BRG05]
The Business Rules Group: The Business Motivation Model – Business Governance in a Volatile World (Release 1.1), http://www.businessrulesgroup.org, 2005
[GRA04]
Patrick Grässle, Henriette Baumann, Philippe Baumann: UML 2.0 projektorientiert, Galileo Press, 2004, ISBN 3898425479
[ISO00]
International Organization for Standardization: Terminology Work – Principles and methods (ISO-704:2000), Second edition 2000-11-15
[ISO00a]
International Organization for Standardization: Terminology Work – Vocabulary – Part 1: Theory and application (ISO-1087-1:2000), First edition 2000-10-15
[JCP03]
Java Community Process: Java Rule Engine API: JSR94 (Version 1.0), 2003
[OMG03] The Object Management Group: MDA Guide Version 1.0.1 (omg/03-06-01), http://www.omg.org, 2003
I Literaturreferenzen
333
[OMG04] The Object Management Group: UML 2.0 Superstructure Specification (ptc/04-10-02), http://www.omg.org, 2004 [OMG05] The Object Management Group: Semantics of Business Vocabulary and Business Rules (bei/05-08-01), http://www.omg.org, 2005 [OMG05a] The Object Management Group: Business Motivation Model (BMM) – Request for Comment (RFC) (bei/0509-11), http://www.omg.org, 2005 [WIL01] Brian Wilson: Soft Systems Methodology: Conceptual Model Building and Its Contribution, John Wiley & Sons, 2001, ISBN 0471894893
334
[ZAC87]
John A. Zachman: A Framework for Information Systems Architecture, IBM Systems Journal, Vol. 26, No. 3, 1987
[ZAC03]
John A. Zachman: Zachman Framework for Enterprise Architecture ~ Primer for Enterprise Engineering and Manufacturing, Zachman International, 2003
I Literaturreferenzen
Index
4 4get-IT, 201, 243
A abgeleiteter Fakttyp, 158, 309 im Inferenzbaum, 160 in der Rule Map, 159 Abgrenzung, 69 Perspektive des Zachman Frameworks, 67 Abhängigkeiten modellieren, 105 Ableitung, 126, 309 Implementation in der Datenbank, 251 Textschablone für, 129 Agilität, 14, 270 Aktion vordefinierte, 137 Aktivitätsdiagramm, 101 Notation, 102, 290 Anforderungen, 203 an die IT-Unterstützung, 201 an Rule Management Werkzeug skizzieren, 209 aus den Regelungen ableiten, 208 Annahme interner Einfluss, 44, 309 Anwendungsfälle für Rule Management Werkzeug festlegen, 209 Architektur, 233 Datenbank-, 236 Generator-, 237 optimieren, 242 Schichten-, 235
Service-, 233 Arität, 85 ARTiSAN Software Tools, 322 ARTiSAN Studio, 322 ASG Software Solutions, 319 ASG-Alliance, 319 Aufgaben, 66, 69 auflisten, 71 Ausbreitungszeit, 204 ermitteln, 208 Ausprogrammierung, 216 Aussage, 79 Aussagelogik einfache, 216 mit Funktionen, 217 Auswirkung bestimmen, 47
B Bedingungs/Aktions-Regel, 131 Berechnung Textschablone für, 135 BizTalk Server 2006, 326 Blaze Advisor, 325 BRT evaluieren, 224 BRT-Anforderungen identifizieren, 223 BRT-Anforderungskatalog zusammenstellen, 224 Business Rule Engine, 215 Aufruf, 251 Business Rules Architekturen, 233 Big Picture, 19 Business Rules Ansatz Grundkonzepte, 19 Lösung für Probleme, 11 Nutzen, 29
Index
335
Nutzen für die Fachseite, 30 Nutzen für die Informatik, 30 typische Anwendungsgebiete, 22 Business Rules Manifest Postulate, 23 Business Rules Solutions, 322 Business Rules Technologie, 214 Rule Execution Technologie, 215
C Calcus, 201 CASSANDRA/BMM, 320 Chance Einfluss, 45 Einschätzung, 309 Change-Management, 191 CleverPath Aion Business Rules Expert, 324 CleverPath Predictive Analysis Server, 319 Closed World Semantik, 137 Cognos, 319 Compliance, 16 Computer Associates, 319, 324 Corticon, 324 Corticon Business Rules Modeling Studio, 324
D DataMite, 320 Datenbank, 215 Datenbank-Architektur, 236 Definition extensionale, 81 intensionale, 81 deklarativ, 124 deklarierter Fakttyp, 158, 310 im Inferenzbaum, 160 in der Rule Map, 159 Deontische Logik, 115 Dimensionen des Zachman Frameworks, 66 Dinge, 66, 69 auflisten, 71 Direktive, 57, 112, 310 neue, ausarbeiten, 272 neue, umsetzen, 272 DOORS, 323 Drools, 327
336
Index
Durchsetzungsgrad, 126 bestimmen, 139
E ECA-Regel, 131 einfache Aussagelogik, 216 Einfluss, 43, 310 analysieren, 271 externer, 43 interner, 44 Einschätzung, 46, 310 Einschränkung, 126, 310 Implementation in der Datenbank, 252 Textschablone für, 133 einwertiger Fakttyp, 82 identifizieren, 88 eMerge, 329 Enterprise Miner, 321 Entscheidungstabelle, 126 Verifikation, 173 Ereignis/Bedingungs/AktionsRegel, 132 Ereignisse, 67, 69 auflisten, 72 Erlaubnis Direktive, 115, 310 evolveIT, 321 Exemplar-Fakttyp, 84 Expert Solutions International, 325 expliziter Unternehmenswert, 44, 310 extensionale Definition, 81 externer Einfluss, 43, 310
F fachliches Systemmodell, 69 Perspektive des Zachman Frameworks, 67 Fair Isaac, 320, 325 Fakt, 79 Faktenmodell, 80, 81 Anbindung, 239 erstellen, 89 Notation, 289 Faktenmodell-Ausschnitte stabilisieren, 243 Fakttyp, 79, 310 abgeleiteter, 158 deklarierter, 158 einwertiger, 82
einwertiger, identifizieren, 88 Exemplar-, 84 höherwertiger, 83 höherwertiger, identifizieren, 88 identifizieren, 88 im Inferenzbaum, 160 in der Rule Map, 159 Rollen-, 86 Spezialisierungs-, 85 vordefinierter, 136 zweiwertiger, 83 zweiwertiger, identifizieren, 88 Flex, 326 formales Deutsch, 129 funktionale Form, 134, 150
G Gefahr Einfluss, 45 Einschätzung, 311 Generator-Architektur, 237 Geschäftsaktivität, 97, 99, 311 identifizieren, 104 in der Rule Map, 159 Geschäftsereignis, 100, 311 in der Rule Map, 159 Geschäftsobjekt, 80, 311 Geschäftsprozess, 97, 99, 100 anpassen, 272 identifizieren, 103 Geschäftsregel, 113, 123, 124, 311 Ableitung, 126 durch IT programmieren, 254 Einschränkung, 126 erarbeiten, 141 mit Fachseite formulieren, 254 Prozessregel, 126 testen, 254 Verwaltung und Änderung von, 187 Geschäftswissen, 111 Geschäftszweck, 36 Gewohnheit interner Einfluss, 44, 311
H Haley, 325 HaleyAuthority/HaleyRules, 325 Handlungsweise, 56, 311 höherwertiger Fakttyp, 83 identifizieren, 88
I IBM, 322 ILOG, 325 impliziter Unternehmenswert, 44, 312 Inferenz, 217 Rückwärts-, 218 Vorwärts-, 218 Inferenzbaum, 160 Entwurf, 163 Notation, 160, 291 Infrastruktur interner Einfluss, 44, 312 Innovations Softwaretechnologie GmbH, 326 intensionale Definition, 81 interner Einfluss, 44, 312
J Jess, 328 JRules, 325
K Kardinalitäts-Einschränkung Textschablonen für, 134 KnowBeer Mitarbeiter, 6 Vorstellung, 5 KnowGravity Inc., 320 Knowledge Management, 189 Knowledge Management Prozess, 189 Konfiguration, 216 Konkurrent externer Einfluss, 43, 312 Konzept, 79, 312 Kunde externer Einfluss, 43, 312
L laufendes Unternehmen, 69 Perspektive des Zachman Frameworks, 68 LibRT, 322 Lieferant externer Einfluss, 43, 312 Logic Programming Associates Ltd, 320, 326 Logic Suite, 329 Logik
Index
337
Deontische, 115 Logist, 325 Lookup-Tabelle, 148
M Maestro, 329 Makro-Architektur, 233 wählen, 242 Managementvorrecht interner Einfluss, 44, 313 Mandarax, 327 Microsoft, 326 Mission, 56, 313 formulieren, 57 Mittel, 56, 313 Model Builder for Decision Trees, 320 Modellregel, 114, 313 mögliche Auswirkung, 46, 313 Motivation sinnvolle Unternehmen, 12 Motivationskette, 170 Motive, 67, 69 auflisten, 71 myTBQ, 201, 232
N NESS, 326 Nutzen analysieren, 47 mögliche Auswirkung, 46, 313 NxBRE, 327
O Objekttyp, 79, 314 definieren, 89 identifizieren, 87 im Faktenmodell, 82 Open World Semantik, 137 OPS5, 220 Oracle, 320 Oracle 10g Data Mining, 320 Oracle Business Rules, 327 Organisationseinheit, 100, 314 Organisationsstruktur definieren, 105 Orte, 66, 69 auflisten, 72
P Partner
338
Index
externer Einfluss, 43, 314 Pega Systems, 328 PegaRULES, 328 Perspektiven des Zachman Frameworks, 67 Pilotprojekt durchführen, 225 Platzhalter, 130 Powertype-Notation, 274 Prädikatenlogik, 217 Projekt, 63 PROLOG, 220 Prologa, 324 Prozessregel, 126, 314 Implementation in der Datenbank, 253 Textschablone für, 131 Prüfzeitpunkt, 206 Pulinco, 323 Pull-Architektur, 240 Push-Architektur, 239
Q qualitatives Ziel, 36, 314 formulieren, 37 quantitatives Ziel, 36, 314 formulieren, 37 QuickRules, 329
R Refactive, 321 Refactive Re-engineering Toolset, 321 Regel-Komplexität, 216 Regelsprache, 250 Regeltechnologie wählen, 242 Regelung, 113, 315 beschreiben, 118 identifizieren, 116 in der Rule Map, 159 klassifizieren, 138 priorisieren, 138 validieren, 172 verifizieren, 172 Regelverwaltung implementieren, 241 RegulationMaster, 227 Requisite Pro, 322 Resolution EBS, 328 Ressource
interner Einfluss, 44, 315 Ressourcen, 66, 69 auflisten, 72 Risiko analysieren, 47 mögliche Auswirkung, 46, 315 Rollen-Fakttyp, 86 Rückwärts-Inferenz, 161, 218 Rule Execution Technologie, 215 Rule Management, 185 Aktivitäten definieren, 193 Verantwortlichkeiten definieren, 194 Rule Management Prozess testen, 255 Rule Management Werkzeug, 207 Rule Map, 159 entwerfen, 162 Entwurf, 161 identifizieren, 162 Notation, 159 RuleArts, 323 RuleBurst, 323, 328 Engine, 328 Interactive, 323 Rule Server, 328 Studio, 323 RuleFX, 244, 256, 260 Rule-Map Notation, 290 RuleModeler, 324 RulesPower, 325 RuleTrack, 322 RuleXpress, 323
S Sandia National Laboratories, 328 Sapiens, 329 SAS, 321 Scenario, 319 Schichten-Architektur, 235 Schlussfolgerung im Inferenzbaum, 160 Schwäche Einfluss, 45 Einschätzung, 315 Service-Architektur, 233 Spezialisierungs-Fakttyp, 85 Stärke Einfluss, 45 Einschätzung, 316
Strategie, 57 erarbeiten, 57 Handlungsweise, 315 Streitpunkt interner Einfluss, 44, 316 SWOT-Analyse, 316 SWOT–Analyse, 45 System Architect, 323 Systemkomponenten, 69 Perspektive des Zachman Frameworks, 67 Systemmodell fachliches, 69 fachliches, Perspektive des Zachman Frameworks, 67 technisches, 69 technisches, Perspektive des Zachman Frameworks, 67
T Taktik, 57, 316 erarbeiten, 58 technisches Systemmodell, 69 Perspektive des Zachman Frameworks, 67 Technologie externer Einfluss, 43, 316 Telelogic, 323 Textschablone für Ableitungen, 129 für Berechnungen, 135 für Einschränkungen, 133 für KardinalitätsEinschränkungen, 134 für Prozessregeln, 131 TMGi-BRH/TGMi-SAT, 321 TopEase, 323 Transoft, 321 Transparentlogic, 329 Trinity Millenium Group, Inc, 321
U Umfeld beobachten, 271 Umgebung beschreiben, 208 Umsetzung definieren, 192 Umsetzungsstrategie, 186 skizzieren, 223 Umwelt
Index
339
externer Einfluss, 43, 317 Unisys, 324 University of Leuven, Belgium, 324 University of Waikato, 321 Unternehmen laufendes, 69 laufendes, Perspektive des Zachman Frameworks, 68 Unternehmenseinfluss, 44 einschätzen, 47 identifizieren, 46 Unternehmensmodell, 69 Perspektive des Zachman Frameworks, 67, 99 Unternehmensvokabular, 77 aktualisieren, 118, 141, 271 Unternehmenswert expliziter, 44 impliziter, 44 interner Einfluss, 44, 317 Unternehmensziele, 53 USoft, 326
V Valens, 322 Validierung, 169, 170 Verantwortlicher, 105 Verantwortlichkeiten zuordnen, 105 Verbot, 317 Direktive, 115 Verifikation, 169 Verpflichtung, 317 Direktive, 115 Versata, 329 Vision, 36, 317 formulieren, 37 VisiRules, 326 Visual Rules, 326 Volatilität, 204 ermitteln, 207
340
Index
Voraussetzung Geschäftsaktivität, 101 vordefinierte Aktion, 137 vordefinierter Fakttyp, 136 Vorschrift externer Einfluss, 43, 317 Vorwärts-Inferenz, 161, 218
W wann, 67, 69, 72 warum, 67, 69, 71 Warum-Erklärung, 221 was, 66, 69 WEKA, 321 wer, 66, 69 Werttyp, 80, 318 Wie-Erklärung, 221 Wissenselement, 114, 318 wo, 66, 69, 72 womit, 66, 69, 71, 79, 87
X XML, 245 Overhead, 240 XML-Dokument, 239
Y Yasu Technologies, 329
Z Zachman Framework, 65, 66, 75, 334 Dimensionen des, 66 Perspektiven des, 67 Ziel, 36, 318 qualitatives, 36 qualitatives, formulieren, 37 quantitatives, 36 quantitatives, formulieren, 37 Zweck, 36, 318 zweiwertiger Fakttyp, 83 identifizieren, 88
