Jak 24-osobowa firma serwisu terenowego uruchomiła aplikację dla pracowników w 10 tygodni

Firma, która do nas zadzwoniła, nie chciała aplikacji. Chciała przestać tracić godzinę każdego wieczoru na tę samą rozmowę: technik dzwoni do biura i wymienia, które zlecenia zrobiono, jakich materiałów użyto i którego klienta nie było w domu. Ktoś w biurze wszystko spisuje, wprowadza do trzech systemów, a tydzień później odkrywa, że brakuje dwóch kart pracy, a jedna faktura jest błędna. To był prawdziwy problem. Aplikacja była tylko kształtem, jaki przypadkiem przybrało rozwiązanie.

To studium przypadku rzeczywistego projektu, zanonimizowane. Chodzi o 24-osobową firmę instalacyjno-serwisową — ogrzewanie, wentylacja i powiązane wezwania — działającą w regionie, z ośmioma busami na drogach przez większość dni. Zmieniliśmy kilka rozpoznawalnych szczegółów i nie udajemy, że liczby przeszły audyt. Ale historia jest prawdziwa, łącznie z fragmentami, w których coś zrobiliśmy źle i musieliśmy się wycofać. Właśnie te fragmenty są zwykle najbardziej pożyteczne, więc je zostawiliśmy.

Jeśli prowadzi Pan firmę serwisu terenowego i zaoferowano Państwu sześciocyfrową kwotę oraz dziewięciomiesięczny termin na aplikację dla pracowników, to jest kontrargument. Dziesięć tygodni, skupiony zakres i narzędzie, które technicy sami otwierali, bez poganiania. Oto jak to wyglądało.

Problem: firma napędzana papierem i telefonami

Gdy usiedliśmy z właścicielem i kierowniczką biura, powierzchowna skarga brzmiała: "musimy się scyfryzować." To zdanie samo w sobie nic nie znaczy, więc zignorowaliśmy je i zamiast tego przyjrzeliśmy się pracy. Spędziliśmy dzień w biurze i poranek na przejażdżce busem. Do pory lunchu prawdziwy problem był oczywisty i nie miał nic wspólnego z przestarzałą technologią.

Każdy technik nosił podkładkę z kartami pracy w kalce. Na zleceniu nabazgrał wykonaną pracę, zaznaczył kilka pól, zanotował materiały i zbierał podpis klienta. Górna kopia trafiała do biura w końcu — czasem tego wieczoru, czasem w piątek w pogniecionym stosie. Biuro przepisywało potem każdą kartę do narzędzia do planowania, ponownie do programu do fakturowania, i po raz trzeci do arkusza, w którym właściciel śledził, które zlecenia są do zafakturowania. Trzy razy wpisywanie tego samego. Dwa z tych razy z nowymi błędami.

Koszt to nie były tylko godziny biurowe. To było opóźnienie. Zlecenie ukończone w poniedziałek mogło być zafakturowane dopiero w kolejnym tygodniu, bo papier jeszcze się nie pojawił. Klienci dzwonili, pytając o pracę, o której biuro nie wiedziało, że jest zrobiona. A gdy karta przepadała całkiem — co zdarzało się częściej, niż ktokolwiek przyznawał — to zlecenie po prostu nigdy nie było fakturowane. Nikt nie potrafił nam powiedzieć, ile pieniędzy w ten sposób wyparowywało, i to właśnie był sedno sprawy.

Czego świadomie nie zbudowaliśmy

Najszybszy sposób na rozsadzenie dziesięciotygodniowego terminu to mówienie "tak" na wszystko. Więc zanim napisaliśmy linijkę kodu, spisaliśmy listę rzeczy, których aplikacja nie będzie robić — i poprosiliśmy właściciela, by zgodził się na nią na głos. To najmniej efektowna część każdego projektu i jednocześnie najważniejszy powód, dla którego wdrożyliśmy go na czas.

Lista życzeń, zebrana w dwóch rozmowach, liczyła około trzydziestu funkcji. Śledzenie GPS busów. Portal rezerwacji dla klientów. Stany magazynowe całego magazynu. Automatyczna optymalizacja tras. Pełny CRM. Raporty szkód ze zdjęciami i adnotacjami. Rejestracja czasu pracy z eksportem do płac. Każdy z nich był rozsądnym pomysłem. Każdy z nich był też sposobem, by nigdy nie skończyć.

Zawęziliśmy zakres do jednego zdania, tak jak doradzilibyśmy każdej małej firmie: technik powinien móc zobaczyć dzisiejsze zlecenia, zapisać, co zrobił, i nikt nie musi tego nigdy przepisywać. Wszystko, co nie służyło temu zdaniu, trafiło na listę "później, może." Ta lista wciąż istnieje. Większości z niej nikt nigdy nie zaczął żałować.

• Poza zakresem: śledzenie GPS busów — atmosfera inwigilacji, której nikt w zespole nie chciał, rozwiązanie problemu, którego nie mieli.
• Poza zakresem: portal rezerwacji dla klientów — osobny projekt z osobnym odbiorcą; połączenie go podwoiłoby termin.
• Poza zakresem: pełne stany magazynowe — kiedyś przydatne, ale nie na ścieżce krytycznej do szybszego fakturowania.
• Poza zakresem: optymalizacja tras — wysoka złożoność, niski realny zwrot przy geografii tej firmy.
• W zakresie: dzisiejsza lista zleceń, cyfrowe karty pracy, rejestracja materiałów, podpis klienta, zdjęcia, natychmiastowa synchronizacja z biurem.

Co aplikacja faktycznie robi

Sprowadzona do sedna aplikacja jest niemal nudno prosta — i to komplement. Technik otwiera ją rano i widzi swoje zlecenia na dany dzień, po kolei, z adresem, klientem, historią danej lokalizacji i tym, czego się od niego oczekuje. Wchodzi w zlecenie i wszystko, co kiedyś żyło na podkładce, żyje teraz na ekranie.

Na miejscu zapisuje wykonaną pracę z krótkiej listy kontrolnej, dodaje materiały z przeszukiwalnej listy (więc "kolanko miedziane 22 mm" to dwa dotknięcia, a nie zgadywanie pisowni), robi jedno czy dwa zdjęcia, jeśli coś trzeba udokumentować, i podaje telefon klientowi do podpisu palcem. Naciska "gotowe." To wszystko. Gdy tylko ma zasięg, wszystko synchronizuje się z biurem — żadnego telefonu, żadnego papieru, żadnego przepisywania.

Szczegół, który liczył się najbardziej: działa bez zasięgu

Aplikacje serwisu terenowego stoją lub upadają na jednej rzeczy, której demo nigdy nie pokazuje: co dzieje się w kotłowni w piwnicy bez zasięgu. Jeśli aplikacja się zawiesza lub traci dane w chwili, gdy znikają kreski, technicy porzucą ją w ciągu tygodnia, a Państwo zbudują kosztowny przycisk do papieru. Dlatego od pierwszego dnia zbudowaliśmy ją w podejściu offline-first. Wszystko działa w pełni bez połączenia; urządzenie przechowuje dane i synchronizuje je, gdy tylko może. Technik nigdy o tym nie myśli, i o to właśnie chodzi.

Strona biurowa: jeden ekran, żadnego przepisywania

Biuro nie dostało rozbudowanego pulpitu. Dostało jeden ekran pokazujący zlecenia w chwili ich ukończenia, każde z dołączoną kartą, materiałami, zdjęciami i podpisem. Stamtąd ukończone zlecenie staje się fakturą z już wypełnionymi danymi — biuro sprawdza ją i wysyła, zamiast przepisywać od zera. Połączyliśmy ją z programem do fakturowania, którego już używali, zamiast go zastępować, bo wymiana działającego oprogramowania w środku projektu to sposób, by dziesięciotygodniowe terminy zmieniły się w dziesięciomiesięczne.

Te dziesięć tygodni, szczerze

Dziesięć tygodni to nie magiczna liczba; to tyle, ile zajął ten zakres przy jednej parze projektant-programista i naprawdę zaangażowanym kliencie. Oto z grubsza, jak rozłożył się czas — łącznie z tygodniem, który straciliśmy, bo udawanie, że projekty idą bezbłędnie, nikomu nie pomaga.

1. 1
   Tydzień 1–2: Obserwuj, nie pytaj

   Jeździliśmy busem, siedzieliśmy w biurze i odwzorowaliśmy rzeczywisty przepływ pracy na ścianie. Spisaliśmy jednozdaniowy zakres i listę 'nie budujemy', i uzyskaliśmy akceptację obu jeszcze przed jakimkolwiek projektowaniem.
2. 2
   Tydzień 3–4: Klikalny kształt

   Zbudowaliśmy klikalny prototyp — bez prawdziwego kodu, same ekrany — i daliśmy go w ręce dwóch techników. Ich opinie wcześnie obaliły trzy nasze założenia, a to najtańsze miejsce na pomyłkę.
3. 3
   Tydzień 5–7: Budowa rdzenia

   Lista zleceń, cyfrowe karty, materiały, podpis, zdjęcia oraz silnik synchronizacji offline. Synchronizacja była trudną częścią i pochłonęła większość tygodnia 7.
4. 4
   Tydzień 8: Tydzień, który straciliśmy

   Integracja z fakturowaniem stawiała opór. Interfejs istniejącego oprogramowania był bardziej kapryśny, niż twierdziła dokumentacja, i spaliliśmy tydzień na czyste mapowanie pól. Warto było — przepisywanie było całym problemem, który rozwiązywaliśmy.
5. 5
   Tydzień 9–10: Pilotaż i szlifowanie

   Dwa busy używały aplikacji naprawdę, podczas gdy pozostałych sześć zostało przy papierze. Naprawiliśmy to, co ujawnił pilotaż, a potem wdrożyliśmy ją dla wszystkich na jednej krótkiej sesji szkoleniowej.

Jak sprawić, by pracownicy terenowi naprawdę z niej korzystali

Można zbudować najlepszą aplikację serwisu terenowego na świecie i patrzeć, jak umiera, bo 55-letni technik z dwudziestoletnią pamięcią mięśniową podkładki uzna, że to nie dla niego. Adopcja to nie problem techniczny i nie rozwiąże się jej funkcjami. Potraktowaliśmy ją jak prawdziwy projekt, którym jest.

Trzy rzeczy wykonały najcięższą pracę. Po pierwsze, sprawiliśmy, że przepływ na miejscu był szybszy niż papier, a nie tylko cyfrowy — mniej dotknięć niż bazgrania, materiały, które się wybiera zamiast literować, podpis zamiast gonienia za czytelnym. Gdyby aplikacja była choć odrobinę wolniejsza niż podkładka, słusznie by poległa. Po drugie, starannie wybraliśmy dwóch techników do pilotażu: jednego po cichu szanowanego przez resztę, jednego otwarcie sceptycznego. Pozyskanie sceptyka było warte więcej niż jakikolwiek marketing.

Po trzecie, nikt nie został potraktowany jak głupek. Szkolenie trwało dwadzieścia minut, aplikacja była celowo oczywista, a kierowniczka biura stała się punktem kontaktowym przez pierwsze dwa tygodnie, więc żaden technik nie czuł się zostawiony sam sobie. W ciągu trzech tygodni papierowe karty pracy zniknęły — nie zakazane, po prostu porzucone, bo aplikacja była naprawdę łatwiejszą drogą.

Co się zmieniło — rezultaty

Będziemy tu ostrożni, bo studia przypadku uwielbiają cytować precyzyjne liczby, które rozpadają się przy dopytywaniu. Te liczby to własne dane firmy, zebrane kilka miesięcy po wdrożeniu, i są kierunkowe, a nie laboratoryjne. Ale kierunek jest jednoznaczny i zgadza się z tym, co właściciel czuje na co dzień.

Nagłówek, na którym zależało właścicielowi, nie był jednak w tej tabeli. To była płynność finansowa. Gdy faktury wychodzą tego samego dnia, a nie tydzień później, pieniądze wpływają mniej więcej tydzień wcześniej w całej firmie — przy każdym pojedynczym zleceniu. Dla 24-osobowej firmy na cienkich marżach to przesunięcie w czasie liczyło się bardziej niż jakakolwiek pojedyncza wydajność. Odzyskane godziny biurowe były miłe. Płatność tydzień wcześniej, za każdym razem, była prawdziwą nagrodą.

Co powiedzielibyśmy Państwu, jeśli rozważacie to samo

Większość lekcji nie jest specyficzna dla serwisu terenowego. To, co powiedzielibyśmy każdej małej firmie kuszonej zamówieniem oprogramowania na zamówienie, i jest warte więcej niż sama aplikacja.

Zawężajcie zakres bezlitośnie i spiszcie listę "nie budujemy" przed listą tego, co budujecie. Obejrzyjcie prawdziwą pracę, zanim cokolwiek zaprojektujecie — właściciele opisują proces, który chcieliby mieć, a nie ten, który faktycznie prowadzą. Pilotujcie na małą skalę i pozwólcie sceptykom przekonać resztę. I łączcie się z narzędziami, których już używacie, zamiast je zastępować, przynajmniej na początku. Nic z tego nie jest sprytne. Wszystko razem sprawiło, że było możliwe dziesięć tygodni zamiast dziesięciu miesięcy.

Jeszcze jedna, ta cicha: aplikacja nigdy nie była celem. Celem było szybsze otrzymywanie zapłaty i zatrzymanie trzykrotnego wpisywania tych samych danych. Część tego moglibyśmy rozwiązać gotowymi narzędziami i dla niektórych firm to właściwy wybór. Dla tej chaotyczna mieszanka rejestracji na miejscu, realiów offline i istniejącego systemu fakturowania sprawiła, że skupiona budowa na zamówienie szybko się zwróciła. Szczera odpowiedź na pytanie "aplikacja czy gotowiec?" brzmi: to zależy, a kto odpowiada od razu, ten coś sprzedaje.

Częste pytania