Телематическая платформа знает, где машина. 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.