На данной вкладке настраивается маршрут согласования — состав и порядок подписей, которые запрашиваются для выполнения перехода. Маршрут согласования может задаваться статически и динамически. Статический маршрут содержит набор подписей, которые всегда запрашиваются на данном переходе в определенном порядке. Динамический маршрут (матрица согласования) формируется в момент начала перехода посредством SQL запроса или хранимой процедуры.
Настройка перехода. Вкладка "Подписи на переходе"
По умолчанию в списке отображаются все подписи. С помощью отбора по статусу можно отобразить список только активных или только неактивных подписей.
Отбор по статусу
Каждая подпись имеет:
•причину запроса (например, "Согласовать платёж", "Подтвердить выполнение заявки"),
•одного или нескольких акцептантов (пользователей, у которых запрашивается подпись и которые должны вынести решение),
•срок обработки (это необязательная, но полезная характеристика подписи, которая защищает от пробуксовки процесса),
•резолюции — набор возможных решений (например, "Согласовать", "Отклонить", "Согласовать с замечаниями" и т.п.).
Резолюции отображаются в виде кнопок — акцептант нажимает кнопку, и вынесенная резолюция фиксируется в системе.
Часто для согласования нужно запросить несколько подписей, по определенным условиям и в определенной последовательности. Например, для согласования договора сначала запрашивается подпись руководителя отдела, затем подпись финансового директора, а если сумма договора превышает 1 млн рублей, то в конце запрашивается еще и подпись генерального директора.
Если порядок запроса подписей неважен, они запрашиваются одновременно, т.е. на одном этапе маршрута согласования. Такие подписи еще называются параллельными. Если порядок запроса подписей важен, они разносятся по нескольким последовательным этапам. На скриншоте ниже на первом этапе параллельно запрашиваются две подписи (неважно, какая из них будет обработана раньше), а затем последовательно запрашиваются еще две подписи (в этом случае их порядок важен).
Пример маршрута согласования
Кроме порядка запроса подписей важно продумать:
1. Всегда ли нужно запрашивать все подписи, или для запроса есть определенные условия (например, большая сумма договора и т.п.);
2. Что будет, если подпись отклоняется. В этом случае можно вернуть задачу на предыдущий этап для доработки, а можно совсем отклонить задачу;
3. Если одна из подписей отклоняется, надо ли ожидать решений остальных участников, или процесс согласования нужно сразу же прервать ("право вето");
4. Если задача отправлялась на доработку, весь процесс согласования нужно начинать заново и снова получать все подписи, или при повторном согласовании нужно запрашивать только те подписи, которые еще не были получены на предыдущих итерациях.
Какие статусы нужны для согласования
Как правило, согласованию предшествует подготовительная работа — нужно собрать информацию и внести ее в дополнительные параметры, составить проект документа. Часто эти работы выполняются на статусе, который называется Подготовка (или близко по смыслу). На этом статусе исполнитель должен иметь право редактировать (изменять) ДП.
После того, как подготовительные работы выполнены, собранные данные и документы отправляются на согласование. Подпись запрашивается в тот момент, когда пользователь нажимает кнопку перехода. Пока задача находится на согласовании, т.е. подписи запрошены, но еще не обработаны, задача получает промежуточный статус — к исходному статусу добавляется префикс "На подписи". Например, если подписи запрашиваются на переходе из статуса Подготовка, то промежуточный статус будет называться На подписи — Подготовка.
В этом промежуточном статусе права на редактирование ДП соответствуют исходному статусу. Чаще всего это означает, что ДП всё ещё открыты для редактирования. Таким образом, пользователь сможет изменить значения ДП даже когда какие-то подписи уже обработаны, а остальные еще ожидают резолюции. Это неправильно и недопустимо.
Чтобы защитить данные и файлы от изменения в процессе согласования, а также чтобы сделать БП более прозрачным, при согласовании мы рекомендуем добавлять в БП отдельный статус Согласование. При переходе в этот статус задачу нужно сразу же переводить в следующий статус с помощью смарт-автоматизации, при этом будет инициироваться запрос подписей. Во-первых, так задача получит более понятный промежуточный статус На подписи — Согласование. Во-вторых, на этом статусе вы сможете защитить ДП от изменения и оставить доступ только на чтение.
Пример настройки процедуры согласования с использованием дополнительного статуса и смарт-автоматизации
Статус при отклонении подписи
При настройке процедуры согласования не забудьте продумать и указать, в какой статус должна перейти задача при отклонении подписи. Здесь возможен один из трёх вариантов:
1. При отклонении подписи задача остается в исходном статусе,
2. При отклонении подписи задача тоже отклоняется,
3. При отклонении подписи задача переводится в какой-то определенный статус.
По умолчанию используется вариант 1.
Если вы используете дополнительный статус Согласование (как в примере, описанном выше), при отклонении подписи нужно либо вернуть задачу в статус Подготовка (вариант c), либо отклонить задачу совсем (вариант b). Если же оставить по умолчанию вариант a, то задача "застрянет" в статусе Согласование, и исполнитель не сможет ни вернуть задачу на подготовку вручную, ни отклонить, ни двигаться дальше.
Порядок действий при запросе подписи на переходе
1. Запрашиваются подписи, выбранные на вкладке Подписи на переходе.
2. В случае согласования:
•Задача переходит в следующий статус.
•Запускается процедура при переходе.
•Ставятся подзадачи заложенные в блоке "Подзадачи на шаге".
3. В случае отклонения задача возвращается в статус, указанный в настройках подписи, или в исходный статус (если в настройках подписи статус не указан).
Порядок действий при обработке запрошенных подписей
1. Из базы данных загружается информация об обрабатываемой подписи и вынесенной акцептантом резолюции.
2. Выполняются пакеты смарт-действий, привязанные к событиям:
•Перед акцептом подписи,
•Перед делегированием подписи,
•Перед отклонением подписи,
•Перед удалением подписи,
•Перед эскалированием подписи.
3. Проверяются права пользователя (акцептанта) на выполнение действий, связанных с вынесенной резолюцией.
4. Создается "мгновенный снимок" (snapshot) задачи на момент вынесения резолюции.
5. Новое состояние подписи и принятая резолюция записываются в базу данных.
6. Публикуется комментарий в задачу, отправляется письмо с уведомлением о вынесенной резолюции.
7. Проверяется статус текущего этапа согласования: завершен ли этап или есть еще подписи, которые должны быть обработаны на данном этапе; нужно ли ждать решений остальных участников.
8. Если этап согласования завершен, то проверяется наличие следующего этапа, и если такой этап есть, то он инициируется.
9. Обновляется статус задачи в базе данных (снимается признак "На подписи").
10. Файлы отправляются в Sharepoint.
11. Если подпись была акцептована и запрашивалась для подтверждения таких действий как изменение срока, смена заказчика, внесение трудозатрат, то соответствующие действия выполняются.
12. Если подпись была отклонена, то выполняются действия при отклонении подписи.
13. Выполняется переход задачи по маршруту и связанные с этим действия (изменение ДП, создание подзадач).
14. Выполняются пакеты смарт-действий, привязанные к событиям:
•После отклонения динамической подписи,
•После отклонения статической подписи,
•После подписания динамической подписи,
•После подписания статической подписи,
•После удаления динамической подписи,
•После эскалирования динамической подписи.
