Właściciel chce raportów, operator chce mniej klikania — kto ma rację

Czwartek, spotkanie projektowe. Właściciel patrzy na makietę ekranu operatora i mówi spokojnie: „Dorzućcie tu jeszcze przyczynę przestoju, numer partii surowca i kto zatwierdził zwolnienie. Przyda się do analiz.” Trwa to pięć sekund. Trzy zdania, trzy nowe pola.

Po drugiej stronie stołu siedzi kierownik produkcji. Robi w głowie inny rachunek. Te trzy pola operator będzie wypełniał przy każdym zleceniu. Zleceń jest sto dwadzieścia na zmianę. Trzy pola razy sto dwadzieścia razy trzy zmiany. On już wie, że za miesiąc przyjdzie do niego ta sama pakowaczka, która przykleiła karteczkę na monitorze, i powie: „Panie kierowniku, ja nie nadążam z tym klikaniem”.

Obaj mają przed oczami ten sam ekran. Właściciel widzi na nim informacje, których mu brakowało. Kierownik widzi sekundy, które ktoś będzie musiał oddać. I żaden z nich nie jest w błędzie — to jest właśnie ten konflikt, który nie ma winnego, tylko dwa uzasadnione punkty widzenia ciągnące w przeciwne strony.

Fizyka problemu: skąd naprawdę biorą się dane

W głowie osoby, która patrzy na gotowy raport, dane po prostu „są”. Wykres pokazuje przyczyny przestojów, tabela pokazuje wydajność linii, zestawienie pokazuje, kto co zatwierdził. Wygląda to tak, jakby system sam to wiedział. Ale system nie wie nic, czego mu ktoś nie powiedział. Za każdą komórką w raporcie stoi moment, w którym człowiek przy terminalu wybrał opcję z listy, wpisał liczbę albo kliknął przycisk.

To jest fizyka, której nie da się obejść dobrymi chęciami. Informacja ma masę — a jej masą jest czas pracy. Gdy właściciel prosi o „jeszcze jedno pole”, w rzeczywistości prosi o ułamek każdej operacji na hali, pomnożony przez liczbę operacji. Ten ułamek jest niewidoczny w pojedynczym przypadku i miażdżący w skali miesiąca. To jedno z tych miejsc, w których firma traci czas, choć nikt tego nie widzi. Pisałem o tym mechanizmie szerzej, pokazując, ile naprawdę kosztuje przepisywanie danych przez operatora — tutaj problem jest subtelniejszy, bo dane nie są nawet przepisywane, tylko dokładane od zera.

Trzy sekundy na pole, sto dwadzieścia razy na zmianę, dwieściepięćdziesiąt dni w roku — to około trzydziestu godzin rocznie na jedno pole i jedno stanowisko. Pięć takich pól na dziesięciu stanowiskach to już równowartość kilku tygodni pełnego etatu, oddana wyłącznie za samo klikanie. I to jest liczenie konserwatywne, bo zakłada, że operator nigdy się nie zastanawia, nie myli i nie poprawia.

Pięć osób, pięć rachunków tego samego pola

Ten konflikt najlepiej widać, gdy posadzi się przy stole wszystkich, których dotyczy jedno dodatkowe pole. Każdy liczy je inną walutą.

Dlaczego ten konflikt w ogóle się rodzi

Bo odległość między prośbą a kosztem jest ogromna

Osoba, która prosi o dane, siedzi w gabinecie. Osoba, która je wprowadza, stoi na hali. Prośba kosztuje pięć sekund wypowiedzenia, koszt ponosi ktoś inny, w innym miejscu, przez cały rok. Ta asymetria sprawia, że pola dokłada się lekką ręką — gdyby proszący sam musiał je wypełniać sto dwadzieścia razy dziennie, lista życzeń skróciłaby się błyskawicznie.

Bo „na wszelki wypadek” brzmi niewinnie

Najgroźniejsze zdanie w projektowaniu systemu to „zbierzmy to, może się przyda”. Dane zbierane na zapas mają zerową wartość dzisiaj i pełny koszt każdego dnia. A ponieważ koszt jest rozproszony, a hipotetyczna przyszła korzyść kusząca, „na wszelki wypadek” prawie zawsze wygrywa — dopóki ktoś nie policzy, ile te wszystkie „wszelkie wypadki” kosztują razem.

Bo nikt nie jest właścicielem całego łańcucha

Właściciel widzi raport. Operator widzi pole. Ale rzadko kto widzi całą drogę od jednego do drugiego i pyta: czy ta konkretna komórka w raporcie jest warta tego konkretnego ruchu na hali? Bez kogoś, kto patrzy na cały łańcuch, każda strona optymalizuje swój koniec, a koszt spada w środek — na kierownika i operatora.

Rozwiązanie: nie wybieraj strony, zaprojektuj zbieranie

Dobra wiadomość jest taka, że w większości przypadków wcale nie trzeba wybierać między danymi a ergonomią. Konflikt jest pozorny wszędzie tam, gdzie dane da się wyprowadzić z czynności, którą operator i tak wykonuje. Sztuka polega na tym, żeby system zbierał informację przy okazji, a nie kazał jej wprowadzać osobno. To zresztą jeden z pierwszych typów zadań na każdej dobrej liście procesów wartych automatyzacji.

Które dane naprawdę warto zbierać, a które są balastem

Nie każde pole da się zautomatyzować i nie każde warto. Kluczem jest uczciwy bilans: wartość decyzyjna informacji kontra koszt jej wprowadzania. Ta tabela pokazuje, jak taki bilans wygląda w praktyce.

Zwróć uwagę na wiersz z komentarzem opisowym. To klasyczne pole „na wszelki wypadek” — nikt go nie czyta, a kosztuje najwięcej. Takie pola są w niemal każdym systemie i to od nich należy zaczynać, gdy chce się oddać operatorowi czas bez utraty czegokolwiek wartościowego. Więcej o tym, które informacje muszą płynąć, a które tylko obciążają, pisałem w tekście o tym, jak przepływ informacji generuje ukryte straty.

Kompromis, który zwykle działa: rozdziel widoki, nie mnóż pól

Gdy dane naprawdę muszą pochodzić od człowieka i nie da się ich zebrać automatycznie, istnieje jeszcze jedna droga, o której często się zapomina. Nie chodzi o to, żeby wybierać między pełnym a ubogim ekranem — chodzi o to, żeby różni ludzie widzieli różne ekrany. Operator potrzebuje najkrótszej możliwej ścieżki do zamknięcia zlecenia. Kierownik potrzebuje wglądu w szczegóły. To nie muszą być te same widoki tej samej rzeczy.

Najczęstszy błąd polega na tym, że projektuje się jeden ekran, który ma zadowolić wszystkich naraz — i w efekcie nie zadowala nikogo. Operator dostaje pola, których nie rozumie, bo są tam dla kierownika. Kierownik i tak nie ufa danym, bo widzi, że operator wypełnia je w biegu. Rozdzielenie ról rozwiązuje oba problemy jednocześnie: operator ma ekran wycięty do minimum, a informacje, których potrzebuje zarząd, dokładają ci, którzy mają na to czas i kontekst — mistrz zmiany, planista, kontrola jakości.

Ta sama logika stoi za tym, dlaczego dane w ERP tak często rozjeżdżają się z rzeczywistością na hali: gdy zmusza się operatora do wprowadzania informacji, na którą nie ma czasu ani kontekstu, dostaje się dane formalnie kompletne, a faktycznie zmyślone. Lepiej mniej pól wypełnionych rzetelnie niż więcej wypełnionych byle jak — bo raport zbudowany na zmyślonych danych jest gorszy niż brak raportu. Brak raportu przynajmniej nie wprowadza w błąd.

Checklista: zanim dodasz pole do ekranu operatora

Podsumowanie

Właściciel, który chce raportów, i operator, który chce mniej klikać, nie są przeciwnikami — są dwoma końcami tego samego łańcucha. Dane, których potrzebuje jeden, powstają z ruchów drugiego. Kto pyta „kto ma rację”, źle postawił pytanie, bo racja jest po obu stronach, a spór dotyczy priorytetów, nie prawdy.

Właściwe pytanie brzmi: jak zebrać potrzebną informację przy najmniejszym koszcie dla tego, kto ją tworzy. I okazuje się, że w większości przypadków wcale nie trzeba wybierać. Dane da się wyprowadzić ze skanu, ze znacznika czasu, z odczytu maszyny — z czynności, którą hala i tak wykonuje. Trzeba tylko projektować zbieranie zamiast dokładać pola, i za każdym razem nazywać odbiorcę, decyzję i koszt.

Konflikt raportów z klikaniem znika nie wtedy, gdy jedna strona wygra, tylko wtedy, gdy ktoś weźmie odpowiedzialność za cały łańcuch — od pola na ekranie do komórki w zestawieniu — i przy każdym ogniwie zapyta, czy warto. To nudna, żmudna praca. Ale to jest dokładnie ta praca, która odróżnia system, którego ludzie używają, od systemu, obok którego rośnie las karteczek.