Термины и определения бизнес-процессного подхода к управлению, используемые в документации

Переход

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

Англоязычный синоним: transition

Сокращенный вариант: —

Transition.png

Обозначение Перехода в графической нотации UML.

Точка Управления

— указатель на активный узел процесса. В выполняющемся Бизнес-процессе одновременно может быть несколько Точек Управления. В соответствии с бизнес логикой процесса Точка Управления может разделиться на несколько Точек Управления в Маршрутном Узле процесса, также Точки Управления могут ждать друг друга в другом Маршрутном Узле и сливаться в одну Точку.

Англоязычный синоним: Control flow

Маршрутный узел

— Узел в графе Бизнес-процесса BPM-системы, соответствует появлению, удалению, разделению, слиянию Точек Управления или выбору перехода. В этих узлах BPM-система, на основании содержащихся в Маршрутных Узлах правил, выбирает следующий узел (узлы), в который будет передано управление.

Англоязычный синоним: RouteNode

Сокращенный вариант: — Вентиль

Действие

— Узел в графе Бизнес-процесса BPM-системы, ассоциированный с каким-либо Действием. В этих узлах BPM-система дает поручение Пользователю на выполнение Действия и ждет ответа (сообщения, что работа выполнена). После ответа Пользователя Точка Управления движется по Переходу к следующему узлу процесса. К Действию может примыкать один входящий и один исходящий Переход. В UML-версии графической нотации обозначается прямоугольником со скругленными краями, в центре которого пишется имя действия. В верхней части прямоугольника должно быть помещено в круглых скобках (в соответствии с UML-нотацией) имя связанной с Действием Роли-Дорожки (определение ниже).

Англоязычный синоним: ActivityNode

Activity.png

Обозначение Действия в графической нотации UML.

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

SmallActivity.png

Обозначение Действия в уменьшенном виде.

Ветвление

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

Англоязычный синоним: DecisionNode

Сокращенный вариант: — Decision

Decision.png

Обозначение Ветвления в графической нотации UML.

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

NewDecision.png

Соединение

Вид маршрутного узла. Должен иметь несколько входящих Переходов и один исходящий Переход. Служит для соединения маршрутов Точек Управления, пришедших в Соединение по разным Переходам. В UML-версии графической нотации обозначается ромбом, так же как и Ветвление.

Англоязычный синоним: MergeNode

Merge.png

Обозначение Соединения в графической нотации UML.

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

Merge02.png

Описании поведения пары элементов Разделение-Слияние

В бизнес-процессе определяется пара элементов: Разделение и соответствующее ему Слияние .

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

Fork.png

Обозначение Разделения в графической нотации UML.

Элемент Слияние должен иметь несколько входящих и один исходящий Переход. Для пришедшей в узел Точки Управления поведение узла следующее:
Проверяется, все ли Точки Управления, вышедшие одновременно с пришедшей Точкой Управления из Разделения пришли в данное Слияние. Если нет, то Точка Управления остается в Слиянии. Если да, то все Точки Управления, вышедшие из соответствующего Разделения, уничтожаются, а «замороженная» в разделении Точка Управления «размораживается» и помещается на исходящий из Слияния Переход.
Слияние обозначается черным прямоугольником, так же, как и элемент Разделение.

Join.png

Обозначение Слияния в графической нотации UML.

Описании поведения пары элементов Разделение-Дискриминатор.

В бизнес-процессе определяется пара элементов: Разделение и соответствующий ему Дискриминатор.

Элемент Разделение должен иметь один входящий и несколько исходящих Переходов. Пришедшая в узел Точка Управления «замораживается» (становится временно недействительной), для каждого исходящего Перехода генерируется новая (дочерняя) Точка Управления. Все сгенерированные Точки Управления далее выполняются параллельно. Пришедшая точка управления будет «разморожена» только когда первая из ее дочерних точек управления придет в узел — Дискриминатор. В случае идущих друг за другом Точек Управления узел «обрабатывает» их в момент прихода Точки Управления в узел независимо друг от друга. В UML-версии графической нотации обозначается черным прямоугольником

Элемент Дискриминатор должен иметь несколько входящих и один исходящий Переход. Для пришедшей в узел Точки Управления поведение узла следующее:
Проверяется, приходила ли уже ранее в данный узел — Дискриминатор какая-то Точка Управления, вышедшая одновременно с данной Точкой Управления из Разделения. Если да, то данная пришедшая Точка Управления уничтожается и больше ничего не делается. Если нет, то данная пришедшая Точка Управления уничтожается, проверяется, есть ли в соответствующем разделении ее «замороженная» «родительская» Точка Управления. Если есть, то она «размораживается» и помещается на исходящий из Дискриминатора Переход.
Дискриминатор обозначается черным прямоугольником, таким же, как и элемент Слияние, но над его правым концом добавляется в квадратных скобках надпись «Discriminator».

Discrim2.png

Рис. Обозначение конструкции «Дискриминатор».

Разделение (альтернативный вариант)

— Вид маршрутного узла. Должен иметь один входящий и несколько исходящих Переходов. Для пришедшей в узел Точки Управления генерируется новая Точка Управления для каждого исходящего Перехода. Сама пришедшая Точка Управления уничтожается Все сгенерированные Точки Управления далее выполняются параллельно. В случае идущих друг за другом Точек Управления «обрабатывает» их в момент прихода Точки Управления в узел независимо друг от друга. В UML-версии графической нотации обозначается черным прямоугольником.

Англоязычный синоним: ForkNode

Сокращенный вариант: — Fork

Fork.png

Обозначение Разделения в графической нотации UML.

Слияние (альтернативный вариант)

— Вид маршрутного узла. Должен иметь несколько входящих и один исходящий Переход. Для каждого входящего перехода пришедшая в Слияние точка управления ставится в очередь на входе данного перехода в Слияние.
Если для всех входящих в Слияние переходов их очереди заполнены хотя бы одной Точкой Управления, то все Точки Управления, находящиеся на первой позиции очереди каждого перехода, уничтожаются, а на выходе из Слияния генерируется одна точка управления. Все остальные Точки Управления, находящиеся в очередях в Слияние, перемещаются на одну позицию вперед.

Слияние в графической нотации обозначается так же, как и конструкция Разделение.

В UML-версии графической нотации обозначается черным прямоугольником.

Англоязычный синоним: JoinNode

Сокращенный вариант: — Join

Join.png

Обозначение Слияния в графической нотации UML.

Дискриминатор (альтернативный вариант)

Вид маршрутного узла. Соответствует WF-паттерну «дискриминатор». В UML-нотации обозначается черным прямоугольником, над верхней частью прямоугольника в квадратных скобках располагается надпись «Discriminator». Черный прямоугольник должен иметь несколько входящих и один исходящий Переход.

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

Discrim2.png

Рис. Обозначение конструкции «Дискриминатор».

Параллельный шлюз

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

В UML-нотации обозначается черным прямоугольником.

Исключающий шлюз

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

В UML-нотации обозначается ромбом.

Начало

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

Англоязычный синоним: InitialNode

Сокращенный вариант: — Start

Begin.png

Обозначение Начала в графической нотации UML.

Окончание

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

Англоязычный синоним: ActivityFinalNode

Сокращенный вариант: — End

End.png

Обозначение Окончания в графической нотации UML.

Роль

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

Англоязычный синоним: Swimlane

Сокращенный вариант: — Swimlane

Swimlane role.png

Возможный вариант обозначения Роли-Дорожки в графической нотации UML

Присоединенный к Действию Таймер

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

Англоязычный синоним: Timer

Timer.png

Обозначение конструкции «Присоединенный к Действию Таймер» в случае времени относительно момента прихода точки управления в Узел-Действие.

Timer02.png

Обозначение конструкции «Присоединенный к Действию Таймер» в случае времени оотносительно значения переменной бизнес-процесса (в данном примере имя переменной — контрольная_дата).

Узел-Ожидание

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

Англоязычный синоним: TimerNode

TimerNode.png

Обозначение конструкции «Узел-Ожидание» в случае времени оотносительно значения переменной бизнес-процесса (в данном примере имя переменной — контрольная_дата, интервал — за 7 дней до контрольной даты).

Замечание о различных вариантах определения шага процесса

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

  • Атомарный шаг – Подпроцесс (Subproc.png) – Композиция (+)
  • Шаг с синхронизацией — Шаг без синхронизации (&)
  • Последовательный шаг — Параллельный шаг (*)

Также в настоящем описании существует такое понятие как Мульти-действие.:

  • Единичный экземпляр шага — Мульти-действие

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

Мульти-действие обозначается специальной иконкой.

То есть данная классификация задает 24 варианта шага процесса. В последующих пунктах будут приведены некоторые типичные варианты шага процесса.

Замечание.Настоящее описание предполагает, что имя шага процесса должно начинаться с глагола в неопределенной форме (неявное повелительное наклонение).

Подпроцесс с синхронизацией

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

Рис. Обозначение шага – последовательного подпроцесса с синхронизацией.

Параллельное действие

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

Англоязычный синоним: Expansion region with only one action

Activity P.png

Рис. Обозначение параллельного атомарного действия без синхронизации.

Подпроцесс без синхронизации

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

Activity Sub Async.png

Рис. Обозначение узла – последовательного подпроцесса без синхронизации.

Activity Sub AsyncP.png

Рис. Обозначение узла – параллельного подпроцесса без синхронизации.

Мульти-действие

Мульти-действие – специальный вид дополнительного узла. Аналогичен Действию, однако в отличие от Действия порождает сразу несколько задач, назначенных разным исполнителям. После того, как все задания Мульти-действия выполнены (если в настройках не указано иное), управление переходит к следующему узлу по исходящему Переходу.

Замечание. Исполнители Мульти-действия определяются значением специальной переменной типа «Список» в момент прихода управления в этот узел.

Англоязычный синоним: MultiTaskState

MultiTaskState.png

Рис. Обозначение конструкции «Мульти-действие».

Мульти-подпроцесс

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

Замечание. Количество экземпляров мульти-подпроцесса определяется значением специальной «присоединенной» переменной в момент прихода управления в это действие.

Англоязычный синоним: MultiInstance

MultiInstance.png

Рис. Обозначение конструкции «Мульти-подпроцесс».

Завершение потока

— Вид маршрутного узла. Соответствует точке завершения исполнения потока управления бизнес-процесса. Точка завершения потока должна иметь один или более входящих Переходов и не должна иметь исходящих Переходов. В UML-версии графической нотации обозначается черным крестиком внутри окружности.

В бизнес-процессе может существовать несколько узлов Завершения потока. Однако этот узел не обязателен в бизнес-процессе, если в бизнес-процессе существует хотя бы одна точка завершения процесса — Окончание.

Завершение потока не останавливает порожденные им подпроцессы.

Англоязычный синоним: FlowFinalNode

Сокращенный вариант: — FlowEnd

ContrFlowEnd2.png

Рис. Обозначение Завершения потока в графической нотации UML

Область с прерыванием

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

Англоязычный синоним: InterruptibleActivityRegion

InterraptRegion.png

Рис. Обозначение конструкции «Область с прерыванием».

Сообщение

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

Англоязычный синоним: Message

Message0.png

Рис. Обозначение конструкции «Сообщение».

Приемник сообщения

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

Англоязычный синоним: Message receiver

Message2.png

Рис. Обозначение конструкции «Приемник сообщения».

Обработчик

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

Англоязычный синоним: ActionHandler

Сокращенный вариант: Handler

ActionHandler.png

Рис. Обозначение Обработчиков.

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

ActionHandler2.png

Рис. Обозначение Перехода и Узла-Действия, содержащего большое количество Обработчиков.

Прочие термины

Системы управления бизнес-процессами

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

  • Workflow
  • DocFlow
  • EAI

как частные реализации BPM-систем в различных парадигмах.

Англоязычный синоним: Business Process Management systems

Сокращенный вариант: СУБП или BPM-системы

Процессный подход к организации управления предприятием

— подход, в соответствии с которым деятельность предприятия представляется в виде множества Бизнес-процессов.

Англоязычный синоним: Process Approach

Workflow-система

— Компьютерная система управления потоками работ. Как правило, WF-системы организуют деятельность людей. Участие в WF-системах автоматизированных систем предприятия носит второстепенный характер. Парадигма WF-системы это — «Поток Действий». В этой парадигме всякую деятельность можно представить в виде набора выполняющихся Бизнес-процессов.

Англоязычный синоним: Workflow system

Сокращенный вариант: WF-система

Основные задачи, которые должна решать BPM-система предприятия:

Задача А. «Эсперанто Менеджмента» — Формирование единого языка описания Бизнес-процессов для менеджеров предприятия. Создания библиотеки Бизнес-процессов предприятия.

Задача Б. «Универсальный Клей» — Быстрая интеграция («склеивание»), в рамках единого процесса, труда сотрудников и компьютерных систем предприятия. Быстрая сборка из разнородных «кирпичиков» связного, качественного процесса.

Англоязычный синоним: Basic Workflow System Purposes

Позиционирование BPM-системы относительно задач интеграции масштаба предприятия.

Современное состояния большинства предприятий характеризуется «лоскутной» автоматизацией. Т.е. большинство информационных систем предприятия работают независимо друг от друга, образуя «суп» приложений. Так как эти системы участвуют в каких-либо Бизнес-процессах предприятия, BPM-системе придется с ними взаимодействовать.

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

BPM-система должна быть центральной частью современных систем масштаба предприятия. Если в корпоративной информационной системе отсутствует WF-компонента, то логика Бизнес-процессов оказывается рассеянной по различным элементам системы – контейнерам, базам данных, отдельным приложениям и т.д. и такие системы будет крайне сложно сопровождать и развивать дальше.

То есть, после внедрения BPM-системы на предприятии большая часть его деятельности может быть представлена в виде «спагетти», где каждая «макаронина» — это отдельный Бизнес-процесс, имеющий начало и завершение.

Англоязычный синоним: Workflow system positioning relatively EAI problem

Сокращенный вариант: —

DocFlow система

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

DF-системы являются наследниками бумажного документооборота. Отсюда следуют их естественные ограничения: с документом можно совершить ограниченный набор действий: одобрить/отказать, визировать, удалить, внести правку и т.п. Обычно системы документооборота дополняются системами хранения образов бумажных документов и системами версионного контроля. Основным преимуществом систем документооборота является возможность быстрого внедрения на предприятии, если там уже на хорошем уровне налажен документооборот.

У DF-систем, также как и у WF-систем, существуют схемы, представляющие собой графы, состоящие из узлов, соединенных возможными Переходами. Однако по этим графам перемещаются не точки управления, а «корзины» документов. В DF-системах, как правило, данные содержатся внутри документов, которые непосредственно перемещаются по схеме документооборота.

В настоящее время WF и DF системы – системы разных типов, однако, постепенно системы документооборота приближаются по функциональности к WF-системам.

Англоязычный синоним: DocFlow system

Сокращенный вариант: DF-система

EAI система

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

Англоязычный синоним: Enterprise Application Integration system

Сокращенный вариант: —

Бизнес-процесс

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

Англоязычный синоним: Business Process

Сокращенный вариант: —

Бизнес-Цель

— То, что должно быть достигнуто в результате выполнения Бизнес-процесса. Должны существовать объективные критерии достижения Бизнес-Цели.

Англоязычный синоним: Business Goal

Сокращенный вариант: —

Действие (второе значение)

— Соответствует действию, выполняемому Пользователем по заданию BPM-системы. В графе Бизнес-процесса BPM-системы с Действиями ассоциированы некоторые узлы графа. В этих узлах BPM-система дает поручение Исполнителю на выполнение Действия и ждет ответа (сообщения, что работа выполнена). После ответа Исполнителя Точка Управления движется по Переходу к следующему узлу процесса.

Англоязычный синоним: Activity

Сокращенный вариант: —

Задание

— Соответствует паре – (Действие, Пользователь). Термин, как правило, применяется при описаниях «с точки зрения» Пользователя.

Англоязычный синоним: WorkItem

Сокращенный вариант: — Task

Пользователь

— Сотрудник компании (возможно, внешней компании) или Бот

Англоязычный синоним: Actor

Сокращенный вариант: —

Функция над Исполнителями

— Функция, возможно имеющая формальные параметры (в качестве фактических параметров этой функции должны будут выступать Исполнители и переменные бизнес-процесса, в частности Роли-Дорожки), возвращающая множество Пользователей

Англоязычный синоним: function over a firm structure

Сокращенный вариант: —

Группа Пользователей

— Множество, каждый элемент которого является либо Пользователем, либо Группой Пользователей (это рекурсивное определение)

Англоязычный синоним: Group of Actors

Сокращенный вариант: —

Исполнитель

— Пользователь или Группа Пользователей

Англоязычный синоним: Executor

Сокращенный вариант:

Бот

— специальное приложение, обеспечивающее взаимодействие BPM-системы и сторонних приложений в процессе исполнения порученных ему Действий. Может быть двух видов:

  • Пуш-бот
  • Пул-бот

Англоязычный синоним: Workflow bot

Сокращенный вариант:

Спецификация Бота

— упорядоченные списки входящих и исходящих формальных параметров бота

Англоязычный синоним: Workflow bot specification

Сокращенный вариант:

Пуш-бот

Характеристики:

  • Бот сам «проявляет активность»
  • Бот может быть самостоятельно разработан третьей стороной без участия основной команды разработчиков.
  • Бот может быть «локально» установлен на отдельном компьютере
  • Бот может быть простым образом установлен в систему

Англоязычный синоним: “Push” workflow bot

Сокращенный вариант: —

Пул-бот

Характеристики:

  • Бот не проявляет «самостоятельной» активности – только отвечает на вызовы.
  • Бот «немедленно» реагирует на события
  • Англоязычный синоним: “Pull” workflow bot
  • Сокращенный вариант: —

Бот-станция (Сервер для Пуш-бота).

Серверное приложение, умеющее работать с BPM-системой. Служит для связи с Пуш-ботом.

Англоязычный синоним: Bot station

Сокращенный вариант: —

Экземпляр бизнес-процесса

— Конкретный процесс, сформированный на основе определения Бизнес-процесса

Англоязычный синоним: Business process instance

Сокращенный вариант: instance

Список заданий

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

Англоязычный синоним: work list

Сокращенный вариант:

Предельный срок

Предельный срок выполнения работы.

Англоязычный синоним: deadline

Сокращенный вариант:

Ядро workflow системы

Серверная часть системы. Хранит определения Бизнес-процессов и выполняющиеся Экземпляры Бизнес-процессов.

Англоязычный синоним: workflow engine

Сокращенный вариант: WF-engine

Графический редактор бизнес –процессов

Компонент BPM-системы. Позволяет создавать и редактировать определения Бизнес-процессов.

Англоязычный синоним: Process editor

Сокращенный вариант: —

Симуляция бизнес процесса

Процесс фиктивного проигрывания Бизнес-процесса с модельными данными на одном рабочем месте за все Роли. Выполняется менеджером с целью отладки Бизнес-процесса.

Англоязычный синоним: Business process simulation

Сокращенный вариант: BP simulation

Конструктор «тонких» графических форм

Компонент BPM-системы. Позволяет менеджеру создавать «тонкие» формы из предопределенного набора графических компонентов.

Англоязычный синоним: Thin forms designer

Сокращенный вариант: —

Клиентское приложение для пользователей

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

Англоязычный синоним: Actor Thin Client

Сокращенный вариант: —

Проигрыватель форм

Компонент BPM-системы. «Проигрывает» формы, которые передает ему Бизнес-процесс.

Англоязычный синоним: Forms Player

Сокращенный вариант: —

Роль

Способ группировки Пользователей. Роль ставится в соответствие Действию, любой Пользователь, входящий в роль, может выполнить соответствующее Действие.

Англоязычный синоним: Role

Сокращенный вариант:

Определение исполнимого бизнес-процесса:

Исполнимый бизнес-процесс — совокупность четырех Перспектив (точек зрения или слоев/уровней рассмотрения):

  • Перспектива потока управления
  • Перспектива Данных
  • Перспектива Ресурсов
  • Перспектива Операций

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

Перспектива потока управления

Перспектива потока управления представляет собой схему бизнес-процесса. Схема бизнес-процесса состоит из направленного графа и, возможно, дополнительных конструкций. Направленный граф — множество узлов, соединенных между собой Переходами. Узлы Бизнес-процесса могут быть трех типов: Шаги процесса, Маршрутные узлы (или Вентили) и комбинированные узлы, представляющие собой слияние шага процесса с одним или несколькими маршрутными узлами. По Переходам перемещается Точка Управления. В маршрутных узлах происходит выбор направления (направлений) дальнейшего движения точек управления. Шаги процессов являются узлами-действиями или дополнительными узлами.

Для изображения элементов графа процесса применяются различные графические нотации (наборы графических элементов, соответствующих определениям узлов, Переходов, а также других атрибутов процесса). Наиболее распространены BPMN и UML — нотации. Мы считаем, что для российских пользователей UML нотация обладает рядом преимуществ, поэтому изображения графических элементов в данном документа в первую очередь даны в UML нотации.

Англоязычный синоним: Control Flow perspective

Сокращенный вариант: CF-perspective

Замечание о поведении точек управления

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

Пример такой ситуации:

Primer2.png

Перспектива Данных

— соответствует набору переменных Бизнес-процесса. Переменные Бизнес-процесса могут являться входящими и исходящими параметрами при взаимодействии BPM-системы с информационными системами предприятия.

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

Англоязычный синоним: Data perspective

Сокращенный вариант: —

Мы предполагаем, что все переменные бизнес-процесса являются глобальными (однако мульти-действие на время своего выполнения может порождать копии некоторых переменных – см. ниже). Доступ «извне» к переменным бизнес-процессов возможен только через ботов или пользователей.

Расширенная версия перспективы данных

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

Перспектива Ресурсов

Перспективе Ресурсов Бизнес-процесса соответствует список Пользователей, которые могут выполнить Действия Бизнес-процесса. Это Перспектива плотно связанна с организационной моделью и моделью информационных систем предприятия.

В этот уровень надо также включить правила определения Пользователей, которые могут выполнить Действие. Эти правила бывают различных видов. Например, Бизнес-процесс может послать Действие на выполнение всем членам Группы Пользователей, а выполнять это Действие будет первый Пользователь, отметивший Действие в своем списке (у остальных членов группы это Действие «пропадет»).
Некоторые системы позволяют задать «взвешенные» правила распределения Действий по исполнителям. В этом случае работа между членами группы распределяется в зависимости от их веса, задаваемого в организационном компоненте BPM-системы и количества Действий уже принятых пользователями. Например, если группа содержит трех сотрудников с весами 20%, 30% и 50% то при прохождении Действий первому сотруднику будет направлено на выполнение 20% от их общего числа, а второму и третьему 30 и 50% соответственно.

Англоязычный синоним: Resource perspective

Сокращенный вариант: —

Расширенная версия перспективы ресурсов

В бизнес-процессе определен набор специальных локальных переменных Ролей-Дорожек (см. Глоссарий), с каждой Ролью-Дорожкой связан специальный оператор — Инициализатор.

Каждому Действию бизнес-процесса поставлена в соответствие одна из Ролей-Дорожек.

Инициализация Роли-Дорожки состоит в том, что Инициализатор ставит ей в соответствие множество Пользователей.

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

Алгоритм работы Инициализатора определяется Формулой инициализации над Исполнителями, переменными бизнес-процесса и Функциями над Исполнителями.

В простейшем случае Формула инициализации представляет собой оператор присваивания, в левой части которого находится имя Роли-Дорожки, а в правой Исполнитель, переменная бизнес-процесса или Функция над Исполнителями с набором фактических параметров. Следующим расширением Формул инициализации будет добавление операций над множествами (объединение, пересечение, разность …)

С каждым узлом-Действием в графе бизнес-процесса связаны следующие дополнительные параметры, относящиеся к перспективе ресурсов:

  • Тип заданий данного Действия
  • Роль-Дорожка
  • Признак реинициализации

Возможные значения параметров:

  • Тип заданий
    • Персональные задания
    • Задание группе
  • Роль-Дорожка
  • Признак реинициализации
    • Да
    • Нет (значение по умолчанию)

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

  • Обязательное задание
  • Предложенное задание

С каждым заданием связан статус задания. Статусы могут быть следующими:

Характеристика — обязательные задания Характеристика — предложенные задания
Направлено к исполнению Предложено к исполнению
Взято в исполнение
Исполнено
Отменено
Отказано

Значение характеристики обязательности заданий в момент прихода управления в Действие.

Тип задания Количество Пользователей, связанных с данной Ролью-Дорожкой данного Действия
Единственный Пользователь Более одного Пользователя
Персональное задание Обязательное задание данному Пользователю Обязательные задания всем Пользователям, входящим в Роль-Дорожку
Групповое задание Обязательное задание данному Пользователю Предложенные задания всем Пользователям, входящим в Роль-Дорожку. Однако непосредственно перед выполнением задания должна быть произведено сужение Роли-Дорожки – во множестве Пользователей Роли-Дорожки останется только Пользователь, первым взявший задание на выполнение. Далее задание станет обязательным заданием этому Пользователю

Состояния Пользователей.

У Пользователя может быть одно из следующих состояний:

  • Присутствует
  • Отсутствует

Состояние «Отсутствует» делится на подсостояния по следующему классификатору:

  • Неожиданное — Ожидаемое отсутствие
  • Отсутствие «на время» — отсутствие «навсегда»

Виды отсутствия:

Неожиданное отсутствие Ожидаемое отсутствие

На время Болезнь Командировка
Неизвестная причина Отпуск
Ч.П.
Навсегда Неожиданное увольнение Увольнение
Смерть

Правила назначения заместителя

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

Заместитель назначается при помощи набора правил замещения Пользователя. Набор является упорядоченным списком правил.

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

  • Замещаемый Пользователь (Пользователь)
  • Заместитель (Пользователь, Функция над оргструктурой, возвращающая Пользователя)
  • Применимо ли правило (Функция, которая может обращаться к заданию, параметрам бизнес-процесса и внешним системам)

Пример правила назначения заместителя:

  • Иванов
  • Петров
  • (Роль = «инспектораКадровойСлужбы») & (Бизнес-процесс= «больничный»)

Порядок применения правил замещения Пользователя.

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

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

Изменение значения Роли, связанное с назначением заместителя.

Когда пользователь получает статус «отсутствует (на время)», никакие значения Ролей-Дорожек не изменяются. Задания этого пользователя появляются в соответствующих списках заданий заместителя. Однако, если заместитель выполнит какое-либо задание замещаемого пользователя, то непосредственно перед отражением этого события в системе соответствующей Роли будет присвоено значение, соответствующее заместителю, а сразу после отражения этого события в системе этой Роли-Дорожке будет присвоено прежнее значение.

Когда пользователь получает статус «отсутствует (навсегда)», значения его Ролей-Дорожек во всех незавершенных процессах изменяются в соответствии с правилами назначения заместителей.

Графическая нотация для перспективы ресурсов.

В соответствии с UML нотацией Роль-Дорожка, поставленная в соответствие Действию, может указываться на диаграмме бизнес-процесса (в верхней части Действия, в круглых скобках).

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

Перспектива Операций

Перспективе Операций Бизнес-процесса соответствует список элементарных действий, совершаемых Исполнителями в рамках узла-действия.

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

Англоязычный синоним: Operational perspective

Сокращенный вариант: —