PROSTO24: Анализ архитектуры транспортной системы и обоснование перехода на внутреннюю разработку
PROSTO24 представляет подробный анализ архитектуры реальной системы управления транспортом (TMS), а также причины, побудившие компанию отказаться от внешних поставщиков в пользу собственной разработки. Система, функционирующая немногим более года, уже успела обзавестись сложной инфраструктурой и демонстрирует значительную управляемость ключевыми бизнес-процессами.
Архитектура современной TMS-системы
Рассматриваемая TMS-система представляет собой комплексное решение, состоящее из пятнадцати модулей и развернутое на трех нодах за балансировщиком. Она обрабатывает заказы, поступающие из SAP, осуществляя подбор водителей и транспортных средств с учетом специфических требований. Рейсы планируются по точкам с временными окнами, а на каждой точке предусмотрены чек-листы. Процессы выдачи и возврата машин сопровождаются составлением актов с фиксацией возможных повреждений.
- Поток данных: Система обрабатывает непрерывный поток GPS-координат, которые сохраняются в партиционированных таблицах для отслеживания рейсов, местоположения и контрагентов.
- Инфраструктура: В составе инфраструктурного слоя используются RabbitMQ и Kafka (по три ноды), Redis, PostgreSQL и выделенный сервер идентичности.
- Функциональность: Помимо основного управления, система включает мобильное приложение для водителей и публичный клиентский портал, позволяющий отслеживать статус доставки.
Экономическая целесообразность собственной разработки TMS
Переход на собственную разработку TMS был обусловлен не стремлением к экономии, а необходимостью восстановления управляемости над критически важными бизнес-процессами. Изначально компания использовала TMS как услугу от внешних поставщиков, однако со временем риски значительно возросли. Эти риски оценивались в денежном эквиваленте и включали:
- Простои: Невозможность влиять на простои системы.
- Сроки исправлений: Зависимость от приоритетов внешнего поставщика при устранении ошибок.
- Зависимость: Высокая зависимость от одного поставщика при изменении условий контракта или качества услуг.
Когда риски достигают критического уровня, собственная разработка становится стратегическим решением, позволяющим компании вернуть полный контроль над ключевыми операциями, несмотря на первоначальные инвестиции. Это подчеркивает сдвиг в корпоративной стратегии от аутсорсинга к внутренней разработке для обеспечения стабильности и безопасности бизнеса.
Очень интересно, что основной причиной перехода на собственную разработку стала именно необходимость восстановления управляемости, а не экономия. Хотелось бы глубже понять, какие конкретно инциденты или ситуации с внешними поставщиками стали последней каплей? И как удалось выстроить эффективную команду для такой сложной системы из пятнадцати модулей всего за год?