O notacji tej mówi się od kilku już lat. Początkowo spotkać można było opinie, że będzie częścią BPMN, a także że będzie jej konkurencją itp.. Pojawiały się nawet tezy (wróżby lub groźby 😉 ), że będzie to dobre narzędzie do „rozrysowywania” złożonych przepływów w procesach (nadzieja dla zwolenników algorytmizacji firm…). Jednak nie. Walka z „kilerem” projektów, jakim jest „utrata panowania nad złożonością diagramów”, z tworzeniem monstrualnych diagramów ocierających się o próby algorytmizowania organizacji trwa.
Niedawno napisałem:
Modele analityczne, jak sama nazwa wskazuje, to modele których celem jest stworzenie abstrakcji, modelu pozwalającego na prowadzenie analiz a nie uruchamianie czy nawet symulacja modelowanych konstrukcji. Każda analiza to praca z uproszczeniami. Te uproszczenia mają na celu pozbycie się zbędnych szczegółów, tych nieistotnych dla danego badanego zagadnienia. (Źródło: Analityczne i wykonywalne modele).
Dlatego model analityczny procesu, poziom jego szczegółowości raczej wygląda tak:
Przypomnę, że podstawowym „blokiem konstrukcyjnym” w takich analitycznych modelach jest proces biznesowy czyli „chronologiczny łańcuch zadań, przetwarzająca określony stan wejścia procesu w stan jego wyjścia”, te stany to określone zestawy informacji (danych, w BPMN DataObject na diagramie zobrazowane jako karteczka z zagiętym rogiem). Elementarnym (atomowym) procesem biznesowym jest jedna aktywność i jej wejście i wyjście. Na diagramie powyżej mamy proces biznesowy obsłużenia pisma (na wejściu Pismo a na wyjściu Odpowiedź) składający się z czterech „atomowych” procesów biznesowych (pojedynczych aktywności mających wejście i wyjście). Każda z aktywności na diagramie może mieć potencjalnie nawet bardzo złożoną i wielowariantową procedurę realizacji. Zobrazowanie jej w postaci „algorytmicznego” diagramu (np. także z użyciem BPMN, albo co gorsza, wrysowanie tej złożoności bezpośrednio w diagram powyżej!!!) doprowadzi do próby stworzenia mega-diagramu, kosztownego zarówno na etapie jego tworzenia jak i aktualizacji!
Ratunkiem przed utratą panowania nad złożonością takich detalicznych schematów blokowych nadal jest stosowanie pisemnej formy reguł biznesowych i powoływanie się na udokumentowane w projekcie umiejętności i kompetencje wykonawcy (ról). Jednak taka forma (pozostawienie procedur poza modelem) nie poddaje się łatwo analizie tak, jak można to zrobić z modelami wyrażonymi w określonej notacji (analizy wpływu, weryfikacje kompletności i spójność itp.). Zgrabnym wyjściem z tej sytuacji w BPMN, jest stosowanie diagramów z aktywnościami ad-hoc.
I tu z pomocą przychodzi CMMN. Notacja ta pozwala na tworzenie modeli opisujących to, jakie powinności i możliwości ma wykonawca (performer w BPMN), jakie zależności powodują to, że w danej konkretnej sytuacji wydarzy się taki nie inny scenariusz. Jednak nie polega to na tworzenia tych paskudnych zawiłych algorytmicznych monstrualnych diagramów. Polega to na opisaniu tego jakie aktywności muszą być wykonane (aktywności planowane do realizacji) , jakie mogą być wykonane (aktywności przewidziane ale nieobligatoryjne) oraz tego, jakie reguły (warunki) tym wszystkim sterują (Tablica planowania). Nie powstaje więc model „algorytmu” a model „tego co musi i czym dysponuje” wykonawca. To „jak” ma to robić opisują detaliczne dokumenty, reprezentowane na modelu jako Case files i Tablice planowania (może ich być wiele i mogą być skojarzone z konkretnymi elementami).
Notacja CMMN to tak na prawdę rozwinięta i uporządkowana metoda modelowania przypadków (wnętrze aktywności), których realizacja to złożony zestaw aktywności ad-hoc mogący wygenerować bardzie wiele konkretnych indywidualnych scenariuszy. W BPMN był by to albo zestaw niepowiązanych logiką aktywności ad-hoc albo monstrualny bardzo trudny w percepcji diagram, z niezliczoną liczbą rombów decyzyjnych (nie wiedzieć czemu tę wersję upodobała sobie znaczna większość analityków).
Na powyższym modelu w notacji BPMN jest zobrazowana, między innymi, aktywność Opracowanie odpowiedzi. Próba stworzenia modelu opisującego wszelkie możliwe, planowane i dopuszczalne zachowania wykonawcy, skończy się mega-diagramem. Użycie notacji CMMN (i logiki tworzenia w niej modeli) zaowocuje mniej więcej takim o to diagramem:
Nie planuję tu opisywania z detalami notacji CMMN, polecam dostępną specyfikację, a w lżejszej formie ). Mam nadzieję, że komentarze co nieco wyjaśniają. Celem moim było teraz jedynie pokazanie tego, że taka notacja jest, jak można jej użyć w analizach i jaką korzyść daje przejście z mozolnego pisania procedur w edytorach tekstów na modele, które stają się częścią całego modelu (w jakimś narzędziu CASE), poddającemu się analizie oraz kontroli spójności. Notacja jest kompatybilna pojęciowo z BPMN, powstała jako narzędzie do modelowania tego co objawia się złożonością na najniższym poziomie. Po prawej stronie, często tu przytaczany, model poziomów abstrakcji w modelowaniu organizacji. CMMN plasuje się narzędzie modelowania pracy ludzi na najniższym trzecim poziomie. Nie zastępuje żadnej z obecnych notacji.
Case Management Model and Notation. Formal Version of CMMN. (OMG CMMN). Polecam do modelowania z użyciem CMMN CASE ArchiMetric 🙂
Polecam też ciekawą prezentację firmy CAMUNDA:
Chyba strzałka z zestawu danych «Odpowiedź na pismo [Opracowana]» do «Nadanie pocztą kurierską» ma zły wektor…
Tak :), „literówka”, już poprawiłem i bardzo dziękuję za zwrócenie uwagi. Ciesze się, gdy ktoś uważnie czyta to co piszę.
„Opis zadania” chyba jest przygotowany w złym momencie, bo jeśli nie ma potrzeby budżetowania, to jest nadmiarowy. Element BR002 to nie wiadomo co to ma być, bo nie przypomina żadnego elementu z notacji BPMN?
Co zaś do radzenia sobie ze złożonością, to kto broni zagnieżdżać poszczególne poziomy procesu (nad)używając zamiast „normalnych” czynności elementu call activity. A jak komuś wynikająca z tego hierarchia nie przekłada się na rzeczywistość to można kombinować z odwzorowywaniem struktur sieciowych/relacyjnych przekazywaniem przepływów przy użyciu zdarzeń sygnałowych.
Opis zadania powstaje jeżeli pojawia się wydatek.
Element BR002 to reguła biznesowa, umieszczona jako symbol na diagramie BPMN, zgodnie z opisem rozszerzania notacji (dodawanie elementów na diagramach, BPMN 8.3.3 Extensibility).
Pisałem o złożoności diagramów a nie modeli jako takich. Rzecz w tym by jeden diagram nie był „przesadnie rozrośnięty”.
Metoda zagnieżdżanie zależy od tego jaki model mamy na myśli, gdyż generalnie mamy modele poglądowe, analityczne i wykonywalne (BPMN 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.
W modelach analitycznych (czyli wszystkich nie przeznaczonych do implementacji bezpośredniej) stosowanie „call activity” nie ma sensu, w modelu analitycznym o znaczeniu decyduje (unikalna) nazwa aktywności a nie odwołanie do podprogramu (call activity) wymagane tylko w modelach wykonywalnych.
Problem złożoności rozwiązujemy:
– stosując elementy „sub-process” (aktywność mająca dekompozycję opisaną także modele BPMN) czyli budując modele zagnieżdżone
– dokumentując detale aktywności innymi metodami (procedury opisane numerowanymi krokami, inne notacje, tu np. CMMN)
Toż dzięki „call activity” możemy w miejscu zadania wpakować w diagram wysokopoziomowy pełnoprawny, niezależny proces niższego poziom – przypominam, ze element ten zastąpił w notacji podprocesy reużywalne (a nie żadne tajemnicze „podprogramy”!), więc jeśli mamy organizacje procesów z których da się ułożyć coś na kształt hierachii to zdarzeń „call activity” NIE powinniśmy się spodziewać na poziome najniższym, czyli wykonywalnym. Czyli jest dokładanie nie odwrót w stosunku do tego co piszesz 🙂
Sugeruję jako źródło oryginalną aktualną specyfikację BPMN. Do zagnieżdżania (tworzenia hierarchii procesów) służą aktywności „sub-process”. ?Call activity?, jak sama nazwa wskazuje, służy do wywołania w jednym procesie wcześniej już zdefiniowanego zadania (a konkretnie jego BPEL’ową realizację). Pojęcie aktywność w BPMN to abstrakcja oznaczająca albo „atomowe zadanie” albo „zdefiniowany pod-proces”.
Rozdz. 7.3.1.
An Activity is a generic term for work that company performs (see page 149) in a Process. An Activity
can be atomic or non-atomic (compound). The types of Activities that are a part of a Process Model are: Sub-Process and Task, which are rounded rectangles.
Rozdz. 10.3.6 Call Activity
A Call Activity identifies a point in the Process where a global Process or a Global Task is used. The Call
Activity acts as a ?wrapper? for the invocation of a global Process or Global Task within the execution. The
activation of a call Activity results in the transfer of control to the called global Process or Global Task.
Innymi słowy: na danym diagramie mamy aktywności, jeżeli jest nią sub-process oznacza to, że istnieje inny diagram BPMN (lub CMMN, jednak ta notacja najwyraźniej nie podbiła świata), który opisuje jej detale, jeżeli jest nią Call Activity, oznacza to wyłącznie re-użycie (odwołanie) do raz już (gdzieś) zdefiniowanej „globalnej” (wspólnej re-używalnej) aktywności (w rozumieniu jej wykonywalna część, procedura, skrypt BPEL itp.). Stosowanie Call Activity na modelach analitycznych nie bardzo ma sens bo nie definiujemy tu globalnych implementacji aktywności.
Co do hierarchii procesów/pod-procesów: czysta drzewiasta struktura jest nie do obrony, to fakt… :), mój ulubiony przykład to Archiwizacja dokumentu, która może wystąpić na dowolnym poziomie i w dowolnym procesie… Można ją udokumentować jako pod-proces BPMN (diagram dziurkacz -> właściwy segregator -> właściwy pokój -> właściwa szafka) i użyć dowolną ilość razy gdziekolwiek, jednak nie ma tu sensu stosowanie call activity bo na modelach analitycznych nazwa jednoznacznie identyfikuje aktywność i praktycznie każde narzędzie CASE wspiera tę formę tworzenia modeli (jeżeli na kilku diagramach jest aktywność o tej samej nazwie, to jest to taka sama aktywność, więc także i pod-proces).
Poprzednik „Call activity” był jak najbardziej aktywnością typu „sub-process”, a chyba z samej zmiany konwencji nazewniczej nie wynika zamian możliwych zastosowań, prawda? Proszę też zwrócić uwagę na to, że pozostałe do dyspozycji aktywności ?sub-process? są na tyle biedne, że nie pozwalają by osadzone procesy miały własne pule, tory, a już broń boże aby w innych kontekstach były osobnymi procesami! W ten oto spośób jeśli mamy proces o nazwie „porada prawna”, z której to porady korzystają użytkownicy innych procesów to albo: 1. modelujemy go w sposób „subprocesowy” i niereużywalny, albo 2. korzystamy z „call activity” lub ze zdarzeń sygnałowych. I nie jest tak jak Pan sugeruje – wybór nie zależy jedynie od tego czy „gdzieś tam” ktoś już taki diagram popełnił, decyzja zależy w dużej mierze od nieobecności metody alternatywnej – wtenczas trzeba ten „wywoływany” proces zdefiniować, nawet jeśli wcześniej nie miało się na to ochoty
„Atomowe zadanie” to jest coś o czym wszyscy mówią, a nikt jeszcze nie dał radę dać niezależnej od kontekstu i celu modelowania definicji – po prostu nie istnieją obiektywne i uniwersalne kryteria dzięki którym można na 100% orzec, że modelować dalej nie można lub się nie powinno. Niestety bardzo często wykorzystują to wykonawcy analizy, którym nie chce się za bardzo drążyć.
Atomowa aktywność ma definicję w specyfikacji BPMN (Dodatek C) i jest to prosta definicja:
Atomic Activity: An activity not broken down to a finer level of Process Model detail. It is a leaf in
the tree-structure hierarchy of Process activities. Graphically it will appear as a Task
in BPMN.
… resztę wyjaśniłem…
Jeszcze jedna ważna uwaga: model wykonywalny to nie jest kolejny najniższy poziom szczegółowości w stosunku do modeli analitycznych, to zupełnie inny model… Np. pula w modelu analitycznym reprezentuje podmiot (business, enterprise) a w modelach wykonywalnych serwer BPMS. Na modelach analitycznych jedna firma to jedna i ta sama pula, w modelach wykonywalnych, pula to serwer, i może wystąpić w ilości większej niż jedna w tej samej firmie, i tego się już pogodzić nie da.
Tory mają sens tylko na modelach analitycznych i służą do partycjonowania obszaru puli (znaczenie toru należy zadeklarować w modelu, z reguły są to role lub komórki organizacyjne), w modelach wykonywalnych torów się nie stosuje z zasady (wykonawce zadania wskazuje parametr zadania „performer”, nie mający znaczenia i nie używany w modelach analitycznych). To tylko główne różnice, jest ich więcej.