W kontekście poziomów modelowania polecam książkę How Works Get Done [zotpressInText item=”{5085975:WMKD2JD4}”], którą właśnie kończę czytać. Bardzo dobre kompendium wiedzy o modelowaniu procesów w kontekście tytułowego “jak ta praca jest wykonywana”.
Nie będę tu pisał streszczenia ;). Książkę gorąco polecam, jest napisana pragmatycznie przez praktyka, który jednak zaznacza, że skuteczne modelowanie, analiza, usprawnianie procesów i firm wymaga pełnego zrozumienia działania tych firm, zrozumienia wzajemnego wpływu ludzi, zasobów, mechanizmów, celów na produkty procesów, podkreśla także znaczenie i wskazuje korzyści z formalnego podejścia to analizy i modelowania (z naciskiem na słowo modelowanie a nie mapowanie).
Autor wskazał w niej także drugą, po modelowaniu procesów, ważną rzecz w projektach tego typu: model danych. Nie chodzi to jednak o modele baz danych (choć wspomina o nich) a o model struktury informacji. Każdy obiekt danych (dokument itp.) na modelach BPMN to abstrakcja “dokumentu” (zestawu danych). Prędzej czy później pojawia się potrzeba udokumentowania: struktury informacji i tego czym ona jest.
To na czym chce się tu skupić to fakt, że autor opisał co rozumie pod pojęciem “poziomów modelowania”, powołując się na takie nazwiska jak: Roger T. Burlton, G. A. Rummler i A. P. Brache [zotpressInText item=”{5085975:64HNXMZ3}”], których spokojnie można już traktować jako autorytety, twórców pewnego ustalonego podejścia, nie raz zresztą nazywanego ich nazwiskami.
Diagram zaczerpnięty z książki:
źr. How work gets done, Artie Mahal, Amazon.
Poziomy te są bardzo wyczerpująco opisane, tu chce tylko wskazać na pewne “pryncypia”, na które wskazywałem w moim niedawnym artykule o poziomach modelowania procesów: Poziomy te to nie “warstwy zagnieżdżania” proces/podproces, poziomy te to ustalona ich szczegółowość. Idąc w gorę model staje się coraz bardziej abstrakcyjny, idąc w dół model zawiera coraz więcej szczegółów.
Najwyższy poziom to “łańcuch wartości”, jest to odpowiednik procesu end-2-end. łańcuch wartości pokazuje role modelowanej organizacji w rynkowym łańcuchu wartości: “co do niej wchodzi i co z niej wychodzi”. Poniżej są procesy (i podprocesy) opisujące wewnętrzny łańcuch wartości firmy. Najniżej mamy poziom zarządzania: konkretne prace i zadania do wykonania wraz ze szczegółowymi opisami. reguły biznesowe są tu traktowane jako element sterujący wykonaniem pracy.
Porównajmy to z tym, znanym nam już, modelem:
(źr.
Poziom 0 (zero) to poziom strategi. Poziomy 1 i 2 to procesy biznesowe, łańcuch wejść i wyjść kolejnych procesów, abstrakcja opisująca jak firma realizuje swoją misję: dostarcza produkty na rynek. Poziomy 3, 4, 5, to najniższy poziom opisujący detalicznie czynności, zadania i procedury oraz zasoby. Liczba tych poziomów zależy już od tego jakie proporcje przyjęto pomiędzy procedurami i regułami biznesowymi a kompetencjami i automatyzacją. Poziomy te to stopień uszczegółowienia opisu (modelu) procesu ale nie hierarchia procesów.
Liczba poziomów modelowania zależy od skali działania firmy, jak widać są zawsze trzy kluczowe poziomy, w ramach każdego z nich można wydzielić ich szczegółowe warstwy (z możliwością dodawania kolejnych szczegółów 5+).
Na każdym poziomie używamy innych narzędzi, w szczególności poziomy 3 i niższe to raczej dokumenty: opisy procedur i szczegółowe instrukcje a nie modele i diagramy. Zaleca się na poziomie procesów biznesowych (poziom 1 i 2) stosowanie notacji BPMN. Najwyższy poziom nie wymaga aż takich formalizmów ale nic nie stoi na przeszkodzie by ich użyć.
Tyle moich komentarzy. Książkę polecam do przeczytania. Jak widać, pewne elementy analizy i modelowania są swego rodzaju kanonem, wymyślanie własnych może mieć sens ale wtedy wymaga to umiejętności udzielenia odpowiedzi na pytanie “dlaczego”. Od siebie mogę powiedzieć, że podejście bardzo podobne do opisanego powyżej stosuje od wielu lat, jako efekt własnych doświadczeń i analiz, które ku mojej radości jak widać nie są odosobnione. Ich zbieżność z cudzymi dokonaniami utwierdza mnie tylko w przekonaniu, że to właściwa droga.
A książkę polecam każdemu kto ma do czynienia z procesowym podejściem do zarządzania, jest napisana bardzo przystępnie, choć po angielsku.
Kwestia “liczby poziomów modelowania procesów” pojawia się na każdym moim szkoleniu w postaci pytań uczestników. Często także spotykam się z tym “zagadnieniem” w projektach i w literaturze. Można np. spotkać modele z procesami ponumerowanymi poziomami modelowania: procesy główne 0.1; 0.2 itp., procesy pierwszego poziomu: 1.1; 1.2; 1.3, dalej 2.2.4 itd. W czym problem?
Definicje
Po pierwsze: proces np. archiwizacji dokumentu może się pojawić na każdym z tych poziomów, jaki numer mu nadać? Po drugie pewne obszary działania są mało złożone i możliwe, że wystarczy jeden “poziom”, inne złożone i potrzebne będą może cztery poziomy?
Elementarny proces, podobnie jak klocek LEGO, może się pojawić wszędzie, niezależnie od poziomu, np. realizacja zobowiązania finansowego, czyli zapłata za coś, może się pojawić jako zapłata za fakturę wystawioną przez kancelarię prawną w procesie negocjowania umowy handlowej (czyli bardzo “wysoko”) jak i w procesie regulowania zobowiązań za dziurkacze (raczej nisko w takiej hierarchii).
Najpierw dwie kluczowe definicje za normą terminologiczną ISO 9000 (jakość zarządzania):
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.
Procedura to: określony sposób realizacji działań lub procesów.
Powyższa definicja jest łatwa do przyjęcia i często stosowana, jednak jest zbyt uboga (pojęcie proces jest tu dość pojemne) by stanowiła podstawę do formalnego modelowania organizacji, dlatego dodatkowo przytoczę tę, nieco pełniejszą:
(cytat, str. 41) Proces biznesowy jest chronologicznym i logicznym ciągiem funkcji (zadań) wykonywanych w toku pracy nad określonym obiektem w ramach racjonalnego działania. [zotpressInText item=”{5085975:UQN54LMV}”]
(cytat, str. 431) Proces biznesowy stanowi zbiór powiązanych ze sobą czynności ukierunkowanych na realizację określonego celu biznesowego w oparciu o wykorzystywane zasoby. Proces biznesowy jest sterowany poprzez strategię organizacji definiującą cele oraz produkty tworzone przez procesy. [zotpressInText item=”{5085975:UQN54LMV}”]
Przeglądając literaturę przedmiotu (w tym powyższe) można dojść do następującej definicji procesu biznesowego:
Proces biznesowy: czynność, lub logicznie powiązany chronologiczny łańcuch czynności, przekształcający stan wejścia procesu w stan jego wyjścia, mający wartość dla odbiorcy. Proces do wykonania, wymaga określonych zasobów, sposób jego realizacji może być ograniczony. (opr. własne)
Do modelowania procesów obecnie używa się najczęściej notacji BPMN (obecnie tak zwany standard de’facto), specyfikacja tej notacji tak definiuje proces:
A Process describes 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 Flows that define finite execution semantics. Processes can be defined at any level from enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped together to achieve a common business goal. [zotpressInText item=”{5085975:JSERUS7B},{5085975:QJUPRFNR}”]
Warto zwrócić uwagę na fakt, że z perspektywy notacji, ta jest jedynie językiem wyrazu, proces to “sekwencja aktywności w organizacji, której celem jest dostarczenie określonego efektu”. Dalej: proces jest obrazowany z pomocą grafu złożonego z elementów o określonej semantyce (mających sztywno określone znaczenia). Proces może być definiowany na dowolnym poziomie. Procesy na najniższym poziomie mogą być grupowane np. wspólnym celem. Tyle notacja. Definicja procesu w BPMN jest zgodna z ISO.
Tak więc procesem jest tu każdy przepływ pracy, zaś procesem biznesowym są te przepływy, których granice (początek i koniec) wyznaczają produkty biznesowe (określone obiekty, cele biznesowe).
Co to oznacza? Oznacza to, że skoro celem biznesowym jest np. wystawienie faktury za dokonaną sprzedaż, zaś przygotowanie samej treści faktury jest jedynie jednym z etapów jej tworzenia (krok), procesem biznesowym jest wystawienie faktury, ale nie jest nim samo jej zredagowanie (krok, kolejne zadanie) bo poza redagowaniem mamy także czynności sprawdzenia, księgowania i wydruku. Tak więc na najniższym poziomie hierarchii mamy proces Fakturowanie, dalsze szczegóły wystawienia faktury to procedura jej tworzenia składająca się z kolejnych, ustalonych kroków (zadań do wykonania).
Proces biznesowy Fakturowanie może być (i z reguły jest) częścią nadrzędnego procesu Realizacja zamówienia. Pierwszym produktem tego procesu jest Zamówienie gotowe do wykonania, proces ten to np. sekwencja Rejestracja Zamówienia i Weryfikacja Zamówienia. Cały proces Realizacji zamówienia ma więc dwa podprocesy: Rejestracja zamówienia oraz następujący po nim proces biznesowy Fakturowanie. Produktem pierwszego jest Zatwierdzone zamówienie a produktem drugiego Faktura sprzedaży.
Poszczególne wewnętrzne kroki obu procesów, same z siebie, nie tworzą produktu (np. zarejestrowane ale niesprawdzone Zamówienie nie ma wartości biznesowej, to krok który należy wykonać ale nie jest to samodzielny proces biznesowy).
Popatrzmy na poniższy diagram:
[zotpressInText item=”{5085975:IYBBBCGI}”]
Pokazuje trzy kluczowe poziomy procesowego opisu organizacji: na samym dole mamy zasoby, ich umiejętności wspierane procedurami. To warstwa realizacji, ta która jest udokumentowana w każdej niemalże organizacji jako zakresy obowiązków, procedury i zarządzenia. Najwyższa warstwa to kluczowe elementy strategii, architektura kluczowych procesów. Na tym poziomie można mówić o tak zwanych procesach end-2-end czyli o tym jak organizacja reaguje na bodźce zewnętrzne (np. na każde zapytanie ofertowe odsyłana jest oferta). Ten poziom także jest prawie zawsze udokumentowany jako strategia i plan marketingowy. Warstwa środkowa, procesy biznesowe, to abstrakcja opisująca (modelująca) logikę działania organizacji – jej wewnętrzny łańcuch wartości.
Popatrzmy teraz na jeden ze sposobów ustalenia liczby poziomów modelowania, bardzo często spotykany:
Level 1 ? End-to-end processes: Span across functions, e.g. market-to-cash.
Level 2 ? Main process areas: Typically function-specific, e.g. accounts receivables.
Level 3 ? Sub-processes: Sequence of related activities, e.g. goods invoicing.
Level 4 ? Activities: Key steps within sub-process, e.g. printing invoices.
Level 5 ? Tasks: Specific user actions or system transactions, e.g. send invoice to print. A step contains a description of how to perform the task.
Poziom oznaczony Level-1 jak najbardziej mamy “zawsze”. Różnica pomiędzy poziomami 4 i 5 jest dla mnie niezrozumiała. Angielskie słowa acitivity i task to odpowiednio czynność i zadanie. Trudno mi sobie wyobrazić drukowanie faktury bez wysłania faktury do druku. Czy to dwa poziomy szczegółowości? To co tu widzę, i nie tylko tu, to mieszanie obszaru działania organizacji (ludzi) z obszarem realizowanym przez “zasoby”. To troszkę (podane przykłady) jak by ktoś uznał, że czynność (poziom 4) to zmiana biegu w samochodzie a zadanie (poziom 5) to zazębienie się właściwych kół zębatych w skrzyni biegów. Ma to sens?
Poziomy 2 i 3 to modele procesów, liczba tych poziomów może być różna o czym dalej.
Przykład
Poniżej procesy end-2-end (celowo nie nadałem im rzeczywistych nazw by nie sugerować się konkretną firmą czy branżą):
Pokazuje jak organizacja reaguje na zdarzenia generowane przez jej otoczenie biznesowe. Kolejny etap (poziom ?) to model (diagram) dla każdego tego procesu:
– proces A
– proces B
Proces A zawiera (tworzy) pośredni produkt (Dane 5) oraz produkt Dane4. Zgodnie z definicją procesu, oznacza to, że A składa się dwóch podprocesów, pierwszy tworzy produkt Dane5 a drugi Dane4. Proces tworzący Dane5 jest wykonywany np. na bazie wiedzy wykonawcy (rola), który posiada wymaganą umiejętność, ta jest opisana w dziale HR więc powielanie zapisów z karty obowiązków jest zbędne, wystarczy się na nią powołać w dokumentacji procesu. Czynność tworząca Dane4 jest na tyle “złożona”, że wiedza wykonawcy to za mało (albo jest ryzyko, że się pomyli) dlatego dokumentujemy (formalizujemy) sposób tworzenia produktu Dane4 jako proces C składający się z określonych czynności:
Proszę zwrócić uwagę, że proces B i C to procedury (wewnątrz nie powstają produkty biznesowe), to tylko opis kroków jakie należy wykonać by powstał produkt procesu. Procedury z powodzeniem można, zamiast tworzyć takie diagramy, opisać znanym z projektów ISO strukturalnym tekstem, diagram raczej nie wnosi tu wartości dodanej. Tworzenie diagramów dla procedur miało by sens, gdyby zrezygnować z procedur w formie tekstowej, w przeciwnym wypadku tworzymy redundantne opisy wymagające synchronizacji. W praktyce robi się tak, dokumentuje procedury diagramami, w przypadkach gdy procedura jest złożona i jej opis tekstowy może być nieczytelny lub trudny w zrozumieniu. Analogicznie ma się sytuacja w przypadkach gdy sposób tworzenia produktu (proces biznesowy) w 100% jest efektem wiedzy posiadanej przez wykonawce (rola): tu powołujemy się wyłącznie na stosowne zapisy w dziale HR, nie tworzymy ich kopii w postaci diagramu.
Zobrazowanie powyższych diagramów, ich powiązań:
Tu mamy diagram obrazujący “podległość”, czyli to jak się one wzajemnie zagnieżdżają i to jak najbardziej obrazuje strukturę całego modelu. Jednak próba ponumerowania konkretnych procesów i zbudowania ich hierarchii zachowującej drzewiastą logikę jest nierealna z powodu własnie tego, że procesy są inicjowane zdarzeniami, te zaś nie są “poziomowe” (np. proces opisany na początku archiwizacji dokumentu może się pojawić na każdym poziomie/diagramie). Numerować hierarchicznie jednak można diagramy, które jak widać, mają strukturę podobną do systemu folderów.
Ile więc mamy poziomów modelowania organizacji? Trzy (patrz pokazany wcześniej diagram BPTrends): najwyższy czyli strategia i procesy end-2-end, najniższy czyli procedury i instrukcje stanowiskowe (implementacja) oraz środkowy czyli abstrakcję – model procesowy – opisującą jak to się wszystko do siebie ma (środkowy poziom ma strukturę zagnieżdżania się diagramów/modeli procesów jak wyżej ale procesy mają jedynie swoje nazwy jako identyfikatory).
Proszę zwrócić uwagę, że:
w zasadzie każda organizacja ma udokumentowany poziom najwyższy (strategia) i najniższy (procedury, zarządzenia, instrukcje)
warstwa środkowa jest tworzona wtedy, gdy chcemy zrozumieć wewnętrzne zależności, których może być dużo, i mogą być złożone (zawiłe); to ile “poziomów” powstanie w warstwie środkowej, zależy wyłącznie od stopnia złożoności danej organizacji i zawsze jest to indywidualna jej cecha, tylko w części zależna od wielkości organizacji.
Często można się spotkać z nieformalnymi (o niezdefiniowanych granicach procesów) diagramami w postaci:
Poziom najwyższy:
i poziomy niższe:
Czy taki diagram nam coś nam daje? Jest w zasadzie graficzną formą tekstowego (niejednoznacznego) opisu.
Modelowanie procesów biznesowych to nie rysowanie diagramów, to tworzenie modeli, które poddają się walidacji i testowaniu zgodności z rzeczywistością. Poprawne modele pozwalają przewidywać reakcję organizacji na planowane zmiany.
Na zakończenie
Modne ostatnio projekty modelowania procesów biznesowych z reguły, jako produkt, dostarczają niezliczone ilości “map procesów”, które kończą swój żywot na zakurzonych z czasem półkach, powstawały zbyt dużym kosztem by je wyrzucić do kosza. Ich stałe utrzymanie (aktualizacja) nie raz bywa kosztowniejsze od wytworzenia.
Po więc robimy te modele? Przytoczę znowu cytat inicjujący pewną dyskusję na forum:
I think the only reason to conduct any project is to improve one or more processes. This means that if you don’t know which process(es) you are trying to improve, you should not start the project. Comments? (Process before project | LinkedIn).
W wolnym tłumaczeniu ;):
jeżeli uznamy, że jedynym powodem prowadzenia projektów jest usprawnianie określonych procesów biznesowych, to znaczy, że uruchamianie tych projektów bez wiedzy, które to dokładnie procesy i bez pełnego zrozumienia ich wpływu na organizację, projektów tych nie należy rozpoczynać.
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, to jest stenotypia. Modelowanie to trudny proces odkrywania prawdziwej logiki działania organizacji (i wypada mi teraz zaprosić na moje szkolenia :)).
Mój serwis systematycznie płynie w stronę marketingu i strategii, chyba nie ma od tego odwrotu. Praktyka pokazuje, że wybór i próba wdrożenia jakiegokolwiek systemu bez związku ze strategią firmy, że już nie wspomnę, przy jej braku, nie wróży dobrze.
Często spotykam się z twierdzeniem, że do wdrożenia nowego systemu trzeba tylko spisać wymagania i przeprowadzić przetarg. Cała sztuka w wymaganiach. Modne są tak zwane ankiety, na bazie których zbiera się informacje o tym co robią pracownicy i na ich podstawie spisuje wymagania. Opis taki staje się wyznacznikiem tego co ma robić wdrażany system i najczęściej pierwszym gwoździem do trumny wdrożenia.
W czym kłopot? W tym, że taka procedura to zastój a nie rozwój.
Firmy, które wdrożyły z sukcesem jakikolwiek system wiedzą, że w większości przypadków stan organizacji pracy osiągnięty po wdrożeniu nijak się nie ma do dawnych opisów z ankiet przedwdrożeniowych, wiec po co je robić?
Więc jak to robić? Firmę można opisać (zamodelować) na trzech podstawowych poziomach:
Cel rynkowy, podstawowa wartość dodana oferowana na rynku czyli położenie w łańcuchu wartości
Opis tego w jaki sposób realizowany jest przez firmę podstawowy produkt rynkowy czyli opis łańcucha procesów biznesowych (przypominam, że proces to zespół czynności tworzący wartość)
Opis tego, w jaki sposób pracownicy firmy realizują prace opisane łańcuchem procesów (łańcuch czynności, pracy.
Czym jest strategia firmy? Jest tym co stanowi podstawę planowania działań nad rozwojem firmy. Jeżeli plan to stan firmy przewidywany jako osiągalny w założonym czasie to strategia jest receptą na realizację tego planu. To lista działań i sposobów ich prowadzenia.
Jak więc można podejść do wyboru i wdrożenia systemu
Powyższy diagram (opracowanie własne) to model procesu realizacji planu rozwoju w kontekście wdrożenia systemu informacyjnego. Każdy z elementów zobrazowanych na diagramie powinien być w firmie zdefiniowany czyli:
Opisana strategia rozwoju
Opisany model funkcjonowania (model procesów biznesowych)
Procedury czyli recepty na wykonywanie czynności
To ostatnie podlega zmianom w trakcie wdrożenia. Dlaczego? Powodem jest właśnie to, że wybierany i potem wdrażany system stanie się nowym narzędziem pracy, które na pewno zmieni (powinno) sposób wykonywania większości czynności. Podejście polegające na spisaniu ankietami obecnie wykonywanych czynności i zaimplementowanie ich prowadzi do sytuacji, w której kierowcę przesadzamy z samochodu na śmigłowiec ale nadal karzemy mu poruszać tylko nad drogami i zatrzymywać na czerwonym świetle.
Należy się pogodzić z reorganizacją, określić cele wdrożenia jednak celem tym nie powinna być sama tylko automatyzacja. Nowy system powinien wnieść do firmy nową jakość, nowe możliwości. W przeciwnym wypadku trudno jest mówić o podnoszeniu konkurencyjności czy uzyskiwaniu istotnej przewagi rynkowej. Bo na czym miała by ona wtedy polegać? Jazda na szybszym rowerze sama z siebie nie jest sposobem na osiąganie istotnej przewagi. Należy najpierw obrać nową drogę i potem dobrać do niej najlepszy pojazd.
