Таксономия исключений для бизнес‑процессов перед автоматизацией

Почему объём автоматизации продолжает расти

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

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

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

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

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

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

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

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

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

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

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

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

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

Разбивайте еженедельные странные случаи по простым корзинам

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

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

• Отсутствующие данные
• Риск по политике или финансам
• Срочно, но разрешено
• Согласование одним человеком
• Внешнее подтверждение или возврат в цикл

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

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

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

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

Как шаг за шагом собрать таксономию

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

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

1. Соберите одну неделю странных случаев из почты, чата и тикетов. Одной недели обычно достаточно, чтобы показать паттерны, не превращая это в исследование.
2. Перепишите каждый случай одним простым предложением: «Когда X происходит, команда делает Y потому что Z.» Например: «Когда клиент пропускает номер контракта, служба поддержки просит отдел продаж подтвердить его, прежде чем продолжить выставление счёта.»
3. Раннее объединяйте дубликаты. Люди по‑разному описывают одну и ту же проблему, поэтому почистите это до начала спора.
4. Дайте каждому случаю корзину, владельца и приблизительную частоту. Простых меток достаточно: отсутствующая информация, конфликт правил, задержка согласования, проблема внешней системы или необычный запрос клиента.
5. Запишите следующее действие, которое должна выполнить система. Будьте конкретны. Попросить недостающие данные, направить человеку, приостановить задачу, отклонить её или создать последующий тикет.

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

Держите формулировки скучными

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

Добавляйте частоту до обсуждения автоматизации

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

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

Решите, что автоматизировать сейчас, а что оставить ручным

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

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

Практический первый релиз обычно соответствует таким правилам:

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

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

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

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

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

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

Пример: согласования покупок с необычными случаями

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

Хаос начинается, когда команда обрабатывает необычные случаи по привычке, а не по правилу. Люди постоянно добавляют ещё одну ветвь, ещё одно исключение, ещё одну пометку. Поток растёт, а ясность падает.

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

Полезные корзины для этого процесса

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

• Нет доказательства покупки
• Срочный запрос без ответа менеджера
• Покупка на несколько бюджетов/разделённый счёт у поставщика
• Подозрение на мошенничество или злоупотребление политикой

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

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

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

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

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

Ошибки, которые съедают время

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

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

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

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

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

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

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

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

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

Короткий чек‑лист перед началом разработки

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

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

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

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

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

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

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

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

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

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

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

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

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