Как решить: разрабатывать собственную TMS или использовать уже готовое решение?

Как решить: разрабатывать собственную TMS или использовать уже готовое решение?

Многие крупные компании у которых есть собственные большие IT отделы, которые уже давно работают на рынке экспресс/адресной доставки или только выходят на него, решили пойти по пути разработки собственных TMS (Transport Management System — систем управления транспортом).

Мотивы, которыми они руководствуются, вполне понятны. Таких мотивов несколько:

1.  Современные TMS, которые используются международными логистическими компаниями стоят сотни тысяч (иногда миллионы) долларов вместе с интеграцией, внедрением и подстройкой под бизнес-процессы компании.

2. Первоначально, разработка собственной TMS кажется стандартной IT задачей, каких много.

3. Наличие собственного департамента IT разработок позволяет создавать сложные IT решения.

4. За использование существующих TMS необходимо ежемесячно платить (у разных TMS разная стоимость и принципы использования), поэтому, хочется сэкономить на такой статье расходов.

5. Многие современные TMS являются Saas решениями (SaaS — модель обслуживания, при которой подписчикам предоставляется готовое прикладное программное обеспечение, полностью обслуживаемое провайдером), а службы безопасности компания до сих пор не очень доверяют облачным решениям и предпочитают «коробочные», которые устанавливаются на собственных серверах.

6. За техническую поддержку с определенным уровнем доступа, опять же, нужно ежемесячно платить, и эту статью расходов тоже хочется уменьшить.

7. Готовое решение стороннего производителя предполагает необходимость иногда очень существенных и дорогостоящих доработок под «хотелки» заказчика и под существующие бизнес-процессы в компании.  И хочется разработать систему сразу же под себя.

8. IT департаменты таких компаний являются «государством в государстве» и не хотят, чтобы бюджеты уходили «нас торону», наоборот, рассматривают такие проекты как возможность усилить свое влияние в компании и увеличить штат таких отделов. Ведь это дополнительная власть и влияние.

Как бы выгод очень много и, казалось бы, что тут еще думать? Решение однозначное — делать самим!

Однако, как говорится: гладко было на бумаге, да забыли про овраги. А по ним — ходить.

Каковы же результаты и почему они — плачевные?

Задача коммивояжера известна очень давно.  (англ. Travelling salesman problem, сокращённо TSP) — одна из самых известных задач комбинаторной оптимизации, заключающаяся в поиске самого выгодного маршрута, проходящего через указанные города хотя бы по одному разу с последующим возвратом в исходный город. В условиях задачи указываются критерий выгодности маршрута (кратчайший, самый дешёвый, совокупный критерий и тому подобное) и соответствующие матрицы расстояний, стоимости и тому подобного. Как правило, указывается, что маршрут должен проходить через каждый город только один раз.

Основной камень преткновения решения этой задачи в том, что уже при относительно небольшом числе городов (66 и более) она не может быть решена методом перебора вариантов никакими теоретически мыслимыми компьютерами за время, меньшее нескольких миллиардов лет.

Если говорить простым языком, то для того, чтобы решить комплексную задачу: сформировать маршруты движения для нескольких автомобилей, каждый из которых должен посетить 15-30 точек доставки, необходимо обработать такое количество данных и перебрать такое количество вариантов решений, что это потребует использование компьютеров такой мощности на это потребуется столько времени, что задача становится не решаемой. И речь идет просто о переборе вариантов маршрутов.

А если еще добавить такие данные огромной важности для построения маршрутов, которые являются выполнимыми и по которым можно отправлять водителей на маршруты как:

  • время обслуживания точек доставки (а оно разное и зависит от знания водителей точки доставки, номенклатуры и количества товара, которое доставляется)
  • время, необходимое для переезда из одной точки в другую (а это время зависит от скорости движения на дорогах в конкретное время дня)
  • также, есть дополнительные ограничения в самом транспорте, которые необходимо учитывать (паспортный тоннаж, реальный тоннаж, который зависит от возраста автомобиля, объем кузова, наличие разрешений на заезд в центральные районы города и т.д.)
  • в какие временные окна нужно привезти продукцию в каждую из точек (приоритет этой задачи с каждым годом возрастает все больше и больше).

Каждый из пунктов — это дополнительные миллиарды данных, которые добавляют сложность к уже существующим.

Чтобы создать качественные маршруты за вменяемое время (к примеру, рассчитать транспортную задачу для 3000 точек доставки за 30 минут) необходима специальная математика. То есть, НОУ-ХАУ в области математики. Фактически, чтобы создавать собственную TMS нужно начинать разработку с математики. Это — самое важное. И если такой математики нет, то такая TMS сразу же становится ущербной. То есть у разработчиков сразу же сужается возможность решать сложные транспортные задачи и приходится идти по такому пути:

Делить территорию обслуживания на мелкие кластеры и уже в них решать задачу коммивояжера. То есть упрощать транспортную задачи по максимуму.  Именно на таком принципе работают большинство известных TMS.

Однако, говорить о том, что это эффективный подход к автоматизации создания маршрутов не приходится. Ведь для того, чтобы действительно создать оптимальные маршруты, необходимо решать транспортную задачу в комплексе. Ведь идеальные ситуации бывают только в теории, когда мы предполагаем, что в кластерах будет идеальная загрузка автомобиля, который там ездит. То есть, автомобиль будет загружен на 100%, а не на 50, 70 или 130%. А в реальности, мы не знаем, сколько точек нужно будет обслужить в конкретный день, какие туда грузы нужно будет привезти в конкретные точки и сколько их будет в каждый конкретный день.

Плюс, еще нужно учитывать такое данное: маршруты устаревают в момент их создания, потому что мы не можем знать будущее. То есть, какие инциденты возникнут после того, как маршруты сформированы и как они повлияют на текущую ситуацию:

  • Заведутся ли все автомобили;
  • Выйдут ли на работу все водители;
  • Вовремя ли будут загружены автомобили и смогут ли они выехать в расчетное время со склада
  • Что будет с дорожной ситуацией в каждый конкретный день
  • Сколько времени проведет водитель в точке доставки и будет ли оно соответствовать расчетному и т.д. и т.п.

Можно сказать, управление инцидентами — это задача сравнимого уровня сложности. Ведь системе нужно:

  1. Предсказывать будущее — на 1,5 — 2 часа вперед, чтобы диспетчер мог понимать — успеет ли водитель доставить груз в запланированное время, или нужно делать коррекцию маршрута, принимать другое управленческое решение.
  2. «На лету» менять маршруты движения автомобилей/автомобиля с учетом текущей ситуации и передавать водителю обновленный маршрут.

Третий важный блок, без которого TMS не будет работать адекватно, это картографический сервис. Есть масса ограничений, которые не позволяют в TMS их использовать:

— существующие картографические сервисы, такие как Google, Yandex не подходят для создания маршрутов движения грузовых автомобилей (потому что данные собираются для легковых);

— их актуальность очень низкая и вносить актуальные правки в режиме сегодня на завтра невозможны;

— нет возможности собирать статистику по скорости движения в разные дни недели для разного времени суток, чтобы создавать адекватные маршруты с учетом этих данных и т.д.

Подведем промежуточные итоги:

Чтобы разработать TMS, которая реально способна решать транспортные задачи подобного уровня сложности, необходимо вложить сотни тысяч, а возможно и миллионы долларов в разработку собственной математики подобного уровня.

А после того, как математика будет разработана, необходимо будет еще тысячи часов работы программистов, чтобы превратить это в продукт, пригодный для коммерческой эксплуатации.

И это будет сопровождаться новыми и новыми проблемами, для которых нужно находить решение.

Кроме того, у каждого из собственных отделов разработки, кроме решения задачи по разработке собственной TMS, есть масса других текущих проектов, которые стоят в очереди на разработку. Что еще больше увеличивает сроки на разработку.

Именно для того, чтобы помочь принять решение компаниям, которые решили пойти по пути создания собственной TMS и оценить величину расходов на разработку и определить — сколько нужно будет потратить на это времени, мы предлагаем услугу бесплатного аудита существующей на данный период времени собственной TMS.

Что такое — бесплатный аудит TMS на этапе «как есть».

Так как мы уже прошли весь этот путь и у нас есть решение, которое отлично справляется с задачами любой сложности, нам легко оценить перспективы любого другого решения на этом рынке.

Для того, чтобы провести такой аудит, необходимо предоставить нам полную информацию о ситуации с разработкой TMS как есть, на данный момент времени.

Мы оцениваем TMS по таким критериям:

 Что проверяем:
1По какому принципу создаются маршруты:
1.1Территория делится на постоянные зоны, и в этих зонах ежедневно создаются оптимальные маршруты (этот вариант требует большого количества ручной работы, из-за необходимости перебрасывать заказы из слабо загруженных машин, в более загруженные)
1.2Берется все множество точек доставки каждого дня и разбивается на оптимальные маршруты с учетом всех необходимых параметров доставки (минимальное вмешательство логистов в создание маршрутов)
  
2Какие параметры учитываются при создании маршрутов:
2.1Знание водителями точек доставки
2.2Точное время которое необходимо для обслуживания конкретной точки доставки  при дотсавке определенного объема и массы груза — service time (время, которое затрачивает экспедитор при доставке невозможно сделать «средним», так как установка «среднего» времени не позволяет сделать маршруты выполнимыми)
2.3Возможная скорость автомобиля на определенных дорогах (чтобы маршрут был выполнимый)
2.4Оговоренные с клиентом временные окна доставки
2.5Включение в маршрут не только точки выгрузки товара, а еще и точки подбора товара из торговой точки или другого склада
2.6Возможность планирования доставок для транспорта с полной массой более 4,5 тонн (не вовсе районы города автомобиль может доехать)
2.7Подбор транспортного средства с учетом:   Веса грузов Объема грузов Совместимости типов грузов между собой Совместимости типа груза с автомобилем Необходимости контроля температуры в кузове
  
3 Работа водителя/экспедитора:
3.1Последовательность точек в маршруте задают водители/ТМС
3.2Система получает данные о том, во сколько водитель посетил точку доставки
3.3Система выдает информацию логисту о том, успеет ли водитель посетить точки доставки на маршруте
3.4У водителя имеется карта с запланированным маршрутом и с повременным планом работы в торговых точках
3.5У водителя есть навигатор, который направляет его по оптимальному маршруту в следующую точку выгрузки (что позволяет водителю в незнаком районе быстро находить нужные  точки выгрузки)
3.6 При изменении маршрута диспетчером, водитель автоматически получает обновленный плановый маршрут
4 Работа диспетчера:
4.1Диспетчер в режиме реального времени следит за выполнением водителями запланированных маршрутов
4.2Диспетчер прогнозирует недовозы за 1,5 – 3 часа до их возникновения и успевать принимать оперативные решения по ним
4.3Диспетчер контролирует превышение водителями скоростей движения, утвержденных в компании (превышение скоростей обычно повышает износ и расход ГСМ)
4.4Диспетчер оперативно перепланирует маршрут в случае возникновения внештатных ситуаций (забор груза, сломалась машина и т.д.)
4.5Диспетчер управляет инцидентами не после того как машина вернулась на склад и сделать уже ничего нельзя, а непосредственно во время возникновения инцидента
5 Отчетность, которой пользуетесь сейчас для принятия управленческих решений:
5.1Статистика по использованию автомобильных ресурсов (машины катались пустые или полные)
5.2Статистика по качеству обслуживания точек доставки:   довезли/не довезли причины недовозов вовремя/не вовремя)
5.3Статистика превышения водителями плановых километражей
5.4Статистика нарушений правильной эксплуатации транспорта (превышения скоростей)
5.5Своевременность выполнения доставок водителями
5.6Качество доставок каждого водителя:   % недовозов % непопаданий во временные окна клиентов % нарушений последовательности маршрутов
5.7Анализ рентабельности маршрутов
5.8Другие отчеты
  
6 Карта, которая используется в системе и ее возможности:
6.1Насколько актуальная карта используется в сервисе (как часто обновляется, кем обновляется)
6.2Какая карта используется в сервисе для построения маршрутов
   
7 Функциональные возможности карты:
7.1Как редактируется карта дорог
7.2Кто может редактировать карту дорог
7.3Сколько необходимо времени для создания/удаления дворового проезда.
7.4Как на карте отображается разрешение на движение тяжелого, специального транспорта
7.5Отображены ли на карте дороги областного и районного значения?
7.6Периодичность применения правок карты
7.7Как учитываются на карте скорости движения автомобилей в определенных критичных местах в определенное время (скорость движения на мостах, ключевых транспортных развязках разная в разное время дня, и от этой скорости зависит выполнимость маршрутов)
  
8Какую статистику собирает и использует система для создания оптимальных маршрутов
8.1Время обслуживания каждой точки, в зависимости от номенклатуры, массы, объема груза
8.2«Живость» водителя/экспедитора. Каково время обслуживания точек разными водителями/экспедиторами (кто хорошо справляется, а кто «медленный» и, его стоит заменить)
8.3Скорости движения на разных дорогах в разное время (от наличия этих статистических данных зависит адекватность маршрутов, так как если не учесть их, маршруты будут невыполнимыми)

На выходе вы получаете данные для принятия точного управленческого решения:

  • продолжать разрабатывать собственную TMS или стоит использовать готовое решение;
  • сколько времени займет разработка собственного решения
  • сколько это будет стоить денег
  • сколько программистов для этого нужно будет задействовать.

Присоединяйтесь в Telegram к сообществу Boss and Logistics для руководителей, управляющих логистикой и зависящих от логистики.

Становитесь членом сообщества  в Facebook, получайте обновления блога, подписавшись на рассылку 

Подпишись и получай самую интересную и полезную информацию от RationalLogistics

Share this post

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *