Jak ustalić, co naprawdę psuje działanie systemu

Zacznij od jednego konkretnego przypadku

Ogólne stwierdzenia typu „proces jest wolny” albo „system jest nieczytelny” nie pokazują miejsca interwencji. Potrzebny jest rzeczywisty przebieg pojedynczej sprawy. Warto zapisać, co uruchamia działanie, jakie informacje są potrzebne, kto podejmuje decyzję, gdzie powstaje oczekiwanie, kiedy sprawa wraca do wcześniejszego etapu i co musi zostać poprawione ręcznie. Taka rekonstrukcja pozwala zauważyć, czy opóźnienie powstaje w samym narzędziu, w regule organizacyjnej, w braku danych czy w zależności od innego fragmentu systemu.

Jeden przypadek nie wystarcza do wniosku, ale dobrze ujawnia pytania. Następnie warto porównać przypadek typowy z sytuacją, w której problem nie wystąpił. Różnica między nimi często jest bardziej informacyjna niż długa lista błędów. Może się okazać, że problem pojawia się tylko przy określonym rodzaju danych, przy przekazaniu między zespołami albo wtedy, gdy użytkownik musi wykonać czynność bez pełnej informacji.

Obejście jest wskazówką, nie tylko naruszeniem procedury

Ręczne arkusze, dodatkowe wiadomości, prywatne listy kontrolne i powtarzane potwierdzenia mogą wyglądać jak niepotrzebne komplikacje. W diagnozie trzeba jednak zapytać, przed czym chronią użytkownika. Jeśli ktoś prowadzi dodatkową listę, być może system nie pokazuje stanu sprawy w potrzebnym momencie. Jeżeli użytkownicy potwierdzają coś poza systemem, być może oficjalny zapis nie daje wystarczającej pewności. Usunięcie obejścia bez zastąpienia jego funkcji może pogorszyć działanie.

Warto rozróżnić obejście lokalne od powszechnego. Jeżeli każdy radzi sobie inaczej, przyczyną może być niejasna reguła. Jeżeli większość osób tworzy podobne rozwiązanie poza systemem, jest to silny sygnał brakującej funkcji albo niewłaściwie umieszczonego kroku. To nie przesądza jeszcze o sposobie naprawy, ale zawęża obszar dalszej analizy.

Sprawdź, gdzie powstaje decyzja wymagająca zgadywania

Systemy tracą jakość, gdy formalna reguła nie odpowiada rzeczywistej sytuacji i użytkownik musi sam uzupełniać brakujące znaczenie. Takie miejsca można rozpoznać po częstych pytaniach, różnym sposobie interpretacji tej samej sytuacji oraz decyzjach zależnych od osoby wykonującej zadanie. Jeżeli identyczny przypadek kończy się różnym wynikiem, trzeba sprawdzić, czy reguła jest niejasna, czy dane wejściowe są niewystarczające, czy też system zmusza do decyzji, której nie powinien pozostawiać użytkownikowi.

Nie każda różnica jest wadą. Niektóre sytuacje wymagają oceny eksperckiej. Problem pojawia się wtedy, gdy system udaje jednoznaczność, ale w praktyce wymusza improwizację, albo odwrotnie: wymusza sztywną ścieżkę w sytuacji, która rzeczywiście wymaga rozróżnienia. Diagnoza powinna ustalić, gdzie potrzebna jest reguła, a gdzie świadoma decyzja człowieka.

Oddziel problem pierwotny od kosztu jego obsługi

Widoczna trudność często jest sumą dwóch rzeczy: źródłowego błędu i kosztu, który powstał wokół jego obchodzenia. Przykładowo brak jednoznacznego statusu może prowadzić do dodatkowych wiadomości, telefonów, notatek i ręcznych kontroli. Same wiadomości nie są przyczyną. Są kosztem niepewności. Jeżeli poprawi się jedynie kanał komunikacji, niepewność może pozostać. Jeżeli usunie się źródło, część czynności pomocniczych zniknie bez osobnej optymalizacji.

To rozróżnienie chroni przed projektami, które automatyzują zbędną pracę. Czynność powtarzalna nie zawsze wymaga automatyzacji. Najpierw trzeba sprawdzić, czy w ogóle powinna istnieć po odnowie systemu.

Diagnoza kończy się wskazaniem granicy problemu

Użyteczny wynik diagnozy mówi, co należy zmienić, czego nie trzeba zmieniać i jakie zależności trzeba uwzględnić. Powinien również wskazywać sytuacje, w których problem nie występuje, bo pomagają one zweryfikować hipotezę o przyczynie. Jeżeli zakładana przyczyna nie tłumaczy różnicy między przypadkiem poprawnym i błędnym, potrzebne jest dalsze sprawdzenie.

Dopiero wtedy warto przejść do priorytetów. Zbyt wczesne projektowanie rozwiązania powoduje przywiązanie do pierwszego pomysłu i późniejsze dopasowywanie diagnozy do wybranej koncepcji. Lepsza kolejność to najpierw mechanizm problemu, potem decyzja, czy i kiedy należy go zmieniać.

Hipoteza diagnozy musi dać się podważyć

Jeżeli każda obserwacja potwierdza przyjęte wyjaśnienie, diagnoza staje się zbyt wygodna. Warto wskazać przypadek, którego wystąpienie obaliłoby hipotezę o przyczynie. Taki test chroni przed dopasowywaniem faktów do pierwszego pomysłu i ułatwia odróżnienie korelacji od mechanizmu problemu. Jeżeli hipoteza przestaje pasować do nowych przypadków, trzeba ją zmienić, a nie dodawać kolejne wyjątki do wyjaśnienia. Właśnie w tym miejscu diagnoza zyskuje praktyczną wartość: ogranicza ryzyko budowania rozwiązania dla problemu, który został źle nazwany.