Задачи и правила автоматизации без программистов

Автоматизация задач в ERP розничной сети — без программистов

AIERP содержит встроенный конструктор правил автоматизации задач — отдельный модуль внутри ERP, который реагирует на события в системе и сам ставит задачи сотрудникам или магазинам. Логика проста: «если в системе произошло такое-то событие и выполнены такие-то условия — поставь такую-то задачу с таким-то сроком и закрой её, когда повод исчез». Правила собираются в наглядном конструкторе и не требуют участия программиста — администратор сети настраивает их сам.

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

События и условия: как правила реагируют на жизнь сети

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

У каждого правила — набор условий с 14 способами сравнения: «равно», «не равно», «больше», «меньше», «не меньше», «не больше», «входит в список», «не входит», «пусто», «не пусто», «содержит», «не содержит», «начинается с», «заканчивается на». Поддерживаются пять типов значений: строка, число, «да/нет», дата и список. Условия объединяются в группы — внутри группы «и» или «или», между группами «или». Это даёт формулу любой сложности, например «(статус заказа = «поступил» и клиент не уведомлён и в магазине-получателе открыта смена) или (срочный)».

Особенность движка — обращение к связанным сущностям. Можно проверять не только поля самой записи, но и связанные данные: открыта ли сегодня смена в магазине, открыта ли смена в магазине-получателе заказа, кто менеджер контрагента-отправителя. Это критично для розницы: правило «не пиши задачу в магазин, где закрыта смена» — это одно простое условие.

Назначение исполнителя, срок и параметры задачи

Когда условия выполнены, правило формирует задачу. Исполнитель указывается полем записи: магазин целиком, магазин-получатель заказа, менеджер контрагента, ответственный сотрудник. Задача может уйти на роль (все сотрудники с правом), на конкретный магазин или на конкретного человека по связи. У задачи есть название, описание (с подстановкой полей сущности), приоритет (низкий, средний, высокий), срок в часах от создания, чек-лист подзадач и теги.

Сгенерированная задача — это полноценная задача в общем модуле задач AIERP. У неё есть наблюдатели (кто получает уведомления о статусе), чек-листы (обязательные шаги с галочками), напоминания (отложенные уведомления), история изменений статусов, теги и связь с исходным объектом. Это не отдельный «движок задач сбоку», а полноценный объект в системе задач со всеми её возможностями.

Сотрудник получает задачу там, где ему удобно: уведомление в мобильное приложение, на почту или СМС — через флаг «отправить уведомление» и список каналов. В уведомлении — название, описание, прямая ссылка на объект в системе (заказ, остаток, заявку) и кнопка «выполнено». Закрытие задачи из мессенджера сразу обновляет статус в системе.

Автозакрытие задач: умная остановка, а не ручной клик

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

Например, правило «Распечатать ценник» создаёт задачу при появлении признака «требуется новый ценник» и автоматически закрывает её, когда сотрудник нажал «ценник напечатан». Правило «Уведомить клиента» закрывается, когда клиент уведомлён. Правило «Подтвердить перемещение» — при переходе заявки в статус «подтверждена» или «завершена». Это убирает массу «висящих» задач, которые формально выполнены, но никто не нажал «закрыть».

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

Чек-листы, регламенты и регулярные задачи

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

Регулярные задачи ставятся по расписанию: ежедневно в начале смены, еженедельно по понедельникам, в первый день месяца, перед акцией. Это закрывает класс «надо бы не забыть» — никто не забудет, потому что задача появляется сама в нужный момент у нужного исполнителя. Чек-лист в задаче гарантирует, что регламент пройден целиком, а не «галочкой ради галочки».

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

Сроки, эскалации, мониторинг и безопасность правил

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

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

Права на правила управляются стандартной системой ролей AIERP: просмотр, создание, изменение, удаление. По умолчанию полный доступ только у роли «Администратор». Каждое правило можно временно выключить переключателем «активно/выключено» — на время инвентаризации, акции, переноса данных. Все операции с правилами доступны и для подключения извне — правила можно поднимать и гасить из внешних систем.

Производительность и архитектура для крупной сети

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

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

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