Для того, чтобы получать информацию о движении поездов и грузов, нужны данные. Много данных. Сегодня расскажу про структуру данных в железнодорожной логистике, которые позволяют оперативно доставлять продукцию, оповещать клиентов, а также предложить оптимальный тариф на железнодорожную перевозку.
Вводная часть: как устроены грузовые перевозки
Для начала коротко поясню, как устроен рынок железнодорожных грузоперевозок.
1. Есть единственный перевозчик - владелец инфраструктуры. Это государственная компания, которая обслуживает железную дорогу, принимает к перевозке грузы, составляет графики, формирует поезда с вагонами разных собственников и везет эти вагоны.
2. Есть частные компании-операторы (например, ПГК), которые предоставляют свои вагоны для перевозки по железной дороге. Также они предлагают клиентам помощь в комплексной организации перевозки – могут взять на себя обсуждение нюансов доставки груза с перевозчиком, оформить нужные документы, организовать погрузку и выгрузку груза силами подрядчиков, застраховать перевозку и так далее. Помимо этого, они могут оказывать услуги по ремонту и подготовке вагонов, продаже и закупке запчастей другим операторам.
3. Есть грузоотправители и грузополучатели, которые заключают договор с оператором на предоставление или аренду вагонов для перевозки в них своей продукции, а также договариваются с владельцем инфраструктуры о самой перевозке.
Чтобы доставить свой груз, клиенту нужно:
а) подать заявку оператору и получить согласование на нее (например, клиенты ПГК могут сделать это онлайн через «Личный кабинет клиента»),
б) подать техническую заявку на перевозку (она называется ГУ-12) в системе владельца инфраструктуры.
После запускается процесс организации перевозки: подача вагонов на нужную станцию, погрузка груза в вагон, включение вагона в нужный состав поезда и так далее. Мы же остановимся на вопросе данных, который на самом деле первичен – без заявки вагон никуда не поедет.
Интеграция с внешними источниками
Основной источник данных на железной дороге – электронная транспортная накладная. Это специальный сервис владельца инфраструктуры, где клиенты онлайн оформляют техническую заявку ГУ-12, о которой я писала выше.
В эту систему поступают заявки на транспортировку каждого груза по железной дороге. В заявке всегда указывается основная информация по перевозке: объем, номенклатура груза, станция отправления, график предъявления груза к перевозке и так далее. Без накладной вагон не поедет, это ключевой документ на железной дороге. Поэтому перевозчик делится этими данными с операторами подвижного состава, в том числе с ПГК.
В системе вагон всегда привязан к накладной – это уникальный номер. Номер вагона не меняется от перевозки к перевозке, он является стационарным и поэтому мы оперируем сцепкой данных номер накладной\номер вагона.
По связке номер накладной\номер вагона мы можем узнать основные атрибуты перевозки: кто был грузоотправителем\грузополучателем, какой был груз, какая станция, под какую ГУ-12, когда отправился вагон, когда он прибыл на станцию, когда раскредитовался, когда убыл со станции.
Из системы владельца инфраструктуры данные о накладных попадают в сервис справочников ПГК. Сначала они приходят в ERP-систему, где хранятся в справочнике нормативно-справочной информации (НСИ). Затем передаются в корпоративное хранилище данных – это общая база данных ПГК, откуда информация подтягивается в цифровые продукты.
Примерно по такому же принципу работает любой железнодорожный оператор. Получает данные по заявкам от перевозчика и заадресовывает свои вагоны в соответствии с указанными графиком подачи парка. Без этой информации мы не будем знать, куда и когда отправлять вагон.
Отмечу, что сейчас в компании ПГК идет трансформация процессов по управлению, обработке и хранению данных. Речь, в первую очередь про данные по накладным, информацию о заявках, данные о дислокационных событиях по каждому вагону, сведения о рейсах, информацию о состоянии вагонов и т.д. В компании накопилось огромное количество исторических данных, которые не были востребованы. Когда компания взяла курс на цифровизацию, мы поняли, что эти данные – кладезь для развития бизнеса и начали думать, как их использовать для повышения эффективности своей работы. Сейчас, когда мы запустили несколько цифровых решений, стало понятно, что системы, в которых изначально хранились и обрабатывались данные, не соответствуют нашим текущим требованиям. Кроме того, назрела необходимость привести к единообразию всю накопленную НСИ. Для этого мы разработали новые системы и методы управления данными. В результате построили платформу данных в качестве отдельной системы. Чтобы упорядочить хранение данных и добавить их описание мы создаем выделенный слой в корпоративном ИТ ландшафт с помощью решений Self Service BI, которые призваны расширить возможности по анализу информации.
Вернемся к данным, которые мы получаем из внешних сервисов. Помимо накладных в системе перевозчика хранятся и другие данные, которыми он также делится с операторами:
реестр вагонов. Владелец инфраструктуры знает все основные параметры вагона: номер, какому оператору он принадлежит, кубатура, год выпуска, срок службы, даты последнего планового и текущего ремонта, срок списания и так далее;
единый справочник станций с кодами. Если на железной дороге появится новая станция, информация о ней будет в системе;
справочник грузов, где учитываются все перевозимые номенклатуры грузов, в том числе новые;
дислокация вагонов на сети железных дорог (срез данных на определенный момент времени);
справочники железных дорог,
справочники обобщённых характеристик по вагонам и так далее.
Кроме того, из системы владельца инфраструктуры операторам приходит информация о дополнительных ограничениях (их называют конвенциями) – это перечень запретов, куда нельзя отправлять вагоны по каким-то причинам. Железная дорога устанавливает их сама и все участники процесса перевозки обязаны подчиниться. Например, причинами таких запретов могут быть технологические ремонты путей, «пробки» на сети и так далее.
Интеграция с системой перевозчика позволяет получать все эти сведения сразу, как только они загружаются в систему.
С точки зрения работы с данными, железнодорожная отрасль уникальна – мало где есть такой ключевой регулятор, от чьих данных зависят остальные представители отрасли. Без этой информации, мы не сможем управлять вагонами.
Внутренние источники
Если говорить про общую архитектуру данных компании, в ее основе ряд общих справочников, с помощью которых мы можем рассчитывать перевозки и оперировать нашим парком вагонов.
Интеграция с системой перевозчика, о которой я говорила в первом блоке, позволяет нам формировать набор собственных баз данных и использовать их в разработке своих цифровых продуктов.
Помимо этого, есть внутренние данные, которые мы заводим на своей стороне – это данные по договорам клиентов и ценовые условия, требования к вагонам в части их грузоподъемности/кубатур. Их мы заводим в ERP-систему. Дальше эта информация также передается на уровень продуктов через корпоративное хранилище данных.
Расскажу чуть подробнее про внутренние данные. Основной источник – это Личный кабинет клиента ПГК, где аккумулируется вся основная информация о перевозке:
информация о клиенте (название, реквизиты, контактные лица и т.д.)
объем отправки,
станция отправления\назначения,
взаиморасчеты,
требования к вагонам.
Наши внутренние сведения не доступны перевозчику, они конфиденциальны. С владельцем инфраструктуры мы делимся только информацией по заадресации вагонов (это происходит при оформлении перевозки в системе перевозчика).
Часть данных по состоянию нашего парка мы получаем из приложения «Мобильный репортер». Про данный продукт я рассказывала в прошлом материале, можно почитать его здесь. Если коротко, то это приложение, в котором мы собираем информацию о дефектах наших вагонов: пользователь заполняет анкету с указанием дефектов, прикладывает фото и видео. Эти данные также поступают в общую базу данных компании, проходят сквозной процесс и после также используются в других продуктах ПГК, например при сменно-суточном планировании или в сервисе «Цифровой вагон».
Информация о коммерческом состоянии парка также недоступна перевозчику.
Вся вышеперечисленная информация – это терабайты данных. Часть данных может обогащаться дополнительными признаками из справочников во время дополнительной обработки. К слову, мы реализовали механизм исторического хранения данных в компании: есть даты действия данных, их изменений.
Как рассчитывается тариф
Для расчета любой перевозки по железной дороге существует специальный справочник, утвержденный на государственном уровне – Прейскурант №10-01. В этом документе прописаны все условия тарификации перевозок. Эти данные учитываются при расчете стоимости перевозки в «Rail-Тариф».
На железной дороге существует автоматизированная версия Прейскуранта – программа «Rail-Тариф». И это еще один источник данных в отрасли. Все участники процесса грузоперевозок проводят в онлайн-сервисе расчет груженого и порожнего тарифов на перевозку. Программа считает стоимость (тарифы) и тарифное расстояние перевозки не только по территории России, но и стран СНГ.
Система автоматически просчитывает тариф в соответствии с указанными критериями:
станция отправления\назначения,
тип отправки груза (повагонная, маршрутная или групповая),
код груза по справочнику ЕТСНГ (Единая тарифно-статистическая номенклатура грузов),
род подвижного состава (полувагон, крытый, цементовоз или контейнер на платформе) и так далее. Всего нужно указать порядка 10 критериев.
Программа может посчитать тариф общего парка (если бы перевозка была в вагонах владельца инфраструктуры) и тариф собственного парка (стоимость перевозки в парке оператора без учета его комиссии). К рассчитанной в «Rail-Тариф» цифре оператор применяет либо скидку, либо наценку.
ПГК, как и другие компании-операторы, высчитывает ставку из тарифа, полученного в сервисе «Rail-Тариф». Для расчета ставки и скидки\наценки мы используем следующие формулы:
Скидка\наценка (%) = (Тариф собственный + Ставка ПГК)/ Тариф инвентарного парка
Ставка ПГК (руб/ваг) Комиссия ПГК за груженный рейс = Тариф инвентарного парка* Скидку/наценку – Тариф собственный
Приведу пример, который мы разбирали с командой, когда готовили один из наших цифровых продуктов.
Допустим, мы везем черные металлы по маршруту станция А – станция Б. Тариф инвентарного парка у этой перевозки составляет 70 тыс. руб./вагон, тариф собственный (его мы рассчитали в «Rail-Тариф») – 45 тыс. руб./вагон.
Если ПГК не применит никакой дополнительно наценки или скидки, то ставка ПГК (читай, доходная часть перевозки) составит 25 тыс. рублей (70 тыс. руб./вагон – 45 тыс. руб./вагон). Из этой части компания заплатит какую-то часть за порожний рейс.
Если бы компания сделала скидку 20% на перевозку, тогда ставка ПГК составит 70 тыс. руб./вагон * (- 20%) – 45 тыс. руб./вагон = 11 тыс. руб./вагон.
ПГК оперирует парком из более 100 тыс. вагонов, обслуживает более 2 тыс. клиентов. Без такого инструмента, как автоматизированная система расчета тарифов, мы бы не смогли обсчитывать вручную огромное количество данных по нашим перевозкам. Только представьте сколько человеко-часов нужно, чтобы просчитать стоимость тысячи отправок в ручном режиме!
Данные из «Rail-Тариф» мы также используем в своих продуктах. Например, мы интегрировали с системой наш продукт «Оптимизатор», над разработкой которого мы сейчас активно работаем. Это решение по оптимизации портфеля заказов и о нем мы расскажем в одном из следующих материалов. «Оптимизатор» направляет по API огромные базы данных на расчет в «Rail-Тариф» и получает все рассчитанные метрики в течение нескольких минут по одной перевозке.
Пожалуй, это основные данные, которыми оперируют на железной дороге и без них сегодня невозможно представить отрасль грузоперевозок. Безусловно есть еще системы, которые контролируют состояние парка и заадресацию вагонов (например, ранее мы писали про «Навигатор»), о них может рассказать подробнее в следующих статьях.