Что такое движок правил в бизнес-процессах: напоминания, назначение, одобрение

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

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

Ценность движка правил – в порядке, который складывается, когда правила собраны вместе. Если правила о предложениях, продлениях, счетах и отпусках записаны в одном месте, руководитель утром видит не то, что идёт хорошо, а то, что отклонилось от правил. Работа, которая не нарушает правило, идёт тихо; внимание уходит только на исключения.

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

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

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

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

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

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

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

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

Разговор с обиженным клиентом или торг по крупному предложению под этот тест не подходят. Здесь правило может напомнить и назначить работу ответственному; сам разговор остаётся за человеком.

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

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

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

Когда правило нарушено, X AI открывает задачу, назначает ответственного и каждое утро одним отчётом сообщает, что сделал, что ждёт и что спрашивает у вас.

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

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