Spis treści
Spotkanie trwa godzinę. Zarząd jest przygotowany. Padają konkretne oczekiwania: podgląd realizacji zleceń, zestawienia sprzedaży, raporty dla menedżerów, powiadomienia o opóźnieniach. Lista ma sens. Wszystko jest spójne.
Wychodzę z tego spotkania z notatkami i z pytaniem, które coraz częściej zadaję sobie przed następnym krokiem: czy powinienem od razu budować system, który rozwiązuje to, co właśnie usłyszałem?
Odpowiedź brzmi: nie.
Przez lata nauczyłem się, że lista oczekiwań zarządu to nie mapa problemu. To mapa tego, co boli na górze. A między tym, co boli na górze, a tym, co naprawdę się dzieje w firmie, jest przepaść, przez którą co roku wpadają projekty, które technicznie działają i biznesowo nic nie zmieniają.
Zarząd widzi firmę inaczej
To nie kwestia złej woli ani braku kompetencji. Zarząd naprawdę wie, czego potrzebuje. Problem w tym, że ta wiedza pochodzi z konkretnego miejsca w organizacji – z poziomu wyników, analiz i podsumowań.
Zarząd mówi: „chcemy mieć dane w jednym miejscu”. Pracownik działu handlowego mówi: „tracę czterdzieści minut dziennie na przepisywanie informacji między arkuszem a mailem, bo nie mamy gdzie zapisywać ustaleń z klientem”. To ten sam problem opisany z dwóch różnych wysokości. Na poziomie zarządu widać objaw: dane są porozrzucane. Na poziomie pracownika widać przyczynę: nie ma miejsca, żeby na bieżąco notować, co ustalono z klientem.
Jeśli zaprojektuję system pod opis zarządu, dostanę ładne wykresy i raporty. Dane nadal będą się rozsypywać, bo źródło problemu – sposób pracy handlowca – pozostanie niezmieniony.
Gdy system rozwiązuje nie ten problem
Kilka lat temu pracowałem z firmą, która chciała systemu do zarządzania zleceniami. Zarząd opisał swoje potrzeby precyzyjnie: przejrzysty podgląd etapów realizacji, powiadomienia o opóźnieniach, raporty terminowości dla klientów.
Brzmiało rozsądnie. Poszedłem porozmawiać z ludźmi, którzy realizowali zlecenia.
Okazało się, że połowa zleceń wchodziła do firmy bez kompletnych danych. Klient zamawiał przez telefon lub maila, handlowiec notował to, co zapamiętał, a reszta trafiała do realizacji z dziurami. Wykonawcy uzupełniali braki telefonami, mailami i domysłami. Zarząd widział opóźnienia. Nie widział, że opóźnienia zaczynały się w momencie przyjęcia zlecenia – zanim ktokolwiek zdążył zacząć pracować.
Gdybym zbudował system zgodnie z tym, czego chciał zarząd, dostaliby terminarz z powiadomieniami. Terminarz pełen niekompletnych zleceń. Problem zostałby przeniesiony, nie rozwiązany.
Zmieniliśmy założenia. Zbudowaliśmy narzędzie, które pilnowało kompletności danych już przy przyjęciu zlecenia. Dopiero potem zajęliśmy się śledzeniem etapów. Wyniki były zupełnie inne, niż gdybyśmy poszli prostą drogą.
Skąd bierze się ta luka
Mechanizm jest prosty, choć trudny do zobaczenia z zewnątrz.
Zarząd reaguje na to, co wychodzi na powierzchnię: opóźnienia, reklamacje, problemy, które ktoś przynosi na spotkanie. Widzi to, co przez kilka warstw organizacji zdążyło dobić do góry. To, co nie dobija – codzienne utrudnienia, własne sposoby pracowników na omijanie problemów, nieformalne „u nas tak się to robi” – pozostaje niewidoczne.
Pracownicy żyją właśnie w tej niewidocznej warstwie. Wiedzą, co naprawdę spowalnia pracę. Wiedzą, gdzie coś nie działa i jak sobie z tym radzą – zazwyczaj kosztem czasu i dodatkowego wysiłku. Ale nikt ich o to nie pyta. Decyzja o nowym systemie przechodzi przez zarząd, więc to zarząd mówi, czego potrzebuje. Pracownicy dostają gotowe rozwiązanie i mają się do niego dostosować.
Firma kupuje coś, co rozwiązuje problemy zarządu. Nie problemy firmy.
Jak naprawdę wygląda rozmowa o potrzebach
Pytanie „czego potrzebujecie od nowego systemu?” jest złe. Nie dlatego, że jest nieuczciwe. Dlatego, że jest skierowane do przyszłości. Ludzie nie wiedzą, czego potrzebują od narzędzia, którego jeszcze nie mają.
Dobre pytania brzmią inaczej. „Pokaż mi, jak to teraz robisz.” „Gdzie tracisz czas?” „Co robisz, gdy coś się nie zgadza i musisz to jakoś obejść?” „Co zawsze sprawdzasz ręcznie, bo boisz się, że coś wypadnie?”
Tych pytań nie można zadać zarządowi. Tylko pracownikom.
Dobra rozmowa o potrzebach nie wygląda jak wypełnianie formularza. Wygląda jak obserwacja codziennej pracy. Siedzisz obok kogoś, kto realizuje zlecenie, obsługuje klienta albo zamawia towar, i patrzysz, co naprawdę robi. Gdzie klika dwa razy niepotrzebnie, gdzie przepisuje to samo z miejsca do miejsca, gdzie czeka na kogoś innego, bo sam nie może przejść dalej.
Z tych rozmów i obserwacji wychodzi lista problemów. Dopiero z tej listy buduje się listę funkcji, których system naprawdę potrzebuje. Nie odwrotnie.
Kto tu jest klientem
Ten schemat powtarza się w różnych branżach i różnych skalach firm. I za każdym razem uderza mnie ta sama nierównowaga: formalnym klientem projektu jest zarząd – podpisuje umowę, zatwierdza zakres, odbiera gotowy produkt. Ale rzeczywistym użytkownikiem systemu jest pracownik, który będzie z nim pracować osiem godzin dziennie.
Tego napięcia nie rozwiąże żadne narzędzie do zarządzania projektami. Można je rozwiązać tylko przez jedno: wyjście poza salę konferencyjną i rozmowę z ludźmi, którzy pracują w tym, co chcemy usprawnić.
Dobry konsultant nie buduje tego, czego klient chce. Buduje to, czego klient potrzebuje – i te dwie rzeczy rzadko wychodzą identyczne po pierwszym spotkaniu.
Systemy, które naprawdę zmieniają sposób pracy firmy, zazwyczaj były projektowane przez kogoś, kto najpierw usiadł przy biurku pracownika.
Zarząd widzi wyniki. Pracownicy wiedzą, dlaczego wyniki są takie, a nie inne.
Pytaj obu. Buduj dla drugich.
Jeśli ten temat jest bliski Twojej firmie...
Na blogu dzielę się obserwacjami z pracy z przedsiębiorstwami oraz refleksjami dotyczącymi technologii, zarządzania i funkcjonowania organizacji. W wielu firmach podobne zagadnienia pojawiają się jednak nie tylko jako ciekawy temat do dyskusji, ale jako realne wyzwanie związane z rozwojem biznesu.
Jeśli w Twojej firmie pojawiają się pytania dotyczące organizacji procesów, wykorzystania technologii lub kierunku rozwoju projektów informatycznych, możesz skorzystać z mojego wsparcia doradczego.
