Wprowadzenie

Regularnie widuję monstrualne diagramy, na których ich autorzy usiłują modelować decyzje podejmowane w toku przepływu pracy. Pierwsze nieporozumienie (i duży  błąd pojęciowy) na tych diagramach, to łączenie na jednym diagramie elementów procesu biznesowego, z tym jaka “praca myślowa” wykonawcy ma być w danym procesie (aktywności) wykonana. Drugi błąd to mieszanie poziomów abstrakcji: proces biznesowy to dość duży poziom ogólności (uogólnienia), jego celem jest pokazanie celowości łańcucha pracy (procesy biznesowe to aktywności tworzące produkty) a nie tego, jak jest w detalach wykonywana:  wnętrze tych aktywności – ich szczegóły – na tym poziomie są nieistotne.

BPMN-Graphical-Representation-spaghetti

Kolejną  przyczyną powstawania tak zwanych “spaghetti modeli” jest “rysowanie” na diagramach reguł biznesowych zamiast powoływać się na nie. O tym pisałem już wcześniej (Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć | Jarosław Żeliński IT-Consulting).

Tak więc osobna specyfikacja reguł biznesowych stanowi system reguł dla całej organizacji. Nie musimy dziesiątki razy nanosić na diagramy symboli wyjaśniających detalicznie, dla każdego procesu i roli, że np. faktura zakupowa o wartości przekraczającej 1000zł musi być dodatkowo zatwierdzona .. i tu ścieżka zatwierdzeń, bo takich sytuacji mogą być w większej firmie nawet setki. Wystarczy, że raz zdefiniujemy (lub pomagamy analizowanej firmie zdefiniować w toku analizy i pisania rekomendacji) regułę brzmiąca np. że “żaden pracownik średniego szczebla nie może samodzielnie zatwierdzać kosztów przekraczających dwukrotność jego wynagrodzenia netto”. Takiej regule w dokumentacji nadajemy identyfikator i nazwę, i powołujemy się na nią w modelu procesów. Skutek jest taki, że diagramy stają się prostsze, zaś zmiana tej reguły nie wymaga przeglądu wszystkich modeli i ich aktualizacji, wystarczy korekta w specyfikacji tych reguł. Dodatkowo, w przypadku pisania wymagań na oprogramowanie, wystarczy załączyć specyfikacje reguł biznesowych zamiast wypisywać nie raz setki tak zwanych “case’ów”.

Na pytanie klientów: ile pracy trzeba żeby utrzymywać aktualność opracowanych modeli procesów biznesowych? Odpowiadam: bardzo mało, wystarczy zarządzać regułami biznesowymi a te są w Zarządzaniach Zarządu.

Tablice decyzyjne

Są kolejnym narzędziem w modelowaniu organizacji, z jednej strony porządkującym wiedzę o niej, z drugiej upraszczającą diagramy modeli procesów. Diagramy przestają być tak zwanymi “spaghetti modelami”, a zaczynają być zwięzłymi, mieszczącymi się na stronie A4, diagramami modelującymi procesy biznesowe. Przykładem dość często spotykanego “boju ze złożonością” są procesy, w których pojawia się rabat. Widuję je na diagramach modelujących procesy (np. w notacji BPMN) jako monstrualne “drzewa decyzyjne” i niekończące się ścieżki opisujące przypadki, w których komuś należy się określony rabat. O tablicach pisałem już kilka razy, jednak tym razem chciałem zwrócić uwagę na pewną przypadłość bardzo wielu projektów: utrata panowania nad złożonością opisu (modelu) i “płynięcie” w tak zwany “case management”.  Pierwsze to umieszczanie na diagramach wszelkich poznanych szczegółów wiedzy o danym procesie (mieszanie poziomów abstrakcji), drugi to opisywanie konkretnych przypadków zamiast poprzestać na zasadach (regułach) (do opisu, zamodelowania, gry w szachy należy spisać tylko reguły gry, a nie tworzyć opisu setek poznanych partii, gdzie i tak wszystkich możliwych nie opiszemy).

Zamiast opisywać skomplikowane “procesy decyzyjne”  w postaci niemalże “algorytmizacji świata” (model procesu wygląda jak rozbudowane drzewo decyzyjne z dziesiątkami wariantów) , lepiej skupić się (i poprzestać) w modelu na tym, jakie decyzje są faktycznie podejmowane, i na “skutkach”, które mają znaczenie w procesie biznesowym.

Bardzo często mamy do czynienia z dziesiątkami możliwości, dużymi ilościami potencjalnych faktów, jednak “obsługiwane są” (mają znaczenie, reagujemy na) tylko niektóre z nich lub ich kombinacje. Jak już w innym artykule wspominałem: ilość możliwych kombinacji trzech kolorów sygnalizatora na krzyżowaniu jest większa niż kombinacje opisane (mające znaczenie) w Kodeksie Drogowym, kierowca reaguje na określoną kombinację, nie analizuje w myślach tego, jak mogą być ze sobą skojarzone poszczególne kolory i w jakiej kolejności się pojawiać – to zbyt absorbujące. Tak samo “działa” biznes: reagujemy na konkretne fakty lub ich kombinacje, pozostałe po prostu ignorujemy bo nie mają znaczenia, nie ma więc sensu zajmowanie się nimi i dokumentowanie ich (modelowanie).

Przypuśćmy, że nasi klienci są podzieleni na cztery grupy docelowe, a do tego każdy z nich, zależnie od historii obrotów, może być sklasyfikowany jak Platynowy, Złoty, Srebrny i Ołowiany  (:)). I teraz załóżmy, że mamy promocję, ta jednak obejmuje wyłącznie klientów Srebrnych z segmentu 2, o ile mają siedziby w woj. Mazowieckim oraz klientów Ołowianych z segmentu 3 o ile mają siedzibę w woj. Podkarpackim. Innymi słowy, z pośród setek możliwych kombinacji obsługujemy wyłącznie dwie. Tworzenie diagramu w sposób: czy klient jest Platynowy? Nie, Czy jest Srebrny, Tak, Czy jest z województwa……. prowadzi do mega diagramu. Zamiast tego tworzymy prostą tablicę decyzyjną, która zawiera wyłącznie obsługiwane w procesie pojedyncze fakty lub ich kombinacje (reguły) oraz przyporządkowane im akcje (działania w postaci konkretnego upustu), nic ponad to (resztę kombinacji po prostu ignorujemy, nie ma potrzeby ich opisywania). Takie decyzje są podejmowane w “jednym kroku”. Tak jak kierowca: reaguje natychmiast na określoną kombinację kolorów na sygnalizatorze, nie analizuje tego jakie inne w ogóle są możliwe. Gdyby ktoś z nas zobaczył na sygnalizatorze zapalone światło czerwone i zielone jednocześnie, raczej uzna to za awarię i zignoruje, niż zacznie analizować jak się to ma do innych możliwych kombinacji i co ma z tym począć (inny, bardziej “prawdziwy”  przykład).

Modele procesów, w których  złożone decyzje są modelowane z użyciem reguł biznesowych i tablic decyzyjnych, a nie z pomocą kaskad dziesiątków bramek decyzyjnych, są prostsze w zrozumieniu, kontrola ich spójności i poprawności jest znacznie łatwiejsza. Reguły biznesowe i tablice decyzyjne pozwalają na ich bezpośrednią implementację w aplikacjach, a same diagramy są znacznie łatwiejsze w czytaniu i aktualizacji. Ich złożoność nie zabija wzroku ;).

Tablice decyzyjne, jako narzędzie na etapie analizy, pozwalają także na bardzo łatwe wychwytywanie reguł nadmiarowych, sprzecznych i innych pozbawionych sensu.

Na koniec kilka obrazowych przykładów, które  nawet dla osób słabo znających język angielski powinny być łatwe do zrozumienia.

Decision table provides a handy way to represent business logic. Check out what is a decision table, what decision table can do and learn how to draw professional decision table with decision table software.
(źr. http://www.visual-paradigm.com/product/articles/decision-table-explained/)

Na zakończenie zaryzykuję tezę, że autor diagramu nie mieszczącego się na stronie A4, utracił panowanie na złożonością projektu…. i diagram płynie w stronę talerza spaghetti…

Sztuczna inteligencja

Najpierw definicja:

Sztuczna inteligencja to (SI) zdolność maszyn do wykazywania ludzkich umiejętności, takich jak rozumowanie, uczenie się, planowanie i kreatywność. Sztuczna inteligencja umożliwia systemom technicznym postrzeganie ich otoczenia, radzenie sobie z tym, co postrzegają i rozwiązywanie problemów, działając w kierunku osiągnięcia określonego celu. Komputer odbiera dane (już przygotowane lub zebrane za pomocą jego czujników, np. kamery), przetwarza je i reaguje. Systemy SI są w stanie do pewnego stopnia dostosować swoje zachowanie, analizując skutki wcześniejszych działań i działając autonomicznie.

źr.: https://www.europarl.europa.eu/news/pl/headlines/society/20200827STO85804/sztuczna-inteligencja-co-to-jest-i-jakie-ma-zastosowania

Jeżeli więc zapewnimy sprzężenie odpowiednie zwrotne między realnym światem a systemem powiązanych tablic decyzyjnych, otrzymamy system cechujący sie samoregulacją i samoadaptacją:

[świat realny] -> [wskaźnikowy system monitorowania] -> [system adaptacji tablic decyzyjnych] -> [system wpływający na świat realny] -> [świat realny]

Typowym zastosowaniem może być system ERP, do którego dodano hurtownię danych i system BI, którego efekty obliczeń modyfikują wagi w systemie tablic decyzyjnych, a te z kolei (decyzje) wpływają na budżety, plany, zamówienia, itp..

Taki system symuluje: uczenie się i dążenie do poprawy wyników: “Komputer odbiera dane (już przygotowane lub zebrane za pomocą jego czujników, np. kamery), przetwarza je i reaguje. Systemy SI są w stanie do pewnego stopnia dostosować swoje zachowanie, analizując skutki wcześniejszych działań i działając autonomicznie.”

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.