Mapowanie 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…?

Rozpoczyna się pierwsze spotkanie biznesowe na poziomie senior/top managementu o zakresie 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 dojść do właściwego pytania, tyle że zadanego w pewnej łagodzącej otoczce. Pytanie brzmi: „Po co?”.

W odpowiedzi słyszę zazwyczaj, ż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. Jeśli taka zmiana 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

Mapa 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 w produkt procesu.

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 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 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);
• powstających danych i dokumentów — Makigami lub rozbudowane notacje typu BPNM na bazie swimlane;
• relacji ilościowych i czasowych przetwarzania w procesie — rozbudowa na bazie VSM lub swimlane;
• 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 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ł — obszarów potencjalnej optymalizacji,
• standaryzacja działań (mapa jako podstawa procedur),
• materiał szkoleniowy dla nowych pracowników,
• narzędzie ładu korporacyjnego,
• sprzedaż (efekt „łoł”).

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 (o czym mówi TOC – Theory of Constraints, czyli teoria ograniczeń) nie jest cały proces, ale jego bardzo mały wycinek i oczywistym jest, że dopóki np. nasz system IT nie zwiększy przepustowości ponad określoną liczbę zapytań, to więcej nie wyciśniemy. A najlepszy proces nie rozwiąże problemów złych relacji międzydziałowych i braków kompetencyjnych (nie znajdziemy 15 kierowców Formuły1 w małej miejscowości).

A jeśli już mapować…

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.

… to warto zwrócić uwagę na dwa istotne aspekty ryzyka z tym związanego. Przede wszystkim: kto jest klientem i/lub właścicielem (to mogą być różne osoby!) tego mapowania. Czyli kto określa odpowiedź na wcześniejsze pytanie „po co” oraz kto na końcu odpowie na pytanie, czy podjęte działania mapowania były skuteczne, czy przyniosły korzyść. 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 jest 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. 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.

Chcesz skomentować, podyskutować lub nawiązać kontakt z autorem? Napisz: andrzej.bogusz@abconsult.pl

Czytaj też: Czy klient jest z Księżyca, a proces z innej galaktyki? >>>

dr Andrzej Bogusz 

Manager i konsultant z szerokim doświadczeniem (bankowość, informatyka, konsulting). Ekspert z zakresu zarządzania i optymalizacji procesów biznesowych, zarządzania projektami, bezpieczeństwa teleinformatycznego, zarządzania ryzykiem. Szef projektów zmian organizacyjnych i projektów informatycznych. Właściciel firmy AB CONSULT, zajmującej się doradztwem operacyjnym i strategicznym.