W firmie, która urosła, nikt nie zna całego przebiegu sprawy. Osoba od sprzedaży wie, co się dzieje do wysłania oferty. Osoba od realizacji wie, co dostaje i co z tym robi. Księgowość widzi sam koniec. Każdy zna swój odcinek i każdy jest przekonany, że jego odcinek działa dobrze, bo z jego miejsca faktycznie działa.
Mapowanie procesów to sposób, żeby te odcinki zobaczyć obok siebie, na jednym obrazku, w kolejności, w jakiej naprawdę następują. Tyle. Cała reszta, czyli notacje, programy i dwudniowe warsztaty, jest nadbudową nad tym jednym pomysłem.
Poniżej: pięć symboli, które wystarczą, przepis na jedno spotkanie i uczciwa lista tego, czego z gotowej mapy nie odczytasz, mimo że poradniki obiecują inaczej.
Czym jest mapowanie procesów, a czym nie jest
Mapowanie procesów to rozrysowanie jednego przebiegu pracy od zdarzenia, które go uruchamia, do rezultatu, którym się kończy, z zaznaczeniem, kto wykonuje który krok. Zdarzeniem może być zapytanie od klienta, reklamacja albo przyjęte zamówienie. Rezultatem: wysłana oferta, zamknięte zgłoszenie, wystawiona faktura.
Najważniejsza różnica w całym temacie jest taka: procedura opisuje, jak ma być, a mapa rysuje, jak jest. Te dwie rzeczy zwykle się nie pokrywają i to właśnie różnica między nimi jest materiałem do pracy. Gdy mapa zgadza się z procedurą co do kroku, warto sprawdzić, z czego ją narysowano: z pracy czy z dokumentu.
Sprawdzian jest prosty. Pokaż mapę osobie, która wykonuje te kroki na co dzień. Jeżeli powie, że tak to wygląda na papierze, masz procedurę. Jeżeli zacznie dopowiadać wyjątki, masz mapę, a te wyjątki są w niej najciekawsze. Szerszy kontekst opisuje tekst o zarządzaniu procesami w małej firmie.
Pięć symboli, które wystarczą
Najczęstszy powód, dla którego mapowanie nie wychodzi za pierwszym razem, to przekonanie, że trzeba się najpierw nauczyć notacji. Notacja istnieje i jest porządna. BPMN rozwija organizacja OMG, obowiązująca formalnie wersja to 2.0.2, a jej wcześniejsze wydanie 2.0.1 zostało przyjęte jako norma ISO/IEC 19510:2013. Kłopot w tym, że pełna specyfikacja jest ogromna: opracowania liczące jej elementy podają od około osiemdziesięciu pięciu do blisko stu konstrukcji, zależnie od sposobu liczenia.
Sama specyfikacja przewiduje wyjście z tego. Definiuje ograniczoną podklasę zgodności, opisową, pomyślaną dla osób z biznesu, bliższą zwykłemu schematowi blokowemu niż pełnej notacji. Innymi słowy: autorzy standardu sami założyli, że większość ludzi nie będzie używać całości. Pięć symboli poniżej nie jest oficjalną listą przepisaną z normy, tylko wyborem praktycznym, ale mieści się w tym, co standard dopuszcza na poziomie opisowym.
Do mapy procesu w małej firmie wystarczy pięć rzeczy:
- Zdarzenie, czyli start i koniec. Dwa kółka, po jednym na każdym końcu mapy.
- Czynność, czyli prostokąt z czasownikiem: sprawdza kompletność, przygotowuje wycenę, dzwoni do klienta.
- Decyzja, czyli romb z pytaniem, na które da się odpowiedzieć tak albo nie, i z dwiema podpisanymi strzałkami.
- Strzałka, czyli kolejność. Mówi, co jest po czym, a nie ile to trwa: między dwoma prostokątami mogą minąć trzy dni.
- Tor, czyli poziomy pas z nazwą roli. Każda czynność leży w torze tego, kto ją wykonuje.
Tory nie są wymysłem nowym ani związanym wyłącznie z BPMN. Diagram międzyfunkcyjny, w którym praca przechodzi między pasami odpowiedzialności, przypisuje się Geary’emu Rummlerowi i Alanowi Brache’owi, autorom wydanej w 1990 roku książki Improving Performance. To z ich obserwacji wyrosła cała reszta: najwięcej gubi się nie wewnątrz działów, tylko w przestrzeni między nimi. Dlatego tory nie są ozdobnikiem mapy: to one pokazują, w którym miejscu praca przechodzi z rąk do rąk.
Jest też argument za trzymaniem mapy w ryzach. Mendling, Reijers i Cardoso w pracy przedstawionej na konferencji BPM w 2007 roku badali, co decyduje o zrozumiałości modelu procesu, i wskazali liczbę połączeń między elementami jako czynnik o istotnym wpływie. Nie liczbę pudełek, tylko liczbę linii między nimi. Praktyczny wniosek: gdy mapa robi się nieczytelna, prostuj przebieg, zamiast dokładać symboli.
Zanim narysujesz pierwszy prostokąt
Mapowanie wykłada się częściej na materiale niż na technice. Potrzebujesz trzech rzeczy naraz.
Pierwsza to jedna konkretna sprawa z ostatnich dni, z nazwiskiem klienta i datami, a nie sprawa typowa. Typowa sprawa jest uśrednieniem, którego nikt nie potrafi zakwestionować, bo nie wydarzyła się nigdy. Druga to osoby, które te kroki naprawdę wykonują, wszystkie, łącznie z tą, która tylko przeklikuje coś w systemie, plus osoba mająca prawo zmienić zasadę. Nikt poza tym gronem nie jest potrzebny. Trzecia to jedno spotkanie bez telefonów. Przy pierwszym procesie zarezerwuj więcej czasu, niż wydaje się potrzebne: najdłużej trwa nie rysowanie, tylko dogadanie się, jak jest naprawdę.
Jeżeli nie masz pierwszej z tych rzeczy, nie zaczynaj. Reszta jest do nadrobienia w trakcie, ta nie.
Jak rozrysować proces krok po kroku
- Ustal granice. Zapisz jednym zdaniem, co uruchamia proces, i jednym, co go kończy. Na przykład: zaczyna się, gdy zapytanie trafia na wspólną skrzynkę, kończy się, gdy klient dostaje wycenę. Dopóki tego nie ma, dyskusja rozjeżdża się na całą firmę.
- Wypisz czynności z tej jednej sprawy. Po jednej na karteczkę, czasownikiem, bez oceniania, czy krok jest potrzebny. Ocenianie w tym momencie kasuje najciekawsze kroki, te, których nikt nie umie uzasadnić.
- Ułóż je w kolejności i połącz strzałkami. Tam, gdzie ktoś musiał wybrać, wstaw romb i nazwij warunek. Jeżeli nikt nie umie nazwać warunku, zapisz to na mapie, bo właśnie znalazłeś decyzję bez kryterium.
- Dołóż tory. Przy każdej czynności rola, nie dział. Dział nie odbiera telefonu i nie odpowiada na maila.
- Przejdź mapę na głos z osobą, która wykonuje te kroki, i poprawiaj do chwili, w której zacznie dopowiadać wyjątki zamiast prostować kolejność.
Tak wygląda to samo na jednym przykładzie. Zapytanie wpada na wspólną skrzynkę (zdarzenie). Ktoś je otwiera i sprawdza, czego dotyczy (czynność, tor: obsługa). Pyta, czy klient podał wszystkie dane (romb): jeżeli nie, wraca do klienta i sprawa czeka; jeżeli tak, idzie dalej. Osoba techniczna wycenia (czynność, tor: technika). Ktoś z obsługi składa i wysyła wycenę (czynność, tor: obsługa). Koniec. Siedem elementów, dwa tory, dwa przekazania i jedno miejsce, w którym sprawa potrafi stać trzy dni, i to widać na rysunku, zanim ktokolwiek zacznie się spierać.
Kartka i ołówek w zupełności wystarczą, byle kartka była duża. Program przyda się dopiero wtedy, gdy mapa ma być czytana przez kogoś, kogo nie było w pokoju, i to on wtedy pilnuje notacji za Ciebie.
Co widać na gotowej mapie
Pierwsza rzecz to przekazania, czyli strzałki przecinające granicę torów. Każda z nich kosztuje: ktoś musi przekazać kontekst, ktoś inny go odtworzyć. Policz je. Liczba przekazań jest jedyną wielkością, którą z mapy odczytasz bez żadnego dodatkowego pomiaru.
Druga to miejsca, w których sprawa leży. Strzałka nie pokazuje czekania, więc czekanie trzeba dopisać ręcznie, słowem, przy strzałce. Zwykle okazuje się, że to nie czynności zajmują tydzień, tylko przerwy między nimi.
Trzecia to dublowanie: ta sama informacja wpisywana drugi raz w innym miejscu, bo tak jest szybciej niż szukać. To osobny, dobrze opisany koszt, o którym mówi tekst o ręcznej, powtarzalnej pracy.
Czwarta to romby bez kryterium, czyli decyzje, które za każdym razem wymagają pytania kogoś wyżej. Na mapie wyglądają niewinnie, w praktyce to one zatrzymują sprawy, a przy okazji rozmywają odpowiedzialność, co opisuje wpis o tym, dlaczego sprawy wiszą.
Czego na mapie nie ma, a co wielu ludzi spodziewa się zobaczyć: wąskiego gardła. Wąskie gardło jest pojęciem o wydajności, więc żeby je wskazać, trzeba dopisać do kroków czas albo liczbę spraw na dzień. Bez tego wskazujesz palcem miejsce, które wygląda na zatłoczone. O tym, czym ograniczenie jest naprawdę, mówi tekst o wąskim gardle i teorii ograniczeń, a metodę, która od początku dopisuje do mapy czasy i wartość dodaną, opisuje wpis o mapowaniu strumienia wartości.
Czego mapa nie pokaże, i po co mimo to ją rysować
Po polskich blogach krążą liczby mówiące, ile procent czasu firma oszczędza dzięki mapowaniu procesów. Sprawdzenie ich kończy się zawsze tak samo: trafia się na kolejny artykuł, który podaje tę samą liczbę bez źródła. Nie udało się dotrzeć do badania ani raportu z opisaną metodą pomiaru, który by którąkolwiek z nich potwierdzał. Nie ma więc podstaw, żeby obiecywać tu procenty, i nie będzie ich w tym tekście.
Powód widać w samej metodzie. Mapa nie mierzy, tylko układa: pokazuje kolejność i odpowiedzialność, nie koszt. Dopóki nie dopiszesz do kroków czasów, wniosek o tym, gdzie tracisz najwięcej, pozostaje domysłem, tyle że narysowanym i przez to bardziej przekonującym, niż zasługuje. Czy usunięcie kroku pomogło, rozstrzyga pomiar po zmianie, nie rysunek przed nią.
Zostaje jednak coś, czego żadna procedura nie daje, a co w zupełności uzasadnia poświęcone na to spotkanie: mapa jest najtańszym znanym sposobem, żeby kilka osób zaczęło mówić o tym samym przebiegu. Spór o to, gdzie sprawy się zatrzymują, może po niej przestać być sporem o wrażenia i stać się rozmową nad jednym obrazkiem, w którą da się wejść palcem. To wystarczający powód, żeby ją zrobić, i uczciwa granica tego, co obiecuje.
Cztery błędy, które unieważniają mapę
Mapa taka, jak ma być. Powstaje, gdy rysuje ją osoba zarządzająca bez ludzi wykonujących kroki. Wychodzi z tego ładny diagram procedury i zero informacji. Poznasz go po tym, że nie ma na nim ani jednego kroku, który kogoś zawstydza.
Mapa całej firmy naraz. Ambitna, nieczytelna i nieskończona. Jeden proces, od jednego zdarzenia do jednego rezultatu, jest jednostką, która domyka się na jednym spotkaniu. Pozostałe procesy zaczekają.
Mapa bez kogoś, kto może zmienić zasadę. Warsztat, w którym nie było nikogo z prawem decyzji, kończy się listą postulatów. Kilka tygodni później wszyscy pracują po staremu i mają uzasadnione poczucie, że stracili popołudnie.
Mapa, do której nikt nie wraca. Proces zmienia się co kilka miesięcy, a mapa nie. Po roku wisi na ścianie dokument opisujący firmę, która już tak nie pracuje, i to on podważa sens metody w oczach zespołu. O tym, jak drobne usterki w przebiegu narastają w koszt, mówi wpis o błędach w procesie obsługi klienta.
Tydzień po warsztacie
Z mapy wybierz jedną zmianę, najlepiej usunięcie jednego przekazania, bo to jedyna wielkość, którą potrafisz odczytać od ręki. Zapisz, co się zmienia, od kiedy i dla kogo.
Domykać ma jedna osoba z imienia, mająca prawo zmienić albo odwołać zasadę: zwykle właściciel firmy albo kierownik tego zespołu. Nie autor pomysłu, jeżeli nie ma wpływu na pracę innych, bo wtedy zmiana stoi na uprzejmości kolegów i znika przy pierwszym gorętszym tygodniu.
Ustal datę, w której spojrzysz na to ponownie, i wtedy przejdź mapę jeszcze raz, na nowej, prawdziwej sprawie. Jeżeli zmiana się utrzymała, drugi obieg jest tani, bo rysujesz różnicę, nie całość. To już jest zwykły cykl usprawnień, opisany we wpisie o PDCA i cyklu Deminga.
Kuszące jest pójść od razu dalej i zautomatyzować to, co na mapie wygląda mechanicznie. Rzecz nie w tym, żeby nie automatyzować, tylko w kolejności: najpierw usunąć krok, potem uprościć, a dopiero na końcu automatyzować to, co zostało, bo automatyzacja zamraża przebieg w takiej postaci, w jakiej go zastanie. Co się do tego nadaje, a co nie, rozbiera wpis o automatyzacji procesów i oszczędności czasu. Jeżeli mapa pokazała, że sprawy gubią się przy przekazaniach, kolejnym krokiem bywa przeniesienie ich tam, gdzie sprawa ma jednego właściciela i widoczny stan, czyli do systemu zgłoszeń takiego jak ProFlow.
Mapa procesu nie jest dokumentem i nie o to w niej chodzi. Jest uzgodnieniem z jednego spotkania, jak naprawdę pracujecie, zapisanym w postaci, którą da się zakwestionować palcem. Procedury tego nie potrafią, i to jest cała przewaga kartki z pięcioma symbolami.