Program dla handlowca na Androida - zamówienia u klienta i praca offline

Program dla handlowca na Androida - zakres aplikacji

Program dla handlowca na Androida przenosi na telefon lub tablet to, co przedstawiciel handlowy dotąd nosił w segregatorze: kartotekę klienta wraz z historią zamówień oraz cennik, a także informację o dostępności towaru. Handlowiec spędza większość czasu poza biurem, więc każda wizyta u klienta jest okazją do złożenia zamówienia na miejscu, a nie po powrocie. Aplikacja dla handlowca zastępuje papierowe zamówienia oraz luźne notatki jednym narzędziem.

Rdzeniem takiego rozwiązania jest zwykle moduł CRM z interfejsem webowym, uzupełniony modułem na urządzenia z Androidem. Program CRM.net pozwala przeglądać zaplanowane wizyty jeszcze przed wyjazdem, wprowadzać notatki ze spotkań i zmieniać dane klienta na miejscu. Szerzej opisuje to strona o mobilnym CRM, a działanie można obejrzeć na demo CRM dla handlowca. Osobny materiał o wizytach i notatkach zawiera artykuł CRM Android.

Dla firm dystrybucyjnych i hurtowni ma to skutek mierzalny w procesie: zamówienie trafia do systemu centralnego w chwili zatwierdzenia, a nie kilka godzin po wizycie. Zmienia się też rola magazynu, który dostaje kompletne zlecenie z ceną i terminem zamiast wiadomości do przepisania.

Wybór między telefonem a tabletem zależy od stylu pracy. Telefon mieści się w kieszeni i wystarcza do szybkiego zamówienia w sklepie. Tablet ułatwia przegląd długiego cennika i pokazanie oferty klientowi przy stole, a większy ekran ogranicza pomyłki przy wyborze pozycji. Aplikacja działa na smartfonach i na tabletach, więc zespół może łączyć oba typy sprzętu bez zmiany procesu.

Zamówienie składane u klienta

Zamówienie u klienta przebiega w krótkiej, powtarzalnej kolejności. Handlowiec wybiera klienta z kartoteki, aplikacja podpowiada cennik i warunki przypisane do tego kontrahenta, a następnie handlowiec dodaje pozycje. Przed zatwierdzeniem sprawdza dostępność każdej pozycji, po czym zamówienie trafia do kolejki wysyłki. Dopiero potwierdzenie z serwera zmienia jego status na przyjęte.

1. Wybór klienta - kartoteka z warunkami handlowymi oraz adresami dostaw, a także historią poprzednich zamówień.
2. Dodawanie pozycji - wyszukiwanie po nazwie lub indeksie albo skan kodu kreskowego aparatem.
3. Kontrola dostępności - informacja o stanie magazynowym z czasem ostatniej synchronizacji.
4. Zatwierdzenie i wysłanie - zamówienie ląduje w kolejce urządzenia i jest przekazywane do ERP oraz modułu kompletacji.

Jeśli kartoteka klienta zawiera kilka adresów dostaw, aplikacja pozwala wskazać właściwy jeszcze przed zatwierdzeniem, bo zmiana adresu po wysyłce wymaga już korekty zamówienia w systemie centralnym. Kolejność ma znaczenie dla poprawności danych. Cena zapisana w pozycji zamówienia powinna być tą, którą klient zobaczył przy składaniu, a nie ceną odczytaną ponownie po synchronizacji. Inaczej zmiana cennika w ciągu dnia zmieniłaby wartość zamówienia, które klient już zaakceptował.

Reguła: cena i rabat są zapisywane w pozycji zamówienia w chwili jego złożenia i nie zmieniają się przy późniejszej synchronizacji cennika.

Po stronie magazynu zamówienie przechodzi do kompletacji, którą opisuje osobny materiał o programie do kompletacji. Integracja z systemem magazynowym i ERP jest tu warunkiem spójności, o czym mówi artykuł o integracji systemów magazynowych.

Cenniki i rabaty w aplikacji handlowca

Cennik w aplikacji terenowej musi być dostępny bez połączenia, więc jego kopia leży na urządzeniu. To oznacza konieczność synchronizacji zmian, a nie pobierania całego cennika przy każdym połączeniu. Cennik dużej hurtowni liczy dziesiątki tysięcy pozycji i wysłanie go w całości przez sieć komórkową jest zbędnym obciążeniem.

Synchronizacja przyrostowa cennika

Wygodnym mechanizmem jest znacznik wersji wiersza. W SQL Server służy do tego typ ROWVERSION, którego wartość rośnie przy każdej zmianie wiersza w bazie. Urządzenie zapamiętuje ostatnią odebraną wersję i przy kolejnym połączeniu prosi tylko o pozycje o wersji wyższej. Poniższy schemat jest przykładowy, a nazwy obiektów nie odpowiadają bazie konkretnego produktu.

CREATE TABLE dbo.CennikPozycja (
    CennikId  INT           NOT NULL,
    Indeks    VARCHAR(40)   NOT NULL,
    CenaNetto DECIMAL(12,2) NOT NULL,
    WaznaOd   DATE          NOT NULL,
    WaznaDo   DATE          NULL,
    Wersja    ROWVERSION    NOT NULL,
    PRIMARY KEY (CennikId, Indeks, WaznaOd)
);

-- zmiany od ostatniej synchronizacji urządzenia
SELECT CennikId, Indeks, CenaNetto, WaznaOd, WaznaDo, Wersja
FROM dbo.CennikPozycja
WHERE Wersja > @OstatniaWersja      -- BINARY(8) zapamiętane na urządzeniu
ORDER BY Wersja;

Zapytanie nie zwróci pozycji usuniętych, ponieważ zniknięty wiersz nie ma wersji. Usunięcie cennika lub pozycji wymaga więc znacznika w tabeli, na przykład kolumny z datą wycofania, którą urządzenie odbiera jak każdą inną zmianę. Zakres ważności (od i do) pozwala trzymać kilka wersji ceny i wybierać tę, która obowiązuje w dniu zamówienia.

Stany magazynowe w aplikacji handlowca

Podgląd stanów magazynowych odpowiada na pytanie klienta, czy towar jest dostępny, zanim handlowiec potwierdzi zamówienie. Handlowiec nie potrzebuje stanu fizycznego, tylko dostępnego, czyli pomniejszonego o rezerwacje pod inne zamówienia. Różnicę między stanem fizycznym a dostępnym opisuje artykuł o stanach magazynowych.

Stan w aplikacji jest informacją z chwili synchronizacji, a nie danymi na żywo. Poza zasięgiem wyświetla się więc ostatnia znana wartość, a interfejs pokazuje godzinę jej pobrania. Ostateczną decyzję o dostępności podejmuje serwer w chwili przyjęcia zamówienia, gdy sprawdza aktualny stan i rezerwuje towar. Jeśli towaru zabrakło w czasie, gdy handlowiec był poza siecią, zamówienie wraca ze statusem wymagającym korekty.

Ta sama platforma mobilna może obsługiwać handlowców i magazynierów, co upraszcza utrzymanie. Aplikacja magazynowa opisana w artykule o Android WMS i praca na kolektorach danych korzystają z tych samych zasad logowania i synchronizacji, więc dział IT prowadzi jedną platformę zamiast kilku osobnych aplikacji. Podejście omawia także tekst o systemie mobilnej obsługi magazynu.

Praca offline i synchronizacja danych

Praca w terenie oznacza przerwy w zasięgu, więc aplikacja zapisuje dane lokalnie na urządzeniu i wysyła je do systemu centralnego po odzyskaniu połączenia z Internetem. Handlowiec może w tym czasie wypełniać zamówienia i przeglądać cennik, a także dodawać notatki. Zapis lokalny przechowuje się zwykle w bazie SQLite, a wysyłką zajmuje się kolejka zadań w tle.

Dobrą praktykę opisują materiały dla programistów: Android udostępnia mechanizm WorkManager do zadań wykonywanych w tle z ponawianiem, a wzorzec pracy bez sieci opisuje przewodnik o aplikacjach offline-first. W obu przypadkach źródłem prawdy dla interfejsu jest baza lokalna, a sieć jest tylko sposobem jej uzupełniania.

Kolejka wysyłki i ponowne wysłanie zamówienia

Największym zagrożeniem synchronizacji jest zdublowane zamówienie. Gdy połączenie zerwie się po wysłaniu, a przed odebraniem potwierdzenia, aplikacja nie wie, czy serwer przyjął zamówienie, i wysyła je ponownie. Rozwiązaniem jest klucz nadawany na urządzeniu w chwili zatwierdzenia i unikalny na serwerze. Powtórna próba trafia wtedy na ten sam klucz i nie tworzy drugiego rekordu.

CREATE TABLE dbo.ZamowienieTeren (
    ZamowienieId INT IDENTITY(1,1) PRIMARY KEY,
    KluczKlienta UNIQUEIDENTIFIER NOT NULL UNIQUE,  -- GUID nadany na urządzeniu
    KlientId     INT      NOT NULL,
    HandlowiecId INT      NOT NULL,
    DataZlozenia DATETIME2(0) NOT NULL
);

BEGIN TRY
    INSERT INTO dbo.ZamowienieTeren (KluczKlienta, KlientId, HandlowiecId, DataZlozenia)
    VALUES (@KluczKlienta, @KlientId, @HandlowiecId, @DataZlozenia);
END TRY
BEGIN CATCH
    -- 2601 i 2627: naruszenie unikalności, czyli ponowne wysłanie tego samego zamówienia
    IF ERROR_NUMBER() NOT IN (2601, 2627) THROW;
END CATCH;

Data zamówienia pochodzi z zegara urządzenia, więc serwer zapisuje także czas odbioru i oznacza zamówienia, w których różnica przekracza ustaloną granicę. Serwer odpowiada w obu przypadkach potwierdzeniem, więc urządzenie usuwa zamówienie z kolejki. Taka odpowiedź nazywa się idempotentną, bo wielokrotne wykonanie operacji daje ten sam wynik co pojedyncze. Ponawianie odbywa się z rosnącym odstępem, aby słaba sieć nie była obciążana serią prób co sekundę.

Konflikty danych rozstrzyga się według prostej reguły. Dla cen i stanów pierwszeństwo ma serwer, bo jest jedynym źródłem aktualnych wartości. Dla notatek z wizyt i zamówień wygrywa urządzenie, bo dane powstały w terenie i nikt inny ich nie zmienia. Zasada ta jest podstawą projektu synchronizacji, a odstępstwa wymagają osobnej decyzji.

Wymagania sprzętowe i bezpieczeństwo danych

Aby aplikacja działała stabilnie w terenie, urządzenie handlowca powinno spełniać kilka warunków sprzętowych i systemowych. Parametry zależą od skali kartoteki i liczby pozycji w cenniku, dlatego przed zakupem sprawdza się je na pilotażowej grupie handlowców.

• System operacyjny - wersja Androida wspierana przez producenta urządzenia, z bieżącymi poprawkami bezpieczeństwa.
• Łączność - transmisja danych mobilnych lub Wi-Fi do synchronizacji, przy czym sama praca z aplikacją musi być możliwa również offline.
• Czytnik kodów - wbudowany aparat lub zewnętrzny skaner do weryfikacji towaru u klienta.
• Zabezpieczenie danych - blokada ekranu oraz szyfrowanie pamięci, a także możliwość zdalnego wylogowania po zgubieniu telefonu.

Dane klientów obejmują często dane osobowe osób kontaktowych, więc zgubione urządzenie to potencjalny incydent. Szyfrowanie pamięci i zdalne wylogowanie ograniczają skutki, a zarządzanie kontami można oprzeć na domenie firmowej: program CRM.net integruje się z Active Directory, dzięki czemu hasła i konta obsługuje się standardowo. Firmy korzystające jednocześnie z aplikacji handlowej i magazynowej często ujednolicają park urządzeń, co upraszcza serwis i wymianę sprzętu, a także szkolenie nowych osób.

Wdrożenie i raportowanie pracy handlowców

Wdrożenie aplikacji dla zespołu sprzedaży przebiega w kilku etapach, niezależnie od wielkości zespołu. Zaczyna się od analizy procesu sprzedaży, w której ustala się, jakie dane handlowiec musi mieć pod ręką i jakie dokumenty wystawia w terenie. Potem następuje konfiguracja integracji z ERP i CRM oraz z systemem magazynowym, tak aby dane płynęły w obu kierunkach bez przepisywania.

1. Analiza procesu sprzedaży - zakres danych i dokumentów wystawianych w terenie.
2. Konfiguracja integracji - połączenie z ERP i CRM oraz z magazynem w obu kierunkach.
3. Instalacja i szkolenie - wgranie aplikacji i założenie kont, a także ćwiczenie na rzeczywistych zamówieniach.
4. Wsparcie po wdrożeniu - pomoc techniczna i aktualizacje dopasowane do zmian w procesie.

Taki przebieg ogranicza sytuację, w której nowe narzędzie jest używane częściowo, a zespół nadal prowadzi część dokumentacji po staremu. Skraca ją sprawnie wdrożony system CRM razem z aplikacją mobilną. Wariant bez własnej infrastruktury serwerowej opisuje strona o CRM opartym na chmurze. Rozwiązanie po stronie producenta można sprawdzić na demo CRM SoftwareStudio.

Raportowanie pracy zespołu terenowego

Kierownik sprzedaży nie widzi na bieżąco przebiegu wizyt, więc aplikacja rejestruje liczbę odwiedzonych klientów i złożonych zamówień oraz czas poświęcony na zadania. Dane można pogrupować według regionu lub przedstawiciela, a także kategorii produktu, co pozwala zestawić wyniki handlowców bez ręcznego raportu na koniec miesiąca. Analiza tych danych wspiera też planowanie tras: klienci o wyższej wartości zamówień są odwiedzani częściej, a mniej aktywne punkty trafiają do rzadszego harmonogramu.

Rozwiązanie sprawdza się tam, gdzie sprzedaż odbywa się poza biurem, a decyzje trzeba podejmować u klienta. Dotyczy to dystrybucji i hurtu, ale też branż o dużej liczbie indeksów i częstych zmianach cen, w których cennik zawsze zsynchronizowany z serwerem chroni przed pracą na nieaktualnych danych.