Mapowanie procesu – wszystko co musisz wiedzieć

Dzień dobry.
Jak znaleźć – „Mariusz Ros podał świetny framework” … może jakiś link?
Dziękuje.

Good job 🙂

„Mapowanie procesu” używane tutaj to synonim do „modelowania procesu” (czy utworzenia modelu procesu) w Inżynierii Oprogramowania. To pojęcie z zakresu Inżynierii Oprogramowania, ale „mapowaniem procesu” zajmują się nie tylko informatycy, stąd ten rozjazd pojęć i brak systematyczności, spójności. Osobiście spotkałem się wielokrotnie z takim problemem, że ludziom myli się „mapowanie procesu” z „mapą procesÓW”, traktują to bardzo „płynnie” przechodząc pomiędzy pojęciami, a to wprowadza zamęt. Oczywiście można zastosować wiele kryteriów podziału procesów, w tym podział na „główne”, „pomocnicze” itp. ale to również potrafi sprowadzić na manowce, ze względu na złożoność wielu procesów i trudność w zarządzaniu tą złożonością – takie kryterium podziału, jak to ostatnie, nie pomaga w jej ogarnięciu. Osobiście stosuję inną systematykę, która pozwala „ogarnąć” złożone projekty, gdzie procesów jest bardzo wiele i jakoś trzeba zapanować nad złożonością obszarów biznesowych. Przede wszystkim, dzielę procesy na obszary – np. sprzedażowe, produkcyjne, operacyjne itp. w zależności od organizacji, dla której pracuję i w ramach nich tworzę Mapę Procesów Biznesowych. Przez „mapę procesÓW” rozumiem takie „helicopter view” na wszystkie procesy w danym obszarze (doskonale w UMLu nadaje się do tego profil Ericssona-Penkera), po czym na 2 poziomie – poziomie pojedynczego procesu, pokazuję jego „podprocesy”, gdzie każdy z podprocesów może być np. instrukcją stanowiskową, lub operacyjną w procesie. Instrukcję stanowiskową/operacyjną modeluję odrębnym diagramem na 3 poziomie szczegółowości/granulacji. To opisane wyżej kryterium ich identyfikacji jest trudniejsze, bo trzeba umieć zachować właściwy poziom granulacji w zależności od poziomu modelu i tego, co opisujemy, już w trakcie identyfikacji procesów starając się myśleć o ich organizacji. I tak na poziomie Mapy Procesów pokazujemy procesy i przepływy informacji i zasobów pomiędzy nimi, identyfikujemy „wyzwalacze” procesów i ich cele, na drugim poziomie pokazujemy sam proces i przepływy, często w obrębie jednej komórki organizacyjnej, np. działu. W tym procesie czynnościami mogą być instrukcje stanowiskowe, czy operacyjne, które specyfikujemy modelem czynności/akcji (w UML) na poziomie trzecim. By zilustrować, o czym piszę. Gdybym modelował Proces Produkcji Samochodów (linię produkcyjną), to „mapa ProcesÓW” na diagramie Ericssona Penkera pokazywała by proces inicjalizacji produkcji, proces obsługi magazynu części/logistyki, proces montażu karoserii w dziale, gdzie jest wytłaczana, spawana i malowana (być może lakiernia miałaby swój własny podproces), proces wyposażenia auta, oraz proces jego magazynowania po wyprodukowaniu. Nie wiem, czy ująłbym tutaj procesy „okołoprodukcyjne”, jak procesy sprzedażowe, procesy związane z B+R i projektowaniem auta – pewnie byłby to inny obszar procesów, w związku z tym inna mapa procesÓW w modelu procesów wykorzystującym profil Ericssona-Penkera. Na drugim poziomie, np. w dziale obsługującym montaż wnętrza auta, (na poziomie pojedynczego procesu), pokazałbym przepływ pracy z tym związanej (na diagramie czynności w UML, czy w BPMN, ale tutaj uwaga – mieszanie notacji to nieszczęście, lepiej tego unikać, w większości przypadków najbardziej uniwersalny wybór to UML). I tak np. w dziale wyposażenia wnętrza auta były by tam czynności związane z montażem części mechanicznych, wyposażeniem auta w konsolę zegarów, wyświetlaczy i wskaźników, montażem wyświetlaczy i wskaźników, zamontowaniem tapicerki, foteli, końcowy przegląd/odbiór jakościowy i przekazanie na magazyn wyrobów gotowych. To poziom 2 (pośredni). Na trzecim poziomie były by instrukcje stanowiskowe/operacyjne dla ludzi i robotów montujących część wyposażenia (np. instrukcja montażu siedzenia kierowcy, czy instrukcja montażu kolumny kierowniczej itp.). Takie podejście pozwala na „ogarnięcie” złożoności problemu i wprowadza pewną systematykę w działaniu, spójność w modelach – wiadomo czego się spodziewać na którym poziomie. Niestety w praktyce, poprzez proste „kalki” językowe wprost z języka angielskiego i brak przemyślanego podejścia, mamy chaos i mieszanie pojęć. Przed chwilą czytałem wyjaśnienie pojęcia „mapowanie procesów” w różnych źródłach i za każdym razem łapałem się za głowę, bo autorzy najwyraźniej mieli mało doświadczenia w tym zagadnieniu, stąd niespójność w ich opisach. Pozwoliłem sobie zostawić ten komentarz, bo w odróżnieniu od innych źródeł tutaj autor zachowuje spójność w podejściu, stąd można podyskutować, czy przeniesione wprost z angielskiego „mapowanie procesu” to szczęśliwe pojęcie, czy nie stosować w zamian „modelowania procesu”, co jest bardziej wprost mówieniem o tym, co robimy, a pojęcie „mapy procesÓW” zachować dla tego diagramu najwyższego poziomu w ujęciu strukturalnym pokazującego „helicopter view” pewnego obszaru procesów/procesów obszaru biznesowego. Poza tym samo zamodelowanie procesu to połowa sukcesu – równie ważne jest utworzenie modelu informacji, które przetwarza proces (słownik pojęć biznesowych/model dziedziny biznesu) a to już nie jest proste w BPMN, za to doskonale daje się zrobić w UML a potem zastosować na diagramie Mapy ProcesÓW” pokazując przepływy informacji/zasobów. Poziomem granulacji trudniej sterować, to wymaga pewnej biegłości w abstrakcyjnym myśleniu, identyfikacji podprocesów i pojęć na odpowiednim poziomie szczegółowości, myślenia o organizacji „mapy procesÓW” rozumianej jako zbioru powiązanych ze sobą procesów już w trakcie ich identyfikacji, ale właściwa organizacja procesów/identyfikacja na odpowiednim poziomie granulacji, jest kluczem do sukcesu. Miłego dnia, DJS.