Wprowadzenie
Ostatnio pojawiła się w prasie i mediach internetowych dyskusja na temat tego czym jest faktura, niestety bardzo wiele z tych opinii jest pozbawiona podstaw merytorycznych i prawnych, są niejednokrotnie po prostu nieprawdziwe. Biorąc pod uwagę fakt, że wiele tych opinii to opinie wygłaszane przez przedsiębiorców, wyłania się smutny obraz jakości informacji zbieranej metodą wywiadów w toku analiz biznesowych. Studiowanie literatury, cudzych opracowań w roli audytora, analiza pytań i uwag moich klientów to ogromne doświadczenie. Rok temu w artykule Mit o notacji BPMN pisałem o szkodliwości nadmiaru szczegółów na modelach. To wszystko razem skłoniło mnie tym razem do opracowania przykładu diagramu obrazującego proces biznesowy wykonany w notacji BPMN1.
Celem tego artykułu jest pokazanie jak opracować model procesu biznesowego bazując wyłącznie na prawie i tego jak to zrobić zgodnie z notacją BPMN. Pokazano także, że notacja BPMN nie jest narzędziem dokumentowania „wszystkiego co wiemy o procesie”. Istotne jest także to, że notacja BPMN to język wyrazu – narzędzie – a nie metodyka, oraz to że specyfikacja BPMN to nie podręcznik modelowania a jedynie opis pojęć i ich znaczeń oraz przykłady konstrukcji (semantyka i syntaktyka notacji) co nie znaczy, że są to wzorce projektowe. Uważam, że wzorców takich nie ma takich w biznesie, procesów „referencyjnych” też nie ma. Biznes to prawo oraz indywidualne wewnętrzne regulacje.
W ramach wprowadzenia opisano najpierw zasady tworzenia modeli analitycznych z użyciem notacji BPMN.
Notacja BPMN a MDA i UML
Kilka uwag na temat notacji BPMN i kluczowych jej cech. Celem stworzenia tej notacji była komunikacja:
The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.[BPMN c.1.1. 1]
Generalnie rzecz biorąc (patrz moje wytłuszczenie): diagramy te powinny być zrozumiałe dla tak zwanych ludzi biznesu (bo jeżeli nie są, to są bezużyteczne), stanowią (sformalizowany) szkic dla ludzi odpowiedzialnych za ich implementację. Modele procesów biznesowych stanowią element modeli CIM (Computational Independent Model, model niezależny od technologii IT2).
Poniżej cytuję akapit opisujący istotę podziału modeli na poziomy abstrakcji (dokładności).
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. [BPMN c.2.2.1.1]
Istotą modelowania procesów z użyciem BPMN jest więc właściwy dobór poziomu szczegółowości. Powyższe ma znaczenie w kontekście umieszczenia tych typów modeli na tle MDA (Model Driven Architecture2) i skorelowania z modelami UML.
Na poziomie CIM powstają modele opisujące mechanizm działania organizacji w całkowitym oderwaniu od technologii IT wspierających tę organizację. Notacja BPMN jest tu wspierana specyfikacją SBVR3 (biznesowy słownik pojęć i reguły biznesowe). Są to wyłącznie modele poglądowe i analityczne.
Kolejny krok to opracowanie modeli wykonywalnych czyli modeli implementacji procesów (wyrażonych w BPMN) z użyciem systemów BPMS (Business Process Management Systems, są to środowiska wykonawcze modeli BPMN common executable). W praktyce te modele mają wersję PIM (wykonane na bazie standardu BPMN/BPEL/XPDL) i PSM czyli dostosowane do środowiska BPMS konkretnego producenta platformy. Jest to ścieżka bazująca całkowicie na notacji BPMN i platformach wykonawczych BPMS.
Proces „tradycyjny” inżynierii oprogramowania oparty na MDA także zaczyna się powstania modelu CIM. Kolejny etap (model) to zawarcie umowy na zakres projektu czyli określenie wymagań. Do tego służy model przypadków użycia (w UML od wersji 2.5 jest jawnie określany jako „dodatkowy”, patrz Figure 6.1 Semantic Areas of UML4):
Biorąc pod uwagę zmiany jakie wprowadzono do UML w v.2.5. w zasadzie książki i podręczniki UML napisane przed 2015 rokiem (wejście 2.5. UML), można wyrzucić do kosza.
Po określeniu zakresu produktu, powstaje model PIM stanowiący model mechanizmu działania oprogramowania. Ten model to specyfikacja logiki działania (często stanowi know-how zamawiającego). Po dokonaniu wyboru dostawcy, ten – mając na uwadze technologię której użyje, tworzy model PSM i realizuje implementację (w praktyce, pomija się model PSM, najczęściej powstaje od razu kod na bazie architektury opisanej w modelu PIM).
Zostało to zobrazowane na diagramie poniżej:
Proces realizacji potrzeb przedsiębiorstwa
Proces realizacji potrzeb przedsiębiorstwa (organizacji) jest inicjowany stwierdzeniem owej potrzeby (wymagana usługa, przedmiot, inne) a kończy się rozliczeniem jej realizacji (dostarczenia). Standardowy proces świadczenia usługi lub dostarczenia produktu jest opisany w Kodeksie Cywilnym5 (zlecenie lub dzieło). Co do zasady więc, na pewnym określonym poziomie szczegółowości, proces ten jest możliwy do opisania bez jakichkolwiek konsultacji z kimkolwiek, treść ustawy wystarczy.
Opis procesu: Pojawianie się potrzeby skutkuje opracowaniem zapytania ofertowego (opis przedmiotu zamówienia jakim może być usługa lub produkt). Z reguły przybiera formę Zapytania ofertowego. Zapytanie takie przekazywane jest potencjalnemu dostawcy, który opracowuje ofertę na realizację tego co opisano w Zapytaniu. Oferta taka jest analizowana, jeżeli zostanie przyjęta, staje się umową pomiędzy Nabywcą a Dostawcą. Umowa ta stanowi podstawę Realizacji zamówienia (jakim jest zaakceptowana oferta). Po zrealizowaniu Zamówienia Dostawca zgłasza gotowość przekazana przedmiotu zamówienia, następuje odbiór. Po odbiorze jest wystawiana faktura na kwotę wskazaną w Ofercie, w określonym terminie ma miejsce płatność. Zamówienie jest zrealizowane i rozliczone.
Opisane aktywności są uzależnione od określonych terminów. Biorąc pod uwagę fakt, że udział biorą w tym procesie dwa podmioty, a całość jest synchronizowana terminami (muszą one być ustalane) proces ten można opisać takim modelem:
Powyższy diagram to model analityczny. Model poglądowy byłyby uproszczony do aktywności i dokumentów, zapewne były by to dwa odrębne proste modele (dla Dostawcy i dla Zamawiającego).
Jak widać uwzględniono na tym modelu (model analityczny) kluczowe fakty jakimi są terminy i momenty doręczenia. Wszelkie detale poszczególnych aktywności stanowią najczęściej specyfikę konkretnych podmiotów i są opisane procedurami (np. procedurami ISO z godnie ze stosowną normą). Dokumentowanie tych detali z użyciem kolejnych, szczegółowych diagramów w notacji BPMN z reguły nie ma sensu, gdyż ich adresatami (recenzentami) byli by (są) wykonawcy tych prac, a Ci raczej bez problemu posługują się procedurami w typowej postaci znanej z norm (testy), a nie diagramami BPMN. Umieszczanie dodatkowych detali wprost na tym diagramie doprowadzi do powstania monstrualnego arkusza, trudnego w użyciu.
Na modelach analitycznych posługujemy dwoma kluczowymi pojęciami (BPMN, Annex C Glossary1):
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.
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.
Atomowym zadaniem, stanowiącym abstrakcję całej aktywności biznesowej prowadzącej do osiągnięcia celu tej pracy, jest aktywność tworząca określony produkt, modelowany w BPMN jako DataObject (notacja BPMN jest oparta na założeniu, że wszelkie efekty pracy są dokumentowane). Innymi słowy nie umieszczamy na modelach procesów detalicznych składowych zadań stanowiących elementy procedury danej aktywności. Procedury modelujemy na osobnych diagramach lub po prostu opisujemy tekstem w odrębnej dokumentacji i powołujemy się na nie.
Co do zasady na modelach analitycznych stosujemy podstawowy, minimalny zestaw symboli opisany w specyfikacji, co gwarantuje ich czytelność i zrozumiałość przez typowego adresata jakim jest osoba, której pracę opisano. Korzystanie z rozszerzonego zestawu symboli (np. symbole detalicznych zadań z ikonami w lewym górnym roku, dodatkowe zdarzenia itp.) nie ma sensu na poziomie modeli analitycznych, gdyż symbole te powstały dla modeli wykonywalnych, przeciętny adresat dokumentacji analitycznej nie poradzi sobie z ich interpretacją. W efekcie po prostu utracimy komunikację w projekcie, co jest niestety bardzo częstym zjawiskiem i przyczyną większości problemów w projektach.
Podsumowanie
Na początkowym, biznesowym, etapie projektów analitycznych celem dokumentacji procesów biznesowych jest opisanie mechanizmu działania organizacji bez zbędnych detali (te zmieniają się dość często). Jeżeli dokumentacja procesów biznesowych wymaga aktualizacji częściej niż raz w roku (a lepiej raz na pięć lat) jest to sygnał, że jest to zła, zbyt szczegółowa dokumentacja.
Literatura naukowa jest pełna opracowań wskazujących, że procesy biznesowe i logika biznesowa to odrębne obszary opisu i modelowania. Notacja BPMN służy do modelowania procesów. Logikę biznesową opisujemy z użyciem reguł biznesowych3, tablic decyzyjnych (patrz artykuł SBVR…), tu jeden z wielu przykładów takich komentarzy:6.
Model procesów biznesowych jest często, w literaturze przedmiotu, nazywany modelem wewnętrznego łańcucha wartości, a nie raz po prostu wewnętrzną strategią realizacji celów rynkowych. Skoro jest to strategia, to nie powinna się ona często zmieniać. W powyższym modelu, uszczegółowienia może wymagań aktywność realizacji zamówienia, gdyż w zależności od podmiotu, może to być realizacja nietrywialnej usługi lub wytworzenia produktu. Była by to tak zwana dekompozycja i powstanie drugi poziom szczegółowości. Pozostałe aktywności to tworzenie określonych dokumentów, a sposób ich powstawania jest określony procedurą i tym jakie pola zawiera dana formatka DataObject. Ten poziom szczegółów opisujemy słownikiem i regułami biznesowymi (SBVR3).
Biorąc pod uwagę fakt, że serwery BPMS są bardzo rzadko wykorzystywane, diagramy BPMN na poziomie common executable praktycznie nie są tworzone. Jeżeli celem tworzenia modeli procesów biznesowych jest analiza przedwdrożeniowa, po modelu analitycznym powstaje umowa w postaci diagramu Przypadków Użycia. Przypadek użycia (patrz artykuł Transformacja…) to odpowiednik atomowej aktywności. Innymi słowy Przypadki Użycia (UML), jako usługi aplikacyjne, wspierają określone aktywności (a konkretnie powstawanie lub przetwarzanie konkretnych dokumentów modelowanych w BPMN jako obiekty DataObject), co opisano na pierwszym diagramie.
Faktura. Diagram procesu biznesowego pokazuje także, że faktura jako dokument, nie jest zobowiązaniem. Zobowiązaniem Dostawcy jest zawarta umowa na dostawę a zobowiązaniem Nabywcy jest płatność po otrzymaniu przedmiotu zamówienia. Zobowiązanie Nabywcy powstaje dopiero po (z reguły pisemnym) odebraniu przedmiotu zamówienia, faktura jest wyłącznie tak zwanym dowodem księgowym, czyli dokumentem stwierdzający jakie kwoty zaksięgować.
Ciekawa dyskusja na temat tego diagramu BPMN wywiązała się na LinkedIn:
https://www.linkedin.com/pulse/błędy-w-modelach-bpmn-piotr-biernacki/
Dzień dobry, pamiętam że opisywał Pan jak modelować procesy w przypadku których poszczególne aktywności nie mają określonej kolejności, mogą być wykonywane w dowolnym momencie. Szukam i nie mogę znaleźć, proszę o pokierowanie.
Specyfikacja BPMN Version 2.0.2. rysunki: 10.37 i 10.38
Mam też pytanie. W organizacjach są procesy typu: zarządzanie danymi. W tych procesach są aktywności tworzące konkretny produkt ale są też takie, które produktu nie tworzą (no chyba, że źle rozumuję) np. koordynacja procesu definiowania danych. Czy takie klocki (nietworzące produktu) są dozwolone?
Zacznijmy od tego, że zarządzanie danymi polega na tym, że ktoś je zbiera, ktoś gdzieś je wprowadza i potem ktoś z tego jakoś korzysta. I to jest proces biznesowy (być może jest to jedna aktywność ale jednak jest). Jeżeli «zarzadzanie danymi» oznacza trzymanie ich w jakiejś bazie danych, to znaczy, że najpierw trzeba zrozumieć po co one tam są, komu i do czego służą ;). Nie ma czegoś takiego jak aktywność nie tworząca produktu :). Czym jest np. ta «koordynacja»?
dziękuję 🙂
Zgadzam się ale wyobraźmy sobie, że jest zespół, który zarządza danymi w firmie. Z jednej strony odpowiedzialny jest za „wyprodukowanie” pewnych artefaktów jak n. polityka/zasady zarządzania danymi, czy opracowanie modeli danych i tu jak nazwać taką aktywność w procesie nie jest problemem, nie jest problemem też identyfikacja produktu/ów tej aktywności. Ale z drugiej strony ten zespół odpowiedzialny jest np. wspieranie innych pracowników w zadaniach związanych z danymi np. poprzez udzielanie informacji telefonicznych, pomoc przy tworzeniu zapytań sql. Wiadomo, że osoba pytająca pyta w jakimś celu. Odpowiedź uzyskania od nas pozwoli jej wykonać swoje zadania tj. pomaga jej w wytworzeniu jakiegoś produktu. Ale z punktu widzenia zespołu zarządzającego danymi (procesu) nie jest to istotne. Istotne jest to, że to jej ważne zadanie więc powinno się znaleźć na modelu procesu. No chyba, że produktem procesu może być w takiej sytuacji „data object” pod nazwą: informacja udzielona, czy np. proces definiowania danych skoordynowany. Czy to ma sens czy nie tędy droga?
Dokument „polityka/zasady zarządzania danymi,” powstaje w procesie zarządzania pewnym zakresem dokumentów, np. Dyr. sprzedaży zarządza cennikiem bo od czasu do czasu wykonuje proces „Aktualizacja cennika”. To są tak zwane procesy ad-hoc. Bywa nie raz, że to atomowe aktywności i ich produkt. Praca w call center ” udzielanie informacji telefonicznych” to siedzenie cały dzień (dyspozycyjność) i opracowanie raportu lub notatki z wykonanej pracy. To aktywność (napisanie raportu) ad-hoc albo w każdy piątek o 14tej :). Być może ten raport to log systemu.
?data object? pod nazwą: informacja udzielona, jeżeli to zapis mający ustaloną strukturę, to znaczy, że mamy proces:
– jeżeli ktoś zadzwoni to pogadaj
– po zakończeniu wypełnij formularz „notatka z rozmowy”