Дублирующиеся расходы на ИИ начинаются с одного сломанного процесса

Почему процесс всё ещё ломается после внедрения нового инструмента ИИ

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

Обычно так не работает. Инструмент меняет один слой, а старый процесс остаётся под ним.

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

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

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

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

Простой пример — команда продаж. Она добавляет ИИ, чтобы писать follow-up письма. Звучит полезно. Но если данные по лиды приходят заполненными лишь частично, названия продуктов непоследовательны, а владельцы аккаунтов меняются прямо посреди сделки, люди всё равно редактируют каждое сообщение перед отправкой. Команда купила скорость, но сохранила путаницу.

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

Откуда начинается дублирование расходов

Дублирующиеся расходы на ИИ обычно начинаются задолго до того, как кто-то замечает проблему в бюджете. Они начинаются тогда, когда две команды пытаются по отдельности решить одну и ту же боль.

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

Перекрытие долго остаётся незаметным, потому что каждая команда видит только свой кусок работы. Один руководитель смотрит на скорость ответа. Другой — на маршрутизацию тикетов. Никто не останавливается и не задаёт простой вопрос: не платим ли мы дважды за обработку одного и того же шага?

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

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

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

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

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

Плохие входные данные создают повторную работу

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

Неправильные метки — частая причина. Если один человек помечает запрос как "billing", другой пишет "invoice", а третий ставит "urgent", инструмент маршрутизации не видит чёткой закономерности. Он отправляет работу не в ту очередь или пересылает один и тот же элемент сразу нескольким командам. Потом кто-то читает его ещё раз, исправляет метку и вручную переносит дальше.

Пропущенные поля создают ту же нагрузку. Если форма не требует номер заказа, account ID или название продукта, инструмент ИИ вынужден угадывать или останавливаться. Большинство команд потом делают медленную часть вручную. Они просят клиента уточнить данные, ждут ответа, снова открывают задачу и начинают процесс заново.

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

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

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

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

Исключения копятся, когда за них никто не отвечает

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

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

Сначала это кажется управляемым. Но обычно так не остаётся. Один человек помечает случай на проверку, другой задаёт дополнительный вопрос, а кто-то ещё позже пытается закрыть его. Работа вроде бы движется, но на самом деле кейс не продвигается.

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

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

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

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

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

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

Один владелец на этап лучше общей ответственности

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

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

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

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

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

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

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

Как разметить процесс шаг за шагом

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

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

Запишите процесс в том порядке, в котором он происходит:

1. Назовите триггер. Что запускает работу и какие данные приходят первыми?
2. Перечислите каждый шаг по порядку. Включите все инструменты, передачи задач и согласования.
3. Отметьте ручные моменты. Покажите, где человек исправляет данные, копирует текст, проверяет результат или дёргает кого-то ради ответа.
4. Отметьте каждое исключение и поставьте рядом одного владельца.
5. Добавьте текущие затраты. Посчитайте ПО, время подрядчиков, внутренние часы и стоимость задержек, прежде чем покупать что-то ещё.

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

Общая ответственность тоже размывает карту. Если три человека могут одобрить, отклонить или исправить один и тот же шаг, никто по-настоящему им не владеет. Поставьте одно имя на каждый шаг, даже если другие могут помогать. Уже это часто объясняет, почему работа замирает.

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

Простой пример из клиентской поддержки

Команда поддержки получает тикеты из трёх каналов: email, chat и web forms. На бумаге всё выглядит современно. Один инструмент ИИ сортирует тикет, другой пишет короткое резюме, а третий готовит ответ.

Команда всё равно ждёт. Клиенты всё равно уточняют дважды. Тикеты по billing по-прежнему попадают в очередь ручной проверки, потому что для них нужны проверки аккаунта, возвраты или решения по политике, с которыми инструменты не справляются до конца сами.

Обычный тикет часто движется так. Приходит письмо, и первый инструмент добавляет категорию. Второй превращает сообщение в краткую сводку для агента. Третий предлагает ответ. Потом агент понимает, что это на самом деле вопрос по billing, и отправляет тикет в другую очередь. Руководитель по финансам или по поддержке читает его ещё раз и пишет настоящий ответ.

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

Более серьёзная проблема — в ответственности. Никто не отвечает за метки, поэтому один и тот же billing-кейс помечают как "payment", "invoice" или "refund" в зависимости от канала. Никто не отвечает за шаблоны, поэтому агенты продолжают переписывать черновик с нуля. Никто не отвечает за правила исключений, поэтому странные случаи накапливаются, пока не вмешается старший сотрудник.

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

Обычно это легко заметить, когда агенты говорят: «Мне всё равно приходится читать весь тред самому» или «chat-tickets работают, а по email всё грязно». ПО изменилось. Процесс — нет.

Лучшее решение обычно скучное. Назначьте одного человека владельцем меток, оставьте один набор шаблонов, которым люди действительно пользуются, и напишите короткое правило, когда billing-кейсы сразу идут на ручную проверку. Это стоит дешевле, чем ещё один инструмент, и сокращает ожидание сильнее.

Ошибки, из-за которых расходы продолжают расти

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

Форма для поддержки или приёма заявок — очень частый пример. Если клиенты могут отправлять расплывчатые запросы, неправильные категории или неполные сведения, инструмент ИИ вынужден гадать. Потом люди всё равно проверяют, исправляют и перенаправляют работу вручную. Компания платит за инструмент и всё равно платит за доработку.

Метки очень быстро создают ту же проблему. Продажи используют один набор тегов, поддержка — другой, а product создаёт третий вариант для своей панели. Вскоре каждой команде нужен свой AI assistant, потому что данные перестают совпадать. Так дублирующиеся расходы на ИИ растут незаметно: один инструмент для сортировки, один для сводок, один для маршрутизации, а люди всё ещё спорят, что именно означает тикет.

Ручная работа часто прячется на виду, потому что никто не ставит ей цену. Если пять человек тратят по 20 минут в день на исправление результата ИИ, это может казаться мелочью. Но за месяц это уже реальные затраты. Многие команды считают это время бесплатным, потому что оно не отражается отдельным счётом за ПО.

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

Потери обычно живут по одним и тем же причинам. Команды покупают до того, как очистили форму. Каждая команда создаёт свои метки и статусы. Руководители игнорируют стоимость ручных исправлений. Никто не отвечает за исключения. Отчёты считают клики, черновики или скорость ответа вместо законченных результатов.

Последний пункт очень важен. Если дашборд показывает, что бот ИИ обработал 80% запросов, это всё равно может быть плохим результатом, если клиентам понадобилось три follow-up или финансам позже пришлось исправить половину записей.

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

Короткий чек-лист перед новой покупкой

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

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

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

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

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

Что делать дальше

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

Потом на минуту остановите покупку инструментов. Новое приложение не исправит плохие входные данные, неясные передачи задач или странные случаи, с которыми никто не знает, что делать. Если процесс запутан уже в первый день, ПО обычно просто ускоряет этот беспорядок.

Сделайте первый проход простым. Запишите каждый шаг — от первого входа до финального результата. Отметьте, где данные приходят поздно, неполными или в неверном формате. Зафиксируйте каждое исключение, которое уводит работу в чат, email или ручное follow-up. Потом дайте одному человеку право убирать перекрытия и принимать решения.

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

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

Если вам нужен внешний взгляд, Oleg Sotnikov на oleg.is работает как Fractional CTO и startup advisor, помогая компаниям практично переводить процессы на ИИ. Такой обзор помогает гораздо легче заметить перекрытия процессов, пробелы в ответственности и дублирующиеся расходы на ИИ.

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