Картирование процессов при внедрении ИИ начинается с исключений

Почему идеального сценария недостаточно

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

Реальная работа начинается, когда что‑то идёт не так. Одно пропущенное поле может остановить весь поток. Если в карточке клиента нет телефона, в счёте нет кода проекта или у запроса нет ответственного, у ИИ недостаточно контекста, чтобы безопасно продолжать.

Тогда вовлекаются люди. Кто‑то смотрит старые сообщения, просит недостающие данные, исправляет запись или отправляет запрос менеджеру, который не был частью официального процесса. Эти мелкие «починки» — и есть процесс. Это не побочные заметки.

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

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

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

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

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

Что считается исключением

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

Большинство исключений не драматичны. Это мелкие разрывы, которые происходят ежедневно: форма пришла без ID клиента, дата в неверном формате, две записи описывают один и тот же заказ или запрос пришёл без документа, который требует политика. Команды часто относятся к таким вещам как к мелкой очистке. Но они не мелкие, если происходят 15 раз в день.

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

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

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

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

Найдите точки, где работа застревает

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

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

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

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

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

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

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

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

Картируйте утверждения до автоматизации

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

Начните с записи каждого утверждения простым языком. Кто говорит «да», что именно они проверяют и что заставляет их вернуть задачу? Если два менеджера утверждают одно и то же по разным причинам, это не один шаг. Это два решения, и карта должна это отражать.

Многие карты утверждений проваливаются потому, что команды фиксируют только официальное правило. Реальное правило часто живёт в голове у кого‑то. Финансовый лидер может отклонять счёт без кода центра затрат, даже если в политике об этом ничего нет. Менеджер по продажам может давать скидки до 15% при условии, что клиент не новый, не имеет просрочек и не просил особых условий. Эти негласные проверки формируют процесс больше, чем сама форма.

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

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

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

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

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

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

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

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

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

Держите правила короткими и конкретными. «Если общая скидка выше 15%, утверждает менеджер по продажам» — полезно. «Эскалировать необычные случаи» — не полезно. То же самое и для отсутствующих данных. Назовите поле, назовите, кто его заполняет, и укажите, останавливается ли процесс, продолжается ли он или переходит к человеку.

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

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

Простой пример из повседневной практики

Клиент просит возврат. Чистый случай выглядит просто: покупка была три дня назад, товар не использован, чек в записи заказа и сумма совпадает с исходной оплатой. Саппорт проверяет заказ, система подтверждает политику, возврат проходит без проверки.

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

Возможно, у клиента нет чека. Возможно, нужен частичный возврат, потому что один товар в наборе пришёл повреждённым. Может быть, запрос поступил на 45‑й день, а окно возврата — 30 дней. Каждый случай ведёт запрос по разному пути.

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

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

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

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

Ошибки, которые команды делают в начале

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

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

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

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

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

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

Быстрая проверка перед автоматизацией

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

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

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

Утверждения нужны в виде правил, а не привычек. «Спросите финансы, если кажется большим» — не правило. «Финансы утверждают любую трату свыше $2,000» — правило. ИИ может следовать правилу, логировать его и передавать остальное человеку. Он не читает мысли.

Прежде чем автоматизировать, убедитесь, что команда ответит на пять простых вопросов:

• Кто владеет каждым шагом?
• Какой надёжный источник для каждого обязательного поля?
• Какое правило управляет каждым утверждением?
• Что происходит при появлении исключения?
• Что ИИ может делать, а что должно оставаться за человеком?

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

Картирование процессов обычно проваливается в мелочах: пустой ID клиента, менеджер, который иногда утверждает в чате, а иногда по почте, или запрос без владельца после 17:00. Эти детали кажутся мелкими, пока система не наткнётся на них 50 раз в день.

Если команда не может ответить на эти пять вопросов простым языком, подождите. Сначала исправьте процесс. Затем автоматизируйте повторяющиеся части.

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

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

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

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

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

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

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