Najpierw zobacz pracę taką, jaka jest
Instrukcja może nakazywać wpisywanie wszystkich danych zamówienia do jednego systemu. W praktyce pracownik prowadzi drugą listę, bo w programie brakuje potrzebnego pola. Pilne wyjaśnienia mogą odbywać się przez telefon, choć procedura przewiduje e-mail. Takie obejścia nie oznaczają automatycznie, że ktoś źle wykonuje swoje obowiązki. Mogą wskazywać, gdzie oficjalny sposób postępowania nie odpowiada potrzebom codziennej pracy. Zapisz osobno drogę opisaną w dokumentacji i drogę rzeczywiście zaobserwowaną. Jeśli w miejsce faktów niepostrzeżenie wstawisz to, co powinno było się wydarzyć, otrzymasz obraz stanu pożądanego, a nie obecnego. Porozmawiaj z osobami wykonującymi zadania i, kiedy to możliwe, przyjrzyj się konkretnemu przypadkowi.
Fikcyjny przykład z obsługi zamówień
Wyobraź sobie zakład produkcyjny zatrudniający dwadzieścia osób. Firma chce zdigitalizować obsługę zleceń. Zanim wybierze program, zespół przygląda się kilku odpowiednim zamówieniom. Kto jako pierwszy wpisuje zamówienie? Jakich danych brakuje, gdy sprawa dociera do produkcji? Gdzie pojawiają się dodatkowe pytania lub oczekiwanie? W hipotetycznym przypadku zgoda na wykonanie jest udzielana telefonicznie, a później nie wiadomo, która wersja rysunku obowiązuje. Może się przy tym okazać, że część czynności jest zbędna albo można ją inaczej zorganizować niezależnie od przyszłego systemu. To wymyślona sytuacja, a nie opis prawdziwego klienta czy obietnica oszczędności. Pokazuje, jakie pytania warto zadać przed decyzją o zakupie oprogramowania.
Wyznacz granice badanego przebiegu
Wybierz jeden powtarzalny rodzaj sprawy zamiast opisywać od razu całą firmę. Początkiem może być potwierdzone zamówienie, a końcem przekazanie zaakceptowanej specyfikacji do produkcji. Jeśli ważne poprawki powstają tuż po tym przekazaniu, poszerz zakres. Zapisz, co pozostaje poza mapą i dla kogo jej wynik ma być użyteczny. Dział sprzedaży, produkcja i klient mogą inaczej rozumieć zakończoną sprawę. Workflow reklamacji może należeć do tego samego procesu albo wymagać osobnej mapy; to zależy od pytania, na które chcesz odpowiedzieć. APQC zaleca, by przed opracowaniem szczegółowego schematu wyjaśnić cel, granice, uczestników oraz dane wejściowe i rezultaty. Mapa obejmująca wszystko bywa zbyt rozległa, żeby pomóc w jednej konkretnej decyzji.
Śledź informacje i odpowiedzialność przy przekazaniach
Przy każdym ważnym etapie odnotuj informacje wejściowe, czynność, decyzję i to, co faktycznie otrzymuje następna osoba. Który dokument przedstawia zatwierdzoną wersję? Gdzie jest przechowywany i skąd druga osoba wie, że może z niego korzystać? Informacja może istnieć, lecz trudno ustalić, czy jest aktualna. Zapytaj, kto rozstrzyga sprzeczne dane, zamiast zakładać, że decyduje osoba przesyłająca plik. Jeśli zmierzysz czas oczekiwania, zapisz czas i przypadek; jeśli ktoś szacuje go z pamięci, oznacz to jako szacunek. Zaznacz również powroty do wcześniejszych etapów i wyjątki. Na początek często wystarczy kartka papieru lub zwykła tabela. Ważniejsze od formatu jest to, czy uczestnicy rozpoznają opisany przebieg pracy.
Oddziel to, co zaobserwowane, od wyjaśnienia
„Przy dwóch przekazaniach zabrakło zatwierdzonego rysunku” może być obserwacją, jeśli sprawdzono te sytuacje. „Pracownicy są nieuważni” jest już interpretacją, a „potrzebujemy nowej platformy” pomysłem na rozwiązanie. Nie zapisuj tych zdań na mapie jako jednakowo pewnych faktów. Może plik trafił do innego katalogu, może zmieniono go po zatwierdzeniu, a może nie było jasne, kto ma wydać zgodę. Przyjrzyj się zamówieniom, zanim uznasz jedno wyjaśnienie za prawdziwe. Jeden nietypowy przypadek nie dowodzi, że wszystkie przekazania zawodzą. Porównaj problematyczne sprawy z takimi, które przeszły bez pytań: czym różniły się informacje i osoby? Zachowaj również fakty, które nie pasują do pierwszej hipotezy.
Mała karta, z której możesz od razu skorzystać
Na górze zapisz jedno pytanie, na przykład: „Dlaczego produkcja czasem nie ma zatwierdzonej specyfikacji?” Wypełnij tę samą krótką kartę dla dwóch lub trzech odpowiednio wybranych zleceń. Zaznacz, czy informacja pochodzi z obserwacji, dokumentu czy wspomnienia rozmówcy. Jeśli dwie osoby różnie opisują ten sam krok, pozostaw obie wersje, aż zrozumiesz rozbieżność. To pomoc robocza, a nie obowiązująca norma ani zamiennik formalnych wymagań w szczególnie regulowanym procesie. Kartę powinna móc przeczytać osoba uczestnicząca w pracy bez wcześniejszego podsuwania jej twojej ulubionej odpowiedzi. Pomiń pola, które nie pomagają wyjaśnić wybranego pytania.
- Początek i koniec: co uruchamia sprawę i kiedy rezultat nadaje się do wykorzystania przez następną osobę?
- Czynność i odpowiedzialność: co dzieje się naprawdę, kto wykonuje pracę i kto decyduje przy wyjątku?
- Dane wejściowe i wynik: jakiej informacji potrzeba, co jest przekazywane i która wersja obowiązuje?
- Dowód i pytanie: co sprawdzono, co pozostaje przypuszczeniem i co wyjaśni kolejny przypadek?
Korzystaj z mapy bez pośpiesznej decyzji
Porównaj wypełnione karty. Czy pytania powtarzają się przy tym samym przekazaniu? Czy konkretna informacja stale dociera za późno, a może występuje pod inną nazwą? Małą próbą może być oznaczanie zatwierdzonego rysunku w uzgodnionym miejscu przy kilku nowych zamówieniach i wspólne sprawdzenie przekazania. To możliwa optymalizacja procesu, nie uniwersalna recepta. Zwróć uwagę, czy rozwiązanie nie przenosi dodatkowej pracy do innego działu. Jeśli przyczyna nadal nie jest jasna, dalsza obserwacja też może być dobrym wynikiem. Kiedy potrzeba stanie się bardziej zrozumiała, przejdź do analizy wymagań i porównaj możliwe korzyści, koszty oraz ryzyka cyfryzacji. Nie nazywaj funkcji programu wymaganiem, zanim ustalisz, jakich informacji potrzebują ludzie.
Sprawdź mapę i aktualizuj ją we właściwym momencie
Mapa jest obrazem określonego stanu, a nie wiecznym dowodem. Różne zmiany, rodzaje zamówień lub okresy większego obciążenia mogą przebiegać inaczej. Zapisz okres i typy spraw, które obejrzałeś. Poproś osoby wykonujące pracę o poprawienie opisu, zwłaszcza przy przekazaniach między zespołami. Zgoda podczas spotkania nie zastępuje sprawdzenia kolejnego rzeczywistego przypadku. Gdy zmieniają się role lub potrzeby, aktualizuj dokument albo oznacz go jako archiwalny, aby nikt nie uznał go za aktualną instrukcję. Zarządzanie procesami może uczynić z tego przeglądu regularne zadanie. Dla pojedynczej decyzji krótka mapa z wyraźnie podanymi ograniczeniami bywa użyteczniejsza niż rozbudowany model. Wynikiem może być po prostu trafniejsze pytanie i jasny zapis obserwacji.
Częste pytania
Czy do mapowania procesu potrzebuję specjalnego programu?
Nie. Przy niewielkim procesie wystarczy kartka, tabela lub prosty rysunek. Liczy się to, czy zaangażowane osoby rozpoznają swoją pracę, mogą poprawić opis i dostrzegają niewyjaśnione miejsca. Specjalistyczne narzędzie może pomóc później przy wielu wersjach lub lokalizacjach, ale nie zastąpi obserwacji.
Czy mapowanie procesu jest tym samym co jego optymalizacja?
Nie. Najpierw opisujesz obecną pracę, wyjątki i niepewność. Na tej podstawie możesz wybrać zmianę do sprawdzenia, lecz mapa sama nie dowodzi, że przyniesie ona poprawę. Czasem pokazuje, że brakuje informacji i rozsądniej obejrzeć jeszcze kilka przypadków niż od razu rozpoczynać projekt.