Wstęp
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.
(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.
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.
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:
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.
(źr. Process Improvement at Carlsberg powered by ARIS from Software AG).
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 :)).
Polecam także wcześniejszy artykuł o modelowaniu organizacji z perspektywy systemów zarządzania jakością ISO, bo projekty IT to nie jedyny przypadek gdy modelowanie organizacji bardzo pomaga.
Sporo pracuję wykorzystując narzędzia z rodziny ARIS. Pójdę jeszcze dalej i wyróżnię nawet 6 poziomów. Opiszę je jednak troszkę innaczej niż robią to koledzy z Software AG. Mianowicie:
I. Poziom 1 i 2 przedstawia „kontekst” (gdzie?). Poziom 1 opisuje globalny kontekst organizacji, natomiast poziom 2 rozwija modele poziomu 1 ukazując jego dodatkowe możliwe warianty.
II. Poziom 3 i 4 przedstawia „koncepcje” (co?). Odpowiednio poziom 3 jest jakby mostem pomiędzy poziomami 2 i 4 w przypadku gdy „zawartość procesów biznesowych” jest zbyt rozległa lub skomplikowana. Z kolei poziom 4 opisuje „esencje” wyjaśniając „działanie biznesu”
III. Poziom 5 i 6 przedstawia „implementację” (jak?). Tutaj mamy następującą sytuacje: poziom 5 to jakby „operacyjna implementacja” związana z czynnościami i zdarzeniami występującymi na modelu poziomu 4. Poziom 6 opisuje w detalach to co musi być zrobione aby wykonać procesy opisane na poziomie 4 i/lub 5.
W swojej pracy zazwyczaj analizę opieram na poziomach 1, 2, 4 i 5, natomiast poziomy 3 i 6 występują czasami opcjonalnie (w zależności od potrzeb). Pracując z klientem mam zatem hierarchię 3 lub maksymalnie 4 poziomów. Wszystko zależy od wielkości organizacji i potrzeb, bo przecież poziomy opisu procesów mają nam pomóc uporządkować pracę a nie przeszkadzać oraz komplikować życie.
Rozumiem. Mnie zawsze zastanawia dlaczego tak mało firm doradczych zamiast korzystania z istnienia dokumentacji HR, wtórnie „modeluje” diagramami (dubluje) „wiedzę” wynikającą z zakresu obowiązków, zarządzeń i przepisów prawa zamiast się na nią w tych modelach powoływać? Tym bardziej, że i tak niemożliwa jest rezygnacja z tych (zakresy obowiązków, zarządzenia i przepisy prawa) dokumentów…
W sumie zachowując pewną konsekwencję (produkt lub stan biznesowy) mamy kolejne poziomy (szczegółowości) procesów biznesowych (nie end-2-end i nie implementacja):
– tworzenia dokumentów (np. wystawienie faktury),
– zmian statusów dokumentów (faktura utworzona, zatwierdzona, zaksięgowana, doręczona),
– dla każdej czynności przyporządkowujemy procedurę lub wymaganą umiejętność/wiedzę, te są dostępne w HR i np. dokumentacji ISO,
Ten najniższy to wspomniana implementacja i raczej nie BPMN a MS Word 😉 (z uwagą w artykule o złożonych jak algorytmy procedurach, które czasem faktycznie warto narysować).
Ale faktem jest, że nie ma jednego wzorca, każdy projekt wymaga ustalenia konwencji dopasowanej do aktualnej kultury firmy i stopnia jej (nie)uporządkowania 😉
Zastanawiam się czy na najwyższym poziomie zawsze mamy do czynienia z procesami typu end-to-end, a na niższych poziomach uszczegóławiamy ich definicję modelując sekwencje działań. Spotkałem się z mapą procesów, na której są one podzielone na obszary, np.: Produkcja, Rozwój, Sprzedaż i Obsługa Klienta, Planowanie i kontrola strategiczna. Można by powiedzieć że jest to pierwszy poziom modelowania procesów. Procesów wyróżnionych w ramach danego obszaru nie można jednak ułożyć w sekwencję, zgodnie z definicją procesu – obszary nie są zatem procesami typu end-to-end. W ramach wyróżnionych obszarów również mogą pojawić się także ?procesy? nie poddające się definicji, nazywam je roboczo ?ciągłymi?, czyli takimi które wykonywane są w sposób nieprzerwany, najczęściej posiadają one w nazwie określenie ?zarządzanie ??, np. Zarządzanie portfelem projektów, Zarządzanie jakością, Zarządzanie portfelem klientów.
Jak sobie radzić z tego typu ?procesami? ? czy w ogólne można je wyróżniać na mapie procesów, czy jednak dążyć do tego, aby każdy proces miał swój początek i koniec. Ich minus jest taki, że definicja procesu na niższym poziomie może być tylko enumeratywną listą procesów typu end-to-end realizujących poszczególne działania, wchodzące w skład ?procesu ciągłego?. Co więcej taka mapa procesów przestawiona została przez firmę konsultingową z BIG4, czyli posiadającej duże doświadczenie, przynajmniej w teorii. Z drugiej strony wydaje się, że istnieją obszary w organizacji, który nie można zdefiniować typowego procesu, a które podchodzą raczej pod coś co jest określane jak Case Management, czym ostatnio zajmuje się także OMG (standard CCMN).
Problem nie jest prosty, „źródłem zła” jest w moich oczach bałagan pojęciowy wprowadzany przez firmy doradcze, wprowadzają one często, we własnych metodach pracy, definicje pojęć odbiegające od tych jakie są określone w notacjach, które te same firmy stosują. Nie potrafią też ich uzasadnić, systemy pojęciowe jakie widuję w produktach wielu firm doradczych, nie tylko BIG4, nie spełniają definicji systemu pojęciowego (rozłączność, niesprzeczności pojęć i zupełność słownika).
Najpierw słownik (cytaty z PWN):
zarządzać: 1. ?wydać polecenie?, 2. zarządzać ?sprawować nad czymś zarząd?
proces ?przebieg następujących po sobie i powiązanych przyczynowo określonych zmian?
Tak więc zarządzanie procesem to „wydawanie poleceń podczas przebiegu następujących po sobie i powiązanych przyczynowo określonych zmian” (domyślnie, poleceń mających wpływ na dany proces). Proces end-2-end ma prostą definicję: początek i koniec (wejście i wyjście) są na styku organizacji z jej otoczeniem.
Planowanie i kontrola. Najpierw musi być zdefiniowana by ją modelować. Proces planowania tworzy plan, proces kontroli tworzy zdarzenia (dane) opisujące to jak się ma stan rzeczywisty do stany zaplanowanego. To produkty tych procesów: plan oraz dane o odstępstwach od planu. Proces planowania inicjowany jest potrzebą zbudowania planu, potem sygnałem o odstępstwach. Są to wewnętrzne procesy, nie mające z end-2-end nic wspólnego. Na jakim są poziomie? W niektórych firmach nawet na każdym!
Terminy takie jak Rozwój czy Obsługa klienta to atrybuty opisujące te procesy tak samo jak kolory: możemy procesy grupować dowolnie.
Większości procesów nie da się ułożyć w jedną sekwencję, co często próbują robić firmy, bo procesy – z definicji – inicjowane są zdarzeniami, a wiele zdarzeń występuje losowo z perspektywy organizacji: generują je elementy otoczenia tych organizacji, a nie one, organizacje, same.
Proces ciągły jest nadal procesem (proces destylacji wody zamienia wodę zanieczyszczona w czystą). Każdy taki proces jest mierzalny stopniem czystości i ilością litrów np. w jednostce czasu. Na pewno nie ma taka destylacja „w pewnym uproszczeniu” początku ani końca, ale proces to „powtarzalna sekwencja”, każdy kolejny litr brudnej wody jest podgrzewany, odparowywany i skraplany. To, że jest to ciecz nie zmienia tego faktu. Proces kontroli i zarządzania? Nie ma takiego! Zarządzanie to nie proces, to w reakcji na odstępstwo od planu, inicjowanie korekty planu. Faktem jest, że jest to tak „często” jak drobinki wody w strumieniu, ale nie jest to proces ciągły zarządzania tylko często występujący proces korekty planu.
Co do produktów BIG4 mogę powiedzieć tylko tyle, że żadna nie potrafi w projekcie udowodnić słuszności swojej metodyki, potrafi napisać, że jakiś proces jest lub nie jest czymś ale nie potrafi już tego „wykazać” (w każdym razie ja nie spotkałem się).
Również jestem zdania, że niektóre z wymienionych przykładów procesów (np. Produkcja, Rozwój) stanowią raczej dodatkowy atrybut procesu end-to-end aniżeli odrębny proces. Podobną koncepcję przytoczył zresztą kolega w pierwszej odpowiedzi, czyli atrybuty: gdzie? i co?.
Z drugiej strony nurtuje mnie przytoczona przez Ciebie definicja procesu end-to-end. Czy tego typu proces występuje tylko i wyłącznie na styku organizacji z biznesem? Wstępnie wydaje się że tak. Mam natomiast pewien dylemat, spowodowany pewnie dużą liczbą procesów identyfikowanych jako wewnętrzne (np. kadrowe, finansowej, administracyjne), które na pierwszy rzut oka są niezależne, jednak po głębszym zastanowieniu można dostrzec na niższych poziomach modelowanie jakieś powiązania z procesami end-to-end.
Zastanawiam się teraz jak wyglądają mapy procesów w organizacjach, których zarządza się procesami. Czy zawierają one wyłącznie procesy end-to-end, czy może utrzymywania jest także osobna mapa procesów wewnętrznych, wykorzystywanych w procesach end-to-end?
I kolejna nurtująca mnie kwestia. Przyjmując że proces end-to-end określa styk organizacji z otoczeniem, jak sobie radzić z właścicielstwem procesu skoro jego realizacja rozciąga się przeważnie przez wiele jednostek organizacji.
Od końca: jeżeli jakiś proces end-2-end nie ma jednego właściciela to „źle się dzieje w firmie” ;). typowym procesem end-2-end jest np. obsługa zapytań ofertowych czy zamówień. Jeżeli jeszcze pierwszy leży z reguły w całości w gestii np. dyr. dz. sprzedaży, to drugi już w wielu firmach jest „bezpański” i znam wiele firm, które zmieniają to po wpadkach z jakością obsługi. Z reguły właścicielem procesu obsługi zamówień staje się logistyk.
Co do procesów zwanych wewnętrznymi. One dostarczają zasobów niezbędnych do funkcjonowania takich jak ludzie (kadry), maszyny, środki finansowe (finanse) itp. W literaturze zachodniej na tematy BPM funckjonuje model IGOE lub ICOM procesu, opisany np. tu: OGOE (opis na stronie BPTrends). Moja wersja tego gdzie są zasoby opisana tutaj. Ludzie, maszyny, środki finansowe itp, to tak zwane „enablers” czyli elementy bez których procesy główne nie mogą funkcjonować. procesy dostarczające owe „enablers” są niewątpliwie bardzo ważne ale nie są to mimo wszystko procesy najważniejsze (end-2-end). Zresztą często są one outsoursowane.