Как ЖД-компания разблокировала 235 млн рублей в месяц.

О Заказчике.

Железнодорожная транспортная компания, 100% дочка металлургического гиганта. Привлекают вагоны для перевозки грузов по России и СНГ. Масштаб: 650 тысяч тонн перевозок в месяц собственными силами — это 25% потребности Материнской компании. Плюс контроль еще 1,95 млн тонн перевозок.

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

Что болело.

В штате — специалисты, которые ежедневно отслеживают вагоны, распределяют грузовую базу между собственниками, согласовывают коммерческие условия, контролируют соответствие тарифам ЖД, выставляют закрывающие документы и ведут бухучет.

Проблема: данные из разных источников — рассылки в почте, Word-файлы со ставками, таблички с дислокацией. Расчет тарифа для каждой отправки вручную: 5-7 минут на один вагон.

Простая арифметика: В пике количество вагоноотправок - 35 тысяч в месяц. Чтобы проверить все на тарифном калькуляторе, нужно 2900-4000 человекочасов. Это нереально. Поэтому проверяли выборочно — один вагон из ста.

Конкретный пример: сотрудник приходил на работу в 6 утра, чтобы выгрузить и вручную обработать CSV-файлы с дислокацией вагонов. Уходило 2-3 часа каждый день. Иначе информация к началу рабочего дня устаревала.

Как подошли к решению.

Это был наш первый крупный проект. Двигались наощупь, но оказалось — в правильную сторону.

Начали с простого: определили вместе с Заказчиком, что является главным юнитом оценки их бизнеса. В нашем случае — вагоноотправка. Дальше исследовали весь путь этого юнита: от согласования ставок и планирования перевозок до конечного выставления счетов Материнской компании.

Параллельно изучали информационную инфраструктуру — откуда данные берутся, как обрабатываются, где узкие места.

И нашли интересное: у Заказчика был доступ к SQL API РЖД, но они его практически не использовали. Сложность реализации и контроля не позволяла самостоятельно управлять этим инструментом — могли только формировать ТЗ для Материнской компании на заказ конкретных справок.

Но именно этот API позволял четко формализовать экономический юнит (вагоноотправку) и работать с ним в контексте процессов Заказчика. Решили копать туда.

Что сделали.

Совместно со специалистами Материнской компании синхронизировали данные о всех вагоноотправках на MS SQL сервер Заказчика. Это стало фундаментом.

Дальше интегрировали процесс планирования перевозок с данными от РЖД — получили классификацию вагоноотправок для аналитики.

Реализовали автоматический расчет тарифов по всем железным дорогам, через которые проходит вагон. API для таких расчетов тогда не было, сделали свое решение на базе официальных Прейскурантов Национальных Железных дорог. Вспомогательные данные интегрировали по API.

На основе анализа перевозок научились прогнозировать сроки доставки текущих грузов.

Свели дислокацию вагонов из разных источников в единую систему.

В итоге построили 40+ витрин данных, описывающих большинство бизнес-процессов Заказчика.

Что изменилось.

1. Экономия от 2900 человекочасов в месяц — расчет тарифов и ставок стал автоматическим. То, что раньше было физически невыполнимо (проверить все 35 тысяч отправок), теперь происходит само.

2. Дополнительная выручка 50-80 млн рублей в месяц. У Заказчика было обязательство не превышать свою долю в 25% общего грузопотока Материнской компании. Штрафы за каждый вагон сверх нормы — серьезные. Поэтому перестраховывались, срезая по 15-25% своего объема в пользу сторонних экспедиторов.

Прозрачная аналитика по классификации вагоноотправок позволила избежать излишней перестраховки. Начали полностью закрывать всю свою долю без рисков. При среднем чеке 40 тысяч рублей за вагон это дало 50-80 миллионов дополнительной выручки ежемесячно.

3. Финпоток 185 млн рублей в месяц под контролем. Расчет тарифов для иностранных ЖД сделал прозрачным процесс экспедирования по территориям других государств. Усилили контроль привлекаемых экспедиторов. В итоге начали самостоятельно экспедировать большую часть грузов вместо подрядчиков.

4. Качество услуг для Материнской компании. Интеграция дислокаций вагонов позволила планировать отправки с учетом реальных потребностей Материнки в доставке грузов и загруженности ее внутренней инфраструктуры. Прямых денег Заказчику это не принесло, но снизило расходы Материнской компании на обработку излишнего парка.

Главный вывод.

Построенная Информационная система не смогла бы ничего принести самостоятельно. Все результаты достиг сам Заказчик и его Материнская компания на основе собственного профессионализма, навыков, знаний и наработанной годами интуиции.

Мы только усилили их понимание бизнеса. Позволили отмахнуться от рутины. Подсветили важные данные об основной деятельности Заказчика. Система дала возможность сосредоточиться на реальных задачах, увеличить эффективность.

Система развивалась вместе с Заказчиком, подстраивалась под его меняющиеся потребности. Что-то прижилось, что-то нет. Это позволило оказать реальную помощь бизнесу, а не гнаться за галочкой "соответствует ТЗ".