Если считать ROI автоматизации по сэкономленным часам сотрудников, цифры почти всегда получаются лучше, чем в жизни. В прошлом году у нас был проект в производстве: собственник хотел автоматизировать закупки, учет и часть цеховых операций. На старте все держалось на ручной работе. Когда мы разложили потери по деньгам, стало видно, что бюджет утекает не в зарплаты, а в простои линии, задержки закупок на 4-6 дней и расхождения между отделами.
После этого разговор сразу стал предметным: сколько стоит час простоя, где теряется выручка и за какой срок проект вернет вложения. Это и есть нормальная точка входа в автоматизацию.
Ошибка обычно сидит в самой базе расчета
Самая частая ошибка - переводить часы сотрудников в рубли и на этом строить всю модель. Если штат не сокращается и команда не начинает делать больше теми же силами, эти часы не превращаются в деньги. В лучшем случае процесс просто идет спокойнее.
Вторая ошибка - считать по регламенту. На бумаге заявка на закупку проходит за 2 дня, по факту - за 5,5 дня, потому что письмо потерялось, согласующий уехал, данные сверяли вручную. ROI имеет смысл считать по реальным потерям: просрочки, возвраты, переделки, простой, потерянные заказы.
В P&L попадает не "экономия времени", а зарплата, брак, штрафы, простой и недополученная выручка.
Частая ошибка: считать идеальный процесс из инструкции.
Как правильно: поднять логи, переписку, историю заявок и посмотреть, как процесс идет в жизни хотя бы за последние 2-3 месяца.
Что имеет смысл считать еще до старта
Для первичной оценки не нужен трехмесячный аудит. Обычно хватает двух встреч и короткого набора цифр. Я смотрю на пять источников эффекта:
- сокращение ручных операций;
- снижение ошибок и цены исправления;
- ускорение цикла;
- уменьшение простоев и срывов;
- рост выручки, если скорость влияет на обработку заявок и заказов.
У B2B-дистрибьютора заказ обрабатывался вручную 26 минут. Мы смоделировали процесс, собрали прототип на Laravel 11 + PostgreSQL 16 и увидели главное: при цикле 9 минут отдел мог взять до 65% больше заказов без найма. В ROI вошли не только часы команды, но и потери от необработанных лидов в пиковые дни.
В производстве картина обычно жестче. Там деньги лежат в отсутствии материалов, браке, срыве отгрузки и длинном цикле, а не в том, сколько раз менеджер кликнул мышкой.
Достаточно одной таблицы, чтобы принять первое решение
В базовый сценарий я включаю только то, что можно доказать цифрами до старта. "Прозрачность" и "контроль" полезны, но в рубли их лучше не переводить. Такой проект проще защитить перед финансами.
| Показатель | До | После |
|---|---|---|
| Операций в месяц | 8 000 | 8 000 |
| Время на операцию | 12 мин | 5 мин |
| Ошибки | 3,5% | 1,2% |
| Исправление ошибки | 1 800 ₽ | 1 800 ₽ |
| Потенциальный годовой эффект | - | 4,1 млн ₽ |
ROI = (годовой эффект - затраты) / затраты x 100%
Payback Period = инвестиции / средний ежемесячный эффект
TCO = внедрение + лицензии + поддержка + доработки + обучение + внутренняя нагрузка команды
Сколько окупаемости считать нормой?
Для SMB я обычно смотрю на вилку 6-18 месяцев по пилоту. Если выходит дольше, нужен уже стратегический аргумент: требования клиента, выход в новый сегмент, снижение зависимости от ручного контроля.
Быстрее всего окупаются скучные места рядом с ядром
Самые быстрые деньги часто лежат не в основном процессе, а рядом - в согласованиях, закупках, сверках, передаче данных между отделами. Мы это видели много раз.
У производственной компании под NDA цех работал стабильно, но заявки на закупку ходили по почте и Excel. Мы собрали цифровой маршрут согласования на Node.js 20 + NestJS, связали его с учетной системой, и срок прохождения заявки сократился с 5,5 дня до 1,5 дня. Эффект пришел не от интерфейса, а от того, что риск остановки линии заметно снизился.
Такие узкие места легче посчитать, быстрее внедрить и проще защитить внутри компании. Поэтому мы обычно начинаем именно с них.
Когда автоматизация не нужна
Не каждый процесс стоит автоматизировать глубоко. Если кейсы редкие, каждый идет по своей логике, а решение сильно зависит от конкретного специалиста, окупаемость быстро уезжает.
У нас был и неудачный заход с тендерными расчетами. Компания хотела отдельную систему, но таких расчетов было всего 3-4 в месяц, и почти каждый отличался по правилам. Мы посчитали модель, и срок окупаемости выходил больше 4 лет. В большую разработку не пошли, оставили шаблоны документов, правила в CRM и пару интеграций с учетом. Это дало пользу без лишнего бюджета.
Если хотите быстро проверить идею, возьмите один процесс и посчитайте четыре вещи: где теряются деньги, сколько это стоит в месяц, что можно убрать первым релизом и за сколько недель это внедряется. В том производственном проекте из начала статьи деньги лежали совсем не там, где их искали сначала, и именно поэтому расчет окупаемости оказался полезнее самой идеи автоматизации.
