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

Почему для повседневных проблем в процессах нужны понятные маршруты

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

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

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

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

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

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

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

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

Определите каждое исключение до создания процесса

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

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

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

Используйте статусы, которые описывают текущее состояние. «Ожидает заявителя», «Отклонена», «Просрочена» и «Нужна ручная проверка» лучше, чем «Исключение 2» или «Ожидает действия». Человек, просматривающий список, должен сразу понять, что произошло и кто действует следующим.

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

В no-code-приложении оформляйте исключения как видимые изменения статуса и отдельные маршруты бизнес-процесса. Визуальный Business Process Editor в AppMaster помогает отображать решения, назначать ответственных и передавать заявки на следующий шаг. Используйте одинаковые формулировки в списках статусов, уведомлениях и интерфейсах сотрудников.

Направляйте заявки с недостающей информацией по отдельному маршруту

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

Статус должен запускать прямое сообщение заявителю. Не используйте расплывчатые заметки вроде «Нужны дополнительные сведения». Назовите недостающий элемент и объясните, каким должен быть приемлемый ответ: «Приложите предложение поставщика и укажите ежемесячную стоимость, чтобы мы могли проверить эту заявку на покупку».

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

Сделайте маршрут возврата явным

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

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

Используйте напоминания и правило закрытия

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

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

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

Обрабатывайте отклоненные заявки, сохраняя контекст

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

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

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

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

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

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

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

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

Задайте правила для просроченных задач

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

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

Отправьте напоминание до истечения срока. Уведомление в момент, когда прошло 75% доступного времени, часто дает ответственному достаточно времени для действий. Для задачи на пять дней отправьте его на четвертый день. Укажите название задачи, срок, текущего ответственного и требуемое действие. Сообщение «У вас есть незавершенная задача» дает слишком мало информации.

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

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

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

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

Добавьте удобный для сотрудников этап ручной проверки

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

Сделайте процесс ручной проверки целевым. Направляйте туда только заявки, которым действительно нужна оценка, и показывайте причину передачи. Расплывчатый статус «Нужна проверка» создает дополнительную работу: проверяющему приходится сначала выяснять, почему процесс остановился.

Дайте проверяющим достаточно контекста

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

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

Ограничьте срок принятия решения

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

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

В AppMaster Business Process может направить исключение в задачу на проверку, сохранить решение и комментарий, а затем продолжить процесс по отдельному маршруту согласования, отказа или внесения изменений. Задача остается связанной с исходной заявкой, поэтому сотрудникам не приходится восстанавливать историю по электронной почте.

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

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

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

Финансовый отдел проверяет оставшийся бюджет отдела и отклоняет заявку, потому что сумма превышает месячный лимит. Процесс обработки отклоненных заявок сохраняет исходную форму, предложение, комментарии и историю согласования вместе. Статус меняется на «Отклонена по бюджету», а заявитель получает понятное сообщение: «Сократите заказ до 1 800 долларов или подождите до следующего месяца».

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

Если согласование приходит с опозданием

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

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

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

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

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

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

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

Несколько правил помогают не превращать исключения в бесконечную переписку по электронной почте:

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

Незаметные сроки создают особые проблемы. Задача может несколько дней лежать без движения, пока каждый думает, что за нее отвечает кто-то другой. Правило управления просроченными задачами должно сначала уведомлять исполнителя, а через установленный период назначенного руководителя. Используйте измеримое правило, например одно напоминание через 24 часа и эскалацию через 48 часов.

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

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

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

Быстрая проверка и следующие шаги

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

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

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

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

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

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

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