Kategoria: mapowanie procesów

  • Jak opisać proces, żeby ktoś inny faktycznie go wykonał

    Typowa firmowa instrukcja wygląda tak: „Wprowadź fakturę do systemu i oznacz odpowiednim
    kodem projektu”. Autor wie, co znaczy „odpowiedni”. Czytelnik nie wie i albo pyta, albo
    zgaduje. Jedno i drugie oznacza, że instrukcja nie zadziałała.

    Różnica między opisem, który działa, a takim który nie działa, sprowadza się do jednej
    rzeczy: czy da się go wykonać, nie znając kontekstu.

    Test pierwszego dnia

    Zanim uznasz instrukcję za gotową, wyobraź sobie, że wykonuje ją ktoś, kto jest w firmie
    trzeci dzień. Nie wie, kto jest kim. Nie wie, gdzie leżą pliki. Nie wie, co robić, gdy coś
    wygląda nietypowo.

    Każde miejsce, w którym taka osoba musiałaby kogoś zapytać, to luka. Nie trzeba ich
    wszystkich zasypywać od razu, ale trzeba je zobaczyć.

    Struktura, która się sprawdza

    Kolejność poniżej nie jest przypadkowa. Człowiek czytający instrukcję w trakcie pracy
    przeskakuje do kroków – dlatego wszystko, co musi wiedzieć wcześniej, ma być nad nimi
    i ma być krótkie.

    1. Kiedy to robimy. Konkretny wyzwalacz: „w każdy poniedziałek do 10:00”,
      „gdy klient przysyła zamówienie mailem”. Nie „regularnie”.
    2. Czego potrzebujesz. Dostępy, pliki, uprawnienia – wypisane z nazwy.
      To ta lista decyduje, czy ktoś zacznie, czy odłoży na później.
    3. Kroki. Jeden krok to jedna czynność. Jeśli w kroku jest „i”, to prawie
      zawsze są to dwa kroki.
    4. Skąd wiadomo, że wyszło. Widoczny efekt: status się zmienił, mail
      poszedł, plik jest w katalogu. Bez tego nikt nie wie, czy skończył.
    5. Co robić, gdy coś nie pasuje. Do kogo iść i w jakiej sytuacji.

    Szablon do skopiowania

    Nazwa procesu: [czasownik + rzeczownik, np. „Rozliczenie faktur kosztowych”]

    Właściciel: [stanowisko, nie imię – imiona się zmieniają]
    Ostatnia aktualizacja: [data]

    Kiedy: [konkretny wyzwalacz]

    Potrzebujesz: [dostępy, pliki, uprawnienia]

    Kroki:
    1. [czynność] → [widoczny efekt]
    2. [czynność] → [widoczny efekt]

    Gotowe, gdy: [stan końcowy, który da się sprawdzić]

    Gdy coś nie pasuje: [do kogo i kiedy]

    Trzy błędy, które psują dobre instrukcje

    Opisywanie wyjątków w głównym ciągu. Instrukcja rozrasta się do trzech
    stron, bo autor wpisał wszystkie „chyba że”. Główna ścieżka ma opisywać przypadek typowy.
    Wyjątki idą na koniec, pod osobnym nagłówkiem.

    Odsyłanie do wiedzy, której czytelnik nie ma. „Postępuj zgodnie
    z przyjętą praktyką” to nie jest krok. Jeśli praktyka jest przyjęta, ale nigdzie nie
    zapisana, to właśnie ją trzeba opisać.

    Brak daty i właściciela. Instrukcja bez daty jest nie do odróżnienia od
    nieaktualnej. Po roku nikt nie wie, czy opisuje stan obecny, i wszyscy wolą zapytać kolegę.

    Jak sprawdzić, czy działa

    Jedyny wiarygodny test: daj instrukcję komuś, kto procesu nie zna, i patrz, jak wykonuje,
    bez podpowiadania. Zapisuj każde miejsce, w którym się zatrzymał. To są dokładnie te miejsca
    do poprawienia – nie te, które Tobie wydawały się trudne.

    Jedno takie przejście daje więcej niż godzina poprawiania tekstu przy biurku.

    Od czego zacząć

    Nie opisuj wszystkiego. Zacznij od procesu, który spełnia dwa warunki naraz: powtarza się
    często i tylko jedna osoba umie go wykonać. To jest miejsce, gdzie opis zwraca się
    najszybciej – bo zdejmuje wąskie gardło, a nie tylko porządkuje dokumentację.