A Business Rules Manifest B Zusammenfassung des Entwicklungsprozesses C Übersicht über die verwendeten Notationen...

Transkript

1 Anhänge A Business Rules Manifest B Zusammenfassung des Entwicklungsprozesses C Übersicht über die verwendeten Notationen D Muster & Checklisten E Meta Modelle F Begriffsdefinitionen G Business Rules Technologie H Weitere Informationen I Literaturreferenzen

2 A Business Rules Manifest Die Prinzipien der Business Rules Unabhängigkeit The Business Rules Group 48 Artikel 1. Primäre statt sekundäre Anforderungen 1.1. Regeln sind Elemente erster Klasse in der Anforderungs-Welt 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 Regeln sind weder Prozesse noch Prozeduren und sollen auch nicht in diesen enthalten sein 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, Business Rules Group., Version 2.0, 1. November Editor Ronald G. Ross. BusinessRulesGroup.org, Übersetzung: M. Schacher, KnowGravity Inc., 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

3 Artikel 3. Bewusstes Wissen statt Nebenprodukt 3.1. Regeln basieren auf Fakten und Fakten basieren auf Konzepten, die durch Begriffe repräsentiert werden Begriffe repräsentieren Geschäftskonzepte; Fakten sind Feststellungen über diese Konzepte; Regeln schränken diese Fakten ein und unterstützen sie Regeln müssen explizit sein. Es dürfen keine impliziten Annahmen über Konzepte oder Fakten als Regeln vorausgesetzt werden Regeln sind die Grundlage dessen, was eine Organisation über sich weiß, d.h. die Grundlage des Geschäftswissens 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 Kann etwas nicht ausgedrückt werden, dann ist es keine Regel Eine Menge von Sätzen ist nur dann deklarativ, wenn damit keine Sequenz impliziert wird Jeder Regel-Satz, der andere Konstrukte als Begriffe und Fakten benötigt, impliziert Annahmen über eine System-Implementation Eine Regel ist etwas anderes als ihre Durchsetzung. Eine Regel und ihre Durchsetzung sind separate Aspekte Regeln sollen unabhängig von den Verantwortlichkeiten (wer, wo, wann, wie) ihrer Durchsetzung formuliert werden 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 Geschäftsregeln sollten so formuliert sein, dass sie untereinander auf Konsistenz verifiziert werden können 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

4 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 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 Ein Business Rules System muss immer in der Lage sein, seine getroffenen Entscheidungen oder ausgelösten Aktionen zu begründen Regeln basieren auf Wahrheitswerten. Wie ein solcher Wahrheitswert bestimmt und aktualisiert wird, bleibt dem Benutzer verborgen 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 Regeln benötigen oft eine selektive Behandlung von festgestellten Regel-Verletzungen. Eine solche Ausnahmebehandlung ist eine Aktivität wie jede andere 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 Regeln sollen die Fachabteilungen immer etwas kosten 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 Mehr Regeln ist nicht besser. Üblicherweise sind wenige gute Regeln besser 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

5 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 Fachabteilungen sollen Werkzeuge zur Verfügung haben, die sie bei der Formulierung, Validierung und Verwaltung von Geschäftsregeln unterstützen 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 Regeln sind ein vitales Gut einer Organisation Langfristig sind Geschäftsregeln wichtiger für eine Organisation als Hardware-/Software-Plattformen Geschäftsregeln sollten so organisiert und verwaltet werden, dass sie sich einfach auf neue Hardware-/Software-Plattformen migrieren lassen 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

6 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

7 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 ) Rule Maps identifizieren Grundlagen und Ergebnisse identifizieren Rule Maps entwerfen Entwurf von Inferenzbäumen (Kapitel ) 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

8 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

9 C Übersicht über die verwendeten Notationen In unserem Buch werden verschiedene grafische Notationen verwendet. Diese sind hier als Übersicht zusammengefasst. C.1 Faktenmodell-Notation genereller Objekttyp... Konzept1 (Konzept1) SatzTeil1 (Konzept2) SatzTeil1 (Konzept3) StatzTeil2 höherwertiger Fakttyp mit Notitz für Satzmuster Konzept3 Aussage über Konzept3 Abb. C.1 Die Faktenmodell- Notation SatzTeil1 Konzept2 Aussage über zwei Konzepte Konzept6 «ist Rolle von» Konzept4 allgemeiner Objekttyp... spezieller Objekttyp Konzept7 Rolle des anderen Objektyps Konzept5 individueller Objekttyp Die Faktenmodell-Notation ist in Kapitel erklärt. C Übersicht über die verwendeten Notationen 289

10 Abb. C.2 Die Aktivitäts- diagramm- Notation C.2 Aktivitätsdiagramm-Notation Organisationseinheit 2 empfangenes Geschäftsereignis Voraussetzung für Organisationseinheit 1 Organisationseinheit 3 Geschäftsaktivität 1 Voraussetzung für Geschäftsaktivität 2 Voraussetzung für Geschäftsaktivität 3 gesendetes Geschäftsereignis Ende Die Aktivitätsdiagramm-Notation ist in Kapitel 11.2 erklärt. Abb. C.3 Die Rule-Map- Notation C.3 Rule-Map-Notation «deklariert» deklarierter Fakttyp «Ableitungen» Regelung «abgeleitet» abgeleiteter Fakttyp «Prozessregeln» eine andere Regelung «Geschäftsereignis» Geschäftsereignis «Geschäftsaktivität» Geschäftsaktivität Die Rule-Map-Notation ist in Kapitel erklärt. 290 C Übersicht über die verwendeten Notationen

11 C.4 Inferenzbaum-Notation «abgeleitet» abgeleiteter Fakttyp «abgeleitet» noch ein abgeleiteter Fakttyp Abb. C.4 Die Inferenzbaum-Notation vorwärts «abgeleitet» ein anderer abgeleiteter Fakttyp «deklariert» noch ein deklarierter Fakttyp rückwärts «deklariert» ein anderer deklarierter Fakttyp «deklariert» deklarierter Fakttyp Die Inferenzbaum-Notation ist in Kapitel erklärt. C.4 Inferenzbaum-Notation 291

12 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 Lookup- Tabelle: 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

13 Bedingungstabelle In einer Bedingungstabelle repräsentieren die Inhaltszellen Teil- Bedingungen, welche zu den Teil-Folgerungen führen. Diese Form der Entscheidungstabelle haben wir im Buch verwendet. Bedingung Kriterium 1 Kriterium 2 Folgerung Kriterium X Kriterium Y Regel n Wert 11 x x Wert 12 x x Wert 21 x x Wert 22 x x Wert 23 x x Wert X1 x x Wert X2 x x Wert Y1 x x Wert Y2 x x Geschachtelte Bedingungstabelle In der geschachtelten Bedingungstabelle werden die Wertebereiche der einzelnen Kriterien ineinander geschachtelt dargestellt: Bedingung Kriterium 1 Wert11 Wert12 Kriterium 2 Wert21 Wert22 Wert23 Wert21 Wert22 Wert23 Kriterium 3 W31 W32 W31 W32 W31 W32 W31 W32 W31 W32 W31 W32 Folgerung Kriterium X Kriterium Y Wert X1 x x x x x x Wert X2 x x x x x x Wert Y1 x x x x x Wert Y2 x x x x x x x 294 D Muster & Checklisten

14 D.2 Textschablonen für formales Deutsch Textschablone für Ableitungen Ableitungen lassen sich auf der Basis der folgenden Textschablone in formalem Deutsch verfassen: <Id>: <Folgerung>, falls alle folgenden Bedingungen erfüllt sind: <Bedingung 1> <Bedingung 2> UND - Verknüpfung <Bedingung n>. Anstelle der UND -Verknüpfung kann auch eine ODER - Verknüpfung treten: <Id>: <Folgerung>, falls mindestens eine der folgenden Bedingungen erfüllt ist: <Bedingung 1> <Bedingung 2> ODER - Verknüpfung <Bedingung n>. Textschablone für Prozessregeln Prozessregeln in der Form von Bedingungs/Aktions-Regeln lassen sich auf der Basis der folgenden Textschablone in formalem Deutsch verfassen: <Id>: Falls alle folgenden Bedingungen erfüllt sind: <Bedingung 1> <Bedingung 2> UND - Verknüpfung <Bedingung n>. Dann müssen/dürfen folgende Aktivitäten (nicht) ausgeführt werden: <Aktion 1> <Aktion 2> UND - Verknüpfung <Aktion n>. D.2 Textschablonen für formales Deutsch 295

15 Liegen Prozessregeln in Form von Ereignis/Bedingungs/Aktions- Regeln vor, kann die folgende Textschablone verwendet werden: <Id>: Falls eines der folgenden Ereignisse eintritt: <Ereignis 1> <Ereignis 2> ODER - Verknüpfung <Ereignis n> Und alle folgenden Bedingungen erfüllt sind: <Bedingung 1> <Bedingung 2> UND - Verknüpfung <Bedingung n>. Dann müssen/dürfen folgende Aktivitäten (nicht) ausgeführt werden: <Aktion 1> <Aktion 2> UND - Verknüpfung <Aktion n>. Textschablone für Einschränkungen Einschränkungen lassen sich auf der Basis der folgenden Textschablone in formalem Deutsch verfassen: <Id>: Für jeden <Objekttyp> müssen immer alle folgenden Bedingungen erfüllt sein: <Bedingung 1> <Bedingung 2> UND - Verknüpfung <Bedingung n>. 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

16 <Id>: <Id>: <Id>: <Id>: <Id>: Jede(r/s) <Objekttyp> <Fakttyp> genau ein(e/er/en/em) <Objekttyp> Jede(r/s) <Objekttyp> <Fakttyp> mindestens ein(e/er/en/em) <Objekttyp> Jede(r/s) <Objekttyp> <Fakttyp> mindestens <Zahl> <Objekttyp> Jede(r/s) <Objekttyp> <Fakttyp> höchstens ein(e/er/en/em) <Objekttyp> Jede(r/s) <Objekttyp> <Fakttyp> höchstens <Zahl> <Objekttyp> Textschablone für Berechnungen Berechnungen (numerische, aber auch nicht-numerische) lassen sich auf der Basis der folgenden Textschablone in formalem Deutsch verfassen: <Id>: <Objekttyp> <Fakttyp> <Formel>, wobei <Objekttyp> <Fakttyp> <Platzhalter> <Objekttyp> <Fakttyp> <Platzhalter> falls alle folgenden Bedingungen erfüllt sind: <Bedingung 1> <Bedingung 2> UND - Verknüpfung <Bedingung n>. Oft entfällt auch der Bedingungsteil in Berechnungen. D.2 Textschablonen für formales Deutsch 297

17 Abb. D.1 Vordefinierte Konzepte 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: Objekttyp Konzept Fakttyp Geschäftsobjekt Werttyp «ist Rolle von» 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 "s" phys. Grösse 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

18 D.4 Fakttypen-Bibliothek Bei der Formulierung eines Faktenmodells kann auf die folgenden, generischen (d.h. immer wieder auftretenden) Fakttypen aufgebaut werden: Konzept (Werttyp) zwischen (Werttyp) und (Werttyp) Werttyp gleich ungleich größer als größer oder gleich kleiner als kleiner oder gleich und zwischen Konzept Werttyp Anzahl (Anzahl) ist unterschiedliche Anzahl von (Objekttyp) in (Fakttyp) Werttyp (Werttyp) ist Minimum von (Werttyp) in (Fakttyp) ist Anzahl von in Fakttyp ist unterschiedliche Anzahl von in Objekttyp Fakttyp ist Minimum von Werttyp Abb. D.2 Vordefinierte Fakttypen Konzept ist eine(r/s) von Menge Werttyp Fakttyp Menge Werttyp ist enthalten in ist Menge Funktion (Werttyp) ist Maximum von (Werttyp) in (Fakttyp) in ist Maximum von Werttyp Datum später als Datum Menge Fakttyp früher als in ist heute ist jetzt (Menge) ist die Menge von (Objekttyp) in (Fakttyp) ist die Menge von Objekttyp Geschäftsregel trifft nicht zu von Geschäftsregeln Bezieht sich auf eine ganze Regelung Objekttyp in Fakttyp Menge 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

19 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 EF EF1 EF1.1 EF1.2 EF1.3 EF1.4 EF1.5 EF1.6 EF1.7 Anforderung Funktionale Anforderungen Regel-Semantik Welche Regel-Typen werden benötigt? - Einschränkungen - Ableitungen - Prozessregeln (Event/Condition/Action oder bloß Condition/Action) Welche Art von Bedingungen wird benötigt? - einfache UND/ODER/NICHT Verknüpfungen von Ja/Nein- Kriterien - Kriterien mit parametrisierten Argumenten (Funktionen) - Bedingungen mit Platzhaltern (logische Variabeln) mit für alle und es existiert Operatoren (Prädikatenlogik) Welche Aktions-Typen werden für Prozessregeln benötigt? - Datenbank-Aktualisierungen - allgemeine eingebaute Aktionen - API-Aufrufe Wie komplex sind die einzelnen Regeln: einige wenige oder duzende von Kriterien in einer Bedingung? Werden unsichere Regeln benötigt, d.h. Regeln, welche Aussagen mit einer gewissen Wahrscheinlichkeit versehen? Werden fuzzy Regeln benötigt, d.h. Regeln, welche stufenlose Wahrheiten (z.b. Halbwahrheiten) repräsentieren? Müssen Regeln beliebig tief verkettet werden können (via Fakttypen und/oder via Aktionen)? 300 D Muster & Checklisten

20 Id EF1.8 EF1.9 EF2 EF2.1 EF2.2 EF2.3 EF2.4 EF2.5 EF2.6 EF2.7 EF2.8 EF3 EF3.1 EF3.2 EF3.3 EF4 EF4.1 EF4.2 EF4.3 ENF ENF1 ENF1.1 ENF1.2 ENF1.3 Anforderung Müssen sich Regeln priorisieren lassen, damit allfällige Widersprüche zwischen Regeln aufgelöst werden können? Müssen Regeln zu Gruppen strukturiert, d.h. modularisiert werden können? Regel-Ausführung Ist Vorwärts-Inferenz notwendig? Ist Rückwärts-Inferenz notwendig? Müssen bei der Ausführung der Regeln Fakten interaktiv vom Benutzer nachgefragt werden? Müssen bei der Ausführung der Regeln Fakten von Datenbanken nachgeladen werden? Müssen bei der Ausführung von Regeln ganze Rule Sets aktiviert oder deaktiviert werden können? Ist eine eingebaute Erklärungskomponente notwendig (Wie bzw. Warum Erklärungen) Ist eine Mehrsprachigkeit für die Erklärungskomponente erforderlich, d.h. sind die in den Erklärungen angezeigten Fakten und Regeln in verschiedenen Landesprachen darzustellen? Ist eine Mandantenfähigkeit erforderlich, d.h. müssen beispielsweise dieselben Fakten je nach Mandant unterschiedlich abgeleitet werden? Autorisierung Muss der Aufruf der Business Rule Engine autorisiert, d.h. nur für ausgewählte Benutzer zugelassen werden? Dürfen gewissen Fakten nur bei entsprechend autorisierten Benutzern in die Entscheidungsfindung einfließen? Dürfen gewisse Regeln oder ganze Regelungen nur bei entsprechend autorisierten Benutzern zu Anwendung kommen? Reporting Monitoring: Muss der aktuelle Zustand der Business Rules Engine sowie Betriebsstatistiken im laufenden Betrieb abgefragt werden? Logging: Müssen die zur Anwendung gelangten Regeln sowie andere Ereignisse protokolliert und vielfältig ausgewertet werden können? Müssen die aktiven, d..h. zur Zeit tatsächlich in Produktion befindlichen Regeln abgefragt werden können? 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? Wie hoch ist die Anzahl der Regeln? D.5 Anforderungen an Regel-Technologie 301

21 Id ENF1.4 ENF2 ENF2.1 ENF2.2 ENF3 ENF3.1 ENF3.2 ENF3.3 ENF3.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? Performance Welche Antwortzeit ist von der Business Rules Engine gefordert? Ist eine Hochverfügbarkeit (7 x 24 Betrieb) gefordert? Integration & Standards Welche Aufrufstandards werden von der Business Rules Engine unterstützt (z.b. JSR-94)? Verwendet die Business Rules Engine ein standardisiertes Regelformat (z.b. RuleML)? Über welche (standardisierten) Schnittstellen soll die Business Rules Engine auf Datenbanken (Fakten) zugreifen? 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 MF MF1 MF2 MF2.1 MF2.2 MF2.3 MF3 MF3.1 MF3.2 MF3.3 MF3.4 MF3.5 MF4 MF4.1 MF4.2 Anforderung Funktionale Anforderungen Wird die gesamte bei der Ausführung benötigte Regel-Semantik unterstützt (siehe EF1 in Tabelle D.1)? Faktenmodell Kann ein Faktenmodell als Grundlage für die Formulierung von Regeln erstellt werden? Können Definitionen für Objekt- und Fakttypen erfasst und aufeinander aufgebaut werden? Kann das Faktenmodell graphisch dargestellt werden (z.b. in der UML- oder ORM-Notation)? Regel-Repräsentation Werden Regeln in strukturierter natürlicher Sprache unterstützt? Werden Entscheidungstabellen unterstützt? Werden Entscheidungsbäume unterstützt? Werden komplexe Berechnungen unterstützt? Werden andere Regel-Repräsentationen unterstützt? Regel-Verwaltung Wird die Versionierung von Regeln oder ganzen Regelungen unterstützt? Müssen Regeln mit einem Gültigkeitsdatum (von, bis) versehen werden können? 302 D Muster & Checklisten

22 Id MF4.3 MF4.4 MF4.5 MF4.6 MF4.7 MF4.8 MF5 MF5.1 MF5.2 MF5.3 MF5.4 MF6 MF6.1 MF6.2 MF6.3 MF6.4 MNF MNF1 MNF1.1 MNF1.2 MNF1.3 MNF2 MNF2.1 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? Sind Mittel für die Validierung von Regeln und Regelungen vorhanden (Testdaten, Regressionstests, Debugging, etc.)? Sind Mittel für die formale Verifikation von Regeln und Regelungen vorhanden (Prüfung auf Vollständigkeit und Widerspruchsfreiheit)? Können Regel-Templates sowie Regel- Parametrisierungen für verschiedene Benutzergruppen definiert werden? Kann der Zugriff auf die Regeln und Regelungen mit einer Autorisierung versehen werden (lesender/schreibender/ausführender Zugriff)? Besteht eine technische Unterstützung zur Entgegennahme und Ablage von Feedback zur Regel-Anwendung im operationellen Betrieb? Reporting Müssen Regeln flexibel und nach verschiedenen Kriterien gesucht und betrachtet werden können (Browsing)? Muss ein automatischer Verwendungsnachweis für Fakttypen erbracht werden können? Muss eine automatische Impact-Analyse für Fakttypen erbracht werden können? Müssen frei konfigurierbare Reports über die Regelbasis erstellt werden können? Regel-Inkraftsetzung Können Regeln und Regelungen im Inter- bzw. Intranet publiziert werden? Können einzelne Regelungen aktiviert/deaktiviert, d.h. gezielt in den operationellen Betrieb überführt bzw. aus diesem entfernt werden? Kann die Inkraftsetzung bzw. Außerkraftsetzung von Regeln und Regelungen zeitgesteuert erfolgen (z.b. per Gültigkeitsdatum) Kann der Deployment-Prozess konfiguriert, d.h. flexibel automatisiert werden? Nicht-funktionale Anforderungen Mehrsprachigkeit Kann dieselbe Regel gleichzeitig in mehreren Sprachen erfasst bzw. dargestellt werden? Kann derselbe Fakttyp gleichzeitig in mehreren Sprachen erfasst bzw. dargestellt werden? Kann die Regel- oder Faktensprache jederzeit gewechselt werden ( Hot Change )? Mehrbenutzerbetrieb Wird gleichzeitiges Ändern von Regeln oder Regelungen verhindert (pessimistisches Locking)? D.5 Anforderungen an Regel-Technologie 303

23 Id MNF2.2 MNF2.3 MNF3 MNF4 MNF4.1 MNF4.2 MNF4.3 MNF4.4 MNF4.5 MNF4.6 MNF5 MNF5.1 MNF5.2 Anforderung Wird gleichzeitiges Ändern von Regeln oder Regelungen festgestellt und gemeldet (optimistisches Locking)? Wird automatisch ein Änderungsnachweis (wer/wann/was/warum) geführt (Change Tracking)? Wie bequem lässt sich das Werkzeug bedienen (Useability)? Integration Kann das Faktenmodell aus einem externen Werkzeug übernommen werden (z.b. via XMI aus einem UML CASE Tool)? Besteht eine Integrationsmöglichkeit mit einem Business Process Modelling Werkzeug? Können Regeln aus einem Rule Discovery Werkzeug übernommen/importiert werden? Können Regeln in verschiedene Rule Execution Technologie exportiert werden? Wenn ja, welche? Können für die Validierung Testdaten (Fakten) aus operationellen Datenbanken übernommen werden? Kann das Rule Management Werkzeug über eine API (Application Programming Interface) ferngesteuert werden? Standards Verwendet die Business Rules Engine ein standardisiertes Regelformat (z.b. RuleML)? Ü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 DF DF1 DF1.1 DF1.1.1 DF1.1.2 DF1.2 DF1.1.1 DF1.1.2 DF2 Anforderung Funktionale Anforderungen Datenquellen Können Regeln aus Programmcode extrahiert werden (Reverse Engineering)? Können Zusammenhänge aus Datenstrukturen (z.b. Datenbanken, Copy-Strecken, etc.) extrahiert werden? Können Zusammenhänge aus Programmstrukturen extrahiert werden? Welche Programmiersprachen werden unterstützt? Müssen Regeln aus Datenbeständen extrahiert werden (Data Mining)? Können Zusammenhänge aus großen historischen Datenbanken extrahiert werden? Können Zusammenhänge aus allgemeinen unstrukturierten Dokumenten extrahiert werden? Funktionalität 304 D Muster & Checklisten

24 Id DF2.1 DF2.2 DF2.3 DNF DNF1 DNF2 DNF2.1 DNF2.2 DNF3 DNF3.1 DNF3.2 DNF4 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 Welche Data Mining Algorithmen werden unterstützt? - Warenkorb-Analyse - Neuronale Netzwerke - Regel-Induktion, z.b. ID3) Müssen die gefundenen Zusammenhänge und Regeln interaktiv verfeinert werden können? Nicht-funktionale Anforderungen Können auch sehr große Datenmengen (Quellcode oder Datenbanken) verarbeitet werden? Integration Können Regeln in verschiedene Rule Execution Technologie exportiert werden? Wenn ja, welche? Kann das Rule Discovery Werkzeug über eine API (Application Programming Interface) ferngesteuert werden? Standards Über welche (standardisierten) Schnittstellen kann auf Datenbanken zugegriffen werden? Wird ein standardisiertes Regelformat verwendet (z.b. PMML oder RuleML)? 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 (Benutzungsschnittstelle) 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 Lieferant A2.1 Wie groß ist der Lieferant (Umsatz, Niederlassungen, Mitarbeiter im Bereich BRT)? Tabelle D.4 Allgemeine Anforderungen D.5 Anforderungen an Regel-Technologie 305

25 Id Anforderung A2.2 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

26 E Meta Modelle E.1 Business Motivation Model Mission Mittel erfüllt definiert durch Vision Zweck Abb. E.1 Das Business Motivation Model besteht aus ermöglicht besteht aus realisiert Handlungsweise unterstützt Ziel konkretisiert konkretisiert formuliert auf Basis qual. Ziel Strategie Taktik quantifiziert implementiert quant. Ziel Durchsetzung von beeinflusst Geschäftsaktivität beeinflusst leitet Geschäftsregel Direktive motiviert durch Formalität verantwortlich für konkretisiert Formalität motiviert durch bezüglich Stärke Schwäche Chance Gefahr Einschätzung betrifft Regelung mögliche Auswirkung identifiziert definiert durch Teil von Organisationseinheit gemacht durch Nutzen Risiko beurteilt Teil von spielt Rolle von externer Einfluss Einfluss Vorschrift Kunde interner Einfluss Copyright 2005, The Business Rules Group Konkurrent Lieferant Partner Technologie Umwelt expliziter Unternehmenswert impliziter Unternehmenswert Infrastruktur Ressource Annahme Streitpunkt Gewohnheit Unternehmenswert Managementvorrecht E Meta Modelle 307

27 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. Abb. E.2 Geschäftsregeln Konzept Wissenselement Mittel Ziel Objekttyp Fakttyp Modellregel unterstützt macht Aussage über Werttyp Verbot Erlaubnis externer Einfluss Vorschrift spielt Rolle von Direktive Verpflichtung Verwendung Teil von Formalität motiviert durch Regelung konkretisiert Geschäftsregel Einschätzung betrifft leitet motiviert durch Teil von Voraussetzung für Ableitung Einschränkung mögliche Auswirkung Geschäftsaktivität kontrolliert Prozessregel Geschäftsprozess realisiert formuliert auf Basis verwendet löst aus beeinflusst ausgelöst durch verantwortlich für Geschäftsobjekt Geschäftsereignis Organisationseinheit Handlungsweise Durchsetzung von Taktik 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

28 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 Ableitung 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 Annahme 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 Chance 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 Marken- Diversifikation F Begriffsdefinitionen 309

29 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: Ein Konzept, welches eine mögliche, für das Unternehmen relevante elementare Aussage über ein oder mehrere Objekttypen darstellt. Fact Type (SBVR) 310 F Begriffsdefinitionen

30 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

31 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 Infrastruktur 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 Interner Einfluss Ein Einfluss innerhalb des Unternehmens, der dessen Zweck und Mittel beeinflusst. Englisch: Internal Influencer (BMM) Konkurrent Englisch: Konzept Kunde Englisch: Englisch: Lieferant Englisch: 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) 312 F Begriffsdefinitionen

32 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 Mission 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 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) Modellregel 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 Mögliche Auswirkung Eine Beurteilung, die eine Einschätzung qualifiziert oder quantifiziert. Englisch: Potential Impact (BMM) Nutzen 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 Cargo- Lieferanten können wir gegenüber dem Direktversand mehr als 20% Kosten einsparen F Begriffsdefinitionen 313

33 Objekttyp 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 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

34 Regelung 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) Ressource 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 Risiko 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 Schwäche 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 Strategie 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 F Begriffsdefinitionen 315

35 Stärke 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 Streitpunkt 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 SWOT-Analyse Ein Werkzeug des strategischen Managements das sowohl eine innerbetriebliche Stärken- Schwä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 Taktik 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 Technologie 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 316 F Begriffsdefinitionen

36 Umwelt 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 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) Vision 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 Vorschrift 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 F Begriffsdefinitionen 317

37 Werttyp 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 Wissenselement Ein Bestandteil des für ein Unternehmen wichtigen Wissens. Dazu gehören Konzepte, Direktiven und Modellregeln. Englisch: Knowledge Element Ziel Englisch: Zweck Englisch: 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) 318 F Begriffsdefinitionen

38 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: ASG Software Solutions Produkt: ASG-Alliance Web Site: Kurzbeschreibung: Bietet verschiedene Analysen der Datenstrukturen in existierendem Programmcode, um dessen Funktionsweise besser zu verstehen. Hersteller: Cognos Produkt: Scenario Web Site: Kurzbeschreibung: 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: Computer Associates Produkt: CleverPath Predictive Analysis Server Web Site: Kurzbeschreibung: 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

39 Hersteller: Fair Isaac Produkt: Model Builder for Decision Trees Web Site: Kurzbeschreibung: 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: KnowGravity Inc. Produkt: CASSANDRA/BMM Web Site: Kurzbeschreibung: Ein einfaches Hilfsmittel, welches eine strukturierte Erfassung des Business Motivation Models (BMM) erlaubt. Das BMM von KnowBeer ist als Beispiel unter zu finden. Hersteller: Logic Programming Associates Ltd Produkt: DataMite Web Site: Kurzbeschreibung: 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: Oracle Produkt: Oracle 10g Data Mining Web Site: Kurzbeschreibung: 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. 320 G Business Rules Technologie