Nagle na kilku grupach dyskusyjnych pojawiły sie ostatnio pytania jak sprzedać modelowanie procesów. Popularyzuje się chyba notacja BPMN (Business Process Modeling Notation, zestaw symboli i zasad ich użycia do modelowania procesów w organizacjach) i biblioteki symboli do MS Visio a także notacja UML (Unified Modeling Language, zestaw symboli do dokumentowania analizy obiektowej i obiektowych modeli systemów informacyjnych).  Nie jedna rozmowa pozwoliła mi szybko się przekonać się, że chodzi o rysowanie a nie o modelowanie. Bo model procesu opisuje zjawisko i jest zrozumiały zaś rysunek procesu to obrazek pokazujący tylko to powiedział pan Jan w trakcie wywiadu a rysownik to skrzętnie narysował, najczęściej jakimś fajnym programem do rysowania diagramów, nie raz jest to MS Visio.

Jak już na jednej z tych grup napisałem, rysunki zawsze można tworzyć i sprzedawać i są tacy co je kupują, modelowanie zaś to wstęp do analizy modelowanego zjawiska, a jest nim także proces biznesowy.

Uważam także, że do modelowania potrzebna jest znajomość ogólnej teorii systemów, teorii modeli i analizy obiektowej w przypadku UML,  do modelowania firm i organizacji dodatkowo wiedza z teorii zarządzania. Bez tego można np. wieżę Eiffla nie zamodelować (stworzyć jej model) a co najwyżej ją narysować, nawet bardzo ładnie ale bez zrozumienia tego jak powstała i dlaczego się jeszcze nie zawaliła. 

Czym sie różni rysunek wieży Eiffla od modelu tejże wieży?  No tym, że rysunek poza tym, że nie raz ładnie wygląda na ścianie nie przyda się do analizy odporności wieży na podmuchy wiatru, nie przyda się do oceny jej sztywności, nie przyda sie nawet do dokładnego wyliczenia ile czasu będzie spadał z niej samobójca (teraz jest siatka więc już nie spadają). Dziś powiem troszkę o modelach jakimi są także mapy procesów, nie będziemy modelowali statków. 

Prawdziwy model

Model to przede wszystkim narzędzie analityczne i komunikacyjne. Analityczne bo model powinien bez potrzeby kontaktu z pierwowzorem zachowywać sie tak jak on (w wybranym kontekście oczywiście). Komunikacyjny bo powinien być zrozumiały dla osoby nie biorącej udziału w jego tworzeniu. Po trzecie model powinien odwzorowywać istotę badanego zjawiska a nie kopiować jego poboczne cechy lub opisywać nie wnoszące nic do badania informacje oczywiste lub wręcz zaciemniające istotę problemu. Model wieży Eiffla do celów zbadania oporów powietrza nie musi zawierać informacji o kolorze i o tym ile schodów należy pokonać by na nią wejść. Na tej samej zasadzie rysowanie na diagramie faktu, że np. dokument jest komukolwiek przekazywany z ręki do ręki jest rysownictwem a nie modelowaniem. 

Nie będę tu rozwijał tego wątku gdyż temat dokładnie zdefiniowałem w treści mojego kursu (patrz koniec tego tekstu) ale tu kilka przykładów. Oferta w pewnej firmie jest tworzona przez handlowca, zatwierdza ją dodatkowo jego przełożony jeżeli wartość oferty przekracza 10.000zł. Handlowiec pracujący krócej niż kwartał zanosi do zatwierdzenia wszystkie swoje oferty.  Na diagramie, który swego czasu audytowałem było sześć czynności (sześć prostokącików) nazwanych "Przekazanie dokumentu...". Konia z rzędem temu kto pokaże tu wartość dodaną (patrz słownikowa definicja procesu biznesowego). Skoro jedna osoba dokument przygotowała a druga go czyta to oczywistym jest, że dokument musi zostać tej osobie przekazany. Nie musimy (i nie powinniśmy) pisać tego w jaki sposób się to stało bo może to ulec zmianie bez utraty istoty procesu (następstwa czynności) ot choćby po wprowadzeniu elektronicznego obiegu dokumentów (tu ewentualnie jest miejsce na modelowanie wymagań funkcjonalnych na system IT ale to inny model!).

Pierwsza rada dla Państwa: jeżeli osoba modelująca Wam procesy umieści na diagramach czynności oczywiste  to znaczy, że jest to rysownik a nie modelarz. Bo jeżeli nawet np. czynność przekazania dokumentu jest istotna z powodów czasowych a planujemy symulacje czasu trwania procesu na podstawie tego modelu to należy ją połączyć z procesem (czynnością) opracowania dokumentu bo celem procesu opracowania dokumentu jest to by znalazł sie on w rękach osoby, dla której został przygotowany i musi do niej dotrzeć co jest oczywiste. Pomijam, że osobiście nie widzę nic wartościowego w takich symulacjach ale to moje subiektywne zdanie. 

Drugi przykład (także z życia). W pewnej instytucji (nie mogę zdradzić jakiej niestety, jest to ważna instytucja) uaktualniałem modele procesów i dodawałem nowe. Jakież było moje zaskoczenie gdy znalazłem na jednym z diagramów niemalże algorytm obsługi sprzętu służącego do przekazywania depesz. Proces wysłania lub odebrania depeszy tym sprzętem jest dokładnie opisany w instrukcji obsługi. Sam proces odebrania lub wysłania zawsze ma ten sam cel, sprzęt może zostać wymieniony na nowszy jednak proces nie ulegnie zmianie a tu proszę: model instrukcji obsługi! Po drugie sprzęt jest typowy dla tego typu instytucji i umiejętność jego obsługi jest zapisana w oczekiwanych kwalifikacjach pracowników zatrudnianych w tej organizacji (oczekiwane kompetencje na tym stanowisku opisane w dziale kadr). Tak więc jeżeli ktoś Państwu "modeluje" podręczniki lub kompetencje pracownika to jest to rysownik a nie modelarz. Tu niestety tym rysownikiem był konsultant rodem z międzynarodowej korporacji. Nie chodzi mi o krytykę tejże korporacji bo ma ona nie małe osiągnięcia na polu modelowania właśnie procesów, jednak dlaczego wysłali rysownika? Nie wiem. 

Tak więc model procesów biznesowych, którego celem jest opisanie tego jak powstaje wartość dodana w firmie i jak jest firma zorganizowana nie powinien zawierać algorytmów pracy, opisów czynności oczywistych czy też opisów oczekiwanych kompetencji. Wtedy modele procesów są na prawdę wartościowymi dokumentami, nie są to setki stron papieru, można je przeczytać bez potrzeby wlewania w siebie litrów RedBull'a, opisują sedno rzeczy, doskonale nadają się np. do sprecyzowania wymagań na system IT czy też wdrożenia Zrównoważonej Karty Wyników. 

Nie zapominajmy jednak, że rysownicy rozliczają się z ilości papieru a modelarze z liczby modeli zaś dobry model procesów jest jak wiersz: sztuką jest jego stworzenie ale do przeczytania powinna wystarczyć znajomość alfabetu i jeden wieczór. Niestety w wielu firmach spotykam się tylko z rysunkami i nie dziwię się, że prezesi tych firm nie widzą w tym sensu.

Krótko o narzędziach

Na zakończenie kilka słów o narzędziach pracy modelarza. Modele można robić ołówkiem na papierze i jest to także dobry sposób. Można sobie troszkę ułatwić rysowanie jakimś programem do tworzenia schematów blokowych (np. mój ulubiony kiedyś MS Visio). Jednak nie raz mamy do czynienia z modelami dużych organizacji, modelami zawierającymi wiele elementów i skomplikowanych zależności. Próba wykonania ich prostym narzędziem nie jest niemożliwa ale jest bardzo pracochłonna i obarczona ryzykiem powstania wielu błędów niespójności. W takich przypadkach faktycznie potrzebny jest kilku poziomowy system kontroli jakości by tego typu błędy wychwytywać, jest to jednak wyjątkowo kosztowny i czasochłonny proces (nawet kilku konsultantów zaangażowanych w wytworzenie jednego diagramu!).

Na szczęście na rynku dostępne są systemy dedykowane do tego typu pracy. Powszechnie nazywane są systemami typu BPM (Business Process Management) lub bardziej rozwinięte systemy klasy CASE (Computer Aided System Engineering). Czy warto w nie inwestować? Warto. Bo wyobraźcie sobie Państwo, że Waszą pracę magisterską nafaszerowaną rysunkami z wielopoziomowym systemem rozdziałów i podrozdziałów, indeksów pojęć i przypisów zleciliście do przepisania osobie mającej do dyspozycji tylko Notatnik z systemu Windows a osoba ta rozlicza się z Wami za czas pracy. Tak właśnie wygląda praca z diagramami nie tylko w Visio bo znam takich co robią to za pomocą programu do tworzenia prezentacji. Nie twierdzę, że modele te są złe, one po prostu są koszmarnie pracochłonne i kosztowne.

Tak więc na początku projektu należy sobie zawsze odpowiedzieć na pytanie: modelarz czy rysownik. Po drugie nie kupujcie modelowania tylko płaćcie ekspertom za wsparcie w rozwiązywaniu Waszych problemów i dokumentowaniu Waszych decyzji bo model to także doskonały sposób na udokumentowanie decyzji ot choćby właśnie organizacyjnych (np. dla potrzeb norm jakości ISO).

Tych, którzy chcą podjąć próbę samodzielnego modelowania procesów zapraszam zaś na mój autorski kurs dostępny zdalnie, opis kursu: Modelowanie procesów biznesowych w analizie systemowej. 

W przygotowaniu mam artykuł o modelowaniu systemów z pomocą notacji UML jako zapis moich przemyśleń po konferencji na ten temat wiec zapraszam do subskrybowania mojego newslettera.