O książce
Książka Real-Life BPMN ma w podtytule: Using BPPMN 2.0 to Analyze, Improve, and Automate process in Your Company. Słowo “automatyzacja” wiele mówi o treści książki ale po kolei.
Kilka razy spotkałem się w środowisku analizy biznesowej z tezą, że książka ta jest bardzo przydatna. Niedawno usłyszałem to kolejny raz. Tak więc kilka uwag do treści (mam drugie wydanie ang. z 2014 roku).
Zacznijmy od tego, specyfikacja BPMN zawiera taki zapis w rozdz.2.2.1.:
As an alternative to full Process Modeling Conformance, there are three conformance sub-classes defined:
? Descriptive
? Analytic
? Common Executable
Descriptive is concerned with visible elements and attributes used in high-level modeling. It should be comfortable for
analysts who have used BPA flowcharting tools.
Analytic contains all of Descriptive and in total about half of the constructs in the full Process Modeling Conformance
Class. It is based on experience gathered in BPMN training and an analysis of user-patterns in the Department of Defense
Architecture Framework and planned standardization for that framework.
Both Descriptive and Analytic focus on visible elements and a minimal subset of supporting attributes/elements.
Common Executable focuses on what is needed for executable process models.
Elements and attributes not in these sub-classes are contained in the full Process Modeling Conformance class.
The elements for each sub-class are defined in the next sub clause.
Innymi słowy: do celów analiz biznesowych i komunikacji ich wyników (adresatem jest człowiek), tworzymy modele analityczne (tu warto wspomnieć, że w UML słowo kluczowe ‘document’ jest definiowane jako “a human-readable file”). Modele wykonywalne (executable) to w zasadzie procedury dla serwerów BPMS (środowiska wykonywania skryptów BPEL4WS, XPDL).
Ta sama, ww. specyfikacja BPMN, w dodatku Słownik (Glossary), podaje definicje:
Process: A sequence or flow of Activities in an organization with the objective of carrying out work. In BPMN, a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flow that adhere to a finite execution semantics. [Sekwencja lub przepływ aktywności w organizacji, których celem jest wykonanie pracy. W BPMN Proces jest przedstawiony jako graf elementów przepływu, które są zbiorem Aktywności, Zdarzeń, Bramek i Linii Przepływów, które mają znaczenie ukończonego wykonania tej sekwencji.]
Innymi słowy, w BPMN ‘proces’ to każda kompletna sekwencja aktywności. Notacja BPMN nie posługuje się pojęciem ‘proces biznesowy’ (nie ma takiego symbolu), pojęcie to występuje jedynie w dodatku:
Business Process: A defined set of business activities that represent the steps required to achieve a business objective. It includes the flow and use of information and resources. [Zdefiniowany zbiór aktywności biznesowych, które reprezentują kroki wymagane do osiągnięcia celu biznesowego. Obejmuje przepływ i wykorzystanie informacji oraz zasobów.]
Kolejna ważna tu rzecz, historia wydań specyfikacji:
VERSION | ADOPTION DATE | URL |
---|---|---|
2.0.2 | January 2014 | https://www.omg.org/spec/BPMN/2.0.2/ |
1.2 | January 2009 | https://www.omg.org/spec/BPMN/1.2/ |
1.1 | January 2008 | https://www.omg.org/spec/BPMN/1.1/ |
1.0 | March 2007 | https://www.omg.org/spec/BPMN/1.0/ |
Mimo, że BPMN od 2011 roku wprowadził podział na modele opisowe i wykonywalne w książce pominięto ten podział i skupiono się tylko na wykonywalnym aspekcie modeli BPMN (dziękuję Piotrowi Biernackiemu z firmy MCX, za uwagi korygujące ten fragment).
Ww. rozdziału 2.2.1. nie ma w wersji 1.2. To wyjaśnia wiele: autorzy książki nie napisali o podziale modeli na analityczne i wykonywalne, bo go wtedy nie było, co kładzie się cieniem na całej jej treści z perspektywy roku wydania. Najprawdopodobniej więc, mino tytułu, książka opiera sie na BPMN v.1.2.
W konsekwencji w ogóle nie ma w niej mowy o podziale procesów na modele analityczne i wykonywalne, za to w rozdz. 3. autorzy wprowadzają pojęcia: “strategic process model”, a pod nim “human process flow” i “technical process flow”, jest też sugestia, że modele “human” są rozwijane do modeli “technical”. Patrząc na obecną specyfikację (ww. rozdz. 2.2.1.) można by szukać tu analogii do modeli analitycznych i wykonywalnych, jednak nie jest prawdą, że modele wykonywalne to rozwinięcie (uszczegółowienie) modeli analitycznych: np. w modelach analitycznych pula to “biznes” (modelowany podmiot), zaś w modelach wykonywalnych pula to serwer BPMS.
Biorąc pod uwagę fakt, że zarówno jedna firma może używać wiele komunikujących się serwerów BPMS (np. departamentowe) lub wiele firm może korzystać z jednego BPMS np. w chmurze, teza że model wykonywalny to uszczegółowiony model analityczny jest nie do obrony. Po drugie modele wykonywalne to deterministyczne procedury a nie, dające jednak pewną swobodę, modele opisujące ludzi mających pewien margines swobody działania. Proces w BPMN to każdy “łańcuch aktywności”, zaś proces biznesowy to “coś” co “wykorzystuje zasoby i informacje” (elementarny proces biznesowy to para aktywność i jej produkt: DataObject). Dlatego określając model jako analityczny (cel biznesowy) aktywności na modelach nie oznaczają (reprezentują) zapisów BPEL/XML a procedury (np. procedury SZJ ISO 9000) realizowane przez ludzi.
I tu pojawia się główna wada tej książki: omawiane w niej procesy i ich przykłady W OGÓLE pomijają elementy “DataObject” czyli całkowicie abstrahują od dokumentów (patrz wyżej definicja dokumentu w UML). Z perspektywy biznesowej (“ludzkiej”) proces biznesowy to para Aktywność-DataObject (praca i jej produkt, patrz ww. definicja pojęcia proces biznesowy). Innymi słowy: książka ta nie mówi nić o modelowaniu procesów biznesowych, jest w całości poświęcona modelowaniu procedur dla serwerów BPMS, z nastawieniem na technologię oferowaną przez firmę Camunda (autorzy są jej założycielami). Jedyne miejsce gdzie pokazano elementy DataObject to jeden, po macoszemu opisany, diagram w rozdziale 3.4. Analiza procesów na poziomie strategicznym.
Autorzy w rozdziale 1.4. A method framework for BPMN, prezentują diagram opisujący strukturę ich metody:
Szczyt to tu przegląd procesów, semantycznie obrazujący logikę działania organizacji, budowany w celu pokazania (szybkiego zrozumienia) tego jak działa organizacja. Poniżej znany od lat w środowisku analiz BPM, schemat obrazujący podstawowe trzy poziomy abstrakcji w modelowaniu organizacji:
A tu umiejscowienie metodyki The Camunda house na tym tle:
Powyższe jest wyjaśnieniem praktycznie całej treści książki: system BPMS Camunda to serwer BPMS, maszyna “programowana” modelami wykonywalnymi BPMN a autorzy, w swojej książce, opisują jak tworzyć te modele i – jak sami pokazują – są to modele opisujące poziom, który jest pomijany (zbyt szczegółowy) na poziomie analitycznym (środkowa warstwa na modelu BP Trends). Niestety ich mapowanie tych warstw jest nieprawidłowe: Camunda to w 100% modele wykonywalne, jest to poziom 3 modelu BP Trends, gdyż jak napisałem powyżej: nie jest prawdą w BPMN, że procesy wykonywalne (technical process flow) są uszczegółowieniem procesów analitycznych (human process flow).
Podsumowanie
Książka w całości traktuje o modelach wykonywalnych, całkowicie abstrahuje od rzeczy najważniejszej w modelach biznesowych: dokumenty i ich treść, słowniki i reguły biznesowe. Teza jakoby model biznesowy działania organizacji można było zobrazować modelami przepływów jest nie do obrony w świetle tego, że “sens” biznesu to informacje (dane) a nie łańcuchy aktywności.
Nie da się zautomatyzować (zalgorytmizować) firmy, wielu próbowało nikt nie dał rady.
Podsumowując mogę powiedzieć, że przydatność tej książki, dla osoby nie będącej użytkownikiem platformy Camunda, jest raczej znikoma. Wartościowy może być rozdział 2. omawiający “na sucho” notację BPMN (o ile ktoś nie lubi czytać oryginalnej specyfikacji), jednak jak na polskie warunki, znacznie efektywniejszym zakupem będzie tu książka Szymona Drejewicza . Od 2014 mamy BPMN z podziałem na modele analityczne i wykonywalne. Te pierwsze to podstawa modeli biznesowych CIM, te drugie odchodzą do lamusa.