В данной статье делюсь опытом создания прототипа TMS (Transportation Management Systems) – ИТ-решения для планирования и контроля исполнения перевозок (доставок/поставок) товаров, оборудования и людей, «собственными силами» или, так сказать, сделанного «на электронной коленке из подручных средств».
На дворе непростые времена: общий экономический кризис, специфическое состояние ИТ-отрасли и рынка труда (как в сегменте ИТ, так и по направлению, связанному с логистикой), а также специфика ситуации на вашем предприятия и с вашей ИТ-службой, могут заставить искать какие-то нестандартные пути для получения такого рода ИТ-решения для автоматизации транспортной логистики. Например, путем создания и внедрения TMS «из подручных средств». Речь пойдет о подходе, в рамках которого ИТ-решение конструируется из доступных, относительно свободно распространяемых компонентов, а вам предлагается писать связующий программный код для получения законченного прикладного ИТ-решения. И создавать это решение можно на «простеньком» компьютере – без использования продвинутого «железа» и «софта», без «облаков» и т.д., т.е. на своей «электронной коленке».
Создание «на коленке» компонентной базы такого ИТ-решения, как то – «вычислительный движок» для оптимизации маршрутов, геокодер, обработчик дорожных графов для вычисления «матрицы расстояний» (расстояний и продолжительностей при перемещении между каждой возможной парой точек доставки/поставки из решаемой задачи), геоинформационный визуализатор и др., представляется утопичным: за разумное время в одиночку - почти невозможно. Посмотрим на мой путь, который вы можете пройти сами, вместе со мной или в комбинированном режиме.
Центром вашего ИТ-решения является «вычислительный движок», на вход которому подаются данные о заказах доставки/поставки и данные о транспортных ресурсах (транспортных средствах или курьерах), а на выходе из которого вы получаете (суб)оптимальное решение задачи – списки точек доставки/поставки из заказов, привязанные к транспортным ресурсам. Я выбрал метаэвристический алгоритм оптимизации «Ruin and Recreate» (описание здесь) и реализующий его опен-сорс’овский «движок» jsprit (исходный код здесь).
Для получения «матрицы расстояний» используются бесплатные свободно распространяемые карты (графы) из проекта OpenStreetMap, которые можно загружать, например, отсюда: http://download.geofabrik.de/ Но для того, чтобы эффективно выудить из дорожного графа данные для «матрицы расстояний» вам нужно специальное средство, например, такое: https://github.com/graphhopper/graphhopper
Этот компонент берет на вход геокоды (географические координаты) точек доставки/поставки, а не адреса в привычном нам виде. Для качественного и бесплатного геокодирования я использую такие геоинформационные сервисы (их API), как например, Google Карты и пробный (тестовый) ключ доступа с квотой 2500 запросов в сутки. Это означает, что при необходимости вы можете ежедневно расширять свою «матрицу расстояний» комбинациями с 2500 новыми адресами (что вполне себе прилично).
Осталось выбрать веб-сервер, если вы хотите создать свое ИТ-решение в виде приложения для веб (как вариант можно делать десктоп’ное-приложение). Я, исходя из своих соображений, выбрал IIS (Internet Information Services). Кстати, для начала вполне подойдет версия Express: ее просто настроить для целей отладки при разработке, тестирования и пробной эксплуатации вашего ИТ-решения пользователями. Ну а раз я выбрал IIS, то и связующий программный код мне пришлось писать на C#/.Net.
Пользовательский интерфейс для логиста/диспетчера, загружающего задачу доставки/поставки на сервер и получающего табличное и графическое представление, можно быстро разработать, например, средствами ASP.Net. А возможно, вы создаете свое решение как расширение корпоративной информационной системы (типа ERP-системы) в виде веб-сервиса, то и веб-интерфейс не нужен – логист/диспетчер работает через интерфейс расширяемой системы.
А вот пользовательский интерфейс веб-приложения для исполнителя транспортной работы (водителя/экспедитора, курьера) лучше создавать с использованием нейтральных технологий типа JavaScript. Замечу, что выбор веб-сервера может оказывать непосредственное влияние на способ реализации приложения для исполнителя, но необязательно. В моем ИТ-решение это приложение написано на «чистом» JavaScript, а для передачи сообщений о результатах работы используется API посредством HTTP/Rest.
(Примечание: помимо этого вы можете подключить внешние инструменты BI (бизнес-аналитики), значительно повысив ценность и возможности своего ИТ-решения для управляющих сотрудников вашей компании.)
Как все это выглядит представлено на скриншотах ниже, а также здесь: https://sites.google.com/view/freetms/home
В конечном итоге, вы получаете ИТ-решение с условно-нулевой стоимостью программных компонентов – функциональных блоков, но при этом должны очень тщательно выполнить системный анализ и написать новый связывающий эти компоненты программный код. В процессе этого (продумывания и реализации связей) вы можете увеличить суммарный эффект за счет кастомизации – разработать ИТ-решение именно под специфику вашего предприятия и его задач в области транспортной логистики.
Не все аспекты и детали создания ИТ-решения возможно раскрыть в этой статье – такую цель я не ставил, но для первичной оценки подхода вполне достаточно. Всем желаю успехов в работе! С удовольствием обсужу различные связанные вопросы и вне публикации.
Комментарии (14)
GbrtR
01.12.2022 17:41+3Немного не в тему, но случайно увидел что «Valid until» принимается в формате: y.d.m
Реально интересно почему? y.m.d можно представить зачем, но y.d.m? Любопытство не даёт заснуть.
erpacademy Автор
01.12.2022 17:55Внутренний американский формат представления даты, одного из языков программирования, задействованного в данном ИТ-решении. Я оставил пока без преобразования при выводе в поле веб-формы для настройки. Предполагается, что эту форму видит администратор, а не конечный пользователь. За несколько дней до окончания периода действия, предупреждение выводится уже в основной отчет по планированию, на основную форму, в обычном - европейском формате даты.
В самом начале я сделал эту опцию - ограничения работы, так как предполагал создание веб-сервиса по подписке: думал, что сам лично буду задавать период действия. Но теперь это Freeware, и осталось как рудимент просто для напоминания - чтобы загружать / обновлять новую версию раз в полгода.
mobilz
01.12.2022 17:57яростно плюсую и негодую ) каждый раз, сталкиаясь с форматом год-день-месяц -- громко кричу.
natberspower
01.12.2022 18:09+2Привет! Какой интересный прототип и задумка. Я занимаюсь Доставкой в Додо Пицце. У нас все по-другому, но всегда интересно, как у других. А можно с тобой где-то в личке пообщаться? Мы тут всей командой прочитали, кое-что не догнали, а кое-что интересно уточнить?))
erpacademy Автор
01.12.2022 18:10Конечно, для этого и публиковал статью.
Mantis-religiosa
01.12.2022 21:28+1Привет! А какая задача у системы? Я на скриншоте видел точки, это я так понимаю адреса доставки?
erpacademy Автор
01.12.2022 22:56+1Привет! Задача "классическая": 1) спланировать оптимальным образом развоз (delivery / pickup) грузов / оборудования / людей по точкам (адресам) с учетом ограничений (временные окна, ограничения на макс. вес, объем, и др.), чтобы суммарная стоимость перевозок была минимальна (учитываются затраты на расстояние, время в пути, простои / ожидания и др.) [Еще это называется Vehicle Routing Problem (VRP)]; 2) передать план развоза на оконечные устройства исполнителей (вероятнее всего, смартфоны); 3) собрать данные об исполнении плана.
Но задачей моего проекта было: сделать так, чтобы конечное ИТ-решение было бесплатным (свободно распространяемым), при этом могло приносить ощутимую пользу тем предприятиям, которые только приступают к оптимизации своей транспортной логистики. Зарабатывать я планировал на адаптации ИТ-решения под уникальные потребности бизнеса, делая это тоже интересным (с технической точки зрения) образом...
DODO_Zhukov
02.12.2022 14:02Я правильно понимаю понимаю, что у нас заранее (до начала смены, рабочего дня и т.п.) есть список адресов, по которым следует выполнить доставку. И у нас до начала смены так же есть список исполнителей.
@natberspower уже упоминала, что мы занимаемся Доставкой в Додо Пицце. И у нас задача несколько другая, у нас в течении дня есть некоторый поток заказов и их необходимо распределять между доступными курьерами, решая приблизительно те же задачиmobilz
02.12.2022 15:56простите что вмешиваюсь, у вас курьеры свои, или привлечённые? у "папы" в своё время доставка была реализована по типу такси, когда курьер сам принимает решение, какой заказ он берёт, какой нет. т.е. пиццерия принимала заказы и готовила, а доставкой по сути занимались сами курьеры. У вас сейчас такая же схема, или система сама накидываем заказы курьерам?
erpacademy Автор
02.12.2022 17:19Да, правильно, ИТ-решение начального уровня работает так. Но концептуально это своего рода крайние точки одного и того же - планировать раз в смену или в интервале, например, час или четверть часа.
mobilz
Хай, мы больше 10 лет делаем http://ats24.ru/, логистикой занимаемся лет 15 минимум.
Неожиданно наблюдать здравый подход в этом "тёмном лесу" ) Из замечаний:
0. конечно, не будем обсуждать стек, каждому своё. но было странно увидеть iis, aps, java решения в контексте "слабого компа" )
1. гугл для рф, увы, закрыт. т.е. оплатить сервисы гугла с каждым днём всё сложнее. для геокодирования вполне можно юзать dadata.ru, да он платный, но вполне рабочий + чаще всего адреса доставки условно-одинаковые. т.е. берём любого клиента, смотрим, и оказывается, что на 1000 адресов в день, новых штук 10 от силы.
одно время у нас была идея самим писать геокодер, но провозившись месяц мы поняли, что не смотря на то, что получается в общем не плохо, этим надо заниматься, а заниматься мы хотели логистикой.
2. для небольших проектов/клиентов для маршрутизации проще использовать сервисы типа
https://openrouteservice.org/
он бесплатный и, скажем, отдельной компании упереться в их лимиты тяжело, при этом маршрутизация поддерживает много плюшек. На самом деле на практике основная задача не "качественно" сделать маршрут, а скорее следить за его соблюдением. случаев, где логист входит в сговор с водителем, строят супер невыгодный маршрут и зарабатывают на этом -- полным полно. т.е. при маршрутизации компании важнее прозрачность, понимание пробега и трат на топливо, нежели чем супер оптимизированные маршруты между точками.
3. вебморда для водителей, увы, штука неудобная. ну и ни слова про датчики (geolocation), без которых нет возможности понимать "окна" входа и выхода водителя в радиус точки.
кстати, а jsprit умеет распределять на основе предпочтений водителей? мы на это много времени потратили. да и у клиентов часто запрос: "мы отправляйем водителей в рейсы, они ездят по одному и тому же маршруту"
erpacademy Автор
Да. Нужно определить эту связь "предпочтение" между водителем и заказом.
erpacademy Автор
Это ИТ-решение начального уровня. А также концептуальный прототип (проектирование из готовых функциональных модулей) и "программный" прототип (можно брать за основу и развивать под индивидуальные потребности).
Если придерживаться задумки "минимальная стоимость владения", то "веб-морда" приложения для исполнителя - это вариант (писать под две нативные платформы - дорогое удовольствие, хотя можно найти что-то усредненное... типа PhoneGap). Поэтому вариант-минимум: "веб-морда" (JavaScript) -> HTML5 -> встроенная в веб-браузер геолокация -> технологическая платформа под веб-браузером -> смартфоны, планшеты, ноутбуки (может, водитель-экспедитор / автокурьер свой лаптоп захочет использовать). Повторю, это начальный уровень, отправная точка для рассмотрения различных проектных вариантов.
erpacademy Автор
Маленькое пояснение: в данной начальной версии, мобильное приложение - это высылаемый с сервера (АРМ'а логиста / диспетчера) на эл. почту исполнителя сконфигурированный html-файлик со всей начинкой для рейса - планом доставки (заказы и расписание) + прикладной JavaScript-код (для визуализации, маршрутизации уже конкретного рейса средствами Google Карты (как пример) с учетом трафика в данный момент времени, отправки сообщений о выполнении работы обратно на сервер через - на выбор: HTTP/Rest или та же самая эл. почта).