Od lat nie cichnie dyskusja na temat przepływu pracy i dokumentów oraz zarządzania procesami biznesowymi zachodzącymi w firmach. Nierzadko wiele pojęć z tego zakresu stosujemy błędnie, dlatego warto usystematyzować sobie wiedzę o nich, wskazać różnice między nimi i ostatecznie odpowiedzieć na pytanie, czy oprogramowania wspomagające ten obszar można z sukcesem wdrożyć we wszystkich przedsiębiorstwach. To kluczowe, jeśli chcemy skutecznie zarządzać procesami w firmie.
Dokumenty i procesy
Demagogią jest twierdzenie, że koszt przechowywania dokumentu elektronicznego to tylko kilka mikrometrów dysku i koszt tego miniobszaru. Prawdziwym kosztem przechowania takiego dokumentu jest bowiem koszt całej infrastruktury wraz z jej zabezpieczeniem. Gdyby było inaczej, każdy z nas miałby już w firmie elektroniczne superarchiwum.
Co więcej, obieg dokumentów to nie ? jak się mylnie sądzi ? zarządzanie procesami. Dokumenty są tylko jednym z elementów mapy procesów organizacji, a zatem systemy obiegu dokumentów to wsparcie zarządzania zorientowanego na procesy, nie zaś systemy zarządzania procesami biznesowymi.
Wielu utożsamia pojęcie obiegu dokumentów, obiegu informacji z procesami biznesowymi i ich zarządzaniem. Jest to moim zdaniem kluczowe nieporozumienie, żeby nie powiedzieć błąd.
Proces biznesowy to działanie charakteryzujące się przede wszystkim wnoszeniem wartości dodanej i posiadanie papieru czy dokumentu w wersji elektronicznej nie ma tu nic do rzeczy. Na mapie procesów biznesowych dokumenty i ich kolejne wersje stanowią produkty procesów (niejedyne zresztą). Proces polegający na podjęciu decyzji to praca człowieka niosąca dużą wartość dodaną, ale nie obieg dokumentów będących śladami po niektórych tylko procesach w firmie. Dla przykładu procesem jest wyprodukowanie podzespołu i nie ma to nic wspólnego z systemem obiegu dokumentów. Gdzieś po drodze powstanie dokumentacja techniczna, ale jeden z elementów systemu zarządzania procesami w firmie, jego podsystem.
Systemy obiegu dokumentów i obiegu informacji są ważnymi elementami w każdej organizacji, ale są to tylko produkty i to nie wszystkie na mapie procesów biznesowych firmy, dlatego właśnie nazywanie systemów, zaliczanych do klasy workflow, systemami BPM (Business Process Management) uważam za poważne nadużycie.
Kolejną ślepą uliczką jest traktowanie systemów klasy workflow jako narzędzi ścisłej kontroli poczynań pracowników. Nie znam przypadku wdrożenia systemu zakończonego sukcesem, którego głównym celem było kontrolowanie pracowników (np. czasu ich pracy). Znacznie skuteczniejsze są systemy informatyczne zaprojektowane tak, by pomagały pracownikom osiągać ich cele. Takie niejako wdrażają się same. Z kolei systemy kontroli i restrykcji, nawet jeżeli udaje się je wdrożyć, są bardzo kosztowne i często bojkotowane przez pracowników.
Jednak coś w tym jest, że obieg dokumentów (informacji) czasami staje się modelem procesów.
Kiedy i co modelować
Jeżeli czegoś nie można narysować, to znaczy, że to nie istnieje! To stwierdzenie odnosi się do istoty procesów i zarządzania nimi. Aby czymkolwiek zarządzać, należy to najpierw opisać, czyli udokumentować. Takim opisem będzie mapa procesów biznesowych, która stanowi model firmy z perspektywy jej funkcjonowania. Jak ją prawidłowo wykonać?
Model firmy powinien w sposób jasny i zrozumiały dla jej pracowników opisywać firmę, jej cel rynkowy oraz wszelkie jej aktywności wewnętrzne i zewnętrzne. Jest on niezbędny do przewidywania zachowań firmy, ale także do przygotowania jej na wdrożenia systemów informacyjnych.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
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):
Rys. Semantic areas of UML 2.5.1
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:
Rys. Struktura modeli zgodnie z MDA.
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:
Rys. Proces realizacji potrzeby w organizacji. Notacja BPMN.
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ć.
________________________________
1.
About the Business Process Model And Notation Specification Version 2.0.2. OMG.org. https://www.omg.org/spec/BPMN/. Published January 13, 2014. Accessed February 10, 2019.
About the Semantics Of Business Vocabulary and Rules Specification Version 1.4. OMG.org. https://www.omg.org/spec/SBVR/. Published May 1, 2017. Accessed February 11, 2019.
4.
About the Unified Modeling Language Specification Version 2.5.1. OMG.org. https://www.omg.org/spec/UML/. Published December 1, 2017. Accessed February 11, 2019.
Domain-Specific Conceptual Modeling Concepts, Methods and Tools, Herausgeber: Karagiannis, Dimitris, Mayr, Heinrich C., Mylopoulos, John (Eds.), ISBN 978 – 3‑319 – 39417‑6, str. 405.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Powodem napisania tego artykułu była publikacja:
„Wdrożenie zintegrowanych elektronicznych usług, informacyjnych na przykładzie poradników przedsiębiorcy, udostępnianych poprzez Punkt Kontaktowy w Polsce” (Elektroniczna gospodarka nr 4/2015, plik pdf).
Autorzy Mgr Szymon Mamrot, doktorant na Wydziale Informatyki i Gospodarki Elektronicznej Uniwersytetu Ekonomicznego w Poznaniu, główny specjalista w Centrum Elektronicznej Gospodarki Instytutu Logistyki i Magazynowania (e‑mail: szymon.mamrot@ilim.poznan.pl). Mgr Magdalena Stachowicz, absolwentka studiów doktoranckich na Wydziale Politologii Uniwersytetu Marii Curie-Skłodowskiej w Lublinie, starszy specjalista w Centrum Elektronicznej Gospodarki Instytutu Logistyki i Magazynowania (e‑mail: magdalena.stachowicz@ilim.poznan.pl). Artykuł był recenzowany.
Autorzy cytują między innymi mój artykuł, a konkretnie definicję procesu biznesowego, piszą także o modelowaniu procesów i o notacji BPMN. Autorzy piszą:
W artykule autorzy podjęli próbę zgłębienia problemu badawczego, jakim jest zastosowanie notacji Business Process Modeling Notation ( BPMN) do tworzenia z integrowanych elektronicznych usług informacyjnych. Posługując się przykładem poradników przedsiębiorcy, udostępnianych na portalu Punktu Kontaktowego (PK), udowodnili, że notacja BPMN pozwala budować skomplikowane modele procesów, uwzględniających wiele powiązanych ze sobą zadań i informacji. Tworzenie zintegrowanych elektronicznych usług informacyjnych, ciekawych w formie i obszernych w pomocne treści merytoryczne, jest przyszłością współczesnej e‑administracji, nie tylko w Polsce, ale i w Europie.
Jednak w treści, jest nieprawdziwa teza:
Nie ma w tym przypadku ograniczenia, że proces musi coś wytwarzać.
Wyjaśnijmy sobie dlaczego nieprawdziwa.
Streszczenie
Jako, że zostałem zacytowany przez ww. autorów, artykuł ten stanowi moją odpowiedź do tej publikacji. Autorzy podważyli definicję, mówiącą, że proces biznesowy tworzy produkt. Skupiłem się tu na formalnym wywodzie prowadzącym do definicji pojęć: proces, proces biznesowy i procedura, na tle notacji BPMN, na którą autorzy się powołują. Wykazałem, że pojęcie produktu procesu jest fundamentem definicji pojęcia proces biznesowy nie tylko w notacji BPMN. Wskazałem także błędne użycie przez autorów powiązanego z pojęciem proces pojęcia bramki (ang. gateway).
Procedura, proces i proces biznesowy
Autorzy piszą:
Według definicji językowej, zawartej w Słowniku Języka Polskiego PWN, procedura to: 1. określone reguły postępowania w jakiejś sprawie, zwykle o charakterze urzędowym lub prawnym; 2. w językach programowania: wydzielony fragment algorytmu.
W artykule autorzy posługują się pierwszym znaczeniem użytym w Słowniku (procedura jako określone reguły postępowania), przy czym istotna jest lista czynności i sama kolejność ich wykonania.
Przyjmowanie najogólniejszych definicji jest ryzykowne, tym bardziej, że celem publikacji było
…przedstawienie nowej metody tworzenia zintegrowanych elektronicznych usług informacyjnych, przy zastosowaniu notacji BPMN.
Zastosowanie sformalizowanej notacji, jaką jest BPMN, i jednoczesne ujmowanie pojęcia procesu najogólniej jak się da i w oderwaniu od tej notacji, jest ryzykowne. Już tu: „procedura jako określone reguły postępowania, przy czym istotna jest lista czynności i sama kolejność ich wykonania” widać, że ogólna definicja została uzupełniona o istotność listy czynności i ich kolejności, czym autorzy zbliżyli się jednak do pojęcia „algorytmu”. W dalszej części piszą:
Według normy ISO 9000, proces to: każde działanie, które przekształca wejście (dane wejściowe) na wyjście (dane wyjściowe). Proces może w swoim ?wnętrzu? zawierać zbiór różnych operacji (działań) wzajemnie ze sobą powiązanych i na siebie oddziałujących. Jarosław Żeliński w swojej pracy, jako analityk biznesowy i systemowy, stosuje następującą definicję procesu: proces to przekształcenie wejścia procesu w jego wyjście, z użyciem określonych zasobów i w obecności określonych ograniczeń.
Autorzy niestety wyjęli to zdanie z kontekstu, cały mój zapis brzmiał:
Polecam ciekawy artykuł na temat definicji procesów, w szczególności Procesu Biznesowego. Zestawiono ze sobą rożne definicje na przestrzeni ostatnich niemal 20 lat. Najbardziej podoba mi się prostota: ?a business process is a series of steps designed to produce a product or service? (Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">proces biznesowy to Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">sekwencja działań zaprojektowanych w celu wytworzenia produktu lub Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">usługi).
Jeśli uznamy, że Szczegóły:
" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">produkt i usługa to „coś co ma wartość dla klienta”, to powstaje prosta i prawdziwa moim zdaniem definicja opisująca „sedno sprawy”. Ogólnie wymowa artykułu potwierdza moją tezę o abstrakcyjności „procesu”, namacalne są za to pozostałe jego elementy: wejście i wyjście (produkty), zasoby (ludzie i maszyny) oraz Szczegóły:
The term ?process? is used in a wide variety of ways. The first definition offered by MerriamWebster Online is (1) a natural phenomenon marked by gradual changes that lead toward a particular result (e.g. the process of growth). In order to avoid confusing our use of the term ?process? with any other possible usage, we will consistently use the term Business Process.
Tak więc generalnie chodzi o rozróżnienie pojęć: proces i proces biznesowy. Na moim blogu prowadzę także słownik, jego celem jest zapewnienie jednoznaczności artykułów, które publikuję. Publikowane tam definicje opierają się na dostępnych źródłach, spełniają też podstawową zasadę budowy słownika (namespace): definicje pojęć dziedzinowych muszą się wzajemnie wykluczać i obejmować sobą wszystkie desygnaty z opisywanej dziedziny: każdy nazwany byt dziedziny (desygnat) spełnia tylko jedną definicję, poprawnie opisana dziedzina problemu nie ma bytów niezdefiniowanych czyli nienazwanych (co oznacza, że poprawny słownik zawiera pojęcia pozwalające jednoznacznie nazwać wszystko w danej dziedzinie), pojęcie specjalizujące są typami swoich uogólnień i łącznie stanowią także poprawny słownik (na podstawie OMG specyfikacja notacji SBVR3).
Autorzy piszą, że z definicjami jak wyżej, nie zgadza się Object Management Group (OMG.org), stwierdzenie to co mnie zaskoczyło.
Jednak z powyżej przytoczonymi definicjami nie zgadza się organizacja Object Management Group (OMG), która w opracowanej przez siebie definicji podkreśla, że proces biznesowy nie zawsze musi być uporządkowany; co więcej – nie zawsze jego wynikiem jest wytworzenie jakiegoś dobra (towaru, usługi, itp.).
Troszkę teorii
Powołując się na specyfikację notacji BPMN czytamy:
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.
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.
(ang. Proces biznesowy: zdefiniowany zestaw działań biznesowych, które reprezentują kroki wymagane do osiągnięcia celu biznesowego. Obejmuje przepływ i wykorzystanie informacji i zasobów.
Proces: sekwencja lub przepływ działań w organizacji w tworząca efekt pracy. W BPMN proces jest przedstawiony jako graf obrazujący przepływ elementów, które są zbiorem działań, zdarzeń, bramek i przepływu, które są zgodne z określoną semantyką ich realizacji).
Autorzy wyciągają wniosek:
Nie ma w tym przypadku ograniczenia, że proces musi coś wytwarzać, gdyż ? jak zauważono ? we wszystkich organizacjach realizuje się szereg prac, które nie zawsze przynoszą jakiekolwiek efekty (niektóre zadania są realizowane, mimo, iż nie mają biznesowego uzasadnienia). Według OMG, proces biznesowy to sekwencja lub przepływ czynności w jakiejś organizacji, których celem jest wykonanie jakiejś pracy. Zatem procesem jest nie tylko sekwencja czynności, ale także sam przepływ czynności.
Prawdą jest więc, że proces biznesowy wg. OMG to praca jako określony łańcuch czynności, ale nie zrozumiałe jest dla mnie ostatnie zdanie: procesem jest nie tylko sekwencja czynności, ale także sam przepływ czynności. OMG w specyfikacji BPMN (patrz wyżej) jasno definiuje pojęcie procesu (sekwencja elementów, które są zbiorem działań, zdarzeń, bramek i przepływu, ten ostatni jest równoprawnym elementem a nie jakimś innym, osobnym czymś).
Zajrzyjmy do specyfikacji notacji BPMN: Powyższy diagram, to tak zwany diagram profilu (UML), profil to graficzna forma słownika pojęć i ich syntaktyki5. Profil (diagram profilu) to diagram klas w notacji UML (patrz specyfikacja OMG: MOF), zawierający związki strukturalne (kompozycja) oraz pojęciowe (asocjacja i generalizacja). Powyższe czytamy:
elementy przepływu w procesie to: Obiekt Danych, Węzeł Przepływu, przepływ (może zawierać warunek przepływu), Odnośnik Do Składu danych, przepływ to element stanowiący wymagany łącznik pomiędzy węzłami,
typy węzłów przepływu: Aktywność, Zdarzenie, Bramka, Aktywność choreografii.
Na tle powyższego, teza autorów publikacji:
Nie ma w tym przypadku ograniczenia, że proces musi coś wytwarzać. […] Zatem procesem jest nie tylko sekwencja czynności, ale także sam przepływ czynności.
jest nieprawdziwa. Proces to określona sekwencja ale proces biznesowy z zasady coś tworzy, jest to skutek (efekt, produkt) wykonania tej sekwencji czynności. Stanowi więc zmianę określonego stanu rzeczy (proces, jako coś co zaszło, z zasady zmienia środowisko w jakim zachodził). Teza, mówiąca że coś zaszło bez skutków jest nielogiczna. Definicja procesu biznesowego w BPMN (dodatek) zawiera w sobie produkt tego procesu.
elementarny proces biznesowy to określone zadanie wraz z jego produktem, mogą one tworzyć łańcuchy procesów pokazane jako ich mapy (modele)
(więcej o notacji BPMN w artykule Notacja BPMN ? Jak czytać diagramy)
1. ?zasada postępowania ustalona przez kogoś lub przyjęta na mocy zwyczaju?
Zgodnie z zasadą logiki zdań (i cech poprawnego słownika), mówiącą że zastąpienie pojęcia w zdaniu jego definicją nie może zmienić sensu całego zdania otrzymamy:
Procedura: określone zasady postępowania, ustalone przez kogoś, w jakiejś sprawie, zwykle o charakterze urzędowym lub prawnym
Zaglądamy ponownie do słownika:
zasada
1. ?prawo rządzące jakimiś procesami, zjawiskami; też: formuła wyjaśniająca to prawo?
Otrzymamy:
Procedura: określone prawa rządzące postępowaniem, ustalone przez kogoś, w jakiejś sprawie, zwykle o charakterze urzędowym lub prawnym
Innymi słowy procedura to zbiór praw (zasad) a nie przepływ zdarzeń (ale ich kolejność może wynikać z tych praw lub może być tym prawem). Potocznie pojęcie procedury faktycznie jest używane do nazwania dowolnego opisanego (procedurą) sposobu postępowania (także w normach jakości ISO) jednak pojawienie się pojęcia proces biznesowy wymaga już doprowadzenia tych definicji do postaci, w której definicje te spełniają wymagania wobec słownika: definicje muszą się wykluczać i jednocześnie pokrywać sobą wszystkie desygnaty danej dziedziny (patrz trójkąt semantyczny notacja SBVR ).
Jednym z elementów procesu w BPMN jest tak zwana aktywność4.
Activity: Work that a company or organization performs using business processes. An activity can be atomic or non-atomic (compound). The types of activities that are a part of a Process Model are: Process, Sub-Process, and Task.
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.
(ang. Aktywność: praca wykonywana przez firmę lub organizację w toku (przy użyciu) procesów biznesowych. Aktywność może być atomowa lub nieatomowa (złożona). Rodzaje aktywności wchodzących w skład Modelu Procesu to: Proces, Podproces i Zadanie.
Aktywność atomowa: aktywność nie dzielona na mniejsze części jako kolejne poziomy szczegółów modelu procesu. Jest to liść w hierarchii drzewiastej w procesach. Graficznie pojawi się jako zadanie w BPMN.)
Nie tylko w języku polskim, aktywnością nazywamy każde podejmowane działanie (czyjeś postępowanie). Tak więc w BPMN mamy:
Każda sekwencja określonych aktywności to proces, taka która ma określone konsekwencje: tworzy produkt (w BPMN zdarzenie lub obiekt danych), to proces biznesowy (notacja BPMN nie zawiera symbolu: proces biznesowy!).
Najniżej w hierarchii procesów i składających się na nie aktywności jest zadanie (atomowa aktywność).
Aktywności w BPMN opisuje poniższy profil:
Czytamy diagram tak (związki słownikowe generalizacji):
Aktywność jest typem węzła, czyli elementem przepływu (patrz poprzedni profil),
Aktywność to pojęcie abstrakcyjne, typami aktywności są zadania, odwołania do zadań oraz pod-procesy.
Warto tu zwrócić, uwagę na to, że pod-proces to tak zwany kontener. Kontener to zasobnik na elementy, formalnie w BPMN takim zasobnikiem jest diagram. Innymi słowy: jeżeli na diagramie pojawi się element pod-proces, to musi z nim być skojarzony określony diagram BPMN stanowiący jego dekompozycję. Innymi słowy jeżeli aktywność jest zadaniem (atomowa aktywność) nie ma ona już dalszych pod-procesów. Aktywność będąca pod-procesem musi być opisana z pomocą kolejnego diagramu BPMN. Najniżej w hierarchii aktywności BPMN są zadania (task). Zgodnie z przytoczonym definicjami, zadanie i jego produkt to «atomowy proces biznesowy» (w literaturze można także spotkać alternatywne pojęcie: proces elementarny).
Co z procedurą?
W BPMN to pojęcie formalnie nie występuje, pojawia się jednak w większości narzędzi do modelowania i symulowania procesów. Tam procedura jest definiowana jako sposób postępowania w ramach aktywności. Ma to głęboki sens, bo uznanie, że procedura jest na szczycie hierarchii procesów prowadziło by do sytuacji, w której wszystko jest procedurą, co przeczy zasadzie wyłączności w budowaniu słowników (proces nie może być typem lub częścią procedury). W ramach norm ISO jest wymóg by procedury tworzyły sobą spójne procesy biznesowe. Innymi słowy,
procedura to specyfikacja realizacji (postępowania w ramach) określonej aktywności
Proces biznesowy jako abstrakcja
Proces biznesowy to aktywność jako abstrakcja określonej pracy oraz powiązane z nią jej wejście i wyjście . Proces jest sterowany (ma ograniczenia), wymaga zasobów. Graficzna postać tej definicji:
Powyższe można przedstawić tak:
(źr.: Jarosław Żeliński, materiały konferencyjne) Proces biznesowy jako aktywności i jej otoczenie.
Z powyższego wynika, że
pojęcie „proces biznesowy” to abstrakcja łącząca w sobie: aktywność, jej wejście i wyjście, ograniczenia i reguły, oraz niezbędne zasoby
To dlatego organizacje mają udokumentowane: wzory dokumentów, zarządzenia, procedury, zakresy obowiązków, instrukcje stanowiskowe i instrukcje użytkownika wykorzystywanego wyposażenia, nad tym wszystkim jest obowiązujące prawo. Rzadko kiedy mają jednak mapy i modele procesów pokazujące to w jakiej kolejności i dlaczego to wszystko sie odbywa.
Z perspektywy metod analizy MBSE: spojrzenia przez pryzmat technologii i ludzi wygląda to tak:
Podsumowując: proces jako element modelu to abstrakcja pracy: aktywność wraz z określeniem „co powstaje” (produkt). Sposób wykonania tej pracy: metoda, to narzucona określona procedura. Procedura może wskazywać na potrzebę użycia określonych narzędzi. Całość realizowana jest w określonym środowisku: organizacja i narzędzia, w tym oprogramowanie (np. ERP).
Kluczowe pojęcia w modelowaniu
W notacji BPMN elementarny proces biznesowy to niepodzielna Aktywność (Zadanie) i jej Wejście i Produkt (w BPMN są elementy typu DataObject). W przypadku modelowania wewnętrznego zachowania się systemu (logika biznesowa realizowana przez oprogramowanie) z użyciem notacji UML, mamy odpowiednio aktywność oraz jej procedurę jako ciąg zadań (linii kodu).
Poniżej model pojęciowy dla opisywanego powyżej zbioru pojęć.
Model pojęciowy (diagram faktów, notacja SBVR, opracowanie własne)
Model powyższy pokazuje, że umieszczenie pojęcia procedura gdziekolwiek wyżej w hierarchii pojęć BPMN jest praktycznie niemożliwe przy zachowaniu zasady logiki zwanej zasadą wyłączonego środka: procedura nie jest procesem a proces nie jest procedurą. Tak więc procesy biznesowe, jako łańcuchy zadań i ich produktów, możemy dekomponować aż do poziomu procesów atomowych, a procedura to sposób postępowania w realizowaniu zadania (atomowej aktywności w procesie). Umieszczenie pojęcia procedura w innym miejscu dopuszczało by prawdziwość stwierdzenia: procedura składa się procesów, co niestety przeczy logice.
Na zakończenie ważna uwaga na temat modeli procesów z użyciem BPMN. Jednym z elementów przepływu są tak zwana bramki (ang. gateway). Dość częstym błędem jest przyporządkowywanie bramkom jakiejkolwiek pracy. Specyfikacja BPMN mówi:
8.4.9 Gateways Gateways are used to control how the Process flows (how Tokens flow) through Sequence Flows as they converge and diverge within a Process. If the flow does not need to be controlled, then a Gateway is not needed. The term ?gateway? implies that there is a gating mechanism that either allows or disallows passage through the Gateway; that is, as tokens arrive at a Gateway, they can be merged together on input and/or split apart on output as the Gateway mechanisms are invoked.
Gateways, like Activities, are capable of consuming or generating additional control tokens, effectively controlling the execution semantics of a given Process. The main difference is that Gateways do not represent ?work? being done and they are considered to have zero effect on the operational measures of the Process being executed (cost, time, etc.).
Ostatnie, wytłuszczone zdaniem mówi:
Główną różnicą jest to, że bramki nie reprezentują „pracy”, mają więc zerowy wpływ na miary operacyjne wykonywanego procesu (koszt, czas itp.).
Innymi słowy jakakolwiek praca, np. z analizą danych i podejmowaniem decyzji, jest realizowana w aktywnościach poprzedzających bramkę, ta (bramka) stanowi sobą wyłącznie mechanizm przepuszczania lub blokowania (tokena), oparty na treści (typowa bramka to bramka danych, np. jakiś atrybut tokenu zawiera określoną treść i ta jest wymagana, to bramka przepuści taki token). Innymi słowy bramka danych jest manifestacją decyzji jaka została podjęta w aktywności poprzedzającej ją.
To oznacza, że autorzy niepoprawnie używają bramek XOR (cytowana praca, Rys.3.), pisząc, że reprezentuje ona pracę czyli zadanie pytania (dialog) i oczekiwanie odpowiedzi. Poprawne podejście w BPMN: pewna określona aktywność zbiera dane (ankieta) i dane te (produkt aktywności ankietowania), w postaci elementu DataObject (lub jako token) trafiają na bramkę XOR, a ta np. przepuszcza dalej wyłącznie token reprezentujący ankietę zawierająca odpowiedź TAK na określone pytanie.
Podsumowanie
[2021 – 06-22] Po wielu pytaniach i dyskusjach, uzupełniłem artykuł:
Generalizując, powyższe można zebrać w postaci struktury pokazanej poniżej:
Struktura modeli procesów biznesowych
Na powyższym diagramie pokazano:
W centralnej części pokazano elementarny (atomowy) proces biznesowy (może on być częścią większej całości).
Nad nim pokazano model (mapę) procesów biznesowych (może to być nadrzędny proces) pokazujących jak procesy biznesowe po sobie następują.
Pod nim procedura i różne formy ich dokumentowania (tekst, tabela, schemat blokowy, może zawierać reguły biznesowe, macierze RACI itp.).
Po prawej stronie struktura dokumentu (artefakt), jest on nośnikiem danych, jest przywoływany na każdym poziomie modelowania (na modelach procesów BPMN jest to karteczka z zagiętym rogiem, w procedurach powołujemy się na nazwy dokumentów) .
Warto tu zwrócić uwagę na fakt, że modelowanie procesów biznesowych na podstawie wywiadów i ankiet (pozyskiwanie informacji o wykonywanych czynnościach) wprowadza ogromną zależność uzyskanych wyników od subiektywnego postrzegania organizacji przez zatrudnionych w niej (i ankietowanych) pracowników. Powoli, od ponad dekady, przebijają się do świadomości firm analitycznych, metody oparte na faktach, a są nimi tak zwane «artefakty» czyli namacalne ślady po wykonanej pracy. W warunkach biznesowych są do dokumenty operacyjne i ich treść.
„Każda firma, niezależnie od tego, jakie fizyczne towary lub usługi wytwarza, opiera się na dokumentacji handlowej. Musi ona zapisywać szczegóły tego, co wytwarza w postaci konkretnych informacji. Artefakty biznesowe są mechanizmem zapisu tych informacji w jednostkach, które są konkretne, identyfikowalne, samoopisujące się i niepodzielne.”
„W ciągu ostatnich kilku lat, coraz większe wymagania stawiane są efektywnym podejściom do projektowania, modelowania i wdrażania międzyorganizacyjnych procesów biznesowych. W procesie współpracy ponad granicami organizacyjnymi, organizacje nadal pozostają autonomiczne, co oznacza, że każda z nich może dowolnie modyfikować swoje wewnętrzne operacje, aby osiągnąć swoje prywatne cele, jednocześnie spełniając wzajemne cele swoich partnerów. Ostatnio udowodniono, że modelowanie procesów skoncentrowane na artefaktach zapewnia większą elastyczność w modelowaniu i realizacji procesów niż tradycyjne metody modelowania skoncentrowane na działaniach.”
Dlatego modelowanie organizacji bazujące na definicji procesu postrzeganego jako działania tworzące produkt (artefakt), wydaje się być obecnie najlepszą praktyką analizy biznesowej.
Estefan, J. A. (2008). INCOSE MBSE Initiative Survey of Model-Based Systems Engineering (MBSE) Methodologies.
Gerede, C. E., Bhattacharya, K., & Su, J. (2007). Static analysis of business artifact-centric operational models. IEEE International Conference on Service-Oriented Computing and Applications (SOCA’07), 133 – 140.
Walden, D. D., Roedler, G. J., & Forsberg, K. (2015). INCOSE Systems Engineering Handbook Version 4: Updating the Reference for Practitioners. INCOSE International Symposium, 25(1), 678 – 686. https://doi.org/10.1002/j.2334 – 5837.2015.00089.x
Yongchareon, S., liu, C., Yu, J., & Zhao, X. (2015). A view framework for modeling and change validation of artifact-centric inter-organizational business processes. Information Systems, 47, 51 – 81. https://doi.org/10.1016/j.is.2014.07.004
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Jednym z zabójców projektów związanych z modelowaniem procesów biznesowych, jest ich nadmierna szczegółowość. Ktoś może powiedzieć, że „o te szczegóły właśnie chodzi”. Jeżeli tak mówi, to nie rozumie czym jest model procesów biznesowych, bo taki model to nie miejsce na takie szczegóły w analizie. Jeżeli jednak przeforsowana zostanie w projekcie teza mówiąca, że „modele procesów mają zawierać wszystkie szczegóły”, otrzymujemy sterty nieczytelnych diagramów, nie poddających się jakiejkolwiek dalszej obróbce.
W artykule Poziomy modelowania… opisałem hierarchię szczegółowości modeli procesów. Tu skupiłem się na walce z nadmiarem szczegółów na nich.
Diabeł tkwi w szczegółach
To częsty argument za tym, by te szczegóły umieszczać na diagramach. Czym są te szczegóły?
Pojęcie procedury. W popularnym polskim WIKI nie ma niestety rozwiniętej definicji pojęcia procedura (stan na 24.09.2013):
Pozostaje mi więc przyjąć nieco ściślejszą niż powyższa, definicję ze sł. j. polskiego PWN jako bazę do dalszych dywagacji (ważna uwaga: słownik pojęć w dokumentacji projektowej pisanej po polsku, nie może być niezgodny ze słownikiem języka polskiego, może być co najwyżej uszczegółowieniem):
Procedura: 1. określone reguły postępowania w jakiejś sprawie, zwykle o charakterze urzędowym lub prawnym, 2. w językach programowania: wydzielony fragment algorytmu.
Ważne jest tu to, że procedura to generalnie określone reguły postępowania (przypominam, że regułą postępowania jest także lista czynności i sama kolejność ich wykonania). Wskazówką by tę definicję doprecyzować jest także nawiązanie (2. znaczenie) to programowania: wydzielony fragment algorytmu. Powyższe pozwala uznać, że konkretna procedura to postępowanie w jednej sprawie (jednym celu). Czy postępowanie w sprawie (albo wydzielony fragment algorytmu) da oczekiwany rezultat jeżeli je przerwiemy? Nie. Tak więc definicja procedury, która się tu sama wręcz narzuca (i taką przyjmuję w projektach) brzmi:
procedura – ciąg czynności (kroków postępowania), którego przerwanie prowadzi do utraty celowości wykonywania tych czynności
Popatrzmy też jak procedurę definiuję norma technologiczna ISO9000:
procedura: określony sposób realizacji działań lub procesów
Definicja ta nie koliduje z moją, ma jednak pewną wadę: nie precyzuje poziomu abstrakcji (lub szczegółowości). Innymi słowy, czy obsługa zamówienia opisana jako „zarejestrowanie dokumentu zamówienia, wystawienie listu przewozowego wg. wzoru i zgodnie z treścią zamówienia oraz wystawienie faktury sprzedaży” to procedura czy sekwencja procesów mających dopiero swoje procedury (np. jak przebiega rejestracja Zamówienia)? Moja definicja jawnie wskazuje, że procedura opisuje najniższy poziom szczegółowości: atomowych procesów biznesowych. tak więc mamy to łańcuch procesów i wymagany brakujący opis procedury „rejestracji Zamówienia”.
Model procesów biznesowych
Czy przypadkiem nie dzielę włosa na czworo? Moim zdaniem nie. Dzięki powyższemu możliwe jest zapanowanie nad szczegółowością projektu analizy procesów biznesowych. Mając definicję pojęć proces biznesowy, podproces (dekompozycja procesu) oraz procedura mam doskonałe narzędzie do kwalifikowania elementów wiedzy o tym „co się dzieje” jako procesy, pod-procesy czy własnie procedury.
Zwróćmy uwagę, proces biznesowy najwyższego poziomu to tak zwany proces end-to-end. Jego dekompozycja (kolejne dekompozycje) doprowadzą nas do elementarnych (atomowych) procesów biznesowych. Atomowy proces biznesowy jest dokumentowany (to jak przebiega) jako procedura. Procedury, z reguły, nie są już diagramami a wypunktowanymi listami, „receptami” działania. Wszystkie szczegóły wykonywanych czynności są zawarte, nie na diagramie procesu, a właśnie w treści procedury (tu polecam artykuł: Co to jest proces biznesowy).
Mając więc powyższą definicję procedury, łatwiej nam teraz jest zakwalifikować informację to tym, że należy zeskanować przychodzący dokument, jako element (krok) procedury a nie jako proces biznesowy. Samo skanowanie, bez następujących po nim dalszych kroków postępowania z dokumentem, do niczego nie służy, więc nie może być (w myśl powyższych definicji) procesem biznesowym. Jest zapisem w treści procedury opisującej sposób realizacji procesu przyjęcia dokumentu.
Bez tej formalizacji (ścisłe stosowanie zdefiniowanych pojęć, także tych z użytej notacji) próby modelowania procesów prowadzą najczęściej do powstawania monstrualnych ilości nieczytelnych diagramów (widywałem dokumentacje, gdzie było dla jednej firmy powstałe blisko tysiąc stron! Masakra). To kompletnie nieprzydatne dokumenty.
Co jeszcze nam daje stosowanie powyższych definicji? Możliwość jednoznacznego „przejścia” (śladowanie) z modeli procesów biznesowych na modele przypadków użycia bo atomowy proces, zakwalifikowany do zakresu projektu jako wymagana usługa oprogramowania, to przypadek użycia nowego oprogramowania, zaś procedura tego procesu to nic innego jak scenariusz tego przypadku użycia lub jak ktoś woli: user story. Z innej strony: jeżeli mamy wdrożoną procesową normę np. ISO9000, to modelując procesy biznesowe i „podpinając” do nich procedury z księgi jakości, szybko się przekonamy, czy nasze ISO to nie jest przypadkiem fikcją.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Ostatnio tematów, jakie chciałbym poruszyć, pojawia się więcej niż jestem w stanie przetworzyć :). Dziś o „mierniku” skuteczności działania wymiaru sprawiedliwości czyli analiza funkcjonowania systemu stanowienia prawa.
Co jakiś czas słyszymy (albo w projektach spotykam się) z ocenami instytucji naszego wymiaru sprawiedliwości. Są to np. liczba nałożonych mandatów, czas trwania sprawy w sądzie, wartość nałożonych kar i itp. Moim zdaniem wszystkie one prowadzą do patologii np. takich jak poniższa:
Gazeta Pomorska ujawniła nagranie, na którym słychać mężczyznę wulgarnie zwracającego się do innej osoby, a może grupy osób. Mężczyzna mówi, że przyjmuje minimalny próg mandatów – 17 na głowę. Według Gazety Pomorskiej jest to głos naczelnika toruńskiej drogówki Wiesława Rospirskiego. […] Opisane zdarzenie jest przede wszystkim problemem Policji, ale można spojrzeć na nie od strony społeczeństwa informacyjnego. Czy przejrzystość działań funkcjonariuszy z drogówki nie mogłaby być większa? Byłoby ciekawie, gdyby na stronach Policji na bieżąco informowano np. o liczbie udzielanych mandatów, funkcjonariuszach wystawiających najwięcej mandatów, wykroczeniach za które wystawiane są mandaty itd. (Ma być k… 17 mandatów! Wyciek tego nagrania okazją do pytań o przejrzystość Policji – Internauci).
Każdy kto zajmuje się zarządzaniem wie, że ludzie robią to, z czego się ich rozlicza (za się ich ocenia). Skoro więc kogoś rozlicza się z liczby nałożonych mandatów to znaczy, że motywuje się go do nakładania mandatów, gorzej – w przypadku „pracy na wskaźnik” może dojść do kreowania przypadków wymagających nałożenia mandatu (i chyba nic nowego nie napisałem). Analogicznie w przypadku wszelkich innych kar administracyjnych.
Popatrzmy na poniższy diagram, przedstawia ogólny system stanowienia i przestrzegania prawa.
Są to: proces główny i jego kluczowe składowe procesy:
Stanowienie prawa (tworzenie aktów prawnych).
Prewencja czyli zapobieganie łamaniu prawa.
Karanie czyli nakładanie odpowiednich sankcji na łamiących prawo (za pośrednictwem sądu lub decyzji).
Generalnie prawo stanowione powstaje w odpowiedzi na stwierdzone przypadki zachowań niepożądanych społecznie. Drugim powodem tworzenia zapisów prawa, jest osiągnięcie zaplanowanego, pożytecznego społecznie, efektu, np. podatki są narzuconym odgórnie wymogiem partycypacji w kosztach utrzymania administracji Państwa, wojska itp. Prawo mówi czego nie wolno i co grozi za jego nieprzestrzeganie (jeżeli prawo coś nakazuje to znaczy tyle, że nie wolno tego nierobić).
Nie wgłębiając się w zawiłości metod tworzenia prawa, uznajemy, że celem jego istnienia jest eliminacja zjawisk, zachowań, społecznie niepożądanych lub wymaganych.
Tak więc mamy opisany powyżej proces stanowienia prawa oraz, będące jego konsekwencją procesy składowe: prewencji i karania.
Prewencja to stwarzania warunków nakłaniających do przestrzegania prawa. Z prewencją mamy do czynienia często, nie tylko w przypadku np. marszu ochranianego przez policję (w celu zapobieżenia faktom łamania prawa) ale także są nią garby na drodze ograniczające prędkość np. przy szkołach.
System stanowienia prawa powinien być nadzorowany, co do tego nikt chyba nie ma wątpliwości. Jak go kontrolować i oceniać? Uznano, że należy stworzyć i na bieżąco śledzić wartość określonych wskaźników (mechanizmem takim jest także ustawa o dostępie do informacji publicznej ale to inny wątek).
W sferze zarządzania mówi się o tak zwanych KPI (ang. [[Key Performance Indicator]] czyli kluczowe wskaźniki efektywności). Ich tworzenie jest jedną z najtrudniejszych elementów zarządzania. Już w latach 50-tych ubiegłego wieku uznano, że idealnym przedmiotem mierzenia są procesy biznesowe. Trudnością jest ich identyfikacja oraz ustalanie właściwych wskaźników. Jaki wskaźnik jest właściwy? Taki, który poprawnie zamyka pętle sprzężenia zwrotnego podnoszącego jakość procesu. Innymi słowy wskaźnik powinien być tak zbudowany by wykonawca procesu (właściciel procesu) widział pozytywny związek pomiędzy wartością wskaźnika a jakością produktu jaki tworzy jego proces.
Każdy proces to swego rodzaju system, złożony z elementów go tworzących (ludzie, maszyny, bodźce, reguły biznesowe itp.). Mamy na naszym modelu zobrazowany System Stanowienia Prawa, miarą jego efektywności jest to w jakim stopniu osiągnięto ideał, czyli brak zjawisk społecznie niepożądanych. Elementami tego systemu są społeczność dla której to prawo powstaje ( która je tworzy), twórcy prawa oraz wyłonione przez społeczność służby strzegące jego przestrzegania (diagram zawiera jedynie same omawiane procesy).
W kontekście policji i cytatu z prasy: istotne jest to, że jeden proces to reakcja na pojedynczy przypadek złamania ustanowionej normy czego konsekwencją (produktem procesu) jest decyzja (tu mandat). Ocenie może podlegać produkt procesu a nie liczba jego wystąpień! Miernikiem jakości pracy policjanta jest więc jakość jego decyzji a nie ich ilość! Jak tę jakość mierzyć? Np. liczbą skutecznych odwołań od jego decyzji. A kogo ocenia liczba mandatów? Jeżeli policjant pracuje uczciwie to raczej stanowiących prawo lub społeczność łamiącą zasady. A co zrobić by policjant pracował uczciwie? Kontrolować go. Jak? Zawsze można złożyć skargę na policjanta, także na jego bezczynność (podobnie jak na każdy inny organ).
Nie mam pojęcia czym kierował się ten kto wymyślił ocenę pracy policjantów poprzez licznie ilości wystawionych przez nich mandatów (albo gorzej – ich wartość!). Wytłumaczeniem może być chęć pozyskania zwiększonych środków z mandatów, ale to nic innego jak działania na szkodę społeczności, którą się reprezentuje!
To tylko namiastka opisu problemu jaki obserwuję. Czy mam rację? Patologia już jest i jej przewidzenie nie jest wielkim wyczynem. Moim zdaniem powyższe tłumaczy ją w dużym stopniu. Podobną patologią było bogato relacjonowane w prasie kreowanie przestępstw przez „służby” za czasów „agenta Tomka”.
Zastanawia mnie kto siedzi za tymi pomysłami. Podobno każdy kraj, a konkretnie jego rząd, ma tak zwane „think tanki”:
Think tank (ang., dosłownie: zbiornik myśli) ? komitet doradczy, z założenia niezależny, niedziałający dla zysku ośrodek zajmujący się badaniami i analizami dotyczącymi spraw publicznych. (Wikipedia, wolna encyklopedia).
Zakładam, że nasz też ma i albo są tam niekompetentni ludzi, albo ich nikt nie słucha, albo jednak nie mamy think tanków. Bo takie miary jak liczba mandatów jako miernik pracy policji czy też liczba wyroków skazujących w sądach, czas trwania procesu itp. to karygodne praktyki prowadzące do patologii.
Co powinno być dobrym miernikiem? W skali całego systemu np. poziom przestępczości. Jednak 0% jest nieosiągalne więc należy założyć z góry poziom akceptowalny. Po drugie, w przypadku tego systemu, celem jest niska (ideałem jest zerowa) przestępczość więc cały system jest sterowany liczbą przypadków (i prób) łamania prawa. Należy mieć świadomość, że duża liczba przypadków łamania prawa może być efektem słabości przymusu, demoralizacji ale także zbyt surowego prawa. Problem nie jest prosty i wymaga nieco bardziej wyrafinowanego modelu niż ten jaki przedstawiłem, jednak uważam, że ten „lepszy” model będzie nieco dokładniejszy a nie inny.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Na ten wpis pewnie wielu z Was czeka, tak przynajmniej sugerują listy do mnie i głosy na forach, a także potencjalni klienci. Ci, których niestety czasem krytykuję, także pewnie czekają. Pokażę na prostym przykładzie, proces od analizy przez wymagania aż do projektu dedykowanego oprogramowania. Całość będzie zgodna z fazami CIM/PIM (www.omg.org/mda). Projekt dziedziny, który powstanie będzie spełniał zasady SOLID projektowania obiektowego, projektowania przez kompozycje (zamiast dziedziczenia) (polecam artykuł Łukasza Barana) i DDD. Opis dotyczy każdego projektu związanego z oprogramowaniem, także gotowym np. ERP, CRM, EOD itp.
Korzystałem z opisu zasad gry w szachy zamieszczonego na WIKI:
Zasady gry w szachy ? prawidła regulujące sposób rozgrywania partii szachów. Choć pochodzenie gry nie zostało dokładnie wyjaśnione, to współczesne zasady ukształtowały się w średniowieczu. Ewoluowały one do początków XIX wieku, kiedy to osiągnęły właściwie swą bieżącą postać. W zależności od miejsca zasady gry różniły się od siebie, współcześnie za przepisy gry odpowiada Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się różnić w przypadku różnych wariantów gry, np. dla szachów szybkich, błyskawicznych czy korespondencyjnych. (Zasady gry w szachy ? Wikipedia, wolna encyklopedia).
To na co chcę zwrócić tu uwagę w szczególności, to metafora:
projektując (modelując) oprogramowanie dla człowieka, modelujemy narzędzie dla tego człowieka a nie jego samego.
Swego czasu pisałem, w artykule o nazywaniu klas, że oprogramowanie z reguły zastępuje dotychczasowe narzędzie człowieka a nie człowieka jako takiego. Druga ważna rzecz: aktor jest równoprawnym elementem systemu (tu systemem jest organizacja z jej ludźmi i używanymi przez nich narzędziami). No to zaczynamy.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.