Почему одна цифра почти всегда вводит в заблуждение
Вопрос «сколько стоит внедрить ИИ» легко свести к цене разработки или подписки. Но за пределами этой суммы могут остаться разбор процесса, подготовка данных, интеграции, настройка прав, тестирование, обработка исключений и поддержка. Пока непонятно, что из этого входит в предложение, сравнивать итоговые суммы рано
В отчёте Маккинзи, опубликованном 25 августа 2026 года, около 20% респондентов сообщили, что операционные расходы уже ограничивают использование ИИ. Опрос проходил с 4 мая по 8 июня и охватил 1 719 участников из 97 стран. При этом 37% связали ИИ с положительным влиянием на прибыль до уплаты процентов и налогов, а около 6% вошли в группу с существенным финансовым эффектом. Показатели опроса McKinsey 2026 основаны на ответах участников, а не на независимой проверке финансовой отчётности 1
Семь статей расходов, которые должны быть видны в смете
Если смета умещается в строку «разработка ИИ-бота», руководитель ещё не понимает, что именно покупает
| Статья расходов | Что в неё входит | Что чаще всего раздувает бюджет |
|---|---|---|
| Разбор процесса | схема текущей работы, исключения, владельцы, метрики | процесс живёт в головах и каждый сотрудник делает по-своему |
| Данные | выгрузки, очистка, база знаний, справочники, разметка примеров | дубли, устаревшие документы, противоречащие правила |
| Интеграции | сайт, телефония, CRM, почта, учётная система, мессенджеры | закрытые интерфейсы, старые системы, нестабильные соединения |
| Логика ИИ | понимание входа, извлечение фактов, выбор действия, ответы | много типов задач и высокая вариативность исключений |
| Контроль | тестовый набор, журнал действий, права, подтверждения человеком | высокая цена ошибки и слабая наблюдаемость процесса |
| Интерфейс | кабинет, очередь исключений, экран проверки, отчёты | попытка построить отдельную платформу без необходимости |
| Эксплуатация | вычисления, запросы моделей, серверы, мониторинг, поддержка | большой объём операций, длинный контекст, частые изменения процесса |
В одном проекте основные расходы приходятся на интеграцию, в другом - на проверку качества: даже простая связь между системами требует серьёзного контроля, если ошибка дорого обходится. Разбивка сметы позволяет увидеть эту разницу
Формула полной стоимости владения на 12 месяцев
Это рабочая модель бюджета, а не бухгалтерский стандарт. Все слагаемые нужно считать в деньгах и за один период; уже включённые в эксплуатацию расходы не добавлять повторно. Ожидаемые потери от ошибок лучше показать отдельно, с пояснением допущений: они отличаются от сумм, которые компания обязательно заплатит
Черновик письма позволяет перехватить ошибку до отправки, но его проверка тоже занимает время. Если система сама меняет цену, отправляет платёжные реквизиты или закрывает сделку, последствия ошибки могут быть гораздо дороже. Внутреннее время руководителя отдела, аналитика и администратора также входит в стоимость проекта, даже если его нет в счёте подрядчика
Три сценария: как объём работ меняет бюджет
Ниже три условных примера архитектуры, а не клиентские кейсы или рыночный прайс. Они показывают, какие работы добавляются по мере расширения задачи; цены без обследования процесса здесь не назначены
Сценарий А - помощник для одного процесса
Компания хочет, чтобы система читала обращения с сайта, определяла интересующий продукт и кратко пересказывала заявку менеджеру. ИИ ничего не отправляет клиенту и не меняет данные самостоятельно. Основная работа - подготовить примеры, подключить источник обращений, проверить классификацию и встроить результат в привычный экран сотрудника. Проверка человеком позволяет заметить ошибку до внешнего действия, но её время нужно учесть в бюджете
Сценарий Б - рабочая автоматизация отдела
Система получает заявки из нескольких каналов, ищет существующего клиента, заполняет карточку, создаёт задачу, готовит ответ и следит за следующим контактом. Здесь уже нужны защита от дублей и повторных событий, права доступа, очередь ошибок и журнал действий: от автоматизации зависит повседневная работа отдела
Сценарий В - агент между несколькими системами
Агент сам выбирает последовательность действий, читает данные из разных источников, меняет состояния и может инициировать внешнее действие. Помимо интеграций, понадобятся тесты всей цепочки, ограничения прав, подтверждение критичных операций и остановка при нехватке данных. После изменения модели или процесса поведение агента придётся проверять заново
Как сравнить две сметы на одном листе
Попросите каждого подрядчика заполнить одинаковую таблицу
| Вопрос | Предложение 1 | Предложение 2 |
|---|---|---|
| Какой конкретный процесс меняется | ||
| Как выглядит исходная метрика | ||
| Какие системы подключаются | ||
| Какие данные нужно подготовить | ||
| Какие действия ИИ выполняет сам | ||
| Что всегда подтверждает человек | ||
| Как проверяется качество до запуска | ||
| Где хранятся журналы действий | ||
| Что входит в поддержку | ||
| Что оплачивается ежемесячно | ||
| Кому принадлежат сценарии и настройки | ||
| Сколько стоит изменение процесса после запуска |
После заполнения таблицы разницу в цене можно обсуждать предметно: какие работы и риски учёл один подрядчик и не учёл другой
Как считать окупаемость до разработки
Для предварительной оценки окупаемости сначала измерьте текущую работу. В условном примере восемь сотрудников тратят по 35 минут в день на одну административную задачу. При 21 рабочем дне это 8 × 35 × 21 ÷ 60 = 98 часов в месяц. Это объём работы до автоматизации, ещё не обещанная экономия
Прежде чем переводить эти часы в деньги, выясните следующее
- Сколько из этих часов действительно исчезнет после внедрения
- Освободившееся время превратится в полезную работу или просто растворится в календаре
- Какие ошибки или потери система уменьшит помимо времени
- Какую часть процесса всё равно придётся обслуживать вручную
Высвобождённое время считайте отдельно. Если сотрудники успевают больше работы, эффект может проявиться в дополнительной марже или отказе от запланированного найма. Но пока загрузка и расходы не изменились, сами по себе 98 часов прибылью не стали. Одну и ту же выгоду нельзя учесть одновременно как экономию труда и как дополнительную маржу
Когда дешёвый проект становится самым дорогим
Не посчитана поддержка. Первый месяц всё работает, затем меняется поле в системе клиентов, обновляется форма или появляется новый тип заявки. Если никто не отвечает за наблюдение и изменения, «готовый проект» начинает требовать аварийных доработок
Нет тестового набора. Команда проверяет несколько удобных примеров, но не проверяет реальные исключения. Набор характерных и сложных случаев нужно сохранить и повторно прогонять после изменений
Слишком рано дали автономность. Система сразу получила право отправлять сообщения, менять статусы и принимать решения. Цена разработки вроде не выросла, зато резко выросли стоимость контроля и последствия ошибок
Создали отдельный интерфейс без необходимости. Иногда сотруднику достаточно увидеть результат в уже используемой системе. Отдельный кабинет добавляет разработку, авторизацию, роли, поддержку и обучение, хотя бизнес-задача от этого не становится лучше
Красные флаги в коммерческом предложении
- точная финальная цена до разговора о процессе и данных
- обещание «автоматизировать отдел» без перечня операций
- отсутствие метрики успеха
- нет разделения разовых и ежемесячных расходов
- нет ответа, как проверяется качество до запуска
- не описаны действия при ошибке интеграции
- нет границ автономности
- подрядчик не может объяснить, что останется у бизнеса после прекращения сотрудничества
Часть этих пунктов не делает предложение плохим автоматически. Но каждый неотвеченный вопрос превращается в неопределённость, которая позже обычно оплачивается отдельно
Где экономить разумно, а где опасно
Разумно начать с одного процесса, использовать существующие интерфейсы, оставить человеку дорогие исключения и подключать системы по мере подтверждения эффекта. Но если ИИ действует от имени компании, сокращать бюджет за счёт журналирования, резервных сценариев и проверки качества опасно: именно они позволяют заметить ошибку и ограничить её последствия
В том же опросе Маккинзи почти три четверти группы с высоким финансовым эффектом сообщили о фундаментальном изменении рабочих процессов, среди остальных - примерно четверть. Опрос показывает связь, но не доказывает, что перестройка процесса сама по себе обеспечивает окупаемость 1. Для сметы из этого следует полезный вопрос: какие шаги можно убрать ещё до разработки, вместо того чтобы оплачивать их автоматизацию
Какой документ должен появиться до сметы
Перед запросом цены соберите одностраничный паспорт проекта
Паспорт для запроса сметы
- какой процесс меняется и где он начинается и заканчивается
- сколько операций проходит в месяц
- сколько времени и денег процесс стоит сейчас
- какие системы и данные участвуют
- какие ошибки происходят сегодня
- какие действия можно автоматизировать без подтверждения
- какие действия всегда остаются человеку
- какая метрика должна измениться, чтобы проект считался успешным
Паспорт даёт подрядчику границы задачи, а руководителю - основу для сравнения предложений. Неопределённые пункты лучше обсудить до сметы, пока они не превратились в дополнительные работы
источники и методика
- Маккинзи: исследование состояния ИИ, 2026 - опубликовано 25 августа; опрос 4 мая - 8 июня, 1 719 участников из 97 стран. Группа высокого эффекта: участники, относящие к ИИ не менее 5% прибыли до процентов и налогов и оценивающие его влияние как значительное. Самооценка, не аудит отчётности
Три сценария архитектуры и пример с 98 часами условные, не клиентские результаты. Формулы и паспорт проекта - инструменты планирования; они не задают рыночную цену и не гарантируют окупаемость
