Внедрять ИИ нельзя оставить как есть: где нужна запятая?

Большие структурные перестройки, внедрение ИИ и автоматизация, безусловно, необходимы в современной конкурентной среде. Но куда, зачем и как внедрять — вот самый важный вопрос. Здесь работает пословица: семь раз отмерь, один отрежь. Меня зовут Татьяна Матвиенко, я эксперт по операционной эффективности и трансформации бизнес‑процессов, основатель «КЛАРИТУС Консалтинг». В этой статье расскажу, как определить готовность бизнеса к автоматизации и убедиться, что внедрение ИИ не обернется сливом бюджета.

Пока во многом ИИ — это terra incognita. По данным RAND Corporation, более 80% проектов в области искусственного интеллекта заканчиваются неудачей — примерно вдвое чаще обычных технологических проектов. Есть и другой тревожный показатель: по данным S&P Global Market Intelligence, в 2025 году 42% компаний отказались от большей части своих ИИ‑инициатив против 17% годом ранее. Мы видим, что, с одной стороны, сейчас в целом у всех не хватает опыта длительной работы с ИИ, а с другой — слишком долгая подготовка к внедрению технологий может привести к серьезному отставанию от конкурентов.

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

Автоматизация вообще довольно беспощадна к качеству управления. Хороший процесс она делает быстрее и дешевле. Плохой — позволяет быстрее и дешевле производить ошибки. Поэтому до выбора RPA, low‑code‑платформы, ИИ‑агента или другой технологии я бы провела четыре проверки. Они позволяют довольно быстро понять, стоит ли вообще начинать проект.

Шаг первый: сформулировать задачу и посчитать эффект

Один из самых настораживающих ответов на вопрос «зачем мы автоматизируем этот процесс?» звучит так: «нам нужно повышать эффективность». Эффективность чего? Что должно измениться после внедрения? Сколько денег компания заработает или перестанет терять? Какую проблему клиента решит? Какой риск исчезнет? Хотя бы примерно. Если на эти вопросы нет ответа, обсуждать технологию пока рано.

На практике эффект автоматизации полезно разделять на три типа.

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

Здесь я всегда стараюсь максимально быстро уйти от процентов к абсолютным величинам. «Сократим время обработки на 30%» звучит убедительно только на презентации. Для инвестиционного решения гораздо полезнее другая формулировка: «сможем дополнительно обработать 12 тысяч заказов в год» или «высвободим 18 тысяч рабочих часов».

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

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

Стратегический эффект. Бывают процессы, без автоматизации которых компании просто не способны работать в необходимом масштабе. Телеком‑оператор автоматизирует биллинг не из‑за того, что финансовая модель показала окупаемость за 2,7 года, а потому что отсутствие автоматизации ставит крест на дальнейшем существовании и конкуренции бизнеса. При миллионах операций ручная модель в принципе невозможна. В таких случаях считать нужно не только ROI проекта, но и стоимость бездействия: что произойдет с бизнесом, если оставить процесс таким, как есть.

Попробуйте ответить на три вопроса:

1. Что произойдет, если ничего не менять еще год? А три года?
2. В какую бизнес‑метрику переводится проблема — деньги, риск, скорость, качество?
3. Кто прямо сейчас платит за неэффективность процесса — клиент, или сама компания?

Эти вопросы возвращают разговор из области модной «цифровой трансформации» в область экономики.

Например, одна дистрибьюторская компания пришла с довольно типичным запросом — автоматизировать склад, чтобы «не отставать от рынка». При диагностике выяснилось, что настоящая проблема находится не в уровне цифровизации склада как таковом. Сверка остатков между складской системой и 1С занимала около девяти часов из за отсутствия единых интегрированных справочников, из‑за чего компания не успевала вовремя отгружать примерно 150 заказов ежемесячно. Часть клиентов уходила к конкурентам. Проблему перевели в деньги — около 40 млн рублей упущенной выручки в год. После этого обсуждение проекта полностью изменилось. Совет директоров рассматривал уже не абстрактную автоматизацию склада, а инвестицию в развитие бизнеса, способную вернуть бизнесу конкретную сумму.

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

Шаг второй: проверить, нужен ли процесс в нынешнем виде

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

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

В одной производственной компании договор с поставщиком проходил семь согласующих и в среднем шел по маршруту 12 дней. Анализ истории согласований показал любопытную вещь: содержательные решения фактически принимали два человека — юрист и финансовый директор. Остальные пять участников появились в цепочке в разное время как реакция на отдельные инциденты и практически никогда не останавливали договор и не вносили существенных правок.

После пересмотра регламента число согласующих сократили до трех, а срок прохождения договора — с 12 до четырех дней. Обратите внимание: на этом этапе компания еще ничего не автоматизировала. И только после упрощения процесса автоматизация оставшегося маршрута позволила сократить цикл примерно до одного дня. Причем само внедрение стало существенно дешевле: разработчикам больше не требовалось воспроизводить в системе семь уровней исторически накопившейся бюрократии. Хороший проект автоматизации иногда начинается с решения ничего не автоматизировать, а сначала что‑нибудь удалить.

Шаг третий: считать экономику, а не ощущения

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

По данным McKinsey, 31% компаний, инвестировавших в автоматизацию и ИИ, не увидели заметного изменения в издержках. В то же время Forrester в исследованиях зрелых внедрений фиксирует трехлетний ROI на уровне 248%. Такой разброс хорошо показывает, сама технология почти ничего не говорит об экономическом результате.

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

Поэтому универсального правила вроде «автоматизация должна окупаться за два года» не существует. Для одного процесса три года будут слишком долго, для другого даже пятилетний горизонт окажется рациональным.

Шаг четвертый: оценить зрелость процесса

Есть еще один вопрос, который редко задают до начала проекта: а процесс вообще готов к тому, чтобы его автоматизировали? Алгоритму придется объяснить правила работы значительно точнее, чем новому сотруднику. Человек способен услышать: «обычно делаем так, но с крупными клиентами лучше уточнить у руководителя» — и каким‑то образом с этим работать. Система попросит определить, кто считается крупным клиентом, при каких условиях нужно уточнение, кому отправлять запрос, сколько ждать ответа и что делать, если его нет. И здесь обнаруживается, что значительная часть корпоративных процессов существует не в регламентах, а в коллективной памяти сотрудников.

Для предварительной оценки зрелости процессов можно использовать четырехуровневую шкалу:

1. Хаотичный процесс. Правила существуют преимущественно в головах людей. Два сотрудника выполняют одну операцию по‑разному, исключения решаются звонками и сообщениями. Автоматизировать такой процесс целиком опасно. Сначала придется договориться, какая из версий процесса вообще является правильной.
2. Повторяемый процесс. Основная последовательность действий уже сложилась, но она плохо формализована, а исключения обрабатываются вручную. Здесь хорошо работает частичная автоматизация: машине передают массовые стандартные сценарии, человеку — нестандартные случаи.
3. Стандартизированный процесс. Есть единый регламент, одинаковые правила и понятные роли. Это уже нормальный кандидат для автоматизации.
4. Измеряемый и управляемый процесс. Помимо стандарта существуют метрики времени, качества, стоимости и ошибок, а сам процесс регулярно корректируется на основании данных.Это наиболее благоприятная среда для автоматизации, потому что компания может не только внедрить решение, но и доказать, улучшило ли оно результат.

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

В розничной сети строительных магазинов планировали роботизировать обработку примерно 4000 заявок на возврат товара в месяц. На бумаге кандидат выглядел почти идеально: большой объем и повторяющиеся операции. Диагностика показала другое. В 12 региональных филиалах действовали разные правила возврата, часть решений принималась после звонка директору магазина, информация о браке находилась в трех системах.

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

Когда автоматизацию лучше не запускать

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

1. Первый очевидный случай это слишком маленький объем операций. Если действие выполняется несколько раз в месяц, стоимость разработки и поддержки может годами превышать стоимость ручного труда.
2. Второй — постоянно меняющиеся правила. Если продукт или регулирование меняются быстрее, чем компания успевает перестраивать алгоритм, она рискует создать дорогую систему, которая хронически живет на шаг позади бизнеса.
3. Третий случай сложнее: цена ошибки высока, а решение требует профессионального суждения. Здесь автоматизация необязательно должна исчезать. Просто меняется ее роль. Система может собрать информацию, проверить документы, найти отклонения, предложить вариант решения — но финальный выбор оставить специалисту.

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

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

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

Матрица решения: зрелость процесса и эффект от автоматизации

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

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

Автоматизировать можно почти все. Вопрос — нужно ли

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

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