Firma serwisująca urządzenia medyczne — postanowiła zbudować własną aplikację dla serwisantów. Na co dzień pracuje na systemie ERP, który obsługuje magazyn i faktury oraz zlecenia serwisowe. Aplikację zespół chciał tworzyć we własnym zakresie, z pomocą narzędzi AI. Zanim powstała pierwsza linia kodu, poprosił nas o przygotowanie gruntu.
Spotkaliśmy się z pięcioosobowym zespołem klienta: właścicielem, administracją, kierownikiem serwisu i serwisantami. Każda z tych osób miała nieco inny obraz tego, czego aplikacja ma dotyczyć.
Ten sam problem, cztery perspektywy
Właściciel myślał o abonamencie „gotowości serwisowej” i o tym, żeby serwisanci przestali odbierać telefony w trakcie montażu. Wiele takich rozmów dotyczy obsługi, a nie awarii: wyłączonego kompresora, nieodłożonego ssaka i innych. Administracja chciała protokołów, z których da się bez dopytywania wystawić fakturę. Kierownik serwisu chciał wiedzieć, kto i gdzie jedzie, bo wspólny kalendarz przestawał wystarczać. Serwisant chciał jednego: wypełnić protokół szybko, często w rękawiczkach a czasem nawet w gabinecie bez zasięgu (bez dostępu do internetu).
Proces wyglądał tak: papierowy protokół (już ~17. wersja wzoru), zdjęcia części wysyłane do biura komunikatorem, a potem ręczne rozpisywanie jednego protokołu na kilka zleceń w Gestorze. Gdy na wizycie serwisant obsłużył dodatkowe urządzenie, biuro musiało o nim pamiętać, bo system go nie widział.
Jak pracowaliśmy
Odbyły się trzy sesje jednego dnia, łącznie około trzech i pół godziny. Na stole leżał prawdziwy, wypełniony protokół. Przeszliśmy go pole po polu i przy każdym pytaliśmy, kto je wypełnia, kiedy i po co.
Równolegle rysowaliśmy szkic procesu w notacji BPMN2.0: klient, firma i system jako osobne tory, a w firmie trzy etapy — rejestracja zgłoszenia, realizacja i rozliczenie. Rysunek szybko pokazał, że wszyscy mówią o tym samym procesie, ale zaczynają go w innym miejscu.
Najwięcej dały pytania przekorne. Czy serwisant może na miejscu zmienić numer seryjny urządzenia, jeśli tabliczka znamionowa nie zgadza się ze zgłoszeniem? Czy biuro może poprawić protokół, który klient już podpisał? Czy serwisant powinien widzieć ceny części, skoro klienci mają indywidualne rabaty? Każda odpowiedź stawała się wymaganiem.
Po każdej sesji zespół dostawał podsumowanie na piśmie, poprawiał je i na kolejnej sesji zaczynaliśmy od tych poprawek. Tak wyszła m.in. gwarancja zaznaczana przy każdej pozycji osobno, a nie dla całego protokołu. Dzięki temu jedna wizyta to jeden protokół zamiast dwóch: płatnego i gwarancyjnego.
Spór, który trzeba było rozstrzygnąć przed kodem
Najdłuższa dyskusja dotyczyła pozornie prostej rzeczy: czy protokół ma być jeden na wizytę, czy osobny na każde urządzenie. Serwisant nie wyobrażał sobie wypisywania sześciu protokołów przy przeglądzie sześciu unitów. Administracja potrzebowała osobnego zlecenia na każde urządzenie, bo tak działa Gestor i tak wygląda faktura.
Rozwiązanie zadowoliło obie strony: jeden ekran dla serwisanta, osobne zlecenia pod spodem. Data i dojazd wpisywane są raz, a zgłoszenie, diagnoza, czynności i części — dla każdego urządzenia osobno. Gdyby ta decyzja zapadła dopiero w trakcie programowania, oznaczałaby przebudowę modelu danych.
Efekt
Po jednym dniu zespół ma:
- podsumowanie z 51 wymaganiami w siedmiu obszarach, z propozycją priorytetów: co na start, co później, co w przyszłości,
- 27 szkiców historyjek dla pierwszego etapu, każdą z kryteriami akceptacji, ułożone na mapie procesu i ról,
- zasady pracy zespołu z AI, bo aplikację będzie tworzyć kilka osób w różnych narzędziach — wspólne repozytorium, przegląd każdej zmiany, brak dostępu AI do produkcji i danych klientów,
- listę decyzji i plan kolejnego warsztatu, z zadaniem domowym: test API nexo, wybór urządzenia pilotażowego i inne.
Zapadło też kilka decyzji kierunkowych. Start ma być prosty. Pilotaż ruszy na jednym dobrze znanym urządzeniu. Aplikacja zostanie postawiona na własnym serwerze. Kod gotowego produktu bazowego pozostaje nietknięty, zmiany idą przez własne moduły. Zespół postawił sobie też mierzalny cel: ograniczyć o około jedną piątą telefony, które dziś odrywają serwisantów od pracy. Pomiar stanu wyjściowego zaczyna się przed wdrożeniem, żeby efekt dało się później wykazać.
Ten przykład pokazuje, że narzędzia AI skracają pisanie kodu, ale nie skracają ustaleń. Nie rozstrzygną, czy protokół ma być jeden na wizytę ani kto może poprawić podpisany dokument. To muszą ustalić specjaliści, którzy będą z aplikacji korzystać i znają kontekst biznesowy definiowanych wymagań. Lepiej przy jednym stole niż w trzecim miesiącu programowania.