Телематична платформа знає, де машина. ERP знає, скільки вона коштує. TMS знає, що вона має везти. Поки ці три системи не розмовляють між собою, хтось у компанії щомісяця переносить дані з одного вікна в інше — і зазвичай це та сама людина, яка мала б займатися іншим.
Інтеграції Wialon ми будуємо 8 років: від простого вивантаження пробігів у бухгалтерію до двостороннього обміну замовленнями із системами TMS.
Що можна інтегрувати
Розрахунки та бухгалтерія. Пробіги, робочий час, витрата пального та витрати по машинах потрапляють в ERP у форматі, який облікова система приймає без ручного доопрацювання. Найчастіша точка старту й найшвидша окупність.
TMS і управління замовленнями. Замовлення, створене в TMS, зʼявляється в платформі як завдання з геозоною точки доставки. Вʼїзд машини в зону змінює статус замовлення. Водій нічого не підтверджує вручну, диспетчер не телефонує з питанням «де ти».
WMS і тайм-слоти. Прогноз прибуття розраховується за реальним положенням машини, а не за обіцянкою перевізника. Склад планує рампи за даними.
Сховища та BI. Сирі телематичні дані у вашому Power BI, Tableau чи SQL-сховищі поруч із даними продажів і витрат. Лише таке зіставлення відповідає на питання про рентабельність конкретного рейсу.
Сервісні системи. Мотогодини та пробіги запускають заявки на ТО замість календаря в таблиці.
Чим ми це робимо
Wialon Remote API. Базовий інтерфейс платформи: обʼєкти, датчики, поїздки, події та звіти за HTTP/JSON, плюс сповіщення для реакції майже в реальному часі.
FleetSQL. Наш продукт для парків, яким не вистачає штатного конструктора звітів. Дозволяє писати SQL-запити прямо по телематичних даних — зіставляти рейси з витратами, будувати власні показники, підключати дані до наявних засобів звітності.
FleetTAB. Застосунок для водія: завдання, підтвердження та звʼязок із диспетчером на планшеті в кабіні, підключені до тієї самої платформи.
Окремі модулі. Там, де стандарту недостатньо, ми розробляємо компонент під конкретний процес — від парсера формату обміну клієнта до повноцінного інтеграційного сервісу.
Як ведемо проєкт
1. Аналіз (1–2 тижні). Описуємо, які дані, у якому форматі та з якою періодичністю рухаються між системами. Результат — специфікація зі списком полів і правилами зіставлення: документ, за яким можна оцінити роботу й перевірити результат.
2. Тестове середовище. Інтеграція запускається на копії даних. Ніхто не тестує на продуктивній системі, у якій виставляють рахунки.
3. Впровадження етапами. Спочатку один напрямок і один тип документа. Після підтвердження коректності — наступний. Кожен етап завершується робочим фрагментом, а не обіцянкою.
4. Супровід. Моніторинг інтеграційних завдань, сповіщення про помилки обміну, оновлення при зміні API з будь-якого боку. Збій інтеграції, про який ви дізнаєтеся з претензії клієнта, — це збій, виявлений на два тижні пізніше потрібного.
Чого ми не робимо
Не будуємо інтеграції, які ніхто не супроводжуватиме. Якщо процес на боці клієнта змінюється щокварталу, періодичне вивантаження в таблицю і дешевше, і чесніше за сервіс, який за півроку перестане відповідати реальності.
Не привʼязуємо клієнта до себе: документація, доступ до коду та передавання знань ІТ-команді входять у кожен проєкт.
Точка старту
Найкращий перший крок — назвати один звіт, який сьогодні збирається вручну, і порахувати години, які він зʼїдає за рік. Ця цифра задає рамку розмови про обсяг — і водночас показує, чи окупається інтеграція взагалі. Порядок дій описано у статті про інтеграцію Wialon з ERP.