Как мы в ПГК контролируем ремонт вагонов с помощью IT
В прошлом году мы писали об одной из частей проекта «Цифровой вагон». Он нацелен на улучшение процесса ремонтов вагонов – снижение их количества и стоимости. Меня зовут Надежда Костякова, я — техлид продукта в ПГК и расскажу, как он развивается, а также о проблемах, с которыми мы столкнулись в процессе, и способах их решения.
Процесс ремонта вагонов
Напомню, что задача оператора — предоставить клиенту вагоны в нужном количестве, надлежащем качестве и в срок. Чтобы техническое состояние вагонов было оптимальным, их ремонтируют. Ремонты бывают текущие (текущий отцепочный ремонт или коротко ТОР) и плановые. ТОРы нужны для восстановления вагона, если поломка случилась в пути. Его отцепляют от поезда и отправляют в депо. Сломанную деталь стараются починить, а если это невозможно, меняют на новую. Плановый ремонт выполняется регулярно согласно утвержденным нормативам. Его можно сравнить с техническим обслуживанием автомобиля, которое нужно проводить с определенной периодичностью. Важны пройденное расстояние, время эксплуатации, причем для разных типов вагонов эти показатели разные, за ними нужно следить. Именно этот вид ремонта мы и решили оцифровать.
В чем заключается главная сложность?
Планирование этого вида ремонтов для наших вагонов – задача непростая. Это связано с разнообразием типов вагонов, их количеством в парке и разветвленностью сети железных дорог в России. Подвижной состав может находиться где угодно в тот момент, когда подойдет срок для его ремонта. К тому же на участках по разным причинам может быть затруднено движение, например, летом из-за традиционного сезона отпусков и путевых работ.
Кроме того, в России 159 вагоноремонтных депо, и мы должны выбрать из них одно для ремонта конкретного вагона. Чем дольше он едет в депо, тем больше денег теряет оператор на простое и порожнем пробеге. Получается, что вагон находится в движении, владелец инфраструктуры получает плату по тарифу, но перевозки нет, так как вагон едет пустым.
Еще один важный фактор – это квоты, которые выделяют вагоноремонтные предприятия собственникам подвижного состава. Если квоту не выбрать, то ее могут уменьшить решив, что такой объем работ в месяц не нужен. Если подать вагонов больше выделенной квоты, они просто будут стоять и ждать, пока площадка освободится для работы с ними. Здесь очень важно соблюдать баланс и учитывать текущую загрузку предприятия.
Так мы приходим к мысли, что необходимо найти оптимальный план ремонтов, учитывающий большое количество факторов. Эту цель перед собой ставит «Оптимизатор ремонтов».
Изначально идея «Оптимизатора ремонтов» родилась у бизнеса. Коллеги из блока ремонта вагонов ПГК начали искать возможности для улучшения плана ремонта вагонов. Они начали сводить все данные в Excel, провели серьезную исследовательскую работу, сделали необходимые расчеты. Каждое депо можно ранжировать по параметрам, о которых мы говорили выше. Это дальность, загруженность, стоимость работ и много другое. Из этих показателей и складывается стоимость ремонта вагонов, которую мы хотим уменьшить.
Линейная оптимизация уже давно в компании
Найти оптимальный план ремонтов нам помогает линейная оптимизация, на базе которой в компании работают многие цифровые продукты, про один из которых мы уже рассказывали. Многие из нас решали в вузе транспортную задачу, где нужно было правильно распределить пункты перевозок с набором ограничений на каждом из этих пунктов. Она практическая, её действительно использует бизнес. Пример решения транспортной задачи с помощью линейного программирования отлично описан в этой статье.
При решении нашей задачи мы используем целочисленное линейное программирование – разновидность задачи математической оптимизации, при которой переменные должны принимать целые числа. Так как наша основная цель — распределение количества вагонов по самым экономически выгодным маршрутам на вагоноремонтные предприятия, то переменные не должны принимать дробные значения. Например, мы не можем отправить 0.45 вагона, если даже наша целевая функция будет минимальна. А округление полученных значений может создать большую ошибку в финальном результате. Так как в компании мы в основном используем язык программирования Python для подобных задач, то для моделирования и решения этой оптимизационной задачи мы использовали именно его при помощи open-source пакета.
Проблемы с данными
Однако для хорошего результата недостаточно выбрать инструмент, необходимо предоставить ему корректные и актуальные данные на входе. Это одна из главных проблем при работе с алгоритмами.
Основных проблем несколько:
Разнообразие источников данных, особенно справочников. Часть справочников поступает через главный вычислительный центр владельца инфраструктуры автоматически, часть ведется пользователями вручную. Проблемы возникают при наличии нескольких справочников, противоречащих друг другу.
Низкая полнота входных данных. Не все интересные для нас факторы для принятия решения возможно автоматизировать. Например, конвенции (ограничения) на сети необходимо вносить вручную. Кроме того, даже автоматизированные источники не всегда содержат все события.
Низкое качество входных данных.
Чтобы решить эти проблемы, в компании идет трансформация процессов управления данными: создается общая платформа open source инструментов и формируются стандарты по работе с ними. Однако просто создание платформы слабо мотивирует бизнес помогать в решении проблем. Для этого необходимо выстраивать с ним диалог и показывать, как совместные действия приведут к общей цели.
Одно из таких мероприятий – проведение бизнес-демо, на которых мы показываем текущие процессы, их изменения с помощью нашего инструмента и, самое главное, необходимые действия с данными от бизнеса для помощи в этих изменениях. Чтобы необходимые действия не забывались, наши бизнес-аналитики ставят напоминания в Outlook для бизнес-пользователей. Работа с проверкой данных – часть их ежедневных задач. Мелочь, которая работает.
Кроме того, важно говорить с бизнесом на одном языке. Для этого все заинтересованные в этом ИТ-сотрудники могут пройти курсы по основам ЖД. Еще мы организуем поездки разработчиков в вагоноремонтные депо, про одну из недавних поездок мы уже писали.
Разработка логики бизнеса – проблемы верификации и тестирования
После того, как базовая версия была разработана, потребовались доработки. Они были связаны не просто с изменением базового функционала, а затрагивали оптимизационное ядро напрямую. Новые релизы привязаны к периодичности ремонтов, то есть они должны выходить каждый месяц к 20-му числу. К этой дате у нас должны быть описаны и проверены гипотезы, реализованы и протестированы успешные гипотезы на бэке и фронте.
Задача решается правильным распределением ролей. У нас есть выделенные роли для каждого этапа. Есть тимлид и аналитики, которые занимаются тестированием гипотез. После завершения R&D мы отдаем результаты разработчикам и затем тестировщикам.
Кроме того, процесс уже понятный, отстроенный, команда понимает, что дальше будет происходить, какие этапы предстоит пройти и, самое главное, что и в какие сроки от них требуется. Это позволяет эффективно планировать своё время.
Дальнейшие проблемы – реализация оперативного плана?
Расчет плана ремонтов – это не финальная точка процесса. Необходимо обеспечить выполнение этого плана диспетчерским блоком. Однако эта часть заслуживает отдельной статьи, которую мы обязательно выпустим на Хабре. Следите за публикациями в нашем блоге!