Зачем грузовой компании идти в разработку — опыт ПГК
Привет, Хабр! Я — Аня Анциферова, продакт «Цифрового вагона» (это одна из разработок Первой грузовой компании). Сегодня на примере опыта ПГК я хочу рассказать о том, почему даже консервативные отрасли вроде железнодорожных перевозок имеют огромный потенциал для развития цифровых сервисов и как «подружить» нетехнологический бизнес и разработку.
Пара слов обо мне и о Первой грузовой компании
По образованию я математик-программист и уже долгое время работаю с командами разработки. Я неплохо знаю специфику железнодорожных перевозок — в ПГК я уже седьмой год, а еще успела поработать в ИТ-подразделении крупного ритейлера и в российских технологических компаниях.
Что касается ПГК — пожалуй, тут имеет смысл дать немного контекста. Для отправки груза по железной дороге необходимо заключить договор с владельцем инфраструктуры (локомотивов и путей) и оператором (владельцем вагонов). Ко второму типу компаний как раз и относится ПГК. Под нашим управлением находится около 100 тысяч вагонов, которые в прошлом году перевезли свыше 136 млн тонн груза; сейчас у нас 13 филиалов по всей России и за рубежом, более двух тысяч клиентов и почти три тысячи сотрудников.
Почему мы пошли в разработку
Со стороны кажется, что железная дорога и товарные вагоны — не самая технологически требовательная сфера. Это не робототехника и не космические перелеты, чтобы активно вкладываться в разработки на базе машинного обучения, да и вообще развивать сильную ИТ-экспертизу. Но только на первый взгляд: на самом деле каждый день наши диспетчеры и другие сотрудники сталкиваются с массой задач, для решения которых компания «пошла в айти». Почему мы это сделали:
Нам есть, что анализировать
Мы получаем данные из нескольких источников, в первую очередь от владельца инфраструктуры. Например, на железнодорожных путях есть рамки, чем-то похожие на рамки металлоискателя (это интегрированные посты диагностики подвижного состава, ППСС). Они считывают данные о состоянии кузова вагона и поверхности катания колеса с помощью лазеров и фотофиксации. Там же, на ж/д-путях, есть и другие комплексы технических измерений (КТИ), которые врезаются в рельсы — данные, полученные от них, можно использовать для оценки состояния подвижного состава.
Система интегрированных постов автоматизированного приема и диагностики подвижного состава (ППСС)
Цена ошибки без автоматизации высока
Очевидно, что при ж/д-перевозках компании-оператору важно, чтобы вагоны двигались по оптимальным маршрутам и не простаивали. Но не только: если оператор вагонов недостаточно хорошо следит за их состоянием, не отправляет их вовремя на ремонт, его ждет много неприятностей:
Владелец инфраструктуры может отцепить «подозрительный» вагон, потому что он угрожает безопасности дорожного движения.
Клиент может отказаться от негодного вагона.
Хотя бывает и хуже. Предположим, речь о большой отправке, и из 70 вагонов один-два негодны. Владелец вагонов не может как конструктор взять и быстро их перецепить: это сложный и длительный процесс. Вагоны — и «больные», и часть «здоровых» — могут отставить, пока задача не будет решена.
Компания-оператор теряет время и деньги на внеплановый ремонт.
Допустим, нормальный оборот полувагона составляет две недели (столько времени требуется, чтобы его разгрузить, передислоцировать на следующую погрузку, загрузить, передислоцировать груженый состав под выгрузку). Если вдруг при погрузке мы понимаем, что вагон негодный, мы теряем в среднем еще 7–12 дней на то, чтобы вагон отремонтировать. Даже без учета цифр понятно, что на это время мы перестаем зарабатывать с этим вагоном.
А еще компания-оператор может вообще потерять клиента: например, если он не готов ждать, пока «больной» вагон отцепят и заменят или отремонтируют.
В таких условия автоматизация процессов — не просто удобно, но и в какой-то мере жизненно необходимо.
Тем не менее, мы пришли в ИТ не сразу
В первую очередь ПГК — грузовая компания, и к разработке мы шли постепенно. Сначала, как это часто бывает, часть бизнес-процессов была немасштабируема, был Excel и «наколеночные» решения. Постепенно они стали заменяться на автоматизированные. В процессе мы рассматривали и варианты с покупкой сторонних ИТ-решений, но были вынуждены отказаться от этой идеи в пользу разработки. ПГК — крупный оператор, а готовые продукты не обеспечивали те возможности и функционал, которые нужны были для решения наших задач. В результате появилась ПГК Диджитал — дочерняя компания ПГК. Сейчас в ПГК Диджитал работает 400 человек, а в нашем портфеле более 150 ИТ-проектов.
Какие сервисы мы разрабатываем
Мы делаем цифровые продукты для логистики, наших клиентов и внутреннего бизнес-заказчика. Вот некоторые из них:
«Мобильный репортер» — помогает нашим клиентам быстро провести осмотр вагона, зафиксировать его состояние и возможные неисправности (по аналогии с тем, как это делают сервисы каршеринга) и подать заявку на замену вагона (о том, как формировалась команда этого проекта, моя коллега Ольга Умнова рассказывала тут: 1, 2;, а о самом приложении — тут).
«Оптимизатор» — в онлайн-режиме помогает нам управлять портфелем заказов: обеспечивать своевременную погрузку, выгодные тарифы и приемлемый уровень издержек.
«Навигатор» — тоже внутренний продукт, выбирает вагоны, которые быстрее и с наименьшими издержками прибудут на нужную станцию; рассчитывает оптимальный вариант из 3,5 млн комбинаций.
«Берувагон» — помогает другим ж/д-операторам получить заказ на перевозку от клиентов ПГК. Фактически, мы предлагаем конкурентам выполнить те заказы, на которых у нас не хватает ресурсов.
Один из наших ключевых продуктов называется «Цифровой вагон». Он построен на базе алгоритмов машинного обучения и решает несколько задач. Во-первых, он помогает нам организовать ремонт вагонов. «Цифровой вагон» позволяет спрогнозировать как минимум на месяц вперед, где и какой вагон выбудет в ремонт. А также оценить, в какое депо мы должны будем его заадресовать с учетом: квот депо, стоимости ремонтов, расстояния до депо и до адреса следующей после ремонта погрузки и других вводных.
Эти плановые данные мы используем для предварительных расчетов. Но на практике в процесс могут вмешаться обстоятельства: нужное депо могут закрыть, другие операторы могут подвезти слишком много вагонов и появится затор. Поэтому вторая задача «Цифрового вагона» — на основании оперативных данных дать рекомендации нашим диспетчерам, куда какой вагон заадресовывать.
Третья задача «Цифрового вагона» — рассматривать каждый отдельный вагон «под микроскопом». На основе поступающих данных мы создаем цифровую копию вагона и оцениваем, что сделать, чтобы меньше ремонтировать его в будущем и предотвращать серьезные поломки (об этом мы уже начали рассказывать здесь и тут).
Как разрабатывать продукт в не-ИТ-компании
На первый взгляд, как и везде: у нас есть команды разработчиков, есть тимлиды, проджект-менеджеры и другие специалисты — сам процесс устроен так же, как и в ИТ-компании. Но есть нюанс — поскольку разработка ведется для «нецифрового» бизнеса, тимлиду необходимо объединить две непересекающиеся области: ИТ-команду и бизнес, который работает в совершенно другой сфере, мыслит иными категориями. Приходится преодолевать культурный барьер: у бизнеса может быть очень своеобразное представление о том, «чем заняты эти айтишники», а ребята, устраивающиеся в ПГК Диджитал, поначалу могут вообще не знать, как идет работа в депо и что такое полувагон. Что в такой ситуации делаем мы:
«Выходим из айти»
Мы погружаем ИТ в бизнес, буквально: ребята из ПГК Диджитал приезжают в депо, смотрят, как ремонтируют вагоны, обтачивают колеса. Например, мой коллега Максим Катрушенко (эксперт по анализу данных и машинному обучению) после поездки в депо рассказывал, что стал лучше понимать «физический» смысл работы: что такое вагон, подшипники и прочие детали, как все устроено. До поездки все это было абстракцией, таблицами с данными.
«Дома я думал: ну почему на ремонт надо тратить три дня, что там столько времени ремонтировать? А когда приехал на завод и увидел эту груду металла, представление изменилось совершенно».
Возросла мотивация, захотелось сделать что-то действительно полезное для тех рабочих, которые каждый день трудятся в депо. Когда видишь процесс своими глазами, понимаешь, что их работа не из легких. Кстати, после поездки Максим написал статью о том, как ChatGPT помогала ему готовить вопросы для интервью с главным инженером вагонно-ремонтного предприятия.
Я очень рекомендую всем, кто развивает разработку в нецифровой среде, вывозить ИТ-команду «в поля» — это хорошая возможность сплотить людей вокруг общего дела. А еще — показать, чем живет бизнес вне офиса и на что именно влияют цифровые продукты, которые вы создаете. О том, как мы с командой ездили в вагоноремонтное депо «Грязи», я рассказывала в этом хабрапосте.
Объясняем, что разработка — не про «перекрасить кнопку»
Справедливо и обратное: мы не только показываем ИТ-команде, как работают остальные подразделения ПГК, но и стараемся объяснить бизнесу, что под силу сделать ПГК Диджитал. Проводим обучение, рассказываем, какие модели можем построить и какие задачи решить, приводим примеры из понятных и близких менеджменту областей. В итоге бизнес становится более подкован в ИТ, а нам не поступают запросы вроде: «Вы же айтишники, давайте перекрасим кнопки на сайте».
Договариваемся о KPI
Третья важная задача: привести KPI к общему знаменателю, когда, с одной стороны, показатели прозрачно связаны с результатом работы разработчика, а с другой — руководство точно понимает, как та или иная доработка влияет на снижение трат и увеличение эффективности бизнеса.
Чтобы этого достичь, мы организуем процесс следующим образом. Сначала собираем потребности бизнеса, затем расписываем роадмап или по методологии GIST выстраиваем путь от большой цели к конкретным задачам. Когда у нас есть список задач, собираемся (раз в квартал) с командой разработки — в случае с «Цифровым вагоном» это команда из более чем 25 человек. Обсуждаем, какие конкретные (не детализированные) задачи нужно сделать в рамках квартала. В процессе корректируем их состав и содержание: например, в ходе обсуждения понимаем, что изначально что-то не учли или наоборот, видим, что можем сделать что-то дополнительно, на это есть ресурсы. После утверждаем с бизнесом план на квартал. А дальше каждый разработчик из команды берет себе конкретные задачи из этой общей схемы.
В нашем подходе есть однозначный плюс: каждый разработчик видит, что конкретно он должен сделать к концу квартала — не абстрактную общую цель, а его личную. В таких условиях мотивация заметно возрастает, потому что от «теоретических», «экономических» KPI, не всегда понятных команде, мы переходим к задачам, которые можно пощупать и оценить.
С другой стороны, есть и минусы. Во-первых, это долго: гораздо быстрее один раз озвучить KPI на общем собрании. А в нашем случае нужно потом пообщаться по отдельности с каждым тех, кто работает над «Цифровым вагоном», расписать ему конкретные задачи. Во-вторых, всегда остается риск возникновении ситуации, когда каждый выполнил свои индивидуальные цели, а общей цели команда так и не достигла. Это уже проблема лидера команды: значит, что-то неправильно спланировали, не рассчитали. Здесь выход только один — лучше планировать.
В процессе работы мы делаем регулярные демо и обновляем роадмап, причем в двух версиях. Для заказчика — верхнеуровневый, в нем делаем упор на то, где мы будем приносить деньги. Для разработки — с фокусом на том, какие модули и когда мы должны будем запустить. Такой подход помогает не только превращать бизнес-KPI в понятные команде задачи, но и контролировать процесс так, чтобы и менеджмент, и разработка оставались на одной волне.
При всем этом, разработка — предприятие затратное, а мы не ИТ-гигант, чтобы выделять на нее неограниченные бюджеты. Поэтому мы пристально оцениваем каждую новую фичу с точки зрения ее возможной эффективности — о том, как мы это делаем, расскажу в следующем материале.
