Aplikacja terenowa offline: co może zrobić pracownik bez zasięgu

Technik dociera do urządzenia w podziemnej części zakładu. Ma ze sobą telefon, listę kontroli i zdjęcia potrzebne do dokumentacji. Nie ma za to zasięgu. Jeśli aplikacja pozwala tylko wyświetlić ekran błędu, technik wraca do notatek na kartce albo robi zdjęcia osobno. Potem ktoś musi przepisać informacje, często już po zakończeniu zmiany.

Aplikacja terenowa offline może pomóc inaczej: przygotować potrzebne dane przed wyjazdem, zapisać efekty pracy na urządzeniu i przekazać je do systemu po odzyskaniu połączenia. Każda z tych czynności wymaga osobnej decyzji. Sam przycisk „synchronizuj” nie odpowie na pytanie, co zrobić z poprawką, którą w międzyczasie wprowadził dyspozytor.

Opisane niżej sytuacje są hipotetyczne. Pasują do pracy serwisu, budowy, transportu czy energetyki, ale szczegóły zależą od procesu, urządzeń i rodzaju danych. Najpierw ustalmy więc, co człowiek ma zrobić bez sieci. Technologię wybierzemy na podstawie tej odpowiedzi.

Które zadania muszą działać bez internetu?

Zacznijcie od jednego dnia pracy. Osoba wyruszająca w teren może potrzebować adresu, opisu zlecenia, historii urządzenia i instrukcji. Na miejscu sprawdza stan, uzupełnia pomiary, zapisuje uwagi, a czasem robi zdjęcie. Po wykonaniu zadania przekazuje informację dalej. Rozpiszcie tę drogę i zaznaczcie momenty, w których utrata internetu zatrzymuje pracę albo zmusza do obejścia procesu.

Nie wszystko musi być dostępne bez połączenia. Przygotowanie porannej listy zleceń może wymagać sieci, jeśli zespół zwykle rozpoczyna dzień w biurze. Z kolei wpisanie pomiaru w hali, w której sygnał regularnie zanika, powinno działać także wtedy, gdy telefon jest odcięty od serwera. Różnica brzmi drobno, ale ma duże znaczenie dla zakresu projektu.

W aplikacji dla ekip energetycznych ważne mogą być schemat urządzenia i historia kontroli. Na budowie pojawią się oznaczenie miejsca oraz zdjęcia, co opisaliśmy przy obsłudze usterek i odbiorów. W transporcie znaczenie mają inne dokumenty i punkty przekazania. Przykłady pomagają zadać pytania, ale nie zastępują obserwacji konkretnej pracy.

Zaproście do rozmowy pracowników terenowych i osoby odbierające ich zgłoszenia. Zapytajcie, co naprawdę musi znaleźć się na ekranie przed wyjazdem, jak często zmienia się plan i które informacje bywają nieaktualne. Osoba planująca trasę może uznać adres za oczywisty, podczas gdy technik potrzebuje jeszcze instrukcji wejścia, numeru urządzenia i informacji o osobie kontaktowej.

Przy planowaniu zapiszcie również, czego pierwsza wersja świadomie nie obejmuje. Jeżeli pracownik może dodać opis, ale podpis klienta będzie obsługiwany później, powinno to wynikać z ustaleń i instrukcji. Dzięki temu brak funkcji nie wygląda jak awaria.

Zapis lokalny i uczciwy status pracy

Informacja wpisana bez sieci powinna pozostać dostępna na urządzeniu po zamknięciu i ponownym otwarciu aplikacji, jeśli taki przypadek uzgodniono w wymaganiach. Sam widok formularza nie daje jeszcze pewności trwałego zapisu. Trzeba ustalić, kiedy dane są utrwalane, jak zachować zdjęcia i co zrobić, gdy pamięć urządzenia się kończy.

Użytkownik powinien odróżnić trzy sytuacje: dane zapisano lokalnie, dane są wysyłane oraz serwer potwierdził ich przyjęcie. Dopiero ostatni stan pozwala powiedzieć, że informacja dotarła do systemu centralnego. Jeśli pojawia się błąd, ekran powinien wyjaśnić, czego nie udało się przekazać i jakie działanie jest możliwe. Zielony znaczek bez opisu bywa ładny, ale nie pomoże ustalić losu protokołu.

Zastanówcie się też, co może zobaczyć dyspozytor. Gdy technik zapisze wynik bez sieci, centrala jeszcze go nie zna. Widoczny tam status nie może udawać, że pokazuje wszystkie zmiany. Odpowiedni komunikat o czasie ostatniego potwierdzenia pomoże uniknąć rozmowy zaczynającej się od pytania: „Dlaczego ja widzę coś innego?”.

To samo dotyczy danych pobranych wcześniej. Aplikacja może pokazać zapamiętaną instrukcję, ale powinna podać, kiedy ją pobrano. W sprawach, w których aktualność instrukcji ma znaczenie dla bezpieczeństwa pracy, organizacja musi osobno zdecydować, czy wolno kontynuować zadanie na podstawie starszych informacji i jak sprawdzić wyjątek.

Co się dzieje po powrocie połączenia

Po odzyskaniu sieci aplikacja powinna wiedzieć, które zmiany czekają na przekazanie i w jakiej kolejności je obsłużyć. Jeśli powiązane zdjęcie wysyła się dłużej niż opis usterki, dobrze uzgodnić, czy zgłoszenie można przyjąć częściowo oraz jak pokazać brakujący materiał. W przeciwnym razie pracownik zobaczy „gotowe”, a odbiorca nie znajdzie dokumentu potrzebnego do oceny sytuacji.

Połączenie potrafi zniknąć również w trakcie wysyłki. Serwer może przyjąć żądanie, zanim telefon otrzyma potwierdzenie. Ponowienie bez odpowiedniego projektu mogłoby utworzyć drugie zgłoszenie. Dlatego warto uzgodnić sposób rozpoznania tej samej operacji oraz sprawdzenia jej wyniku po odzyskaniu połączenia. Samo ponawianie nie jest uniwersalnym zabezpieczeniem przed duplikatem.

Gdy systemy wymieniają informacje także z innymi usługami, zakres synchronizacji trzeba sprawdzić od początku do końca. W automatyzacji zleceń serwisowych przyjęcie notatki może uruchomić kolejne zadanie. Projekt powinien określić, czy jest gotowa do działania, czy czeka jeszcze na brakujące zdjęcia albo weryfikację.

Nie zakładajcie, że wszystkie urządzenia działają identycznie w tle. MDN opisuje mechanizmy pracy bez połączenia w aplikacjach webowych, a szczegóły dostępności funkcji zależą od przeglądarki i platformy. Na etapie projektu trzeba sprawdzić wspierane urządzenia oraz to, czy wysyłka wymaga ponownego otwarcia aplikacji. Obietnica „zawsze samo się wyśle” wymaga potwierdzenia w konkretnych warunkach, nie samej dobrej woli.

Kiedy dwie osoby zmienią tę samą sprawę

Załóżmy, że technik offline zapisuje wymianę części, a dyspozytor tymczasem zmienia termin zlecenia. Te informacje mogą dać się połączyć, ponieważ dotyczą różnych pól. Inaczej jest, gdy dwie osoby wpiszą różne wyniki tego samego pomiaru. Automatyczne pozostawienie ostatniej wartości mogłoby ukryć ważną różnicę.

Dla każdej istotnej zmiany określcie regułę: połączyć bez pytania, zachować obie wersje do rozstrzygnięcia czy poprosić użytkownika o wybór. Dobrze pokazać nie tylko dwie wartości, ale też autora, czas i kontekst zmiany, o ile system może je wiarygodnie udostępnić. Decyzja powinna trafić do osoby rozumiejącej proces, niekoniecznie do tej, która jako ostatnia odzyskała zasięg.

W firmie logistycznej może chodzić o zmianę miejsca dostawy, w utrzymaniu ruchu o stan urządzenia, a na budowie o status usterki. W każdym przypadku inne są konsekwencje błędu. Przykład procesu przekazania danych opisaliśmy przy dokumentach przewozowych. Nie warto kopiować reguły z jednego procesu do drugiego bez rozmowy z zespołem.

Dane na urządzeniu i urządzenie w terenie

Praca offline oznacza, że część danych znajduje się poza centralnym systemem. Uzgodnijcie, kto może korzystać z urządzenia, jakie informacje są przechowywane i jak długo pozostają po synchronizacji. Telefon używany przez kilku pracowników wymaga innego podejścia niż urządzenie przypisane jednej osobie. Zaplanujcie też postępowanie po zgubieniu telefonu oraz po odebraniu dostępu pracownikowi.

Sprawdzenie uprawnień w chwili połączenia nie rozwiązuje automatycznie sytuacji, w której urządzenie przez dłuższy czas pozostaje bez sieci. Potrzebna jest decyzja, jak długo można pracować na wcześniej pobranych danych i co ma się stać po ponownym połączeniu. Odpowiedź zależy od wrażliwości informacji oraz rzeczywistych warunków pracy, a nie od jednej uniwersalnej liczby dni.

Ograniczajcie ilość danych pobieranych na urządzenie do tych potrzebnych do zadania. Przy zdjęciach ustalcie, czy mają pozostać w pamięci po wysłaniu i kto może je zobaczyć. Przedstawcie te zasady pracownikom prostym językiem. Skomplikowana procedura, której nikt nie zna w chwili zgubienia telefonu, pozostaje tylko dokumentem.

Zaplanuj przygotowanie do wyjazdu

Tryb offline zaczyna się często jeszcze przy dobrym połączeniu. Przed opuszczeniem biura lub bazy aplikacja może pobrać przydzielone sprawy, aktualną listę urządzeń oraz materiały potrzebne w danym dniu. Ważne, żeby pracownik wiedział, czy przygotowanie się zakończyło. Jeśli pobranie przerwało się w połowie, komunikat powinien wskazać brakujące elementy i pozwolić spróbować ponownie.

Uzgodnijcie, co zrobić z pilnym zleceniem dodanym po wyjeździe pracownika. Dopóki urządzenie nie odzyska połączenia, centrala nie ma pewnego sposobu przekazania aktualizacji przez samą aplikację. W niektórych zespołach potrzebny będzie ustalony kanał awaryjny lub zmiana planowania. To decyzja operacyjna, którą system powinien wspierać czytelnym stanem danych, a nie ukrywać pod słowem „synchronizacja”.

Nie pobierajcie na zapas całej historii firmy tylko dlatego, że dane mogą się kiedyś przydać. Zespół powinien określić sensowny zakres dla przydzielonych zleceń, a potem sprawdzić go w praktyce. Jeżeli do naprawy regularnie potrzebne są starsze protokoły, można zmienić zakres pobierania po analizie realnych potrzeb. W ten sposób ograniczenia pamięci i dostępu stają się częścią projektu zamiast niespodzianką podczas pierwszego wyjazdu.

Gdy synchronizacja i zasady konfliktów są już gotowe, każdą zmianę trzeba jeszcze bezpiecznie przekazać użytkownikom. Przygotowanie takiej operacji opisujemy w artykule o wdrażaniu wersji aplikacji i planie powrotu.

Ustal, kto zamyka sprawę

Czynność wykonana w terenie i sprawa zamknięta w firmie nie zawsze są tym samym. Technik może zakończyć oględziny, a koordynator nadal potrzebować oceny zdjęć albo zamówienia części. Warto nazwać te etapy osobno: wykonanie kontroli, przekazanie danych i decyzję o dalszym postępowaniu. Osoba w terenie ma wtedy jasność, czy może zakończyć pracę na miejscu.

W ćwiczeniu odbiorowym poproście pracownika o zapis wyniku bez połączenia, a drugą osobę o odczytanie sprawy w systemie centralnym. Niech obie opiszą, co ich zdaniem już się wydarzyło. Różnica w odpowiedziach wskazuje miejsce, w którym przyda się lepszy komunikat lub doprecyzowanie procesu. Nie wymaga znajomości kodu i może ujawnić problem, którego nie wykryje sam test techniczny.

Sprawdź działanie tam, gdzie pracuje zespół

Test w biurze zacznijcie od pobrania przykładowego zlecenia, wyłączenia sieci i zapisania kilku zmian. Potem zamknijcie aplikację, otwórzcie ją ponownie i sprawdźcie stan danych. Następnie przywróćcie sieć, przerwijcie ją w trakcie wysyłki i porównajcie wynik na urządzeniu oraz w systemie centralnym. W teście używajcie danych przygotowanych do tego celu.

Przetestujcie także dwa urządzenia pracujące na tej samej sprawie, pełną pamięć, błędny format zdjęcia i wygaśnięcie uprawnień. Wynik powinien opisywać zachowanie użytkownika oraz oczekiwany stan systemu, nie tylko to, czy serwer odpowiedział. Podczas testu prototypu z pracownikami obserwujcie, czy potrafią rozpoznać, które zlecenia są już przekazane.

Na koniec sprawdźcie reprezentatywne urządzenia i warunki pracy w terenie. Rękawice, ostre światło czy niestabilny sygnał wpływają na zadanie inaczej niż wygodne biurko. W aplikacji produkcyjnej powiązanej ze zleceniami i przestojami dodatkowo ustalcie, czy zmiana ma trafić do planisty od razu po odzyskaniu sieci, czy dopiero po zatwierdzeniu.

Wybór między aplikacją mobilną a rozwiązaniem webowym warto podjąć po ustaleniu tych potrzeb. Ich porównanie znajdziesz w tekście aplikacja webowa, PWA czy mobilna. Jeżeli planujesz własną aplikację dla zespołu terenowego, możesz wysłać krótki brief: opisz zadania bez zasięgu, używane urządzenia i system, do którego mają wrócić dane. Na tej podstawie łatwiej omówić pierwszy zakres oraz sposób jego sprawdzenia.