Как в ПГК учатся делать точные прогнозные рекомендации по своевременной отправке вагонов в ремонтные депо.

В июле мы писали о старте проекта «Цифровой вагон». Он позволяет выстраивать предиктивную аналитику на основании данных о состоянии колесных пар. Меня зовут Надежда Костякова, я лидер команды разработки проекта в ПГК и расскажу, как он развивается, а также о проблемах, с которыми мы столкнулись в процессе, и способах их решения.

Как мы пришли к предиктивной аналитике

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

Когда по инициативе РЖД на сети начали массово устанавливать датчики, которые измеряют технические показатели колесных пар вагонов, мы разработали модуль — ИС КТИ (контрольно-технические измерения). Он позволяет нам анализировать информацию о толщине гребня и обода колесной пары. Это ключевые показатели, с помощью которых определяют техническое состояние колесных пар и принимают решение о том, куда вагон отправится – к клиенту или в депо на ремонт.

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

Привет, Хабр! Меня зовут Дмитрий Крупенин, я руковожу продуктовой разработкой в Первой грузовой компании (ПГК). Сегодня хотел бы рассказать о разработанном нами продукте для оператора вагонов железных дорог. Он называется "Навигатор", а его основная задача - повышение эффективности управления парком за счет оптимального распределения вагонов по нашим заказам, разбросанным по стране и СНГ.

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

Меня зовут Павел Куницын, я работаю в Первой грузовой компании (ПГК) главным специалистом по анализу данных и машинному обучению. Недавно опубликовал пост на Kaggle с рекомендациями для тех, кто хочет перейти в Data Science, не имея релевантного опыта. Он оказался интересным сообществу, и я решил подготовить специально для вас расширенную версию публикации – дополнить важной информацией, рекомендациями.

Здесь я не напишу список онлайн-платформ с курсами по Data Science. Об этом писали уже много раз, а расскажу о том, как нужно учиться. У меня есть список правил, которых придерживаюсь сам, когда хочу развить свои профессиональные навыки в какой-то новой сфере. Используйте их не только при изучении Data Science, но и других областей.

1. Сформулируйте для себя конечную цель

Вы можете прийти в Data Science по разным причинам: от интереса к новой сфере до желания устроиться на высокооплачиваемую работу. Возможно, вы — руководитель проекта, и ваша цель – получить краткое представление о том, какие этапы включают в себя проекты по машинному обучению (ML), чтобы сделать общение со своей командой эффективнее. Или, может быть, вы аналитик, и ваша цель – получить новые технические навыки? А, может быть, ваша нынешняя работа никак не связана со статистикой или разработкой, вы никогда не писали код, но хотели бы научиться. Тогда целью может быть получение всех необходимых для этого знаний.

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

Всем привет! В прошлый раз я, как Product Owner клиентского мобильного приложения Первой грузовой компании (ПГК), рассказала о формировании нашей продуктовой команды. Спасибо всем, кто оставил комментарии под текстом. Благодаря вашим сообщениям появился этот материал. Сегодня поделюсь с вами опытом, как мы сформировали матрицу компетенций, и как коллеги развивали свои скилы во время прототипирования и проектирования сервиса.

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

Как собирали команду

Мы пригласили в команду представителей разных сфер бизнеса. В нее вошли коммерческие специалисты (продажи) – люди, непосредственно работающие с клиентами, принимающие их заявки и понимающие, что им нужно. Они — «первая линия» по сбору обратной связи о некачественных вагонах. Еще позвали представителей вагонного блока – тех, кто отвечает за ремонт вагонов, специалистов движенческого блока, оформляющих документы на отправку вагона в депо, и ИТ-экспертов, которые воплощают в жизнь пожелания бизнеса и клиентов. Отмечу, что мы выбирали и профильных специалистов, и руководителей.

Было сложно. В тот период корпоративной жизни у нас еще не было таких направлений, как «проектная работа» и «продуктовая разработка». Между собой преимущественно общались смежные подразделения. Мы только делали первые шаги в области кроссфункционального взаимодействия. Во время проработки прототипа продукта специалисты по продажам, ремонту и движению вагонов, ИТ по-настоящему «открыли» друг друга во время проработки прототипа продукта.

С помощью ML-моделей сегодня выдают кредиты, регулируют движение на дорогах, определяют цены на товары и многое другое. Однако, процесс их разработки и вывода в продуктивную среду сложен и полон подводных камней. Очень часто качество прогноза, основанного на реальных данных, не соответствует ожиданиям пользователей. Меня зовут Надежда Костякова, я руковожу управлением анализа данных и машинного обучения в Первой грузовой компании (ПГК). В статье расскажу о принципах, которым следует наша команда Data Science, чтобы гарантировать надежную работу алгоритмов машинного обучения в продуктивной среде.

Какие проблемы возникают при использовании ML-моделей?

В 2013 году на площадке Kaggle было запущено соревнование. Его участники должны были отличить звук, издаваемый китом, от остальных звуков. Запуск прошел нормально, и люди начали загружать свои результаты. Один из них поразил организаторов: он был сильно выше ожидаемого и достигал невероятного показателя 0,99 ROC AUC. Как выяснилось, результат этот был достигнут даже без чтения звуковых файлов. Что же произошло?

Оказалось, что файлы с записью китов отличались по продолжительности от остальных, имели другой формат даты и были сгруппированы по времени. Организаторы и участники столкнулись с проблемой Data Leakage – когда не основные данные, а метаинформация помогла достичь результата. Это огромная проблема при использовании модели в «проде»: в реальных условиях у модели не будет таких метаданных, и ее результат будет крайне низким. В бизнесе это может привести к значительному экономическому ущербу.

Всем привет!

Меня зовут Никита Ямщиков, руководитель департамента цифрового развития «Первой грузовой компании» (ПГК). В статье я расскажу о том, как наша команда делает обычный железнодорожный вагон цифровым. Собственно, один из продуктов, над которым мы сейчас работаем, так и называется — «Цифровой вагон». Система помогает собирать и анализировать большое количество данных о состоянии вагона, принимать своевременные решения о его ремонте и, таким образом, оптимизировать затраты компании.

Оцифровать ремонт вагонов

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

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

Меня зовут Ольга Умнова, я — Product Owner (владелец продукта) железнодорожного оператора Первой грузовой компании (ПГК). Мы создаем такие IT-продукты, которых на нашем рынке еще нет. Разработчики ПГК — первопроходцы в своем деле. Сегодня я расскажу вам, как формировалась и работала команда, которая создала один из флагманских проектов компании — приложение «Мобильный репортер» для контроля коммерческого состояния крытых вагонов. Этот продукт мы называем Instagram для грузовых вагонов.

Сейчас явно прослеживается тенденция на очеловечивание сухих интерфейсов. Это говорит о том, что меняется подход к разработке IT-продуктов даже в тех компаниях, которые считались консервативными. Клиент повсеместно стал более требователен и разборчив. Что бы оставаться конкурентоспособными, компаниям важно ориентироваться на пользователя, его нужды и пожелания. Меня зовут Дмитрий Бохан, в ПГК руковожу проектом «Личный кабинет клиента». Недавно на одном вебинаре рассказал о том, как превратить сухую бизнес-идею в «живой» интерфейс. Хочу поделиться и с вами. Надеюсь, этот опыт будет полезен.

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

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

Привет! Меня зовут Дмитрий Крупенин, я руковожу продуктовой разработкой в Первой грузовой компании (ПГК). Создаю интересные внутренние продукты по оптимизации управления вагонами, которых у нас достаточно много – 113 тысяч. У меня более 5 лет опыта работы в промышленных и логистических компаниях, где я разрабатывал продукты «про железную дорогу и вагоны». Сегодня хочу рассказать о том, чем отличаются внутренние продукты и работа над ними.