Wstęp
Jako analityk i projektant, w projektach które nadzoruję to ja jestem autorem dokumentów, moje problemy to raczej tłumaczenie developerom treści tych dokumentów (mimo tego, że każdy(!) developer składając ofertę, oświadcza że zna i posługuje się notacjami BPMN ?(?Business Process Model and Notation,? 2014)? i UML ?(?Unified Modeling Language,? 2017)?, praktyka jednak pokazuje, że bardzo często kłamią).
Jako wykładowca akademicki, osoba prowadząca badania nad tworzeniem i stosowaniem modeli, a także jako osoba audytująca cudze dokumenty, lub udzielająca po prostu konsultacji studentom innych uczelni, mam poważny problem z argumentami „a tu (jakaś publikacja) jest tak napisane”. Przywykłem do tego, że tam faktycznie „jest tak napisane”. Problem pojawia się gdy okazuje się, że autorem „tego co tak jest napisane” jest utytułowany pracownik uczelni lub utytułowana firma doradcza.
Ten artykuł będzie o niskiej jakości niektórych dokumentów. W czym problem z kiepskiej jakości analizami i modelami? W tym, że ich autorzy podejmują próby dodawania nowych symboli do notacji, psując spójność i jednoznaczność diagramów, stosują symbole notacji niezgodnie z nadanymi im znaczeniami, czyli łamią zasady semantyki i syntaktyki notacji, albo łamią zasadę wyłączonego środka mówiącą w uproszczeniu, że jeżeli coś jest czymś to znaczy, że nie jest już niczym innym (np. jeżeli coś jest zdarzeniem to na pewno nie jest ani czynnością, ani danymi, ani regułą decyzyjną).?(Żeliński, 2011)?
W ciągu dosłownie dwóch dni, wpadły mi w ręce trzy, dostępne publicznie, opracowania:
- doc.1. Analiza procesów biznesowych pewnego urzędu, wykonana przez dużą, znaną firmą doradczą, jest to załącznik do SIWZ (publikacja na BIP tego urzędu), opracowanie z 2012 roku,
- doc.2. Wynik i opis mapowania procesów biznesowych, którego celem było przygotowanie do wdrożenia zintegrowanego systemu zarządzania w pewnej firmie, publikacja naukowa osoby z tytułem doktora inż. pewnej znanej politechniki, publikacja z 2018 r.
- doc.3. Wynik i opis mapowania procesów biznesowych, którego celem było wsparcie analizy konkurencyjności i ryzyka, publikacja naukowa osoby z tytułem doktora inż. pewnej znanej politechniki, publikacja z 2016 r.
Nie jest tu moim celem recenzowanie tych prac, celem jest wskazanie dość powszechnie popełnianych błędów. Do celów tego artykułu zanonimizowałem te prace (choć cytaty są nie do uniknięcia).
Doc.1.
Słownik pojęć zawiera jedynie osiem pozycji, w tym: czym jest BPMN, czym jest IT, definicję procesu i procesu biznesowego, zbliżoną do definicji umieszczonej w Dodatku C specyfikacji notacji BPMN ?(?Business Process Model and Notation,? 2014)?, zdefiniowano pojęcia Wykonawca i Zamawiający.
Dokument zawiera listę procesów uznanych za kluczowe, pogrupowaną w obszary tematyczne, jednak nie podano ani źródła tej listy ani metody jej opracowania ani opisu metody grupowania i selekcji. Innymi słowy treść ta nie może podlegać żadnej ocenie poprawności, po prostu „jest dobra” z powodu, że ją podano. Jedyne podane uzasadnienie kształtu tej lisy jest „podjęta decyzja” (czyli dowód z autorytetu). Dokument ma 55 stron, powstał w 5 tygodni, modele i opisy procesów stanowią ok. połowę objętości. W części Metodyka nie opisano metod, podano własne definicje elementów notacji BPMN, niezgodne nie raz z oryginałem: pojęcie proces w BPMN oznacza poprawny diagram BPMN a nie „logiczny ciąg czynności niezbędnych do przekształcenia stanu wejściowego w wyjściowy”, to dodatek C zawiera definicję:
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. (ang. Proces biznesowy: zdefiniowany zestaw aktywności biznesowych, które reprezentują kroki wymagane do osiągnięcia celu biznesowego. Obejmuje przepływy, wykorzystanie informacji i zasobów.)
Warto wiedzieć, że notacja BPMN nie zawiera symbolu definiowanego jako „proces biznesowy”. I dalej: dokument zawiera definicję:
Czynność (activity) ? jeden element diagramu procesu, reprezentujący
jeden krok w procesie; łączy się z innymi czynnościami poprzez połączenia (connection lines) opisujące kierunek przepływu transakcji,
Oryginał w BPMN:
An Activity is a generic term for work that company performs (see page 151) in a Process. An Activity can be atomic or nonatomic (compound). The types of Activities that are a part of a Process Model are: Sub-
Process and Task, which are rounded rectangles. (ang. Aktywność jest podstawowym prostym terminem określającym pracę jaką w firmie się wykonuje (patrz strona 151) w ramach procesu. Aktywność może być atomowa lub nieatomowa (złożona). Typy aktywności wchodzące w skład modelu procesu to: Sub-Proces (pod-proces) i zadanie, które są zobrazowane jako zaokrąglone prostokąty.A Task is an atomic Activity that is included within a Process (see page 156). A Task is used when the work in the Process is not broken down to a finer level of Process detail. (ang. Zadanie jest atomową (elementarną, niepodzielną) aktywnością zawartą w procesie (patrz strona 156). Zadanie jest używane [w modelu] , gdy dana praca w [modelowanym] procesie nie jest już dzielona na kolejne pod poziomy procesu.)
Dla wyjaśnienia z dodatku C:
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ść atomowa: Aktywność niedzielona na kolejne poziomy szczegółów modelu procesu. Jest liściem w hierarchii struktury aktywności danego procesu. Graficznie jest to zadanie [task] w BPMN).
Warto wiedzieć, że pojęcie transakcja (autor tego dokumentu używa go zamiennie z pojęciem proces) w BPMN jest zastrzeżone (dla modeli wykonywalnych), i oznacza:
A transaction is a Sub-Process that is supported by a special protocol that insures that all parties involved have complete agreement that the activity should be completed or cancelled (see page 178). (ang. Transakcja to podproces obsługiwany przez specjalny protokół [w systemie BPMS, przyp. mój], który zapewnia, że ??wszystkie aktywności będą zakończone lub nie, i wtedy ich pośrednie efekty zostaną anulowane (patrz strona 178).
Definicja pojęcia zdarzenie w oryginale:
An Event is something that ?happens? during the course of a Process (ang. Wydarzenie to coś [fakt], co ?wydarzyło się? w trakcie procesu).
zaś autorzy dokumentu piszą: „Zdarzenie (event) ? stan jaki pojawia się podczas przebiegu procesu biznesowego. I w takim samym stylu „przedefijiowano” BPMN w pozostałej części opracowania. Stwierdzenie zaś, że „Czynnościami w modelu procesu mogą być: Proces, Podproces, Zadanie.” to już czysta herezja (w BPMN nie ma symbolu o nazwie proces). W dodatku C mamy:
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: sekwencja lub przepływ działań w organizacji mająca na celu dostarczenie efektu pracy. W BPMN proces jest przedstawiany jako diagram złożony z elementów przepływu, które są zestawem działań, zdarzeń, bramek i sekwencji przepływu, które są zgodne z [określoną] semantyką realizacji procesu.)
Innymi słowy proces w BPMN to poprawny diagram (schemat blokowy zgodny z semantyką i syntaktyką notacji).
Diagramy czyli ignorowane definicje. Najpierw jednak pewna uwaga, już w 2013 roku pisałem:
Procesy modelujemy więc po to, by zrozumieć jak działa organizacja oraz po to, by przewidzieć jak się ona zachowa, jeżeli jakiś proces zmienimy, bo może się nie raz okazać, że nie warto się pewnych projektów podejmować z uwagi na skutki. Modelowanie, jak widać, nie jest procesem obrazkowego zapisu tego co wiemy od pracowników tej czy innej firmy, bo to jest stenotypia. Modelowanie to trudny proces odkrywania prawdziwej logiki działania organizacji. ?(Żeliński, 2013)?
Co do zasady, zgodnie z przytoczonymi definicjami, mamy pewne wbudowane ograniczenie na poziom szczegółowości modeli. Te ograniczenia to definicje atomowej aktywności (zadanie) i procesu biznesowego (aktywność tworząca produkt). Innymi słowy model procesu powinien się składać z elementarnych aktywności, z których każda ma wskazany produkt (oczekiwany efekt). W BPMN jedynym elementem modelującym (służącym do zobrazowania) jakichkolwiek efektów zadań (produktów pracy) jest Data Object (Obiekt Danych, generalnie reprezentuje zestaw danych czyli dokument), który to – najważniejszy – element, autorzy pominęli przy opisie notacji. Rozbudowane diagramy w omawianym dokumencie, zawierają wiele różnych prostych aktywności i bardzo mało ich efektów. Na jednym z diagramów mamy np. Zadanie „Powzięcie informacji o błędnej deklaracji” nie mające żadnego wejścia ani produktu! (a jest tam takich sytuacji wiele). Takie elementy na diagramach, w literaturze przedmiotu (autorzy piszący o BPMN), są nazywane „śmieciowe czynności na diagramach”, są to elementy diagramu nie wnoszące żadnej wartości dodanej w łańcuchu procesu, stanowiące oczywiste stwierdzenia (jak np. „przekazanie dokumentu”). Więcej o tym pisałem w artykule Poziomy modelowania procesów ?(Żeliński, 2013)?. Wszystkie modele procesów w tej dokumentacji zawierają zadania w większości nie skojarzone z żadnym informacjami. Jeżeli tytuł opracowania zawiera „Analiza procesów biznesowych […] związanych z przetwarzaniem informacji […]” to nie wiem czego się dowie adresat tego dokumentu o tychże informacjach i ich przetwarzaniu.
Kwiatkiem na sam koniec, jest zastrzeżenie praw autorskich do dokumentu (beneficjent, który pokrył koszty tej analizy nie dostał praw majątkowych do jej efektu). Dokument nie zawiera imion i nazwisk autora (autorów).
Dok.2.
Zacznijmy od poprawności cytowania źródeł: autor podaje: Strona domowa firmy XXX, www.XXX.com.pl, dostęp 08.01.2018, rzecz w tym, że to strona tytułowa, dotarcie do miejsca skąd pobrano cytowaną treść graniczy z cudem. Po drugie autor piszący o notacjach, używający definicji notacyjnych, który to autor nie powołuje się na (i nie umieszcza w spisie leteratury!) ich oryginalnej specyfikacji wykazuje poważne braki metodologiczne.
Dokument zatytułowany jest Mapowanie procesów przygotowania oferty… a jego celem jest opisanie metod (metody?) modelowania procesów biznesowych. Z uwagi na anonimizację nie wkleję z oryginału, ale: przytoczenie jako przykładu dwóch diagramów UML bez podania ich nazwy (UML to trzynaście nazwanych typów diagramów, ?(?Unified Modeling Language,? 2017)?) jest poważnym uchybieniem. Publikacja traktuje o modelowaniu procesów, a autor jako przykłady podaje notację UML, a jako przykładowe modele UML podał akurat te, niemające z modelowaniem procesów nic wspólnego (maszyna stanowa i diagram komunikacji), warto też wiedzieć, że od 2015 jawnie w specyfikacji UML zostało napisane, że ta notacja służy wyłącznie do modeli systemów ?(?Meta Object Facility,? 2016)?, i nie należy jej używać do modeli biznesowych. Modele biznesowa CIM, (Computation Independent Model, ?(?MDA Foundation Model,? 2006)?) od tego są notacje BPMN ?(?Business Process Model and Notation,? 2014)? oraz SBVR ?(?Semantics Of Business Vocabulary and Rules,? 2017)?.
W tej pracy, na diagramach modeli procesów, popełniono wszystkie błędy opisany dla Doc.1., ale pojawił kolejny, wręcz kuriozalny: autor naniósł (rozciągnął) jedną aktywność na dwa tory (jedno zadanie ma dwoje odpowiedzialnych??) co jest niedopuszczalne w BPMN.
Doc.3.
W tytule tej pracy mamy: „Mapowanie procesów biznesowych jako technika wspierająca… „. W rozdziale Metoda badawcza, nie ma ani słowa o metodzie mapowania procesów (?) a następny rozdział jest zatytułowany Mapowanie procesów biznesowych. Rozdział ten zawiera schematy blokowe pozbawione legendy a więc nieczytelne i raczej trudne do interpretacji. Jeżeli autor tworzy własną notacją, to tym bardzie należy ją zdefiniować przed użyciem. Schematy blokowe (bez opisu i legendy!) kształtem nawiązują do tak zwanej metody „swim lanes” modelowania przepływu pracy, gdzie tory reprezentują osoby odpowiedzialne lub fizycznych wykonawców, czasami komórki organizacyjne. ?(Rummler & Brache, 2000)?. Jednak i tu jedna aktywność rozciągnięta na twa tory co jest łamaniem zasad.
Poziom merytoryczny (stosowanie metod a raczej ich brak), brak cytowania kanonu literatury na temat procesów biznesowych i ich modelowania, zastosowanie, bez uzasadnienia, własnej i niezdefiniowanej notacji, w XXI wieku, w zestawieniu z tym, że jest to produkt doktora inżyniera znanej uczelni technicznej w roku 2015, stawia także tego autora w słabym świetle.
Podsumowanie
Jak już wspomniałem na początku, celem moim było pokazanie tego, że prace zaliczane do profesjonalnych produktów firm doradczych, czy też będące tak zwanymi publikacjami naukowymi, powinny cechować się tym samym wysokim poziomem merytorycznym, a naukowe także metodologicznym. Z przykrością muszę tu napisać, że recenzje jak powyższa, są moim stałym zajęciem zarówno jako biegłego jak i nauczyciela akademickiego. Bo nie ma dla mnie znaczenia to, czy dokumenty, takie jak powyżej, przywołuje mój dyplomant czy też robi strona skarżąca usługodawcę. Znaczenie ma to, że one powstają, a ich autorzy otrzymują za nie, nie raz sowite, wynagrodzenie.
Często słyszę od autorów: „bo klient chciał żeby tak narysować”. Wiem, klienci nie raz tak chcą, ale zadaniem profesjonalisty jest zagwarantować poziom merytoryczny swoich dokumentów i ich jakość, a przede wszystkim ich późniejszą przydatność, a ta w takich sytuacjach bywa bardzo wątpliwa.
Klient nasz Pan? Często to słyszę. Otóż nie. Klient zamawia produkt, jeżeli jest nim opracowanie eksperckie, to nie klient a expert, jest jego autorem i to ekspert decyduje o treści (pod którą prawdziwy ekspert podpisuje się imieniem i nazwiskiem!). Taksówkarze też dzielą się na dwie grupy: Ci którzy łamią przepisy ruchu drogowego jak klient prosi (bo się np. spieszy) i Ci, którzy tego nie robią. Warto pamiętać, że ewentualne mandaty płacą kierowcy a nie pasażerowie.
Źródła
- Business Process Model and Notation. (2014). Retrieved 2019, from OMG.org website: https://www.omg.org/spec/BPMN/
- MDA Foundation Model. (2006). Retrieved 2019, from OMG.org website: https://www.omg.org/cgi-bin/doc?ormsc/10-09-06
- Meta Object Facility. (2016). Retrieved 2019, from OMG.org website: https://www.omg.org/spec/MOF
- Rummler, G. A., & Brache, A. P. (2000). Podnoszenie efektywności organizacji. Jak zarządzać ?białymi plamami? w strukturze organizacyjnej? Warszawa: Polskie Wydawnictwo Ekonomiczne.
- Semantics Of Business Vocabulary and Rules. (2017). Retrieved 2019, from OMG.org website: https://www.omg.org/spec/SBVR/About-SBVR/
- Unified Modeling Language. (2017). Retrieved 2019, from OMG.org.pl website: https://www.omg.org/spec/UML/About-UML/
- Żeliński, J. (2011, November 15). Logika wnioskowania dedukcyjnego czyli czym jest poprawna analiza i modelowanie. Retrieved September 13, 2019, from IT-Consulting.pl website: https://it-consulting.pl//2011/11/15/trzy-zasady-nazywane-czasem-najwyzszymi-prawami-myslenia-czyli-czym-jest-poprawna-analiza/
- Żeliński, J. (2013). Poziomy modelowania procesów. Retrieved 2019, from IT-Consulting.pl website: https://it-consulting.pl//2013/07/04/poziomy-modelowania-procesow/