Достаточно ли стабилен процесс для ИИ: как оценить бизнес‑процесс

Почему команды автоматизируют нестабильную работу

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

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

Утверждения ломаются так же. Менеджер может утвердить что‑то, потому что это «выглядит нормально», а не потому что правило чётко определяет, что считать приемлемым. Люди могут так жить какое‑то время. Программное обеспечение — нет. Если правило решения живёт в привычке, а не в словах, ИИ придётся угадывать, а угадывание — плохая база для автоматизации.

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

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

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

Как выглядит стабильный процесс

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

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

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

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

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

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

Сначала проверьте входы

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

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

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

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

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

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

Картографируйте утверждения и передачи

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

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

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

Ваша карта должна отвечать на четыре вопроса: кто получает работу, кто решает да/нет/удержание, какие факты они используют для решения и куда работа идёт дальше.

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

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

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

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

Посмотрите на споры, исключения и доработки

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

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

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

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

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

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

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

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

Оцените один процесс шаг за шагом

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

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

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

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

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

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

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

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

Простой пример с утверждением счёта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Короткий чеклист перед автоматизацией

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

Используйте небольшую выборку сначала. Вытяните один месяц кейсов или хотя бы 20–30 реальных примеров. Затем проверяйте одни и те же проблемы каждый раз.

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

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

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

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

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

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

Держите первый пилот узким и с человеком в цепочке. В первые недели ИИ должен предлагать, черновать, сортировать или помечать. Человек всё ещё должен утверждать результат, прежде чем что‑то уйдёт к клиенту, поставщику или другой команде.

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

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

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

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

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

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