Na przełomie lutego i marca 2025 roku kontrolerzy amerykańskiej poczty odwiedzili 21 placówek doręczeniowych. W 20 z nich znaleźli łącznie 133 863 opóźnione przesyłki. Tymczasem placówki wykazały w systemie raportowym tylko 37 392, czyli około 28% stwierdzonej liczby. Dziesięć jednostek nie zgłosiło żadnych zaległości, choć kontrolerzy je znaleźli.

W raporcie opublikowanym w sierpniu 2025 roku audytorzy wskazali konsekwencję: jeśli lokalne placówki nie zgłaszają opóźnień, kierownictwo wyższego szczebla zakłada, że takich opóźnień nie ma. Głównym problemem było nieprzestrzeganie procedur ręcznego raportowania. Kontrola obejmowała wybrane, wcześniej audytowane placówki, więc jej wyników nie można odnosić do całej sieci pocztowej.

Ten przypadek nie dowodzi, że ktoś podjął błędną decyzję. Pokazuje natomiast, jak bardzo obraz sytuacji dostępny dla kierownictwa może odbiegać od tego, co dzieje się w operacjach.

W firmie konsekwencją podobnej rozbieżności może być choćby potwierdzenie klientowi terminu, którego nie da się dotrzymać, lub zbyt późna reakcja na problem z dostępnością zasobów. Zanim uznamy, że zawiódł pracownik albo system, warto sprawdzić, jakie informacje były dostępne w chwili podejmowania decyzji.

Kiedy warto to sprawdzić?

Nie każda nieaktualna informacja oznacza problem wymagający inwestycji. Raport odświeżany raz dziennie może wystarczyć do planowania pracy na kolejny tydzień. Nie wystarczy jednak do decyzji, którą trzeba podjąć w ciągu godziny, jeśli w międzyczasie sytuacja może się istotnie zmienić.

Sygnałem ostrzegawczym jest sytuacja, w której kierownictwo dowiaduje się o problemie dopiero od klienta, po zmianie planu albo podczas wyjaśniania, dlaczego nie dotrzymano terminu. Warto się jej przyjrzeć także wtedy, gdy po fakcie nikt nie potrafi ustalić, na jakich danych oparto decyzję.

Nie warto zaczynać od sprawdzania wszystkich raportów. Lepiej wybrać decyzję, w której łączą się trzy warunki: pomyłka może być kosztowna, sytuacja zmienia się szybko, a wcześniejsza informacja pozwoliłaby jeszcze zareagować. Jeżeli nawet natychmiastowe powiadomienie niczego by nie zmieniło, szybszy przepływ danych nie rozwiąże głównego problemu.

Dzisiejszy status nie mówi, co było wiadomo wczoraj

Planista potwierdził klientowi termin realizacji zamówienia. Następnego dnia w systemie widać, że część potrzebnego materiału wydano wcześniej do innego zlecenia. Łatwo wtedy uznać, że planista zignorował dane.

Nie wiemy jednak, czy w chwili potwierdzania terminu informacja o wydaniu była dostępna w raporcie, z którego korzystał. Trzeba ustalić cztery momenty:

• Zdarzenie: kiedy materiał rzeczywiście wydano.
• Zapis: kiedy wydanie odnotowano w systemie.
• Udostępnienie: kiedy informacja pojawiła się w miejscu, z którego planista powinien korzystać.
• Decyzja: kiedy potwierdzono termin klientowi.

To inny problem niż w przypadku amerykańskiej poczty. Tam część opóźnień nie została prawidłowo zgłoszona. W przykładzie z magazynem zdarzenie mogło zostać zapisane od razu, ale raport używany do podejmowania decyzji zaktualizował się za późno.

Odrębną kwestią jest to, czy pracownik zapoznał się z dostępnymi danymi i prawidłowo je zinterpretował. Sam fakt, że informacja była w systemie, nie pozwala tego rozstrzygnąć. Rozróżnienie czasu, którego dotyczy zdarzenie, i czasu jego zapisu jest znane z modelowania danych historycznych. Przy analizie decyzji trzeba dodatkowo sprawdzić, kiedy zapis był dostępny dla właściwej osoby.

Jak sprawdzić, czy informacja była dostępna na czas?

Na początek wystarczy przeanalizować jedną istotną decyzję. Właściciel procesu, przy wsparciu osoby znającej systemy, powinien odpowiedzieć na pięć pytań.

1. Jaka decyzja została podjęta? Kto ją podejmował i kiedy? Na przykład: potwierdzenie klientowi terminu realizacji zamówienia o godzinie 10:00.

2. Jaka informacja była potrzebna? W naszym przykładzie: czy wymagana ilość materiału była w tej chwili dostępna. Trzeba też sprawdzić, czy w procesie określono, jak aktualna miała być ta informacja. Jeśli takiego wymagania nie było, nie można uznać po fakcie, że zostało naruszone. Należy natomiast ustalić je na przyszłość.

3. Co potwierdza rzeczywisty stan? Można zestawić historię operacji, dokument wydania i inne niezależne potwierdzenia. Jeśli źródła sobie przeczą, trzeba ustalić dlaczego, zamiast arbitralnie uznać jedno z nich za prawdziwe.

4. Co było dostępne w chwili decyzji? Sprawdzamy czas zdarzenia, jego zapisu, aktualizacji raportu i podjęcia decyzji. Jeśli system nie przechowuje historii zmian, dzisiejszy widok nie wystarczy do odtworzenia przeszłości.

5. Jaki jest wynik? Potrzebna informacja była dostępna na czas i dostatecznie wiarygodna, nie spełniała tych warunków albo nie ma wystarczających dowodów, by to ocenić. Każdy wynik prowadzi do innego następnego kroku.

Przykład z potwierdzeniem terminu

Przyjmijmy, że zgodnie z zasadami procesu planista powinien przed potwierdzeniem terminu widzieć wszystkie wcześniejsze wydania potrzebnego materiału.

Jeśli historia aktualizacji potwierdza tę kolejność, wiadomo, że raport nie zawierał wymaganej informacji, kiedy planista podejmował decyzję. Nie wiemy jeszcze, dlaczego raport zaktualizował się z opóźnieniem ani czy klient rzeczywiście odczuł jego skutki.

Gdyby aktualne dane były dostępne przed godziną 10:00 w uzgodnionym miejscu, należałoby sprawdzić, jak korzystano z nich przy podejmowaniu decyzji. Jeżeli nie zachowała się historia aktualizacji ani inne wiarygodne ślady, nie można rozstrzygnąć, jaki stan był wtedy dostępny planiście. W obu przypadkach pochopne zlecenie przebudowy raportu mogłoby być stratą pieniędzy.

Nie wystarczy sprawdzić tego, co zapisano w systemie

Jest jeszcze druga pułapka. Jeśli analizujemy wyłącznie zdarzenia zapisane w badanym systemie, nie znajdziemy tych, które nigdy do niego nie trafiły.

Dlatego część spraw warto wybrać z rejestru, a część na podstawie innych potwierdzeń wykonanych czynności. W procesie magazynowym mogą to być dokumenty wydań, a w obsłudze zamówień potwierdzenia od kontrahentów. Także te źródła mogą zawierać błędy, więc trzeba je ze sobą porównać.

Badania nad jakością rejestrów zdarzeń opisują m.in. brakujące wpisy i nieprawidłowe znaczniki czasu. Sprawdzenie kilku odpowiednio dobranych przypadków może ujawnić rodzaj rozbieżności, ale nie wystarczy do ustalenia, jak często występuje ona w całej firmie.

Jeśli nie da się odtworzyć historii, lepiej sprawdzić następne realizowane sprawy. Można przez ustalony czas zapisywać moment zdarzenia, moment jego rejestracji, udostępnienia informacji i podjęcia decyzji. Zakres zbieranych danych powinien być ograniczony do tego, co potrzebne do takiej analizy.

Co powinien otrzymać zarząd?

Wynikiem nie musi być obszerny audyt. Dla kilku spraw wystarczy krótkie zestawienie: jaka decyzja była podejmowana, jaka informacja była potrzebna, czy była dostępna na czas i co należy zrobić dalej. Powinno też wskazywać osobę odpowiedzialną za następny krok.

Przykładowy wniosek mógłby brzmieć: „Wydania materiału są rejestrowane od razu, ale raport planisty pokazuje je z opóźnieniem. Właściciel procesu powinien określić, jak szybko informacja ma być dostępna, a zespół IT sprawdzić przyczynę zwłoki”. To znacznie bardziej użyteczny wynik niż ogólne zlecenie budowy nowego dashboardu.

Po ustaleniu przyczyny można określić wymagania dla rozwiązania: jaka informacja ma być dostępna, dla kogo, w jakim czasie i jak sprawdzimy jej poprawność. Czasem wystarczy zmienić procedurę. Innym razem potrzebna będzie konfiguracja systemu, integracja lub możliwość przeglądania historii zmian.

W Codino realizowaliśmy projekty, w których udostępnialiśmy dane z systemów operacyjnych w postaci przydatnej do analizy i podejmowania decyzji. Przy takich pracach samo przygotowanie raportu nie wystarcza. Trzeba jeszcze ustalić, na jakie pytanie ma odpowiadać i czy dane będą dostępne wtedy, gdy są potrzebne.

Zanim firma zainwestuje w kolejne raporty, warto sprawdzić kilka istotnych decyzji i ustalić, jakie informacje były wtedy rzeczywiście dostępne. To pozwoli odróżnić problem z danymi od problemu z ich wykorzystaniem i wybrać właściwy sposób działania.

Jeżeli informacje są dostępne na czas, a realizacja zamówień nadal się opóźnia, pojawia się inne pytanie: co dzieje się między zakończeniem jednej czynności a rozpoczęciem kolejnej? O tym jest następna część tej serii.