Cała praca jest w zamówieniach, które idą nie tak

Każdy system zamówień pokazuje na prezentacji ten sam przepływ: zamówienie wpada, zostaje opłacone, skompletowane, spakowane, wysłane i zafakturowane. Ta ścieżka jest niemal wszędzie dobrze zautomatyzowana i w dobry dzień większość zamówień przechodzi nią bez niczyjego udziału.

Teraz spójrzcie, na co naprawdę idzie dzień w dziale obsługi zamówień. Na te zamówienia prawie nic. Idzie na pozostałe: te, które stają, dzielą się, zmieniają albo wracają do życia — i które system traktuje tak, jakby nie powinny istnieć.

Jak wygląda wyjątek

Zmiana po kompletacji. Klient chce inny adres, dodatkową pozycję albo inny kolor, a paczka leży już na stole do pakowania.

Brakująca pozycja. Jednej z sześciu pozycji nie ma na półce. Czekać, wysłać pięć teraz, zaproponować zamiennik czy anulować pozycję — cztery decyzje, każda ze skutkami dla stanu, faktury i klienta.

Zamówienie, które czeka. Wstrzymane do czasu płatności, dostawy albo potwierdzenia ceny. Czekanie to stan i coś musi go zakończyć — inaczej zamówienie wisi, dopóki klient nie zadzwoni.

Duplikat. To samo zamówienie złożone dwa razy, dwoma kanałami, albo raz w sklepie internetowym i raz przez telefon, bo klient nie był pewien, czy pierwsze doszło.

Adres, który nie przechodzi. Kurier go odrzuca, paczka wraca, a zamówienie trzeba wysłać ponownie albo oddać pieniądze.

Dopisek przez telefon. Stały kontrahent dorzuca trzy pozycje do zamówienia złożonego wczoraj przez internet, a osoba, która odebrała telefon, musi zdecydować, gdzie to zapisać.

Dlaczego systemy radzą sobie z nimi źle

Modelują je jak błędy. Zamówienie jest zaprojektowane tak, żeby szło do przodu. Wszystko, co je zatrzymuje, dzieli albo cofa, staje się statusem, który ktoś wymyślił, polem uwag albo etykietą w kolorze, który coś znaczy dla jednego zespołu.

Decyzja zapada poza systemem. Czy czekać, czy dzielić, ustala się mailem albo krzykiem przez pół magazynu, a system poznaje tylko wynik. Powód ginie.

Każdy kanał ma swoją wersję. Sklep, panel marketplace i ERP mają własne pojęcie wstrzymanego czy częściowego zamówienia i żaden nie zgadza się z pozostałymi co do tego, co się właściwie stało.

Kolejka nie ma właściciela. Wyjątek, którego nie widzą wszyscy, to wyjątek czekający na zapomnienie — zwykle do chwili, gdy klient zapyta, gdzie jest jego zamówienie.

Ile to kosztuje

Najpierw czas: wyjątek zabiera minuty człowieka, a zwykłe zamówienie sekundy maszyny. Potem błędy — dostawa częściowa zafakturowana w całości, anulowana pozycja, która dalej blokuje rezerwację, zamiennik wysłany bez zgody klienta. A na końcu koszt powolny: nikt nie zapisuje, dlaczego wyjątki się zdarzają, więc te same wracają co tydzień.

Jak wygląda porządne zamodelowanie

Wyjątki jako prawdziwe stany. Wstrzymane, wysłane częściowo, czeka na zamiennik, anulowane po kompletacji. Nazwane, z jasnymi zasadami, co każdy z nich robi ze stanem magazynowym i z fakturą.

Właściciel i powód. Każdy wyjątek przypisany do konkretnej osoby, z powodem wybranym z krótkiej listy, a nie wpisywanym za każdym razem od nowa.

Pełna historia na zamówieniu. Co się zmieniło, kiedy, kto zdecydował i dlaczego. Gdy klient dzwoni, odpowiedź jest na ekranie, a nie w czyjejś skrzynce.

Jedna kolejka dla wszystkich kanałów. Otwarte wyjątki z każdego kanału w jednym miejscu, widoczne dla całego zespołu, od najstarszego.

Zasady spisane, zanim będą potrzebne. To, co robimy, gdy brakuje pozycji, jest polityką firmy, a nie decyzją podejmowaną inaczej przez każdą osobę na każdej zmianie.

Wersja mierzalna

Przez tydzień poproście dział obsługi zamówień, żeby oznaczał każde zamówienie, którego ktoś musiał dotknąć ręcznie, i zapisywał dlaczego. Na koniec tygodnia pogrupujcie powody.

Ta lista to Wasz prawdziwy proces. Schemat blokowy opisuje zamówienia, które obsługują się same; lista opisuje pracę. Większość okazuje się przewidywalna, a przewidywalne wyjątki to dokładnie te, którymi powinien zajmować się system — żeby ludzie mieli czas na te, których nikt nie przewidział.