Business Decision Management und Business Process Management – Eine Einführung für Einsteiger WHITE PAPER-REIHE „BUSINESS DECISION MANAGEMENT“ BSC – Dr. Jürgen Pitschke Autor: Dr. Jürgen Pitschke www.enterprise-design.eu Dieses Dokument enthält Beitrage von Signavio GmbH www.signavio.com DIESE UNTERLAGEN KÖNNEN FREI FÜR NICHT-KOMMERZIELLE ZWECKE BENUTZT WERDEN. DIE WEITERVERBREITUNG ODER KOMMERZIELLE NUTZUNG JEGLICHEN TEILS DIESER UNTERLAGEN IST OHNE ZUSTIMMUNG VON BCS – DR. JÜRGEN PITSCHKE UND SIGNAVIO GMBH NICHT GESTATTET. FÜR LIZENZEN UND WEITERVERWENDUNG SPRECHEN SIE UNS BITTE AN. KOPIEREN SIE DIESE NOTIZ IN JEDE REPRODUKTION.
Transcript
Business Decision Management und Business Process Management – Eine Einführung für Einsteiger
WHITE PAPER-REIHE „BUSINESS DECISION MANAGEMENT“
BSC – Dr. Jürgen Pitschke Autor: Dr. Jürgen Pitschke www.enterprise-design.eu
Dieses Dokument enthält Beitrage von Signavio GmbH www.signavio.com
DIESE UNTERLAGEN KÖNNEN FREI FÜR NICHT-KOMMERZIELLE ZWECKE BENUTZT WERDEN. DIE WEITERVERBREITUNG ODER KOMMERZIELLE NUTZUNG JEGLICHEN TEILS DIESER UNTERLAGEN IST OHNE ZUSTIMMUNG VON BCS – DR. JÜRGEN PITSCHKE UND SIGNAVIO GMBH NICHT GESTATTET. FÜR LIZENZEN UND WEITERVERWENDUNG SPRECHEN SIE UNS BITTE AN. KOPIEREN SIE DIESE NOTIZ IN JEDE REPRODUKTION.
Kontakt ................................................................................................................................................... 25
1. Gutes Geschäftsprozessmanagement braucht „Business Process Management“
Geschäftsprozessmanagement ist seit mehreren Jahren eine etablierte Disziplin in vielen Unternehmen.
Die Abläufe von Geschäftsprozessen werden beschrieben, analysiert und optimiert. Die einzelnen Aktivitäten werden detailliert spezifiziert, um sie zu implementieren oder Arbeitsanleitungen zu erstellen.
Damit Business Process Management erfolgreich ist, muss Erreichtes immer wieder in Frage gestellt werden. Das gilt für die verbesserten Geschäftsprozesse genauso, wie für die eingesetzten Arbeitstechniken oder die verwendeten Werkzeuge.
Eine Erkenntnis vieler Anwender ist die Tatsache, dass die ausschließliche Beschreibung von Abläufen nicht ausreicht. Zusätzlich wachsen die Anforderungen hinsichtlich Compliance mit gesetzlichen Vorgaben oder internen Richtlinien. Neben der Beschreibung flexibler Prozesse ist „Business Decision Management“ ein Haupttrend.
Die Erkenntnis, dass Geschäftsprozesse und Geschäftsregeln zusammen gehören, ist nicht neu. In der Ver-gangenheit wurden dabei häufig einzelne Geschäftsregeln betrachtet. Das verursacht eine hohe Komplexität, da es schwierig ist, eine große Menge von Regeln auf Konsistenz und Korrektheit zu prüfen. Eine einzelne Aktivität benötigt nicht nur eine Geschäftsregel, sondern im allgemeinen eine Vielzahl von Regeln. Dafür wird ein Ordnungsmechanismus benötigt, der in klassischen Geschäftsregel-Ansätzen nicht vorhanden war. Ver-schiedene Anwendungsfälle benötigen andere Darstellungsformen der Geschäftslogik. Business Decision Management bietet einen Ansatz, der für viele solcher Anwendungsfälle hervorragend geeignet ist.
Wir verwenden häufig Begriffe, ohne uns zu vergewissern, was unser Gegenüber darunter versteht. Missverständnisse sind vorprogrammiert.
Wenn wir umgangssprachlich von einer Business Decision oder Entscheidung sprechen, meinen wir einerseits eine Aktivität oder aber auch das Ergebnis dieser Aktivität. Für die weiteren Abschnitte konzentrieren wir uns auf den ersten Aspekt: Eine Entscheidung ist eine Aktivität.
In der Literatur gibt es verschiedene Sichten und Definitionen für Business Decisions.
Betrachten wir Business Decisions aus der Geschäftsprozess-Sicht, so zeichnen sie sich durch folgende Eigenschaften aus:
Eine Entscheidung stellt eine Auswahl aus verschiedenen Optionen oder eine Berechnung mit verschiedenen Optionen dar. Diese Auswahl basiert auf Fakten. Die Entscheidung hat eine Aktion zur Folge.
Betrachten wir diese Arbeitsdefinition etwas näher:
Kennzeichnend für eine Entscheidung ist, dass wir eine Auswahlmöglichkeit haben. Das gilt auch, wenn nur eine der Auswahlmöglichkeiten zum Beispiel durch ein Gesetz als richtig anerkannt wird. Dann ist es Aufgabe des Entscheiders die „richtige“ (die vorgeschriebene) Antwort zu finden.
Diese Auswahl basiert auf Fakten. Oft wird der Begriff „Fakt“ missverstanden. Es geht hier nicht um einen mathematisch-logischen Wahrheitswert oder ähnliches. Vielmehr stammt der Begriff „Fakt“ aus der Geschäftsregel-Welt und bezeichnet hier eine uns bekannte Information über Geschäftsobjekte. Das kann ein Datensatz in unseren IT-Systemen sein oder eine Information, die uns zum Zeitpunkt der Entscheidung bekannt wird.
Wenn wir Entscheidungen aus Geschäftsprozess-Sicht betrachten, hat eine solche Entscheidung eine Aktion zur Folge. Es mag Anwendungsfälle geben, in denen eine Entscheidung nicht direkt Aktion zur Folge hat. Das wollen wir hier nicht vertiefen.
Betrachten wir Business Decisions aus der Geschäftsregelsicht, dann finden wir z.B. folgende Definition:
Eine Entscheidung repräsentiert eine Gruppe von Geschäftsregeln, die zu einer Schlussfolgerung führen und die auf Fakten basieren.
Wir fassen Geschäftsregeln, die zu einer Aktivität gehören, zusammen. Über den Aktionsteil wird hier nicht gesprochen, das ist Sache des Geschäftsprozesses. Für den Begriff „Fakt“ gilt das oben gesagte.
Die erste Definition stellt eine Top-Down-Sicht dar. Von den Aufgaben in einem Geschäftsprozess ausgehend untersuchen wir die Entscheidungen. Die zweite Sicht ist eine Bottom-Up-Sicht und gibt uns die Details einer Entscheidung. Aus methodischer Sicht ist ein Top-Down-Vorgehen zu bevorzugen. Benötigt werden beide Sichten.
Wir stellen dem Wort Decision immer das Wort „Business“ voraus, um zu betonen, dass es hier um Entscheidungen geht, die ein Unternehmen oder eine Organisation im Rahmen seiner geschäftlichen Aktivitäten trifft.
Ein allgemeines Missverständnis ist die Einstellung, dass nur Manager Entscheidungen treffen. Das ist nicht richtig. Wir finden im Unternehmensalltag verschiedene Arten von Entscheidungen, die unterschiedliche Auswirkungen und unterschiedlichen Wert für das Unternehmen haben.
Tabelle 1 gibt einen Überblick über verschiedene Entscheidungsarten.
Wer entscheidet? Über was? Entscheidungsumfang
Management Strategische Entscheidungen Geringe Anzahl Sehr hoher Wert einer Einzelentscheidung Hoher Gesamtwert
Mittleres Management Taktische Entscheidungen Vorgaben für Operative Entscheidungen
Bearbeiter Operative Entscheidungen Sehr hohe Anzahl von Entscheidungen Niedriger Wert einer Einzelentscheidung Möglicherweise hoher Gesamtwert
Beispiele für solche Entscheidungen sind in der nachfolgenden Tabelle enthalten.
Entscheidungstyp Beispiel
Strategische Entscheidungen
Sollten wir Firma ACME übernehmen? Sollten wir das Geschäftsfeld ABC aufgeben?
Taktische Entscheidungen
Vorgaben für Operative Entscheidungen
Sollten wir eine Niederlassung in X eröffnen? Sollten wir den Prozess A reorganisieren?
Welche Rabatte werden gewährt? Welche Kundensegmente wollen wir erreichen?
Operative Entscheidungen
Welchen Preis für das Produkt X soll ich diesem Kunden offerieren? Soll ich den Antrag für Unterstützung von diesem Studenten akzeptieren?
Ist dieses Auto sicher? Wie hoch sind die Gebühren für diese Transaktion?
Tabelle 2: Darstellung von Entscheidungstypen
Die verschiedenen Arten von Entscheidungen erfordern verschiedene Arten der IT-Unterstützung. Geht es bei strategischen Entlscheidungen um eine Entscheidungsunterstützung durch Bereitstellung der für die Entscheidung wichtigen Informationen (Stichwort Business Intelligence), ist bei operativen Entscheidungen oft die (Teil-)Automatisierung das Ziel.
Im Weiteren betrachten wir ausschließlich operative Entscheidungen.
Operative Entscheidungen werden täglich hundert- oder tausendfachgetroffen. Das sind Entscheidungen, die viele verschiedene Mitarbeiter im Unternehmen treffen. Daher geht es nicht darum, wie der Manager diese Entscheidungen treffen würde. Es geht nicht darum, wie der erfahrenste Mitarbeiter diese Entschei-dung trifft. Es geht darum, wie das Unternehmen oder die Organisation diese Entscheidung trifft, um konsistentes, rechts-konformes Verhalten zu erreichen.
Nicht immer ist eine (Teil-)Automatisierung operativer Entscheidungen möglich oder sinnvoll. Nicht immer geht es um die Entscheidungen, die den höchsten ökonomischen Wert für das Unternehmen haben. Manchmal geht es um eine einheitliche Kommunikation oder ein konformes Verhalten. Deshalb sind Arbeitsanweisungen oder ähnliche Dokumente ebenfalls Ergebnis der Modellierung von Entscheidungen.
4. Operative Entscheidungen und Business Process Management
Betrachten wir Aufgaben in einem Geschäftsprozess, dann stellen wir sehr schnell fest, dass sehr viele Aufgaben Entscheidungen sind. Nicht alle diese Entscheidungen sind es wert, explizit modelliert, umgesetzt und gemessen zu werden. Oft beginnen wir mit der Modellierung und Umsetzung einiger weniger Entschei-dungen. Die nachfolgenden Grafiken stellen auf einer abstrakten Sicht dar, worüber wir in Geschäftspro-zessen Entscheidungen treffen. Die Aufstellung ist nicht vollständig.
Abbildung 1: Anwendungsfälle für Entscheidungen
Typische Anwendungsfälle für Entscheidungen:
Berechtigungen:
Die Überprüfung, ob eine Person oder eine Organisation berechtigt ist, einen bestimmten Service oder ein bestimmtes Produkt in Anspruch zu nehmen, ist ein sehr häufiges Beispiel für Business Decision Management. Beispiele sind:
Ist dieser Student berechtigt, finanzielle Hilfe zu beantragen? (Bereich Studenten-Unterstützung)
Ist dieser Kunde berechtigt einen Kredit zu beantragen? (Finanzen)
Ist der Kunde berechtigt diese Störungsmeldung zu übermitteln? (HelpDesk)
Darf der Kunde diese Sendung importieren? (Logistik)
Ist ein Kunde berechtigt, unsere Leistungen in Anspruch zu nehmen, wird insbesondere im Banken- und Versicherungswesen häufig das Risiko beurteilt.
Soll ich dem Kunden den Kredit gewähren?
Welche Versicherungs-Police soll ich dem Kunden anbieten?
Welche Versicherungs-Police darf ich dem Kunden nicht anbieten?
Prozess-Steuerung:
Prozesse besitzen alternative und optionale Szenarien. Zur Laufzeit muss entschieden werden, welches Szenario ausgeführt wird. Das kann im Zusammenhang mit einem anderen Entscheidungstyp geschehen (Welcher Ablauf ist für einen Kunden mit einem hohen Kreditrisiko auszuführen?), das kann eine eigene Ent-scheidung sein. Insbesondere bei der Modellierung und Umsetzung von flexiblen Service-Prozessen sind Entscheidungen über den konkreten Prozessablauf sehr wichtig.
Maximierung und Zielbestimmung:
Im Geschäftsleben existieren viele Entscheidungen über Angebote mit dem Ziel, den Umsatz und Gewinn zu erhöhen oder Kunden nicht zu verlieren.
Welchen Preis sollen wir für den Artikel verlangen?
Welches Cross-Sales-Angebot soll ich dem Kunden unterbreiten?
Wie lange soll das Sonderangebot gelten?
Im Unterschied zu den anderen bisherigen Beispielen, die analytischen Charakter haben, handelt es sich hier um eine vorhersagende Entscheidung („predictive Decision“). Solche vorhersagenden Entscheidungen benö-tigen ein neues Herangehen, sowohl was die Beschreibung, als auch was die Umsetzung und Bewertung der Entscheidung angeht.
Daten-Qualität:
Sprechen wir über Business Decisions ist der Anwendungsfall Datenqualität möglicherweise überraschend. Trotzdem ist es einer der häufigsten Anwendungsfälle für Business Decision Management und häufig eine Vorstufe für andere Entscheidungen. Es geht dabei nicht um die Prüfung einzelner Daten. Das ist eher eine Implementationsfrage. Es geht vordergründig darum, ob die vorliegenden Informationen aus Geschäftssicht konsistent, vollständig und ausreichend sind, um andere Entscheidungen und Aktivitäten auszuführen.
Ist der Antrag vollständig und konsistent?
Sind die erhaltenen Informationen schlüssig?
Kann mit den vorliegenden Informationen die Störungsmeldung bearbeitet werden?
5. Business Process Management und Business Decisions
Entscheidungen und Geschäftsregeln werden bisher oft noch nicht explizit dargestellt. Sie sind in Programm-code, Geschäftsprozessmodellen, Arbeitsanweisungen oder anderen Dokumenten implizit beschrieben oder sind völlig undokumentiert.
Ich will hier nur zwei Beispiele zeigen, bei denen Prozesse Entscheidungen enthalten und dadurch Komplexität entsteht.
5.1. Komplexität innerhalb eines Prozess-Modells
Abbildung 2 zeigt einen Modellausschnitt eines Helpdesk-Prozesses. Nachdem die Störungsmeldung auf-gezeichnet und klassifiziert wurde, finden wir einen Prozessablauf, der auch visuell an einen Entscheidungs-baum erinnert. In Abhängigkeit von der Kategorie der Störungsmeldung und weiterer Informationen wird die Fälligkeit der Störungsmeldung bestimmt.
Abbildung 2: Modell-Komplexität in einem Prozessmodell
Ganz offensichtlich ist hier Entscheidungslogik im Prozessmodell eingebettet und mit BPMN-Elementen beschrieben. Ungeachtet der Tatsache, dass BPMN dafür nicht das geeignete Hilfsmittel ist, entsteht durch die Vermisch-ung der Darstellung von Prozessablauf und Entscheidungslogik unnötige und schwer beherrschbare Komplexität:
Wird die Entscheidungslogik geändert, muss auch das Prozessmodell geändert werden, obwohl der Ab-lauf sich nicht geändert hat. Durch eine explizite und vom Ablauf getrennte Darstellung können beide Aspekte unabhängig voneinander angepasst werden.
Das Beispiel zeigt eine sehr einfache Logik. In der Realität sind Entscheidungen wesentlich komplexer. Ein Prozess enthält nicht nur eine Entscheidung. Entscheidungen sind miteinander verbunden und werden eventuell wieder verwendet. Das Prozessmodell wird stark aufgebläht. Sowohl Ablauf als auch Logik sind kaum noch zu erkennen. Das Modell ist nur begrenzt nutzbar.
Diese Problematik wurde von vielen Anwendern erkannt. Daher finden wir solche Modelle inzwischen seltener in der Praxis
Eine bessere und einfache Darstellung des Prozesses zeigt das nachfolgende Modell.
Abbildung 3: Vereinfachtes Prozessmodell
Das lässt jedoch offen, wie und wo die Geschäftslogik dargestellt wird.
5.2. Komplexität in Prozessmodell-Gruppen
Um dem gerade gezeigten Problem zu entkommen, haben Anwender die Prozesslogik aufgeteilt. Der einzelne Prozess wird dadurch überschaubar. Abbildung 4 zeigt ein solches Prozessmodell. Es handelt sich dabei um einen Antragsprozess für finanzielle Hilfen für Studenten.
Abbildung 4: Eingebettete Entscheidungen in Gruppen von Prozessmodellen
Obwohl das einzelne Prozessmodell überschaubar und verstehbar ist, entstehen hier Probleme:
Die Organisation besitzt ca. 50 solcher Modelle, da es ca. 50 verschiedene Programme für Studenten gibt. Die Komplexität ist nicht im einzelnen Prozessmodell zu sehen. Sie entsteht in der Gruppe aller Prozesse für die Antragsbearbeitung.
Der größte Teil des Prozessmodells stellt Geschäftslogik dar. Genauer gesagt den Teil der Geschäftslogik für das jeweilige Programm. Es entsteht Redundanz und möglicherweise Inkonsistenz.
Die Geschäftslogik ist nirgendwo insgesamt dargestellt und kann daher nicht systematisch überprüft und angewendet werden.
Betrachtet man das Modell genauer, sieht man auch Probleme in der Kommunikation zwischen Antrag-steller und Organisation.
Das Prozessmodell wurde wie folgt überarbeitet und ergänzt:
Abbildung 5: Verbessertes Prozessmodell
Dieses Prozessmodell gilt für alle Programme der Organisation. Das Verhalten im Prozess ist für alle Programme konsistent und für den Antragsteller wiedererkennbar.
Wird ein neues Programm aufgelegt, ist das Prozessmodell anwendbar. Es ist „lediglich“ die Entschei-dungslogik für das neue Programm zu beschreiben bzw. zu ergänzen.
Der Prozess besitzt eine klare Struktur. Es wurde eine Wiedervorlage eingeführt und damit die Kommu-nikation zwischen Antragsteller und Organisation klar geregelt.
Auch hier bleibt die Frage, wie und wo die Geschäftslogik dargestellt wird.
Um Entscheidungen zu beschreiben folgen wir einem iterativen Ansatz, mit folgenden Schritten
Business Decisions identifizieren und abgrenzen
Decision Requirements beschreiben
Entscheidungslogik spezifizieren
Entscheidungskontext beschreiben
Abbildung 6: Iterative Decision Elicitation
Zum Entscheidungskontext gehört auch der Geschäftsprozess, der die jeweilige Entscheidung beinhaltet. In diesem White Paper starten wir mit dem Geschäftsprozess. Selbstverständlich können wir Entscheidungen auch ohne vorhandenes Geschäftsprozessmodell identifizieren und beschreiben. Ohne Geschäftsprozess oder einen Workflow bleibt der Kontext der Entscheidung unvollständig.
Zur Darstellung und Beschreibung der Entscheidungen nutzen wir den OMG-Standard „Decision Model and Notation® (DMN®)“. Dieser wurde im Dezember 2014 vom Architecture Board der OMG® als Standard angenommen.
Der Standard dient der Beschreibung von Entscheidungen, sowohl was die Entscheidungsanforderungen angeht, als auch die Entscheidungslogik. Er ergänzt die Standards „Business Process Model and Notation (BPMN)“ und „Case Management Model and Notation (CMMN)“. Gemeinsam bilden diese drei Standards die BPM-Trilogie.
Im ersten Schritt identifizieren wir Entscheidungen und grenzen diese in ihrem Umfang ab.
Dazu können wir einmal das Geschäftsprozessmodell analysieren. Ein häufiges Missverständnis ist, dass Gateways auf eine Entscheidung hinweisen. Ein Gateway selbst ist keine Entscheidung, es reflektiert gegebenenfalls das Ergebnis einer Entscheidung. Nicht jede Entscheidung hat zwingend ein Gateway zur Folge. Das trifft nur auf eine kleine Menge von Entscheidungen zu.
Vielmehr analysieren wir die Aufgaben in unserem Prozessmodell daraufhin, ob dort eine Entscheidung getroffen wird. Im einfachsten Fall ist das eine textuelle Analyse. Verben wie „entscheiden“, „auswählen“, „beurteilen“, „berechnen“, „bestimmen“, „optimieren“, „maximieren“, „zuordnen“, „prüfen“, „klassifizieren“, „kategorisieren“ oder „schätzen“ deuten auf Entscheidungen hin.
Ein zusätzlicher Weg ist es, die Kommunikation im Prozess zu betrachten. Meist wird vor einer Kommu-nikation eine Entscheidung getroffen (Was teile ich dem Prozess-Partner mit?).
Neben dem Prozessablauf können wir andere Quellen nutzen.
Haben wir den Prozess bereits umgesetzt, dann sind Prozess-Dashboards und KPIs eine gute Quelle, um Entscheidungen zu identifizieren. Wenn unsere Prozessqualität nach bestimmten Kriterien beurteilt wird dann sollten wir in der Lage sein, diese auch zu beeinflussen. Wir haben in Bezug auf diese Kriterien eine Wahlmöglichkeit, wir treffen eine Entscheidung.
Es existieren weitere Möglichkeiten, Entscheidungen zu identifizieren.
Abbildung 7: Helpdesk-Prozess, Modellausschnitt
Haben wir eine Aufgabe als Entscheidungsaufgabe identifiziert, dann markieren wir diese im Geschäfts-prozessmodell mit Hilfe des Attributes „Task Type“ als Business Rule Task. Die Aufgabe erhält in der linken oberen Ecke ein zusätzliches Icon. Wir erkennen die Aufgabe auch visuell als Entscheidungsaufgabe. In Abbildung 7 wurden die entsprechenden Aufgaben bereits entsprechend bearbeitet.
Zugleich ordnen wir dieser Aufgabe ein „Decision Requirements Diagramm (DRD)“ mit der Entscheidung „Akzeptanz der Störungsmeldung“ entsprechend der DMN-Notation zu.
Abbildung 9: Entscheidung im Decision Requirement-Diagramm
Um die Entscheidung abzugrenzen, spezifizieren wir, welche Frage wir mit der Entscheidung beatworten wollen und welche Antworten möglich sind. In unserem Beispiel lautet die Frage „Akzeptieren wir diese Störungsmeldung vom Kunden X?“. Mögliche Antworten sind „akzeptieren“ und „nicht akzeptieren“. Natürlich ist das ein einfaches Beispiel um das Vorgehen zu erläutern. In der Praxis werden die Fragen und möglichen Antworten schnell komplexer.
Hinterfragen Sie die Abgrenzung der Entscheidung, wenn Sie Fragen mit vielen „und“ oder „oder“ formu-lieren. Hinterfragen Sie die Abgrenzung der Entscheidung, wenn Sie Antworten haben, die „und“ oder „oder“ enthalten. Das muss nicht falsch sein. Manchmal handelt es sich jedoch um zwei unabhängige Entscheidun-gen, die dann besser getrennt beschrieben werden.
7.2. Decision Requirements beschreiben
Nachdem wir die Entscheidung abgegrenzt haben, versuchen wir die benötigten Informationen zu identifi-zieren. Es sei erinnert, dass wir ein iteratives Vorgehen gewählt haben.
Für die Entscheidung „Akzeptanz der Störungsmeldung“ benötigen wir einerseits Informationen über den bestehenden Wartungsvertrag des Kunden. Unabhängig vom Wartungsvertrag akzeptieren wir Anfragen von wichtigen Kunden.
Schauen wir uns die benötigten Informationen genauer an, so finden wir heraus, dass die Informationen über den Wartungsvertrag des Kunden vorliegende Informationen sind. Z.B. kommen diese Informationen aus unserem CRM-System.
Die benötigte Information, ob der anfragende Kunde ein „wichtiger“ Kunde ist, ist dagegen selbst eine Entscheidung. Abhängig vom Umsatz klassifizieren wir Kunden in Platin-, Gold- und Standardkunden.
Im Ergebnis entsteht ein Baum, der einerseits eine Dekomposition der Entscheidung in Teilentscheidungen und zugleich die jeweils benötigen Inputs zeigt.
Abbildung 10: Decision mit Input und Sub-Decision
Durch die Dekomposition in Teilentscheidungen reduzieren wir die Komplexität der Gesamtentscheidung. Mit Hilfe von Werkzeugen und Arbeitstechniken können wir so die Korrektheit der Entscheidung besser überprüfen.
Wir kennen nun auch die Inputs für die Entscheidungen und bestimmen, wo diese Inputs zur Laufzeit herkommen. Das können Informationen aus unseren IT-Systemen sein oder Daten, die wir erst erfassen müssen.
Nachdem die Struktur der Entscheidung beschrieben ist, wollen wir die Details der Entscheidungslogik beschreiben. Wir wollen zeigen, wie die Entscheidung im Detail beschrieben wird.
Die DMN bietet dafür das Element „Business Knowledge Model“ an.
Abbildung 11: Decision mit Business Knowledge Model
Das „Business Knowledge Model“ ist ein Platzhalter für die konkrete Entscheidungslogik. DMN lässt aus-drücklich jede geeignete Darstellungsform zu. Je nach Fragestellung der Entscheidung kann das eine Ent-scheidungstabelle, ein Entscheidungsbaum, ein Algorithmus (z.B. bei Optimierungen) oder auch eine Sammlung natürlich-sprachlicher Geschäftsregeln sein. DMN spezifiziert in der gegenwärtigen Version nur Entscheidungstabellen formal. Weitere Formen z.B. Entscheidungsbäume, werden in späteren Versionen folgen.
DMN bietet neben dem Business Knowledge Model eine vereinfachte Darstellungsform. Dabei werden die Entscheidungstabellen direkt der Entscheidung zugeordnet. Die Grafik sieht dann wie in Abbildung 10 aus. Welche Darstellungsform sie wählen, bleibt Ihnen überlassen.
Schauen wir uns Entscheidungstabellen an, dann scheinen diese uns sehr vertraut. Schauen wir nochmals, dann sehen wir sehr schnell, dass auch eine Entscheidungstabelle schnell missverstanden werden kann:
Wie viele Ergebnisse soll die Entscheidungstabelle liefern? Genau eines? Oder mehrere?
Wenn es mehrere Ergebnisse geben kann, sollen diese alle geliefert werden? Wollen wir die Ergebnisse aggregieren, z.B. das Maximum der Werte erhalten?
Enthält die Entscheidungstabelle alle möglichen Geschäftsregeln bzw. Wertekombinationen?
Ich möchte das Thema Analyse einer Entscheidungstabelle hier nicht vertiefen. Das ist Gegenstand weiterer White Paper, genauso wie die Frage anderer Darstellungsformen von Geschäftslogik. Grundsätzlich beur-teilen wir Entscheidungstabellen danach, ob sie korrekt, konsistent und vollständig sind. DMN bietet zur Beschreibung entsprechende Attribute. Ein gutes Werkzeug sollte uns bei der Analyse der Entscheidungstabelle unterstützen.
7.4. Entscheidungskontext beschreiben – Compliance, Prozess, Ziele und mehr
Wir haben nun sowohl die generelle Struktur der Entscheidung als auch die Details der Entscheidungslogik beschrieben. Was bleibt? – Eine Vielzahl von Detailinformationen für verschiedene Zwecke.
DMN bietet ein weiteres Element - die Knowledge Source.
Abbildung 13: Decision Requirement Diagramm mit Knowledge Sources
Eine Knowledge Source hilft uns zu beschreiben, warum wir die Entscheidungslogik in einer bestimmten Art gewählt haben. In unserem Beispiel sind die Quellen unsere AGBS und der Standard-Wartungsvertrag.
Solche Wissensquellen können vielfältig sein. Wenn es um die Fragestellung „Compliance“ geht, sind Wis-sensquellen häufig Gesetze und vergleichbare Vorgaben. Es kann sich dabei um interne Regelungen und Vorschriften handeln. Es kann sich auch um informelles Wissen oder auch einen Experten handeln. In jedem Fall dokumentieren wir, woher das Wissen für die Spezifikation der Entscheidungslogik stammt.
Zum Kontext einer Entscheidung gehören viele weitere Elemente:
Der Geschäftsprozess: Wir sind vom Geschäftsprozess ausgegangen. Durch die Analyse unserer Entscheidungen gewinnen wir neue Erkenntnisse über unseren Prozess. Möglicherweise verändert das den Prozess. Wir wollen vielleicht Teilentscheidungen verlagern, um eine höhere Effizienz zu erreichen. Wir wollen möglicherweise Entscheidungen wiederverwenden. Business Process und Business Decisions bedingen einander.
Die Motivation: Ich habe am Anfang betont, dass es beim Business Decision Management nicht um mathematische Logik und absolute Wahrheiten geht. Entscheidungen sind immer auch mit unseren Motivationselementen verbunden. Welche Vision hat die Organisation? Welche Ziele wollen wir erreichen? Wie wollen wir durch unseren Kunden wahrgenommen werden? Entscheidungen sind daher mit Elementen wie Zielen oder Vision verbunden.
Verantwortlichkeiten: Bezüglich einer Entscheidung gibt es verschiedene Verantwortlichkeiten. Eine Rolle ist für die Vorgaben der Entscheidung zuständig – der Owner (ich stehe auf Kriegsfuß mit dem Begriff Owner, dazu ein anderes Mal mehr). Eine Rolle ist für die Ausführung der Entscheidung zuständig (Make). Andere Rollen werden über die Entscheidung informiert. Vergleichbar zum RACI-Konzept im Geschäftsprozessmanagement können wir hier eine OMI-Matrix erstellen.
Andere Eigenschaften: Unsere Entscheidungsprojekte verfolgen unterschiedliche Ziele. Wir wollen Entscheidungen implementieren und umsetzen. Dafür brauchen wir weitere Informationen. Wir wollen Entscheidungen messen und beurteilen. Dafür benötigen wir wiederum Informationen. Wie oft wird die Entscheidung getroffen? Wie einfach ist es, die Qualität des Ergebnisses zu beurteilen? Wie schnell sind die Auswirkungen der Entscheidung zu sehen?
Je nach Zweck des Modells sind viele weitere Eigenschaften denkbar. Ein gutes Werkzeug sollte es uns ges-tatten, alle diese Detailinformationen zu erfassen und gegebenenfalls eigene Eigenschaften zu definieren.
Zu Beginn haben wir auf Vorteile der expliziten Darstellung der Geschäftslogik hingewiesen. Freigabezyklen zwischen Prozess und Entscheidungslogik werden entkoppelt. Entscheidungen können einfacher geändert werden. Wir gewinnen Agilität, indem wir schnelle Änderungen ermöglichen und die Umsetzung vereinfachen.
Nehmen wir an, wir wollen den Service für obiges Helpdesk-Beispiel erweitern. Neben jährlichen Wartungs-verträgen wollen wir weitere Verträge anbieten. Ein Kunde kann zum Beispiel ein Zeitkontingent (z.B. Support im Umfang von 100 Stunden) oder ein Volumenkontingent (z.B. 100 Anfragen) kaufen. Dann ist der Input „Wartungsvertrag des Kunden“ im Entscheidungsmodell nicht mehr ausreichend. Wir müssen dagegen prüfen, ob der Wartungsvertrag noch Kontingent enthält. Ist es ein periodischer Vertrag wie ein jährlicher Wartungsvertrag, ist das der Fall, wenn er noch nicht abgelaufen ist. Im Falle eines Volumenvertrages muss die Anzahl der bisherigen Anfragen kleiner sein als das vereinbarte Volumen. Aus dem Input wird eine Teil-entscheidung, die neben dem Wartungsvertrag des Kunden weitere Informationen über die Historie des Kunden benötigt.
Abbildung 14: Erweitertes DRD
Viele solche Erweiterungen auf unterschiedlichen Ebenen sind möglich. Stellen Sie sich vor, wir wollen eine Karenzregelung einführen. Ein Wartungsvertrag wird auch dann als aktiv angesehen, wenn er weniger als 10 Arbeitstage abgelaufen ist.
Das Beschreiben von Entscheidungen ist kein Selbstzweck. Wollen wir die Vorteile der expliziten Spezifikation von Entscheidungen nutzen, ist ein umfassendes Business Decision Management notwendig.
Abbildung 15: Kernphasen des Business Decision Management
Business Decision Elicitation: Wie dargestellt identifizieren wir Entscheidungen, grenzen diese ab, strukturieren sie und beschreiben die Entscheidungslogik im Detail. Wir beschreiben, analysieren und verbessern den Vorgang der Entscheidungsfindung.
Decision Implementation: Die Entscheidungen werden umgesetzt. Das kann die Implementation in einem IT-System mit einer Rule Engine sein. Das kann aber auch die Umsetzung in Form von Arbeitsanweisungen oder Checklisten sein. Selten werden die Entscheidungen innerhalb eines Geschäftsprozesses zu 100% implementiert.
Decision Evaluation: Wir bewerten das Ergebnis unserer Entscheidungen. Für diesen Zweck haben wir während der Erhebung der Entscheidungen ebenfalls Informationen erfasst.
Die Beurteilung der Ergebnisse ist Input für einen neuen Zyklus des Entscheidungsmanagement.
Passende Softwarewerkzeuge sind für professionelles Business Decision Management unerlässlich. Tools ermöglichen eine konsistente Abbildung von Entscheidungen im zugehörigen Prozesskontext, die Einhaltung der DMN-Syntax, Logikprüfungen, die Erzeugung von ausführbarem Programmcode und nicht zuletzt die Zusammenarbeit im Team. In diesem Kontext bietet Signavio eine vollständige Unterstützung für den DMN 1.0 Standard (Conformance Level 1).
9.1. Grafische Modellierung von Entscheidungsstrukturen
Ein besonders populärer Teil des DMN-Standards sind die grafischen Decision Requirements Diagrams. Diese ermöglichen, Entscheidungen in Teilentscheidungen zu zerlegen, die Abhängigkeit von Input-parametern abzubilden sowie die Verbindung zu externen oder internen Regularien und Policies darzustellen.
Abbildung 16 DMN im Signavio Editor
Signavio bietet eine intuitive grafische Modellierungsoberfläche für DMN-Diagramme. Elemente können per Drag&Drop verbunden werden. Abbildung 16 zeigt das Supportbeispiel im Signavio-Editor. Schon bei der Modellierung wird zudem sichergestellt dass die Syntaxregeln der DMN eingehalten werden.
Um die Logik einer Entscheidung zu spezifizieren, stehen zwei Wege zur Verfügung. Entweder fügt man eine einfache textuelle Beschreibung hinzu. Oder man definiert eine Entscheidungstabelle. Diese ermöglicht die Spezifikation von Ergebniswerten für eine bestimmte Kombination von Inputwerten. Beide Möglichkeiten erreicht man durch einen Klick auf das Icon einer DMN-Entscheidung.
Abbildung 17 zeigt den Editor für Entscheidungstabellen in Signavio. Hier können beliebig viele Input- und Output-Spalten konfiguriert werden. Sobald der Wertebereich für eine Spalte definiert wurde, stehen die zulässigen Werte und Operatoren in den Zellen der Tabelle zur Verfügung.
Um eine Wiederverwendung von Datentypen zu erreichen, kommt das Signavio-Glossar zum Einsatz: So können die zulässigen Werte an zentraler Stelle definiert werden und entsprechend in verschiedenen Entscheidungen verwendet werden.
Abbildung 17 Entscheidungstabelle im Signavio Editor
Die meisten Entscheidungen sind in einen Prozess eingebettet. Daher bietet es sich an, den umgebenden Prozess auch als Modell darzustellen und die Verknüpfung zur Entscheidung an der entsprechenden Stelle einzufügen. BPMN 2.0 ist dabei die Modellierungssprache der Wahl, denn hier werden explizit Entscheidungsaufgaben (“Business Rule Tasks”) vorgesehen.
In der Signavio-Plattform sind BPMN und DMN sehr eng verzahnt. Beginnt man mit der Modellierung von BPMN, so kann man Aufgaben per Klick auf das “Rule”-Icon eines Tasks verfeinern. Hierbei wird ein neues DMN-Diagramm erzeugt, das bereits die Top-Level-Entscheidung enthält. Falls dem Rule Task in BPMN bereits ein Verzweigungspunkt folgt, werden die Entscheidungsoptionen direkt in die Entscheidungstabelle der DMN-Entscheidung übernommen.
9.4. Kollaboration im Fokus
Bereits für die Prozessmodellierung bietet Signavio zahlreiche Funktionen, die die Zusammenarbeit im Team erleichtern. Diese Kollaboration ist für Entscheidungsstrukturen mindestens ebenso wichtig. Gerade dadurch dass Entscheidungslogik vom fachlich orientierten Modellierungstool Signavio bis zur Ausführung in einer Rule Engine mit wenigen Klicks gebracht werden kann, ist die Abstimmung im Team - aber auch eine entsprechende Governance - von großer Bedeutung.
Funktionen wie der Versionsvergleich, die Kommentierungsfunktion aber auch die Veröffentlichung im Pro-zessportal zielen allesamt darauf ab zu verstehen, wie sich Entscheidungen im Laufe der Zeit verändern und sich möglichst effizient abzustimmen, wie Ist-Entscheidungen in Soll-Entscheidungen zu überführen sind.
Freigabe-Workflows ermöglichen darüber hinaus, genau zu kontrollieren, welche Schritte auf dem Weg von der ersten Veränderungsidee bis zur Live-Setzung in den Systemen vorgenommen werden müssen.
9.5. Funktionsumfang: Aktueller Stand und Ausblick
Die grafische Modellierung von DMN, die Definition von Entscheidungstabellen sowie die Verbindung zwischen DMN und BPMN ist ab sofort in den Signavio Produkteditionen Professional, Corporate und Ultimate ohne Aufpreis verfügbar.
In den kommenden Monaten werden weitere Funktionen folgen, unter anderem die Verifikation von Ent-scheidungslogik (d.h. die Prüfung auf Widersprüche und fehlende Regeln in Entscheidungstabellen). Darüber hinaus wird es Funktionen für die Verknüpfung von Datenmodellen sowie die Validierung von Entschei-dungsmodellen geben. Von vielen Anwendern lang ersehnt ist darüber hinaus die Generierung von aus-führbaren Regeln, z.B. im Drools-Format. Diese weiter führenden Funktionen sind dann als Teil eines kosten-pflichtigen Zusatzmoduls erhältlich.
James Taylor, Neil Raden, Smart (Enough) Systems, Pearson Education, 2007, ISBN: 0-13-234796-2
James Taylor, Decision Management Systems, Pearson Education, 2011, ISBN: 978-0-13-288438-9
Barbara von Halle, Larry Goldberg, The Decision Model: A Business Logic Framework Linking Business and Technology, Auerbach Publishing, 2009, ISBN: 978-1420082814
Ronald G. Ross, Business Rule Concepts, Business Rules Solutions, LLC, 2005, ISBN: 094104906X
Ronald G. Ross, Gladys Lam, Building Business Solutions, 2011, Business Rules Solutions, ISBN 978-0-941049-10-8
Jürgen Pitschke, Unternehmensmodellierung für die Praxis – Eine Einführung in die Darstellung von Unternehmensmodellen, 2010, Books on Demand GmbH, ISBN 978-3-8423-2576-0
