Привет, Habr!

Я Виктор Соловьев – бизнес-аналитик (БА) продукта «Оптимизатор ремонтов» в Первой грузовой компании (ПГК).

Ранее моя коллега Надежда Костякова - техлид продукта, уже начала рассказывать про него в своей статье «Можно ли снизить затраты на ремонт вагонов?». Рекомендую к прочтению.

Сегодня я хочу продолжить тему и подробнее рассказать, что это за зверь такой «Оптимизатор ремонтов». Но как БА считаю неправильно рассказывать про продукт в отрыве от контекста, поэтому начну погружение в проект по пути от общего к частному.

О модели бизнеса по оперированию грузовых вагонов (предоставлению грузовых вагонов для перевозок).

Основная потребность клиентов ПГК – переместить груз из точки А в точку Б. Чтобы предоставить нашим клиентам лучший сервис, наша компания постоянно поддерживает грузовой парк, состоящий из около 90 тысяч вагонов, в технически исправном и коммерчески привлекательном состоянии.

 Во время своей «жизни», вагон может быть:

• исправным – перевозить грузы и приносит доходы бизнесу;

• неисправным – нуждаться в каких-либо ремонтных работах и приносить компании прямые расходы и косвенные потери.

В железнодорожной терминологии эти состояния принято называть рабочий парк (РП) и нерабочий парк (НРП) вагонов.

Разберемся, почему вагон становится неисправным

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

Завод изготовитель устанавливает для автомобиля сервисный интервал технического обслуживания (ТО), например, для «Москвича 3» он составляет 10 тыс. км, но не реже 1 раза в год.

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

Вернемся к нашим вагонам: так вот у них точно такая же ситуация

Завод изготовитель устанавливает для каждой модели грузовых вагонов свой сервисный интервал планового технического обслуживания, в железнодорожной терминологии – плановый ремонт (ПР).

Самый «популярный» интервал ПР для грузовых вагонов составляет 160 тыс. км, но не реже 1 раза в 3 года.

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

 Так и с вагонами, помимо плановых, бывают еще и внеплановые виды ремонта, на ж/д языке их принято называть – текущий ремонт (ТР).

 Вот теперь, когда мы с вами, немного погрузились в бизнес-контекст и терминологию, можно начать разговор непосредственно про цифровые продукты.

В ПГК можно выделить два основных цифровых продукта, связанных с ремонтами:

1. Предиктивный ремонт — снижает число ремонтов и оптимизирует стоимость внеплановых ремонтов. Продукт на основании предиктивной аналитики данных о вагонах прогнозирует дефекты, что позволяет устранить их на ранней стадии с меньшими затратами;

2. Оптимизатор ремонтов (ОР) — минимизация совокупных затрат компании на проведение планового ремонта вагонов за счет управления логистикой ремонтов.

Про «Предиктивный ремонт» мы писали ранее . Оставляйте комментарии, и в следующих статьях мы углубимся в рассказ о развитии этого продукта, а также опишем его актуальное состояние. Я же, как БА «Оптимизатора ремонтов», подробно расскажу про этот продукт.  

О метриках эффективности процесса плановых ремонтов

Выше я отмечал, что грузовой вагон – это основной ресурс ПГК, поэтому справедливое требование бизнеса – его максимально эффективное использование. В идеальном мире вагон должен никогда не исключаться из коммерческого перевозочного процесса, и компания не должна тратить на ремонт свои финансовые ресурсы. В реальном же мире без ремонтов парка не обойтись. В ПГК задачи по снижение издержек и затрат на плановые ремонты решает ОР.

Задачи ОР:

1. Сокращение времени на проведение планового ремонта. Метрика – время ПР;

2. Сокращение затрат на проведение планового ремонта. Метрика – затраты ПР. 

Время на проведение планового ремонта можно укрупненно разделить на следующие компоненты:

1. Время передислокации в ремонт: определяется как разница даты возникновения потребности ремонта и даты прибытия вагона на станцию ремонта.

2. Время нахождения вагона на станции ремонта: определяется как разница даты прибытия на станцию ремонта и даты отправки оттуда исправного вагона под погрузку. Этот компонент состоит из:

   ● времени ожидания: от прибытия вагона на станцию ремонта до того момента, как вагон со станции поступил на ремонтное предприятие;

   ● времени ремонта: от поступления на ремонтное предприятие, до получения от подрядчика информации о том, что ремонт завершен;

   ● времени простоя: от поступления информации о том, что ремонт завершен, до отправки со станции ремонта исправного вагона под погрузку.

3. Время передислокации исправного вагона после ремонта на станцию погрузки.

Затраты на проведение планового ремонта, по аналогии со временем можно разделить на три основные группы:

1. Затраты на оплату железнодорожного тарифа за перевозку вагона до ремонтного предприятия.

2. Затраты на ремонт складываются из:

   ● оплаты подрядчику работ по ремонту и заменяемых запасных частей;

   ● оплата запасных частей и стоимости их перевозки, которые АО «ПГК» поставляет самостоятельно.

3. Затраты на оплату ж/д тарифа за перевозку исправного вагона со станции ремонта до станции погрузки.

Кроме прямых затрат в процессе ремонта возникают косвенные потери:

1. Упущенная выгода компании за время, когда ремонтируемый вагон не участвовал в перевозках;

2. Качество услуг по ремонту: некачественный ремонт может привести к дополнительным отцепкам и внеплановым ремонтам.

Теперь, перейду непосредственно к описанию продукта «Оптимизатор ремонтов».

О продукте – Оптимизатор ремонтов

Продукт «Оптимизатор ремонтов» состоит из трех основных сервисов: 

1. [Прогноз выбытия] Формирует прогноз вагонов, которым потребуется плановый ремонт в следующем месяце.

2. [План ремонта] Подготовка прогноза географии выбытия (места, где будет находиться вагон, требующий ремонта) и погрузки (куда вагон будет направлен после ремонта). На основании этих данных, а также существующих ограничений (логистические ограничения на передислокацию вагонов, технологические мощности ремонтных предприятий и пр.) сервис определяет оптимальное распределения вагонов по ремонтным предприятиям. Цель — минимизация общих затрат компании на ремонт.

3. [Матрица заадресации] Этот сервис подсказывает диспетчеру на какое ремонтное предприятие оптимальнее отправить конкретный вагон, в соответствие с ранее сформированным планом. Кроме этого, сервис собирает сведения, если диспетчер не может выполнить рекомендацию по какой‑то причине.

Остановимся на каждом из сервисов подробнее.

Прогноз выбытия

Задача сервиса — определить дату планового ремонта. Делается это на основании анализа актуального состояния счетчиков расхода межремонтного ресурса и прогноза суточного расхода километров (сколько вагон проходит километров каждые сутки). При завершении очередного планового ремонта счетчик у вагона обнуляется и в самом частом примере становится равным 3 года/160 000 км. После каждой перевозки, счётчик уменьшается. Такой подход позволяет с точностью +/–5% определить будущее количество плановых ремонтов.

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

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

2. Статус вагона. Если на момент формирования прогноза вагон уже едет или находится на ремонтном предприятии, логично, что расчет прогноза на него производить не нужно, т.к. уже есть фактические данные о дате проведения планового ремонта.

Интерфейс

О перспективах развития сервиса «Прогноз выбытия».

Сейчас сервис качественно прогнозирует число вагонов, требующих планового ремонта по сроку или пробегу. Я бы это назвал естественное/органическое поступление вагонов в ремонт.

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

Решение о досрочном ремонте принимается, если вагон поступает во внеплановый ремонт с неисправностью, на устранение которой нужны значительные затраты. При этом до очередного планового ремонта остается уже не так много времени. Для решения этой задачи планируется использовать данные ранее упомянутого сервиса «Предиктивный ремонт», который сможет спрогнозировать износ узлов вагона.

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

Также сейчас используем и активно прорабатываем возможности развития ML инструментов в сервисе прогнозирования.

Как подтверждение моих слов, 10-12 ноября 2023 года ПГК и ПГК Диджитал проводили хакатон «DataWagon», на котором как раз был кейс по прогнозированию выбытия вагонов в ремонт. Я участвовал в этом мероприятии в роли эксперта и проводил для участников мастер-класс по процессу ремонта.

Задачу решали 106 команд, были предложены интересные решения и найдены неочевидные инсайды коррекции данных. Мне понравилось решение с применением метода «Анализ выживаемости» для прогнозирования ремонтов, хотя обычно такой метод применяют в медицине.

Кстати, на хакатоне кроме интеллектуальных были и творческие активности – такие как конкурс мемов с призами. Победитель:

План ремонта

Сервис решает транспортную задачу линейного программирования для минимизации совокупных затрат на проведение планового ремонта.

Стек технологий применяемый для решения задачи в рамках сервиса:

1. Python — язык программирования

2. Pandas — библиотека для анализа данных

3. Pyomo — библиотека для оптимизации

4. GLPK (GNU Linear Programming Kit) — алгоритм для решения задачи линейного программирования

Описание основных входных данных, используемых сервисом:

1. Из сервиса «Прогноз выбытия» сервис «План ремонта» получает информацию о прогнозном количестве плановых ремонтов на необходимый период планирования.

2. Внутри сервиса «План ремонта» на основании данных статистики формируется:

2.1. Прогноз географии мест возникновения потребности проведения плановых ремонтов. Он формируется в два этапа. Сначала используется историческая статистика о том, в каких долях ранее происходило распределение вагонов требующих ремонтов в разрезе 16 крупных географических субъектов (железных дорог - ЖД). Потом внутри ЖД объем распределяется по станциям, для этого используется историческая статистика выгрузки (т.к. основная часть вагонов отправляются в ремонт после выгрузки), при этом пользователь может выбрать внутри интерфейса пограничный критерий станции с каким минимальным объемом выгрузки участвуют в распределении.

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

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

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

5. Данные о тарифах за перевозку вагонов между станциями.

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

Интерфейс

О перспективах развития сервиса «План ремонта».

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

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

Матрица заадресации

Оформление транспортных документов для передислокации вагонов производится в интерфейсе «Пульт диспетчера» (не является частью ОР. Командой ОР реализована интеграция сервиса «Матрица заадресации» и «Пульта диспетчера». Когда диспетчер начинает оформлять вагон в пульте, он получает рекомендацию – список оптимальных предприятия с учетом фактической географии дислокации вагона. В текущей реализации сервиса, формируется список предприятий, отранжированных от более оптимальных к менее. С такой подсказкой диспетчер, учитывая оперативные факторы (которые еще не оцифрованы) делает выбор и отправляет вагон на вагоноремонтное предприятие. Также сервис собирает причины отклонений от рекомендаций. «Хорошей» считается отправка в адрес топ-5 предприятий. Для сбора аналитики диспетчер заполняет причины, почему он не выбрал топ-1.

В «Пульте диспетчера» рекомендации содержат минимальную необходимую информацию: названия предприятий и их ранг. Более детальную информации можно посмотреть в отдельном интерфейсе сервиса «Матрица заадресации».

Интерфейс

О перспективах развития сервиса «Матрица заадресации».

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

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

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

Другое направление развития – это оцифровка дополнительных факторов, влияющих на принятие решения о выборе оптимального предприятия для ремонта. Мы это называем – учет оперативной обстановки. Сейчас нами определено 11 причин по следующим направлениям: загрузка производственных мощностей предприятия, обеспечение запасными частями, время необходимое для ремонта, наличие логических запретов на отправку в ремонт от внешних регуляторов и пр.

В чем польза?

Отдельный раздел хочется посвятить экономике продукта. «Оптимизатор ремонта» – внутренний продукт, поэтому наша команда должна постоянно подтверждать его эффективность и рассчитывать экономические эффекты для компании.  

Для этого применяется стандартный подход сравнения AS IS и TO BE состояния процесса, т.е. какая экономика планового ремонта была до и стала после реализации нашего решения. 

Но тут возникает ряд сложностей, которые необходимо преодолеть для объективного сравнения состояний AS IS и TO BE:

1. Смена структуры договоров на ремонт и подрядчиков;

2. Ценовые параметры по одним и тем же позициям затрат могут измениться как в большую, так и меньшую сторону;

3. Смена географии присутствия клиентов влияет на тарифы за передислокацию вагонов;

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

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

Для оценки эффекта применяется следующий подход:

1. В затратах до и после внедрения продукта выделяются и рассматриваются обособленно факторы, оказавшие влияние на изменения каждого компонента затрат. В текущей модели расчета эффекта таких факторов 24 (цены на услуги и запасные части для ремонта, география погрузки/выгрузки и пр.).

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

На этом мой рассказ про продукт «Оптимизатор ремонтов» с точки зрения БА завершен.

С удовольствием отвечу на все вопросы в комментариях!