Business Rule Management Systemewinf-wiki.fhslabs.ch/images/9/9e/2011_WISE_DROOLS... · 2019. 11....

BUSINESS RULE MANAGEMENT

SYSTEME (BRMS) Verfasser/in: Dominik Löliger, Daniel Ritter

Projektcoach: Prof. Dr. Rainer Endl

Wirtschaftsinformatikseminar an der FHS St.Gallen,

Hochschule für Angewandte Wissenschaften

2011

FHS-Projektteam:

Dominik Löliger Daniel Ritter

Projekt-Coach:

Prof. Dr. Rainer Endl

Eingereicht am:

Freitag, 6. Januar 2012

Quelle Titelbild: http://www.ultimus.com/Portals/54405/images//131.jpg

Vorwort I

Business Rule Management Systeme

Vorwort

Die vorliegende Arbeit ist das Resultat des Wirtschaftsinformatikseminars (WISE) im fünften

Vollzeitsemesters an der Fachhochschule St. Gallen, Hochschule für Angewandte

Wissenschaften. Im Rahmen dieses Seminars erhielten wir die Möglichkeit uns vertieft mit

dem Thema „Business Rule Management Systeme“ auseinander zu setzen. Dieses

Kernthema der Wirtschaftsinformatik ist aktuell und sehr viele Unternehmen suchen nach

einer Lösung. Ursprünglich bestand das Ziel der Arbeit die Open-Source-Software Drools im

FHS Labor zu installieren und in Betrieb zu nehmen. Nach diversen Schwierigkeiten

beschlossen wir zur Projekthälfte, zusammen mit dem Projektcoach, einen 90 Grad Shift in

der Auftragsdefinition. Neu konzentrierten wir uns auf die Breite der verschiedenen

Anwendungen, anstelle auf die Tiefe in Drools.

Während der Arbeit stiessen wir auf verschiedene Widerstände. Bedingt durch das äusserst

aktuelle und innovative Thema ist nur sehr wenig Fachliteratur vorhanden. Weiter mussten

wir feststellen, dass verschiedene Anbieter von entsprechender Software aufstreben und

auch wieder verschwinden. Somit können wir sagen, dass der Markt für Business Rule

Management Systeme äusserst dynamisch und volatil ist.

Wir danken unserem Projektcoach Herr Prof. Dr. Rainer Endl für seine Unterstützung

während der ganzen Projektzeit. Er stand uns jederzeit zur Seite, gab wichtige Inputs und

zeigte sich jederzeit äusserst hilfsbereit und flexibel. Seine Beiträge halfen uns in jeder

Phase der Arbeit ziel- und lösungsorientiert zu arbeiten.

Weiter bedanken wir uns bei Lars Henning, Dozent an der FHS St. Gallen, für seine Inputs

während den GPMT-Lektionen.

St. Gallen, im Januar 2012 Dominik Löliger

Daniel Ritter

Management Summary II


Management Summary

Inhaltsverzeichnis III


Inhaltsverzeichnis

Vorwort .................................................................................................................................. I

Management Summary ........................................................................................................ II

Inhaltsverzeichnis ............................................................................................................... III

Abbildungsverzeichnis ...................................................................................................... VI

Abkürzungsverzeichnis .................................................................................................... VII

1 Auftragsdefinition .......................................................................................................... 1

1.1 Ausgangslage des Projektes .................................................................................. 1

1.2 Projektziele ............................................................................................................. 1

1.3 Projektaufträge/Aufbau der Arbeit........................................................................... 1

1.3.1 Neue Zieldefinition ...................................................................................... 2

1.4 Projektplanung ....................................................................................................... 2

2 Business Process Framework ...................................................................................... 3

2.1 Begriffsdefinitionen ................................................................................................. 3

2.2 Business Process ................................................................................................... 3

2.3 Business Rule Engine (BRE) .................................................................................. 4

2.4 Workflow Management System (WFMS) ................................................................ 4

2.5 XML Process Defintion Language (XPDL) .............................................................. 4

2.6 Business Process Management System (BPMS) ................................................... 5

2.7 Business Logic ....................................................................................................... 5

2.8 Business Process Modelling ................................................................................... 6

2.8.1 Ereignisgesteuerte Prozesskette (EPK) ...................................................... 6

2.8.2 Business Process Execution Language (BEPL) .......................................... 7

2.8.3 Architecture of Integrated Information (ARIS) .............................................. 7

2.8.4 Business Process Modeling Notation (BPMN) ............................................ 7

3 Konzepte ........................................................................................................................ 8

3.1 Human Workflow Management .............................................................................. 9

3.1.1 Kanäle für die Einbindung von Prozessbeteiligten ....................................... 9

3.2 Prozessorientierte Anwendungsintegration ........................................................... 10

4 Aktuelle Business Rule Suites ................................................................................... 12

4.1 Workflow Tools / Rule Execution Werkzeuge ....................................................... 12

4.1.1 Drools ....................................................................................................... 13

Inhaltsverzeichnis IV


4.1.2 ILOG ......................................................................................................... 13

4.1.3 BizTalkServer ........................................................................................... 14

4.1.4 Innotas Integration Platform ...................................................................... 14

4.1.5 SharePoint ................................................................................................ 14

4.1.6 NxBRE ...................................................................................................... 15

4.1.7 Fazit .......................................................................................................... 15

4.2 Einordnung Drools ................................................................................................ 16

5 Drools im Labor ........................................................................................................... 17

5.1 Die Drools Suite ................................................................................................... 17

5.1.1 Drools Expert (rule engine) ....................................................................... 18

5.1.2 jBPM 5 (process/workflow) ........................................................................ 18

5.1.3 Drools Fusion (event processing/temporal reasoning) ............................... 19

5.1.4 Drools Guvnor (Business Rule Manager) .................................................. 19

5.2 Laborversuch ....................................................................................................... 21

5.2.1 Versuchsaufbau ........................................................................................ 21

5.2.2 Nutzen ...................................................................................................... 21

5.2.3 Vorgehen - Resultate ................................................................................ 22

5.2.4 Herausforderungen und Schwierigkeiten................................................... 23

6 Drools – Workflow Management bei der Helvetia Versicherungen .......................... 24

7 JRules – Business Rule Management bei der Credit Suisse .................................... 26

8 Reifegradmodell .......................................................................................................... 27

8.1 Was ist ein Reifegradmodell? ............................................................................... 27

8.2 Reifegradmodell für BRMS ................................................................................... 27

8.2.1 Level 1 – Initial .......................................................................................... 28

8.2.2 Level 2 – Repetable .................................................................................. 28

8.2.3 Level 3 – Defined ...................................................................................... 28

8.2.4 Level 4 – Managed ................................................................................... 28

8.2.5 Level 5 – Optimizing ................................................................................. 29

9 Fazit und Ausblick ....................................................................................................... 30

9.1 Fazit ..................................................................................................................... 30

9.2 Ausblick ................................................................................................................ 31

9.3 Persönliche Erfahrungen ...................................................................................... 31

Glossar ................................................................................................................................ 32

Quellenverzeichnis ............................................................................................................. 33

http://sharepoint.microsoft.com/de-de/

Inhaltsverzeichnis V


Anhänge ................................................................................................................................ 1

Anhang A: Interview mit Markus Kreher, Credit Suisse .................................................... 1

Anhang B: Interview mit Andreas Eigenmann, Helvetia Versicherungen ......................... 1

Anhang A: Interview mit Markus Kreher, Credit Suisse .................................................... 1

Anhang B: Interview mit Andreas Eigenmann, Helvetia .................................................... 1

Vertraulichkeitserklärung .................................................................................................... 2

Abbildungsverzeichnis VI


Abbildungsverzeichnis

Abbildung 1: Beispiel Geschäftsprozess ................................................................................. 3

Abbildung 2: Einsatzbeispiel XPDL ........................................................................................ 4

Abbildung 3: BPM Standards ................................................................................................. 5

Abbildung 4: Beispiel EPK ...................................................................................................... 6

Abbildung 5: Grundgerüst BPEL ............................................................................................. 7

Abbildung 6: ARIS-Haus ........................................................................................................ 7

Abbildung 7: Mensch-Maschine- und Maschine-Maschine-Schnittstellen ............................... 8

Abbildung 8: Human Workflow Management als Analogie zur Vorgangsbearbeitung ............. 9

Abbildung 9: Prinzip der Hub-and-Spoke-Integration ............................................................ 11

Abbildung 10: BPM-Softwaresichten .................................................................................... 12

Abbildung 11: Drools Logo ................................................................................................... 13

Abbildung 12: SharePoint Logo ............................................................................................ 14

Abbildung 13: NxBRE Logo .................................................................................................. 15

Abbildung 14: Übersicht Drools Projekte .............................................................................. 16

Abbildung 15 Drools BLIP .................................................................................................... 17

Abbildung 16 Beispiel einer Regel, die von Drools verarbeitet werden kann ........................ 18

Abbildung 17 Teil eines Geschäftsprozesses als Flussdiagramm......................................... 18

Abbildung 18 Beispiele von Zeitoperatoren zwischen Objekten ............................................ 19

Abbildung 19 Web-GUI zum Erstellen von Regeln in Drools Guvnor .................................... 20

Abbildung 20: Helvetia Versicherungen Logo ....................................................................... 24

Abbildung 21: Credit Suisse Logo ........................................................................................ 26

Abbildung 22 Die 5 Levels des Reifegradmodells gemäss CMM .......................................... 27

Abkürzungsverzeichnis VII


Abkürzungsverzeichnis

ARIS Architecture of Integrated Information

BLIP Business Logic Integration Platform

BPEL Business Process Execution Language

BPMN Business Process Modelling Notation

BPM Business Process Management

BPMS Business Process Management System

BRE Business Rule Engine

DLS Domain specific Language

EPK Ereignisgesteuerte Prozesskette

WfMC Workflow Management Coalition

WFMS Workflow Management System

XML Extensible Markup Language

XPDL XML Process Defintion Language

Kapitel 1: Auftragsdefinition 1


1 Auftragsdefinition

1.1 Ausgangslage des Projektes

Zu Beginn des fünften Vollzeitsemester an der Fachhochschule St. Gallen erhielt die

Wirtschaftsinformatikklasse (WI VZ09w) den Auftrag Gruppen von zwei bis vier Studierenden

zu bilden. Diese Gruppen werden sich während dem ganzen Semester vertieft mit einem

aktuellen Thema der Disziplin Wirtschaftsinformatik beschäftigen. Zur Auswahl standen die

Themen Programmierung von Apps, Apps im Unternehmenseinsatz, Cloud Computing,

Drools, Enterprise 2.0, Self-Tracking und Semantische Prozess Wikis. Die Projektgruppe

Dominik Löliger und Daniel Ritter bewarb sich für das Thema Drools mit dem Coach

Prof. Dr. Rainer Endl und erhielt den Zuschlag.

1.2 Projektziele

Die Informatik entwickelt sich in horrendem Tempo. Im ordentlichen Ablauf des Lehrplanes

ist es kaum möglich, aktuellen Themen in einer angemessenen Tiefe gerecht zu werden.

Das Wirtschaftsinformatik-Seminar soll eine offene Modulform zur Bearbeitung aktueller

Wirtschaftsinformatik-Themen durch Studierenden-Teams bieten. Die Teams werden von

Dozierenden begleitet. Als übergeordneter Rahmen für das Seminar gilt die

Modulbeschreibung.

1.3 Projektaufträge/Aufbau der Arbeit

Die Business Logic Integration Platform Drools soll mit ihren Funktionen und den

Einsatzzwecke vorgestellt werden.

Business Logic Integration Platforms und Business Process Managementsysteme sind

Systeme für das integrierte Management von Geschäftsregeln und Geschäftsprozessen. Ein

wichtiger und moderner Vertreter dieser Klasse ist das OpenSource-Projekt Drools. In

diesem Seminar sollen der vorhandene Funktionsumfang von Drools untersucht und

praktische Einsatzzwecke vorgestellt werden.

Die Ziele der Arbeit sahen wie folgt aus:

Überblick über die Architektur und Funktionsweise von Drools

Beschreibung geeigneter Einsatz- und Integrationsszenarien (wie kann / wird Drools

konkret verwendet?)

Vorschlag für ein systematisches Vorgehen für den Einsatz von Drools im

Unternehmen

Kapitel 1: Auftragsdefinition 2


Erfolgreiche Installation von Drools

Erstellen und Durchführen eines Testfalles

Definition des erwarteten Ergebnisses Inhalt und Form

1.3.1 Neue Zieldefinition

Das Projektteam konnte Drools erfolgreich im Labor installieren. Jedoch stiessen sie danach

auf unlösbare Probleme, die in den weiteren Kapiteln erläutert werden. Daher hat das

Projektteam zusammen mit Dr. Rainer Endl etwa zur Projekthalbzeit folgende neue Ziele

definiert:

Begriffliche Abgrenzung

Wie stehen die Begriffe zueinander?

Welche Grundsätzlichen Architektur Ansätze gibt es?

Welche Konzepte gibt es?

Experteninterviews durchführen

1.4 Projektplanung

Das Projektteam benutzte für ihre Planung der jeweiligen Schritte vor allem die

Auftragsdefinition und die Disposition. Diese musste im Verlauf des Projektes immer wieder

an die neuen Gegebenheiten angepasst werden. Die Änderungen geschahen immer im

Einverständnis mit dem Projektcoach.

Kapitel 2: Business Process Framework 3


2 Business Process Framework

Die Themen Business Process Management (Geschäftsprozessmanagement) und

Workflow-Management beinhalten die verschiedensten Begriffe, die im Einzelnen erklärt

werden müssen. Dieses Kapitel definiert die verschiedensten Begriffe im Bereich des

Business Process Framework. Zudem werde die begrifflichen Unterschiede erklärt.

2.1 Begriffsdefinitionen

Die nachfolgenden Unterkapitel erklären die verschieden Begriffe der Business Rule

Management Welt. Manche Begriffe sind wissenschaftlich begründet und andere Definition

hat der jeweilige Softwarehersteller eher aus Marketingzwecken erfunden. Weiter zeigen die

Kapitel auch die Abgrenzungen zwischen den Begriffen.

2.2 Business Process

Der Term Geschäftsprozess wird auf verschiedene Weise definiert. Es herrschen die

Definitionen von Scheer und Jost, von den Pionieren Hammer und Champy, von Österle, die

Definition von Berkau und weitere. Im weiteren Verlauf wird die folgende Definition eines

betriebswirtschaftlichen orientierten Geschäftsprozesses zugrunde gelegt:

Ein Geschäftsprozess ist eine zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die

arbeitsteilig von mehreren Organisationen oder Organisationseinheiten unter Nutzung von

Informations- und Kommunikationstechnologien ausgeführt werden können. Er dient der

Erstellung von Leistungen

entsprechend den vorgegebenen,

aus der Unternehmensstrategie

abgeleiteten Prozesszielen. Ein

Geschäftsprozess kann formal auf

unterschiedlichen

Detaillierungsebenen und aus

mehreren Sichten beschrieben werden. Ein maximaler Detailierungsgrad der Beschreibung

ist dann erreicht, wenn die ausgewiesenen Aufgaben je in einem Zug von einem Mitarbeiter

ohne Wechsel des Arbeitsplatzes ausgeführt werden können.

(Gadatsch, 2010, S. 41)

Abbildung 1: Beispiel Geschäftsprozess; gefunden am 30.10.2011 unter http://www.imn.htwk-leipzig.de/~weicker/pmwiki/pmwiki.php/Main/ModellierungEinesGesch%E4ftssystems



2.3 Business Rule Engine (BRE)

Eine Business-Rule-Engine (BRE) ist eine technische Softwarekomponente als Bestandteil

eines Business-Rule-Management-Systems (BRMS), die eine effiziente Ausführung von

Geschäftsregeln beziehungsweise Business-Rules ermöglicht. Das primäre Ziel der BRE ist

es, die Geschäftslogik von der Programmlogik oder Prozesslogik zu trennen, was

grundlegende Änderungen an der fachlichen Geschäftslogik ermöglicht ohne Änderungen

am Programm-Code oder am Design des Geschäftsprozesses vornehmen zu müssen. Diese

Regeln werden in einem Rule Repository gespeichert.

Andere Komponenten eines BRMS sind ein Business-Rule-Editor und ein Business-Rule-

Repository. Dieses Repository ist wiederum eine gute Quelle für Revisionen und Audits, um

die Einhaltung von Compliance-Regeln zu prüfen. Geschäftsregeln (Business Rules) werden

so nicht mehr implizit formuliert, sondern können transparent gepflegt, verwaltet und geprüft

werden.

(Liebhart, 2007, S. 95)

2.4 Workflow Management System (WFMS)

Mit einem Workflow Management System ist eine anwendungsneutrale Standardsoftware

zur Modellierung, Simulation, Ausführung und Analyse von Geschäftsprozessen unter

Einbindung unterschiedlicher Hardware- und Softwarearchitekturen gemeint. Das erwähnte

System bietet dem Controller vielfältige Möglichkeiten zur Analyse der Effizienz von

Geschäftsprozessen. Ein WFMS ist so zu verstehen, dass es die Vorgänge interpretiert, aber

nicht automatisch mit anderen Systemen interagiert.

(Gadatsch, 2010, S. 430), (Schneider & Bratskich, S. 8)

2.5 XML Process Defintion Language (XPDL)

Die XPDL wird als Standard durch die Workflow

Management Coalition (WfMC) betreut. Dabei handelt

es sich um dieselbe Einrichtung, die bereits im Jahr

1995 das bekannte Worflow Reference Model

veröffentlichte. Die ursprüngliche Ambition der WfMC

bestand darin eine möglichst generische Sprache zur

Beschreibung unterschiedlichster Geschäftsprozesse

zu gestalten. Aus dieser Konsequenz basieren viele

Process Engines zwar offiziell auf XPDL, haben die

Abbildung 2: Einsatzbeispiel XPDL; gefunden am: 30.10.2011 unter http://social-biz.org/2006/05/26/bpmn-xpdl-and-bpel/

http://de.wikipedia.org/wiki/Softwarekomponente

http://de.wikipedia.org/wiki/Business-Rule-Management-System

http://de.wikipedia.org/wiki/Business-Rule

http://de.wikipedia.org/wiki/Gesch%C3%A4ftslogik

http://de.wikipedia.org/wiki/Gesch%C3%A4ftsprozess

http://de.wikipedia.org/w/index.php?title=Business-Rule-Editor&action=edit&redlink=1

http://de.wikipedia.org/wiki/Business-Rule-Repository

http://de.wikipedia.org/wiki/Business-Rule-Repository



Sprache aber proprietär derart umfassend erweitert, dass eine Übertragung der definierten

Prozessmodelle zwischen den Engines unmöglich ist, was der Zielsetzung eines Standards

widerspricht. In letzter Zeit verdrängte die Business Process Execution Language (BPEL)

zunehmend XPDL. Daher wird XPDL inzwischen verstärkt als Austauschformat für

graphische Prozessmodelle, insbesondere Business Process Modelling Notation (BPMN),

verwendet. Dementsprechend ungewiss ist die Zukunft von XPDL.

(Freund & Götzer, 2008, S. 119)

2.6 Business Process Management System (BPMS)

Moderne Business Process

Management Systeme

ermöglichen die automatische

Ausführung von Abläufen auf

Grundlage von graphischen

Modellen, die das Verständnis

der implementierten Prozesse

auch für Personen ohne

Programmierkenntnisse

erleichtern. Die Darstellung

eines solchen ausführbaren

Workflows-Modells ähnelt

dabei sehr dem fachlichen

Modell eines zu

unterstützenden Geschäftsprozesses. Daher unterstützen die korrekte Umsetzung von

BPMS die fachlichen Anforderungen von informationstechnischen Lösung und erlauben im

Idealfall eine Modellerstellung direkt durch den Fachanwender. Darüber hinaus lassen sich

mittels BPMS vorhandene Web Services zu kompletten Geschäftsprozessen integrieren.

(Fürstenberg, S. 168–169)

2.7 Business Logic

Geschäftslogik (engl. Business Logic, auch Anwendungslogik) ist ein abstrakter Begriff in der

Softwaretechnik, der eine Abgrenzung der durch die Aufgabenstellung selbst motivierten

Logik eines Softwaresystems von der technischen Implementierung zum Ziel hat. Allerdings

ist der Begriff unscharf, da eine klare Trennung oft nicht möglich ist.

Abbildung 3: BPM Standards; gefunden am 30.10.2011 unter http://www.bartonitz.net/

http://de.wikipedia.org/wiki/Softwaretechnik

http://de.wikipedia.org/wiki/Programmlogik



Eingeführt wurde der Begriff in Verbindung mit Schichtenarchitekturen, vor allem mit

Aufkommen von Client-Server-Architekturen. Kontextuell ist die Geschäftslogik dabei in der

Mitte angesiedelt, „oberhalb“ einer Datenhaltungsschicht und „unterhalb“ der

Präsentationsschicht, also zwischen Datenbank und Benutzeroberfläche.

Die Motivation bei Einführung des Begriffs liegt im Wesentlichen darin, dass man die Logik,

die die eigentliche Problemstellung implementiert, von der Logik trennt, die die technischen

Belange abdeckt. Dabei wird unterstellt, dass diese Anwendungsteile unterschiedlichen

Änderungszyklen unterliegen und daher durch deren Trennung die Wartbarkeit des

Softwaresystems verbessert wird.

In Verbindung mit der Objektorientierung wurde der Gedanke der Geschäftslogik zu

sogenannten Geschäftsobjekten erweitert.

(lexitron.de, ohne Datum)

2.8 Business Process Modelling

In den folgenden Unterkapiteln werden die bekanntesten und am häufigsten verwenden

Business Process Modelling Sprachen und Tools vorgestellt. EPK, ARIS, BEPL und BPMN

wurden auch an der Fachhochschule St. Gallen in mehreren Modulen doziert. Somit ist die

Relevanz auch wissenschaftlich abgestützt.

2.8.1 Ereignisgesteuerte Prozesskette (EPK)

Ereignisgesteuerte Prozessketten sind halbformale

grafische Darstellungen, die hauptsächlich dazu benutzt

werden, um Geschäftsprozesse zu veranschaulichen.

Die EPKs wurden in den 90ern vom Institut für

Wirtschaftsinformatik (IwI) an der Universität des

Saarlandes entwickelt und in das ARIS (Architecture of

Integrated Information Systems) Framework integriert.

Dadurch, dass EPKs einerseits eine zentrale

Komponente des SAP R/3 Systems und des darunter liegenden Frameworks und

andererseits im ARIS Framework und in den homogen weit verbreiteten ARIS Werkzeugen

von ids-scheer enthalten sind, stellen sie eine gebräuchliche, allgemein bekannte Methode

der Geschäftsprozessmodellierung dar, welche in Industrie und akademischer Praxis bereits

gebräuchlich ist.

(Fraunhofer Gesellschaft zur Förderung der angewandten Forschung e.V., 2007)

Abbildung 4: Beispiel EPK; gefunden am 30.10.2011 unter http://dia-installer.de/shapes/edpc/index.html.de

http://de.wikipedia.org/wiki/Schichtenarchitektur

http://de.wikipedia.org/wiki/Client-Server-Modell

http://de.wikipedia.org/wiki/Datenbank

http://de.wikipedia.org/wiki/Benutzeroberfl%C3%A4che

http://de.wikipedia.org/wiki/Wartbarkeit

http://de.wikipedia.org/wiki/Objektorientierung

http://de.wikipedia.org/wiki/Gesch%C3%A4ftsobjekt



2.8.2 Business Process Execution Language (BEPL)

BPEL ist eine XML-basierte Sprache zur Beschreibung

von Geschäftsprozessen, deren einzelne Aktivitäten

durch Webservices implementiert sind. BEPL ist ein

Grundgerüst mit vier Säulen. In der nachfolgenden

Abbildung ist das erwähnte Gerüst exemplarisch

dargestellt.

(Geske, 2008, S. 34)

2.8.3 Architecture of Integrated Information (ARIS)

Die ARIS Design Plattform hat sich in den letzten Jahren zum

de facto Standard der Geschäftsprozessmodellierung

entwickelt. Geschäftsprozesse können mit diesem

Modellierungswerkzeug aus unterschiedlichen Perspektiven

betrachtet werden. Dazu werden fünf verschiedenen Sichten

zur Verfügung gestellt: die Daten-, Organisations-, Funktions-,

Leistungs- und Prozessschicht. In den ersten vier dieser

Sichten kann jeweils modelliert werden, ohne die Elemente der

anderen Sichten berücksichtigen zu müssen. So wird es dem

Modellierer ermöglicht, sich in der Datensicht vollständig auf

die Erstellung des Datenmodells zu konzentrieren, ohne die

Funktionen oder Organisationseinheiten betrachten zu

müssen, die auf die einzelnen Datenelemente zugreifen. Die Funktionssicht wiederum

beschäftigt sich nur mit den Funktionen und ihrer statischen Struktur im Sinne einer

Hierarchisierung; die Reihenfolge der Funktionsaufführung bleibt in dieser Sicht vollkommen

aussen vor. Durch diese Modellierung in Sichten wird eine deutliche Reduzierung der

Komplexität bei der Modellerstellung und –pflege erreicht.

(Grief, 2005, S. 3–5)

2.8.4 Business Process Modeling Notation (BPMN)

Die Business Process Modeling Notation (BPMN) ist eine grafische Modellierungssprache,

die von mehreren Herstellern von Workflow-Management-Systemen unterstützt wird. Sie

umfasst zahlreiche Diagrammtypen für unterschiedliche Einsatzzwecke.

(Gadatsch, 2010, S. 259)

Abbildung 5: Grundgerüst BPEL, Quelle: Geske, 2008, S. 34

Abbildung 6: ARIS-Haus; gefunden am 02.11.2011 unter http://commons.wikimedia.org/wiki/File:ARIS-Modell.png

Kapitel 3: Konzepte 8


3 Konzepte

Im Fokus der Prozessautomatisierung stehen solche Aktivitäten, die sich auf die Steuerung

von Prozessen beziehen. Weiterhin werden Aktivitäten zu Messung von Kennzahlen im

Rahmen der Prozessdurchführung automatisiert. Prozesse zu automatisieren bedeutet,

Prozessmodelle in die Realität zu überführen. Daher erfolgt zuerst die Prozessmodellierung.

In einem zeitlich nachgelagerten Schritt ist die Implementierungs- oder Umsetzungsphase

der Prozessautomatisierung zuzuordnen.

Heutzutage sieht der typische Prozessablauf in vielen Organisationen wie nachfolgend

beschreiben aus. Mitarbeiter A informiert Mitarbeiter B, dass Mitarbeiter A seine

Arbeitsschritte beendet habe und somit Mitarbeiter B mit seiner Tätigkeit beginnen könne. In

diesem Szenario existiert kein übergeordneter Koordinator, der die Fertigmeldung von A

entgegennimmt und danach B seine Aufgabe zuweist. Genau diese Aufgabenzuweisung als

Form der Prozesssteuerung steht im Fokus der Prozessautomatisierung. Ein IT-System, eine

sogenannte Process Engine, übernimmt die Rolle des übergeordneten Koordinators. Die

Process Engine weist den Prozessbeteiligten, internen und externen Schnittstellen, über

verschiedensten Kanäle Aufgaben zu und wartete deren Fertigmeldung ab.

Grundsätzlich gibt es zwei Möglichkeiten von Prozessautomatisierung. Es gibt wie eingangs

beschrieben das Human Workflow Management und die

prozessorientierte Anwendungsintegration. Dabei wird

die Arbeitsausführung nicht mehr von einer

menschlichen Kraft verantwortet. Hier übernimmt ein IT-

System die Aufgabenerledigung. Bislang wurde davon

ausgegangen, dass die Aufgabe trotzdem von einem

Mitarbeiter übernommen werden musste, der mithilfe

einer Benutzeroberfläche mit den entsprechenden IT-

Systemen interagiert. In Wahrheit ist diese Oberfläche

jedoch nichts weiter als eine Mensch-Maschine-

Interaktion, die wie in der nebenstehenden Abbildung

gezeigt durch eine Maschine-Maschine-Interaktion ersetzt werden kann.

Durch den Einsatz des IT-Systems ergibt die Messung von Kennzahlen quasi als

„Abfallprodukt“. Die Process Engine ist für die Gesamtsteuerung des Prozesses

verantwortlich. Somit kann sie auch jegliche Zustände und Zeiten erkennen und messen.

(Freund & Götzer, 2008, S. 55–57)

Abbildung 7: Mensch-Maschine- und Maschine-Maschine-Schnittstellen, Quelle: Freund & Götzer, 2008, S. 55–57



3.1 Human Workflow Management

Die Grundidee des Human Workflow Management ist angelehnt an der papierbasierten

Vorgangsbearbeitung. Dies ist auch der Grund weshalb die ersten Lösungen in diese

Richtung in den 90-er Jahren sich als Komponenten von Dokumentenmanagementsystemen

(DMS) darstellten.

In der neueren Zeit, jedoch noch in der frühen Form der Prozessautomation, ähnelte dieses

sehr stark der E-Mail-Kommunikation. Der

entscheidende Unterschied ist jedoch die

Tatsache, dass in der E-Mail-Kommunikation der

Absender entscheidet, wer seine Nachricht

erhalten soll. Im Workflow-Management trifft diese

Entscheidung die Workflow Engine. Dieser Fakt

ermöglicht die Gestaltung und Anpassung des

Workflows durch eine koordinierende Stelle und

steigert somit massgeblich die Agilität des

abgebildeten Prozesses. Dies wird nachfolgend

bildlich dargestellt.

Das Prinzip der Vorgangsbearbeitung wurde auch auf weitere Systeme ausgedehnt. Mittels

Customer Relationship Management (CRM) konnten Prozesse für die Akquise,

Troubleticket-Systeme und Softwaresupport abgebildet werden. Die Hersteller von

Enterprise Resource Planning (ERP) Systemen übernahmen ebenfalls die neue Denkweise

und richteten vergleichsweise generische Workflow-Komponenten für ihr jeweiliges

Funktionsportfolio ein.

Das aktuelle Verständnis der Prozessautomation nimmt zunächst eine Trennung zwischen

der Automation des menschlichen Arbeitsablaufes (Human Workflow) und der

prozessorientierten Systemintegration (Service Orchestration Workflow) vor. Jedoch müssen

beiden Disziplinen in den Projekten wieder kombiniert werden, um effektiv Prozesse

automatisieren zu können. Denn diese spielen sich häufig in organisatorischen und IT-

systemtechnisch heterogenen Landschaften ab.

(Freund & Götzer, 2008, S. 57–59)

3.1.1 Kanäle für die Einbindung von Prozessbeteiligten

Für die Einbindung der Prozessbeteiligten gibt es verschiedene Kanäle. Dies kann zum

Beispiel durch eine eigenständige Desktop-Anwendung realisiert werden. Dabei erfolgt die

Taskzuweisung direkt an das angeschlossene System (z.B. ERP). Diese Variante hat die

Abbildung 8: Human Workflow Management als Analogie zur Vorgangsbearbeitung; Quelle: Freund & Götzer, 2008, S. 57–59



Vorteile, dass der Komfort einer Windows-Anwendung, wie „drag and drop“, zur Verfügung

steht. Zudem kann mit der vertrauten Benutzeroberfläche von Systemen, die ohnehin bereits

im Unternehmen im Einsatz sind, gearbeitet wird. Die Nachteile dieser Lösung liegen auf der

Kostenseite. Für jede installierte Version des Workflow-Clients auf den Arbeitsplatzrechner

muss eine Lizenz gelöst werden. Zudem wirkt sich die Festinstallation negativ auf die

Flexibilität aus. Weiter erfordern jegliche Anpassungen in die angeschlossenen Systeme ein

erneutes Deployment bei den Prozessbeteiligten. Dies kann bei komplexen Organisationen

eine grosse Herausforderung sein.

Eine weitere Möglichkeit der Einbindung besteht in der Integration in vorhandene

Collaboration Clients. Eigenständige Interaktionsoberflächen haben oft den Nachteil von

Schulungsaufwänden und Akzeptanzproblemen bei der Belegschaft. Daher ist die Integration

von Aufgabenlisten und –masken des Workflow-Management-Systems in vorhandene

Collaboration Clients empfehlenswert. Damit sind Programme wie Microsoft Outlook oder

Lotus Notes, die der allgemeinen Kommunikation im Unternehmen dienen, gemeint. Eine

sehr einfache und wirksame Möglichkeit ist die Interaktion mit völlig herkömmlichen E-Mails.

Dabei schickt die Workflow Engine eine E-Mail mit der Aufgabe direkt an den zuständigen

Mitarbeitenden. Sobald dieser die Aufgabe erledigt hat kann er die ursprüngliche Nachricht

einfach zurücksenden („reply-to“). Die Workflow Engine weist danach die weiteren Tasks zu.

Relativ neu ist die Methode die Prozessbeteiligten mittels Webanwendung anzubinden.

Dabei werden über Thin Clients mit herkömmlichen Webbrowsern (Internet Explorer, Firefox

etc.) die Prozesse gesteuert. Der Hauptvorteil liegt hier an der maximalen Flexibilität der

Masken. Diese können zentral administriert und angepasst werden. Diese Methode gewinnt

immer mehr an Bedeutung, vor allem vor dem Hintergrund des Siegeszuges mobiler

Endgeräte. In der Praxis reicht es häufig aus mit den Mitarbeitenden via SMS in Interaktion

zu treten. Durch die zunehmende Unterstützung der Programmiersprache Java bei Mobilen

Devices ist auch die direkte technische Unterstützung von Aufgabenlisten auf Smartphones

möglich.

(Freund & Götzer, 2008, S. 59–74)

3.2 Prozessorientierte Anwendungsintegration

Mit der Einführung von ERP-Systemen erhofften sich viele Unternehmen in den 90er-Jahren

die Abschaffung des „Software-Zoos“. Die Erfahrung der letzten zehn Jahre zeigt jedoch,

dass diese Hoffnung häufig enttäuscht wurde. Früher oder später reichten auch die

leistungsfähigen ERP-Lösungen nicht mehr aus um alle Geschäftsprozess abzubilden.

Daher konzentriert man sich mittlerweile auf Lösungsansätze, die das Zusammenspiel der

verschiedenen genutzten Systeme optimieren. Dieses Zusammenspiel hat essentielle



Bedeutung, weil viele Geschäftsprozesse nicht nur von einem System, sondern von vielen

abgewickelt werden. Der jeweilige Wechsel stellte einen Systembruch dar, der mit

Aufwänden und Risiken verbunden ist. Die Überwindung von Systembrüchen kann durch

einen regelmässigen Zeitpunkt des Datenaustausches oder durch eine Benutzeranweisung

ausgelöst werden.

Neben den Herausforderungen auf Softwareseite stehen viele Unternehmen immer noch vor

dem Problem, dass die Softwarearchitektur eine Schnittstelle zwischen zwei Systemen

vorsieht. Diese Point-to-Point-Integration ist zwar kurzfristig die einfachste, langfristig aber

häufig nicht die die sinnvollste Lösung. Denn die Anzahl Schnittstellen wächst

überproportional zur Anzahl der Systeme.

Formel zur Berechnung der benötigten Anzahl Schnittstellen x in einer Point-to-Point-

Integration mit n Anwendungen:

Da dieser Ansatz bereits bei 20 Anwendungen (190 Schnittstellen) nicht mehr vernünftig

umsetzbar ist, hat sich die Hub-and-Spoke-Architektur oder

Enterprise Application Integration (EAI) entwickelt und

durchgesetzt. Im Zentrum dieser Architektur steht wie in der

folgenden Abbildung gezeigt ein EAI-Server, der die

Entgegennahme und den Versand von Daten aus

beziehungsweise an die angeschlossenen Anwendungen

übernimmt. Der Vorteil hier ist, dass pro Anwendung nur eine

Schnittstelle zum EAI-Server entwickelt werden muss. Der

Nachteil des Hub-and-Spoke-Ansatzes liegt in der Skalierbarkeit.

Bei hohen Volumina bildet der EAI-Server häufig den Flaschenhals bezüglich der

Performance.

(Freund & Götzer, 2008, S. 75–81)

Abbildung 9: Prinzip der Hub-and-Spoke-Integration; Quelle: Freund & Götzer, 2008, S. 78

Kapitel 4: Aktuelle Business Rule Suites 12


4 Aktuelle Business Rule Suites

Derzeit werden auf dem Markt verschiedene Arten von Softwarelösungen im Bereich BPM-

Suites angeboten. Die Produkte können in folgende Kategorien definiert werden:

1. BPM-Softwarelösungen mit vordefinierten Lösungsvorlagen, Notationen,

Metamodellen und Modellen von Geschäftsprozessen.

2. BPM-Softwarelösungen mit Tool und Plattformen für modifizierbare Modellvorlagen,

Metamodellen und Sprachen.

3. BPM-Softwarelösungen mit Modellierungsplattformen, Modellierungssprachen und

Modellverwaltungen.

4. BPM-Softwarelösungen wie in Kategorien 3, die jedoch auch Verbindungen zu

anderen Modellierungsplattformen und BPM-Softwarelösungen beinhalten.

5. BPM-Softwarelösungen, in denen Knowledge-Management-Systeme integriert sind.

Jede BPM-Suite ist auf Modellierungssprachen

oder Entwicklungsplattformen basiert, wie zum

Beispiel auf J2EE, Eclipse, XML oder BPEL.

Zusammen mit verschieden BPM-Tools, Utilities

und BPM Server Engines, sind die

Modellierungssprachen in einer BPM-Suite

vereinigt. Zusätzlich wird das Knowledge-

Framework in die BPM-Suite und Applikation

eingefügt.

Die verschienden Technologien sind mittels

Schichten klar hierarchisch abgegrenzt. Somit basiert jede BPM-Suite auf der Verwendung

von verschiedenen Technologien. Dies ist graphisch in der nachfolgenden Abbildung

skizziert.

(Pajkovska Goceva & Petrick, 2009, S. 10)

4.1 Workflow Tools / Rule Execution Werkzeuge

Auf dem Markt sind verschiedene Open Source und kommerzielle Software-Anbieter tätig.

Eine Studie des amerikanischen Verlages BZ Media aus dem Jahr 2005 zeigte, dass JBoss

mit Drools einen Marktanteil von 33,9 Prozent hat. Die nachfolgende Aufstellung zeigt eine

Auswahl von Rule Execution Werkzeugen.

(entwickler.de, 2005)

Abbildung 10: BPM-Softwaresichten; Quelle: Pajkovska Goceva & Petrick, 2009, S. 11



4.1.1 Drools

Hersteller: (Open Source)

Produkt: Drools

Website: http://www.jboss.org/drools/

Kurzbeschreibung: Eine Java-basierte Business Rule

Engine, welche Vorwärts-Inferenz

unterstützt. Sie verwendet eine XML-

basierte Regelsprache, die sich aus

verschiedenen domänenspezifischen Sprachen (DSLs) erzeugen lässt.

Die verfügbaren DSLs sind allerdings eher technisch orientiert.

(Schacher & Grässle, 2006, S. 324–328)

4.1.2 ILOG

Hersteller: ILOG

Produkt: JRules

Website: http://www.ilog.com

Kurzbeschreibung: Eine J2EE- und .NET-basierte Business Rule Engine mit hoher

Leistung, umfangreicher Funktionalität sowie umfassendem Toolset,

inklusive Rule Management. Weiter wird die Definition von

Geschäftsregeln mittels Microsoft Word und Excel unterstützt. ILOG

durch dezidierte Engines für Optimierungsprobleme ergänzt.

Der gesamte ILOG Rule Kit besteht im Wesentlichen aus folgenden

Komponenten:

Rule Builder; graphische Entwicklungsoberfläche

Business Rule Repository; XML-basierte Repository zur

Speicherung der Metadaten

Debugger; Sammlung von Funktionen zur Analyse und

Konfliktslösungen

Profiler; Visualisierung und Evaluation von Geschäftsregeln

Rule Editors; zusätzliche, konfigurierbare Web- oder Java-

Editoren

(Endl, S. 283–285), (Schacher & Grässle, 2006, S. 324–328)

Abbildung 11: Drools Logo; gefunden am 30.10.2011 unter http://www.Drools.org

http://www.jboss.org/drools/

http://www.ilog.com/



4.1.3 BizTalkServer

Hersteller: Microsoft

Produkt: BizTalk Server

Website: http://www.microsoft.com/germany/biztalk/default.mspx

Kurzbeschreibung: Ein EAI-Tool (Enterprise Application Integration) mit dem

applikationsübergreifende Geschäftsprozesse integriert werden können.

Dazu wurde eine einfache Business Rule Engine integriert, die es

erlaubt, Entscheidungen im Ablauf eines Geschäftsprozess zu

automatisieren.


4.1.4 Innotas Integration Platform

Hersteller: Innotas

Produkt: Innotas Integration Platform

Website: http://www.innotas.com/products-integration-platform

Kurzbeschreibung: Eine Lösung für strategisches IT-Management. Innotas integriert

Business Logik via Konnektoren.

(Innotas)

4.1.5 SharePoint

Hersteller: Microsoft

Produkt: SharePoint

Website: http://sharepoint.microsoft.com

Kurzbeschreibung: SharePoint ist eine Business Plattform

für Zusammenarbeit im Unternehmen

und im Web. SharePoint verfolgt soll

das zusammen arbeiten vereinfachen,

die Kosten senken dank einer

einheitlichen Infrastruktur und eine

schnelle Reaktion auf die Business

Anforderungen ermöglichen.

SharePoint erleichtert damit die Zusammenarbeit von Projektteams

innerhalb und ausserhalb des Unternehmens. IT Leiter schätzen die

Möglichkeit bisherige komplexe Systeme durch SharePoint abzulösen

Abbildung 12: SharePoint Logo; gefunden am 30.12.2011 unter http://www.collaborationdays.ch/SiteAssets/SitePages/Homepage/SP2010.ppng

http://www.microsoft.com/germany/biztalk/default.mspx

http://www.innotas.com/products-integration-platform

http://sharepoint.microsoft.com/de-at/Seiten/default.aspx






und damit Kosten zu sparen. Zudem können neue Prozesse schneller

zur Verfügung gestellt werden.

Es muss jedoch klar festgehalten werden, dass SharePoint nicht andere

Anwendungen integriert, sondern SharePoint wird von anderen

Anwendungen (z.B. SAP) integriert. Dies ist ein grundlegender

Unterschied zu BRMS.

(Microsoft, ohne Datum)

4.1.6 NxBRE

Hersteller: (Open Source)

Produkt: NxBRE

Website: http://www.nxbre.org

Kurzbeschreibung: Eine .NET-basierte Business

Rule Engine, welche Vorwärts-

Inferenz unterstützt. Regeln

können in graphischer Form von

Microsoft Visio erfasst werden,

aber auch im RuleML-Format eingelesen werden.


4.1.7 Fazit

Wie in den vorhergehenden Unterkapiteln beschrieben, besitzt Drools einen markanten

Marktanteil. Zusätzlich ist Drools als Open Source Software frei auf dem Markt erhältlich.

Aus diesen beiden Gründen hat sich das Projektteam entschieden Drools im Labor der

Fachhochschule St. Gallen zu installieren und in Betrieb zu nehmen. Die diesbezüglich

gemachten Erfahrungen beschreibt das Kapitel „Drools im Labor“.

Abbildung 13: NxBRE Logo; gefunden am 30.10.2011 unter http://sourceforge.net/apps/trac/nxbre/wiki

http://www.nxbre.org/



4.2 Einordnung Drools

Das nachfolgende Kapitel zeigt wie Drools in der Begriffswelt einzuordnen ist. Drools bietet

mit dem Projekt Drools Expert eine Rule Engine

an. Die weiteren Projekte sind wie in der

nebenstehend Abbildung beschrieben Drools

Guvnor als Business Rule Manager, jBPM 5 für

den Process und Workflow, Drools Fusion regelt

das Event Processing und das Temporal

Reasoning sowie Drools Planner für das

automatisierte Plannung. Diese beschrieben

Suite bietet Drools und jBPM als Drools – The

Business Logic integration Platform an. Somit ist Drools als Business Rule Management

System anzusehen.

(Drools - JBoss Community, ohne Datum a)

Abbildung 14: Übersicht Drools Projekte; gefunden am 02.11.2011 unter http://www.jboss.org/Drools/

Kapitel 5: Drools im Labor 17


5 Drools im Labor

Das vorangehende Kapitel hat einen Überblick über die aktuelle Softwarelandschaft im

Bereich BRMS gegeben. In diesem Kapitel soll die opensource Suite Drools näher betrachtet

werden. Der zweite Teil zeigt die Resultate eines Versuchsaufbaus von Drools und schildert

die Herausforderungen bei der Implementation eines Laborsystems. (Drools - JBoss

Community, ohne Datum a)

5.1 Die Drools Suite

Drools ist ein opensource Business Rule Management System (BRMS) und wird vom

Hersteller JBoss selbst als Business Logic integration Platform (BLIP) bezeichnet. Die

Regeln die für ein System definiert werden, prüft das System mit Hilfe des Rete-Algorithmus‘

um Konsequenzen bzw. Aktionen abzuleiten.

Das System besteht aus 4 Modulen, die zusammen die BLIP bilden:

Drools Expert

jBPM5 bzw. Drools Flow

Drools Fusion

Drools Guvnor

In den folgenden Unterkapiteln werden die einzelnen Module von Drools kurz beschrieben.

Dabei wird erklärt welche Funktionalität das Modul hat und wofür es typischerweise

eingesetzt werden kann.

Abbildung 15 Drools BLIP, Quelle: http://www.slideshare.net/ge0ffrey/Drools-bejug-2010

Zusätzlich zu den vier erwähnten Modulen gibt es weitere Module, die in Entwichlung sind.

Diese Module sind aber noch nicht stabil genug und werden als ‚experimentell‘ bezeichnet.

Dabei handelt es sich unter anderem um die Drools-Module Planner, Chance und Grid.

(Drools - JBoss Community, ohne Datum a)



5.1.1 Drools Expert (rule engine)

Drools Expert ist das eigentliche Kernmodul, denn darin befindet sich die Ruleengine. Im

Modul Expert werden die definierten Regeln mit Hilfe des so genannten Rete-Algorithmus

geprüft. Der Rete-Algorithmus wurde 1979 vom US-amerikanischen Informatiker Charles

Forgy entwickelt. Der damaligen Konkurrenz war der Algorithmus etwa um den Faktor 3000

überlegen und ist heute der de-facto Standard für Regelverarbeitung in vielen Bereichen.

(Forgy, 1982)

Die Einsatzmöglichkeiten von Drools Expert sind sehr breit. So kann es beispielsweise zum

Validieren oder Ableiten von Entscheidungen verwendet werden. Es kann aber auch

eingesetzt werden um Bewertungen vorzunehmen oder in Spielen verwendet werden.

Abbildung 16 Beispiel einer Regel, die von Drools verarbeitet werden kann. Quelle: http://www.slideshare.net/salaboy/Drools5-community-training-module1-Drools5-blip-introduction

Die obenstehende Grafik zeigt die Regel ‚My Rule‘, die von Drools Expert interpretiert

werden kann. Bei der Regel wird geprüft ob der Name einer Person mit John übereinstimmt.

Dann wird im Falle der Übereinstimmung der Text „Hi John!“ ausgegeben.

(Drools - JBoss Community, ohne Datum b)

5.1.2 jBPM 5 (process/workflow)

jBPM ist das Modul in Drools, das die Geschäftsprozesse mit den Regeln verknüpft. In jBPM

können die Geschäftsprozesse einer Unternehmung mit Hilfe von Flussdiagrammen definiert

und visualisiert werden. Dazu kann in jBPM die Business Process Modeling Notation 2.0

(BPMN 2.0) verwendet werden. Das Modul deckt dabei den ganzen Lebenszyklus von

Geschäftsprozessen ab und unterstützt damit von der Architektur der Prozesse, über deren

Ausführung und Überwachung, das ganze Geschäftsprozess Management.

Abbildung 17 Teil eines Geschäftsprozesses als Flussdiagramm Quelle: http://www.jboss.org/jbpm

(jBPM - JBoss Community, ohne Datum)



5.1.3 Drools Fusion (event processing/temporal reasoning)

Die Komponente Drools Fusion gliedert sich als eigenständiges Modul in die Drools Suite ein

und bietet die Funktionalitäten von „Complex Event Processing“ und „ Temporal Reasoning“.

Doch entgegen herkömmlichen Modellierparadigmen, die eine der drei Komponenten

Regeln, Prozesse oder Events priorisieren, setzte Drools Fusion auf alle drei auf. Diese

Sichtweise erlaubt es, sehr anspruchsvolle und komplexe Systeme zu modellieren und

realitätsnah abzubilden. So ist es in Drools Fusion zum Beispiel möglich, 13 Zeitoperatoren

zu verwenden um das Verhalten zweier Objekte zu beschreiben. Diese Operatoren

beschreiben das zeitliche Verhalten der zwei Objekte und sind beispielsweise: vor, nach,

während, endet-mit, endet-vor, startet mit und weitere.

Abbildung 18 Beispiele von Zeitoperatoren zwischen Objekten Quelle: http://www.slideshare.net/salaboy/Drools5-community-training-module1-Drools5-blip-introduction

Diese Eigenschaften machen Drools Fusion sehr flexibel und führen zu einem sehr breiten

Einsatzgebiet. Eingesetzt wird es typischerweise in Gebieten, bei denen eine Erkennung von

Mustern notwendig ist. So kann es eingesetzt werden, zur Betrugsbekämpfung, im Handel

mit Wertpapieren, bei Transport- und Logistikunternehmen.

(Drools - JBoss Community, ohne Datum c)

5.1.4 Drools Guvnor (Business Rule Manager)

Als viertes Modul in der Drools Suite gibt es Drools Guvnor, das für die Persistenz

verantwortlich ist. Drools Guvnor ist ein zentrales Repository für Regeln, Prozesse und

Business-Knowledge. Damit können alle Wissens-Assets verwaltet werden und auch die

Versionierung sichergestellt werden.



Abbildung 19 Web-GUI zum Erstellen von Regeln in Drools Guvnor Quelle: http://www.jboss.org/Drools/Drools-guvnor.html

Drools Guvnor bietet aber neben dem reinen Verwalten auch Tools zum Bearbeiten der

Assets an. So können über Web-GUIs direkt Editoren geladen werden, die es erlauben, mit

Hilfe von Assistenzfunktionen direkt neuen Inhalt zu produzieren.

(Drools - JBoss Community, ohne Datum d)



5.2 Laborversuch

Das Programmpaket Drools mit seinen Modulen ist ein sehr komplexes Gebilde, das

vorwiegend in grossen Betrieben eingesetzt wird. Diese betreiben die Software in einem

exakt zugeschnittenen Umfeld auf leistungsfähigen Servern und abgestimmt auf ihre

spezifischen Prozessen. Es ist also sehr schwierig oder aufwändig, eine Software wie Drools

auszuprobieren oder zu testen. Dies hängt damit zusammen, dass jeder Betrieb ganz eigene

Prozesse, Schnittstellen und Aufgaben hat und sich die Organisationen in ihrer Struktur sehr

stark unterscheiden.

Doch um die Grundfunktionalität von Drools und seinen Komponenten kennenzulernen, wäre

eine generische Laborumgebung eine gute Alternative. So könnte in einem Labor quasi an

einem nicht spezifischen Prototypen getestet werden, auch ob sich das System an die

Gegebenheiten in einer Unternehmung anpassen lässt. Das folgende Kapitel befasst sich mit

dem Aufbau einer solchen Versuchsanlage im Informatiklabor der FHS St. Gallen, schildert

die Erfahrungen die gemacht wurden und nennt Gründe für das Scheitern.

5.2.1 Versuchsaufbau

Wie in der Einleitung erwähnt, hat sich das Projektteam zum Ziel gesetzt, eine kleine

Laborlandschaft aufzubauen um die Funktionalität von Drools testen und demonstrieren zu

können. Dabei ist das Ziel, ein einfaches Set an Geschäftsregeln und -prozessen zu

erarbeiten. Diese Regeln und Prozesse sollen dann in einer Mikroumgebung funktionieren

können, mit Standard-Software aus der Microsoft Office Familie, wie Word, Excel oder

Access. Mit diesen leistungsstarken Tools können grosse Bereiche aus dem Tagesgeschäft

vieler Unternehmen abgedeckt werden.

Auf der technischen Seite wären zum einen natürlich die Server nötig, auf welchen die

Module von Drools laufen. Im operativen Betrieb würden dafür performante Geräte benötigt,

in einer Laborumgebung geht es aber in erster Linie darum, die Realisierbarkeit zu zeigen.

Deshalb wird auf die Standard-HW aus dem Informatik-Labor der FHS St. Gallen

zurückgegriffen, auf denen der JBoss Aplication Server installiert wird, um die Drools

Komponenten zu deployen. Zusätzlich zum Drools System sind einige Clients notwendig, die

Interaktionen mit dem System ermöglichen, um die Geschäftstätigkeit zu simulieren.

5.2.2 Nutzen

Als Resultat dieses Aufbaus kann nach der Installation aller Komponenten und der

Implementation der Prozesse und Regeln eine Unternehmung „en miniatur“ simuliert werden.

So könnte zum Beispiel der Weg einer Bestellung simuliert werden, die am Kundendienst-

Client empfangen und geprüft wird. Nach erfolgreicher Prüfung soll das System die



Bestellung automatisch zum Rüsten an den Lager-Client senden, sowie die

Rechnungssumme ins Abrechnungs-Excel der Buchhaltung eintragen. Sobald das Lager den

Status auf „gerüstet“ setzt, kann der Spedition ein Versandauftrag erteilt werden und die

Rechnung an den Kunden gesendet werden. Natürlich sollte das System auch erkennen,

dass etwa die Regel für den Mindestlagerbestand nach dem Rüsten nicht mehr erfüllt wird

und automatisch einen Bestellvorschlag an den Einkauf senden.

5.2.3 Vorgehen - Resultate

Um die oben beschriebene Lösung umzusetzen, hat das Projektteam versucht, die Drools

Module auf dem erwähnten JBoss Aplication Server zu betreiben. Dieses Vorgehen zeigt

bereits, dass es sich bei der Installation von Drools nicht um eine mit Standard-Software –

wie Word oder Excel – vergleichbare handelt. Eine zweite mögliche „Installation“ ist das

Ausführen der Drools Module aus der Entwicklungsumgebung Eclipse. Bei dieser Methode

wird der Quellcode direkt ausgeführt und im Application Server gestartet.

Die Installation des JBoss Application Servers verlief ohne Probleme und ähnelt gewohnten

Installationen. Doch nach dem Starten des Servers konnte man bereits erkennen, dass es

sich um ein anderes System handelt. So wird der Server über eine Weboberfläche

konfiguriert und auch die Installation der Drools Module erfolgt aus dem Web-Interface. Dies

hat den Vorteil, dass ein Server remote über einen beliebigen Client im Firmennetz

konfiguriert werden kann.

Doch die Installation der Drools Module verlief nicht ganz ohne Probleme. Da die

heruntergeladenen Source ohne Hilfe oder nur mit knappem Manual daher kamen, war ein

grosser Effort notwendig um die Komponenten zum Laufen zu bringen. Als dann die Module

gestartet werden konnten, konnte man sie, wie auch den JBoss Application Server selbst,

über eine Web-Oberfläche bedienen. Das Resultat der Installation war zum einen ein Erfolg,

zeigte aber bereits die nächsten Herausforderungen. Es kann zum Beispiel in Drools Guvnor

eigentlich nur die Funktionalität der Regeleditoren getestet werden. Um die

Repositoryfunktion zu testen, wären ja bereits eine Sammlung von Regeln und Prozessen

notwendig. Doch auch die Regeleditoren benötigen eine gewisse Einarbeitungszeit um damit

funktionierende Regeln zu erstellen. Der Aufbau von Knowhow um Drools einzuführen und

zu benutzen ist nach diesen Erfahrungen ein zeitintensiver Vorgang.

Parallel zur Implementation von Drools auf dem JBoss Application Server testete das

Projektteam auch den Ansatz über die Entwicklungsumgebung Eclipse. Obwohl die beiden

Varianten sehr unterschiedlich sind, waren vergleichbare ist das Team vergleichbaren

Schwierigkeiten begegnet. So konnte zwar nach einer Weile das Eclipse Plug-In gestartet



werden und eine erste rudimentäre Regel definiert werden, über diese erste, einfache Regel

aus war aber kein Fortschritt ersichtlich.

5.2.4 Herausforderungen und Schwierigkeiten

Der Erfahrungsbericht aus dem vorherigen Kapitel zeigt es deutlich, eine Drools-

Implementation ist ein nicht zu unterschätzendes Unterfangen, auch im kleinen Laborumfeld.

Aus diesem Grund und den Limitierungen der Projektlaufzeit hat das Projektteam zusammen

mit dem Dozenten entschieden, auf die Realisierung der Laborumgebung in diesem Projekt

verzichtet.

Aus diesen Fakten kann man schnell ableiten, dass die Implementierung von Drools in

einem betrieblichen Umfeld sehr guter Vorbereitungen und einer professionellen Begleitung

bedarf. Der Aufwand für ein derartiges Projekt sollte also auf gar keinen Fall unterschätzt

werden.

Kapitel 6: Drools – Workflow Management bei der Helvetia Versicherungen 24


6 Drools – Workflow Management bei der Helvetia Versicherungen

Helvetia Versicherungen setzt seit jüngster

Zeit Drools als Business Logic Integration

Platform ein und nutzt somit ein Business

Rule Management System. Die ersten

Projekte werden momentan umgesetzt und

erste Erfahrungen gesammelt.

Laut Andreas Eigenmann, Software Engineer bei Helvetia Versicherungen, setzt Helvetia

Versicherungen Firefox als Browser und für Webservices auf Client-Seite ein. Als

Applikationsserver dient JBoss AS mit Java EE 6 und im Backend wird ein IBM Host

verwendet. Drools steht unternehmensweit bei über 1‘000 Mitarbeitenden im Einsatz. Diese

führen täglich über 100 Transaktionen durch. Helvetia Versicherungen führt mittels einer

Webapplikation die komplette Bestandesverwaltung (Kunden, Partner, Mitarbeiter) durch.

Dabei greift der Applikationsserver via Web-Interface auf die bestehende Datenhaltung auf

dem Host zurück. Bei Änderungen des Bestandes werden entsprechende Events ausgelöst.

Diese leitet das Drools-Regelwerk. Anhand der definierten Regeln werden weitere Prozesse

angestossen oder andere Anwendungen über Ereignisse im Bestand informiert. Die Regeln

verwaltet zurzeit die IT-Abteilung.

Ein vollständiger BPM-Ansatz im Unternehmen über die komplette Applikationslandschaft

hinweg ist für die Helvetia Versicherungen kurzfristig kein Ziel. Modellierung, Simulation und

Reporting/KPI's für den Fachbereich spielen daher eine untergeordnete Rolle und es

bestand bei der Evaluation keine direkte Anforderung nach einer unternehmensweiten BPM-

Suite. Vielmehr ging es darum, ein leichtgewichtiges, technisches Framework innerhalb einer

Applikation zu haben, um Regeln und Workflows einfach abbilden und verwalten zu können.

Für Drools sprach aus Sicht von Helvetia Versicherungen, dass sie bereits die JBoss-

Plattform und deren Open-Source-Projekte nutzten. Weiter ist Helvetia Versicherungen auch

in JBoss-Community tätig sind. Drools ist gemäss Andreas Eigenmann eines der wenigen

Frameworks das Rules, Workflows und Complex Event Processing (CEP) in einer einzigen

Knowledge Base und API vereint und somit eine direkte Interaktion zwischen diesen erlaubt.

Helvetia Versicherungen sieht verschiedene Einsatzmöglichkeiten BRMS. Vorstellbar wäre

beispielsweise die zukünftige Nutzung der Rule-Engine zur Prämienberechnung von

kleineren Produkten. Einschränkungen sind vor allem aufgrund der Tatsache, dass Drools

keine vollständige BPM-Suite ist, im Bereich des kompletten Prozessmanagement (inkl.

Regeln) innerhalb eines Unternehmens gegeben. Die Formulierung oder sogar Verwaltung

der Regeln direkt durch den Fachbereich ist sehr schwierig. Ein BRMS kann für eine

Abbildung 20: Helvetia Versicherungen Logo; Quelle: http://www.helvetia.ch/logo.gif

Kapitel 6: Drools – Workflow Management bei der Helvetia Versicherungen 25


konkrete Aufgabenstellung auch überdimensioniert sein und keine konkreten Vorteile

bringen. Es sollte deshalb früh in einem Projekt ermittelt werden, wie komplex und

dynamisch die Regeln schlussendlich wirklich sind.

Gemäss Aussage von Andreas Eigenmann evaluierte Helvetia Versicherungen bereits zu

einem früheren Zeitpunkt Drools als ein mögliches Business Rule Management System. In

diesem Projekt verzichtete das Unternehmen jedoch bewusst auf Drools als BRMS, in dem

es dem Fachbereich möglich ist anhand von sehr komplexen und dynamischen Formeln

einen Versicherungstarif zu designen. Die in Drools vorgesehenen Expression Language ist

für die direkte Nutzung durch den Fachbereich ungeeignet. Die Definition einer Domain

Specific Language (DSL) anderseits war durch die geforderte grosse Dynamik zu komplex.

Auch ist die Web-Applikation Guvnor zur Verwaltung der Regeln aus Sicht von Andreas

Eigenmann für Nicht-Experten zu komplex. Aus diesen Gründen haben sie sich im

genannten Projekt für eine Eigenimplementierung entschieden.

„Der Markt an kommerziellen und freien BRMS sowie BPM-Suiten ist sehr gross und es ist

nicht immer ganz einfach die Unterschiede der einzelnen Produkte zu identifizieren und zu

bewerten“, sagt Andras Eigenmann. Es sollten somit vorher detailliert die Anforderungen und

das geplante Einsatzgebiet bekannt sein. Die grösste Entscheidung dürfte dabei sein, sich

im Unternehmen für oder gegen den Einsatz einer kompletten BPM-Suite inkl. BRMS zu

entscheiden. Sehr grossen Einfluss dürfte auch die vorhandene Systemlandschaft bei der

Wahl eine Rolle spielen. Bei Drools selber sieht der Experte von Helvetia Versicherungen vor

allem beim Einsatz des Eclipse-basierte Designers Verbesserungspotenzial.

Das Auslagern von Businesslogik in ein Regelwerk kann eine Applikation auch komplexer

und für den Entwickler schlechter durchschaubar machen. Es ist ein weiteres System an der

Applikation beteiligt und die Logik somit zwischen Java und der Rule-Engine verteilt. Das

suchen nach Fehlern und Debuggen kann dadurch erschwert werden.

Für die Definition von Geschäftsregeln liefert der jeweilige Fachbereich dies ausformulierte

Regeln in einem Excel- oder Word-Dokument. Diese Regeln werden durch den Entwickler in

das entsprechende Drools-File eingepflegt. Die Erstellung und Verwaltung der Drools-Regeln

direkt durch den Fachbereich ist vorerst bei Helvetia Versicherungen nicht vorgesehen.

(Interview mit Andreas Eigenmann, 30.12.2011)

Kapitel 7: JRules – Business Rule Management bei der Credit Suisse 26


7 JRules – Business Rule Management bei der Credit Suisse

Das Projektteam führte ein

Experteninterview mit Markus Kreher, Leiter

des Business Rule Competence Center der

Credit Suisse in Zürich durch. Dabei konnte

erfahren werden, dass etwa 20

Mitarbeitende der Business-Seite und 40

Mitarbeitende der IT-Seite der Credit Suisse mit JRules 7.1.1 von ILOG und den

Komponenten Rule Studio, Rule Team Server und Exceution Unit arbeiten. Täglich werden

über 2.5 Millionen Transaktionen durchgeführt.

Credit Suisse setzt JRules in allen Bankbereichen ein, um schnell auf veränderte

Anforderungen reagieren zu können. Dies sei auch einer der grossen Vorteile von JRules.

Die Regeln werden nicht mehr irgendwo im Source-Code vergraben, sondern zentral im

BRMS abgelegt. Diese Transparenz ermöglicht eine rasche Reaktion auf jegliche

Veränderungen im Markt.

Eine Gefahr sieht die Credit Suisse bei der allzu flexiblen Änderung von Regeln. Dies kann

dazu führen, dass Regeln zu leichtfertig angepasst werden. Daher muss das Thema

Governance unbedingt im Zusammenhang mit BRMS geregelt werden (er macht wann

welche Änderungen, wie werden Änderungen frei gegeben, wie werden Regeln

nachvollziehbar in die Test- bzw. Produktionsstufen verteilt).

(Interview mit Markus Kreher, 05.12.2011)

Abbildung 21: Credit Suisse Logo; Quelle: https://www.credit-suisse.com/

Kapitel 8: Reifegradmodell 27


8 Reifegradmodell

Um eine Technologie richtig nutzen zu können ist es wichtig, sie auch richtig zu kennen.

Nachdem in dieser Seminararbeit die Grundlegenden Begriffe und Funktionen von BRMS

und BPM im Allgemeinen definiert wurden und zusätzlich aktuelle Suiten und Fallbeispiele

diskutiert wurden, soll sich dieses Kapitel den Reifegraden widmen. Es soll nach einer

kurzen Heranführung in die Thematik ein mögliches Reifegradmodell aufgezeigt und

diskutiert werden.

8.1 Was ist ein Reifegradmodell?

Ein Reifegradmodell macht wie der Name sagt, eine Aussage über die Reife einer

Organisation im Verhältnis zu einem definierten Referenzzustand. Die Organisation wird also

in ein Modell eingeordnet und nach verschiedenen Kriterien bewertet. Gemäss Schmelzer

und Sesselmann bildet ein Reifegradmodell eine „Vergleichsbasis für die Bewertung der in

einer Organisation definierten und gelebten Prozesse.“ Und basiert auf „bewährten

Praxiserfahrungen und bieten die Möglichkeit, die Ist-Situation der Prozesse mit Best

Practice zu vergleichen.“ (Schmelzer, Sesselmann & Schmelzer-Sesselmann, 2010, S. 316)

Mit Hilfe eines Reifegradmodells kann deshalb beurteilt werden, auf welcher

Entwicklungsstufe sich eine Unternehmung befindet. Dies dient zum einen dazu, den Ist-

Zustand festzuhalten. Auf der anderen Seite hilft es aber den Unternehmen auch, klar

aufzuzeigen, wo sie noch Potential haben und welcher Änderungen es bedarf um sich

weiterzuentwickeln.

8.2 Reifegradmodell für BRMS

Die folgenden Unterkapitel bilden ein einfaches Reifegradmodell beziehungsweise

charakterisieren den prozessorientierten Teil eines Reifegradmodells. Es wird für die

einzelnen Qualitätslevel genannt, welche Eigenschaften und Denkweisen zu etablieren sind

um dem Level zu entsprechen. Die Bezeichnungen der Levels basieren auf CMM, dem

Vorläufer des heute breit etablierten CMMI-Referenzmodells.

Abbildung 22 Die 5 Levels des Reifegradmodells gemäss CMM, Quelle: eigene Darstellung

Level 1 Initial

Level 2 Repetable

Level 3 Defined

Level 4 Managed

Level 5 Opzimizing



8.2.1 Level 1 – Initial

In diesem Level ist die Umsetzung von BRMS und BPM noch nicht ersichtlich, sondern erst

initial. Zwar gibt es einzelne Projekte zur Umsetzung von BPM, doch diese werden

gewöhnlichen Projekten gleichgestellt und kämpfen mit den üblichen Projektrisiken, wie

Kostenüberschreitungen, Verzögerungen oder Qualitätsproblemen. Da in diesem Level

weder die Vorteile von BPM in Bezug auf die Qualität noch auf die Planbarkeit genutzt

werden können, empfiehlt es sich einen höheren Level anzustreben.

8.2.2 Level 2 – Repetable

Für den zweiten Level werden wiederholbare BPM-Methoden etabliert. Dazu wird ein BPMS

verwendet, das die Methoden technologisch Unterstützt. Durch diese erste technische Hilfe,

können die Reproduzierbarkeit und genauere Prognosen gewährleistet werden. Diese

konstanten Prozesse führen dann auch zu einer verbesserten Qualität. Zudem können durch

die Wiederholungen Anforderungen aus dem Business direkt in BPM-Elemente umgesetzt

und damit im BPMS modelliert werden.

8.2.3 Level 3 – Defined

In dieser Phase sind bereits viele Handlungsmuster bekannt, um BPM-Lösungen zu

implementieren und dokumentieren. In BPM-Projekten werden Lösungen erarbeitet und

vorangetrieben, die Wiederverwendungscharakter haben. Zu diesem Zweck werden

zusätzlich auch Modelle implementiert und Entwickelt, die für künftige Modellierungen und

Regeln als Grundlage verwendet werden können. Weiter wird bei dem erarbeiten der

Lösungen darauf geachtet, dass die einzelnen Ergebnisse in den Gesamtrahmen passen

und den Prozessentwicklungsstandards entsprechen.

8.2.4 Level 4 – Managed

Der Level Managed wird erreicht, wenn die BPM-Prinzipien und -Techniken nicht nur

nachhaltig angewendet werden, sondern wenn sie gemessen und gemanagt werden. Das

heisst, dass die Präzision und Qualität der Prozesse und Modelle gemessen wird. Daraus

werden dann gegebenenfalls Hinweise für Verbesserungen und Anpassungen gewonnen. In

diesem Level kann eigentlich nicht mehr auf die technologische Unterstützung durch BRMS

oder BPMS verzichtet werden, denn das effiziente Überwachen und Messen ist ohne

Softwaresystem nicht möglich. BRMS können aber auch auf Seite der Verbesserungen

unterstützen, durch die Dokumentation von Änderungen im Repository oder die

automatische Messung von Prozesszeiten.



8.2.5 Level 5 – Optimizing

Im fünften und letzten Level des Reifegradmodells wird das ständige Optimieren und

Überprüfen gelebt. Gegenüber den fallweisen Betrachtungen von Optimierungspotential und

Verbesserungen, wie in Level 4, wird hier ein kontinuierlicher Überprüfungsprozess gelebt.

Diese Stufe verlangt auch äusserst hohe Managementattention um den

Optimierungsgedanken wirklich implementieren zu können. Denn ab dieser Stufe ist es das

Ziel, das BPM auf allen Ebenen zu verbessern. Das heisst nicht nur die Prozesse und

Regeln, die im BRMS verwaltet werden, sind im Fokus, sondern auch das BRMS selber, die

Art und Weise der Erarbeitung von Prozessen und Regeln

(Setrag Khoshafian, 2006)

Kapitel 9: Fazit und Ausblick 30


9 Fazit und Ausblick

In dieser Seminararbeit an der FHS St. Gallen, konnte das Projektteam das Thema Business

Rule Management Systeme und die angrenzenden Bereiche rund um Geschäftsprozesse

aus unterschiedlichen und spannenden Seiten Beleuchten. Dieses abschliessende Kapitel

dient dem Blick zurück und soll kritisch hinterfragen und ein Fazit ziehen. Es soll aber auch

ein Blick nach vorne gewagt werden, auf die künftige Entwicklung der Thematik BRMS. Zum

Schluss werden die Verfasser auch ihre persönlichen Erfahrungen kurz Wiedergeben.

9.1 Fazit

Das Spannungsfeld rund um Geschäftsprozesse, Geschäftsregeln und deren Management-

Systeme ist äusserst anspruchsvoll und komplex. Dies hängt damit zusammen, dass es sich

um virtuelle und nicht konkret fassbare Themen handelt, kommt aber auch durch den

Wildwuchs an verschiedenen Begriffen zustande, wie sie einleitend in diese Arbeit erklärt

wurden. Oftmals ist es nicht möglich die einzelnen Begriffe scharf voneinander Abzutrennen

und klar zu definieren.

Diese begrifflichen Hürden erschweren zwar den Einstieg in die Thematik, sind aber nach

einer Einarbeitungszeit rasch ausgeräumt. Doch auch der Selbstversuch – die Installation

von Drools in einer Laborumgebung – und das Reifegradmodell zeigen, dass es für die

gewinnbringende Umsetzung von BRMS sehr hohe Anstrengungen braucht. Auf technischer

Seite, bis das System implementiert ist und alle Schnittstellen miteinander kommunizieren

können. Aber auch auf der Business-Seite, wo alle Prozesse und Regeln formalisiert werden

müssen und der Prozessgedanke breit etabliert werden muss. Zusammenfassend kann

durchaus gesagt werden, dass ein BRMS oder BPMS Projekt eine Mammutaufgabe ist und

grosse Mengen an Ressourcen und Zeit benötigt und auch ein weit fortgeschrittenes Wissen

in dem Bereich.

Doch diesen eher negativen Punkten stehen die enormen Möglichkeiten gegenüber. So

können BRMS einen sehr hohen Mehrwert generieren, in dem sie gleichzeitig die Qualität

erhöhen und die Durchlaufzeiten verringern können. Dies gelingt durch die standardisierten

Abläufe und die repetitive Entscheidungsfindung. Auf diese Weise kann auch die Planbarkeit

erhöht werden, was dem Management deutliche Vorteile bringt. Diese Planbarkeit geht aber

nicht zu Lasten der Flexibilität, denn durch die Teilung von Business-Logik und Programm-

Logik können Änderungen schnell realisiert werden, ohne das System zu gefährden.

Kapitel 9: Fazit und Ausblick 31


9.2 Ausblick

Die Herausforderungen, die im vorherigen Kapitel geschildert wurden werden zwar durch die

Vorteile aufgewogen und es entstehen enorme Chancen. Für den Moment werden diese

Systeme und damit auch deren Vorteile hauptsächlich den mittleren und grossen

Unternehmen vorbehalten sein, die sich Unterfangen in dieser Grössenordnung leisten

können. Doch durch Veränderungen im Angebot an BRMS-Lösungen könnte die Einführung

auch für kleinere Unternehmen erschwinglich werden.

Im Markt für BRMS dominieren im Moment noch die Spezialanbieter, die den grössten Teil

am Kuchen haben. Sie werden konkurriert durch die reinen Modellierungsspezialisten und

Open-Source-Produkte. Doch auch die Big-Players der IT-Industrie steigen in das

Geschäftsfeld BPM ein, meist durch Zukauf oder Kooperationen. Obwohl die Spezialisten im

das Feld im Moment noch anführen, ist davon auszugehen, dass sich die Big-Player in den

nächsten Jahren nach und nach durchsetzen werden. (Schmelzer et al., 2010, S. 413)

Für die Anwender hätte diese Entwicklung auch positive Eigenschaften, denn die

Konzentration auf die Big-Player würde zu einer Standardisierung der Lösungen führen.

Dadurch wird der Markt zwar etwas weniger variantenreich, aber dafür besser überschaubar.

Zusätzlich können die Big-Player auch die Kontinuität besser gewährleisten, die für

Unternehmen extrem wichtig ist, vor allem bei langfristigen strategischen Projekten.

9.3 Persönliche Erfahrungen

Persönlich war das Arbeiten und Recherchieren während diesem

Wirtschaftsinformatikseminar (WISE) sehr interessant und lehrreich. Wir haben eine äusserst

Spannende und topaktuelle Thematik untersucht und erlebt, mit welchen Schwierigkeiten

man in diesem Feld zu kämpfen hat. Doch auch diese Rückschläge oder gesteigerten

Herausforderungen konnten unser Motivation keinen Abbruch tun und haben unsere Neugier

eher gesteigert.

Das Thema hat aber auch visionären Charakter und wir haben während des Projektes viele

Ideen erarbeitet, die nicht alle im Rahmen von WISE realisiert werden konnten. Zwar ist das

Projekt mit dem Semesterende abgeschlossen, aber die Ideen, das erarbeitete Wissen und

die Erfahrungen werden wir sicher mitnehmen und bei gegebener Zeit Umsetzten, Nutzen

und Weitergeben.

Glossar 32


Glossar

RuleML-Format Die Rule Markup Language ist eine XML-Sprache zur

Beschreibung von Transformationen auf Daten.

Inferenzmaschine Eine Inferenzmaschine ist eine Software aus dem Bereich der

künstlichen Intelligenz, die durch Schlussfolgerung neue

Aussagen aus einer bestehenden Wissensbasis ableitet.

Damit sind Inferenzmaschinen Kernbestandteil von

Expertensystemen und anderen wissensbasierten Systemen.

http://de.wikipedia.org/wiki/Software

http://de.wikipedia.org/wiki/K%C3%BCnstliche_Intelligenz

http://de.wikipedia.org/wiki/Schlussfolgerung

http://de.wikipedia.org/wiki/Wissensbasis

http://de.wikipedia.org/wiki/Expertensystem

http://de.wikipedia.org/wiki/Wissensbasiertes_System

Quellenverzeichnis 33


Quellenverzeichnis

Drools - JBoss Community. (ohne Datum a). Drools - The Business Logic integration Platform. Gefunden am 2.11.2011 unter http://www.jboss.org/Drools/

Drools - JBoss Community. (ohne Datum b). Drools Expert. Gefunden am 31.12.2011 unter http://www.jboss.org/Drools/Drools-expert.html

Drools - JBoss Community. (ohne Datum c). Drools Fusion. Gefunden am 31.12.2011 unter http://www.jboss.org/Drools/Drools-fusion.html

Drools - JBoss Community. (ohne Datum d). Drools Guvnor. Gefunden am 31.12.2011 unter http://www.jboss.org/Drools/Drools-guvnor.html

Endl, R. Regelbasierte Entwicklung betrieblicher Informationssysteme. : Bd. 45. Köln, Bern: Eul.

(entwickler.de, Hrsg.). (2005). Starke Marktanteile für JBoss und Eclipse, Software & Support Media GmbH. Gefunden am 30.10.2011 unter http://javastarter.de/zonen/portale/psecom,id,99,news,19434,neu,1.html

Forgy, C. (1982). Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem. Artificial Intelligence, S. 17–37.

(Fraunhofer Gesellschaft zur Förderung der angewandten Forschung e.V., Hrsg.). (2007). EPK-Modellierung. Gefunden am 30.10.2011 unter http://www.re-wissen.de/opencms/Wissen/Techniken/EPK-Modellierung.html

Freund, J. & Götzer, K. (2008). Vom Geschäftsprozess zum Workflow: Ein Leitfaden für die Praxis. München: Hanser.

Fürstenberg, F. (Hrsg.). Der Beitrag serviceorientierter IT-Architekturen zu integrierten Kontraktlogistikdienstleistungen (1. Aufl.). : Bd. 14. Berlin, Berlin: Univ.-Verl. der Techn. Univ. Berlin.

Gadatsch, A. (2010). Grundkurs Geschäftsprozess-Management: Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker (6., aktualisierte Auflage). Wiesbaden: Vieweg+Teubner Verlag / GWV Fachverlage GmbH Wiesbaden.

Geske, M. (2008). Vom Geschäftsprozessmodell zum ausführbaren Programm: Entwurf einer ganzheitlichen Methodik (1. Aufl.). s.l: GRIN Verlag.

Grief, J. (2005). ARIS in IT-Projekten: Zielgerichtet zum Projekterfolg durch fundiertes ARIS-Wissen, jede Menge Praxiserfahrung, erprobte Lösungen (1. Aufl.). Wiesbaden: Vieweg.

Innotas. Innotas Integration Platform: Simple, flexible, and in the Cloud, Innotas. Gefunden am 30.10.2011 unter http://www.innotas.com/products-integration-platform

jBPM - JBoss Community. (ohne Datum). jBPM. Gefunden am 31.12.2011 unter http://www.jboss.org/jbpm

lexitron.de. (ohne Datum). Business Logic. Gefunden am 30.10.2011 unter http://www.lexitron.de

Liebhart, D. (2007). SOA goes real: Service-orientierte Architekturen erfolgreich planen und einführen. München: Hanser.

Löliger, D. & Ritter, D. (05.12.2011), Interview mit Markus Kreher. Zürich

Löliger, D. & Ritter, D. (30.12.2011), Interview mit Andreas Eigenmann. St. Gallen

Microsoft. (ohne Datum). Microsoft SharePoint 2010: Möglichkeiten und Nutzen. Gefunden am 30.12.2011 unter http://sharepoint.microsoft.com/de-de/Seiten/default.aspx

Quellenverzeichnis 34


Pajkovska Goceva, S. & Petrick, N. (2009). Business Process Management Suites: Ein Überblick. München: GRIN Verlag GmbH.

Schacher, M. & Grässle, P. (2006). Agile Unternehmen durch Business Rules (1. Aufl.). s.l: Springer-Verlag.

Schmelzer, H. J., Sesselmann, W. & Schmelzer-Sesselmann. (2010). Geschäftsprozessmanagement in der Praxis: Kunden zufriedenstellen, Produktivität steigern, Wert erhöhen ; [das Standardwerk] (7. Aufl.). München: Hanser.

Schneider, H. & Bratskich, L. Business Process Management: GRIN Verlag.

Setrag Khoshafian. (2006). Three Dimensions of BPM Maturity Models, bpminstitute.org. Gefunden am 31.12.2011 unter http://www.bpminstitute.org/articles/article/article/three-dimensions-of-bpm-maturity-models/news-browse/11.html

Anhänge 1


Anhänge

Anhang A: Interview mit Markus Kreher, Credit Suisse

Anhang B: Interview mit Andreas Eigenmann, Helvetia Versicherungen

Anhang A: Interview mit Markus Kreher, Credit Suisse 1


Anhang A: Interview mit Markus Kreher, Credit Suisse

Anhang A: Interview mit Markus Kreher, Credit Suisse 2


Anhang B: Interview mit Andreas Eigenmann, Helvetia 1


Anhang B: Interview mit Andreas Eigenmann, Helvetia

Vertraulichkeitserklärung

Wir erklären hiermit, dass ich/wir:

- den Inhalt dieser Arbeit unter Angabe aller relevanten Quellen selbständig

verfasst haben/habe.

Ort/Datum: Namen:

St. Gallen, 06.01.2012 Dominik Löliger

Daniel Ritter

Business Rule Management Systemewinf-wiki.fhslabs.ch/images/9/9e/2011_WISE_DROOLS... · 2019. 11....

Documents

Transcript of Business Rule Management Systemewinf-wiki.fhslabs.ch/images/9/9e/2011_WISE_DROOLS... · 2019. 11....