Внедрили ИИ в компанию с парком 400 авто. Выручка не выросла ни на рубль — и это лучший результат, который мы могли получить

Внедрили ИИ в компанию с парком 400 авто. Выручка не выросла ни на рубль — и это лучший результат, который мы могли получить

Пять месяцев назад мы начали разворачивать корпоративную AI-экосистему в компании, которая сдаёт автомобили в аренду водителям такси. Парк — около 400 машин, несколько регионов, управляющая компания и офисы в городах. Собственник, технический директор, финансовый директор, коммерческий директор.

Заказчик пришёл с формулировкой, которую я слышу почти от каждого: «хотим внедрить нейросети, чтобы вырасти». Через месяц работы стало очевидно, что расти ему пока некуда — и что настоящие деньги лежат в другом месте.

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

ПОЧЕМУ ВЫРУЧКА НЕ ВЫРОСЛА

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

То есть рычаг «рост выручки» был физически заблокирован. Оставался второй: расходы. И вот тут выяснилась неприятная вещь — компания не знала, сколько именно она переплачивает.

ЧТО НАШЛА СИСТЕМА В ТЕХНИЧЕСКОМ БЛОКЕ

Ремонт был второй статьёй расходов после лизинга. Согласование смет от сервисов шло вручную: технический директор смотрел документ и принимал решение, опираясь на память и здравый смысл. По нескольким сотням машин.

Что сделали (руками технического директора, не нашими):

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

2. Гарантийный свод по запчастям. Каждая установленная деталь получила гарантийный срок. Если она выходит из строя внутри этого срока, система подсвечивает: меняем по гарантии. До этого сервис спокойно менял деталь ещё раз — за счёт компании.

3. Оцифровка технического блока целиком: автоматизированный сбор заявок, бюджет ремонта на одну машину в разрезе марок и ремонтных боксов, срок ремонта, учёт товарно-материальных ценностей.

Результат за период внедрения, со слов технического директора:

— бюджет технического ремонта: минус 25–30% — доля парка, стоящего в ремонте: 14% → 5,7% — среднее время ремонта: минус 65% — время закрытия смет: минус 38% — цикл заявки: ускорился в три раза за четыре месяца — только за июль: срезано около 1,15 млн ₽ работ, которые сервис заявил к оплате

И отдельно — то, чего вообще не существовало: заявки на ремонт как учётная сущность. Раньше их не было. Ремонт начинался с разговора, а не с записи. Сравнивать «до» не с чем, потому что «до» не считалось.

Что НЕ получилось: кузовной ремонт не подешевел. Там ценообразование другое, механика подсветки повторов не работает. Пишу честно — обычно в кейсах эту часть вырезают.

ЧТО ПРОИЗОШЛО С ФОНДОМ ОПЛАТЫ ТРУДА

Финансовый директор: фонд оплаты труда снижен на 20%. Сокращено не менее пяти человек — часть службы поддержки и часть продавцов. Их функции ушли не «в нейросеть», а в мобильное приложение компании, которое команда написала сама за пять месяцев. Около 70% вопросов водителей закрывается в приложении без человека.

СКОЛЬКО ЭТО СТОИЛО

Раз я прошу вас верить цифрам экономии, честно покажу и обратную сторону.

Внедрение обошлось компании примерно в 4 500 USDT единоразово плюс корпоративная подписка на модели — это прямые расходы, они идут разработчику модели, не мне. Всё остальное команда делала своими руками: я вёл сессии, давал промпты и разбирал блокеры.

Сопоставьте с одной цифрой выше: 500 000 ₽ экономии по фонду оплаты труда в месяц. Внедрение стоило дешевле, чем один месяц этой экономии. Годовой эффект превышает стоимость проекта примерно в 15–20 раз — и это без учёта экономии на ремонте, которую мы ещё сверяем по документам.

Я специально не считаю ROI в процентах и не рисую графики окупаемости. Вот две цифры, вот арифметика, посчитайте сами. Ровно так же я предпочитаю считать на цифрах клиента до начала работы, а не обещать «эффект 40%», которого никто потом не проверяет.

ПОЧЕМУ Я НЕ ПОКАЗЫВАЮ ВАМ P&L

Самая красивая цифра, которую я мог бы вынести в заголовок, у меня есть. Я её не публикую, и вот почему.

Когда я попросил финансового директора привязать результат к отчёту о прибылях и убытках, он ответил прямо: брать P&L как метрику эффекта от автоматизации некорректно. Компания перераспределяет расходы на будущие периоды, и в отчёте это выглядит не так, как в реальности.

Второе: экономия признаётся с задержкой. Сервисам платят с отсрочкой в месяц-полтора. Экономию июня компания начала чувствовать деньгами только в августе. Любой, кто в июле показал бы вам «эффект внедрения» по банковской выписке, показал бы вам июньские платежи по майским работам.

Это скучная правда, и она стоит дороже красивого графика. Если подрядчик приносит вам ROI через месяц после старта — он либо не понимает, как устроен ваш учёт, либо понимает и рассчитывает, что не поймёте вы.

ЧТО СКАЗАЛИ САМИ РУКОВОДИТЕЛИ

Технический директор: «Времени стало втрое больше. Я никого не жду, пока мне кто-то что-то сделает. Программисты не нужны». Делает три-четыре задачи параллельно. Его формулировка про инструмент: «это как молоток для строителя — если кто-то работает палкой, он уже проиграл».

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

Собственник сформулировал итог сам: решена задача масштабироваться без роста численности управляющей компании. И второе, более важное: «проблемы теперь решаются на уровне причины, а не последствий».

ГЛАВНЫЙ ВЫВОД, ЕСЛИ ЧИТАТЬ ТОЛЬКО ОДИН АБЗАЦ

Самое дорогое, что находит корпоративный ИИ в первые месяцы, — не автоматизации. Это течи и ошибки в ваших собственных данных. Повторные ремонты, которые никто не сверял. Гарантийные детали, за которые вы платили дважды. Подрядчик, у которого есть акты и нет цифрового следа работы (в этой компании так закрыли договор с SEO-агентством и готовят иск). Функции, которые давно можно не выполнять.

Автоматизация приходит потом. И приносит меньше, чем наведённый порядок.

Мы в DNAI Engineering разворачиваем такие контуры целиком: владение данными, роли, автоматизации руками самих руководителей и передача системы внутреннему «хранителю», чтобы компания не зависела от подрядчика. dnai.engineering

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

2