Прикладное использование Задачи по простому бизнес-процессу

Появившийся в новых версиях "простой бизнес-процесс" позиционируется как легкий инструмент для автоматизации типовых бизнес-процессов компании с возможностью (но не обязательностью) вложения объекта. Зачастую подразумевается именно процесс с заданиями сотрудникам для выполнения. Но некоторые процессы могут состоять только из самого запроса/запуска процесса и получения уведомления о их завершении.

Рассмотрим на примере несколько распространенных кейсов, для решения которых ранее требовалось большое количество ручного труда или привлечение разработчиков/администраторов и (что не рекомендуется) прямые запросы к БД.

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

Разбор кейсов

Кейс 1. Передача документов уволенного сотрудника

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

Настроим проверку массива договорных (для примера) документов на наличие уволенных сотрудников в качестве ответственных и их замену на руководителей подразделения, указанного в документе.

В качестве критерия процесса укажем ограничение по возможности запуска сотрудниками.

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

Укажем нужные параметры для вычисления:

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

Для удобства сотрудников, указываем Тему задачи при выборе процесса:

На блоке предварительного условия в текущем примере поставлено сравнение разности количества всех вложений с списком исправленных документов. Аналогично отработает проверка количества элементов в параметре Список подразделений в документах (если больше 0, то «Да»).

Так же при старте блока Условие выбираем Подразделение, для документов которого будем проводить замену ответственного; и убираем выбранное подразделение из параметра Список подразделений. Таким образом мы последовательно будем забирать из общего списка подразделений по одному элементу.

 При установке условия параметру списка документов эти действия необходимо перенести на блок скрипта ниже.

При завершении блока условия с результатом «Да» проводим изменение свойств объектов: меняем ответственного:

И записываем в Список исправленных документов все вложения с данным подразделением.

Блок «Ожидание» устанавливаем с выражением «Текущая дата и время», это позволит притормозить выполнение блока условия повторно (до завершения выполнения изменения свойств).

В качестве результата получаем массив документов с Ответственными = Руководителями указанных в документе подразделений вместо уволенных сотрудников.

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

Кейс 2. Очистка данных после миграции документов

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

Кейс заказчика – по списку таких сотрудников указать нового ответственного и заменить указанное служебное подразделение на подразделение нового ответственного.

Стандартное решение – список запросов к базе или модификация утилиты импорта из таблицы с откорректированными значениями.

Решение силами No-code – простой бизнес-процесс.

Предварительные действия:

1. Создадим роль со списком уволенных сотрудников, подлежащих замене в документации.
2. Создадим вычисляемую роль с контекстом Сотрудник, в которой укажем заместителей данных сотрудников. Важный момент – в нашем кейсе заместитель указан прямо и зависит только от самого заменяемого сотрудника, но и кейс с вычислением нового ответственного по контексту Договорного документа также возможен.

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

Создадим нужный вариант процесса:

Укажем необходимы для работы параметры:

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

Алгоритм процесса схож с примером выше:

1. На старте процесса вычисляем Список сотрудников для замены:

2. На блоке Условие проверяем наличие документов для исправления:

3. При наличии документов на замену – запускаем цепочку скриптов:
   1. Вычисляем замещаемого сотрудника

1. 2. Вычисляем заместителя

1. 3. Снимаем блокировку поля Подразделение у нужных документов
   4. Производим замену Подразделения

1. 5. Производим замену Ответственного

1. 6. Возвращаем блокировку поля Подразделение и убираем заменённого сотрудника из списка к замене.

Возвращаемся к предварительному условию и проверяем наличие незаменённых сотрудников.

По завершению замен отправляем уведомление Инициатору.

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

Важный момент – снятие блокировки поля Подразделение в данном случае – изменение свойства Регистрация у договорного документа. Именно поэтому важно установить в критерии варианта процесса проверку запускающего сотрудника и провести предварительный анализ допустимости такого действия (отсутствие настройки регистрации по подразделению, например).

Ограничения и огорчения применения Задач по простому бизнес-процессу

1. Изменение свойств объектов начинает вычисление выражение только с «Задача». Выбрать заранее сформированную коллекцию объектов из Параметров процесса невозможно. Это сильно затрудняет процесс, так как формировать коллекцию на изменение приходится комбинацией фильтров.
2. Нет возможности указать цепочку выполнения действий с параметром «ожидать выполнения предшествующего действия». Приходится использовать цепочку блоков Ожидание с выражением Текущая дата и время вместо срока ожидания.
3. Сообщения об ошибках процесса не очень информативны. Хорошо, что хотя бы есть указание «Ошибка вычисления» или «Ошибка выполнения» и номер блока с ошибкой.
4. Появление ошибки выполнения зависит даже от размещения одного и того же вычисления на старте или завершении блока без объяснения причин (предполагаю, что не успевает отработать вычисление на завершении предшествующего блока).
5. Не всегда очевидны результаты вычислений. Например, вычисляемая роль возвращает коллекцию субъектов прав, при этом её можно выбрать в качестве значения свойства типа Сотрудник без ошибки на отладке, но с ошибкой при выполнении процесса.
6. Разумеется, в данных процессах всегда есть ограничение количества вложений. Что могло бы быть решено при наличии возможности устанавливать значения Параметра процесса от любого из справочников или списков в системе.

Результаты

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

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

Среди дальнейших кейсов по использованию простого бизнес-процесса:

• сортировка архивных документов с вычислением подразделения и ответственного по значению свойств документа
• проверка сроков действия документов и их перевод в статус «устаревший» по комбинации признаков.