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