System kart pracy dla firmy elektrycznej zamiast papieru
Karty pracy wypełniane z telefonu zaraz po zleceniu, akceptowane w panelu przez biuro i eksportowane do CSV. Papierowy druk wypadł z obiegu.
- Klient
- FUR Dorian
- Branża
- Instalacje elektryczne
- Czas realizacji
- niecałe 3 tygodnie do startu produkcyjnego
- Technologie
- Laravel
- MySQL
- Laravel Cloud

Wyzwanie
Ekipy wypełniały papierowe karty pracy długopisem, rozpisując z ręki skład brygady i zużyty materiał, a kwity wracały do biura bez żadnej reguły.
Co dostarczyliśmy
- Panel z rolami, dostępami i logowaniem 2FA
- Karta pracy wypełniana z telefonu w przeglądarce
- Eksport CSV do systemów klienta zamiast integracji
FUR Dorian to firma elektryczna z kilkoma ekipami w terenie - serwis, instalacje i wsparcie na obiektach klientów. Ludzie jeżdżą po zleceniach kilkoma autami serwisowymi, a każdy wyjazd kończy się kartą pracy.
Karta była drukiem. Po skończonej robocie ktoś z ekipy wypełniał ją długopisem: do kogo pojechali, jakim autem, kto był w składzie, kiedy zaczęli i skończyli, co zużyli. Dwa z tych pól nie były polami, tylko listami - skład brygady i zestawienie materiału potrafiły zająć pół kartki.
Kwity wracały do biura wtedy, kiedy wracały. Czasem po trasie, czasem pod koniec miesiąca, razem z całą stertą. Dopiero wtedy ktoś przepisywał je do systemów, którymi firma rozlicza robociznę i materiał. Problemem nie był papier sam w sobie, tylko to, że przez ten czas biuro nie wiedziało, co się na zleceniach wydarzyło.
Od czego zaczęliśmy
Od druku, nie od ekranów. Przeszliśmy przez kartę pole po polu i przy każdym pytaliśmy, kto tę informację czyta i co z nią potem robi.
Wyszły dwie rzeczy, których nie było w opisie zlecenia:
- Większość pól to proste dane, które da się wybrać zamiast wpisywać - klient, auto, data. Cała praca siedziała w dwóch polach listowych: składzie brygady i zestawieniu materiału. To one decydowały, czy karta powstaje na miejscu, czy „później się uzupełni“.
- Biuro nie potrzebowało kolejnego systemu do rozliczeń. Potrzebowało, żeby dane z karty dało się wprowadzić do systemów, które firma już ma.
Druga obserwacja przesądziła o zakresie, i to w kierunku odwrotnym, niż zwykle idą takie projekty.
Co zbudowaliśmy
Panel w przeglądarce, bez aplikacji do zainstalowania. Pracownik po skończonym zleceniu loguje się z telefonu i wypełnia kartę na miejscu, zanim wsiądzie do auta. Administrator widzi ją w tej samej chwili - może zaakceptować, poprawić albo odesłać z pytaniem.
Dostępy rozdzielone są rolami: pracownik pracuje na swoich kartach, administrator widzi całą firmę i zarządza użytkownikami, autami oraz bazą klientów. Logowanie chroni drugi składnik - kod z aplikacji uwierzytelniającej. To panel z danymi handlowymi klientów, otwierany z dowolnej przeglądarki na dowolnym telefonie, więc samo hasło było za mało.
Klient wpisany z ręki albo wybrany z bazy
Największe ryzyko takiego formularza jest banalne: pracownik stoi na obiekcie, klienta nie ma w bazie, formularz go nie przepuszcza. Wtedy karta ląduje „na potem“, czyli w tym samym miejscu co papier.
Pole klienta działa więc dwutorowo. Jeśli firma jest już w bazie, wystarczy wpisać kilka pierwszych znaków nazwy i wybrać ją z podpowiedzi - zlecenie łączy się z profilem i wchodzi do jego historii. Jeśli jej nie ma, pracownik wpisuje nazwę z ręki i jedzie dalej, a biuro dopina profil później. Formularz nigdy nie jest powodem, żeby nie wypełnić karty.
Eksport CSV zamiast integracji
Klient nie chciał wpinać panelu bezpośrednio w swoje systemy i miał ku temu powód: integracja to koszt po obu stronach i związanie się z jednym układem na lata. Stanęło na kompromisie - biuro akceptuje karty w panelu i eksportuje je do pliku CSV, który wchodzi do systemów firmy tak samo jak każdy inny import.

Nikt nie sprzedawał tego jako rozwiązania docelowego. Jest tańsze, powstało od razu i niczego nie zamyka: jeśli firma zdecyduje się kiedyś na bezpośrednie połączenie, dane są już w jednym miejscu i w jednym formacie.
Jak poszło wdrożenie
Pierwsza działająca wersja powstała w tydzień i klient dostał ją do obejrzenia, zanim cokolwiek zapłacił. Łatwiej ocenić ekran niż zakres spisany zdaniami, zwłaszcza gdy rozmawiamy z kimś, kto nie zamawiał wcześniej oprogramowania.
Kolejne dwa tygodnie poszły na spięcie całości i testy na prawdziwych zleceniach. Po niecałych trzech tygodniach ekipy wypełniały karty w panelu, a druk został w segregatorze.
Co się zmieniło po starcie
Uczciwie o pomiarze: firma nie prowadziła statystyk sprzed wdrożenia. Nie mamy więc porównania w rodzaju „wcześniej zajmowało to tyle, teraz tyle“, a liczby pod tym tekstem opisują stan po starcie, nie oszczędność wyliczoną z danych klienta.
Zmiana, której nie da się zapisać liczbą, jest taka: karta przestała być dokumentem docierającym do biura z opóźnieniem. Biuro widzi ją tego samego dnia i może dopytać o szczegół, kiedy ktoś jeszcze pamięta zlecenie, a nie trzy tygodnie później nad stertą kwitów.
Zakres urósł w trakcie. Kiedy panel zaczął działać na żywo, okazało się, że administrator musi w nim zarządzać także użytkownikami i autami - a tego w ustaleniach nie było, bo na papierowej karcie takie rzeczy po prostu nie istnieją. Dołożyliśmy to bez dopłaty, uznając, że panel bez własnej administracji i tak wróciłby do nas przy pierwszej zmianie w ekipie.
Wniosek na przyszłość: druk pokazuje, co pracownik zapisuje, ale milczy o tym, kto tym wszystkim zarządza. Słowniki, role i dostępy trzeba wliczać w zakres od pierwszego dnia, nawet jeśli nikt o nich nie mówi.
Efekty w liczbach
- 0
- kart pracy przepisywanych ręcznie w biurze
- 7
- pól papierowego druku w jednym formularzu