Równo 10 lat temu napisałem:

Model firmy powinien w sposób jasny i zrozumiały dla pracowników firmy opisywać firmę, jej cel rynkowy oraz wszelkie jej wewnętrzne i zewnętrzne zachowania oraz reakcje. Poza tym, jest niezbędny do przewidywania zachowań firmy w tym także do przygotowania jej do wdrożenia systemów informacyjnych. Wiele firm doradczych i informatycznych pod pojęciem mapy i modelu procesów biznesowych dostarcza nieprzydatne, utrwalone na dziesiątkach diagramów opisy czynności realizowanych przez ankietowanych pracowników, które nie wiele mają wspólnego z planowanymi zmianami na lepsze.Większość modeli firm jakie widziałem to obrazki nie mające wiele wspólnego z procesami. Zdarza mi się otrzymywać zlecenia, których głównym celem jest ocena cudzej dokumentacji przedwdrożeniowej. Bardzo często jest to sieczka w postaci udokumentowanych życzeń i wyobrażeń ankietowanych pracowników firmy… (Źródło: Modelowanie biznesowe czyli pilnowanie hochsztaplerów)

I niestety nie wiele w tym względzie się zmieniło od tamtego czasu. Zmieniło się jednak to, że funkcyjna idea modelowania organizacji w postaci modelu procesów  biznesowych ma już ugruntowaną pozycję, i mamy postęp w postaci powstania, i ugruntowania sobie pozycji jako standardu de’ facto, notacji [cm_tooltip_parse]BPMN[/cm_tooltip_parse].

Wtedy powoływałem się na notacje IDEF0, w której fundamentem jest funkcyjny blok konstrukcyjny:

Powyższy diagram to wykonany w notacji [[IDEF0]] model procesu jako funkcji, jej wejścia, wyjścia, sterowania i mechanizmu działania. Systemowe (naukowe, czyli pozwalające na testowanie modelu i jego falsyfikacje) modelowanie organizacji nadal bazuje na pojęciach z tej (IDEF0) notacji i modelu procesu ICOM (ang. Input, Output, Controll, Mechanizm):

Idea ta bazuje na uznaniu, że każdy proces biznesowy to wnoszące wartość dodaną funkcja przekształcająca wejście w wyjście procesu, przekształcenie to, sposób jego realizacji, jest ograniczone a działania, ich mechanizm, mogą być definiowalne jako deterministyczne. Notacja IDEF0 była długo stosowana jednak miała podstawową wadę: znacznie strzałek (semantyka notacji) było uzależnione od ich położenia, co utrudniało weryfikację modeli, utrudniało ich tworzenie i narażało te modele na niejednoznaczność przy ich czytaniu (pamiętamy, że model to także treść czyli komunikacja).

Notacja BPMN nie ma tej wady ale też nie zawiera takich pojęć jak Controll i Mechanizm. BPMN to przede wszystkim przepływ pracy oraz dane wejściowe i wyjściowe (diagram powyżej). Jednak notacja ta pozwala na rozszerzanie semantyki o nowe symbole. Bardzo złą praktyką jest nanoszenie na modele procesów (diagramy BPMN dla tych procesów) detali związanych ze sposobem działania czyli logiką biznesową i mechanizmem podejmowania decyzji. Modele takie stają się bardzo szczegółowe a utrzymanie ich aktualności (stanowią dokumentację procesów) praktycznie nie jest możliwe (każda zmiana sposobu działania wymaga korekty tych diagramów). Tworzenie takich, zbyt szczegółowych, modeli określane jest w literaturze określane wręcz jako “utrata panowania nad szczegółowością projektu”.

Od lat stosowane są, jako uzupełnienie modelowania organizacji, macierze [[RACI]], pozwalają one, jako uzupełnienie np. modeli BPMN,  osobno udokumentować złożone zależności pomiędzy rolami w procesie (więcej o RACI…..). Takie elementy pojęciowe ICOM jak Controll i Mechanizm można (zaleca się) modelować jako system reguł biznesowych i tabel decyzyjnych.

Model procesu wykonany w notacji BPMN, uzupełniony o sterowanie i mechanizm podejmowania decyzji, wygląda tak:

Zadanie 1 zostało tu skojarzone z Reguła biznesową (Controll) i Tablicą decyzyjną (mechanizm). Reguły biznesowe to sformalizowane zapisy określające “panujące prawo” w organizacji (np. zarządzenia i regulaminy). Tablice decyzyjne to sformalizowane macierze opisujące deterministyczne decyzje (konkretna odpowiedź systemu w odpowiedzi na konkretny zestaw bodźców). Wejście i wyjście to nic innego jak odpowiednio oznaczone Dane (Obiekt danych w BPMN). Szczegóły wykonania Zadania to albo wiedza i umiejętności wykonawcy albo procedura (np. ISO). W dokumentacji  projektowej powołujemy się na (załączamy) wymagany zakres kompetencji wykonawcy (rola na diagramie procesu) lub załączamy stosowną procedurę (dokument, nie nanosimy na diagram BPMN). Takie niepodzielne już zadanie, wraz z jego wejściem, wyjściem i ewentualnymi regułami to elementarny proces biznesowy.

Tak więc zasady naukowego modelowania (a wcześniej analizy) nie zmieniają się:

1. zdefiniowanie i określenie problemu,
2. analiza i opracowanie hipotezy (modelu, tu badanej organizacji czyli jej modelu procesowego: tak organizacja realizuje swoje cele),
3. testowanie (próba falsyfikacji modelu) w postaci sprawdzania czy są w organizacji dane przetwarzane inaczej niż na modelu,
4. opracowanie wyników, lub korekta modelu w przypadku jego udanej falsyfikacji (wtedy powtarzamy pkt 2. i 3.)
5. opracowanie rekomendacji czyli odpowiedź na pytanie zadane w pkt. 1.

Notacja BPMN do duży krok do przodu, bo narzędzie to ma precyzyjną (poddającą się walidacji), semantykę i syntaktykę, a możliwość nadania modelom kontekstu poprzez dodatkowe użycie macierzy RACI, reguł biznesowych i tablic decyzyjnych, pozwala tworzyć bardzo precyzyjne modele biznesowe możliwe do zarządzania (nie obarczone nadmiarem szczegółów). Wydzielenie poziomu szczegółowości związanego z podejmowaniem decyzji,  poza diagramy (jako załączone elementy), pozwala po pierwsze utrzymać rozsądny  poziom szczegółowości samych diagramów, ich czytelność i zarządzalność, np. zmiana mechanizmu podejmowania decyzji nie wymaga aktualizacji diagramów, bo przepływ pracy nie zmienia się. Poniżej wielokrotnie tu przytaczany model warstwowy;

Środkowa warstwa to wskaźniki (np KPI), architektura procesów, strategie itp. Najniższa warstwa to wszelkie szczegóły takie jak instrukcje stanowiskowe, procedury, zakresy obowiązków, opisy wymaganych umiejętności, instrukcje dla użytkowników urządzeń i oprogramowania, wszelkie inne szczegóły opisujące sposób pracy (nie raz mechanizm jej wykonywania). Środkowa warstwa  to właśnie abstrakcja, jaką jest model procesów biznesowych, jest on opisem przepływu pracy. Na tym poziomie opracowujemy model, który w literaturze z zakresu strategii i zarządzania jest nazywany wewnętrznym łańcuchem wartości w organizacji. Na tym poziomie nie dokumentujemy żadnych szczegółów (powołujemy się na nie, załączamy je), na tym poziomie pokazujemy wyłącznie CO i PO CO się dzieje a nie JAK.  Opis tego jak JAK to się dzieje to właśnie owe Controll i Mechanizm.

Owszem wymaga to użycia dodatkowych elementów na diagramach BPMN, wymaga także także odpowiedniego narzędzia CASE, które na to pozwala, ale warto bo dokumentacja taka staje się łatwa w korzystaniu z niej, mamy zapewniony odpowiedni poziom abstrakcji samych modeli procesów, mamy także osobno udokumentowane szczegóły logiki biznesowej, co bardzo ułatwia (w zasadzie przekazujemy jej bez modyfikacji) postawienie wymagań przed oprogramowaniem, które miało by je implementować (reguły biznesowe i tablice decyzyjne stają się w takim wypadku wymaganiem).