Помните задачу о рюкзаке, в который нужно сложить предметы разного размера и ценности так, чтобы стоимость содержимого рюкзака была максимальной? Подобные головоломки каждый день решают сотрудники «Алтай-Кокса» при загрузке вагонов, только факторов нужно учесть несравнимо больше: грузоподъёмность, фракцию груза, тарифные планы, тип маршрута и много чего ещё. Последний год в этом помогает математическая модель, завернутая в цифровой сервис - об этом (а еще о металлургическом коксе) речь под катом.

Все, что вы хотели знать о коксе...

Кокс получается путем коксования каменного угля при температурах 950-1100°С без доступа кислорода в течение 14-25 часов и является необходимым компонентом для выплавки чугуна в доменных печах. Кокс в доменных печах выполняет 3 важных функции:

1. Энергетическую (работает как топливо – обеспечивает расплавление железорудного сырья).

2. Восстановительную (отбирает кислород у оксидов железа из которых преимущественно состоит руда).

3. Функцию газопроницаемости (за счёт того, что куски кокса долгое время сохраняют форму при высокой температуре).

«Алтай-Кокс», о котором речь в этом посте, — одно из крупнейших коксохимических предприятий России, на долю которого приходится 15% производимого в России кокса. Оно поставляет доменный кокс, литейный кокс, коксовую мелочь, коксовый орешек и коксовую пыль.

Уголь привозят составами, а вагоны, которые его привезли, используются для отправки кокса потребителям. Если взглянуть на структуру отгрузок, то можно увидеть, что большая часть кокса (90%) отправляется на расстояния более 3000 км, 10% отправляется к другим грузополучателям на расстояния от 100 до 500 км. При таких объемах даже «ничтожная» оптимизация стоимости дает реальную экономию в несколько десятков миллионов рублей в год.

В чем заключается «проблема вагонов»

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

Чем больше вместимость вагона, тем ниже удельный тариф РЖД за тонну/километр перевозки груза. Оно и понятно: тариф РЖД привязан к весу вагона вместе с грузом (брутто), т.к. от него зависят расходы на топливо / электроэнергию и износ железнодорожной инфраструктуры, а для «больших» вагонов доля собственно вагона в общей массе ниже. По сути для нас это означает, что если отправлять вагоны с большей грузоподъёмностью на более дальние дистанции, а с меньшей на ближние, то мы можем экономить на транспортировке. Соответственно, предприятию выгодно отправлять большие вагоны на дальние расстояния, а вагоны поменьше — на ближние.

Но это еще не всё. На стоимость перевозок влияет плата за использование подвижного состава и такие нюансы, как скидки за составы, которые включают 71 вагон и отправляются одному получателю — так называемые прямые отправительские маршруты, которым не требуется сортировка в пути следования. Таким ключевым получателем продукции Алтай-Кокса является Липецкая площадка НЛМК.

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

Мы задумались о том, как можно этот процесс автоматизировать. Все входные данные уже были доступны: диспетчеры работали с развитой ИС «Транспорт», нашей самописной системой на базе Oracle Database / Oracle Forms. Кстати, ей уже около 20 лет — она настоящий ветеран, но несмотря на возраст ИС «Транспорт» до сих пор помогает нам в цифровой трансформации.

Итак, что мы сделали:

• Проанализировали исторические данные: структуру отгрузок по фракциям кокса и направлениям, статистику грузоподъемности вагонов, которые были у нас в наличии.

• Экстраполировали простейшим способом тарифы, чтобы закрыть «дырки» в статистике.

• Ну и, собственно, реализовали «жадный алгоритм» решения задачи о рюкзаке. Если читателю статьи известны особенности логистики, то они безусловно знают о том, что в распоряжении клиентов РЖД есть несколько типов вагонов. Условно их можно разделить на «старые» — грузоподъемностью 65, 69, 70 тонн и «новые» — 75-77 тонн. Поэтому загружать 4 «новых» вагона значительно выгоднее, чем 5 старых. Наша модель учитывает этот принцип и позволяет добиться дополнительной эффективности за счет его применения.

Расскажу обо всем подробнее.

Все начинается с гипотезы

Все наши продукты мы создаем по принятой у нас методологии с использованием практик Agile (из которых мы, впрочем, карго-культа не делаем).

Разработка и внедрение продукта идёт в несколько стадий:

Гипотеза → PoC → MVP → Развитие.

На всех этапах бьём работы на двухнедельные спринты. В качестве трекера задач используем Jira. Продуктовая команда каждое утро собирается на Daily чтобы обсудить текущие вопросы – проводим его по Zoom – это помогает команде синхронизироваться и держать ритм. Встречи смешанной команды (включая представителей производства, логистики и ИТ) проводим раз в неделю – также через Zoom. Мы стали это практиковать ещё до того, как в пандемию это стало мейнстримом. Команда у нас географически распределённая – Заринск, Липецк, Москва – а в последнее время у меня в команде появились люди, работающие удаленно из Питера, Самары и даже Приэльбрусья.

В случае с новым цифровым сервисом для «Алтай-Кокса» мы не отступили от привычной методики.

1. Гипотеза

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

Важно, что идея рождается на производстве, а не в цифре и не в ИТ. Как я всегда говорю своим коллегам с производственных площадок: «Цифровая трансформация, это не когда к вам прилетели инопланетяне и сделали вам хорошо. Цифровая трансформация – это когда вы решили: «А почему бы и нет – меняемся прямо сейчас». Главное – чтобы были люди, готовые меняться сами и менять мир вокруг себя

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

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

2. Proof of Concept

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

3. MVP

• Обернули нашу модель в сервис: изначально Data Scientist (DS), как правило, работает в Jupyter Notebook, а данные поднимает из csv-файлов. После завершения разработки модели DS передает ноутбук разработчику, который переводит его в формат модуля python и снабжает всеми необходимыми интеграциями, в результате чего модель «оживает».

• Развернули сервис на нашем кластере OpenShift.

• Привлекли коллег из ИТ, отвечающих за ИС «Транспорт». Они помогли нам с интеграционными таблицами и научили свою систему обращаться к нашему сервису через Web API и получать от него рекомендации.

• И сразу же начали использовать сервис. Мы встроились в уже существующий процесс формирования сортировочных листов таким образом, что обойти процесс выдачи рекомендаций невозможно – они автоматически будут рассчитаны при печати сортировочного листа.

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

4. Развитие

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

Расскажем поподробнее, как работает модель

Входная информация

Сейчас в сервис поступает следующая информация:

• План отгрузки по грузополучателям/станциям:

— наименование груза (тип фракции);
— станция назначения;
— запланированный объем готовой продукции;
— планируемая дата отправки;

• Информация по вагонам в наличии:

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

• Тарифы отправки вагона для всех станций назначения;

• Номер приоритетного пути.

В качестве входных данных для построения базовой версии алгоритма использовались исторические данные продолжительностью 1,5 года.

Основная метрика

Метрикой оценки качества работы алгоритма была задана удельная цена отправки вагона:

где n — все вагоны, p — стоимость отправления вагона, m — масса вагона, S — расстояние до станции назначения. При этом масса вагона рассчитывается, как произведение объема кузова вагона на насыпную плотность фракции (она известна для каждой фракции).

Стоимость отправления вагона (p) включает:

• основную плату за тариф РЖД;

• cтавку предоставления за вагон;

• штраф за простой вагона на станции отправления;

• экспедиторское вознаграждение (процент от тарифа РЖД).

Анализ и обработка входных данных

В первую очередь был проведен анализ исторических данных, в ходе которого было выяснено:

1. Готовая продукция, разделяется на различные фракции, где основной является фракция 25мм и более.

2. В наличии есть вагоны как с большим объемом кузова (например, 94 м3), так и с маленьким (например, 74 м3).

4. Большая часть кокса направляется грузополучателям на расстояние более 3000 км и около 10% вагонов отправляются до станций менее 500 км. Это говорит о том, что можно ожидать потенциальный экономический эффект от внедрения алгоритма.

В расчете стоимости отправления вагона фигурирует плата за тариф РЖД. В представленных данных по тарифам РЖД цена перевозки для большинства направлений была известна только для 47, 52 и 62 тонн (а для некоторых направлений — вообще только для 47 тонн). Для точного расчета стоимости перевозки необходимо рассчитывать цену для любого веса груза, так как объем кузова вагона может быть разный, как и вес груза. Было выявлено, что цена груза за 47, 52 и 62 тонны хорошо ложится на прямую, т.е. зависимость цены от веса груза очень приближена к линейной.

Поэтому для расчета тарифа РЖД для любого веса груза необходимо провести линейную аппроксимацию точек линейной функцией y=kx+b.

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

Разработка алгоритма

Базовая реализация алгоритма достаточно проста.

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

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

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

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

• Учет всевозможных ограничений: (Признак безлюкового, признак возможности отправки за пределы РФ, техническая годность для подготовки под мелкие фракции, etc.)

— Входным параметром в алгоритм является приоритетный путь, все вагоны с которого должны быть обязательно расформированы. Это необходимо для сокращения затрат на маневровые работы.

— За пределы РФ можно отправлять только вагоны с разметкой «ЭКСПОРТ».

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

Пайплайн работы сервиса

Планирование

Процесс начинается с того, что производственный отдел совместно со службой продаж согласовывают объемы отгрузок на месяц или декаду в разрезе фракций готовой продукции и контрагентов и формируют план отгрузки (количество вагонов или тоннаж в разрезе Фракция / Станция назначения / Календарный день). Этот процесс пока проходит с использованием Excel. Планы регулярно актуализируются.

Согласованный план отгрузки передается транспортному отделу. Транспортный отдел заносит его в нашу информационную систему Транспорт — для этого в ней предусмотрена соответствующая форма.

Выдача рекомендаций

Бригадир участка подготовки вагонов (УПВ) – куда вагоны попадают после разгрузки сырья - открывает в ИС «Транспорт» форму сортировочного листа (СЛ), указывает номер пути, вагоны, стоящие на котором нужно обработать, нажимает кнопку «Печать» и вот тут возникает немного магии:

• ИС «Транспорт» складывает в интеграционные таблицы набор вагонов, доступных для загрузки, актуальный план отгрузки с указанием того, какая часть плана уже охвачена вагонами и сколько ещё осталось, а также актуальные тарифы, и вызывает через Web API наш интеллектуальный сервис.

• Сервис забирает данные из интеграционных таблиц и рассчитывает рекомендации (работает собственно модель). Рекомендации сервис кладёт также в интеграционную таблицу и отдаёт ИС «Транспорт» response c ID расчёта.

• ИС «Транспорт» смотрит в рекомендации отображает их на форме сортировочного листа и сохраняет у себя (в сущности, которая очевидно и называется «Сортировочный лист».

Вот в таком интерфейсе работает пользователь:

Осмотр вагонов и оценка рекомендаций

Бригадир передаёт распечатанный сортировочный лист осмотрщику вагонов. Осмотрщик осматривает вагоны на степень изношенности и решает, могут ли вагоны быть подготовлены под те фракции, которые рекомендованы сервисом (в сильно изношенных вагонов щели больше, поэтому их весьма затруднительно использовать для перевозки мелких фракций). Если этого сделать нельзя (а некоторые вагоны вообще могут быть в неисправном состоянии и предназначены к ремонту), он отмечает это в сортировочном листе и возвращает его с пометками бригадиру. Вагоны начинают готовить под погрузку.

Корректировки рекомендаций

Бригадир УПВ вновь открывает СЛ в ИС «Транспорт», вносит доп. Информацию по вагонам (какие под какие фракции готовят, какие в ремонт) и заново запрашивает рекомендации сервиса. В тех случаях, когда ранее выданная рекомендация не может быть выполнена по состоянию вагона, она сбрасывается, сервис выдает новый набор рекомендаций. Новый сортировочный лист с новыми рекомендации становится информацией о том, какие вагоны с какой фракцией и по каким направлениям пойдут, соответственно железнодорожный цех понимает на какую коксосортировку какой вагон подавать

Загрузка вагонов

Вагоны подаются на требуемые коксосортировки (фронты погрузки), где кокс рассеивается на фракции), грузятся необходимыми фракциями, провешиваются. Факт погрузки и провески фиксируется в ИС Axapta.

Ну вот, вагоны готовы к отправке потребителям! Диспетчер железнодорожного цеха формирует в ИС Axapta шаблон железнодорожной накладной для ИС Этран. И тут внезапно опять возникает немного магии. ИС «Транспорт» успела передать в ИС Axapta рекомендации нашего сервиса, поэтому диспетчеру уже точно известно, на какую станцию должен идти каждый вагон.

Конечно, не всегда всё идёт гладко. С момента выдачи рекомендации ситуация могла поменяться (отказ клиента, etc.) и вагон может пойти в другое направление. В таких случаях ИС Axapta передает информацию о фактическом предъявлении вагона к перевозке в ИС «Транспорт». ИС «Транспорт» на основании расхождений корректирует доступный план отгрузки для корректной выдачи дальнейших рекомендаций.

Мониторинг – чрезвычайно важная вещь

При запуске продуктов по «быстрой» методологии неизбежно возникновение проблем: неисполнение процесса со стороны конечных пользователей; проблемы в алгоритме самого сервиса, проблемы, связанные со сбоями в работе сети и т.д. Поэтому на старте разработки мы сразу задумались о мониторинге работы сервиса. Первым делом собрали в отдельной БД статистику выдачи рекомендаций / сформированные сортировочные листы / фактическую отправку вагонов и вывели в Grafana дашборд с приживаемостью, чтобы можно было смотреть, какая доля вагонов ушла в соответствии с рекомендациями, а какая – нет. Он нам помогал выявлять проблемы и детально в них разбираться.

Что в итоге

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

За счёт чего так получилось? Раньше, когда вагоны подбирались «вручную», их подбирали по сути осмотрщики-ремонтники вагонов. Они исходили прежде всего из технической годности вагонов – какие вагоны под какие фракции им комфортно готовить – и не смотрели на экономику перевозки (да и не могли смотреть – нет у них такой информации). А если бы и попробовали, то без применения математики учесть множество факторов невозможно. Собственно, Алтай-Кокс несколько лет пытался развить эту тему, но получилось только тогда, когда в группе компаний появились соответствующие компетенции.

Я в группе НЛМК лидирую разработку цифровых продуктов для коксохимического производства. В основном мы решаем задачи, направленные на снижение стоимости сырья и стабилизацию качества продукции, но сегодня написали и про оптимизацию логистического процесса. Получилось объемно, но, надеюсь, интересно! Если у вас возникли вопросы — задавайте их в комментариях, постараюсь ответить на все.