Problem jest znany. I właśnie to zaczyna być problemem
W poniedziałek zespół zgłasza kolejny błąd przy przepisywaniu danych z CRM do systemu zamówień. Tym razem trzeba ręcznie poprawić siedemnaście rekordów. Nie ma sporu, czy problem istnieje. Wszyscy go znają. Ktoś mówi: „trzeba się tym zająć”. Ktoś zapisuje temat. Pada nawet pomysł, żeby wrócić do niego po zamknięciu miesiąca. Mija tydzień. Potem następny. Problem pojawia się znowu.
Na kolejnym spotkaniu rozmowa jest już krótsza. Nie trzeba tłumaczyć, o co chodzi. Wystarczy powiedzieć: „znowu CRM”. Tyle że tym razem ważniejszy jest duży klient. Później zamknięcie miesiąca. Potem awaria. Potem wdrożenie.
Po pewnym czasie mamy sytuację trochę absurdalną: problem jest dobrze znany, regularnie omawiany i nadal pozostaje częścią codziennej pracy.
Piąte zgłoszenie mówi więcej niż pierwsze
Pierwsze zgłoszenie mówi: coś nie działa. Drugie potwierdza, że sprawa nie zniknęła. Jeżeli jednak ten sam temat wraca na pięciu kolejnych spotkaniach, dostajemy nową informację. Już nie tylko o CRM. Dostajemy informację o tym, co dzieje się z problemem po jego zgłoszeniu.
W notatkach jest ślad rozmów. Zespół potrafi wskazać skutki. Wszyscy wiedzą, że ręczne poprawianie zamówień zabiera czas i zwiększa ryzyko kolejnych błędów. A mimo to sposób pracy pozostaje taki sam.
To wystarcza, żeby przestać patrzeć wyłącznie na pierwotną usterkę.
„Zajmiemy się tym” może niczego nie uruchamiać
Samo przyjęcie problemu do wiadomości nie jest jeszcze decyzją. Można go wpisać do notatki. Można utworzyć zadanie. Można omówić go na kolejnym spotkaniu. Jeżeli jednak nie wiadomo, kto ma doprowadzić sprawę do końca, do kiedy i po czym poznamy, że problem rzeczywiście został rozwiązany, cała aktywność może kończyć się dokładnie tam, gdzie się zaczęła. W tej sytuacji warto więc sprawdzić nie liczbę rozmów, lecz drogę od zgłoszenia do zmiany.
Problem może być ważny i ciągle przegrywać
Nikt nie musi go lekceważyć. Może być dokładnie odwrotnie: wszyscy zgadzają się, że trzeba go naprawić. Tylko za każdym razem pojawia się coś pilniejszego. Dzisiaj klient. Jutro zamknięcie miesiąca. Za tydzień wdrożenie. W ten sposób problem może pozostawać ważny przez wiele miesięcy, nigdy nie stając się wystarczająco ważny, żeby dostać pierwszeństwo.
To istotna różnica. Wiedza o problemie istnieje. Nie znika również wartość dobrej jakości obsługi. Ale w praktyce inne cele otrzymują większą wagę.
Wiedza i możliwość zmiany mogą być w różnych miejscach
Osoby obsługujące zamówienia najlepiej widzą skutki błędu. Wiedzą, ile czasu zabiera ręczna korekta i gdzie najczęściej pojawiają się pomyłki. IT wie, co należałoby zmienić w systemie. Menedżer decyduje, czy poświęcić na to czas i zasoby. Każda z tych osób ma inny fragment obrazu. Tylko że najwięcej o skutkach wiedzą ci, którzy nie ustalają priorytetów. I właśnie dlatego zdanie: „Mówię o problemie. Nic się nie zmienia” nie musi oznaczać, że nikt nie słucha.
Może oznaczać coś znacznie bardziej konkretnego: problem jest widoczny, ale droga od Wiedzy do decyzji i działania gdzieś się urywa.
Poniższa mapa pokazuje, gdzie warto jej szukać.
Powtarzalność sama stała się częścią Wiedzy
Po przejściu mapy wiemy już więcej niż na początku. Nie tylko to, że pojawiają się błędy w zamówieniach. Wiemy również, że ten sam temat wrócił pięć razy i nie doprowadził do zmiany sposobu pracy. To nie jest jeszcze wyjaśnienie przyczyny. Jest jednak mocnym sygnałem, że nie mamy już do czynienia wyłącznie z pojedynczym błędem. Trzeba przyjrzeć się również sposobowi, w jaki organizacja reaguje na powtarzające się problemy.
Pilne zadania mogą skutecznie chronić problem przed rozwiązaniem
Mapa pokazuje też coś bardzo zwyczajnego. Każdego tygodnia istnieje dobry powód, żeby odłożyć zmianę. Klient naprawdę jest ważny. Zamknięcie miesiąca naprawdę ma termin. Awaria naprawdę wymaga natychmiastowej reakcji. Każda z tych decyzji może być racjonalna osobno. Problem pojawia się wtedy, gdy kolejne racjonalne przesunięcia składają się na trwały mechanizm: problem wraca, ale jego miejsce w kolejce się nie zmienia. Wtedy warto przestać pytać wyłącznie „dlaczego jeszcze tego nie zrobiliśmy?” i zapytać: co musiałoby się wydarzyć, żeby ta sprawa rzeczywiście dostała pierwszeństwo?
Rozmowa może zacząć udawać rozwiązanie
Tu mapa jest szczególnie bezlitosna. Spotkanie się odbyło. Temat został zapisany. Ktoś zadeklarował działanie. Powstał kolejny punkt na liście. Organizacja może więc mieć poczucie, że reaguje. Tyle że stan rzeczy pozostaje bez zmian. Dlatego dobrym testem nie jest pytanie: „co zrobiliśmy w sprawie problemu?” lecz: „co po tych działaniach jest dziś inne niż wcześniej?”
Jeżeli odpowiedź brzmi „nic”, aktywność zaczęła pełnić funkcję substytutu rozwiązania.
Brak właściciela oznacza, że problem może należeć do wszystkich i do nikogo
W mapie pojawia się jeszcze jeden bardzo konkretny sygnał: brak właściciela, terminu i kryterium końca. To drobiazgi tylko z pozoru. Jeżeli nie wiadomo, kto ma doprowadzić sprawę do końca, problem może przechodzić między spotkaniami i działami bez formalnego zatrzymania. Jeżeli nie ma terminu, zawsze można przesunąć go jeszcze raz. Jeżeli nie ma kryterium zakończenia, samo wykonanie kilku czynności może zostać uznane za wystarczające.
Wtedy organizacja nie tyle świadomie toleruje problem, ile nie posiada jasnego punktu, w którym ktoś musi powiedzieć: rozwiązane albo nierozwiązane.
Najwięcej wiedzieć nie znaczy móc uruchomić zmianę
Obsługa zna skutki. IT zna system. Menedżer ustala priorytety. To nie musi być wada. Podział ról jest czymś normalnym. Problem zaczyna się wtedy, gdy Wiedza osób najbliższych skutkom nie ma wyraźnej drogi do miejsca, w którym zapada decyzja o zasobach i pierwszeństwie. Wtedy można przez wiele miesięcy bardzo dobrze wiedzieć, co nie działa, i jednocześnie nie mieć mechanizmu, który zamieni tę Wiedzę w zmianę.
I dlatego „nic się nie zmienia” to jeszcze nie diagnoza
To sygnał. Po mapie możemy już powiedzieć znacznie więcej: problem jest realny; powtarza się; kolejne zgłoszenia nie zwiększają jego priorytetu; brakuje jasnego mechanizmu domknięcia; a Wiedza o skutkach i możliwość uruchomienia zmiany znajdują się w różnych miejscach.
Dopiero teraz pytanie robi się naprawdę użyteczne: gdzie dokładnie zatrzymuje się droga od rozpoznania problemu do zmiany stanu rzeczy?
I to jest właściwy początek dalszego rozpoznania.