CRM-платформа с low-code/no-code-настройкой: пользователь собирает объектную модель раздела, настраивает бизнес-процессы и маршруты согласования под свой бизнес.
Дизайнер бизнес-процессов — инструмент, через который пользователь описывает автоматизации в системе: что должно происходить при определённых событиях, как данные должны двигаться между разделами, какие уведомления и действия должны срабатывать.
TL;DR
Дизайнер бизнес-процессов представляет из себя визуальный конструктор автоматизаций: пользователь собирает процесс из элементов — триггеры, действия с данными, шлюзы, уведомления — на холсте. Дизайнер раздела даёт возможность настраивать структуру данных, бизнес-процессы — описывать, как эти данные ведут себя в работе.
Собрал визуальный конструктор процессов с триггерами разного типа, CRUD-операциями над записями, шлюзами для ветвления логики, формулами для работы с параметрами и встроенными уведомлениями. Дополнительно — две связанные с конструктором таблицы: библиотека процессов и журнал запущенных процессов с отображением статусов исполнения по каждому элементу.
На мне был весь цикл: проработка структуры конструктора, проектирование интерфейса для каждого типа элемента, проработка движка исполнения с точки зрения интерфейса, защита решений перед бизнесом и командой, декомпозиция, поддержка разработки до релиза.
Уведомления как элемент бизнес-процессов
Внедрение уведомлений в существующий движок автоматизаций — отдельным элементом, который можно ставить в процессы наравне с действиями и шлюзами.
Ситуация
Пользователь должен получать уведомления о событиях, которые его касаются. Назначили активность, изменился статус по записи, в которой он указан, и так далее.
Задача
Закрыть сценарий, при котором пользователь получает уведомления о значимых для него событиях в системе, и сделать настройку этих уведомлений гибкой, чтобы покрыть и типовые случаи, и нестандартные.
Действия
Изначальное решение — отдельный элемент «Уведомление» в дизайнере бизнес-процессов. Элемент ставится в процесс наравне с другими, получатели задаются через параметры, тело — через формулу. Любые условия срабатывания, любые получатели, любой текст.
Затем возникла другая идея. Ведь дизайнер бизнес-процессов задумывался как движок для сложных автоматизаций, и использовать его, чтобы отправить уведомление, может быть избыточно. Подумали в сторону механизма подписки на изменения записи: если пользователь упомянут в записи, он автоматически подписывается на изменения. В настройках раздела можно чекбоксами выбрать конкретные колонки, по изменению которых нужно получать уведомления.
Проработал альтернативу как полноценное дизайн-решение и вынес оба варианта на обсуждение. Подсветил плюсы и минусы каждого. По итогам всё-таки решили идти по изначальному пути — элемент в дизайнере бизнес-процессов. Второй вариант остался в бэклоге.
Результат
В продукте появились уведомления — встроенные в движок бизнес-процессов как отдельный элемент. Гибкость, которую дал этот подход: любые условия срабатывания через шлюзы, любые получатели через параметры, любое тело уведомления через формулу. Отдельной системы для уведомлений делать не пришлось.
Итог
Дизайнер бизнес-процессов был для меня проектом с другой парадигмой проектирования. Если в дизайнере раздела пользователь работает со структурированной формой настроек, а в маршрутах — с линейной схемой согласования, то здесь — с холстом и независимыми элементами, между которыми течёт логика исполнения. Пользователь не заполняет настройки сверху вниз, а собирает граф: ставит элементы, соединяет их потоками, настраивает условия ветвления, передаёт данные через параметры между элементами.
Продукт не вышел в коммерческую эксплуатацию. Дизайнер бизнес-процессов — инструмент, который, я думаю, оценивается через то, что в нём собирают, и сделать такую оценку в полной мере без реальных клиентов невозможно. На этапе проектирования опирался на известные сценарии — проверял, что автоматизации собираются через интерфейс. Дальше нужны данные использования: какие элементы востребованы, насколько сложные процессы собирают клиенты, обращения в поддержку.
Проект дал мне опыт проектирования визуального конструктора, в котором логика собирается на нескольких уровнях: каждым отдельным элементом, способами их соединения и общим движком исполнения.