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

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

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

Скорость не заменяет маршрут

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

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

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

Первый симптом — невозможно объяснить задачу без длинного разговора

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

Если инструкция состоит из фраз «там обычно понятно», «спроси у Ольги» или «смотри по ситуации», это не повод ругать сотрудника. Чаще всего именно он и удерживает процесс на себе, компенсируя дырки опытом. Но пока эта скрытая часть не названа, её нельзя ни надёжно передать человеку, ни безопасно отдать помощнику.

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

Второй симптом — данные спорят друг с другом

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

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

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

Третий симптом — никто не владеет исключениями

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

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

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

Что на самом деле стоит автоматизировать сначала

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

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

Такой подход кажется медленным только в начале. На деле он экономит недели переделок. Команда видит, какая часть работы действительно повторяется, а какая требует суждения и переговоров. Это намного полезнее, чем поставить дорогой инструмент и потом объяснять, почему он «не прижился».

Плохой процесс не нужно сначала идеально рисовать

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

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

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

Как я проверяю, что автоматизация приносит пользу

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

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

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

Четыре вопроса владельцу процесса

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

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

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

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

Что меняется для команды

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

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

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

Где заканчивается пилот

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

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

Не теряйте ручной маршрут

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

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

С чего начать на этой неделе

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

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