Gdy w domu cieknie kran, dzwonisz do hydraulika i mówisz: „cieknie kran, proszę przyjechać”. Nie mówisz: „potrzebuję klucza szesnastki, uszczelki, zaworu i dwóch wężyków”. Fachowiec przyjedzie, zada kilka pytań, oceni sytuację, kupi potrzebne części i wystawi fakturę za usunięcie usterki. Miara sukcesu jest oczywista: kran przestał cieknąć.
W firmach robimy to zwykle odwrotnie. Dzwonimy do informatyków albo dostawców oprogramowania i mówimy: „potrzebujemy systemu do obsługi zgłoszeń serwisowych”, „potrzebujemy aplikacji do workflow”, „potrzebujemy bazy danych pod rejestr środków trwałych”. Podajemy rozwiązanie, zanim ktokolwiek zapytał, jaki jest problem.
Dlaczego zaczynamy od rozwiązania
Wiemy, że coś nie działa, więc naturalnie idziemy szukać narzędzia, a potem wykonawcy, który je wdroży. Kłopot w tym, że kiedy skupiamy się na rozwiązaniu, tracimy z oczu problem. Pomijamy etap, w którym warto ustalić, co właściwie się dzieje i dlaczego. Może się wtedy okazać, że wdrożyliśmy świetne narzędzie, które naprawia nie ten problem, co trzeba.
Jest też druga strona. Pytanie „a jaki właściwie macie problem?” bywa odbierane jako podważanie pomysłu, sugestia, że firma jest źle zarządzana, albo próba zarobienia na dodatkowych rozmowach. Rozumiem te obawy. Dlatego rozmowę o problemie staram się prowadzić spokojnie, bez wytykania błędów. Pytanie o problem nie krytykuje Twojego pomysłu. Sprawdza, czy pomysł trafi tam, gdzie naprawdę boli.
Co powinien zrobić wykonawca
Rola IT w firmie jest podobna do roli hydraulika. Powinien przyjechać, porozmawiać, wyciągnąć kontekst: jak działa Twoja branża, jakie są zależności między działami, jakie inne systemy już u Ciebie pracują. Dopiero potem zaproponować rozwiązanie, które faktycznie rozwiąże problem.
Czasem, rzadko, ale jednak, jest to coś zupełnie innego niż to, co zamawiałeś. Bardzo często to, co widzi biznes, jest tylko skutkiem czegoś większego. Zgłaszasz „wolno nam idzie obsługa klientów”, a źródłem jest na przykład brak jednego, wspólnego miejsca, w którym zapisane są ustalenia.
Jak opisać problem w pięciu pytaniach
Nie musisz znać terminologii analityków. Wystarczy, że odpowiesz na kilka prostych pytań, najlepiej na kartce, własnymi słowami:
- Co dzisiaj nie działa? Opisz sytuację, a nie narzędzie, które chcesz kupić.
- Kogo to dotyczy i jak często? Jedna osoba raz w miesiącu to inny problem niż cały zespół codziennie.
- Ile to kosztuje? Czas, pieniądze, zdenerwowani klienci. Nawet w przybliżeniu.
- Po czym poznamy, że jest lepiej? To właśnie miara sukcesu.
- Czego nie wolno zepsuć? Procesy, które działają, inne systemy, ograniczenia budżetu.
Miara sukcesu: twarda, nie ogólna
Przy kranie miarą jest „nie cieknie”. W systemie informatycznym może to być na przykład skrócenie o połowę czasu obsługi zgłoszenia albo wyższe zadowolenie klientów, o ile potrafisz je zmierzyć. Tu często wychodzi kolejna rzecz: wiele firm nie mierzy takich wskaźników wcale. Wtedy sam brak pomiaru okazuje się częścią problemu, a pierwszym zadaniem jest nauczyć się mierzyć. To zresztą temat na osobną rozmowę.
Bez miary nie dowiesz się, czy wdrożenie się opłaciło. A kiedy dostawca pyta, jak ma ocenić efekt swojej pracy, odpowiedź „żeby było lepiej” nie wystarcza żadnej ze stron.
Przykład z mojej skrzynki
Takie wiadomości zdarzają się często. Ktoś pisze, że szuka wydajnego i prostego w obsłudze systemu CRM dla małej firmy: wszechstronnego, wielojęzycznego, z intuicyjnym interfejsem. Obejrzał demo kilku popularnych systemów i żaden nie spełnił wymagań. Przy okazji potrzebuje magazynu, prognozowania przepływów finansowych i zarządzania projektami w produkcji. Pyta, czy mogę coś polecić.
To nie jest błąd nadawcy. Nikt nie musi umieć formułować wymagań funkcjonalnych i niefunkcjonalnych. Od tego są wykonawcy. Ale w tej wiadomości nie ma ani jednego problemu, który system miałby rozwiązać. Są przymiotniki („prosty”, „wszechstronny”) i lista funkcji. Moja odpowiedź to zestaw pytań: jaki problem ma rozwiązać ten system, jak ma się zwrócić, jak zmierzymy oszczędność, ilu użytkowników będzie z niego korzystać i w jakich rolach, jaki jest budżet.
Podobnie wygląda kupowanie linii produkcyjnej. Nikt nie pisze, że chce linię „wydajną i wszechstronną”. Pisze, ile elementów na zmianę ma wychodzić, jak bardzo ma być zautomatyzowana i ilu operatorów ma ją obsługiwać. Z systemami dla firm powinno być tak samo.
Co dalej
Opis problemu i miary sukcesu to pierwszy krok. Kolejne to ustalenie, ile całość ma kosztować (więcej w tekście Ile naprawdę kosztuje system dla firmy) oraz, jeśli wybierasz gotowy produkt, jakie pytania zadać przed demo.
Jeśli po kolejnym pokazie wszystkie systemy wyglądają Ci tak samo, przeczytaj o problemie Żaden CRM ani ERP nam nie pasuje. Pomagam przy tym na dwa sposoby: w ramach usługi Wybór systemu dla firmy pomagam opisać potrzeby i porównać oferty, a w prototypie i specyfikacji przed zleceniem zamieniam opis problemu w coś, co wykonawcy mogą rzetelnie wycenić.