Plakat DMN Feel

Z przyjemnością informuję, iż w ramach AION opracowaliśmy i opublikowaliśmy nasz własny plakat prezentujący konstrukcje języka DMN FEEL, mogące znaleźć zastosowanie do opisu logiki decyzyjnej. Wkrótce pojawi się nadrzędny plakat, prezentujący konstrukcje DMN.

Zapraszamy do lektury.

Recenzja: The Microguide to Process And Decision Modeling

Process and Decision ModelingDwa miesiące temu znalazłem w końcu czas, by przeczytać książkę, która czekała na mnie dłuższą chwilę. Kupiłem ją mając wątpliwości czy określenia microguide oraz process and decission modeling wzajemnie sobie nie przeczą. Nie mniej jednak, kupiłem, gdyż dopóki nie przeczytałem, nie wiedziałem. Poniżej, garść subiektywnych wrażeń po lekturze. Na wstępie, przedmowa autorstwa James’a Sinur’a, w której czytamy

For organizations that have a planning culture, this book is a bible […]

Stwierdzenie motywujące, więc tym chętniej zagłębiam się w lekturę.

Wstęp. Kilka stron poświęconych głównym wątkom książki: procesowi, decyzji oraz zdarzeniu (biznesowemu). Warte przeczytania, gdyż z jednej strony prezentują znaczenie każdego z aspektów opisu organizacji, z drugiej, porządkują wiedzę.

Rozdział 1. Definitions. Podobnie jak w przypadku wstępu, rozdział służy uporządkowaniu wiedzy. Metodą zstępującą, czytelnikowi prezentowane są różne aspekty procesowości, inżynierii decyzji oraz zdarzeń. Autorzy anonsują wzorce modelowania decyzji oraz, w stopniu adekwatnym do rozmiaru książki, omawiają zależności łączące reguły biznesowe oraz decyzje. Rozdział jak najbardziej wart poświęcenia czasu; także przez osoby, które w każdej z dziedzin mają już własne doświadczenia.

Rozdział 2. Modeling Basics. Tutaj autorzy troszkę mnie zaskoczyli. Większą część rozdziału zajmuje bowiem wstęp do składni BPMN 2.0., który, moim zdaniem, jest zbyt powierzchowny, by czegokolwiek praktycznego nauczyć, natomiast zbyt rozbudowany, by odwołać się do intuicji. Niejawnie założyłem, iż autorzy będą się koncentrowali na wskazywaniu zależności łączących dwa wymienione w tytule aspekty funkcjonowania organizacji, więc po przebrnięciu przez rozdział w poszukiwaniu sensu, czułem się lekko zawiedziony.

Rozdział 3. Building on the Basics. Analogicznie, jak w rozdziale poprzednim, autorzy wprowadzają kolejne konstrukcje BPMN. I tak samo, jak w poprzednim rozdziale zbyt szczegółowo i zbyt pobieżnie.

Rozdział 4. Handling Complexity. Walki z BPMN ciąg dalszy. W rozdziale załączono wyjątkowo dużo informacji dostępnych wprost w specyfikacji BPMN 2.0, co jeszcze bardziej pogarsza moją ocenę.

Rozdział 5. Business Events and Business Event Modeling. Ten rozdział ponownie trafia w moje oczekiwania. BPMN jest w nim omówiony w kontekście modelowania zdarzeń biznesowych, a w zasadzie w kontekście traktowania organizacji jako systemu reagującego na zdarzenia. Wartościowe spojrzenie, wartościowy fragment książki, materiał stymulujący do rozważań.

Rozdział 6. Connecting Decisions in DMN to Processes in BPMN. Analogicznie jak w przypadku rozdziału 5, bardzo wartościowy fragment książki. Kolejny rozdział, w ramach którego autorzy wywiązują się z obietnicy złożonej tytułem książki. Przykłady omawiane w rozdziale są na tyle rozbudowane, by dotknąć rzeczywistości analitycznej i wskazać kierunki myślenia przy podejmowaniu niektórych rodzajów decyzji związanych ze sposobem interpretowania i modelowania biznesu.

Rozdział 7. Execution Semantics. W rozdziale autorzy powracają niestety do wcześniejszych praktyk tłumaczenia BPMN, tym razem na poziomie wykonywalnym. Moim zdaniem, zupełnie niepotrzebny rozdział, tym bardziej, że z praktycznego punktu widzenia, niewiele można z niego wynieść.

Rozdział 8. Conclusions. Krótko i zwięźle.

Aneks A. Commercial Information. Reklamy.

Podsumowując, w mojej opinii „mniejsza połowa” książki stanowi o jej wartości, dużej wartości. Połowa większa, stanowi dodatek, którego wartości nie dostrzegłem. Jest to w moim mniemaniu materiał na inną pozycję, w ramach której należałoby go jednak poszerzyć o aspekt praktyczny, aby stanowiła nową wartość na dość dobrze już rozwiniętym rynku książek typu „BPMN 2.0 od podstaw”.

Dane bibliograficzne:

Taylor, James; Debevoise, Tom (2014-12-05). The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling, ISBN-10: 1502789647, ISBN-13: 978-1502789648

Odnośnik do Amazon.com.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

IT czy nie IT, oto jest pytanie.

RulesSurfując po sieci, natrafiłem na post zamieszczony na niniejszym blogu, którego fragment przykuł moją uwagę na dłuższą chwilę:

Wydaje się, iż delegowanie ludzi Biznesu do pracy z typowo informatycznymi narzędziami, jakimi są maszyny regułowe, nie jest działaniem optymalnym z punktu widzenia skuteczności i efektywności prac w ramach architektury biznesowej.„  źródło

Pomyślałem, że często, spotykając się z klientami biznesowymi, stykam się z takim przekonaniem, że zmiany w systemach informatycznych powinny robić osoby, które się na tych systemach znają. Zazwyczaj zaraz za taką tezą pada kolejna:

„…niestety nawet proste zmiany trwają strasznie długo i czasem kosztują absurdalnie dużo”.

Moim zdaniem myślenie w ten sposób jest spowodowane przyzwyczajeniem do tego, że w technologiach i przy architekturze systemów sprzed kilku lub kilkunastu lat zmiany były możliwe tylko w kodzie przez programistów – magików. Nie ma to najczęściej nic wspólnego z możliwościami współczesnych systemów informatycznych.

Już jakiś czas temu rozpoczęła się lekka odwilż w takim myśleniu o temacie i przy tworzeniu specyfikacji rozwiązania informatycznego coraz częściej pojawiają się zapisy o „konfiguracji biznesowej”. Najczęściej ma ona postać listy parametrów, które użytkownik z odpowiednimi uprawnieniami może zmienić bezpośrednio w aplikacji.

Nie zawsze tak musi być

Dwa lata temu miałem przyjemność uczestniczyć w projekcie, w którego wymaganiach pojawiło się coś więcej – możliwość zmiany algorytmów decyzyjnych przez zamawiającego.

Całą  wymaganą „konfigurację biznesową” oraz wszystkie reguły biznesowe, tablice decyzyjne czy algorytmy przenieśliśmy do osobnego rozwiązania, które umożliwiło w sposób graficzny modyfikować te elementy systemu (kilka informacji na temat jego architektury można znaleźć tutaj „Zastosowanie zewnętrznego silnika obliczeniowego w systemie IT”). Przy realizacji tego zamówienia cały czas zastanawialiśmy się, czy rzeczywiście klient weźmie na siebie odpowiedzialność za zmiany i będzie w stanie  je realizować we własnym zakresie.

System został wdrożony. Na początku wyznaczony analityk klienta realizował drobne zmiany, głównie dotyczące pojedynczych wartości liczbowych: stawek, wartości procentowych, wysokości limitów, itp. Zmiany w algorytmach, nawet te najprostsze, trafiały do nas.

Po pół roku funkcjonowania systemu zostaliśmy poproszeni o przeprowadzenie szkolenia z konfiguracji silnika obliczeniowego na poziomie zaawansowanym dla kilku pracowników. Obecnie, to właśnie osoby biznesowe zarządzają pełną konfiguracją w tym obszarze.

To właśnie „ludzie biznesu” dostrzegli potencjał, jaki daje im takie podejście:

  • nie trzeba czekać na dostępność „zasobów” zewnętrznych działów,
  • nie trzeba nikomu tłumaczyć, co należy zmienić,
  • nie trzeba spisywać dokumentacji,
  • nie trzeba podpisywać dodatkowych umów CR,
  • koszt zmiany jest praktycznie zerowy, a niektóre pojedyncze, drobne zmiany można przeprowadzić w kilkanaście minut.

Takie podejście pozwala im na samodzielne i dynamiczne sterowanie procesami i logiką działania wielu obszarów aplikacji końcowej: funkcjonalności sprzedażowych, windykacyjnych, przydzielania prowizji czy oceny klienta. Pozwala to na szybkie reagowanie na to, co dzieje się aktualnie na rynku (więcej o tym projekcie można znaleźć „Elastyczne reguły – elastyczny biznes”).

Podsumowanie

Najważniejszym krokiem i zmianą, która była potrzebna w organizacji nie jest system informatyczny – klient już go miał. Zmianie musiał ulec sposób postrzegania tego, czym jest konfiguracja biznesowa i co tak naprawdę współczesne systemy informatyczne pozwalają bezpiecznie modyfikować bez konieczności zmian w kodzie. Gdy klient zna biznes, zmiana wielu elementów, przy zachowaniu odpowiednich zasad, jest bezpieczna.

Z roku na rok dostrzegam wzrost świadomości możliwości technologii i wzrost kompetencji w firmach wspierających swoją działalność systemami informatycznymi. Dzięki temu, że rozwiązania informatyczne mają coraz większe możliwości konfiguracji, zadania, które kiedyś były możliwe do wykonania przez programistów stają się możliwe do wykonania przez osoby z wiedzą biznesową. Zyski z takiego podejścia zachęcają kolejne firmy do inwestowania w technologie, które im to umożliwiają.

Autor: Paweł Ociepka, http:/www.algorithmssystem.com/blog/

Reguły biznesowe a reguły decyzyjne

DecyzjaPojęcia te, jak zauważam, są stosowane zamiennie. A nie powinny. Można uznać, iż reguła decyzyjna, rozumiana jako wiedza potrzebna do podjęcia określonej decyzji w określonym miejscu funkcjonowania organizacji, jest szczególnym rodzajem reguły biznesowej. Aczkolwiek, pojęcie reguły biznesowej jest dużo szersze.

Próbując zarysować różnicę pomiędzy pojęciami, warto przypomnieć sobie wpływ reguły biznesowej na przebieg procesu biznesowego, opisany we wpisie RuleSpeak: behawioralne reguły biznesowe a model procesów. Omawiany w nim przykład pokazywał, iż konieczność przypisania dedykowanego sprzedawcy do obsługi zamówienia priorytetowego może sprawić problem przy: obsłudze zamówienia, obsłudze zatrudnienia pracowników (rozstanie się z pracownikiem pełniącym taką rolę wobec zamówień, długotrwała nieobecność pracownika, itd.). Fakt złamania reguły biznesowej i wynikająca z niego konieczność wykonania określonych działań korekcyjnych nie jest decyzją sensu stricte, lecz obsługą wystąpienia, przewidzianego w modelu organizacji, zdarzenia.

Reguły decyzyjne mają inne zastosowanie. Ich celem jest opisanie wiedzy potrzebnej do podjęcia określonej decyzji w określonym miejscu przebiegu procesu biznesowego (na potrzeby wpisu, ograniczę rozważania do organizacji zarządzanej procesowo). Zakłada się, iż decyzja taka ma charakter powtarzalny (czyli, powołanych zostanie wiele instancji procesu, zawierającego odwołanie do reguły decyzyjnej) i bardziej operacyjny, niźli strategiczny (aczkolwiek tak być nie musi). Przykład procesu, który mógłby być uzupełniony o regułę decyzyjną, przedstawia poniższy diagram.

Przykład przebiegu procesu zawierającego miejsce podejmowania decyzji

Przykład przebiegu procesu zawierającego miejsce podejmowania decyzji

W zależności od liczby kryteriów branych pod uwagę przy wyznaczaniu sposobu obsługi Zamówienia, liczby przypadków decyzyjnych oraz ustalonych standardów architektury biznesowej, logika decyzyjna mogłaby się znaleźć na przepływach warunkowych bądź też zostać ukryta w regułach decyzyjnych (opisanych, na przykład, tabelami decyzyjnymi), skutkując umieszczeniem na przepływach warunkowych wyników procesu decyzyjnego; takie podejście zostało zilustrowane na prezentowanym diagramie.

Ustanawiając docelowy sposób opisywania logiki decyzyjnej, warto brać pod uwagę nie tylko aspekt dokumentacyjny, ale w co najmniej równym stopniu, również aspekt facylitacyjny. Z mojego doświadczenia wynika, iż umiejętne stosowanie na przykład tabel decyzyjnych, w zauważalny sposób może przyczynić się do zwiększenia efektywności i skuteczności prac analitycznych dając w efekcie dobry jakościowo produkt.

Więcej o współczesnych metodach tworzenia modeli decyzyjnych, w tym między innymi o DecisionSpeak™ oraz The Decision Model,  będzie można poczytać w kolejnych wpisach.