Na jednym z projektów zapytałem trzy osoby z tego samego zespołu, jak wygląda u nich obsługa reklamacji. Kierowniczka opisała proces w sześciu krokach. Osoba z biura obsługi w dziewięciu. Magazynier powiedział: „u nas to zależy, kto ma zmianę”. Trzy osoby, jeden proces, trzy wersje.
Po to właśnie rysuje się diagram procesu: żeby te wersje zderzyć ze sobą i ustalić, co naprawdę się dzieje. W tym artykule przechodzę całą drogę od rozmowy do gotowego modelu na jednym przykładzie - reklamacji w sklepie internetowym. Ten sam warsztat zadziała przy onboardingu pracownika, obiegu faktur i każdym innym procesie.
Diagram procesu to wynik rozmowy, nie rysowania - najczęstszy błąd na start
Typowy falstart wygląda tak: otwierasz narzędzie, wybierasz symbole i rysujesz to, co wydaje Ci się, że wiesz o procesie. Po godzinie masz estetyczny diagram, który opisuje Twoje wyobrażenie. Nie rzeczywistość.
Moje proporcje z projektów: 70% pracy nad diagramem procesu biznesowego to wywiady z ludźmi, którzy w tym procesie siedzą na co dzień, a 30% to notacja. Diagram jest tylko zapisem ustaleń. Jeśli ustalenia są błędne, żadna notacja tego nie uratuje - a błędny model wygląda równie profesjonalnie jak poprawny i właśnie dlatego jest groźny.
Nasz przykład na cały artykuł: sklep internetowy, obsługa reklamacji, przyjmijmy do ćwiczenia 400 zgłoszeń miesięcznie. Klient pisze maila, że produkt jest wadliwy, i od tego momentu coś się dzieje - tylko nikt w firmie nie umie powiedzieć dokładnie co. Formalną definicję znajdziesz pod hasłem proces biznesowy w słowniku, ale robocza wystarczy: powtarzalny ciąg czynności od wyzwalacza do rezultatu.
Całe mapowanie procesów zamyka się w pięciu krokach: wywiad, szkic, model, walidacja, analiza. Po kolei.
Krok 1 - wywiad: 8 pytań, które wyciągają proces z głowy eksperta
Zasada numer jeden: rozmawiaj z osobą, która proces wykonuje, nie tylko z jego właścicielem. Kierownik zna wersję oficjalną. Wykonawca zna prawdziwą. Potrzebujesz obu.
Osiem pytań, które zadaję w tej kolejności - skopiuj i zabierz na rozmowę:
- Co uruchamia proces? Mail, telefon, formularz, zdarzenie w systemie? W naszym sklepie: mail od klienta albo formularz na stronie. Jeśli słyszysz „no, różnie”, drąż - każde „różnie” to osobny start.
- Po czym poznajecie, że sprawa jest zamknięta? Zaskakująco często pada tu cisza. Jeśli zespół nie umie wskazać końca, proces zwykle „rozmywa się” zamiast się kończyć.
- Kto bierze w tym udział i kto podejmuje decyzje? Notuj role, nie imiona. „Kasia” to dziś Kasia, za pół roku ktoś inny.
- Jak wyglądała ostatnia taka sprawa, krok po kroku? Celowo pytam o ostatnią, nie „typową”. Opowieść o wczorajszej reklamacji jest wiarygodniejsza niż uśredniona teoria.
- Gdzie sprawa czeka i na co? To pytanie robi później całą analizę. Czekanie na decyzję, na kuriera, na „aż ktoś sprawdzi w magazynie”.
- Co najczęściej idzie nie tak? I co wtedy robicie? Tu wychodzą ścieżki wyjątków, których nie ma w żadnej procedurze.
- Jakie systemy i dokumenty biorą w tym udział? Każde „przepisujemy z maila do Excela” zapisz pogrubione. Wróci w kroku 5.
- Ile takich spraw macie miesięcznie i ile trwa jedna? Bez liczb nie policzysz potem, czy zmiana się opłaca.
Jak notować? Zapisuję czasowniki dosłownie tak, jak wypowiada je rozmówca, każde „to zależy” oznaczam na marginesie, liczby trzymam w osobnej kolumnie. I celowo nie rysuję niczego podczas rozmowy - rysowanie na żywo przełącza uwagę na notację, a rozmówca zaczyna opisywać proces „pod diagram” zamiast po swojemu. Gdy proces przecina kilka działów, jeden wywiad nie wystarczy: wtedy zbieram ludzi razem, a to już technika opisana w tekście o facylitacji warsztatu wymagań.
Krok 2 - szkic: lista kroków zanim dotkniesz notacji
Z notatek wywiadu robię zwykłą listę kroków. Technika jest banalna i działa: każdy krok to czasownik + rzeczownik. Nazwa kroku ma mówić, kto ma coś zrobić i z czym.
| Źle (rzeczownik ogólny) | Dobrze (czasownik + rzeczownik) |
|---|---|
| obsługa zgłoszenia | zarejestruj zgłoszenie |
| weryfikacja | zweryfikuj dowód zakupu |
| logistyka | zamów kuriera po odbiór produktu |
| komunikacja z klientem | poinformuj klienta o rozstrzygnięciu |
Lewa kolumna to nazwy teczek, nie czynności. Za każdą z nich chowa się kilka kroków i przynajmniej jedna decyzja, a szkic ma je właśnie wyciągnąć na wierzch.
Surowy szkic naszej reklamacji, prosto z wywiadów:
- Zarejestruj zgłoszenie w systemie
- Zweryfikuj dowód zakupu (klienci przysyłają skan paragonu mailem)
- Zamów kuriera po odbiór produktu
- Przyjmij produkt w magazynie
- Sprawdź wadę (magazyn robi to partiami, raz dziennie)
- Podejmij decyzję: uznać czy odrzucić (decyduje wyłącznie kierowniczka BOK)
- Wypłać zwrot albo wyślij produkt wolny od wad
- Poinformuj klienta o rozstrzygnięciu
- Zamknij zgłoszenie
Obok listy trzymam notatki z marginesu: „to zależy” padło przy kroku 2 (co, jeśli nie ma paragonu?) i przy kroku 6 (co z reklamacjami oczywistymi, typu uszkodzona przesyłka?). Te miejsca to przyszłe bramki decyzyjne. Szkic w tej formie pokazuję rozmówcom jeszcze przed rysowaniem - poprawienie listy zajmuje minutę, poprawianie diagramu kwadrans.
Krok 3 - model: przenosimy szkic do BPMN
Do modelu używam BPMN, z prostego powodu: to standard, który przeczyta analityk, deweloper i audytor. Na naszym job boardzie BPMN pojawia się w 22% aktywnych ofert dla analityków - to najczęściej wymieniana kompetencja, przed UML i SQL. Symbole i ich znaczenie rozpisałem osobno w tekście BPMN - co to jest i jak zacząć, tutaj skupiam się na kolejności pracy. Narzędzie jest sprawą drugorzędną: darmowy draw.io w zupełności wystarczy, a pierwszą iterację często robię flamastrem na tablicy. Bo diagramu nie rysuje się od razu w całości. Buduję go w czterech iteracjach.
Iteracja 1: happy path
Jedna linia, zero decyzji: zdarzenie startowe „wpłynęło zgłoszenie”, potem kolejno zadania ze szkicu, na końcu zdarzenie końcowe „reklamacja rozpatrzona”. Wszystko idzie dobrze, klient ma rację, pieniądze wracają. Ten szkielet musi być czytelny, zanim dodasz cokolwiek więcej.
Iteracja 2: decyzje
Wracam do miejsc oznaczonych „to zależy” i wstawiam bramki decyzyjne. Każda bramka to pytanie z jednoznacznymi wyjściami: „czy jest dowód zakupu?” (nie: poproś klienta o numer zamówienia), „czy reklamacja jest zasadna?” (nie: poinformuj o odrzuceniu i zakończ osobnym zdarzeniem końcowym). Dobra praktyka od pierwszego diagramu: etykietuj każde wyjście z bramki. Diagram z nieopisanymi strzałkami czyta się jak SMS bez polskich znaków - niby się da, ale po co.
Iteracja 3: uczestnicy
Dokładam tory (lane'y): klient, biuro obsługi, magazyn, księgowość. Każde zadanie wpada do toru tego, kto je wykonuje. I tu dzieje się magia: nagle widać, ile razy sprawa przeskakuje między działami. W naszej reklamacji jest sześć takich przeskoków, a każdy przeskok to potencjalne czekanie.
Iteracja 4: wyjątki
Na końcu ścieżki smutne: klient nie odsyła produktu w 14 dni (zdarzenie czasowe, po którym zgłoszenie zamyka się bez rozpatrzenia), przesyłka przychodzi uszkodzona z winy kuriera (osobna ścieżka do przewoźnika), kierowniczka jest na urlopie i decyzje stoją. Wyjątki dodaję ostatnie, bo dodane za wcześnie zabijają czytelność szkieletu.
Moim zdaniem na start wystarczy 6-7 symboli BPMN: zdarzenie startowe i końcowe, zadanie, bramka XOR, tor, zdarzenie czasowe, przepływ. Pełna specyfikacja ma ich dziesiątki, ale 80% diagramów, które robiłem zawodowo, mieści się w tym zestawie. Lepszy prosty model, który wszyscy rozumieją, niż popis notacyjny, który czyta tylko autor.
Krok 4 - walidacja: pokaż diagram ludziom z procesu
Gotowy diagram to hipoteza. Weryfikują ją ci sami ludzie, z którymi robiłem wywiady - ale review trzeba poprowadzić, a nie wysłać diagram mailem z dopiskiem „daj znać, czy ok”. Na takiego maila każdy odpisze „ok”.
Działa jedna technika: przeczytaj ścieżkę na głos jak historię. „Klientka zgłasza wadliwy czajnik przez formularz. Zgłoszenie rejestruje się w systemie. Asia z BOK sprawdza numer zamówienia...” I patrzę na twarze. Zmarszczone brwi przy kroku 5 mówią więcej niż godzina ankiet.
Drugi trik, kontrowersyjny, ale go bronię: celowo zostawiam w diagramie jeden błąd - na przykład decyzję przypisaną do złego działu. Jeśli nikt go nie wyłapie, to znak, że nikt naprawdę nie przeczytał modelu, i taka „akceptacja” jest nic niewarta. Wolę to wiedzieć na etapie walidacji niż po wdrożeniu zmiany.
Czego słuchać podczas review? Trzy frazy to złoto: „no, niezupełnie tak”, „to zależy” i „ale Marek robi to inaczej”. Każda oznacza brakującą ścieżkę albo niespisany wariant procesu. A czego się bać? Ciszy i kiwania głowami. Walidację robię też osobno z wykonawcami i osobno z kierownikiem, bo przy szefie ludzie potwierdzają wersję oficjalną, nie prawdziwą.
Po review nanoszę poprawki od razu, tego samego dnia, i odsyłam uczestnikom wersję z datą w nazwie. Diagram bez daty i autora żyje potem latami jako „ten aktualny”, choć proces dawno odjechał. U mnie każda wersja ma datę, a stara ląduje w archiwum, nie w koszu.
Krok 5 - analiza: znajdź wąskie gardła i policz potencjał zmiany
Zwalidowany diagram stanu obecnego (as-is) to dopiero połowa wartości. Teraz szukam miejsc, gdzie sprawa czeka. W naszej reklamacji są trzy:
- Magazyn sprawdza wady partiami, raz dziennie. Paczka, która przyszła rano, czeka do jutra. Średnio doba straty na każdej sprawie.
- Każdą decyzję podejmuje jedna osoba. Kierowniczka BOK wraca do reklamacji „między spotkaniami”, typowo po dwóch dniach. Przy 400 zgłoszeniach miesięcznie to setki dni czekania, które klient odbiera jako opieszałość sklepu.
- Dowód zakupu weryfikowany ze skanu paragonu. Ręczne oglądanie załączników, choć numer zamówienia i tak jest w systemie sprzedażowym.
Teraz liczenie, bo bez liczb to tylko narzekanie na proces. Sama decyzja kierowniczki: 400 zgłoszeń razy średnio 2 dni czekania daje 800 dni oczekiwania miesięcznie po stronie klientów. Jeśli próg kwotowy zdejmie z niej choćby połowę spraw, typowa reklamacja skraca się o 2 dni bez zatrudniania kogokolwiek. Taki jeden akapit z wyliczeniem przekonuje sponsora zmiany szybciej niż najładniejszy diagram.
Z tej listy powstaje szkic stanu docelowego (to-be), rysowany obok diagramu as-is, nigdy zamiast niego - bez zachowanego stanu wyjściowego nie udowodnisz, że zmiana cokolwiek dała. W wersji to-be: reklamacje do 200 zł uznaje BOK bez kierowniczki, weryfikacja zakupu idzie automatycznie po numerze zamówienia, a magazyn oznacza sprawy reklamacyjne jako priorytet zamiast partii raz dziennie. Efekt widać na diagramie gołym okiem: krótsza ścieżka decyzyjna i dwa przeskoki między działami mniej.
Jedno zastrzeżenie: liczby w tym przykładzie przyjąłem do ćwiczenia. W realnym projekcie czasy czekania bierzesz z systemu ticketowego albo mierzysz na próbce spraw, a całe porównanie stanów opisuję szerzej w artykule o analizie procesów as-is i to-be. Samo pojęcie mapy znajdziesz też w słowniku pod hasłem mapa procesów.
Zrób to sam - wyzwanie na platformie
Teoria przeczytana, czas na Twój diagram. Zadanie: zmapuj proces zwrotu towaru w sklepie internetowym. Nie reklamacji, tylko zwykłego zwrotu konsumenckiego w 14 dni. Jest podobny do naszego case'u na tyle, że wykorzystasz cały warsztat, i różny na tyle, że nie skopiujesz rozwiązania.
Przejdź pełne pięć kroków: wywiad (wystarczy rozmowa z kimś, kto niedawno robił zwrot, albo własne doświadczenie zakupowe), szkic czasownik + rzeczownik, cztery iteracje modelu, walidacja z drugą osobą, trzy wąskie gardła z propozycją zmiany. To nie jest ćwiczenie do szuflady - polecenie „opisz albo narysuj proces zwrotu” regularnie pada na rozmowach o pracę w analizie, o czym pisałem przy okazji wejścia do zawodu bez doświadczenia.
Jeśli chcesz zrobić to zadanie z informacją zwrotną, na platformie Analify czeka 14 wyzwań praktycznych z peer review w formule double-blind: oceniasz anonimowo i jesteś oceniany anonimowo, więc feedback dotyczy diagramu, a nie osoby. Mapowanie procesów to też jeden z wcześniejszych przystanków całej ścieżki, którą rozpisałem w tekście jak zostać analitykiem biznesowym.
Chcesz najpierw sprawdzić, ile już wiesz o procesach i notacji? Zrób darmowy test wiedzy - bez zakładania konta, wynik od razu.