40М ежемесячных потерь. Почему проект по их устранению провалился.

Заказчик.

Многопрофильная транспортная компания, основной бизнес — самосвальные перевозки сыпучих грузов. Мы уже внедрили у клиента систему учета рейсов и BI-аналитику финансовых показателей. Результат — рост выручки с 90М до 135М рублей в месяц (+50%).

Доверие было, результаты были. Решили копать дальше.

Проблема.

Вместе с ростом выручки значительно увеличились затраты. Аналитика позволила разбить их по статьям: 75-80% приходилось на лизинг, кредиты, ФОТ, топливо и ремонты. Среди них выделялись ремонты — они напрямую влияли на простои автопарка, и именно их можно было улучшить силами Заказчика.

Вот что увидели:

1. Прямые затраты на ремонты: 22 млн руб/месяц. Рост затрат соответствовал росту общей выручки бизнеса, но значительно опережал производственные показатели, что вызывало подозрения. При этом компания инвестировала более 25 млн руб в запуск собственного автосервиса. С его запуском затраты на ремонты не сократились, а выросли.

2. Процесс не формализован. Заявки от водителей приходили по телефону, вечером фиксировались в Excel по памяти в свободной форме. Данные о сроках, поломках, стоимости — либо в примечаниях, либо нигде. Анализировать невозможно.

3. Простои на ремонтах: 9-12 млн руб в месяц убытка, если считать среднесуточную выручку автомобиля.

4. Фиктивные выходы на линию и KPI. Машины, обозначенные механиками как рабочие, не могли везти груз. Их "выпускали на линию" только на бумаге или гоняли порожними рейсами, чтобы выполнить KPI: неважно, что машина не может везти груз, главное — чтобы она прошла 250 км в сутки. Убыток — 5-8 млн руб ежемесячно на ФОТ водителей и топливо.

5. Ад логистам. Водители и логисты не понимали сроков окончания ремонта, планирование вывоза грузов превращалось в хаос.

Итого: ~40 млн рублей в месяц уходит на ремонты, есть потенциал на снижение затрат 2-3 кратно.

Подход к решению.

Именно ремонты были на предприятии тем "бутылочным горлышком", ограничивающим рост компании в целом.

Наметили цели:

1. Формализовать ввод данных о ремонте, сделать его возможным в момент поступления заявки

2. Создать инструмент накопления структурированных данных для аналитики

3. Обеспечить оперативное информирование сотрудников: статус, сроки, ответственный, место проведения

4. Разработать аналитические витрины об эффективности ремонтов

Решение.

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

Собственную разработку построили на Clean Architecture: разделение кода по слоям, формализация бизнес-сущностей, интеграция сторонних API без превращения проекта в свалку спагетти-кода.

Интегрировали API стороннего сервиса, существующей системы Заказчика, сервиса телеметрии и слежения за автомобилями. Структурировали и объединили данные, получили возможность накопления для аналитики.

Для уведомлений использовали три инструмента: личный кабинет стороннего сервиса, витрины данных в Metabase и Telegram-бота с механизмом подписки на ремонты конкретных автомобилей.

Стек: Okdesk, Python, Clean Architecture, LiteStar, Advanced SQLAlchemy, alembic, aiogram, Telegram, PostgreSQL, Redis, Metabase, Docker, microservices.

Далее требовалось внедрение…

Анализ провала.

Перед внедрением прошли путь одобрения снизу вверх: от исполнителей к среднему руководству и директору. Показали проблему, получили одобрение концепции и реализации.

Саботаж исполнителей. Его ждали. Люди годами привыкали к накатанным решениям, не верили в оптимизацию. Демонстрации продукта, обучение, всесторонняя поддержка сработали — на исполнительском уровне продукт зашел в работу.

Пример реакции пользователя: "Я целый день должен отписываться в различные чаты по ремонтам, а тут вы еще со своей программой".

Наш ответ: "Смотри. Мы сейчас вместе создали заявку и отписали её в автосервис, все причастные получили уведомления. Задача, которая занимала у тебя 1-2 часа на созвоны, решена за 30 секунд". Плюс один поклонник продукта в компании.

Саботаж среднего руководства. Их KPI исходил из пройденного километража каждой машины и статистики выхода на линию, которая считалась вручную. Новая система несла риск лишиться премий. Ответственный за бизнес-процесс сотрудник вкладывал время и усилия в изучение продукта, раз за разом запрашивал добавление нового функционала, но в итоге наотрез отказался работать без видимых объективных причин.

Владелец процесса с прямыми затратами в 22 млн рублей в месяц защищал зарплату: не только свою, но и своего отдела, который он собирал годами.

Мы поняли: решить боль Заказчика не выйдет, если не решим боль сотрудников — обеспечить их достойной и стабильной зарплатой. Нужна помощь директора.

Саботаж директора. Директор дважды в неделю собирал совещания с механиками, обсуждал каждый ремонт, вникал, какая машина где ремонтируется, какую запчасть покупают. Уверенно, по его мнению, владел ситуацией. Чтобы мотивировать механиков, разработал систему KPI: зарплата зависит от выхода на линию, а выход на линию — когда машина проехала 250 км за день.

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

Без помощи директора не получится обезопасить коллектив от рисков потери зарплат при внедрении новых показателей. Без помощи коллектива не получится внедрить систему. На понимание этого ушла ещё неделя, в течение которой мы пробовали запуститься с имеющимися возможностями. После чего покинули проект.

Выводы.

Мы верно определили "бутылочное горлышко" компании, исследовали и выявили реальные потери, в том числе скрытые — общие расходы на ремонты 40 млн рублей в месяц можно было сократить как минимум в два раза.

IT-технологии, особенно аналитика, призваны быть фонариком для руководства компаний: освещать объективную реальность, показывать её историю, строить прогнозы. "Для руководства", а не "вместо руководства". IT — инструмент, а руки и голова — у Заказчика.

Микроменеджмент руководства губителен для бизнеса. Директор не должен знать, какую резину поставили на заднюю ось 158-го тягача на восходящую луну месяца. Директор должен знать реальную финансовую картину своего предприятия.

Кривые показатели эффективности — ещё более серьёзная проблема. Особенно, когда они ложатся в KPI. Качественные показатели, нацеленные на причинение пользы бизнесу существенно помогают его росту, отсутствие таких показателей возлагает всю ответственность на внутреннюю мотивацию команды, но неверно выбранные показатели заставляют хороших сотрудников делать плохие для бизнеса вещи.