Автоматизация бизнес-процессов — это перенос повторяемых действий и правил из ручной работы в систему: она принимает данные, проверяет условия, передаёт задачу дальше и фиксирует результат. На схеме такой процесс обычно выглядит аккуратно: заявка поступила, ответственный назначен, документ подготовлен, клиент уведомлён. В реальной работе между этими шагами быстро появляются оговорки.
У клиента может не оказаться нужного документа. Заказ может прийти от филиала, которого нет в справочнике. Сумма — выйти за обычный диапазон. Ответственный сотрудник — заболеть. Два источника — прислать разные данные об одной операции. Именно в таких местах автоматизация чаще всего и ломается: система получает ситуацию, для которой у неё нет понятного правила.
Поэтому до разработки полезно изучить не только основной маршрут процесса, но и его неровные края. Чем раньше они станут видны, тем проще определить, где нужны правила, где проверка, а где осознанное решение человека.
Как найти исключения до начала разработки?
Я бы не начинал с вопроса «как должен работать процесс». Он почти неизбежно приводит к красивой схеме, которая описывает нормальный день. Гораздо полезнее сначала восстановить несколько реальных случаев от начала до конца и посмотреть, где сотрудники отходили от стандартного порядка.
Для этого можно взять недавние заявки, сделки, платежи, обращения или документы. Среди них нужны не только успешно закрытые, но и зависшие, возвращённые, отменённые, исправленные вручную. По каждому случаю важно понять, какие данные пришли на входе, кто принимал решения, чего не хватало и почему пришлось менять обычный маршрут.
Хороший источник исключений — не регламент, а люди, которые ежедневно разбирают последствия. Менеджер помнит, когда клиент прислал сведения в свободной форме. Бухгалтер знает, почему платёж иногда нельзя сопоставить со счётом. Руководитель отдела видит, какие задачи приходится срочно переназначать. Такие детали редко попадают в официальное описание, хотя именно они определяют надёжность будущей системы.
Полезно отдельно собрать фразы вроде «обычно мы делаем так, кроме случаев, когда…» и «если это важный клиент, тогда…». За ними почти всегда скрываются условия, которых нет на основной схеме. Ещё один сигнал — таблицы, заметки и переписка, где сотрудники ведут дополнительный учёт. Если рядом с официальной системой существует ручной список, значит часть процесса уже вышла за её границы.
Получившийся список не надо сразу превращать в техническое задание. Сначала исключения стоит сгруппировать: неполные данные, ошибочный формат, дубликаты, конфликт сведений, превышение лимита, отсутствие ответственного, внешняя система недоступна. Так вместо десятков частных историй появляются несколько понятных типов ситуаций, для которых можно обсуждать правила.
Какие нестандартные случаи нужно автоматизировать, а какие оставить человеку?
Здесь я смотрю не на то, насколько случай необычен, а на то, можно ли принять решение по устойчивому и проверяемому правилу. Если правило одинаково понимают разные сотрудники, его результат легко проверить, а ошибка обратима, такой случай обычно имеет смысл передать системе.
Например, она может отклонить файл неподдерживаемого формата, найти повторную заявку по идентификатору, запросить обязательное поле или перенаправить задачу другому сотруднику при отсутствии основного. Это тоже исключения, но они предсказуемы: для них можно заранее определить условие и нужное действие.
Человеку лучше оставить ситуации, где требуется оценить контекст, договориться, истолковать неоднозначную информацию или принять заметный деловой риск. Система может показать расхождение между договором и заявкой, но не всегда должна сама решать, какая версия верна. Она может обнаружить заказ с необычными условиями, однако окончательное согласование скидки или отсрочки часто зависит не только от формальных полей.
Удобная граница проходит между обнаружением и решением. Обнаруживать отклонения, собирать связанные данные и уведомлять ответственного можно автоматически. Принимать необратимое или спорное решение стоит только тогда, когда критерии действительно однозначны.
Важно учитывать и цену контроля. Если редкий случай возникает раз в год, а для его автоматизации понадобится сложная логика, отдельная интеграция и постоянное обслуживание, ручная обработка может быть разумнее. И наоборот, сравнительно редкое исключение стоит автоматизировать, если ошибка в нём способна остановить весь процесс или остаться незамеченной.
Это не поражение автоматизации. Хорошая система не обязана самостоятельно закрывать каждую ветку. Её задача — уверенно выполнять понятную часть работы и безопасно передавать остальное сотруднику вместе с контекстом.
Что должна делать система, если ей не хватает данных?
Недостаток данных должен быть предусмотренным состоянием, а не неожиданной ошибкой. Система не должна додумывать сведения, подставлять сомнительные значения или молча продолжать процесс. Ей нужен отдельный маршрут для неполного входа.
Сначала стоит определить, какие поля действительно обязательны для конкретного шага. Иногда процесс можно начать без полного комплекта и запросить недостающее позже. В другом случае продолжение создаст ошибочный документ, неверный расчёт или дублирующую операцию. Тогда шаг нужно остановить.
Сообщение о проблеме должно объяснять, чего именно не хватает и что делать дальше. Формулировка «ошибка обработки» бесполезна и сотруднику, и клиенту. Гораздо понятнее указать, что не найден номер договора, дата имеет неверный формат или контрагент отсутствует в справочнике.
После этого система может вернуть задачу источнику данных, направить запрос ответственному или поместить случай в отдельную очередь проверки. Очередь — это просто список ситуаций, которые нельзя безопасно обработать автоматически. В ней должны быть видны причина остановки, исходные сведения, время ожидания и доступные действия.
Важно сохранить уже полученные данные. Если после исправления сотруднику приходится повторно вводить всё с начала, система переносит техническую проблему на человека. Лучше продолжить процесс с остановленного места, одновременно записав, кто добавил или изменил информацию.
Полезен и предел ожидания. Заявка без документа не должна незаметно лежать месяцами. Напоминание, передача другому ответственному или закрытие по установленному правилу превращают зависание в управляемый статус.
Кто принимает решение при спорной ситуации?
Ответ на этот вопрос должен быть частью самого процесса, а не срочной договорённостью в рабочем чате. Для каждого типа спорных случаев нужен владелец решения: конкретная роль, а не фамилия человека, который может уйти в отпуск или сменить должность.
Операционное расхождение может разбирать руководитель отдела, финансовое — сотрудник с нужными полномочиями, юридическое — профильный специалист. Если решение зависит от суммы, типа клиента или последствий, можно задать уровни согласования. Тогда система понимает, кому передать случай, а сотрудник видит предел своих полномочий.
Одного назначения ответственного мало. Вместе со спорной задачей ему нужно показать исходные данные, найденное противоречие, предыдущие действия и срок ответа. Иначе он будет заново собирать контекст по письмам и таблицам, а автоматизация лишь быстрее доставит ему непонятную проблему.
Решение стоит фиксировать в понятной форме: одобрено, отклонено, возвращено на уточнение, выбран один из вариантов. Свободный комментарий полезен как пояснение, но не должен быть единственным результатом. Структурированная запись помогает продолжить процесс и позже увидеть, какие споры повторяются.
Нужен и маршрут замещения. Если основной ответственный недоступен, задача должна перейти человеку с теми же полномочиями или подняться на следующий уровень. Иначе формально правильная схема остановится из-за обычного отпуска.
Повторяющиеся решения можно со временем превратить в новые правила. Но делать это стоит только после проверки: одинаково ли сотрудники оценивают такие случаи и не меняется ли результат из-за контекста, который система пока не видит.
Как проверять работу процесса после изменений?
Проверка начинается с набора контрольных сценариев. В него входят обычный случай, несколько известных исключений, неполные данные, дубликат, спорная ситуация, недоступность внешнего источника и отсутствие ответственного. Для каждого сценария заранее нужен ожидаемый результат: какой статус появится, кому уйдёт задача, что сохранится и как процесс продолжится после исправления.
После любого изменения полезно прогонять не только новую ветку, но и основной маршрут. Исправление редкого случая иногда влияет на привычную работу: меняет условие перехода, обязательность поля или порядок уведомлений.
В рабочем процессе я бы наблюдал не только за количеством успешно завершённых операций. Показательнее доля ручных вмешательств, число возвратов, время ожидания в очереди исключений, повторные ошибки и случаи, которые пришлось обходить вне системы. Резкий рост таких событий часто говорит о том, что изменились входные данные или появилось новое исключение.
Журнал действий помогает разобраться, где именно возникло отклонение. В нём достаточно фиксировать значимые события: какие данные поступили, какое правило сработало, кто принял решение и чем завершился случай. Это не тотальный надзор за сотрудниками, а способ восстановить ход процесса без догадок.
Первый практический шаг простой: возьмите десять последних случаев из выбранного процесса, включая проблемные, и разложите их по фактическим действиям. Если для каждого отклонения понятно, может ли система продолжить работу, каких данных ей не хватает и кому передать решение, процесс уже можно предметно обсуждать для автоматизации. Если ответы держатся только в памяти отдельных сотрудников, сначала стоит зафиксировать эти правила.