Business Decision Management und Business Process Management Eine Einführung für Einsteiger

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.

Inhaltsverzeichnis 1. Gutes Geschäftsprozessmanagement braucht Business Process Management... 3 2. Was ist eine Business Decision?... 4 3. Wer entscheidet im Unternehmen?... 5 4. Operative Entscheidungen und Business Process Management... 7 5. Business Process Management und Business Decisions... 9 5.1. Komplexität innerhalb eines Prozess-Modells... 9 5.2. Komplexität in Prozessmodell-Gruppen... 10 7. Business Decisions Elicitation mit DMN... 13 7.1. Entscheidungen identifizieren und abgrenzen... 13 7.2. Decision Requirements beschreiben... 14 7.3. Entscheidungslogik beschreiben... 16 7.4. Entscheidungskontext beschreiben Compliance, Prozess, Ziele und mehr... 17 7.5. Decision Elicitation Iterativ und Agil... 19 8. Entscheidungsmanagement... 20 9. Entscheidungsmodellierung mit DMN in Signavio... 21 9.1. Grafische Modellierung von Entscheidungsstrukturen... 21 9.2. Entscheidungstabellen... 22 9.3. Entscheidungen und ihr Prozesskontext... 23 9.4. Kollaboration im Fokus... 23 9.5. Funktionsumfang: Aktueller Stand und Ausblick... 23 Literatur... 24 Kontakt... 25 Seite 2 von 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 Vergangenheit 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. Verschiedene 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. Seite 3 von 25

2. Was ist eine Business Decision? 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. Seite 4 von 25

3. Wer entscheidet im Unternehmen? 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 Tabelle 1: Wer entscheidet über was? Seite 5 von 25

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 Sollten wir eine Niederlassung in X eröffnen? Sollten wir den Prozess A reorganisieren? Vorgaben für Operative Entscheidungen 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 Entscheidung 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. Seite 6 von 25

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 Entscheidungen. Die nachfolgenden Grafiken stellen auf einer abstrakten Sicht dar, worüber wir in Geschäftsprozessen 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) Seite 7 von 25

Risiko: 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 Entscheidung 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? Seite 8 von 25

5. Business Process Management und Business Decisions Entscheidungen und Geschäftsregeln werden bisher oft noch nicht explizit dargestellt. Sie sind in Programmcode, 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 aufgezeichnet und klassifiziert wurde, finden wir einen Prozessablauf, der auch visuell an einen Entscheidungsbaum 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 Vermischung 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 Ablauf sich nicht geändert hat. Durch eine explizite und vom Ablauf getrennte Darstellung können beide Aspekte unabhängig voneinander angepasst werden. Seite 9 von 25

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 Seite 10 von 25

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 Antragsteller 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 Entscheidungslogik 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 Kommunikation zwischen Antragsteller und Organisation klar geregelt. Auch hier bleibt die Frage, wie und wo die Geschäftslogik dargestellt wird. Seite 11 von 25

6. Business Decision Elicitation und DMN Um Entscheidungen zu beschreiben folgen wir einem iterativen Ansatz, mit folgenden Schritten Business Decisions identifizieren und abgrenzen Decision Requirements beschreiben Entscheidungslogik spezifizieren Entscheidungskontext beschreiben Entscheidung abgrenzen Entscheidungskontext beschreiben Entscheidungs- Anforderungen beschreiben Entscheidungslogik spezifizieren 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. Seite 12 von 25

7. Business Decisions Elicitation mit DMN 7.1. Entscheidungen identifizieren und abgrenzen 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 Kommunikation 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äftsprozessmodell 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. Seite 13 von 25

Abbildung 8: Entscheidungsaufgabe 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 formulieren. 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 Entscheidungen, die dann besser getrennt beschrieben werden. 7.2. Decision Requirements beschreiben Nachdem wir die Entscheidung abgegrenzt haben, versuchen wir die benötigten Informationen zu identifizieren. 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. Seite 14 von 25

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. Seite 15 von 25

7.3. Entscheidungslogik beschreiben 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 ausdrücklich jede geeignete Darstellungsform zu. Je nach Fragestellung der Entscheidung kann das eine Entscheidungstabelle, 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? Seite 16 von 25

Abbildung 12: Entscheidungstabelle 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 beurteilen 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 Seite 17 von 25

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 Wissensquellen 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 gestatten, alle diese Detailinformationen zu erfassen und gegebenenfalls eigene Eigenschaften zu definieren. Seite 18 von 25

7.5. Decision Elicitation Iterativ und Agil 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 Wartungsverträ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 Teilentscheidung, 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. Seite 19 von 25

8. Entscheidungsmanagement 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. Seite 20 von 25