Проектные элементы БП. Общие свойства.

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

 

Пакет элементов вместе с группой разделов, куда входят «Процессы», «Статистика», «Ситуации» и «Сообщения», а также деталь «Процессы» легко переносятся на любые проектные решения версий с 3.2.0. до 3.3.2. Важно отметить, что хотя возможность переноса отдельных частей функционала существует, предпочтительно, всё же, загрузка всего описываемого пакета целиком. Реализация данного решения продумывалась именно как комплекс; так, чтобы одним пакетом закрыть максимальное количество возможных задач, в том числе с учётом будущих, более высоких требований к ним.

 

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

 

Одним из важнейших свойств всех проектных элементов является их привязка к ролям пользователей в процессе, например, «Менеджер по продаже», «Руководитель отдела», «Владелец процесса».

 

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

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

 

 

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

 

 

На случай, если данный пользователь в отпуске, в командировке, или отсутствует по другим причинам, в системе существует справочник заместителей, в котором можно указать промежуток времени и заместителя отсутствующего пользователя. При трансляции роли система автоматически переставляет шаги бизнес процесса на указанного заместителя. Поиск заместителя осуществляется каскадно, то есть, если у заместителя в свою очередь есть заместитель, то владельцем шага будет выбран заместитель заместителя и т.д. пока не будет найден истинный заместитель, либо система не обнаружит «рыбу» (когда А замещает Б, а Б замещает А).

 

 

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

 

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

 

Важен также и тот момент, что бизнес-процесс по возможности назначает права доступа к связанным сущностям для пользователей, транслируемых из роли. Это позволяет избежать ошибок, связанных с недостаточной продуманностью распределения прав, а также даёт важный дополнительный функционал, когда заранее неизвестно, кто должен получить права на работу с той или иной записью, либо разграничить права доступа обычными способами трудозатратно. Например, если существуют два типа продаж – «продажа» и «тендер», непросто настроить администрирование так, чтобы менеджеры по продажам имели доступ только к «продажам», а менеджеры по тендерам – только к «тендерам» (то есть, сделать так, чтобы права доступа зависели от типа сущности). Между тем бизнес процесс при транслировании пользователя из роли в процессе эти права раздаёт. Если, например, роль транслируется в зависимости от типа сущности на того либо другого менеджера, только он и будет видеть связанную сущность. Другой пользователь этой записи вовсе не увидит, если в разделе администрирования у него нет таких прав. Так менеджеры по тендерам получают доступ только к продажам типа «тендер», а менеджеры по продажам – только на «продажи», проходя каждый по своей ветке процесса.

 

Использование ролей в процессе является огромным преимуществом при его проектировании и даёт значимую экономию времени. Достаточно просто выбрать нужную роль из списка. Вся «механика» остаётся за кадром, нет нужды настраивать параметры процесса и элементов, их связи и т.п.

 

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

 

 

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

 

 

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

 

 

Также на всех открываемых по БП карточках система создаёт кнопки «Связи процесса», облегчающие навигацию по используемым в процессе сущностям:

 

 

Во многих случаях это избавляет от необходимости добавлять в сущность дополнительные поля только ради процесса. Собственно, сами элементы тоже умеют создавать доп. поля по процессу в любом месте карточки (на приведённом выше скриншоте – поле «Территория» из контрагента) и управлять ими. Однако подробнее об этом я расскажу в последующих публикациях.

 

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

 

 

На диаграмме наличие описания отмечается знаком * в конце названия элемента.

 

 

В самом названии шага во время выполнения звёздочка не видна, но видна кнопка «Подсказка». При нажатии на эту кнопку пользователь видит текст подсказки.

 

 

Тот же текст виден на детали «Элемент» (см. предыдущие публикации). Подсказка может формироваться динамически в самом процессе.

 

 

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