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

Материал из RunaWFE
Перейти к навигации Перейти к поиску

RunaWFE. Глоссарий терминов


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

Переход

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

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

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

Transition.jpg

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


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

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

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

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

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

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

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

Узел-Действие

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

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

Activity.jpg

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


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

SmallActivity.jpg

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

Узел-Обработчик

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

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

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

ActionNode.jpg

Обозначение Узла-Обработчика.

Ветвление

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

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

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

Decision.jpg

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

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

NewDecision.jpg

Соединение

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

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

Merge.jpg

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

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

Merge02.jpg

Разделение

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

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

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

Fork.jpg

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


Слияние

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

Для пришедшей в узел точки управления поведение узла следующее:

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

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

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

Join.jpg

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

Дискриминатор

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

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

Discrim2.jpg

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


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

Обозначения элементов. – Такие же.

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

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


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

Обозначения элементов. – Такие же.

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

Поведение элемента Разделение в паре такое же, как поведение локального элемента Разделение. Поведение элемента Дискриминатор в паре отличается от поведения локального элемента Дискриминатор:

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


Начало

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

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

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

Begin.jpg

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

Окончание

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

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

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

End.jpg

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

Роль-Дорожка

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

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

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

Swimlane role.jpg

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


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

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

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

Timer.jpg

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


Timer02.jpg

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

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

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

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

TimerNode.jpg

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


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

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

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

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

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

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


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


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


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

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

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

Activity Sub Sync.jpg

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

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

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

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

Activity P.jpg

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

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

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

Activity Sub Async.jpg

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

Activity Sub AsyncP.jpg

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

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

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

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

MultiInstance2.jpg

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

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

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

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

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


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

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

ContrFlowEnd2.jpg

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

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

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

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

InterraptRegion.jpg

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

Сигнал

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

Signal0.jpg

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

Приемник сигнала

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

Signal2.jpg

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

Обработчик

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

ActionHandler.jpg

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


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

ActionHandler2.jpg

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

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

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

- компьютерные системы, основанные на процессном подходе к управлению предприятием. Важной характеристикой этих систем является возможность быстрой разработки и изменения Бизнес-процессов предприятия без обновления специализированного кода, используя лишь графическую среду разработки Бизнес-процессов. Термин 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.jpg


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


Примеры различных возможных поведений точек управления при входе и выходе из Узлов-Действий приведены на рисунке:


TokenAndState2.gif

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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


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

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

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


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

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


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

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


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

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

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


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

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


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


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

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

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

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

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

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

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

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