Наблюдаемость рабочих процессов с ИИ для поиска узких мест в бизнес‑процессах

Почему быстрая модель ИИ всё ещё может оставлять работу зависшей

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

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

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

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

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

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

Метрики, которые показывают, где замедляется работа

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

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

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

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

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

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

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

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

Еженедельный обзор становится понятным, если задать несколько прямых вопросов:

• На каком шаге самая старая очередь?
• Где время передачи резко увеличивается?
• Упал ли процент утверждений?
• Сколько работы вернулось на доработку?
• Какой доле задач стали исключениями?

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

Начните с простой карты рабочего процесса

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

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

Для наблюдаемости AI‑workflow карта должна показывать не только место запуска модели. Она должна показывать, где люди останавливаются, проверяют, редактируют, утверждают или отправляют работу назад. Именно там позже становятся полезны метрики бизнес‑процесса.

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

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

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

Уhandoffs должны иметь имена, а не только должности. «Проверка финансов» менее полезно, чем «проверяет ведущий по расчётам». Когда у передачи нет явного владельца, работа дрейфует. Люди предполагают, что кто‑то другой подхватит, и время передачи растёт незаметно.

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

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

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

Выберите один рабочий процесс, начало и конец которого находятся в явном виде. Хороший первый выбор — что‑то рутинное, например запрос доступа, возврат клиенту или согласование закупки. Если начало или конец расплывчаты, ваши числа будут расплывчатыми тоже.

В наблюдаемости AI‑workflow процесс важнее вызова модели. Многие команды логируют момент, когда ИИ ответил, и на этом останавливаются. Тогда остаётся вне учёта часть, где работа сидит в очереди, ждёт человека, отправляется назад или требует второго просмотра.

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

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

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

Доработкам нужны собственные маркеры. Считайте каждое возвращение, редактирование, второе утверждение и повторную отправку. Когда задача возвращается, записывайте причину. Короткая причина вроде «нет поля» или «несоответствие политике» достаточна. За неделю анализ процента утверждений и доработок скажет, понятен ли процесс или люди постоянно исправляют одну и ту же проблему.

Держите первый период наблюдения коротким. Часто достаточно одной недели, чтобы заметить паттерны и не утяжелять настройку.

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

Простой пример: согласование счета с ИИ

Рабочий процесс со счётом показывает, почему быстрая модель ИИ не всегда означает быстрые операции. Модель может прочитать PDF за секунды, но счёт всё равно может лежать два дня, прежде чем кто‑то его утвердит. Именно эту разницу должна выявлять наблюдаемость AI‑workflow.

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

Если смотреть только на задержку модели, числа выглядят прекрасно. Экстрактор возвращает данные за 12 секунд. Проверка в финансах занимает 4 минуты. Полный цикл, однако, занимает 31 час. Большая часть этого времени сидит в одном месте: в очереди на утверждение у менеджера.

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

Эти числа расскажут яснее, чем «ИИ быстрый». Представьте 100 счетов на этой неделе. Модель обрабатывает все 100 менее чем за 20 секунд каждый. Финансы принимают 82 с первого прохода, но отправляют 18 обратно — потому что отсутствует PO, имя поставщика не совпадает или сумма кажется неверной. Менеджеры утверждают 63 в тот же день, 29 на следующий и 8 позже. Теперь ограничение очевидно.

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

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

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

Ошибки, которые скрывают реальное узкое место

Быстрая модель может оказаться в медленном процессе. Команды часто празднуют 2‑секундный ответ ИИ, в то время как задача ждёт 6 часов, прежде чем кто‑то её просмотрит, исправит или передаст дальше. Хорошая наблюдаемость AI‑workflow смотрит дальше вызова модели и следует за работой, пока кто‑то её не завершит.

Первая ошибка — смотреть только на API‑латентность и ничего больше. Скорость модели важна, но редко объясняет, почему работа накапливается. Если возраст очереди продолжает расти, проблема чаще в штатах, утверждениях, отсутствии данных или неаккуратной передаче между инструментами. Быстрая модель мало поможет, когда элементы ждут весь день в очереди проверки.

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

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

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

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

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

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

Быстрая проверка для еженедельного обзора

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

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

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

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

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

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

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

Что делать дальше с числами

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

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

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

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

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

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

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

Когда рабочий процесс пересекает ИИ, софт и несколько команд, настройка быстро усложняется. В таких случаях внешняя помощь экономит время. Oleg Sotnikov на oleg.is работает со стартапами и малыми компаниями по AI‑first разработке продуктов, автоматизации и Fractional CTO‑поддержке, и может помочь решить, что измерять в первую очередь, не превращая проект в тяжёлую отчётную работу.

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