Najpierw zmapuj proces: dlaczego nigdy nie powinien Pan automatyzować procesu, którego nie potrafi narysować

Niemal każda automatyzacja, która się nie udaje, zepsuła się jeszcze zanim ktokolwiek dotknął narzędzia. Właściciel pominął nudny etap — faktyczne narysowanie, jak praca przebiega dziś — i od razu przeskoczył do zakupu oprogramowania dla procesu, którego nie potrafiłby wyjaśnić nowemu pracownikowi. Efekt jest do przewidzenia: automatyzacja obsługuje tę wersję pracy, która istnieje w Pana głowie, a nie tę, która naprawdę dzieje się we wtorkowe popołudnie, gdy klient oddzwania, by zmienić zamówienie.

Przesiedziałem wiele takich rozliczeń po fakcie. Mała firma wydaje realne pieniądze na elegancką platformę, pewnie ją konfiguruje, a w ciągu miesiąca ludzie po cichu zaczynają ją omijać. Gdy zapyta Pan dlaczego, odpowiedź prawie nigdy nie brzmi „oprogramowanie było słabe.” Brzmi: „oprogramowanie nic nie wiedziało o wyjątku, z którym mamy do czynienia co tydzień.” Nikt nie spisał tego wyjątku, bo nikt nigdy nie narysował całości na papierze.

Zmapowanie procesu przed jego automatyzacją to najtańsza polisa, jaką może Pan kupić. Kosztuje popołudnie i tablicę. Wyłapuje ukryte kroki, ciche przekazania i luki typu gdzie-właściwie-zapada-ta-decyzja, które w przeciwnym razie wypłyną trzy tygodnie po starcie. To ten fragment, który każdy chce pominąć, i to właśnie on po cichu decyduje, czy projekt zadziała.

Co tak naprawdę oznacza "zmapowanie procesu"

Odrzućmy żargon. Mapowanie procesu oznacza po prostu spisanie po kolei każdego kroku, który następuje między wyzwalaczem a gotowym rezultatem — i bycie szczerym wobec chaotycznych fragmentów. Wyzwalaczem może być „wpływa nowe zapytanie”, a gotowym rezultatem „klient zapłacił, a zlecenie zostało zamknięte.” Wszystko pomiędzy to Pana mapa.

Nie rysuje Pan procesu, który chciałby mieć. Rysuje ten, który faktycznie Pan ma — as-is, a nie to-be. To rozróżnienie ma większe znaczenie niż jakakolwiek notacja czy narzędzie. Cała wartość mapowania bierze się z uchwycenia rzeczywistości, łącznie z krępującymi fragmentami: arkusz, który potrafi aktualizować tylko Maria, akceptacja, która zapada przez podejście do czyjegoś biurka, e-mail przepisywany ręcznie do systemu fakturowania.

Dobrze zrobiona mapa mieści się na jednej stronie, a ktoś z zewnątrz mógłby ją przeczytać i z grubsza zrozumieć, jak Pana firma zamienia zapytanie w pieniądze. To jest poprzeczka. Jeśli Pana mapa potrzebuje legendy i czterech kolorów, żeby była czytelna, to ją Pan przekombinował.

Dlaczego pominięcie tego kroku jest tak kosztowne

Gdy automatyzuje Pan bez mapowania, nie automatyzuje swojego procesu — automatyzuje swoje założenie o procesie. A w przepaści między tymi dwiema rzeczami znikają pieniądze. Trzy tryby awarii pojawiają się raz za razem.

Pierwszy to niewidzialny krok. Niemal zawsze istnieje zadanie tak rutynowe, że nikt o nim nie wspomina: szybkie sprawdzenie, ręczna korekta VAT, telefon, by potwierdzić adres. Nigdy nie trafia do briefu, więc nigdy nie trafia do automatyzacji, a przy pierwszej potrzebie cały przepływ się zacina.

Drugi to nieudokumentowana decyzja. Gdzieś w Pana procesie człowiek po cichu wydaje osąd — to zamówienie jest pilne, ten klient dostaje rabat, ta wycena wymaga zgody kierownika. Jeśli nie ujawni Pan, gdzie ta decyzja zapada i jaką regułę stosuje, automatyzacja albo ją zignoruje, albo zgadnie — a oba warianty są złe.

Trzeci to przekazanie-widmo. Praca przechodzi między dwiema osobami lub dwoma systemami kanałem, którego nikt nie udokumentował — przesłany e-mail, współdzielony folder, ustna informacja. Zautomatyzuje Pan obok niego, a praca po prostu wpadnie w lukę. Mapowanie to sposób, by znaleźć je, zanim one znajdą Pana.

Zanim cokolwiek narysujesz: wybierz jeden proces i jeden rezultat

Niech Pan nie próbuje mapować całej firmy. Tak samo mapowanie zamienia się w sześciomiesięczny projekt, który umiera na dysku współdzielonym. Niech Pan wybierze dokładnie jeden proces — ten, co do którego już podejrzewa, że wart jest automatyzacji — i zmapuje tylko jego, od jasnego wyzwalacza do jasnego końca.

Niech Pan zdefiniuje oba końce na głos, zanim zacznie. Gdzie ten proces się zaczyna? i Jak wygląda "gotowe"? Jeśli nie potrafi Pan nazwać obu jednym zdaniem każdy, nie jest jeszcze gotów do mapowania — próbuje Pan zmapować mgłę. "Od chwili, gdy wpłynie e-mail z zamówieniem, do chwili wysłania faktury" to proces dający się zmapować. "Nasza sprzedaż" — nie.

Jak zmapować proces, krok po kroku

Nie potrzebuje Pan do tego specjalnego oprogramowania. Karteczki na ścianie biją każde narzędzie, bo łatwo je przesuwać, a cały zespół może się wokół nich zebrać. Jeśli woli Pan cyfrowo, świetnie sprawdzi się współdzielona tablica albo nawet numerowana lista w dokumencie. Metoda liczy się znacznie bardziej niż medium.

1. 1
   Zbierz w sali właściwych ludzi

   Nie tylko właściciela. Ludzie, którzy faktycznie wykonują pracę, widzą kroki, o których istnieniu właściciel zapomniał. Jeden brakujący głos i przeoczy Pan całą gałąź procesu.
2. 2
   Najpierw zapisz wyzwalacz i rezultat

   Niech Pan umieści początek skrajnie z lewej, koniec skrajnie z prawej. Wszystko, co Pan dodaje, mieści się między tymi dwoma stałymi punktami, co powstrzymuje mapę przed rozlewaniem się.
3. 3
   Przejdź przez jeden prawdziwy przykład

   Niech Pan weźmie rzeczywisty niedawny przypadek — prawdziwe zamówienie, prawdziwe zapytanie — i opowie dokładnie, co się z nim działo, krok po kroku. Prawdziwe za każdym razem bije hipotetyczne.
4. 4
   Oznacz każde przekazanie i decyzję

   Za każdym razem, gdy praca przechodzi do innej osoby lub systemu, niech Pan to narysuje. Za każdym razem, gdy ktoś dokonuje wyboru, niech narysuje rozgałęzienie i zapisze stojącą za nim regułę. To miejsca, w których automatyzacja stoi albo upada.
5. 5
   Poluj na wyjątki

   Teraz niech Pan zapyta: kiedy to NIE idzie zwykłym torem? Zwrot, pilne zlecenie, kłopotliwy klient. Niech Pan doda częste wyjątki; rzadkie zanotuje na marginesie.
6. 6
   Oszacuj z grubsza czas każdego kroku

   Niech Pan zapisze przybliżoną liczbę minut obok każdego kroku. Szuka Pan grubych fragmentów — gdzie faktycznie znikają godziny — żeby wiedzieć, co warto zautomatyzować.

Gdy Pan skończy, powinien móc położyć palec w dowolnym miejscu mapy i powiedzieć, co się dzieje, kto to robi, ile to trwa i co może pójść nie tak. Jeśli jest krok, w którym szczera odpowiedź brzmi „nie jestem do końca pewien, jak to działa” — gratulacje, właśnie znalazł Pan najważniejszą rzecz na ścianie. Ta mgła to dokładnie to, co zepsułoby Pana automatyzację.

Czy potrzebujesz formalnej notacji?

Istnieje cały formalny język do tego, zwany BPMN, z precyzyjnymi symbolami zadań, bramek i zdarzeń. Dla dużego przedsiębiorstwa z dedykowanym zespołem procesowym jest naprawdę przydatny. Dla firmy z ośmioma osobami i jednym bolesnym procesem to przerost formy, który tylko przeszkadza. Prostokąty dla kroków, romby dla decyzji, strzałki dla przepływu — tyle notacji Panu wystarczy. Niech doskonała notacja nie powstrzyma Pana przed narysowaniem niedoskonałej mapy.

Czytanie mapy: co naprawić, zanim zautomatyzujesz

Oto fragment, który ludzie przeoczają. Mapa to nie tylko dokumentacja dla programisty — to diagnoza. Gdy proces znajdzie się na ścianie, problemy, z którymi żył Pan latami, nagle wyglądają oczywiście. Niech Pan oprze się pokusie natychmiastowej automatyzacji. Najpierw niech naprawi to, co mapa ujawnia.

Niech Pan szuka kroków, które istnieją wyłącznie z przyzwyczajenia. Zaskakująca część procesów w małych firmach to archeologia — rzeczy robione w określony sposób, bo ktoś tak to ustawił w 2017 roku i nikt od tej pory tego nie zakwestionował. Jeśli krok nie wnosi wartości, niech go Pan usunie. Zautomatyzowanie bezsensownego kroku tylko przyspiesza bezsensowny krok.

Niech Pan szuka też tej samej informacji wpisywanej więcej niż raz. Każde zdublowane wprowadzenie danych na Pana mapie to zarówno pożeracz czasu, jak i miejsce, w które wkradają się błędy — i zwykle jest najłatwiejszą, najbardziej opłacalną rzeczą do zautomatyzowania. I niech Pan szuka wąskich gardeł: pojedynczego kroku, w którym wszystko się piętrzy w oczekiwaniu na jedną osobę. Czasem rozwiązaniem nie jest tam wcale oprogramowanie, lecz zmiana reguły.

• Zbędne kroki istniejące tylko dlatego, że "zawsze tak robiliśmy" — niech je Pan usunie.
• Te same dane wpisywane ręcznie do dwóch lub więcej systemów — pierwszorzędne cele automatyzacji.
• Decyzja podejmowana przez człowieka, która w istocie podąża za stałą, spisaną regułą — tę regułę można zautomatyzować; prawdziwego osądu nie da się.
• Wąskie gardło, w którym praca czeka na jedną osobę — czasem zmiana procesu bije zmianę technologiczną.
• Przekazanie, które gubi informację — niech je Pan domknie, zanim owinie wokół niego automatyzację.

Krótki przypadek: dział zamówień, który najpierw zautomatyzował niewłaściwą rzecz

Mały hurtownik, z którym pracowaliśmy — powiedzmy regionalny dostawca sprzętu gastronomicznego, jakieś dwadzieścia osób — przyszedł do nas przekonany, że potrzebuje narzędzia AI do czytania przychodzących e-maili z zamówieniami. Zamówienia wpływały jako e-maile w wolnym tekście, ktoś przepisywał je do systemu, i to przepisywanie wydawało się oczywistą rzeczą do zautomatyzowania. Niemal podpisali się pod produktem czytającym dokumenty, zanim usiedliśmy.

Spędziliśmy jedno popołudnie na zmapowaniu rzeczywistego procesu od zamówienia do faktury na ścianie ich sali konferencyjnej. Mapa opowiadała inną historię. Owszem, przepisywanie e-maili było uciążliwe — może dziesięć minut na zamówienie. Ale dwa kroki dalej każde zamówienie zatrzymywało się na biurku jednej osoby na ręczne sprawdzenie stanu magazynu i ręczne sprawdzenie zdolności kredytowej, bo te dwa systemy nie rozmawiały ani z systemem zamówień, ani ze sobą. To tam zamówienia czekały godzinami, czasem cały dzień.

Drogi czytnik e-maili AI urwałby dziesięć minut z kroku, który nie był wąskim gardłem, podczas gdy prawdziwe opóźnienie pozostało nietknięte. Co gorsza, mapa ujawniła nieudokumentowaną regułę: zamówienia powyżej pewnej wartości zawsze wymagały telefonu potwierdzającego przed realizacją. Nikt o tym nie wspomniał, a po cichu zepsułoby to każdą naiwną automatyzację.

To, co faktycznie zbudowaliśmy, było mało efektowne i tańsze: połączenie, które automatycznie zaciągało stan magazynu i status kredytowy do ekranu zamówienia, tak że sprawdzenie stało się rzutem oka zamiast półgodzinnego objazdu, plus oznaczenie dla zamówień o wysokiej wartości, które wciąż wymagały ludzkiego telefonu. A przepisywanie e-maili? Też w końcu je zautomatyzowaliśmy — ale jako krok drugi, gdy mapa pokazała, że to mniejsza nagroda. Łączny odzyskany czas w całym dziale wyniósł poglądowo około półtora dnia tygodniowo, i niemal nic z tego nie pochodziło z rzeczy, którą pierwotnie chcieli kupić.

Zamiana gotowej mapy w plan automatyzacji

Gdy Pana mapa jest już narysowana, usprawniona i godna zaufania, automatyzacja niemal sama się definiuje. Przestaje Pan zadawać przerażające otwarte pytanie — „jak zautomatyzować naszą firmę?” — a zaczyna zadawać małe, dające się odpowiedzieć, jedno po drugim, krok po kroku.

Niech Pan przejdzie wzdłuż mapy i szczerze oznaczy każdy krok. Niektóre to czyste reguły — uruchamia się przypomnienie, dane przechodzą z A do B, aktualizuje się status. To zwykła automatyzacja: tania, niezawodna, bez AI. Kilka kroków obejmuje chaotyczny ludzki język lub osąd — odczytanie nieustrukturyzowanego e-maila, sformułowanie odpowiedzi, obsługa pytania przez telefon. Tam nowoczesne AI naprawdę zarabia na siebie. A niektóre kroki powinny celowo pozostać ludzkie, bo koszt pomyłki jest wysoki. Mapa uwidacznia te kategorie w sposób, jakiego rozmowa nigdy nie zapewni.

Niech Pan zwróci uwagę, co z tego wynika. Nie musi Pan automatyzować całej mapy naraz — i nie powinien. Niech Pan wybierze najbardziej wartościowy krok oparty na regułach, zautomatyzuje tylko jego, udowodni, że działa w prawdziwym tygodniu, i dopiero potem przejdzie do następnego. To mapa pozwala rozsądnie ułożyć kolejność, zamiast porywać się na całość i się zakrztusić.

Częste pytania