O książce

Książka Real-Life BPMN [zotpressInText item=”{5085975:AFBWILK3}”] 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.

[zotpressInText item=”{5085975:QJUPRFNR}”]

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 [zotpressInText item=”{5085975:CXM2UWU6}”]. Od 2014 mamy BPMN z podziałem na modele analityczne i wykonywalne. Te pierwsze to podstawa modeli biznesowych CIM, te drugie odchodzą do lamusa.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Właśnie skończył się mi instalować upgrade Visual Paradigm v.17. To narzędzie towarzyszy mi od 2005 roku, ale po kolei.

W zasadzie od początku swojej kariery w branży IT modele tworzyłem wyłącznie z użyciem sformalizowanych notacji. Kluczowym powodem zawsze były: kontrolowalna poprawność i logika tych modeli oraz standaryzacja. To troszkę jak z matematyką: wiemy, że dwa i dwa to zawsze cztery a do zakomunikowania tego innym używamy standardowej formy zapisu: 2+2=4. W zasadzie z matematyką nie mamy problemu, problemem są schematy blokowe: wielu ludzi uważa, że to tylko obrazki, które można sobie rysować po swojemu a ikonki notacji to tylko biblioteka fajnych symboli. Niestety nic bardziej mylnego: sformalizowana notacja to język z jego regułami i mającymi określone znaczenie znakami. Nie będę tu tego wątku kontynuował, na moim blogu jest wiele artykułów na ten temat, dzisiaj o narzędziach.

Moja przygoda z modelami zaczęła w latach 90-tych gdy jako analityk projektant musiałem zacząć porządnie dokumentować wyniki analiz i projektowane systemy. Bardzo szybko sie nauczyłem, że wszelkie zaniedbania z mojej strony, szczególnie brak precyzji w opisywaniu firm klientów czy projektowanych rozwiązań, to po prostu brak szacunku dla czasu moich koleżanek i kolegów z działu developmentu.

Pierwsze modele jakie robiłem to były modele procesów i przepływy danych robione z użyciem notacji DFD (nadal zdarza się, że jej używam) oraz IDEF0. W drugiej połowie lat 90-tych pojawia się notacja UML, która w moich projektach (systemy komponentowe zorientowane obiektowo) zaczęła zajmować miejsce DFD. Podstawowym narzędziem początkowo był Staffware (obecnie TIBCO), ale z uwagi na jego “ciężkość” i koszty, przeniosłem sie na “Visio Sampler” (po przejęciu przez Microsoft obecnie MS Visio).

I tak to trwało do 2005 roku, gdy w dużym projekcie dla Echo Investment SA, okazało, że pracochłonność związana z aktualizacją modeli i całęgo raportu z analizy, czyli dokumentu Analiza Biznesowa i Projekt Systemu, z użyciem MS Visio, staje się ogromnych pożeraczem czasu, a ja mam kontrakt “fixed-price”. Tak więc pewnego razu, w hotelu “Łysogóry” w Kielcach, po północy, z wizją niedotrzymania terminów, usiadłem do komputera i zacząłem szukać w Internecie “zbawienia”, porównanie kilku produktów zaowocowało wyborem Visual Paradigm. Głównym konkurentem wtedy był EA SPARX, jednak fakt, że goły EA bez pluginów nie nadaje się do zbyt wielu rzeczy, ma niezgodności ze specyfikacjami BPMN i UML (export XMI, nie pozwala na wielokrotne umieszczanie tych samych elementów na jednym diagramie itp.), sama instalacja i konfiguracja wersji demo zajmowała ponad godzinę, brak (wtedy) możliwości natychmiastowej aktywacji po opłacie kartą kredytową (następnego dnia rano musiałem coś pokazać i nie mogła to być wersja ewaluacyjna i jej znaki wodne), spowodowały, że na placu boju został VP, którego instalacja i aktywacja zajmuje kilka minut, po których nadaje się natychmiast do pracy.

Okazało się, że praca z VP nie wymaga niczego poza znajomością specyfikacji notacji: jak coś jest w specyfikacji to jest także w VP. Do tego suport VP działa natychmiast (odpisują na maile, w skrajnym przypadku “wchodzą” zdalnie na komputer). Z EA miewałem kilka przygód jako podwykonawca w projektach, i za każdym razem wniosek był ten sam: nie rezygnuję z VP.

Jak się z tym narzędziem pracuje? Swego czasu na żywo pokazywałem:

Obecnie mamy wersje 17. Kolejna dojrzalsza wersja, bogatsza o kilka nowinek w stosunku do poprzedniej 16.3.: https://www.visual-paradigm.com/whats-new/

Kluczowe moim zdaniem cechy tego narzędzia to:

1. praktycznie pełna zgodność wspieranych notacji z ich specyfikacjami na OMG.org,
2. potężny generator raportów (nie używam do tego celu MS Office od 2007 roku), pracochłonność opracowywania i aktualizacji dokumentów wynikowych (PDF/docx) spadła niemalże do zera,
3. serwer pracy grupowej (Teamwork Server) w chmurze to:
   1. pełne wersjonowanie (identycznie jak wersjonowanie kodu na serwerach Subversion i podobnych), możliwość budowania gałęzi projektu, powrotu do dowolnej wcześniejszej “revizji”, itp.
   2. praca grupowa na hierarchicznym repozytorium (nie jest to baza SQL, praca off-line gwarantuje pełne bezpieczeństwo),
   3. kontrolowany dostęp do wglądu (rola recenzenta dokumentacji) obywa się bez dodatkowych opłat (moduł Postmania),
   4. synchronizacja skojarzonego z projektem fideru plików (wszelkie załączniki, np. dokumenty źródłowe),
4. możliwość tworzenia diagramów on-line.

To tylko wybrane cechy, w obecnej wersji 17. między innymi dodano nowe funkcjonalności do generatora dokumentacji i elementów zarzadzania projektem. Tak! VP ma potężne narzędzie do zarządzania projektem na etapie nadzoru nad implementację: niezależne wersjonowanie wszystkich elementów modeli i generowanie raportów różnic między “commitami”. Dokumentowanie przypadków użycia zgodne z Use Case 2.0, zgodność ze SCRUM i wsparcie dla zwinnych metod pracy (praca z user story, kanban, i wiele innych).

Od samego początku VP to także wsparcie dla najważniejszych obiektowych wzorców projektowych (Rebeka Wirfbrock i jej książka Wirfs-Brock, R., & McKean, A. (2009). Object design: Roles, responsibilities, and collaborations. Addison-Wesley) i modelowania struktur XML, SOA, RESTfull API, itp.

I na koniec mój drugi “wewnętrzny idol” to cała sekcja UX Design and Wireframe Tools czyli tworzenie makiet ekranów Low Fidelity oraz High Fidelity, a także map i animowanych modeli ich przepływu. Więcej tu: Makiety.

Tak więc mając Visual Paradigm, niczego więcej nie potrzebuję i z przyjemnością powitałem na moim komputerze wersję 17.0 do czego zachęcam innych użytkowników VP. Pozostałych zaś informuję, że jest takie narzędzie ;).