Autor ANDRZEJ BOGUSZ
PO PIERWSZE: NIE MAPUJ! Kiedy i dlaczego warto mapować procesy biznesowe, a kiedy jest to niepotrzebnym wydatkiem.
Mapowanie procesów to nie sztuka dla sztuki. Mapa ma być przydatnym narzędziem, np. jako podstawa do dalszego rozwoju firmy lub impuls do podjęcia jakiejś decyzji. Jednak nie każdy problem wymaga zmapowania. Zatem kiedy mapować, a kiedy nie?
Mapowanie — moda, gadżeciarstwo czy…?
Rozpoczynam pierwsze spotkanie biznesowe z senior/top managementem o współpracy w temacie podnoszenia efektywności przedsiębiorstwa. Nagle, jako jedno z pierwszych wypowiedzianych zdań, pada ze strony klienta: „My jesteśmy bardzo zaawansowani, od roku mapujemy nasze procesy!”. Profesjonalizm nakazuje mi zachować twarz pokerzysty, wziąć głęboki oddech, tak jakbym z uznaniem przyswajał tę wiadomość. I dopiero po chwili poprzez meandry prowadzenia rozmów biznesowych (z dylematem „mam być szczery czy miły?”) dojść do właściwego pytania. Pytanie brzmi: „Po co?”.
Po zbyt „szczerym” zadaniu tego pytania, zazwyczaj tym razem z drugiej strony, następuje chwila na głęboki oddech lub dwa i słyszę w odpowiedzi, że: to dobre praktyki, pójście z duchem czasu, łatwość szkolenia, poszukiwanie wąskich gardeł, standaryzacja, wizualizacja, wspólne rozumienie procesów itp. Teoretycznie wszystko się zgadza. Ale po kolejnym moim pytaniu: „Jakie korzyści z tego mapowania osiągnęliście, wyraźcie to w dowolnej walucie (przecież prowadzicie biznes, a nie działalność non profit)?”, zaczyna się robić mniej komfortowo i trzeba dyplomatycznie zmienić temat. A jeśli zmiana tematu nie nastąpi, to może wyjść na jaw, że przyniesiona na to spotkanie wydrukowana mapa „wzorcowa”, mierząca po sklejeniu 3m x 50cm (20 kartek A4,) jest po prostu bezużyteczna.
Jeśli powyższa scenka wywołuje pobłażliwy uśmiech — bo przecież „u nas” tak nie jest — to bardzo dobrze, ale z tego typu sytuacją miałem do czynienia nie raz, nie dwa i nie trzy. I to w dużych, poważnych, dobrze prosperujących firmach. Co więcej, są na rynku firmy doradcze lansujące mapowanie jako systemową drogę do wzrostu efektywności. To trochę tak, jakbyśmy robiąc codzienną fotografię ogródka zapewniali wzrost trawnika i eliminację szkodników.
Mapa procesu — chwila wywodu teoretycznego
Co to jest mapa? Uogólniając definicję słownikową, jest to odwzorowanie, przedstawienie pewnej rzeczywistości w postaci symbolicznej, zazwyczaj graficznej, za pomocą ustalonego (i zrozumiałego) zestawu znaków (symboli).
Rzeczywistość ta (przedmiot mapowania) w przypadku procesu biznesowego jest ciągiem działań, realizowanych poprzez określone osoby lub urządzenia, przy użyciu pewnych środków, maszyn i innych zasobów, w konkretnej kolejności i czasie, mających za zadanie przetworzenie wsadu (wejścia do procesu) w produkt procesu.
Mapa procesu z kolei, czyli wspomniane jego odwzorowanie, może być zrealizowana w różnych aspektach. Najczęściej spotykane są mapy procesów:
- logiki (kolejności) działań — flowchart, czyli diagram procesu;
- powiązań z podmiotami zewnętrznymi względem procesu — np. SIPOC (Supplier-Input-Process-Output-Customer), co wg mnie nie do końca stanowi „mapę”, a raczej jest elementem architektury procesowej;
- przepływu pomiędzy stanowiskami, osobami, gniazdami — swimlane, tory pływackie;
- rodzajów ról pełnionych przez uczestników — RACI (Responsible-Accountable-Consulted-Informed, w jednej z wielu występujących wersji);
- generowania wartości dostarczanej klientowi — VSM (Value Stream Mapping);
- przepływu działań w czasie wraz z powstającymi danymi i dokumentami — Makigami;
- szczegółowych powiązań logicznych i przepływów danych – rozbudowane notacje typu BPNM na bazie swimlane;
- relacji ilościowych i czasowych przetwarzania w procesie — rozbudowa na bazie VSM lub swimlane, MCT (Manufacturing Critical-Path Time);
- przepływu danych i informacji — np. diagramy DPI/DPD (diagram przepływu danych/informacji), stosowane w inżynierii oprogramowania, ale również VSM;
- kombinacje powyższych i inne.
Nietrudno zauważyć, że różne mapy to narzędzia, które mogą służyć różnym celom. A zatem hasło „mapujemy” od razu rodzi pytanie: „jak?”. Żeby odpowiedzieć na pytanie, jakiego rodzaju mapowania mamy używać, trzeba zrozumieć, co jest naszym celem, jaki problem mamy rozwiązać dzięki temu — po co mamy mapować? Być może okaże się, że wcale nie musimy tego robić.
Po co mapować?
Są różne ku temu powody. Wymieniam w kolejności wynikającej nie z badań rynku, ale z mojego doświadczenia, zaznaczając, że czasem ostatni z tych powodów może być jedynym i wystarczającym. Nie jest to też lista kompletna. A zatem powody mapowania to m.in.:
- wspólne (dla zespołu lub różnych działów) zrozumienie przebiegu procesu od początku do końca,
- narzędzie komunikacji z interesariuszami procesu (budowanie relacji),
- określenie i uświadomienie zadań i odpowiedzialności,
- identyfikacja wymaganych i posiadanych kompetencji w relacji proces vs zespół,
- dobra identyfikacja klienta i celu procesu,
- określenie miar i celów procesu,
- określenie produktów i dokumentów powstających oraz możliwości audytowych,
- identyfikacja (zazwyczaj zespołowa) wąskich gardeł i obszarów potencjalnej optymalizacji,
- standaryzacja działań (mapa jako podstawa procedur),
- materiał szkoleniowy dla nowych pracowników,
- narzędzie ładu korporacyjnego,
- sprzedaż (efekt „łoł”)
- potrzeba szczegółowego określenia przepływów na potrzeby zbudowania rozwiązania IT.
(nawiasem mówiąc, narzędzia do mapowania stworzone w dedykowany sposób dla ostatniego z powyższych punktów są masowo stosowane we wszystkich pozostałych – jak się ma w ręku młotek, to na wszystko się patrzy jak na gwóźdź…)
Jeśli dobrze się zastanowić, to każdy z powyższych powodów jest dobry… ale też każdy z tych celów można osiągnąć (lub starać się osiągnąć) bez mapowania. Co więcej, niewłaściwie dobrane narzędzie mapowania może nas oddalić od osiągnięcia celu.
Niektóre procesy są w zmapowaniu trywialne, a mimo to problematyczne.
Często problemem nie jest cały proces, ale jego bardzo mały wycinek
(o czym mówi TOC – Theory of Constraints, czyli teoria ograniczeń) i oczywistym jest, że dopóki np. nasz system IT nie zwiększy przepustowości ponad określoną liczbę zapytań, lub kontrola jakości nie zacznie pracować na dwie zmiany, to więcej nie wyciśniemy. A najlepszy proces nie rozwiąże problemów złych relacji międzyludzkich i międzyzespołowych oraz braków kompetencyjnych (nie znajdziemy 15 kierowców Formuły1 w małej miejscowości).
A jeśli już mapować…
… to warto zwrócić uwagę na dwa istotne aspekty ryzyka z tym związanego. Przede wszystkim: kto jest klientem (odbiorcą) i/lub właścicielem (to mogą być różne osoby!) tego mapowania. Czyli kto określa odpowiedź na wcześniejsze pytanie „po co”, „do czego mi to posłuży” oraz kto na końcu odpowie na pytanie, czy podjęte działania mapowania były skuteczne, czy przyniosły korzyść, czy poniesione nakłady zwróciły się firmie. Ta korzyść może być arbitrem podczas zatwierdzenia standardów mapowania (tak, tak, często hasło „mapuj” jest w trzech miejscach realizowane na cztery sposoby pięcioma narzędziami). Mapowanie procesów jest samo w sobie procesem, a proces bez właściciela i określonego klienta jest sztuką dla sztuki. Co z tego, że pasjonującą…
A poza tym: co dalej będzie się działo z efektami mapowania? Czy służą tylko celom doraźnym i idą do kosza/archiwum (a przy kolejnej iteracji mapujemy od nowa — co akurat wcale nie musi być pozbawione sensu)? Czy mają być upubliczniane, a w związku z tym wymagają „dopieszczenia”, opisów, zabezpieczenia? Czy mają być stale aktualne, a więc wymagają audytów, przeglądów, weryfikacji, utrzymania, komunikacji, szkoleń (pełny cykl PDCA)? Większość z tych decyzji pociąga za sobą wymierne koszty i obowiązki w organizacji. Mapowanie to nie tylko przyjemność, ale też wynikające z niego obowiązki.
A PO DRUGIE: MAPUJ — ALE Z GŁOWĄ!
Bardzo lubię mapować. Co nie znaczy, że robię to zawsze. Natomiast bardzo nie lubię, gdy jestem przedstawiany, jako „pan od mapowania”. Moją domeną są procesy i zarządzanie procesowe, a niektórym kojarzy to się tylko z mapowaniem (ech, te skojarzenia…). Często żeby stworzyć jedną lub kilka prostych map w sposób przydatny dla klienta, potrzeba wielu dni warsztatów, analiz, wywiadów, przemyśleń, prób. Tak, żeby na końcu to, co powstanie, było naprawdę przydatne — czy to jako podstawa do dalszego rozwoju, czy impuls do podjęcia jednej decyzji. Tak więc mapuj — jeśli trzeba, nie wyłączając przy tym myślenia i pamiętając, że mapy to tylko pewna grupa narzędzi, nie jedyna, choć często bardzo skuteczna.
Autor: Andrzej Bogusz
Artykuły tego Autora
