21.02.2018

Was ist der Unterschied zwischen DMN und BRM?

Artikel teilen:

IT-Experten und Business-Analysten zeigen großes Interesse am DMN-Standard (Decision Model and Notation). In der Praxis zeigen sich jedoch häufig noch Unklarheiten, insbesondere bei der Frage “Was ist der Unterschied zwischen DMN und BRM (Business Rules Management)?”

In diesem Beitrag möchten wir Antworten liefern und Klarheit schaffen.

Decision Management liegt definitiv im Trend. Und diese eher neue Disziplin profitiert derzeit von der Dynamik von DMN, dem Standard zur Modellierung und Implementierung von Entscheidungen. Es macht den Anschein, dass sich die Modellierung von Entscheidungen zunehmend als eigene Disziplin etabliert – nicht ganz zu Unrecht, denn in Entscheidungen liegt reichlich Potenzial für Effizienzsteigerungen durch Automatisierung und Digitalisierung.

Viele Unternehmen haben in den letzten Jahren (oder Jahrzehnten) bereits massiv in Business-Rules-Management-Technologien investiert. Nun positionieren sich die BRM-Anbieter verstärkt im Decision Management (inklusive DMN). Es ist daher nachvollziehbar, dass manche Unternehmen verunsichert sind und wissen möchten, ob ihre Investitionen in BRM sicher sind. Dieser Artikel soll etwas Licht ins Dunkel bringen, einige grundlegende Fragen beantworten und Missverständnisse beseitigen.

DMN und BRM – Standard vs. Disziplin

Zunächst einmal ist DMN schlicht eine Standardspezifikation. DMN definiert einen herstellerunabhängigen, systematischen Ansatz zur Dokumentation und Implementierung von Entscheidungen und Geschäftsregeln. Die Ziele des Standards sind:

  • Beseitigung von Mängeln des BPMN-Standards (Business Process Model and Notation) bei der Definition und Implementierung komplexer Entscheidungslogik
  • Erhöhung der Transparenz von Geschäftsentscheidungen
  • Verbesserung der Zukunftssicherheit und des Investitionsschutzes durch Bereitstellung eines offenen Standards

BRM hingegen ist eine Disziplin, die sich mit der Definition, der Automatisierung und dem Management regelbasierter Entscheidungen befasst. Die Ziele von BRM sind:

  • Steigerung der Effizienz durch Automatisierung von regelbasierten Entscheidungen
  • Verbesserung der Business-Agilität
  • Business-IT-Alignment und Steigerung der Fachbereichs-Autonomie
  • Optimierung der Effizienz und Flexibilität der IT-Architektur

Das BRM hat seine Ursprünge in der fortschreitenden Digitalisierung und DMN bietet nun einen Standard für bestimmte Aspekte des BRM. DMN behandelt jedoch keine typischen Herausforderungen im Zusammenhang mit dem Management und der Automatisierung von Geschäftsregeln, wie etwa Best Practices auf IT-Architekturebene, bei der Zusammenarbeit zwischen Fachbereichen und IT oder bei Bereitstellungs- oder Governance-Themen.

DMN erweitert BRM auf einer neuen Ebene

Beim Blick auf “klassische” BRM-Ansätze zeigt sich, dass diese typischerweise direkt mit der Definition der Entscheidungslogik anhand von Geschäftsregeln beginnen. Der vorherige Schritt, die Anforderungsdokumentation, erfolgt häufig außerhalb des typischen BRM-Prozesses. DMN beginnt hingegen immer bei der Anforderungsdokumentation. Der Standard erweitert BRM damit auf einer neuen Ebene. Dies ist einer der zentralen Vorteile des Standards: DMN unterstützt die häufig interdisziplinären Anwender dabei, zuerst das Entscheidungsmodell ganzheitlich abzubilden (mit allen Abhängigkeiten und Beziehungen), bevor sie mit der Definition der Entscheidungslogik beginnen.

Ganzheitliches Entscheidungsmodell mit DMN

Diese ganzheitliche Modellierung mit Hilfe des sogenannten Decision Requirements Diagram(DRD), ist besonders wichtig in der Finanzbranche, wo Entscheidungsprozesse oft zwei parallele Dimensionen beinhalten: eine fachliche Dimension und eine regulatorische Dimension.

Betrachten wir zum Beispiel einen Anlageberatungsprozess: Eine Bank möchte ihren Kunden eine gute Anlageberatung bieten. “Gut” heißt in diesem Zusammenhang: Risiken reduzieren und gleichzeitig die Profitabilität erhöhen – für die Bank und den Kunden. Dies ist in hohem Maße eine Frage fachlicher Entscheidungen, die auf umfassendem Wissen über das Anlagegeschäft basieren. Daneben gibt es aber auch eine Vielzahl regulatorischer Vorgaben, die bei der Anlageberatung zu berücksichtigen sind, wie etwa: Hat die Bank den Kunden ausreichend über mögliche Risiken informiert? Hat die Bank das individuelle Risikoprofil des Kunden berücksichtigt? Diese Fragen sind typische Compliance-Entscheidungen. DMN ermöglicht Unternehmen, Geschäftsentscheidungen und Compliance-Entscheidungen in einem ganzheitlichen, transparenten Entscheidungsmodell abzubilden.

BRM als Implementierungs-Möglichkeit von DMN

DMN beginnt mit dem Decision Requirements Diagram, d. h. mit einem gut durchdachten, optimierten, ganzheitlichen Entscheidungsmodell. Die Implementierung der Entscheidungslogik geschieht unmittelbar danach. Hier kommt typischerweise das Business Rules Management ins Spiel (muss aber nicht). Ein großer Unterschied zwischen DMN und BRM ist, dass DMN keine “klassischen” Geschäftsregeln vorschreibt. Stattdessen bietet der Standard verschiedene Möglichkeiten, um Entscheidungslogik zu implementieren. An dieser Stelle wird es interessant, weil nicht alle Entscheidungen (oder Sub-Entscheidungen) auf Basis von Geschäftsregeln getroffen werden. Immer häufiger setzen Unternehmen künstliche Intelligenz (prädiktive Logik) für bestimmte Teile der Entscheidungsfindung ein, während andere Teile auf vordefinierten Regeln basieren (präskriptive Logik). Selbst im zuletzt genannten Fall schreibt DMN nicht vor, wie Geschäftsregeln zu implementieren sind. DMN bietet lediglich eine Möglichkeit zur Definition von Entscheidungslogik und zur Implementierung von Geschäftsregeln. Unternehmen können jedoch weiterhin Ihre bestehenden Geschäftsregeln und andere Nicht-BRM-Technologien (z. B. Machine Learning) nutzen, um Entscheidungen zu treffen.

Die Abbildung oben zeigt ein DMN Decision Requirements Diagram in der Mitte (obwohl das DRD nicht wirklich in der Mitte, sondern auf einer anderen Ebene ist). Die Abbildung zeigt ein Entscheidungsmodell, das verschiedene Subentscheidungen kombiniert. In jeder Subentscheidung wird die Entscheidungslogik auf eine andere Weise implementiert:

  • Die DMN-Entscheidungstabelle implementiert Geschäftsregeln auf Basis des DMN-Standards
  • Die proprietäre BRM-Ablaufregel implementiert Geschäftsregeln aus einem vorhandenen BRM-Projekt
  • Ein Machine-Learning-Modell implementiert eine durch künstliche Intelligenz vorhergesagte Entscheidungslogik
  • Das Beispiel zeigt: DMN erweitert das BRM, es ersetzt es nicht.

DMN und ablauforientierte Entscheidungslogik

DMN führt viele nützliche Innovationen und Ansätze ein, kann in mancherlei Hinsicht allerdings auch einschränken. So unterstützt der DMN-Standard keine ablauforientierten Entscheidungen. Was bedeutet das? Nicht selten folgt die Entscheidungsfindung einem prozessartigen Ablauf mit einem klar definierten Startpunkt. Anwendungsfälle dieser Art erfordern eine klare Reihenfolge, welcher Teil der Entscheidungsfindung Schritt für Schritt ausgeführt wird. In DMN wird eine Entscheidung erst getroffen, wenn alle Sub-Entscheidungen getroffen wurden die Reihenfolge der einzelnen Sub-Entscheidungen kann jedoch nicht bestimmt werden. Einsatzbereiche, die so etwas wie einen Prozessablauf erfordern, sind daher möglicherweise besser mit einem proprietären BRM-Ansatz bedient, der die Definition und Ausführung von Ablaufregeln unterstützt.

Decision Engine vs. Rule Engine

Immer häufiger sprechen Anwender von einer “Decision Engine” anstelle einer “Regel Engine”, oder sie nutzen die Begriffe synonym. Was steckt dahinter? Der DMN-Standard führt neben den Modellierungsaspekten auch eine Ausdruckssprache zur Definition der Entscheidungslogik ein. Diese heißt “FEEL” (Friendly Enough Expression Language) und zielt darauf ab, Anwender aus dem Fachbereich stärker in die Definition von Entscheidungslogik einzubeziehen und deren Verständlichkeit zu verbessern.

Um Entscheidungen auf Basis von DMN und FEEL zu automatisieren, benötigen Unternehmen eine Ausführungs-Komponente, die in der Lage ist, die mit FEEL definierte Entscheidungslogik zu interpretieren. Nach unserem Verständnis wird eine solche Ausführungs-Komponente ‘Decision Engine’ genannt (und bei ACTICO ist dies der Fall). Im Gegensatz dazu ist eine ‘Regel-Engine’ typischerweise eine proprietäre Ausführungs-Engine, die die Ausführung von herstellerspezifischer Geschäftsregellogik ermöglicht.

Anwender sollten sich von den Begrifflichkeiten allerdings nicht täuschen lassen. Im Markt sind Ausführungs-Komponenten verfügbar, die DMN und FEEL voll unterstützen und vom Hersteller als ‘Rule Engine’ vermarktet werden. Es sind aber auch Ausführungs-Komponenten verfügbar, die DMN und FEEL nicht unterstützen und als ‘Decision Engine’ bezeichnet werden.

Modellierungs-Standards & Conformance Levels

Insbesondere in großen Organisationen finden sich häufig verschiedene BRM-Technologien und unterschiedliche Ansätze zur Dokumentation und zur Automatisierung von Entscheidungen und Regeln. DMN ermöglicht Unternehmen, einen einheitlichen, systematischen Ansatz für die gesamte Organisation einzuführen.

Beim Blick auf DMN zeigt sich dasselbe Phänomen, das bereits aus dem BPM-Bereich (Business Process Management) bekannt ist. Dort gab es (und gibt es immer noch) eine Vielzahl proprietärer BPM-Ansätze und -Technologien. Die Object Management Group (OMG) führte deshalb den BPMN-Standard (Business Process Model and Notation) ein. Einige Unternehmen adaptierten BPMN, andere wiederum nutzten weiterhin proprietäre (herstellerspezifische) Ansätze – schlicht weil letztere ihre individuellen Bedürfnisse besser erfüllten. Mit DMN verhält es sich voraussichtlich ähnlich. Einfach gesagt, ist DMN folglich für BRM (und Decision Management), was BPMN für das Geschäftsprozessmanagement ist.

Bei der Auseinandersetzung mit dem DMN-Standard kommt den “Conformance Levels” eine besondere Bedeutung zu. Worum geht es? Die DMN-Spezifikation definiert drei Conformance Levels. Diese Conformance Levels zeigen die Übereinstimmung eines Softwareprodukts mit den DMN-Standardspezifikationen auf. Alle drei Conformance Levels unterstützen die Definition von Entscheidungsanforderungen (DRDs), Entscheidungslogik und Entscheidungstabellen. Sie unterscheiden sich jedoch auf der Implementierungsebene, also bei der automatisierten Ausführung von DMN-Entscheidungsmodellen und bei der Austauschbarkeit dieser Modelle mit DMN-Software eines anderen Anbieters.

  • Conformance Level 1 bedeutet, dass die DMN-Entscheidungsmodelle nicht interpretiert werden können. Dies bedeutet im Wesentlichen, dass ein entsprechendes DMN-Projekt auf die Entscheidungsmodellierung beschränkt wäre.
  • Conformance Level 2 bedeutet, dass eine DMN-Implementierung S-FEEL (Simple Enough Expression Language), eine Teilmenge von FEEL, interpretieren kann.
  • Conformance Level 3 bedeutet, dass eine DMN-Implementierung FEEL (und S-FEEL) interpretieren kann. Dies ist das höchste (vollständige) Conformance Level.

Bei der Evaluierung von DMN-Software sollte deshalb vorab Klarheit über das zu erreichende Ziel herrschen: Werden Entscheidungen nur dokumentiert? Dann reicht ein einfaches Modellierungstool mit Unterstützung des Conformance Levels 1 aus. Wenn das Ziel hingegen Automatisierung und Herstellerunabhängigkeit ist, sollten Unternehmen auf vollständige Standardkonformität (Conformance Level 3) achten.

DMN vs. BPMN – Entscheidungen vs. Prozesse

Wie bereits erwähnt, ist DMN für das Decision Management, was BPMN für das Business Process Management ist. Und da der DMN-Standard (wie auch der BPMN-Standard) von der Object Management Group veröffentlicht wird, überraschend es wenig, dass diese Standards komplementär sind. Für Unternehmen, die bereits BPMN einsetzen, kann DMN eine nützliche Erweiterung sein, um die Komplexität ihrer BPMN-Modelle zu reduzieren und diese zu optimieren.

Die direkte Einbettung von Entscheidungen in BPMN-Modelle (ohne DMN) kann sehr intransparent und komplex werden. Es ist daher sinnvoll, Entscheidungsmodelle (und Logik) in DMN-Modelle auszulagern, die dann mit den BPMN-Modellen verknüpft werden. Dies ist in erster Linie eine Frage des Requirements Engineering. Technisch gesehen werden Entscheidungen auf Basis von (Web)-Services getroffen und automatisiert ausgeführt – dies gilt sowohl für DMN-basierte Entscheidungen als auch für BRM-basierte Entscheidungen.

Warum ist es sinnvoll, Entscheidungsmodelle von Prozessmodellen zu trennen?

  • Prozessmodelle dienen der Abbildung von Prozesslogik (Orchestrierung), während Entscheidungsmodelle Intelligenz und komplexe Geschäftslogik abbilden. Prozesse stellen sicher, dass Prozessschritte effizient ausgeführt werden. Entscheidungen stellen sicher, dass Business Value geschaffen wird, d. h. durch Entscheidungsmodelle, die auf hohe Profitabilität und geringes Risiko optimiert sind.
  • Prozesse sind normalerweise über Monate oder Jahre hinweg stabil, während sich die Entscheidungslogik häufiger ändert (aufgrund von Marktveränderungen, neuen Richtlinien, neuen Vorschriften usw.). Durch die Entkopplung von Entscheidungen und Prozessen lassen sich unabhängige Änderungszyklen realisieren. Decision Management-Technologie ist die Lösung, um diese Änderungszyklen effizient zu managen.
  • Entscheidungen werden oft von verschiedenen Prozessen, Systemen und Kanälen gemeinsam genutzt. In vielen Fällen ist dafür kein Geschäftsprozessmanagement erforderlich. Durch zentralisiertes Decision Management können Unternehmen Konsistenz sicherstellen, den Wartungsaufwand reduzieren und die Business-Agilität verbessern (Whitepaper zum Thema).

Unterschied zwischen DMN und BRM – die Take-Aways

Wie Sie sehen können, gibt es einige grundsätzliche Unterschiede zwischen DMN und BRM sowie Interdependenzen und Überschneidungen mit anderen Ansätzen und Disziplinen. Um die wichtigsten Take Aways zusammenzufassen:

  • Was sind die zentralen Vorteile von DMN gegenüber BRM?
    DMN ist ein herstellerunabhängiger, offener Standard und verbessert die Transparenz durch Einführung einer neuen Anforderungs-Ebene über dem BRM.
  • Sollten Unternehmen DMN einsetzen?
    Unternehmen, die auf Herstellerunabhängigkeit und Standardisierung setzen, sollten sich mit DMN auseinandersetzen. Dabei sollten sie allerdings genau die Anwendungsfälle prüfen: Erfüllt DMN die fachlichen und technischen Anforderungen? Softwarehersteller bieten immer noch eine Vielzahl proprietärer Ansätze zur Nutzung ihrer Technologie und es gibt meist Gründe, warum Unternehmen diese Ansätze anwenden.
  • Wird die Bedeutung von BRM abnehmen?
    Nein. Einzelne Aspekte der Entscheidungsfindung werden weiterhin auf vordefinierten Elementen (präskriptive Geschäftsregeln) basieren, wie etwa regulatorische Anforderungen, interne Richtlinien, Risikomodelle oder Kundenpräferenzen. Andere Aspekte der Entscheidungsfindung werden jedoch vermehrt prädiktive Technologien wie Machine Learning einsetzen, z. B. zur Betrugserkennung.
  • Wie unterscheidet sich DMN-Software von BRM-Software?
    DMN ist lediglich ein Standard. Der wahre Business Value kommt durch die Automatisierung von Entscheidungen. Diese sowie die Verwaltung von Entscheidungen erfordert immer noch eine Decision Engine und andere Komponenten, die Anwender im gesamten Decision-Management-Lebenszyklus unterstützen. Dies kann ein Business-Rules-Management-System oder eine Decision-Management-Suite mit DMN-Unterstützung sein.

Wir hoffen, der Artikel konnte etwas Klarheit schaffen über den Unterschied zwischen DMN und BRM. Falls Sie Fragen haben, sprechen Sie uns einfach an.

Weiterführende Links

Screencast: Entscheidungsmodellierung mit DMN

Erfahren Sie im Video mehr über den DMN-Standard zur Modellierung, Dokumentation und Automatisierung von Entscheidungen.

Jetzt Screencast ansehen
Video zu DMN in Compliance & Risikomanagement

Wie Sie die Anforderungen von Compliance und Risikomanagement mit DMN effektiv umsetzen können.

Jetzt Video ansehen
Business Rules Management steigert Agilität

Durch BRM erreichen Unternehmen ein Maximum an Agilität, indem sie Fachlogik mittels Geschäftsregeln von Prozessen und Anwendungen entkoppeln.

Weitere Informationen

Kontaktieren Sie uns