Dlaczego narzędzie nie uratuje źle opisanego procesu

Problem rzadko polega na tym, że narzędzie ma za mało funkcji. Znacznie częściej chodzi o to, że firma nie umie dokładnie opisać, jak przebiega praca od „startu” do „zrobione”.

Bez takiego opisu wybór systemu nie jest decyzją operacyjną, tylko zakupem opartym na wyobrażeniu. Wyobrażenia świetnie wyglądają na prezentacji, dopóki nie trzeba na ich podstawie pracować.

Problem nie zaczyna się w systemie, tylko dużo wcześniej

Na etapie wyboru wszystko wygląda porządnie. Są tabelki, listy funkcji, obietnice i zapewnienia, że „to się da ustawić”.

Tyle że nadal nie ma odpowiedzi na najważniejsze pytanie: co dokładnie dzieje się między początkiem sprawy a jej domknięciem. Jeśli tego nie wiadomo, nie da się uczciwie ocenić, czy narzędzie wspiera pracę, czy tylko dobrze ją udaje.

Opis procesu nie służy do tego, żeby narysować ładny schemat dla zarządu. Służy wskazaniu kroków, decyzji, wyjątków, przekazań i odpowiedzialności. Dopiero wtedy widać, czego naprawdę trzeba od systemu.

Bez granic procesu wszystko staje się domysłem

Proces bez opisu nie ma wyraźnych granic. Nie wiadomo, gdzie zaczyna się odpowiedzialność, kto podejmuje decyzję, kiedy temat przechodzi dalej i co właściwie znaczy „zrobione”.

Wtedy wymagania nie są wymaganiami. Są zlepkiem przypuszczeń różnych osób, które opowiadają o tej samej pracy z różnych miejsc i z różnym poziomem pamięci. Jedna osoba pamięta wyjątki, druga zna tylko wersję oficjalną, trzecia od lat wszystko obchodzi ręcznie i nawet nie zauważa, że to obejście.

To właśnie tutaj zaczyna się koszt. Jeszcze nie w licencji. Jeszcze nie w integracji. Najpierw w tym, że firma kupuje narzędzie pod opowieść o procesie, a nie pod sam proces.

Wdrożenie przegrywa z rzeczywistością

Kiedy system jest już wybrany, szybko okazuje się, ile rzeczy nie zostało wcześniej uwzględnionych. Jeden etap ma kilka wyjątków, akceptacja wcale nie jest pojedyncza, a część danych w ogóle nie trafia do systemu, bo wcześniej była dopisywana „na boku”.

Wtedy pojawiają się ręczne obejścia, dopiski, nadmiarowe pola i dziwne zasady, których nikt nie planował. Narzędzie zaczyna wyglądać jak winowajca, choć w praktyce tylko ujawnia bałagan, który wcześniej był ukryty pod codziennym przyzwyczajeniem.

Najbardziej ironiczne jest to, że wiele zespołów nazywa ten moment doprecyzowaniem wymagań. Nie. To są wymagania, które należało znać przed wyborem, a nie po podpisaniu umowy.

Dobry wybór nie zaczyna się od listy funkcji

Wyobraź sobie firmę usługową, która chce wdrożyć system do obsługi zleceń. Na spotkaniu wszyscy mówią, że proces jest prosty: klient wysyła zgłoszenie, firma wycenia pracę, realizuje ją i zamyka temat.

Brzmi pięknie. Problem w tym, że po rozpisaniu pracy okazuje się, że część zleceń wymaga dodatkowej akceptacji, część wraca do uzupełnienia, terminy zależą od dostępności ludzi, a „zamknięcie” dla działu operacyjnego oznacza co innego niż dla księgowości.

Jeśli system wybrano przed odkryciem tych różnic, zaczyna się dłubanie na siłę. Niby wszystko działa, ale tylko pod warunkiem, że ludzie pamiętają, czego system nie potrafi obsłużyć samodzielnie. Czyli klasyka: narzędzie kupione dla porządku staje się nową warstwą bałaganu.

Są sytuacje, w których brak pełnego opisu nie zabija wdrożenia

Żeby było uczciwie: nie każdy wybór narzędzia wymaga rozpisania procesu z dokładnością do sekundy. Jeśli firma wdraża bardzo prosty system do jednego, wąskiego zadania, a sam przebieg pracy jest niemal identyczny za każdym razem, szczegółowy opis nie musi być rozbudowany.

Na przykład proste narzędzie do umawiania spotkań zwykle nie wymaga mapowania trzydziestu wyjątków i siedmiu warstw odpowiedzialności. Wystarczy wiedzieć, kto udostępnia terminy, kto potwierdza spotkanie i co dzieje się po rezerwacji.

Jeśli proces ma wiele etapów, wyjątków i punktów decyzyjnych, bez jego wcześniejszego opisu nie da się rzetelnie ocenić, jakie narzędzie będzie do niego pasować.

Ludzie mylą brak opisu z elastycznością

Jeden z częstszych błędów polega na tym, że zespół uważa nieopisany proces za „elastyczny”. W praktyce zwykle oznacza to coś znacznie mniej szlachetnego: każdy robi trochę inaczej, odpowiedzialność jest rozmyta, a wyjątki są obsługiwane pamięcią ludzi zamiast zasadami.

Drugi błąd to przekonanie, że narzędzie „wymusi porządek”. Nie wymusi. Może co najwyżej wymusić formularz, ekran i kolejność kliknięć. To nie jest to samo co dobrze zrozumiana praca.

Trzeci błąd brzmi jeszcze lepiej: „wdrożymy teraz, a proces dopracujemy później”. To bardzo elegancki sposób powiedzenia, że firma zapłaci za odkrywanie własnego chaosu już po zakupie systemu.

Co z tego wynika w praktyce

Przed wyborem narzędzia trzeba umieć nazwać kilka rzeczy bez ściemniania:

jakie są kroki,
gdzie zapadają decyzje,
jakie istnieją wyjątki,
kto przekazuje temat dalej,
i po czym poznaje się, że sprawa naprawdę jest zamknięta.

Dopiero wtedy wymagania zaczynają być czymś więcej niż zbiorem życzeń. Da się porównać systemy uczciwie, bo wiadomo, czego mają pilnować, czego nie mogą gubić i gdzie nie wolno udawać automatyzacji.

Nawet dobrze opisany proces nie daje pełnej gwarancji powodzenia. Natomiast brak takiego opisu zwykle prowadzi do błędnych założeń już na początku wdrożenia.

FAQ

Czy najpierw opisać proces, a dopiero potem wybierać narzędzie?

Tak, jeśli proces ma więcej niż kilka prostych kroków i zawiera wyjątki, decyzje albo przekazania między ludźmi. Inaczej porównuje się narzędzia do wyobrażenia o pracy, a nie do samej pracy.

Czy opis procesu musi być bardzo formalny?

Nie. Musi być przede wszystkim prawdziwy i użyteczny. Lepiej mieć prosty, konkretny opis realnych kroków niż rozbudowany dokument, który niczego nie pokazuje.

Skąd poznać, że wymagania są źle zebrane?

Najczęściej po tym, że prawdziwe potrzeby wychodzą dopiero po wdrożeniu. Zaczynają się ręczne obejścia, wyjątki dopisywane po fakcie i zmienianie sposobu pracy pod ograniczenia systemu.

Czy dobre narzędzie może pomóc uporządkować proces?

Może pomóc, ale nie zastąpi myślenia. Narzędzie wspiera dobrze nazwany proces. Źle nazwany tylko utrwala w droższej wersji.

Co dalej

Jeśli proces już się rozjechał, warto go najpierw nazwać krok po kroku, a dopiero potem myśleć o automatyzacji, AI i wdrożeniu systemu.