Aplikacja do przeglądów floty: co zrobić z terminem, którego nikt nie przejął

Termin potrzebuje właściciela

W firmowym kalendarzu widnieje termin przeglądu pojazdu. Kierowca zakłada, że wizytę umówi dział administracji. Administracja czeka na informację, kiedy samochód wróci z trasy. Termin minie niezauważony nie dlatego, że nikt o nim nie wiedział, lecz dlatego, że nikt nie przejął następnego kroku.

Aplikacja do planowania przeglądów floty powinna łączyć informację o pojeździe z osobą odpowiedzialną, przygotowaniem wizyty i potwierdzeniem wykonania. Samo przypomnienie na telefonie nie mówi, czy warsztat przyjął termin, kto dostarczy pojazd ani co zrobi zespół, gdy samochód będzie potrzebny w pracy.

Przykłady w tym tekście są hipotetyczne. Mogą dotyczyć kilku pojazdów firmy usługowej lub większej floty działającej w wielu oddziałach. Szczegółowe zasady zależą od rodzaju pojazdów, kraju, umów i sposobu ich użytkowania. Projekt aplikacji zaczyna się od rozpoznania tych warunków, a nie od przypisania wszystkim pojazdom jednej uniwersalnej daty.

Rejestr, z którego da się zaplanować pracę

Dla każdego pojazdu ustalcie identyfikator, miejsce użytkowania oraz osobę lub zespół odpowiedzialny. Wpiszcie również informacje potrzebne do planowania: rodzaj pojazdu, sposób przypisania do pracy i dane kontaktowe opiekuna. Numer rejestracyjny może pomóc odnaleźć pojazd, lecz projekt powinien uwzględniać także zmianę numeru oraz sytuację, w której podobne pojazdy należą do różnych jednostek.

Oddzielcie stan pojazdu od stanu zadania. Samochód może być dostępny, przeznaczony do przeglądu albo wyłączony z użytkowania. Zadanie może czekać na umówienie, być zaplanowane lub wymagać wyjaśnienia po wizycie. Połączenie tych informacji powinno odpowiadać na praktyczne pytanie: czy można przydzielić pojazd do pracy w konkretnym czasie?

Jeśli firma ma kilka lokalizacji, zapiszcie, kto widzi flotę w całej organizacji, a kto jedynie pojazdy własnego oddziału. Centralny koordynator może potrzebować zbiorczego obrazu, ale kierowca nie zawsze potrzebuje danych o wszystkich współpracownikach. O wspólnych zasadach i różnicach lokalnych przeczytacie w tekście o systemie dla wielu oddziałów.

Nie każda informacja musi trafić do pierwszej wersji. Zastanówcie się, które pola są potrzebne do umówienia i potwierdzenia wizyty, a które służą jedynie późniejszej analizie. Zbyt szeroki formularz potrafi opóźnić wpisanie danych, na których rzeczywiście opiera się harmonogram.

Dobrze również zapisać zmiany w przypisaniu pojazdu. Jeżeli samochód przechodzi do innego oddziału, kto przejmuje rozpoczęte zadania i kontakt z warsztatem? Przeniesienie wpisu do nowej lokalizacji nie powinno automatycznie zamykać spraw oczekujących. Osoba przejmująca potrzebuje widzieć nie tylko datę, ale też ostatni potwierdzony krok i informacje potrzebne do jego kontynuacji.

Oddziel badanie techniczne od planu obsługi

W codziennej rozmowie słowo „przegląd” może oznaczać różne czynności: okresowe badanie techniczne, zaplanowaną obsługę w warsztacie lub sprawdzenie wskazane przez wewnętrzne zasady firmy. W aplikacji warto nazwać te zadania osobno i zapisać ich źródło. Inna osoba może odpowiadać za umówienie wizyty, a inna za potwierdzenie dokumentu po jej zakończeniu.

Ministerstwo Infrastruktury wskazuje, że badania okresowe odbywają się w odstępach zależnych od rodzaju pojazdu, a dodatkowe badania dotyczą odrębnych sytuacji. Dlatego system nie powinien obliczać terminu na podstawie jednej domyślnej reguły dla całej floty. Aktualne wymagania trzeba sprawdzić dla konkretnego pojazdu oraz właściwej jurysdykcji.

W Polsce dostępna jest usługa umożliwiająca właścicielowi lub posiadaczowi sprawdzenie danych pojazdu. Oficjalny opis zastrzega, że informacje przekazywane do ewidencji przez różne instytucje mogą nie być aktualne. Może to być pomocne źródło do porównania danych, ale nie oznacza automatycznie, że aplikacja firmy posiada dostęp integracyjny do rejestru. Możliwości i warunki dostępu trzeba ustalić osobno.

Dla obsługi serwisowej ustalcie, czy sygnałem jest data, wskazanie licznika lub inna informacja wynikająca z zasad użytkowania. Gdy aktualny przebieg nie został wprowadzony, system powinien pokazać brak danych, a nie udawać, że nic nie wymaga sprawdzenia. O jakości informacji przed automatyzacją piszemy w artykule o porządkowaniu danych.

Gdy harmonogram zależy od wskazania licznika, ustalcie sposób odczytu i datę jego zapisania. Warto pokazać, czy dane pochodzą od kierowcy, z urządzenia czy z dokumentu warsztatowego. Jeśli kolejne odczyty są sprzeczne, potrzebna jest kontrola człowieka oraz możliwość korekty z zachowaniem historii. Pozornie dokładna prognoza oparta na nieaktualnym przebiegu może utrudnić planowanie bardziej niż widoczny brak informacji.

Od przypomnienia do umówionej wizyty

Przy każdym zadaniu określcie osobę odpowiedzialną, termin działania i sposób zastępstwa. Przypomnienie może trafić do opiekuna pojazdu, lecz jeśli przez uzgodniony czas nie zostanie podjęte, potrzebna jest widoczna kolejka spraw do przejęcia. Zapis „powiadomiono” nie odpowiada na pytanie, czy ktokolwiek umówił wizytę.

Po wybraniu terminu wpiszcie miejsce, potwierdzony zakres i osobę, która dostarczy pojazd. Uzgodnijcie również, kiedy samochód przestaje być dostępny do pracy i kiedy może wrócić do planu. Jeżeli termin zostanie przesunięty, zmiana powinna dotrzeć do osoby planującej trasy oraz do kierowcy, którego dotyczy.

Sprawdźcie przypadek braku odpowiedzi warsztatu. Wysłanie zapytania nie jest równoznaczne z przyjęciem rezerwacji. Dopóki nie ma potwierdzenia, system powinien pokazywać stan oczekiwania i osobę odpowiedzialną za dalszy kontakt. Takie rozdzielenie pomaga uniknąć sytuacji, w której pojazd znika z grafiku, choć nikt go faktycznie nie przyjmie.

Jeśli planowanie obejmuje zgłoszenia napraw, warto rozróżnić zgłoszenie problemu od zatwierdzonego zlecenia i potwierdzonego wykonania. Podobny przepływ omawiamy w artykule o automatyzacji zleceń serwisowych. We flocie dodatkowo trzeba uwzględnić dostępność pojazdu i skutki zmiany terminu dla innych zadań.

Zastanówcie się, jak często system powinien ponawiać przypomnienie i kiedy przekazać sprawę zastępcy. Jeżeli osoba otrzymuje codziennie ten sam komunikat, ale nie ma dostępu do kalendarza warsztatu, sama liczba powiadomień nie umówi wizyty. Przypomnienie powinno prowadzić do działania, wskazywać termin decyzji oraz pozwalać odnotować rzeczywisty stan rozmowy.

Pojazd zastępczy i konsekwencje zmiany

Gdy samochód jest w warsztacie, jego wcześniejsze zadania nie znikają. Ustalcie, kto ocenia, czy potrzebny jest pojazd zastępczy, oraz jakie warunki musi spełnić. Inny samochód może nie mieć wyposażenia potrzebnego zespołowi albo znajdować się w innym mieście. Samo oznaczenie go jako wolnego nie wystarcza do potwierdzenia przydziału. Przydział samochodu zastępczego wymaga także sprawdzenia nakładających się terminów, o czym piszemy przy rezerwacji pojazdów i innych zasobów.

Przed zmianą planu sprawdźcie rezerwacje obu pojazdów. Jeżeli czas naprawy się wydłuży, system powinien pomóc wskazać zadania wymagające decyzji i osobę, która kontaktuje się z użytkownikami. Nie powinien automatycznie przenosić wszystkich zleceń bez sprawdzenia warunków. O planowaniu pracy między zespołami piszemy także przy aplikacji dla firmy usługowej.

Warto zaplanować również sytuację, w której warsztat zwraca pojazd wcześniej lub później niż przewidywano. Kto potwierdza jego odbiór? Czy powrót do dostępności następuje automatycznie, czy po sprawdzeniu wyniku? Czy kierowca potrzebuje dodatkowej informacji? Jasne odpowiedzi ograniczają liczbę telefonów i zapobiegają przydzieleniu auta, które nadal nie jest gotowe do pracy.

Jeśli pojazdy są współdzielone, dopiszcie sposób przekazania kluczy i dokumentów oraz osobę przyjmującą zwrot. Aplikacja może przechować status i instrukcję, ale nie zastąpi fizycznego przekazania. Dobrze, gdy ekran jasno pokazuje, które zadanie pozostaje do wykonania poza systemem.

Przed przydzieleniem zamiennika sprawdźcie również planowany moment jego zwrotu. Samochód wolny rano może być potrzebny innemu zespołowi po południu. Jeżeli zadanie nie ma jeszcze pewnej godziny zakończenia, warto pokazać tę niepewność i uzgodnić sposób aktualizacji. Właściciel floty powinien mieć możliwość podjęcia decyzji, a osoby korzystające z pojazdów otrzymać informację o zmianie.

Potwierdzenie wykonania i dalsze zadania

Po wizycie osoba odpowiedzialna powinna móc zapisać wynik, datę oraz źródło informacji. Jeśli konieczna jest dodatkowa naprawa albo dokument zawiera uwagi, zamknięcie samej wizyty nie powinno ukrywać nowego zadania. Ustalcie, kto je ocenia, do kiedy i jaki wpływ ma ono na dostępność pojazdu.

Dokumenty mogą być potrzebne różnym osobom, lecz nie muszą być widoczne dla każdego użytkownika. Ustalcie zakres dostępu, czas przechowywania i sposób poprawienia błędnie przypisanego pliku. Wprowadzając dane z dokumentu, zapiszcie również, kto je potwierdził. Jeśli dokument i wpis różnią się, potrzebna jest ścieżka wyjaśnienia zamiast automatycznego nadpisania.

Przy integracji z innymi narzędziami uzgodnijcie, który system przechowuje obowiązujący status i jak przekazywane są zmiany. O wyborze właściciela informacji piszemy w tekście o źródle danych w integracji. Jeżeli aktualizacja nie dotrze, osoba planująca pracę powinna zobaczyć problem i wiedzieć, kto zajmuje się jego wyjaśnieniem.

Historia powinna pozwalać odróżnić plan od wykonanego zadania. Wpis o zaplanowanej wizycie nie dowodzi jej odbycia, a zamknięcie zgłoszenia w jednym systemie nie zawsze oznacza gotowość pojazdu. Każdy status powinien odpowiadać uzgodnionemu zdarzeniu oraz osobie, która je potwierdza.

Przy odbiorze pojazdu można zapisać również informację, kto potwierdził przekazanie i jakie zadania pozostały otwarte. Jeśli dalsze działanie zależy od części lub dodatkowej wizyty, nie ukrywajcie go w polu swobodnej notatki dostępnym tylko jednej osobie. Przypiszcie zadanie odpowiedzialnemu zespołowi i uzgodnijcie, czy pojazd może być w tym czasie używany.

W innym procesie podobnego powiązania egzemplarza z wynikiem wymaga ewidencja przyrządów pomiarowych.

Sprawdź proces przed wdrożeniem

Przygotujcie kilka fikcyjnych pojazdów i przejdźcie cały scenariusz: zbliża się zadanie, opiekun je przejmuje, warsztat potwierdza wizytę, pojazd znika z dostępności i wraca po zatwierdzeniu wyniku. Następnie sprawdźcie brak odpowiedzi, przesunięcie terminu, nieobecność opiekuna oraz konieczność przydzielenia zastępstwa.

W próbach uwzględnijcie osoby, które naprawdę będą prowadzić flotę, a nie tylko zespół projektowy. Poproście kierowcę i koordynatora o wskazanie następnego kroku na podstawie widocznego stanu. Różne odpowiedzi mogą ujawnić niejasny komunikat lub brakującą decyzję. Pomocne zasady opisujemy przy testowaniu prototypu z pracownikami.

Zapiszcie również sposób odbioru: kto potwierdza wynik, które scenariusze obejmuje próba oraz co pozostaje poza pierwszą wersją. Jeśli zewnętrzny system jest symulowany, zanotujcie ograniczenie i zaplanujcie osobną próbę połączenia. Więcej o takich ustaleniach znajdziecie w tekście o kryteriach odbioru aplikacji.

Jeśli chcesz uporządkować plan przeglądów, zobacz zakres oprogramowania na zamówienie i skontaktuj się z Archifutura. W briefie opisz flotę, obecny sposób planowania, osoby odpowiedzialne oraz miejsce, w którym najczęściej ginie decyzja. Dane prawdziwych kierowców nie są potrzebne do pierwszej rozmowy.

Po uruchomieniu sprawdźcie także jakość wprowadzanych terminów. Jeśli część zadań jest regularnie zamykana bez potwierdzenia, trzeba wyjaśnić przyczynę z zespołem. Może brakować dostępu do dokumentu albo status wymagać zbyt wielu kroków. Korekta powinna obejmować sposób pracy i narzędzie, a jej wynik warto sprawdzić na kolejnych sprawach.

Warto wskazać właściciela zmian oraz termin ponownego przeglądu.