Есть цифра, после которой нормальный руководитель должен закрыть проект и больше к нему не возвращаться. 10–15 лет окупаемости.

Именно столько получилось у нас в расчётной модели по одному из процессов, которые мы обследовали все в том же холдинге из девяти предприятий.

Причём процесс на первый взгляд подходил для автоматизации отлично. Закупки. Много ручной работы, заявки ходят по разным каналам, цены надо проверять, остатки на складе тоже, где-то требуется тендер, где-то дефектовка — техническое подтверждение, что деталь действительно неисправна и её нужно менять. Над всем этим сидит руководитель экономического блока и каждый день вручную контролирует счета. На проверку у него уходит примерно полчаса в день.

В целевой схеме мы рассчитывали сократить эти полчаса примерно до пяти минут. Плюс снять часть ручных сверок со снабженца. В сумме получалось около 13 освобождённых часов в месяц.

Если перевести это в деньги по оценочным ставкам ФОТ — примерно 67 тысяч рублей в год.

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

Получаем те самые 10–15 лет окупаемости. На этом месте финансовая модель как будто говорит: ребята, расходимся.

Но процесс мы из программы не убрали.Потому что человеко-часы здесь оказались не главным эффектом.

Что на самом деле происходило с закупкой

Если сильно упростить, цепочка была такой: инициатор формировал заявку, руководитель подразделения её подписывал. После этого нужно было проверить, нет ли нужной позиции на складе. Если покупать всё-таки нужно, снабженец собирал предложения поставщиков, выбирал вариант, получал от поставщика счёт и передавал его на проверку руководителю экономического блока.

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

Это было видно и по реестру заявок за апрель–май 2026 года, который нам передали для анализа: из 56 заявок примерно две трети были либо без формального номера, либо вообще устными. То есть значительная часть закупок не оставляла нормального документального следа, по которому потом можно было восстановить основание и историю согласования.

А дальше счёт попадал к тому самому руководителю экономического блока — на финальную проверку перед оплатой.

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

То есть его полчаса в день были не просто ещё одной ручной операцией.

Человек фактически стоял у кассы. Он и оставался последним ручным фильтром перед оплатой.

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

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

Но здесь мы упёрлись в ограничение: посчитать этот эффект в деньгах тогда было невозможно. Такой статистики компания раньше не вела.

В расчётной модели по этому процессу у нас в итоге стояли рядом две строки.

Первая — экономия трудозатрат. Её мы посчитали: около 67 тысяч рублей в год.

Вторая — предотвращённые финансовые потери от завышенных цен, ненужных и нецелевых закупок.

А напротив второй строки: не квантифицировано.

Мне эта запись нравится гораздо больше, чем красивый ROI, высосанный из пальца.

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

Значит, на старте у проекта есть гипотеза эффекта. Фактическая цифра появится позже.

В нашем случае в программу как раз заложили накопление такой статистики. Система должна фиксировать аномалии, решение человека и итог по каждой спорной заявке. Через несколько месяцев уже можно вернуться к журналу и посчитать, сколько денег реально удалось не потерять.

До этого момента писать в презентации «сэкономили N миллионов» рано.

А где здесь вообще ИИ?

Для первого этапа здесь вообще не нужна сложная ИИ-система.

Никакой нейросети, которая сидит вместо начальника отдела закупок и рассуждает, брать подшипник за 18 тысяч или за 24.

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

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

На момент обследования в 1С было заведено больше 23 тысяч наименований запчастей, материалов и других закупаемых позиций. При этом по большинству из них не было нормальной истории цен, а одна и та же запчасть могла числиться под разными названиями. Поэтому сравнить новый счёт с «обычной» ценой система просто не могла.

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

После этого уже можно искать аномалии.

И финальное решение всё равно остаётся за человеком. Система поднимает флаг и показывает причину. Руководитель экономического блока смотрит и либо останавливает покупку, либо подтверждает её, потому что знает контекст, которого в данных нет.

Не всё считается в человеко-часах

Вообще человеко-часы хорошо работают далеко не для любой автоматизации.

С протоколами совещаний всё наглядно: было 3–4 часа ручной работы, стало несколько минут проверки. С первичными документами тоже можно посчитать, сколько ручного ввода исчезло.

А попробуйте тем же способом оценить систему, которая ищет брак на производстве. Она может не сократить ни одного человека.

Если до неё сотрудник десять минут смотрел на линию и вместе с ней продолжает десять минут контролировать линию, по ФОТ экономия — ноль. Но если система заметила дефект раньше и партия не уезжает клиенту, эффект есть.

С безопасностью похожая история. С контролем договоров. С мошенничеством. С закупками.

Там зарплата человека зачастую вообще не главная статья потерь.

Поэтому в таких процессах мы разделяем экономику хотя бы на три части:

·  трудозатраты — сколько ручной работы действительно исчезает;

·  потери и ошибки — сколько денег система помогает не потерять;

·  скорость процесса — что даёт бизнесу сокращение самого цикла, если ожидание тоже стоит денег.

Первая часть считается легко.

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

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

Если цифр нет — не надо их придумывать

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

Мы так не считаем. Если истории нет — значит, истории нет.

Ставим измерение внутрь пилота и набираем статистику.

Поэтому процесс закупок с его страшными 10–15 годами окупаемости по трудозатратам остался в программе. Только продавать его как способ освободить 13 часов в месяц было бы довольно глупо.

Эти часы — самый маленький эффект из тех, ради которых там вообще имеет смысл что-либо делать.

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

И если при расчёте ИИ-проекта у вас есть только формула «часы × зарплата», я бы не спешил делать выводы об окупаемости. Сначала посмотрите, что происходит с деньгами внутри самого процесса. А если этого сегодня никто не измеряет — начните измерять.

Хуже плохой окупаемости только красивый ROI, собранный из цифр, которых в компании никогда не существовало.