Można narysować poprawną mapę w BPMN 2.0 i nie usprawnić w firmie absolutnie niczego. Bramki się zgadzają, strzałki prowadzą tam, gdzie trzeba, a ludzie dalej pracują po staremu.

Na co dzień pracujemy z BPMN i widzimy, że problemy często zaczynają się jeszcze przed narysowaniem pierwszego symbolu. Mapujemy za dużo, nie ustalamy po co albo zakładamy, że gotowa mapa sama zmieni sposób pracy. Poniżej zebrałyśmy siedem błędów, przez które mapowanie staje się projektem samym w sobie, zamiast pomagać w usprawnianiu firmy — i podpowiedzi, jak ich uniknąć.

Błąd 1: Mapowanie wszystkiego

Chcesz zmapować wszystkie procesy w firmie? Sugerujemy poważnie się zastanowić.

Mapowanie jest czasochłonne, a organizacja to żywy organizm. Stosując takie podejście, uzyskamy jedynie projekt, który nigdy się nie kończy i mapy procesów, które dezaktualizują się szybciej, niż zdążą komukolwiek realnie pomóc.

Owszem, warto zrobić na początku badanie, jakie procesy w ogóle występują w naszej organizacji. Można je wylistować bez wchodzenia w szczegół. Można też zrobić prostą, wysokopoziomową mapę procesów, żeby zobrazować główne przepływy w naszej organizacji. To pozwoli zrobić rozpoznanie, które pomoże zadecydować, co dalej. Kolejne kroki i priorytety zależą od celu, jaki nam przyświeca przy chęci mapowania.

Błąd 2: Brak jasnego celu i poziomu szczegółowości

Nie mapujmy dla mapowania. Nim rozpoczniemy, odpowiedzmy sobie na pytanie – po co w ogóle mamy to robić i jak planujemy wykorzystać mapy później?

Zazwyczaj mapowanie procesów kojarzy się z ich usprawnianiem. Mapa ma nam wówczas pomóc znaleźć wąskie gardła w procesie, które później będziemy naprawiać. Jest jednak wiele innych powodów, dla których chcemy stworzyć mapę procesu, np.:

• poznanie procesu – określenie jego poziomu skomplikowania (uwierzcie nam, często dopiero po narysowaniu mapy, uczestnicy widzą proces po raz pierwszy w całości)
• ujednolicenie i standaryzacja procesu: 1 mapa = 1 sposób działania
• mapa jako baza wiedzy do wykorzystania przy szkoleniach czy wdrażaniu nowych pracowników.

W zależności od celu warto zdecydować o poziomie szczegółowości mapy – od wysokopoziomowego SIPOC po szczegółowe mapowanie procesów w notacji BPMN 2.0. Oba podejścia są poprawne, ale służą do zupełnie innych rzeczy.

Przykład: jeśli chcesz skrócić czas wystawienia faktury, potrzebujesz zobaczyć, gdzie czekamy na dane, co wraca do poprawki i jak informacje przechodzą między działami. Nie musisz przy okazji opisywać każdego kliknięcia w CRM. Poziom szczegółowości ma pomóc odpowiedzieć na konkretne pytanie, a nie udowodnić, że potrafimy narysować wielką mapę.

Błąd 3: Mapowanie „jak powinno być”, a nie „jak jest”

To jeden z tych błędów, które wynikają albo z tzw. dobrych chęci, albo ze strachu przed oceną. Często spotykałyśmy się z sytuacją, gdzie wypytywany przez nas pracownik opowiadał nam o tym, jak proces powinien wyglądać. Czasami ciężko jest to wyłapać na początku, gdy mapujemy nieznany nam proces. Ale pracownika mogą zdradzić takie sformułowania jak:

• „Raport powinniśmy wysyłać o 8:00”
• „Tę czynność wykonujemy w sposób XYZ”

A potem, jak dopytujemy o to, jak to wygląda w rzeczywistości, to okazuje się, że:

• „Ten raport rzadko udaje się wysłać o 8:00, nie ma szans, by wyrobić się tak rano – realnie wychodzi jakoś przed południem”
• „Znam te ustalenia, ale one są bez sensu i wydłużają pracę. Ja robię to po swojemu i udaje mi się to robić szybciej”

Jeśli nie jest się tego świadomym – rysuje się proces nie taki, jaki faktycznie pracownicy wykonują, ale taki, jaki powinien być według procedur. Szczególnie jeśli chcemy procesy optymalizować, to koniecznie mapujemy je „as-is”, nawet jeśli nie wygląda to elegancko. Dopiero potem przechodzimy do „to-be”, czyli projektowania docelowego procesu po zmianach. Bez tego optymalizacja stanie się poprawianiem fikcji.

Błąd 4: Brak właściciela procesu

Błędem nie jest traktowanie mapowania jako projektu. Problem pojawia się wtedy, gdy na tym projektowym podejściu kończy się odpowiedzialność za proces. Zapominamy, że później przychodzi codzienność – konieczność podejmowania decyzji procesowych oraz wdrażania i utrzymywania optymalizacji. Bez wyznaczenia osoby odpowiedzialnej proces prędzej czy później zaczyna się „rozjeżdżać”.

Właściciel procesu to osoba (czasem rolę tę pełni więcej niż jedna osoba), która odpowiada za to, żeby dany proces działał skutecznie end-to-end, był aktualny, rozwijany i realnie dowoził wartość biznesową.

Ważna podpowiedź: właścicielem procesu powinna być osoba, która chce się nim zajmować i ma realną możliwość wpływania na jego przebieg. Jeśli rola trafi do kogoś przypadkowego – zostanie zepchnięta na dalszy plan. Jeśli trafi do kogoś bez sprawczości – utknie w łańcuchu aprobat. W obu przypadkach odpowiedzialność będzie wyłącznie formalna, a proces zacznie się ponownie rozjeżdżać.

Błąd 5: Optymalizowanie wewnątrz silosów

Usprawnienia projektowane wyłącznie z perspektywy jednego działu rzadko działają w całym procesie. Zadania zazwyczaj przechodzą przez kilka zespołów, a zmiana w jednym miejscu może wydłużyć pracę gdzie indziej, zwiększyć liczbę poprawek albo przerzucić problem na kolejny etap.

Bez spojrzenia end-to-end optymalizujemy lokalnie, pogarszając globalny wynik procesu. Dobrze przygotowana mapa pozwala zobaczyć zależności między zespołami i ocenić realny wpływ zmian na cały przepływ pracy – nie tylko na jego fragment.

Przykład: wyobraź sobie, że wydajesz pieniądze na usprawnienie sprzedaży. Handlowcy przekazują dalej więcej zleceń, ich wyniki rosną, tylko reszta firmy już wcześniej nie nadążała z realizacją. Co ci po tym usprawnieniu? Zamiast większej liczby wykonanych zleceń masz dłuższą kolejkę i coraz bardziej zirytowanych klientów.

Właśnie dlatego warto zacząć od ograniczenia, które hamuje wynik całej firmy. Ten sposób myślenia rozwija Igor w tekście o tym, jak znaleźć wąskie gardła i usprawnić pracę.

Błąd 6: Brak przygotowania organizacji do mapowania

Samo narysowanie mapy procesu jest bardzo czasochłonne, ale to wcale nie jest najtrudniejszy etap mapowania. Jest nim zebranie informacji o procesie od uczestników procesu.

Dla wielu osób mapowanie procesów oznacza przyjrzenie się ich codziennej pracy, sposobowi podejmowania decyzji oraz nieformalnym „obejściom”, które powstawały przez lata. Bez przedstawienia odpowiedniego kontekstu całego przedsięwzięcia i jasnej komunikacji celu zbierania informacji łatwo uruchomić w pracownikach opór i nieufność, co przekłada się na niechęć do dzielenia się realnymi spostrzeżeniami na temat procesu.

Jeśli chcemy, żeby mapowanie przebiegło bez dodatkowych utrudnień, potrzebujemy przygotować organizację na zmianę: jasno zakomunikować cel, rolę zespołów oraz to, w jaki sposób wnioski z mapowania przełożą się na realne decyzje i usprawnienia. Dopiero gdy pracownicy poczują się bezpiecznie w zmianie, to będą skłonni do współpracy.

Lektura dodatkowa: artykuł jak wprowadzać zmiany w organizacji.

Błąd 7: Zła ewidencja map procesów

Na koniec klasyk – procesy zmapowane, ale nikt nie wie gdzie. Procesy powstają w ramach warsztatów, projektów czy inicjatyw usprawniających, a potem lądują w prezentacjach, na dyskach zespołów albo w folderach, do których dostęp ma kilka osób.

Brak jednej, wspólnej ewidencji procesów sprawia, że trudno wrócić do ustaleń, sprawdzić, która wersja procesu jest aktualna i do czego faktycznie się odnosimy w codziennej pracy. W efekcie organizacja często funkcjonuje na podstawie „wiedzy w głowach ludzi”, a nie na wspólnym, aktualnym obrazie procesów.

Jeżeli mapy nie trafiają do wspólnego repozytorium i nie są zapisane w uzgodnionym formacie, to prędzej czy później przepadają. Zostają na koncie Miro jednej osoby, w folderze projektu albo w mailu sprzed pół roku. I w momencie, gdy naprawdę są potrzebne – nikt nie wie, gdzie ich szukać.

Co zrobić? Ustal jedno wspólne miejsce przechowywania map. Przy każdej wskaż osobę odpowiedzialną za jej aktualizację, datę ostatniej zmiany i obowiązującą wersję. Stare wersje mogą zostać w archiwum, ale nikt nie powinien zgadywać, według której pracujemy.

Błędy mapowania procesów: Podsumowanie

Dobrze przeprowadzone mapowanie procesów nie polega na stworzeniu idealnego diagramu, ale na uchwyceniu rzeczywistości taką, jaka jest – nawet jeśli bywa chaotyczna. Uniknięcie tych kilku opisanych przez nas pułapek może zadecydować o tym, czy mapa procesu stanie się realnym wsparciem w podejmowaniu decyzji i optymalizacji pracy, czy jedynie kolejnym plikiem zapisanym na dysku.

Chcesz zobaczyć, jak wygląda to w praktyce? W artykule BPMN 2.0 — mapowanie procesu krok po kroku przeprowadzamy cię przez konkretny projekt: od zbierania informacji po mapę i usprawnienia.