Business Rulesmedia.tuwien.ac.at/fileadmin/user_upload/htellioglu/...Business Rules Praktikum Seite 7 von 32 6. Semester jeweiligen Prozessmodell können Verweise auf die entfernten

Business Rules

Praktikum Seite 1 von 32 6. Semester

BUSINESS RULES Projektpraktikum

Peter SMEJKAL | 0304134 | 532

Business Rules


1 Inhaltsverzeichnis

1 INHALTSVERZEICHNIS............................................................................................... 2

2 EINLEITUNG................................................................................................................... 3

2.1 BUSINESS RULES COMMUNITY ..................................................................................... 4

2.2 FORDERUNGEN DES BUSINESS RULES ANSATZES ......................................................... 5

2.3 DAS BUSINESS RULES MANIFEST ................................................................................. 6

2.4 DAS BUSINESS MOTIVATION MODEL ........................................................................... 7

3 ANWENDUNGSGEBIETE DES BUSINESS RULES ANSATZES.......................... 10

4 ARTEN VON BUSINESS RULES................................................................................ 11

4.1 ABLEITUNGS-BZW. STRUKTURELLE REGELN (DERIVATION RULES)........................... 11

4.2 EINSCHRÄNKUNGEN-ODER BEDINGUNGSREGELN (CONSTRAINTS) ............................. 12

4.3 PROZESS-ODER VERHALTENSREGELN (REACTION RULES) ......................................... 13

5 EIGENSCHAFTEN VON BUSINESS RULES ........................................................... 14

6 PROBLEME DER UNTERNEHMEN ......................................................................... 16

6.1 BEWÄLTIGUNG DURCH BUSINESS RULES ANSATZ...................................................... 16

6.2 ENTSTEHUNG DURCH BUSINESS RULES ...................................................................... 17

6.2.1 Inkonsistente Durchführung der Business Rules................................................ 17

6.2.2 Missverständnis der Business Information ........................................................ 18

7 ENTSCHEIDUNGSTABELLEN .................................................................................. 19

8 MODELLIERUNG VON BUSINESS RULES ............................................................ 21

8.1 BUSINESS RULES ALS REACTION RULES..................................................................... 25

9 FORMULIERUNG VON GESCHÄFTSREGELN.................................................... 27

10 FAZIT........................................................................................................................... 30

11 LITERATURVERZEICHNIS ................................................................................... 30

Business Rules


2 Einleitung

Der Begriff Geschäftsregel oder englisch Business Rule (BR) bezeichnet verschiedene Arten von Regeln, die unter anderem in Zusammenhang mit Computerprogrammen verwendet werden können. Man versteht darunter nicht notwendigerweise eine geschäftliche Angelegenheit, sondern Sie können auch ganz elementare technische Sachverhalte beschreiben. Weiters können es auch einfach Vorgaben sein, die beschreiben, wie sich ein Computerprogramm oder Geschäftsprozess, der durch ein Computerprogramm gesteuert wird, verhalten soll [3]. Laut der Business Rules Group (BRG) kann man die Definition der Business Rules aus 2 verschiedenen Seiten sehen [18]: 1. Aus Sicht des Unternehmens: „Eine Direktive, die das Verhalten des Unternehmens in eine bestimmte Richtung steuern soll. Dabei soll sie die Einhaltung der Unternehmenspolitik unterstützen.“ 2. Aus Sicht der IT: „Eine Aussage, die Verhaltensweisen oder Vorgänge innerhalb des Unternehmens einschränkt. Sie hat aus dieser Sicht die Aufgabe die Unternehmung zu strukturieren bzw. zu kontrollieren.“ Business Rules werden durch das Unternehmen bestimmt, eingerichtet und deshalb auch durch das Unternehmen verwaltet. Sie werden als Brücke zur Angleichung des Informationssystems (IS) mit dem Betrieb verwendet. Falls eine Regel nicht im Zuständigkeitsbereich eines Unternehmens liegt ist sie keine Business Rule, wie zum Beispiel das Gesetz der Schwerkraft oder mathematische Regeln. BR können extern oder intern definiert sein. Interne Regeln sind innerhalb des Betriebes definiert und werden von strategischen Elementen abgeleitet, die die Motivation für ihre Existenz darstellen. Externe Regeln kommen im Gegensatz dazu von außerhalb des Betriebes und beinhalten Regierungsvorschriften und bestimmte Gesetze, die ein bestimmtes Verhalten verlangen. Laut [14] ist eine Business Rule - “a statement about how the business is done, i.e., about guidelines and restrictions with respect to states and processes in an organization” - “a law or custom that guides the behaviour or actions of the actors connected to the organization“ - “a declaration of policy or condition that must be satisfied”

Business Rules


In letzter Zeit wurden Business Rules immer populärer in der Community der IS wegen ihrer Fähigkeit, Applikationen flexibel und offen für Veränderungen zu machen.

2.1 Business Rules Community

Die Business Rules Group wurde im Jahr 1989 gegründet und war der erste Entwickler des Business Rules Ansatzes. Diese Gemeinschaft wollte sich am Anfang darauf fokussieren, die Business Rules direkt in die Informationstechnologie zu implementieren. Um solche Rules in Programm Code umzusetzen müssen diese aber vorher festgelegt und ausgearbeitet werden. Die Business Rules Group wurde gegründet um diese Dokumentation zu übernehmen. Der Durchbruch, der auch manchmal Business Rules Mantra [18] genannt wird, begann damit, dass die EntwicklerInnen des Business Rules Ansatzes übereinkamen, das die BR spezifisch Terme, Fakten und Regeln beinhalten. Dies wurde in dem so genannten GUIDE Business Rules Project beschlossen. Weiters wird durch die Business Rules Group betont, dass ein Unterschied zwischen der Bedeutung einer Business Rule und der Durchführung besteht. Die Business Rules Group begann als ein Projekt, bestehend aus mehreren Leuten, von der User Group GUIDE International. Dort publizierten sie ihren ersten Artikel im Jahr 1995, ihr original ‚white paper’ mit dem Namen „Defining Business Rules - What are they really?“. Hier wurde die Natur der Business Rules erklärt, wie sie funktionieren und in welche Kategorie sie fallen können. Es wurde noch 2-mal überarbeitet und steht jetzt in der neuesten Version aus dem Jahr 2000 unter dem offiziellen Business Rules Group (BRG) Banner zur Verfügung. Im Jahre 2000 brachte die Business Rules Group ihr zweites Paper heraus: „The Business Motivation Model – Business Governance in a volatile world“. In diesem Artikel geht es hauptsächlich um die Motivation, die in einem Unternehmen benötigt wird, um die Produkte und Services zur richtigen Zeit am richtigen Ort zu organisieren. Das Paper wurde 2005 ein weiteres Mal überarbeitet (siehe 2.4). 2002 wurde ihr „Business Rules Manifest“(siehe Punkt 2.3), in dem die Prinzipien der Business Rules Unabhängigkeit dargestellt wurden, herausgebracht. Es wurde aus dem Englischen auch in viele andere Sprachen übersetzt.

Business Rules


2.2 Forderungen des Business Rules Ansatzes

Ein interessantes Detail an dem Erscheinen des Business Rules Ansatzes ist das er nicht als Antwort auf eine neu aufkommende Klasse von Software Tools, sondern vielmehr eine neue, basisdemokratische Bewegung war, für die das Business an sich und nicht die Technologie der Auslöser war. Das Ziel ist den Unternehmen den best möglichen Ansatz zu bieten, Business Lösungen mit Hilfe von automatisierten Systemen auszubauen [19]. Im GUIDE Business Rules Project wurde weiters in der Definition das Wort Kontrolle und Einfluss in Bezug auf das Business Verhalten verwendet. Man darf hier bei den Regeln nicht immer von harten, strikten „Befehlen“ ausgehen, denn wenn man das tut, entgeht einem mindestens die Hälfte des Geltungsbereiches des Business Rules Ansatzes. Nicht zu vergessen sind hier auch die Ratschläge, Richtlinien und Methoden, die durch die Regeln gegeben werden. Im Business Rules Ansatz werden die Regeln wortwörtlich auf Fakten aufgebaut, die wiederum auf Konzepten aufbauen, die durch Terme repräsentiert werden. Wenn man versucht Business Logik so aufzubauen, hat das den Vorteil das Teile dieser Logik an anderen Stellen wieder benutzt werden können, wie zum Beispiel bei anderen Prozessen und Hardware/Software Plattformen, wodurch ein hohes Maß an Einsatzradius gegeben ist. Laut [10] stellt nach der immer schneller werdenden Entwicklung in den letzten Jahren 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 Know-how benötigt werden. ● Änderungen in der Geschäftspolitik sollen sofort umsetzbar sein.

Business Rules


Die komplette und perfekte Erfüllung dieser Forderungen ist noch Zukunftsmusik, sie zeigen aber die Richtung vor in die sich der Business Rules Ansatz entwickelt.

2.3 Das Business Rules Manifest

Die Grundgedanken des Business Rules Ansatzes sind im Business Rules Manifest zusammengefasst, das im Jahre 2002 von der Business Rules Group [18] erarbeitet wurde. Sie hatte sich bereits seit 10 Jahren mit dem Thema beschäftigt und deshalb den Begriff „Business Rules“ geprägt und kann deshalb als eigentliche „Erfinderin“ des Business Rules Ansatzes bezeichnet werden. Das Manifest hat die Aufgabe1

- „die Essenz des Business Rules Ansatzes, 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.“

Im Folgenden werden ein paar Absätze laut [10] aus dem Manifest erläutert: Geschäftsregeln sind wichtig 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. Des Weiteren gibt es noch die selbst auferlegten Geschäftsregeln, die ein Geschäft so definieren, dass die Unternehmensziele erreicht werden können. Geschäftsregelns sollen explizit formuliert werden, aber nicht versteckt in anderen Modellen, sondern als eigenständige Elemente. Das heißt in der Praxis wird eine zentrale Regelverwaltung benötigt. Trennen der Geschäftsregeln von den Prozessen Oft sind Business Rules in Prozessen versteckt, zum Beispiel in einem IT-System, das die Abwicklung der Prozesse automatisiert. Dabei wird oft vergessen, dass die meisten BR nicht nur einem Prozess gehören, d.h. nicht nur im Kontext genau einer Aktivität gültig sind, sondern eine generelle Gültigkeit besitzen. Wenn man die Prozesse erweitert oder ändert, werden in manchen Aktivitäten wichtige Geschäftsregeln vergessen. Um dies zu vermeiden muss man die BR aus Prozessmodellen und Beschreibungen entfernen und in eine zentrale Regelverwaltung überführen. Im

1 Schacher, Grässle: Agile Unternehmen durch Business Rules: s. 23

Business Rules


jeweiligen Prozessmodell können Verweise auf die entfernten Geschäftsregeln hinterlassen werden. Deklarativ und wohl definiert Business Rules müssen deklarativ und wohl definiert beschrieben sein. Deklarative Regeln beschreiben das was, während prozedurale Regeln oft das wie und das wann beschreiben. Sie sollten so strukturiert wie möglich formuliert sein. Man muss dabei aber beachten, dass man nicht in einen Konflikt zwischen Strukturiertheit und Lesbarkeit kommt, es sollt immer noch natürlich klingen und verständlich sein. Von, durch und für die Fachleute Geschäftsregeln werden durch das Geschäft erzeugt und gelten auch für das Geschäft, und nicht der Informatik. Wenn BR auf traditionelle Weise automatisiert werden, geschieht das in Form von Programmcode in einem IT-System. Aus einer Regel werden ein paar Zeilen Code. Solcherart implementierte Regeln können von Fachvertretern nicht mehr vertanden werden, oft nur durch Informatiker geändert werden und unterliegen oft einem längeren Release-Zyklus. Das heißt sie gehören nicht mehr der Fachabteilung sondern der IT-Abteilung, was zur Folge hat, dass sich die Fachabteilung nicht mehr um die Regeln kümmert und sich deren nicht mehr bewusst sind. Die Motivation für diese Geschäftsregeln ist verloren gegangen. Dies gilt 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, wie zum Beispiel Werkzeuge, die es den Fachvertretern erlauben, ihre Geschäftsregeln selber zu verwalten.

2.4 Das Business Motivation Model

Die BR gibt es nicht alleine, hinter ihnen stehen mehr als nur die Regeln allein. Sie hängen nicht in der Luft sondern basieren auf einer gesunden Grundlage der Unternehmensmotivation. Das Business Motivation Model 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. Die BR sind also nur die Spitze des Eisberges. Dieses Modell bietet ein Schema für die Entwicklung, Kommunikation und Verwaltung von Business Entwürfen als organisiertes Ganzes. Es

- sucht Faktoren zur Motivation von Business Plänen - definiert die Elemente eines Business Plans - zeigt, wie alle diese Faktoren und Elements miteinander interagieren.

Business Rules


Es gibt laut [15] 2 wesentliche Bereiche des Business Motivation Models (BMM):

1. Die Ziele die für ein Unternehmen erreicht werden sollen und die Dinge die gebraucht werden um diese Ziele zu erreichen, wie zum Beispiel Strategien, Taktiken, Policies und Business Rules.

2. Die Einflüsse, welche die Elemente eines solchen Business Plans bilden und die Beurteilung wie gut solche Einflüsse auf die Ziele wirken. (wie zum Beispiel Stärken, Schwächen, Möglichkeiten und Gefahren)

Abbildung 1: Business Motivation Model in UML-Notation (Quelle: www.brportal.org)

Die Basisidee ist es, ein Business Modell für diese Elemente zu entwickeln bevor das Systemdesign und die technische Entwicklung beginnen. In einem Business Plan werden nicht alle Elemente detailliert beschrieben, jedes ist ein essentieller Teil des gesamten Modells, wobei folgende genauer beschrieben werden:

Business Rules


Business Prozesse: Pläne beinhalten Aktionen um die sich gesetzten Ziele auch zu erreichen, die in Business Prozesse transformiert werden müssen, die Aktivitäten, einzelne Sequenzen, Abhängigkeiten und Interaktionen umfassen. Das BMM enthält Platzhalter für Business Prozesse um in gewissen Situationen die Integration von neuen Prozessen zu ermöglichen. Workflows: Hier werden die Verantwortlichkeitsbereiche der Prozesse den Rollen in der Organisation zugewiesen. Das Design von Workflows liegt außerhalb des Geltungsbereiches der Business Pläne, wobei die Pläne aber Strategien und Taktiken enthalten, die die Struktur der Organisation so bestimmen wollen, das ein effektiver Workflow zustande kommt. Vokabular: Alle Terme und Fakten, die das Unternehmen unterstützen, müssen spezifiziert werden. Im Business Plan werden diese Konzepte und Vokabel beschrieben, die als Elemente besonders in den Business Rules verwendet werden. Business Rules werden in solchen Plänen mit folgenden Absichten verwendet:

- Business Taktiken weiterzuentwickeln und die Leistung der Arbeit beizubehalten bzw. zu steigern

- Ausweichlösungen anzubieten, falls Teile des Business Plans versagen - Konflikte beheben, falls mehrere Ziele des Unternehmens einen Konflikt miteinander

haben Wegen diesen Schlüsselrollen, die oft entscheidend für das Überleben und den Erfolg eines Business Plans sind, ist die Förderung der Business Rules im BMM für ein Unternehmen mehr als nur wichtig.

Business Rules


3 Anwendungsgebiete des Business Rules Ansatzes

In [10] beschreiben Schacher und Grässle weiterhin das es ein weitreichendes Spektrum an Gebieten gibt, in denen Business Rules eingesetzt werden. Wenn man ins Internet blickt, kann man gleich einige erkennen: Kreditvergabe, Kreditkarten, Leasing, Versicherungen und Betrugserkennung. Auch Telefongesellschaften, welche BR 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. Auch in CRM(Customer Relationship Management)-Systemen findet man den Begriff häufig, zudem werden Geschäftsregeln in Berechtigungssystemen und natürlich in vielen weiteren Bereichen, wie zum Beispiel Gepäckssystemen oder Zeit- und Portoptimierungen für Pakete, eingesetzt. Business Rules braucht man in diesen Gebieten, damit diverse Projekte auch zu einem positiven Ende gebracht werden können. Denn generell kann beobachtet werden, dass BR vermehrt in erfolgreichen Projekten verwendet werden und die spezifischen Eigenschaften des Business Rules Ansatzes wie Flexibilität, einfache Änderbarkeit, usw., auch im durch Einsatz in einem Projekt als von großem Nutzen herausgestrichen werden können [20]. Es werden auch vermehrt Lösungen realisiert, die nicht in einem großen Business Rules Produkt arbeiten, sondern die Geschäftsregeln, getrennt von der Infrastruktur, mittels „traditioneller“ Programmiersprachen implementieren. Hierbei ist das wichtigste, dass man bei der Umsetzung die Denkweise des Business Rules Ansatzes in den Mittelpunkt stellt. Ein paar Anwendungsbeispiele für Business Rules sind Airline Ticketing-Systeme für Flugbuchungen, wo die Regeln getrennt von der technischen Implementierung zu halten und auszuführen sind. Ein anderes Beispiel wäre Visa International, die eine Business Rules Engine benutzt, um komplexe globale Transaktionen mit ihren 21000 Mitgliederbanken durchzuführen, damit bankspezifische Businessstrategien verwirklicht werden. Des Weiteren ist die interne Verwaltung von Wertschriften in einer Bank gemäß internationaler Regulatorien und bankinterner Strategien ein anderes Beispiel für ein Anwendungsgebiet [20]. Die Einsatzbereiche von Business Rules werden immer vielfältiger. Auch große Softwarehersteller wie IBM, Oracle oder Microsoft erweitern ihre Technologie mit diesem Ansatz. Aus diesem Grund kann eine weitere Zunahme der Business Rules in Projekten angenommen werden [10].

Business Rules


4 Arten von Business Rules

Laut [10] werden Business Rules in verschiedene Arten ( term rules, fact rules, action rules, event-action rules...) kategorisiert, es haben sich aber üblicherweise 3 Typen der Business Rules in der Literatur durchgesetzt: Einschränkungen (Constraints), Ableitungsregeln (Derivation Rules) und Prozessregeln (Reaction Rules). Diese verschiedenen Regeln können auch in manchen Fällen vom Business Level in ausführbaren Code (im IS) umgewandelt werden (siehe Abbildung 2). Concept Implementation Constraints If-then statements in programming languages;

DOMAIN, CHECK and CONSTRAIN clauses in SQL table definitions; CREATE ASSERTION statements in SQL database schema definitions

Derivation Rules Daductive database (or Prolog) rules; SQL CREATE VIEW statements Reaction Rules If-then statements in programming languages;

CREATE TRIGGER statements in SQL; Production rules in ‘expert systems’

Abbildung 2: Umwandlung der BR vom Business Level in ausführbaren Code (Quelle: Taveter, Wagner:

Agent-Oriented Enterprise Modeling Based on Business Rules. Eindhoven. 2001. S 530)

4.1 Ableitungs-bzw. Strukturelle Regeln (Derivation Rules)

Ableitungsregeln sind Regeln, „die eine neue Information aus bestehenden Informationen herleiten“2. z.b.: - Eine Person ist auf der schwarzen Liste, falls eine an sie gelieferte Bestellung nicht innerhalb von 30 Tagen bezahlt wurde. - Die Information „Person ist auf der schwarzen Liste“ wird hier abgeleitet. Ein anderes Beispiel wäre: „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.

2 Schacher, Grässle: Agile Unternehmen durch Business Rules: 2006. S. 18

Business Rules


Strukturelle Business Rules sind Aussagen, die in einem Unternehmen verwendet werden. Hier gibt es verschiedene Level: Bsp.: - Eine Telefonverbindung ist eine Anlage. Hier wird beschrieben, was eine Telefonverbindung ist. Es beschreibt die Anforderungen eines Unternehmens, also dass eine Telefonverbindung eine Anlage ist, nicht nur ein Equipment. Dieser Typ von Business Rules wird meistens von Experten erkannt, erfordert also keine Implementation in einem Informationssystem. Weitere Beispiele wären: Kunden werden durch ihre Adresse und ZIP-Code identifiziert. Ein Kunde gibt eine Bestellung auf. Ein Kunde ist eine Person. Ein Auto besteht aus Reifen und einer Karosserie.

4.2 Einschränkungen-oder Bedingungsregeln (Constraints)

Aussagen über das Geschäft, die immer wahr sein müssen bzw. immer genau so gelten müssen und an die man sich halten muss, wie Verbote oder Gebote. Bsp.:

- Ein Kunde darf seine Kreditlimite nie überschreiten. - Jede aktive Bestellung darf nur aktive Produkte enthalten.

Diese Regeln beinhalten Statements über die Bedingungen, unter denen eine Firma arbeitet. Sie veranschaulichen den Status der Objekte (in diesem Beispiel Kunden und Bestellungen), und versichern, dass nur Aktionen ausgeführt werden können, die auch in gültigen Zuständen enden. Bsp.:

- Kunden können kein Geld abheben, wenn ihr Konto überzogen wurde. - Ein Kunde muss mindestens ein Konto haben, darf aber nicht mehr als drei

besitzen - Für jede Transaktion muss es ein Datum geben. - Aktive Konten müssen von Kunden benutzt werden.

Business Rules


4.3 Prozess-oder Verhaltensregeln (Reaction Rules)

Prozessregeln sind Regeln, die Aktionen anstoßen, verhindern oder erlauben. Es sind Anweisungen die besagen, dass in gewissen Situationen gewisse Aktionen ausgeführt werden müssen, dürfen oder aber nicht ausgeführt werden dürfen. Beispiele:

- Wenn ein neuer Kunde eine Bestellung aufgibt, muss seine Kreditwürdigkeit geprüft werden.

- Guinness muss empfohlen werden, falls Heineken bestellt wird. Verhaltensregeln sind Statements über dynamische Aspekte in einem Unternehmen. Sie beschreiben, was mit etwas als Antwort auf eine andere Sache passieren wird, und in wiefern die Aktionen, die daraufhin passieren, einen Einfluss auf den Status haben. Beispiele dafür wären: - Wenn ein Versicherungsanspruch neu erhoben wird, wird diesem eine Erhebungsnummer zugeteilt. - Wenn ein Kunde Geld abhebt, wird dies vom zugehörigen Konto abgebucht. Diese Beispiele veranschaulichen schön, dass wirklich jedes Unternehmen Geschäftsregeln besitzt, viele sie aber nicht dokumentiert haben, und deshalb ist die Dokumentation eines der wichtigsten Ziele neben denen, die in Kapitel 6 genannt worden sind.

Business Rules


5 Eigenschaften von Business Rules

Eine Business Rule ist laut Schacher und Grässle3 „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.“ Sie besitzt folgende Eigenschaften:

- Sie ist so präzise, dass sie eindeutig ist und keinen Interpretationsspielraum offen lässt.

- Sie soll für MitarbeiterInnen von Fachabteilungen verständlich sein, es darf kein spezielles Fachwissen für ihre Interpretation notwendig sein.

- Sie ist deklarativ formuliert, d.h. sie soll beschreiben WAS gelten soll aber nicht WIE

es zu erreichen ist.

- Sie ist deklarativ, nicht prozedural. Sie beschreibt einen Status, der erreicht werden soll, oder eine Situation, die verhindert werden soll. Sie ist möglicherweise konditional, also wenn etwas der Fall ist, muss oder muss eben nicht etwas anderes der Fall sein. Sie beschreibt nicht die Schritte, die notwendig sind, um von einem Status in einen anderen zu kommen. Business Rules repräsentieren Praktiken und Methoden, die in einem Unternehmen von wichtigster Bedeutung sind. Sie entscheiden, was möglich und wünschenswert ist, um ein Unternehmen am Leben zu halten. Ein Unternehmen hat im Normalfall viele verschiedene Business Rules, wobei sich manche ähneln oder voneinander abstammen können. Alle Regeln müssen als ein Ganzes gesehen werden, damit man die Firmenpolitik verstehen kann, indem man sie in verschiedene Modelle(siehe Kapitel 8) einbaut um ein homogenes Ganzes zu erreichen. Die Geschäftsregeln eines Unternehmens können unterschiedlich gehandhabt werden. Manche werden formal dokumentiert und gelten so als die offizielle Unternehmenspolitik, andere wiederum werden nur in den betrieblichen Ablauf eingebaut.

3 Schacher, Grässle: Agile Unternehmen durch Business Rules: S. 124

Business Rules


Mit dem Aufkommen des Computers unterstützen jetzt Business Rules immer mehr die Informationssysteme (IS). Ein Beispiel für eine Business Rule, die ein Unternehmen haben könnte ist folgendes: ‚Kunden, die innerhalb der letzten 2 Jahre keine Bestellung gemacht haben, werden am Ende jedes Monats als nicht aktiv markiert.’ Als Beispiel kann Kundeninformation in einer Datenbank gespeichert werden und die zugehörige BR als Datenbank Trigger implementiert werden: EVENT Ende des Monats CONDITION Kunde hat innerhalb der letzten 2 Jahre keine Bestellung gemacht ACTION Kunden als nicht aktiv markieren Weiters gibt es die Möglichkeit, Business Rules aus IS wiederzuerlangen und Benutzern explizit zugänglich zu machen. Das kann folgende Vorteile mit sich bringen:

- Erhöhung der Qualität der Daten: Die Daten werden exakt und genau verstanden, was für die Benutzer essentiell ist.

- Entwicklung von BR: Durch bestimmte Umstände wie zum Beispiel das Verlassen einer Mitarbeiterin oder eines Mitarbeiters eines Unternehmens kann es passieren, dass gewissen Regeln einfach verloren gehen. Das Modifizieren oder Weiterentwickeln von bestehenden BR, und das sich somit damit Beschäftigen, erhöht die Erreichbarkeit der Regeln und das Verständnis jeder Person, sodass solche Probleme nicht mehr auftreten sollten.

- Pflege von bestehenden Geschäftsregeln: Der Zugang zu den Geschäftsregeln erleichtert System Technikern die Wartung und Pflege.

Business Rules


6 Probleme der Unternehmen

6.1 Bewältigung durch Business Rules Ansatz

1) Fehlende Motivation:

Sinnvolle und motivierte Regeln sind laut [10] Regeln die etwas zur Erreichung der Unternehmensziele beitragen. Das Gegenteil ist eine unsinnige oder unmotivierte Regel. Diese - trägt nichts zur Erreichung der Unternehmensziele bei oder behindert deren Erreichung - regelt etwas nicht Relevantes bzw. etwas was selten vorkommt und nicht sehr wichtig ist - ist nicht mehr aktuell bzw. der Grund für die Einführung der Regel ist nicht mehr Aktuell. Explizit machen einer Regel: Zur Überprüfung der Motivation einer Regel durch explizite Regeln kann man das Verhalten eines Unternehmens immer wieder an die sich ständig ändernde Gegebenheit anpassen: - Explizite Regeln schützen das Unternehmen vor Wissensverlust. Auch wenn wichtige MitarbeiterInnen das Unternehmen verlassen bleibt das explizit gemachte Wissen erhalten. - Explizite Regeln können auf Konsistenz und Vollständigkeit überprüft werden. Konflikte oder Lücken von Regeln zu entdecken wird einfacher. - Explizite Regeln sichern ein konsistentes Verhalten des Unternehmens.

2) Fehlende Agilität: Zurzeit gibt es in Unternehmen häufig Spannung zwischen Automatisierung + Standardisierung und andererseits Individualisierung. Diese beiden Trends stehen in Konkurrenz zueinander und lassen sich nur schwer gleichzeitig befriedigen. Daneben gibt es noch das Problem der IT-Falle, bei der es sich darum handelt, das die Anpassung der IT-Systeme immer teurer und aufwändiger wird und daher oft nicht in nützlicher Frist realisiert werden kann.

Es ist nicht mehr das Geschäft, das die IT bestimmt, es ist die IT, die das Geschäft bestimmt.

3) Fehlende Compliance:

Es wird überprüft ob die Regelungen ein konformes Verhalten des Unternehmens sicherstellen, d.h. es muss gesetzeskonform arbeiten. Ziel ist, die Regeln zu dokumentieren, vollständig, konsistent und interpretationsfrei zu

Business Rules


halten, sowie sie zumindest teilweise zu automatisieren. Weitere Probleme die auftreten wenn man Business Rules in Unternehmen nicht richtig einsetzt bzw. nicht regelmäßig wartet sind:

- Fehlende Dokumentation der Geschäftsregeln - Business Rules werden in Programm Code „begraben“. Es ist oft nicht klar welche

Regeln zu welcher Applikation gehören und wie sie implementiert sind. - Die Business Logik ist schwer aufrechtzuerhalten, wenn die Regeln über die gesamte

Logik der Applikation verstreut sind. - Business Rules sind schwer zu kontrollieren, wenn sie nicht in einen allgemeinen

Speicher abgelegt werden, der nur zur Speicherung dieser dient. Durch Business Rules werden eben genau diese Probleme aus der Welt geschafft. Der Business Rules Ansatz bringt dem Unternehmen also genau diese Reihe von Vorteilen:

- motivierte Unternehmen - agile Unternehmen - Unternehmen die regelkonform funktionieren

6.2 Entstehung durch Business Rules

Auch die Einsetzung von Business Rules können Probleme entstehen. Die 2 Hauptprobleme der Unternehmen sind:

6.2.1 Inkonsistente Durchführung der Business Rules

Die erste Implementierung im Informationssystem eines Unternehmens läuft noch wie gewollt ab. Es wird die Firmenpolitik befolgt und es treten kaum Differenzen auf. Nach einiger Zeit weichen die angepeilten Business Rules von den tatsächlich implementierten Business Rules ab, da das System immer weiter wächst und älter wird. Mit der Zeit geht Wissen rund um die implementierten Business Rules verloren, was dazu führt, dass zeitweise Pflege, unter Unständen auch vom falschen Personal, nicht richtig durchgeführt wird und die Business Rules, die das Unternehmen einmal als Ziel gehabt hat, schon lange nicht mehr mit denen konsistent sind, die vom Informationssystem durchgeführt werden. Daraus folgt, dass sich die Firma in ihrem Wachstum und ihrer Kapazität blockiert fühlt.

Business Rules


6.2.2 Missverständnis der Business Information

In manchen Organisationen führen Informationssysteme Business Rules aus, die den Benutzern gar nicht bekannt sind. Dadurch sind die angelieferten Daten dann oftmals aus dem Zusammenhang gerissen und für Benutzer nicht verständlich. Ein Beispiel dafür wäre ein Warenlager, das Kundeninformationen nach bestimmten Business Rules abspeichert, wie zum Beispiel ob ein Kunde noch ‚active’ ist oder nicht. Ein Benutzer dieses Systems, der diese Regeln nicht kennt, ist möglicherweise nicht in der Lage zwischen den verschiedenen Typen von Inaktivität zu Unterscheiden. Das führt dann dazu, dass Kunden Sachen zugeschickt werden, obwohl diese eigentlich inaktiv sind. Des Weiteren geht viel Zeit verloren nur für die Suche der Daten, die wirklich relevant für den Kunden sind.

Business Rules


7 Entscheidungstabellen

„Entscheidungstabellen dienen zur besseren Darstellung und Beschreibung von Entscheidungsprozessen. Sie fassen in prägnanter und eindeutiger Art und Weise alle Bedingungen zu einem Thema und die daraus zu schließenden Folgerungen zusammen“ 4: Tabellenbezeichnung R1 R2 R3 R4 R5 R6 R7 R8 Bedingungen Bedingung 1 j j j j n n n n Bedingung 2 j j n j j n n n Bedingung 3 j n j n j n j n Aktionen Aktion 1 x x x Aktion 2 x x Aktion 3 x x x x x Aktion 4 x x x Aktion 5 x

Tabelle 1: Beispiel einer Entscheidungstabelle (Quelle: http://de.wikipedia.org/wiki/Entscheidungstabelle)

Die Spalten R1 bis R8 bezeichnen die jeweiligen Regeln. Am Beispiel der Regel 7 sei erläutert, wie die Regeln zu lesen sind:

Wenn die Bedingung 3 erfüllt ist, die Bedingungen 1 und 2 hingegen nicht, dann sind die Aktionen 1 und 4 auszuführen [4].

Eine Entscheidungstabelle beinhaltet die einzelnen Regeln der Form Wenn <Bedingung> dann <Folgerung> Oder etwas genauer Wenn <Teil-Bedingung 1> und <Teil-Bedingung 2> und <Teil-Bedingung n> Dann <Teil-Folgerung X> und <Teil-Folgerung Y> und <Teil-Folgerung m> Sowohl Teil-Bedingungen und als auch Teil Folgerungen bestehen aus Kriterien und ihren möglichen Werten, die aus dem Faktorenmodell stammen. Durch Kreuze in den Regel-Kolonnen kann nun festgelegt werden, welche Kombination von Teil-Bedingungen zu welcher Kombination von Teil-Folgerungen führt.

4 Schacher, Grässle: Agile Unternehmen durch Business Rules: s. 126ff.

Business Rules


Die folgende Tabelle kann als Beispiel gesehen werde, das es veranschaulicht, welches Freizeitprogramm an einem freien Sonntag zur Anwendung kommen soll:

Regel 1 2 3 4 5 6 7 Bedingung

Vormittag x x x Nachmittag x x x

Tageszeit

Abend x x x Regen x x Bedeckt x x x

Wetter

Sonnig x x Folgerung

Schlafen x Spazieren x x x Kino x x x

Tätigkeit

Fernsehen Schlafen x Spazieren x Kino x

Alternative

Fernsehen x x x Tabelle 2: Entscheidungstabelle „Freizeitprogramm“ (Quelle: Schacher, Grässle: Agile Unternehmen

durch Business Rules: s. 128)

Auch hier können die Kolonnen wieder als Regel formuliert werden, was im Falle von

Kolonne 2 so aussehen würde:

Wenn die Tageszeit Nachmittag oder Abend und

Das Wetter regnerisch ist

Dann wäre Kino eine passende Tätigkeit und

Fernsehen eine Alternative

Entscheidungstabellen eignen sich grundsätzlich für alle Arten von Geschäftsregeln. „Einerseits kann die Folgerung auch direkt als Aufforderung zu Aktivitäten verstanden werden um damit Prozessregeln auszudrücken. Andererseits können die ausgefüllten Kolonnen als erlaubte Kombinationen 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“5.


Business Rules


8 Modellierung von Business Rules

Auch in einfachen Unternehmen basieren die Applikationen des Informationssystems laut [17] auf Business Rules. Alle Business Rules müssen zuerst aus den Business Ausdrücken in den Applikation Code umgewandelt werden. So wird dann letztendlich der Source Code zum Entwurf der Regeln und Politik eines Unternehmens. Das Auftauchen einer Business Rule ist laut von Halle6 ein „formaler Weg der Automatisierung von Business Rules einer Organisation, damit sich das Business so verhält, wie es die jeweilige Führung verlangt“. Business Rules repräsentieren Politik, Wissen und Kompetenz eines Unternehmens und sind ein wichtiger Bestand der Organisation, insbesondere des Managements. Um dies zu erreichen müssen sie klar formuliert sein, automatisch angepasst werden und immer bereit für Veränderungen sein. Mit Hilfe des richtigen Designs und der richtigen Analyse des Informationssystems kann dieses Ziel erreicht werden, indem man den Fokus dabei auf die Formalisierung und die Offenlegung legt. Für die Erzeugung von Business Rules gibt es so genannte „Business Rules Engines“, die Entitäten erzeugen, die entweder final oder non-final sein können. Die non-final entity benötigt noch eine Evaluierung durch die Engine, was bei der final entity nicht der Fall ist. Eine Entität ist evaluiert wenn alle ihre Attribute genau definiert sind. Es gibt 4 Typen von Entitäten des Informationssystems: database entities (oder objects), die benutzt werden für die Interaktion zwischen einem Client und einem Datenbankserver; file entities (oder objects), die für die Interaktion zwischen Client und Fileserver; webpage oder service entities, die in den Anfragen von Web Clients oder Web Service Clients zu Web Servern oder Web Services verwendet werden; und service entities, die in Anfragen auf EIS(Enterprise Information Systems) benutzt werden. Diese 4 Entitäten werden non-primitive entities genannt. Wenn man sich die vier non-primitive types genauer anschaut erkennt man das jede non-primitive Entität mit einem Information System Server assoziiert ist: Database, File, Web Server oder ein Information System Service. Die Engine evaluiert die Entität, indem ein Request an den jeweiligen Server oder an das Service geschickt wird. Die speziellen Regeln für jede Entität Evaluierung sind in der jeweiligen Definition vorhanden. Eine Entität ist primitive, wenn die Business Rules Engine die Entität evaluieren kann, ohne ein einziges Mal einen Server bzw. Service benutzen zu müssen.

6 B. von Halle: Business Rules Applied. New York. 2002. zit. in: Zsifkov, Campeanu: Business Rules Domains and Business Rules Modeling. S 172.

Business Rules


Ein Information System Request besteht immer aus einem System Client, einem System Server und dem Event. Bei jedem Request das eine Business Rules Engine erhält wird zuerst die Entität des Events evaluiert. Für jedes Request gibt es maximal eine Business Rule. Ein formales Beispiel [17] für eine Business Rules ist: if boolean-expression then

[process the event] //falls ein Ausdruck zutrifft, führe Events für den Fall ‚true’ aus serviceEventTrue1 serviceEventTrue2 . . . return true/success

else //falls ein Ausruck nicht zutrifft, führe alternative Events für den //Fall ‚false’ aus

serviceEventFalse1 serviceEventfFalse2 . . . return false/failure

Enterprise Knowledge Development Modell Eine weitere Möglichkeit der Modellierung ist das Enterprise Knowledge Development Modell, eine Art der Darstellung der Architektur ist in Abbildung 3 dargestellt.

Abbildung 3: Enterprise Knowledge Development Modell (Quelle: Bajec, Krisper: A methodology and tool

support for managing business rules in organisations. 2004. S. 428)

Business Rules


Hier gibt es 5 Untermodelle, von dem eines das Business Rule Modell ist:

- Business Vision Model: Beschreibt eine allgemeine Strategie eines Betriebes mit den Zielen und den Problemen, die gelöst werden müssen um diese Ziele zu erreichen.

- Business Process Model: Beschreibt die Prozesse, die festgesetzt werden, um die Ziele eines Betriebes zu erreichen. Es beschreibt wie sich ein Betriebsprozess verhält und klärt den Input und Output eines Prozesses.

- Business Rule Model: Definiert und hält die expliziert formulierten Business Rules in stand, genauso wie die Regeln, die implizit in anderen Modellen vorhanden sind.

- Business Actors and Resource Model: Konzentriert sich mehr auf die Strukturen der Ressourcen und deren Beziehungen zu den Akteuren, Prozessen, Zielen und anderen Komponenten des Enterprise Models.

- Business Concepts Model: Hier wird eine gängige „Sprache“ entwickelt um die Konzepte, die in der Umgebung des Betriebes verwendet werden, zu beschreiben. Dieses Model verhindert Missverständnisse und Falschinterpretationen von diversen Termen.

Meta-Model aus Business Level und IS Level Laut [1] zeigt das Model in Abbildung 4 die wichtigsten Informationen über Business Rules, die durch den Lebenszyklus und das darin enthaltene IS dargestellt werden können. Dieses Meta-Model ist in 2 Sektionen unterteilt, die erste beinhaltet Business Level Elemente, die andere Konzepte, die für das IS Level interessant sind. Im Business Level ist jede Business Rule in einer Business Language (Business Description) beschrieben, die für die Personen im jeweiligen Unternehmen verständlich ist. Zwischen den Regeln bestehen verschiedene Beziehungen, zum Beispiel unterstützt eine Regel eine andere, oder eine Regel steht im Konflikt mit einer anderen (Rule Impact). Jede Regel hat eine History, die erklärt, ab wann Sie eingesetzt wurde und was an Ihr und durch Sie mit der Zeit verändert worden ist. Das Konzept Current Status gibt die aktuelle Position der Regel an (z.b. suggested, accepted, put into operation, declined, etc.). Wichtig ist immer dass man seine Quellen, wie zum Beispiel Richtlinien, Vorschriften oder andere administrative Gesetze, dokumentiert (Documentation). Eine andere Quelle von einer Business Rule könnte auch ein anderes Element sein, das in Enterprise Models modelliert wurde, wie zum Beispiel ein Ziel oder ein Prozess (Enterprise Model Element). Die Effizienz einer Geschäftsregel (Rule Efficiency) beschreibt wie effizient eine Regel in Bezug auf die Erreichung der Ziele ist. Die Effizienz wird üblicherweise dadurch gemessen, dass man schaut, in wie weit die Regel eine einschränkende Wirkung hat bzw. in wie weit sie als Auslöser für eine andere Sache gesehen werden kann.

Business Rules


Abbildung 4: Meta-Model von Business Rules bestehend aus Business Level und IS Level (Quelle: Bajec,

Krisper: A methodology and tool support for managing business rules in organisations. 2004. S. 430)

Im IS Level müssen Business Rules atomar in der Hinsicht sein, das sie nicht weiter „zerfallen“ dürfen ohne ihre Bedeutung zu verlieren (Atomic Business Rule). Seit Beschreibungen von Regeln an Bedeutung zugenommen haben, werden formale Sprachen immer mehr verwendet (Formal Description). Um die Formalisierung zu vereinfachen und die Implementierung zu unterstützen werden die Regeln meist kategorisiert (Category). Zu guter Letzt ist jede Business Rule im System mit einer oder mehreren IS physischen Komponenten (IS physical components) verbunden, was eine wichtige Information ist um zu wissen wo und wie die Regel implementiert ist.

Business Rules


8.1 Business Rules als Reaction Rules

Business Rules, die das interaktive Verhalten von Agents definieren, werden am besten durch Reaction Rules formalisiert. Das sind die Regeln, bei denen der agent-orientierte Ansatz am viel versprechendsten ist. Zugleich scheinen sie der wichtigste Typ von BR zu sein. In Abbildung 5 ist der Prozess einer Autovermietung basierend auf 3 Reaction Rules modelliert worden.

Abbildung 5: Reaction Rule Model einer Autovermietung (Quelle: Taveter, Wagner: Agent-Oriented

Enterprise Modeling Based on Business Rules. Eindhoven. 2001. S. 10)

Eine Reaction Rule wird mit einem Kreis mit ausgehenden und eingehenden Pfeilen dargestellt. Jede Rule hat genau einen eingehenden Pfeil, der die auslösende Event Bedingung repräsentiert. Weiters kann es noch weitere einfache, eingehende Pfeile geben, die Status Bedingungen repräsentieren. Bei R1 wird ein Request von einem Customer empfangen, der ein Auto einer bestimmen CarGroup mieten will. Falls das Auto in einer gewissen Periode vorhanden ist, was durch das evaluieren des Prädikates hasCapacity der Instanz CarGroup erreicht wurde, sendet die Branch eine Abfrage an das Headquarter um sicherzugehen das der Customer nicht blacklisted ist.

Business Rules


R2 bekommt die Anfrage von der Branch ob ein Customer blacklisted ist. Dieses wird kontrolliert, und wenn dies nicht der Fall ist, wird ein ‚no’ zurückgeschickt. Nachdem vom Headquarter die Antwort kommt, das der Customer nicht blacklisted ist, führt in R3 die Branch die Reservierung durch, bestätigt dem Customer das ein Auto zur Verfügung gestellt wird, sendet ein Request zum Timer Agent und sendet dem Customer eine Bestätigung der Reservierung. Eine Reaction Rule kann auch in textueller Form bestehen. R1 aus unserem vorigen Beispiel könnte so dargestellt werden:

Abbildung 6: Regel 1 aus Abbildung 5 in textueller Form (Quelle: Taveter, Wagner: Agent-Oriented Enterprise

Modeling Based on Business Rules. Eindhoven. 2001. S 537)

und R3 könnte so formuliert werden:

Abbildung 7: Regel 3 aus Abbildung 5 in textueller Form (Quelle: Taveter, Wagner: Agent-Oriented Enterprise

Modeling Based on Business Rules. Eindhoven. 2001. S 537)

Weiters gibt es noch andere Modelle wie zum Beispiel die Ross Notation, den Enterprise Knowledge Development Approach, konzeptionelle Graphen oder andere auf UML basierende Modelle, auf die hier aber nicht näher eingegangen wird.

Business Rules


9 Formulierung von Geschäftsregeln

Die Formulierung der Geschäftsregeln erfolgt in 2 Schritten. Zuerst müssen die Regeln bei der Externalisierung(Nach-außen-Verlagerung) des Geschäftswissens dokumentiert werden. Weiters muss dieses Geschäftswissen ständig gepflegt und neuen Gegebenheiten angepasst werden. Die Identifikation und Formulierung der Business Rules ist in beiden Schritten dieselbe und kann laut [10] in 7 Schritte unterteilt werden: 1. Regelungen priorisieren

Um die Geschäftsregeln formulieren zu können, muss für ein Unternehmen zuerst einmal klar sein welche Regelungen die wichtigsten sind, die umgesetzt werden wollen. Diese sollten „priorisiert und zu handhabbaren Gruppen zusammengestellt werden“. Folgende Faktoren sind bei der Auswahl am wichtigsten:

- Compliance: Welche Einflussfaktoren (Unternehmenspolitiken, Taktiken,...) sind für das Unternehmen wichtig, bzw. gibt es neue oder äußere Einflussfaktoren die noch nicht miteinbezogen wurden?

- Agilität: Auf welche neuen Markteinflüsse muss wie reagiert werden, wie zum Beispiel neue Angebotspakete oder neue Preisstrategien als Reaktion auf die Konkurrenz.

- Motivation: Fehlt gewisses Know-How bei den Mitarbeiterinnen und Mitarbeitern, wodurch Probleme entstehen können?

Falls schon Regelungen vorhanden sind, müssen diese natürlich nur mehr aktualisiert werden falls sie etwaige Mängel haben. Die Personen, die mit der Ausarbeitung der Regelungen beschäftigt werden, können meist im frühen Stadium bestimmt werden. 2. Regelungen klassifizieren

Nachdem die Regelungen festgelegt wurden, die noch genauer bearbeitet werden sollten, werden sie nach den Regelarten (siehe Kapitel 4) klassifiziert. „Bei dem größten Teil der Regelungen dürfte es sich erfahrungsgemäß um Ableitungen handeln.“7


Business Rules


3. Durchsetzungsgrade bestimmen

Nach den vorigen Regelungs-Klassifizierungen lassen sich die notwendigen Durchsetzungsgrade festlegen. Hier wird also überlegt, was bei einer Verletzung dieser Regelungen passieren soll. Beispiele solcher Durchsetzungsgrade (laut http://www.omg.org/), welche aber keine Vorlage sein sollen, sondern auch ergänzt werden können, sind

- Strikte Durchsetzung: Bei Verletzung der Geschäftsregel kommt immer eine Strafe zur Anwendung.

- Vorgängige Autorisierung: Die Geschäftsregel wird durchgesetzt, allerdings sind Ausnahmen möglich, falls diese vorher autorisiert wurden.

- Mit Begründung: Die Geschäftsregel darf verletzt werden, allerdings muss eine solche Verletzung begründet werden.

4. Grundlagen identifizieren

„Jede Regelung basiert auf Informationen aus dem Faktenmodell, welche als Grundlagen in den Regeln verwendet werden.“ Besonders bei den Ableitungen sollte man sich genau überlegen, auf welchem Fakttyp sie basiert, noch bevor die Formulierung der Geschäftsregeln beginnt. 5. Werkzeug zur Verwaltung des Regelkatalogs festlegen

Um das gesamte Wissen, das hier behandelt wird, möglichst nicht zu verfremden und gut zu behandeln, empfiehlt es sich, einige elektronische Hilfsmittel zu verwenden, um die Regelungen zu erfassen und zu verwalten. Diese Hilfsmittel sollten laut [10] folgende Anforderungen erfüllen:

- Unterstützung verschiedener Formalismen (Entscheidungstabellen, formales Deutsch..)

- Integration des Unternehmensvokabulars - Strukturierungs- und Gruppierungsmöglichkeiten - Flexible Suchmöglichkeiten - Funktion zur Publikation

Von der Benutzung von einfachen Textverarbeitungsprogrammen wird abgeraten, da diese viele dieser Anforderungen nicht entsprechen und dadurch die Geschäftsprozessmodellierung um einiges erschwert wird.

Business Rules


6. Geschäftsregeln erarbeiten

Um Business Rules zu erarbeiten, müssen sie entweder aus den Regelungen erarbeitet werden oder sie liegen bereits in irgendeiner Form vor und müssen „auf einheitliche Art (neu-) formuliert und mit dem Unternehmensvokabular abgestimmt werden“. Der Grund warum Regeln schon teilweise vorhanden sein können sind unter anderem „Arbeitsanweisungen, Richtlinien, Personalhandbücher, aber auch bestehende IT-Applikationen, die bereits heute eine große Anzahl von Geschäftsregeln automatisieren“8. Bei bereits bestehenden Geschäftsregeln sollte man weiters beachten ob diese Regeln noch „zeitgemäß“ sind, d.h. der heutigen Geschäftspolitik entsprechen. Oftmals kann es sein das solche Regeln schon „veraltet“ sind und deshalb gar nicht mehr zutreffen, deshalb sollte man dabei immer darauf achten sie kritisch zu hinterfragen. 7. Unternehmensvokabular aktualisieren

Während der Formalisierung der Geschäftsregeln entstehen oft neue Begriffe, die in dieser Form noch nicht im Unternehmensvokabular enthalten sind. Deshalb sollte nach jeder Aktualisierung von Regelungen auch das Unternehmensvokabular überprüft und gegebenenfalls auf den neuesten Stand gebracht werden. Bei der Formulierung der Geschäftsregeln kommt es nicht darauf an die Regeln möglichst schnell zu finden, viel wichtiger ist es sie dauernd aktualisiert und gepflegt zu halten. Bei der Suche nach Geschäftsregeln ist es wichtig, möglichst verschiedenartige Regeln zu finden, damit durch ein breites Spektrum an Business Rules verschiedenste Anforderungen an das Faktorenmodell gestellt werden, damit dieses bereits sehr früh möglichst umfassend und stabil wird.


Business Rules


10 Fazit

Zum Abschluss lässt sich sagen, dass sich bei der Entwicklung im Bereich der Business Rules in den letzten Jahren einiges getan hat. Unter einer Geschäftsregel an sich versteht man heutzutage nicht mehr nur die Regel als eine Vorschrift an sich, an die sich Unternehmen zu halten haben, sondern auch als eine einfache Aussage, welche Ziele ein Unternehmen hat, wie es sich verhalten soll oder einfach ein paar Bestimmungen für technische Sachverhalte. Business Rules haben ganz einfach die wichtige Aufgabe, den Betrieb mit den verschiedenen Politiken und Taktiken mit dem Informationssystem zu verbinden, und so das Ziel zu erreichen offen und flexibel für Veränderungen zu sein. Weiters finden immer mehr Systeme Gefallen an der Systematik der Business Rules, und die Änderungsrate in der Geschäftswelt wird weiter ansteigen. Schon allein durch den Druck, der durch den Markt und der Konkurrenz erzeugt wird, müssen sich viele Unternehmen anpassen, damit sich Änderungen in immer kürzerer Zeit bewältigen lassen können. Die Anzahl an Applikationen, welche die variablen Business Rules anwenden, war im Jahr 2002 bei 10-15 Prozent und wird für das Jahr 2007 auf 30-35 Prozent geschätzt anwachsen [20]. Dadurch, dass derzeit die größten Probleme die durch die BR entstehen, erkannt werden, wird es in den nächsten Jahren noch zu einigen Verbesserungen in der Qualität kommen. Das langfristige Ziel ist das Business Rules Management als Prozess, in welchem die Änderung einer Regel eine vorhersehbare und geplante Auswirkung hat28. Es gibt viele verschiedene Arten, Business Rules darzustellen und zu modellieren. Doch bei allen kommt es im Wesentlichen drauf an, wie die Regeln in den Betrieb integriert werden, und die Unternehmenspolitik beeinflussen und steuern. Sie sind eines der wichtigsten Bestandteile des Betriebes, ohne das die Steuerung, Verwaltung und Veränderung der Geschäftseinheiten deutlich erschwert sein würde. Zusammenfassend kann man sagen, dass das Gebiet Business Rules im Moment im Umbruch ist. Es handelt sich um eine viel versprechende Technik, die erwarteten Effekte werden aber sicher nicht kurzfristig erzielt werden [20]. Mit der Verankerung der Business Rules in den Informationssystemen und der gezielten Modellierung wird man die Effekte erst nach einiger Zeit erzielen.

Business Rules


11 Literaturverzeichnis

[1] Bajec, Krisper: A methodology and tool support for managing business rules in organisations. Ljubljana. 2004

[2] De Tommasi, Corallo: SBEAVER: A Tool for Modeling Business Vocabularies and Business Rules. Lecce. 2006 [3] http://de.wikipedia.org/wiki/Business_Rule [4] http://de.wikipedia.org/wiki/Entscheidungstabelle [5] Kardasis, Loucopoulos: A roadmap for the elicitation of business rules in information systems projects. Athens. 2005 [6] Mues et. Al.: From Knowledge Discovery to Implementation: A Business Intelligence Approach Using Neural Network Rule Extraction and Decision Tables. 2005. [7] Mugridge: Expressing Business Rules. New Zealand. 2005 [8] Rosca et. Al.: Enterprise Modeling and Decision-Support for Automating the Business Rules Lifecycle. Netherlands. 2002 [9] Sandtner, Oliver: Business Rules. Karlsruhe. 2000. [10] Schacher, Grässle: Agile Unternehmen durch Business Rules. Leipzig. 2006. [11] Shao, Pound: Extracting business rules from information systems. 1999. [12] Snoeck, Michiels: Domain Modelling and the Co-Design of Business Rules in the Telecommunication Business Area. Leuven. 2002 [13] Spreeuwenberg, Gerrits: Business Rules in the Semantic Web, Are There Any or Are They Different? Amsterdam. 2006 [14] Taveter, Wagner: Agent-Oriented Enterprise Modeling Based on Business Rules.

Eindhoven. 2001. [15] The Business Rules Group: The Business Motivation Model – Business Governance in

a Volatile World. 2005 [16] Valatkaite, Vasilecas: A Conceptual Graphs Approach for Business Rules Modeling. Vilnius. 2003

Business Rules


[17] Zsifkov, Campeanu: Business Rules Domains and Business Rules Modeling. York. [18] www.businessrulesgroup.org [19] www.brcommunity.org [20] www.brportal.org

Documents

Business Rulesmedia.tuwien.ac.at/fileadmin/user_upload/htellioglu/...Business Rules Praktikum Seite 7 von 32 6. Semester jeweiligen Prozessmodell können Verweise auf die entfernten