Platforma telematyczna pokazuje, gdzie jest pojazd. ERP wie, ile kosztuje. TMS wie, co ma przewieźć. Dopóki te trzy systemy nie rozmawiają ze sobą, ktoś w firmie co miesiąc przepisuje dane z jednego okna do drugiego — i to zwykle ta sama osoba, która powinna zajmować się czymś innym.
Integracje Wialon budujemy od 8 lat: od prostego eksportu przebiegów do księgowości po dwukierunkową wymianę zleceń z systemami TMS.
Co da się zintegrować
Rozliczenia i księgowość. Przebiegi, czas pracy, zużycie paliwa i koszty per pojazd trafiają do ERP w formacie, który system księgowy przyjmuje bez ręcznej obróbki. Najczęstszy punkt startowy i najszybszy zwrot.
TMS i zarządzanie zleceniami. Zlecenie utworzone w TMS pojawia się w platformie jako zadanie z geostrefą punktu dostawy. Wjazd pojazdu w strefę zmienia status zlecenia. Kierowca nie potwierdza niczego ręcznie, dyspozytor nie dzwoni z pytaniem „gdzie jesteś”.
WMS i awizacje. Przewidywany czas przyjazdu wyliczony z realnej pozycji pojazdu zamiast deklaracji przewoźnika. Magazyn planuje rampy na podstawie danych, nie obietnic.
Hurtownie danych i BI. Surowe dane telematyczne w Twoim Power BI, Tableau czy hurtowni SQL, obok danych sprzedażowych i kosztowych. Dopiero to zestawienie odpowiada na pytanie o rentowność pojedynczej trasy.
Systemy serwisowe. Motogodziny i przebiegi wyzwalające zlecenia przeglądów zamiast kalendarza z arkusza.
Narzędzia, którymi to robimy
Wialon Remote API. Podstawowy interfejs platformy: odczyt jednostek, sensorów, tras, zdarzeń i raportów przez HTTP/JSON, plus powiadomienia pozwalające reagować na zdarzenia niemal natychmiast.
FleetSQL. Nasz produkt dla flot, którym nie wystarcza standardowy kreator raportów. Pozwala pisać zapytania SQL bezpośrednio na danych telematycznych — zestawiać trasy z kosztami, budować własne wskaźniki, wpinać dane w istniejące narzędzia raportowe.
FleetTAB. Aplikacja dla kierowcy: zadania, potwierdzenia i komunikacja z dyspozytorem na tablecie w kabinie, spięta z tą samą platformą.
Moduły dedykowane. Tam, gdzie standard nie wystarcza, budujemy komponent pod konkretny proces — od parsera formatu wymiany z systemem klienta po pełny serwis integracyjny.
Jak prowadzimy projekt
1. Analiza (1–2 tygodnie). Rozpisujemy, jakie dane, w jakim formacie i w jakim cyklu mają trafiać między systemami. Efektem jest specyfikacja z listą pól i regułami mapowania — dokument, na podstawie którego można wycenić pracę i sprawdzić rezultat.
2. Środowisko testowe. Integrację uruchamiamy na kopii danych. Nikt nie testuje na produkcji systemu, w którym liczy się faktury.
3. Wdrożenie etapami. Najpierw jeden kierunek i jeden typ dokumentu. Po potwierdzeniu poprawności — kolejne. Każdy etap kończy się działającym fragmentem, nie obietnicą.
4. Utrzymanie. Monitoring zadań integracyjnych, alerty o błędach wymiany, aktualizacje przy zmianach API po obu stronach. Awaria integracji, o której dowiadujesz się z reklamacji klienta, to awaria wykryta o dwa tygodnie za późno.
Czego nie robimy
Nie budujemy integracji, których nikt nie będzie utrzymywał. Jeżeli proces po stronie klienta zmienia się co kwartał, tańszym i uczciwszym rozwiązaniem jest cykliczny eksport do arkusza niż serwis, który po pół roku przestanie odpowiadać rzeczywistości.
Nie zamykamy też klienta na siebie: dokumentacja, dostęp do kodu i przekazanie wiedzy zespołowi IT są elementem każdego projektu.
Punkt wyjścia
Najlepszy pierwszy krok to wskazanie jednego raportu, który dziś powstaje ręcznie, i policzenie godzin, które pochłania w skali roku. To liczba, wokół której da się prowadzić rozmowę o zakresie — a także sprawdzić, czy integracja w ogóle się opłaca. Więcej o kolejności działań piszemy w artykule o integracji Wialon z ERP.