Привет, Хабр! Меня зовут Дмитрий Крупенин, я руковожу продуктовой разработкой в Первой грузовой компании (ПГК). Сегодня хотел бы рассказать о разработанном нами продукте для оператора вагонов железных дорог. Он называется "Навигатор", а его основная задача - повышение эффективности управления парком за счет оптимального распределения вагонов по нашим заказам, разбросанным по стране и СНГ.
Мы написали программу с нуля, и это было непросто. Зато сейчас она позволяет автоматизировать большое количество задач, которые ранее либо выполнялись вручную, либо были автоматизированы, но не полностью. О подробностях - под катом.
Что такое "Навигатор"?
В первую очередь, это цифровой продукт, который помогает специалистам в динамично меняющихся условиях определить оптимальные варианты отправки вагонов для снижения затрат при обеспечении планируемого количества заказов. Система анализирует и выбирает те вагоны, которые могут быстрее и с меньшими затратами прибыть на нужную станцию. Понятно, платформа не угадывает, решения принимаются на основе тщательного анализа таких данных:
• месторасположение и состояние вагонов
• прогноз прибытия вагонов
• прогноз высвобождения из-под грузовых операций
• дефицит и профицит вагонов на местах
• обстановка на железной дороге
• существующие ограничения по отправкам вагонов по тем или иным направлениям
• спрос на вагоны со стороны грузоотправителей
• стоимость тарифов
В ходе анализа система учитывает около 3,5 млн вариантов. После всего этого "Навигатор" автоматически просчитывает оптимальные варианты по времени и по стоимости, плюс сопоставляет баланс парка вагонов по филиалам и станциям. Данные направляются сотруднику компании для утверждения - да, окончательное решение должен принимать человек.
Как только решение принято, система тут же формирует заявку на отправку вагона в SAP - в полностью автоматическом режиме. На данный момент "Навигатор" тестируется, но уже в ноябре его ждет полноценный запуск.
Интересный момент - сразу мы хотели сделать решение, которое можно было бы назвать цифровым диспетчером. То есть программа, которая управляла бы парком самостоятельно. Но потом поняли, что лучше всего сделать цифровой советчик - симбиоз машины и человека - продукт, который бы служил вспомогательным инструментом для специалистов, снимая с них рутинную нагрузку и оставляя к разбору только сложные ситуации, которые невозможно предсказать алгоритмами.. Так и получилось - сейчас "Навигатор" представляет собой именно такую систему, которая, ко всему, адаптируется нами под постоянно меняющиеся условия на железной дороге. Мы сняли с наших диспетчеров необходимость решать рутинные задачи, оставив лишь обязанность решать неожиданные случаи, инциденты.
Когда и как началась разработка продукта
Сейчас сложно сказать, поскольку этапов разработки было немало, но начало всему было положено в 2019 году. Идея, которая лежала в основе "Навигатора" (который и не был еще "Навигатором) - экономия расходов, в основном, на "порожнем пробеге". Если коротко, то чем больше по рельсам катается пустых вагонов, тем больше убытков терпит компания, на которую эти вагоны работают.
Сначала мы разработали тестовый, относительно небольшой продукт. В 2020 году, после его готовности, оказалось, что экономический потенциал его использования весьма неплохой, поэтому решили дорабатывать продукт до варианта, который может заинтересовать средний и крупный бизнес. Но для разработки нужна была команда, которой изначально не было, и ее пришлось формировать. В конце 2020 года началась полноценная работа над продуктом, и вот сейчас все уже близится к своему завершению.
Важный момент, которым хотелось бы поделиться - продукт у нас довольно масштабный, а вот команда, которая его делает - относительно небольшая. В нее входит около 20 человек.
Технологии, которые мы используем
"Навигатор" - это сложное веб приложение. Бэкенд у нас базируется на Python, а фронт - на JavaScript и фреймворке Angular. Несколько ML-моделей помогают нам с задачами прогнозирования, а саму оптимизационную задачу мы решаем с помощью Gurobi. Интерфейсы мы прорабатываем в Figma и утверждаем с заказчиком до разработки.
У нас полноценный CI/CD, релизимся не реже раза в неделю. Мы умеем в Docker контейнеры и Kubernetes. Zabbix работает для мониторинга, а ELK стек - для логирования.
Что касается исходных данных, то довольно большой их объем получаем от РЖД. Сюда входят информация о состоянии вагонов, и и их местонахождении. По России качество данных неплохое. К сожалению, если говорить об СНГ, то есть определенные проблемы, но мы постепенно разрабатываем обходные решения, которые позволяют избавиться от некоторых неприятных проблем. Но, в целом, мы получаем большой объем информации, узнаем о тысячах вагонов, станций и т.п.
На выходе программа дает рекомендации к заадресации вагонов, которые понятны диспетчеру, работающему с ними. С UX, в целом, проблем нет, тестировщики вполне довольны результатом.
Что в итоге?
Программа помогает обрабатывать огромные массивы данных, которые человек, даже целая команда профессионалов-диспетчеров, вряд ли способны охватить и проанализировать. "Навигатор" помогает собрать все исходники вместе и помочь принять решение. Например, система позволит довести точность графиков подачи вагонов под погрузку до 80% (сейчас этот показатель гораздо ниже).
Стоит отметить, что профессионалы тоже способны принимать корректные и очень эффективные решения. В ходе тестирования программы мы пригласили группу экспертов и дали им для решения простую задачу. Исходные условия включали десять станций, заказы и вагоны. Нужно было распределить парк таким образом, чтобы обеспечить минимальный пробег для обеспечения этих станций.
Справились и люди, и программа. Эксперты решили задачу лишь на 0,1%-0,2% хуже, чем "Навигатор", то есть, практически, на одном уровне. Но вот система сделала это за 0,2 секунды, а профессионалы коллективно решали ее 40 минут. И, напомню, это очень простая, можно сказать, рутинная задача.
"Навигатор" помогает движенцам (это сотрудники ПГК, которые организуют и управляют перевозками на железнодорожном транспорте), эффективнее справляться с логистикой. Например, если сейчас многие отчеты в филиалах составляются вручную, то "Навигатор" делает все автоматически.
Так, для каждой станции платформа отображает наличие парка и статус вагонов, включая число порожних, погруженных, неизрасходованную потребность, прогнозное наличие и т.п. А для каждого вагона указывается рекомендованная отправка с указанием станции отправления, станции назначения, тарифа, даты отправления и прибытия.
В будущем планируем добавить к возможностям еще и "модуль ремонта", то есть часть функционала, которая будет отвечать за учет проблемных вагонов, инцидентов и т.п.
hungry_forester
Интересно. Если позволите, несколько вопросов.
Вы планируете ежесуточно или в текущем режиме? На сколько дней вперед? Из текста можно составить мнение, что формируется заявка на отправку конкретного вагона, тогда по какому событию?
Какие СУБД используются?
Порядок величины парка вагонов? До 1 тыс, до 10 тыс и т.д.
DKrupenin Автор
Пересчет модели каждые Х часов, сейчас живем в режиме пересчета каждые 4 часа. Формируем прогнозный план сразу на 30 дней вперед с учетом ML прогнозов, это дает возможность выбрать наиболее оптимальный маршрут на ближайшие 2 дня. Заявка формируется, если модель понимает, что вагон годен к отправке и на него еще не назначено задание.
СУБД - Oracle + Postgres
Парк вагонов 100.000+, разбивку по типам можно посмотреть в годовой отчетности, открыто размещенной на сайте компании.
hungry_forester
Спасибо.