Każdego roku prowadzę kilka, bywa że kilkanaście, szkoleń z zakresu modelowania procesów biznesowych z użyciem notacji BPMN. Do tego w ramach zająć jakie prowadzę na uczelni (studia niestacjonarne) wykłady i laboratoria z obszaru analiz i modelowania z użyciem sformalizowanych notacji (UML, BPMN, SBVR). To znaczy, że mam co roku kontakt co najmniej z kilkudziesięcioma osobami zajmującymi się praktycznym stosowaniem tych notacji. W ogromnej większości przypadków dostrzegam ten sam problem: brak wiedzy i zrozumienia pojęcia abstrakcji i umiejętności modelowania warstwy abstrakcyjnej analizowanego podmiotu.
Tym tytułowym mitem jest teza, że zawsze można używać wszystkich dostępnych symboli i należy tworzyć diagramy detalicznie opisujące wszelkie czynności.
Na początek cytat z oryginalnej specyfikacji (Business Process Model and Notation (BPMN)
Version 2.0.2):
2.2.1 BPMN Process Types
The implementations claiming Process Modeling Conformance MUST support the following BPMN packages:
- The BPMN core elements, which include those defined in the Infrastructure, Foundation, Common, and Service packages (see Clause 8).
- Process diagrams, which include the elements defined in the Process, Activities, Data, and Human Interaction packages (see Clause 10).
- Collaboration diagrams, which include Pools and Message Flow (see Clause 9).
- Conversation diagrams, which include Pools, Conversations, and Conversation Links (see Clause 9).
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 ConformanceClass. It is based on experience gathered in BPMN training and an analysis of user-patterns in the Department of DefenseArchitecture 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.
Mamy więc trzy typy modeli:
- opisowe (descriptive), wykorzystują podstawowe elementy notacji, tylko ich graficzne atrybuty, pokazują procesy na wysokim poziomie abstrakcji jako ich architekturę (ogólny, abstrakcyjny przepływ pracy),
- analityczne (analytic), pokazujące to co modele opisowe, te modele wykorzystują już ok. połowy wszystkich zdefiniowanych elementów notacji (nadal bez ich wewnętrznych atrybutów), służą do analiz i modelowania konkretnych wzorców zachowań i procesów, także procedur,
- wykonywalne (common executable), zorientowane na tworzenie detalicznych modeli, możliwych do implementacji (uruchomienia) w środowiskach BPMS.
Wykonywalne ze swej natury, tworzone są z użyciem wszystkich pojęć BPMN i ich atrybutów. Celem ich tworzenia jest uruchomienie procesów w środowisku BPMS, jest praca analogiczna do programowania.
Modele opisowe i analityczne, to abstrakcyjne modele, a celem ich tworzenia jest udokumentowanie mechanizmów opisujących funkcjonowanie organizacji z perspektywy przepływu pracy i powstających jej produktów. Pozostaje więc powiedzieć, że nie ma sensu na modelach opisowych i analitycznych używanie pojęć i atrybutów nie wnoszących wartości dodanej do tych modeli a przeznaczonych do tworzenia model wykonywalnych. To dlatego na tych – analitycznych – modelach używa się maksimum ok. połowy elementów zdefiniowanych w notacji BPMN i to głównie te abstrakcyjne.
Typowym przykładem są zadania (task):
10.3.3.1 Types of Tasks
There are different types of Tasks identified within BPMN to separate the types of inherent behavior that Tasks might represent. The list of Task types MAY be extended along with any corresponding indicators. A Task which is not further specified is called Abstract Task (this was referred to as the None Task in BPMN 1.2). The notation of the Abstract Task is shown in Figure 10.8.
Predefiniowane typy zadań (service task, send task, manual tast, itp.) to symbole reprezentujące konkretne wykonywalne elementy i parametry (atrybuty) zadań na poziomie skryptów BPEL4WS czy XPDL. Stosowanie ich na opisowych czy analitycznych modelach warstwy abstrakcyjnych nie ma większego sensu, zaciemnia diagram, a u wielu ich adresatów prowokuje ich intuicyjne interpretowanie, co dodatkowo prowadzi do wielu nieporozumień i pomyłek. Innymi słowy stosowanie na diagramach symboli przeznaczonych do interpretowania w środowiskach BPMS (zapisane jako BPEL4WS lub XPDL) na diagramach nie przeznaczonych do takiej interpretacji (opisowe i analityczne), a tylko do komunikowania architektury procesów lub mechanizmu działania organizacji, po protu nie ma sensu i szkodzi.
Zjawisko nadużywania tych symboli jest niestety dość powszechne na świecie, wielu autorów publikacji o stosowaniu BPMN, zwraca jednak uwagę na błędne stosowania formalnych notacji: jako biblioteki (fajnych) symboli. Notacje formalne to sformalizowane systemy pojęciowe, modele te to nie infografika prezentacyjna, to języki, których elementy cechuje określona semantyka i syntaktyka, których należy po prostu przestrzegać, bo bez tego diagramy te będą tylko obrazkami a nie modelami a ich interpretacja będzie niejednoznaczna.
Nagminnie spotykam się z diagramami podobnymi do tego:
Biorąc pod uwagę to, że nie jest to model procesu do wykonania w środowisku BPMS, diagram jest typowym przykładem przerostu formy nas treścią, czegoś co w literaturze nazywane jest „spaghetti-modelingiem”. Myślę, że sama nazwa wyjaśnia co autorzy tego określenia mieli na myśli.
Diagramy opisowe i analityczne reprezentują raczej poziom szczegółowości jak poniżej:
Warto pamiętać, że modele analityczne to także modele opisowe, jednak na tyle precyzyjne, że pozwalają np. na analizy możliwych optymalizacji, analizy przepływu informacji czy analizy wymagań na oprogramowanie. Przykładem modelu opisowego jest np. ten diagram:
Source: BPM Professional: Using Extension Artefacts in BPMN Process Model
Warto pamiętać, że symbol DataObject to abstrakcja reprezentująca określony dokument, z reguły formularz. Słownik kluczowych pojęć (Specyfikacja BPMN, dodatek C) zawiera dwie ważne definicje: atomic activity oraz business process. Proces biznesowy to aktywność (lub ich ciąg) prowadząca do powstania określonego biznesowego rezultatu. Atomowa (elementarna) aktywność to element, który nie jest już dalej dekomponowany, graficznie jest to Zadanie (Task) w notacji BPMN. Tak więc tworząc na opisowe, a nawet analityczne, modele procesów biznesowych, podstawowym blokiem konstrukcyjnym jest Zadanie i Dokument jaki tworzy (lub zmienia), nie ma więc sensu „obrazkowe” opisywanie wypełniania pól tego dokumentu w postaci diagramu i ciągu zadań z wariantami na nim. Treść dokumentu (DataObject, w tym rygory treści jego pól) dokumentuje się biznesowym słownikiem pojęć i regułami biznesowymi np. wartość upustu wybieramy z tablicy promocji, gdzie pojęcia upust i promocja mają swoje definicje.
Podobnie nie ma sensu na modelach analitycznych umieszczanie elementów takich jak „system IT” bo modele opisowe i analityczne, to modele biznesowe nazywane CIM (Computation Independent Model) czyli modele niezależne od oprogramowania (patrz OMG MDA).
O modelach wykonywalnych (common executable) nie tu piszę, bo rośnie sceptycyzm co do ich tworzenia. Dostawcy systemów BPMS (środowisk wykonywalnych BPM) tworzą własne rozszerzenia notacji BPMN lub nie raz stosują własne notacje, by możliwe było w pełni wykorzystanie dostarczanych rozwiązań i uwzględnienie ich ograniczeń.
W latach 60-tych powstała notacja IDEF0 (modelowanie procesów biznesowych do celów analitycznych), podstawowym zaleceniem metodycznym było tam modelowanie na takim poziomie abstrakcji, by poszczególne diagramy mieściły się na poziomo zorientowanych kartkach A4 i było czytelne, co gorąco polecam.
A tu przykładowe zastosowanie modelu analitycznego w notacji BPMN:
- tego, że zgodnie z BPMN 2.0 można do diagramów dodawać inne elementy .…
- tego jak przejść, zgodnie z definicjami procesów i przypadków użycia, od modelu procesu do modelu przypadków użycia:
