Bernd Rücker Camunda

DMN ist extrem spannend, da die Modelle für die Verständigung zwischen Fachbereich und IT sehr gut geeignet sind.

Decision Model and Notation (DMN) ist der neue Standard zu Entscheidungen von der Object Management Group (OMG), die auch BPMN oder UML standardisiert hat. Die wichtigste Zielsetzung dabei ist, eine Notation zu definieren, die Fachseite und IT gleichermaßen verstehen, um damit eine Brücke zwischen beiden Welten zu bauen.

In diesem Artikel betrachten wir anhand des Praxisbeispiels „Skill-based Routing“, also der automatisierten Entscheidung, welcher Sachbearbeiter eine bestimmte Aufgabe durchführen soll, warum DMN die Brücke zwischen IT und Fachabteilung sein kann. DMN unterscheidet dafür zwischen Entscheidungsanforderungen (Decision Requirements) und Entscheidungslogik (Decision Logic). Die theoretische Seite beleuchtete bereits Marcus Winteroll in seinem Artikel „Entscheidungen mit der DMN analysieren und modellieren“ im Business Technology 2.2015. Wieder zurück zum Praxisbeispiel: Nehmen wir an, Sie melden einen Autounfall an Ihre Versicherung. Daraufhin muss der Versicherer wichtige Entscheidungen treffen, z. B. ob der Schaden automatisch reguliert werden kann, um Aufwand zu sparen, oder falls nicht, welcher Sachbearbeiter den Schaden bearbeiten soll. Die zweite Entscheidung wird als Skill-based Routing bezeichnet, da man aus einer Menge von Mitarbeitern anhand deren Fähigkeiten (Skills) den am besten geeigneten Mitarbeiter heraussuchen möchte. Sollte nicht so schwer sein, oder?

Decision Requirements: Anforderungen an Entscheidungen definieren

In einem Praxisprojekt haben wir in einem Workshop die Anforderungen an diese Entscheidung herausgekitzelt und modelliert. Hierbei ist das so genannte Decision Requirements Diagram (DRD) eine große Hilfe: Es zerlegt die eigentliche Entscheidung, hier „passender Mitarbeiter“, in mehrere Teilentscheidungen (Abb. 1). Im Beispiel wird zuerst die notwendige Kompetenz ermittelt (Rechteck = Entscheidung). Dazu wird als Input (= abgerundetes Rechteck) der Schadensfall benötigt. Des Weiteren soll die Erfahrung des Mitarbeiters einbezogen werden, die allerdings in keinem System gepflegt wird. Im Workshop haben wir herausgefunden, dass es eine Freigabekompetenz gibt, also welche Schadenshöhe ein Mitarbeiter noch freigeben darf. Aus dieser Kompetenz soll die Erfahrung abgeleitet werden. Mit diesen Informationen werden alle verfügbaren Mitarbeiter gescort, also Punkte vergeben, wie geeignet ein Mitarbeiter für den aktuellen Fall ist. Den konkreten Mitarbeiter zu bestimmen, ist dann einfach: Es ist der Mitarbeiter mit dem höchsten Score.

Abb. 1: Das Decision Requirements Diagram (DRD) zeigt das Big Picture der Entscheidung

Abb. 1: Das Decision Requirements Diagram (DRD) zeigt das Big Picture der Entscheidung

Das DRD war im Workshop sehr hilfreich, um strukturiert über die Gesamtentscheidung diskutieren zu können. Im Projekt haben wir die Inputs noch feingranularer modelliert, sodass wir auf Basis jedes Attributs klären konnten, ob und in welchem IT-System es zur Verfügung steht. In einer großen Runde aus Fachbereich und IT ließ sich so effizient der Projekt-Scope abstecken, da die Wünsche des Fachbereichs und die Machbarkeit in der IT schnell abgeglichen wurden. An noch nicht zur Verfügung stehende Inputs ließ sich sofort ein grobes Preisschild hängen. Dadurch konnte der Fachbereich entscheiden, ob er dieses Geld in die Hand nehmen möchte, oder doch besser die Entscheidungsfindung anpasst.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Business Technology 1.16 - "Entscheidungswege: Informiert und mutig ans Ziel"

Was es mit DMN – Decision Model and Notation – auf sich hat, zeigt Bernd Rücker im Business Technology 1.16.

Alle Infos zum Heft
208954Decision Model and Notation: Zwischen Fachseite und IT
X
- Gib Deinen Standort ein -
- or -