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

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

Немного теории

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

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

Депо. Начало

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

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

Обточка колёсной пары
Обточка колёсной пары

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

В депо

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

Демонстрация устройства обмера диаметра колеса
Демонстрация устройства обмера диаметра колеса

Отмечу, что само депо оказалось не таким уж и «аналоговым», как мы себе представляли. Хотя предприятие и было основано в 1936 году, здесь проводится постоянная модернизация, недавно было установлено современное оборудование. В частности, полностью модернизированы тележечный и колесно-роликовый цеха, внедрена новая автоматизированная система контроля качества ремонта АСУ-В.

Причинять добро

Cотрудники депо к появлению целой делегации IT-шников отнеслись со скепсисом. Сразу несколько человек высказали опасение, что оцифровка их труда уменьшит загрузку, а, следовательно, и зарплату. Нам пришлось долго объяснять, что вагоны, как и прежде, продолжат поступать в ремонт, просто этот процесс станет более прогнозируемым, а значит поможет в планировании работ. Почему-то сразу вспомнился первый закон робототехники Азимова: «Робот не может причинить вред человеку…».

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

Искать

За три часа экскурсии много не успеешь. И все же кое-что новое удалось выяснить. Один из важных критериев принятия решения о направлении в депо – это длительность простоя. Посетив предприятие и понаблюдав за процессом, мы поняли, что на самом деле простои формируются не в депо, а за его пределами. Сейчас рынок перевозок на подъеме, вагонов много. Станционная инфраструктура работает на пределе, зачастую не хватает маневровых локомотивов для выполнения растущего объема работ. В результате растут и простои вагонов: при нормативе в 78 часов этот показатель в среднем составляет 129,6 часа.

Как использовать эти входные данные? Разумеется, наполнять бэклог! Мы уже начали разработку сервиса, который позволит автоматически подбирать и заадресовывать вагоны в наиболее выгодные и эффективные депо с учётом большого количества факторов, о чём мы расскажем в одном из грядущих постов в следующем году!


Кстати, вы хотели бы услышать про особенности работы продактов в промышленных компаниях? Если да, маякните в комментах, что наиболее интересно?

Пироженки
Пироженки

Комментарии (6)


  1. madortuma
    29.12.2021 14:18
    +1

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


    1. NightDolphin Автор
      29.12.2021 14:29
      +2

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


  1. VirtualHunter
    29.12.2021 15:13
    +1

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


    1. NightDolphin Автор
      29.12.2021 16:01
      +1

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

      Кстати, прогноз ресурса в следующем году мы ещё будем отдавать нашему продукту "Навигатор", как раз он отвечает за оптимальную заадресовку под погрузку.


  1. NoWeekOff
    29.12.2021 16:35

    Бывать на местах жизненно необходимо. Даже короткая проставка в виде аналитики иногда приводит к потере информации. А когда путь идет через разные отделы/департаменты и т.д. получатся вообще два разных мира.

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


  1. pae174
    29.12.2021 19:32

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