Mapowanie procesów w firmie: przykład przed automatyzacją

Czym jest mapa procesu i gdzie wyznaczyć jej granice?

Mapowanie procesów polega na zapisaniu, jak praca przechodzi od zdarzenia początkowego do określonego wyniku. Na mapie widać czynności, osoby odpowiedzialne, potrzebne dane i decyzje zmieniające dalszy przebieg. Przed automatyzacją warto narysować jeden taki proces i przejść po nim z osobami, które wykonują tę pracę.

Zacznijcie od małego zakresu, na przykład obsługi zgłoszenia do chwili ustalenia terminu. Ustalcie, co uruchamia proces oraz po czym poznacie jego zakończenie. Wynikiem może być potwierdzony termin, ale również oczekiwanie na dane albo przekazanie wyjątku konkretnej osobie. Samo hasło „obsługa klienta” jest zbyt szerokie, żeby ustalić kolejność działań.

Mapa stanu obecnego ma odzwierciedlać rzeczywistą pracę. Najpierw zapytajcie wykonawców o jej przebieg i sprawdźcie przykładowe sprawy. Propozycje zmian zapisujcie osobno. Dzięki temu będzie wiadomo, które czynności już istnieją, a które dopiero chcecie wprowadzić.

Jakich symboli potrzebujesz na początek?

Na pierwszej mapie wystarczy kilka prostych oznaczeń. IBM wymienia między innymi prostokąty czynności, romby decyzji, strzałki kierunku oraz owalne oznaczenia początku i końca. Poniżej używamy tej podstawowej konwencji; nie jest to pełna notacja BPMN.

Przy każdej czynności dopiszcie rolę, na przykład „koordynator”, zamiast samej nazwy aplikacji. Przy decyzji nazwijcie warunek i podpiszcie obie drogi. Czytelnik powinien wiedzieć, co wydarzy się także po odpowiedzi „nie”.

• Prostokąt: czynność, np. „Sprawdź proponowany termin”.
• Romb: decyzja, np. „Czy termin jest wolny?”.
• Strzałka: kolejność przejścia do następnego kroku.
• Zaokrąglone pole: początek albo nazwany wynik, np. „Oczekuje na dane”.

Jak zrobić mapę procesu krok po kroku?

Do pracy zaproście osoby, które przyjmują sprawę, wykonują zadanie i rozstrzygają wyjątki. Możecie zacząć na kartce lub tablicy. Narzędzie do rysowania będzie potrzebne dopiero wtedy, gdy chcecie uporządkować i udostępnić uzgodniony przebieg.

• 1. Wyznaczcie początek i koniec. Zapiszcie konkretne zdarzenie wejściowe oraz dopuszczalne wyniki. Ustalcie też, czego ta mapa nie obejmuje.
• 2. Odtwórzcie dzisiejszy przebieg. Prześledźcie przykładową sprawę, łącznie z przepisywaniem danych, czekaniem, poprawkami i powrotem do wcześniejszej osoby. Nie zastępujcie go od razu wersją idealną.
• 3. Przypiszcie role i dane. Przy każdym kroku wskażcie wykonawcę, informację potrzebną do działania oraz wynik przekazywany dalej. Jeśli przy jednym kroku są dwie osoby, doprecyzujcie, kto podejmuje decyzję.
• 4. Dodajcie decyzje i wyjątki. Rozpiszcie brakujące dane, powtórzenie zgłoszenia, niedostępność zasobu i inne sytuacje rzeczywiście spotykane w tym procesie. Każda droga ma prowadzić do działania albo jawnego stanu oczekiwania.
• 5. Uzgodnijcie mapę z wykonawcami. Przejdźcie ją wspólnie od początku. Sprawdźcie pominięte czynności, kolejność oraz przekazania między rolami. Rozbieżne wersje przebiegu wymagają wyjaśnienia.
• 6. Dopiero potem zaplanujcie zmianę. Przy wybranym kroku zapiszcie problem, proponowane usprawnienie i sposób jego sprawdzenia. Jeśli chcecie oceniać czas lub koszt, ustalcie źródło pomiaru przed wdrożeniem.

Przykład mapy procesu w firmie serwisowej

Przygotowaliśmy fikcyjny serwis, w którym pracują osoba przyjmująca zgłoszenie, koordynator i technik. Przykład zaczyna się od wiadomości z propozycją terminu. Kończy się lokalnym potwierdzeniem albo jednym z jawnych wyników oczekiwania lub dołączenia wiadomości. Opisuje założony ręczny proces, a nie pracę rzeczywistego klienta.

Zapis wpływu wiadomości nie jest jeszcze nową sprawą serwisową. Sprawa powstaje dopiero po sprawdzeniu kompletu danych i powtórzenia zgłoszenia. W tym modelu powtórzenie oznacza ten sam numer zgłoszenia tego samego klienta; podobny opis problemu nie wystarcza. Rozpoznane identyfikatory i dostępny kontakt są założeniami przykładów.

Poniżej znajduje się pełne 10 kroków działania i decyzji. Numery pomagają czytać rozgałęzienia; pojedyncze zgłoszenie nie przechodzi przez wszystkie kroki. Tabelę tych kroków można pobrać z odsyłacza pod artykułem.

• 1. Przyjmujący zgłoszenie rejestruje wpływ wiadomości: numer, kontakt, opis problemu i proponowany termin. Przechodzi do kroku 2.
• 2. Przyjmujący sprawdza komplet kontaktu, opisu i proponowanego terminu. Jeśli czegoś brakuje, wybiera krok 3. Przy komplecie przechodzi do kroku 4.
• 3. Przyjmujący zapisuje braki i prosi o uzupełnienie. Wynik: „Oczekuje na dane”, z odpowiedzialnością przyjmującego. Nowa sprawa i potwierdzenie terminu jeszcze nie powstają.
• 4. Koordynator sprawdza, czy ten sam klient ma już zgłoszenie o tym numerze. Jeśli tak, wybiera krok 5; w przeciwnym razie krok 6.
• 5. Koordynator dołącza wiadomość do istniejącej sprawy. Wynik: „Wiadomość dołączona; bez nowego terminu”. Nie tworzy kolejnej sprawy.
• 6. Koordynator zakłada nową sprawę serwisową i przekazuje ją technikowi. Następny krok to 7.
• 7. Technik sprawdza proponowany termin w harmonogramie i przechodzi do decyzji w kroku 8.
• 8. Technik ustala, czy termin jest wolny. Przy braku dostępności wybiera krok 9, a przy wolnym terminie krok 10.
• 9. Koordynator przejmuje uzgodnienie innego terminu. Wynik: „Oczekuje na uzgodnienie terminu”, z odpowiedzialnością koordynatora i bez potwierdzenia wizyty.
• 10. Koordynator zapisuje ustalenie i przygotowuje potwierdzenie. Wynik tego scenariusza: „Termin potwierdzony w przykładzie”.

Jak sprawdzić mapę procesu przed automatyzacją?

Najpierw zapiszcie dane wejściowe i oczekiwany wynik każdej próby. Potem przejdźcie po strzałkach, sprawdzając warunki decyzji oraz osobę odpowiedzialną za zakończenie lub oczekiwanie. Gdy wynik jest inny, wróćcie do warunku albo brakującej czynności, zamiast poprawiać samą etykietę końcową.

Dla naszej mapy wykonaliśmy lokalną symulację czterech przejść na wymyślonych danych. Oczekiwania zapisaliśmy przed uruchomieniem. Wszystkie cztery wyniki były zgodne z oczekiwaniami; każde rozgałęzienie tej małej mapy zostało sprawdzone. Nie wysłaliśmy wiadomości, nie połączyliśmy się z kalendarzem i nie zarezerwowaliśmy wizyty.

Ta próba nie sprawdza wszystkich sytuacji serwisu. Nie obejmuje błędnego identyfikatora klienta, braku możliwości kontaktu, sprzecznych zapisów, późniejszej zmiany terminu ani dwóch równoczesnych rezerwacji. W rzeczywistej firmie trzeba rozpoznać te przypadki i dopisać właściwe reguły. Proponowany termin z wiadomości pozostaje preferencją klienta.

• Pełne dane, nowy numer i wolny termin: powstaje nowa sprawa, a koordynator przygotowuje potwierdzenie. To wynik scenariusza, nie dowód doręczenia wiadomości.
• Dostępny kontakt, ale brak opisu problemu: zapisany wpływ czeka na uzupełnienie. Przyjmujący odpowiada za zebranie danych; nowa sprawa i potwierdzenie jeszcze nie powstają.
• Numer zgłoszenia tego samego klienta już istnieje: koordynator dołącza wiadomość do fikcyjnej sprawy SP-090. Nie powstaje druga sprawa ani nowy termin.
• Pełne dane i nowy numer, ale termin zajęty: nowa sprawa czeka na uzgodnienie innego terminu. Koordynator przejmuje dalsze działanie; wizyta nie jest potwierdzona.

Co można automatyzować, a co zostawić człowiekowi?

Na tej mapie można wskazać kandydatów do kolejnej próby: przepisanie pól wiadomości do rejestru oraz sprawdzenie, czy wymagane pola są wypełnione. Kontrola obecności opisu nie potwierdza jednak, że opis jest prawdziwy lub wystarczający do wykonania usługi.

Odczyt dostępności z kalendarza wymagałby osobnej integracji, właściwych uprawnień i zabezpieczenia przed konfliktem rezerwacji. Nie sprawdzaliśmy tego w przykładzie. Uzgodnienie innego terminu, rozbieżne dane i odpowiedzialność za potwierdzenie pozostają po stronie człowieka.

Dla wybranego usprawnienia przygotujcie odrębny pilotaż i kryteria odbioru. Mapa pomaga je określić, ale sama nie dowodzi, że automatyzacja działa, skraca czas lub obniża koszty. Zasady przygotowania takiej próby opisujemy w poradniku o ocenie pilotażu AI.

Z czym przyjść na audyt procesu?

Przynieście uzgodnioną mapę, kilka niepoufnych przykładów, listę wyjątków i pytania, na które zespół nie ma jeszcze wspólnej odpowiedzi. Przy pomiarach zaznaczcie źródło, okres i braki. To pozwala rozmawiać o konkretnym przekazaniu pracy, zamiast zaczynać od wyboru narzędzia.

W AIA taki materiał może być punktem wyjścia do audytu procesu i ustalenia zakresu automatyzacji. Jeśli dopiero zbieracie informacje od zespołu, skorzystajcie również z poradnika o przygotowaniu firmy do audytu AI. Po narysowaniu mapy wróćcie do jej wykonawców i sprawdźcie, czy potrafią przeprowadzić po niej rzeczywistą sprawę.

Źródła

• IBM: metoda mapowania procesu, podstawowe symbole i weryfikacja z zespołem