Modelowanie decyzji za pomocą notacji DMN – część pierwsza

Decyzje, decyzje…

Modelując procesy biznesowe bardzo szybko napotykamy na miejsca, w których należy podjąć decyzję jaki konkretny scenariusz biznesowy będzie realizowany. Stosując notację BPMN do sterowania przebiegiem procesu mamy tzw. bramki decyzyjne i zazwyczaj ten mechanizm całkowicie wystarcza. Proces „niesie” różnego rodzaju informacje i na ich podstawie możemy podjąć decyzję, jak ów proces dalej ma przebiegać:

• „Przyznać Klientowi upust czy nie?”,
• „Skierować Pacjenta do specjalisty, a jeżeli tak, to do którego?”,
• „Przyznać Klientowi kredyt hipoteczny czy nie?”.

Modelowanie procesów biznesowych to projektowanie różnych scenariuszy biznesowych w zależności od podjętych decyzji. No właśnie, ale co to właściwie jest to „podejmowanie decyzji”.

Decyzja to akt wyboru rezultatu spośród wielu możliwości (alternatyw) na podstawie przyjętych kryteriów (zasad logicznych). Czasami zasady logiczne determinujące decyzje są dość trywialne, np.

• „Jeżeli Klient kupuje towary za kwotę równą lub większą niż trzysta złotych, zwolniony jest z wszystkich dodatkowych opłat związanych z dostarczeniem zakupionych produktów”
• „Jeżeli dzisiaj jest sobota, to obniż ceny o 10%”

Możemy jednak spotkać bardzo skomplikowane kryteria podejmowania decyzji, szczególnie w przypadku gdy przestrzeń decyzyjna (wszystkie możliwe decyzje) jest duża. Przypuśćmy, że chcemy kupić psa. Mamy do wyboru setki ras psów! Liczba czynników determinujących decyzję jest także ogromna. Atrybuty opisujące psa to między innymi: wysokość w kłębie (od 25 cm do 1 m), masa ciała (od 1 do 100 kg), kształt głowy, typ uszu, długość sierści czy też użyteczność psów (psy myśliwskie, psy pasterskie, psy obronne, psy stróżujące, psy pociągowe, psy ozdobne, psy do towarzystwa…). Inne czynniki, które powinniśmy uwzględnić to cena psa, nasze warunki mieszkaniowe, nasze nawyki (czy będziemy w stanie spacerować z psem przynajmniej godzinę dziennie, czy będziemy regularnie poić i karmić psa…), charakter psa i … wiek swoich pociech (nie każdy pies toleruje małe dzieci). Czy to nie dziwne, że ktoś w ogóle decyduje się na zakup psa?

Proces decyzyjny wcale nie musi być racjonalny. Możemy kupić psa pod wpływem impulsu („Jaki piękny szczeniaczek!”), za przyczyną dziecka, które nie daje nam spokoju („Chcę psa!, Chcę psa!, Proszę, proszę, proszę…”), bo czujemy się samotni po stracie kogoś bliskiego lub wreszcie z pobudek bardziej egoistycznych – chcemy zaimponować sąsiadom lub ich przestraszyć (w tym wypadku możemy skorzystać z pomocy Ministra Spraw Wewnętrznych i Administracji, który publikuje wykaz psów agresywnych, takich jak Bull terier, Dog argentyński, Rottweiler, Moskiewski stróżujący czy Owczarek kaukaski). Proces decyzyjny może wyznaczać decyzje optymalne, wystarczające i dopuszczalne.

Kupno psa czy decyzja biznesowa dotycząca nabycia jakieś spółki to decyzje typu strategicznego. Proces decyzyjny w tym wypadku jest zazwyczaj bardzo skomplikowany, a przestrzeń decyzyjna ogromna. Na szczęście dla analityków biznesowych w trakcie modelowania procesów biznesowych najczęściej mamy do czynienia z decyzjami operacyjnymi. Takie decyzje oparte są zazwyczaj na dość ściśle sformułowanych zasadach logicznych, które pozwalają poprzez dokonanie obliczeń, sprawdzanie stanu różnych parametrów biznesowych i zastosowanie określonych algorytmów określić, co w dalszym kroku procesu biznesowego ma być zrobione.

Przez lata do określenia logiki decyzyjnej tworzyło się tzw. rejestry reguł biznesowych, w których zapisywano wszelkie czynniki wpływające na decyzję i różne ich kombinacje w zestawieniu z potencjalnymi decyzjami. Tak zapisane „wymagania biznesowe” mogły stanowić podstawę do ich zaimplementowania z wykorzystaniem Silnika Reguł Biznesowych (BRE – Busines Rule Engine). Do zapisu reguł biznesowych wykorzystywano zazwyczaj arkusze kalkulacyjne lub przedstawiano je w formie tabel. Tak zapisane wymagania były później interpretowane przez architektów rozwiązań IT i programistów i transformowane w wykonywany kod. Taki sposób działania miał tę wielką wadę, że po pierwsze mimo najlepszych chęci interesariusze techniczni byli narażani na popełnianie błędów w procesie translacji wymagań na kod, a po drugie logika decyzyjna to rzecz, która podlega ciągłym zmianom. Ponieważ logika decyzyjna jest rodzajem logiki biznesowej, to ludzie biznesu powinni mieć zdolność do jej definiowania i utrzymywania samodzielnie, bez potrzeby angażowania pracowników technicznych.

Od niedawna mamy wreszcie po raz pierwszy w historii standard przemysłowy pozwalający użytkownikom biznesowym tworzyć wykonywalne modele decyzyjne. Standardem tym jest rozwijana przez organizację Object Management Group (OMG) notacja DMN – Decision Model and Notation. DMN umożliwia analitykom biznesowym, architektom biznesu, ale także „zwykłym” pracownikom biznesowym samodzielne modelowanie logiki decyzyjnej i dbanie o jej stałe aktualizowanie. Zatem zamiast pisania wymagań dla programistów i czekania kiedy zostaną wymagania zaimplementowane, ludzie biznesu mają możliwość bieżącego zarządzania logiką biznesową bez potrzeby asysty technicznej.

Należy tutaj zaznaczyć, że model decyzyjny tworzony przy użyciu notacji DMN to nie to samo, co oparty o tekst dokument wymagań. Wymagania ze swej natury zakładają możliwość zapisywania ich w wielu formach, mniej lub bardziej ustrukturyzowanych. Model DMN to diagramy i tabele o ściśle zdefiniowanej strukturze i dzięki temu może być wykorzystywany bezpośrednio przez silniki BRE, które tak zdefiniowaną logikę biznesową potrafią w 100% zdekodować.

DMN jest standardem przemysłowym. Najnowsza wersja tego standardu (1.1) została opublikowana w czerwcu 2016 (Decision Model and Notation (DMN) V1.1 – OMG Document Number: formal/2016-06-01). Oznacza to, że ani koncepcja DMN, ani definicja tej notacji nie jest własnością żadnego producenta narzędzi CASE czy też jakieś firmy konsultingowej. Standard DMN jest wspierany przez wielu dostawców, a dzięki temu że został zdefiniowany standard XML zapisu modeli decyzji, możliwy jest transfer danego modelu z jednego narzędzia do innego.

Reasumując, DMN jest notacją umożliwiającą:

• Projektowanie modelu decyzyjnego
• Automatyzowanie procesu decyzyjnego
• Monitorowanie i zarządzanie procesem decyzyjnym

Podstawowe koncepcje DMN

Model decyzyjny tworzony jest na dwóch poziomach – Poziomie Wymagań Decyzyjnych (Decision Requirements Level) i Poziomie Logiki Decyzyjnej (Decision Logic Level). Poziom Wymagań Decyzyjnych jest poziomem bardziej abstrakcyjnym i w jego skład wchodzą Graf Wymagań Decyzyjnych (DRG – Decision Requirements Graph), który z kolei jest reprezentowany przez jeden lub wiele Diagramów Wymagań Decyzyjnych (DRD – Decision Requirements Diagrams).

Każdy element decyzyjny obecny na diagramach DRD może być powiązany z tabelami decyzyjnymi, za pomocą których możemy szczegółowo określić logikę decyzyjną.

Dobrą praktyką modelowania procesów biznesowych jest oderwanie reguł biznesowych i logiki podejmowania decyzji od samego procesu. Ilustruje to grafika zaczerpnięta ze specyfikacji DMN:

W modelu wykonywalnym BPMN zadanie „Reguła biznesowa” wywołuje odpowiedni model decyzyjny zaimplementowany w oparciu o silnik reguł biznesowych BRE. Decyzja wypracowana przez BRE wraca do modelu procesów uruchomionego z wykorzystaniem BPMS i pozwala wybrać dalszy przebieg procesu, co oznacza w powyższym przykładzie albo zaoferowanie jakiegoś produktu klientowi, albo rezygnację z przedstawienia oferty. Oczywiście model decyzyjny może też być skorelowany z zadaniem manualnym jeżeli nie jest zaimplementowany silnik BRE. Wtedy model decyzyjny pomaga użytkownikowi w podjęciu decyzji, ale jej nie determinuje w sposób automatyczny.

Decision Requirements Model

Notacja DMN w wersji 1.1 składa się z dziewięciu komponentów konstrukcyjnych podzielonych na trzy rodzaje:

• Elementy
• Wymagania
• Artefakty

Konstruktor	Notacja DMN	Opis
Elementy
Decyzja (Decision)		Decyzja oznacza akt ustalenia jakiejś wartości wyjściowej na podstawie jednej lub wielu danych wejściowych w oparciu o logikę odnoszącą się do jednego lub wielu modeli wiedzy biznesowej.
Model wiedzy biznesowej (Business Knowledge Model)		Model wiedzy biznesowej to rodzaj modelu analitycznego zawierającego wiedzę biznesową w formie reguł biznesowych, tablic decyzyjnych lub innych rodzajów zapisu wymagań biznesowych.
Dana wejściowa (Input Data)		Dana wejściowa oznacza informacje wejściowe na podstawie których podejmowana jest jedna lub wiele decyzji. Jeżeli dana wejściowa jest w związku z modelem wiedzy biznesowej, należy ją traktować jako parametr danego modelu wiedzy.
Źródła wiedzy (Knowledge Source)		Źródło wiedzy oznacza pochodzenie naszej wiedzy dotyczącej procesu podejmowania decyzji. Stanowi ono umocowanie modelu wiedzy biznesowej.
Wymagania
Wymaganie dotyczące informacji (Information Requirement)		Wymaganie dotyczące informacji wskazuje dane wejściowe oraz inne decyzje wpływające na proces podejmowania wskazanej decyzji.
Wymaganie dotyczące wiedzy (Knowledge Requirement)		Wymaganie dotyczące wiedzy wskazuje, jaki model wiedzy biznesowej będzie wykorzystywane w procesie podejmowania decyzji.
Umocowanie wymagania (Authority Requirement)		Umocowanie wymagania wskazuje, które z elementów diagramu DRD są źródłem naszej wiedzy.
Artefakty
Adnotacja tekstowa (Text Annotation)		Adnotacja tekstowa pełnią podobną funkcję jak w notacji BPMN i można za ich pomocą zapisywać dodatkowe informacje pomocne czytelnikowi z zrozumieniu diagramu
Asocjacja (Association)		Asocjacja pełni funkcję łącznika elementów diagramu DRG z adnotacją tekstową

Jak widać, notacja DMN w porównaniu z językiem UML czy też notacją BPMN jest bardzo prosta.

Spróbujmy zatem stworzyć jakiś prosty diagram DRG. Do tego celu będę używał bardzo zgrabnego narzędzia jakim jest Signavio Decision Manager. Jak będzie można zauważyć, elementy „Decyzja” i „Model wiedzy biznesowej” w narzędziu Signavio reprezentowany jest troszkę inaczej niż opisuje to standard OMG i wyglądają one tak, jak na poniższym obrazku:

Zmiana wyglądu tych elementów nie jest przypadkowa, bo autorzy narzędzia wymyślili sprytną sztuczkę jak powiązać diagram DRG z tabelami decyzyjnymi (o tym napiszę w kolejnym artykule).

Przejdźmy zatem do jakiegoś przykładu zastosowania notacji DMN. Wyobraźmy sobie sytuację, że wdrażamy w jakimś przedsiębiorstwie produkcyjnym system zarządzania oparty o jakość (TQM – Total Quality Management). Musimy w zawiązku z tym zaprojektować od nowa wiele procesów, w tym procesy logistyki zaopatrzenia. Chcemy na przykład przyjmować potrzebne nam podprodukty tylko wysokiej jakości. Zatem partie towaru przyjmujemy tylko od Zaufanych Dostawców, którzy poprzednimi dostawami udowodnili, że potrafią dbać o jakość. Stosując zasadę ograniczonego zaufania Inspektor Jakości przed przyjęciem ładunku sprawdza czy dokumentacja jakości towarów jest w należytym porządku, a w przy przypadku pojawienia się jakiejś wątpliwości, może transport odrzucić lub zarządzić procedury sprawdzenia jakości ładunku.

W przypadku gdy pojawi się nowy Dostawca, Inspektor może przed przyjęciem transportu zarządzić badania laboratoryjne próbki towarów, kompleksowy przegląd jakości dostawy lub nawet zażądać wizyty u dostawcy w celu dokonania szczegółowej inspekcji jego procesu produkcyjnego. Podproces kontroli jakości partii dostawy może zamodelowany w BPMN wygląda tak:

W zależności od tego, jakie informacje uzyska Inspektor Jakości podczas sukcesywnego kontrolowania jakości nadchodzących partii towarów, podejmowana jest decyzja przyjęcia dostawy (dlatego ten przebieg oznaczyliśmy gałęzią domyślną), ale w zależności od różnych czynników wejściowych może zostać podjętych szereg czynności pokontrolnych. No właśnie. Co wpływa na podjęcie decyzji pokontrolnej? Do zamodelowania wymagań związanych z tym zagadnieniem posłuży nam diagram DRD.

Jak widzimy z powyższego diagramu, na decyzję określającą które działania pokontrolne należy po przeprowadzeniu inspekcji podjąć wpływa analiza sensoryczna, testy laboratoryjne oraz dwie inne decyzje: ocena jakości produktu i ocena dokumentacji towarzyszącej produktom, a dotyczącej jakości. Źródłem wiedzy dotyczących decyzji określenia działań pokontrolnych jest „Księga dobrych praktyk inspekcyjnych”, zaś „Księga jakości produktu” jest nam pomocna w ocenie dokumentacji i ocenie jakości produktu.