Подпроцессы – Глава 10. Процесс. Подпроцесс

1 Май 2020   | Разное

Содержание

Глава 10. Процесс. Подпроцесс

<<предыдущая содержание следующая>>

10.2.5 Подпроцесс

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

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

Далее будут рассмотрены различные типы Подпроцессов.

Встроенный Подпроцесс (Embedded Sub-Process (Sub-Process))

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

  • Подпроцесс
    представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен одинарной тонкой линией.
    • Текст, цвет, размер, а также линии, используемые для изображения Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм». Однако следует учитывать следующее исключение:
      • Одинарная жирная линия в изображении границ Подпроцесса ДОЛЖНА означать использование данного графического элемента в качестве Действия Вызов (Подпроцесс).
      • Пунктирная линия в изображении границ Подпроцесса ДОЛЖНА означать использование данного графического элемента в качестве Событийного Подпроцесса.
      • Двойная линия в изображении границ
        Подпроцесса         ДОЛЖНА означать использование данного графического элемента в качестве Подпроцесса Транзакции.

Подпроцесс может быть свернутым (Collapsed Sub-Process), при этом его детали скрыты (см. фигуру 10.25). Подпроцесс также может быть развернутым (Expanded Sub-Process), при этом его детали отображаются внутри Процесса, в котором данный Подпроцесс содержится (см. фигуру 10.26). В случае, если Подпроцесс является свернутым, то используется маркер, позволяющий отличить Подпроцесс от Задачи.

  • Маркер Подпроцесса ДОЛЖЕН изображаться в виде небольшого квадрата, расположенного в центре нижней части графического элемента и заключающего в себе знак «+».

Фигура 10.25 – Графический элемент Свернутый Подпроцесс

Фигура 10.26 – Графический элемент Развернутый Подпроцесс

Подпроцессы используются для создания контекста для управления исключением, применяемым к группе Действий. Подобным образом выполняется управление Компенсацией.

Развернутый Подпроцесс используется для более компактного отображения группы параллельных Действий с использованием минимума деталей. Как показано на фигуре 10.27, Действия «С» и «D» заключены в безымянном развернутом

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

Фигура 10.27 – Развернутый Подпроцесс, выступающий в роли «параллельного блока».

BPMN различает пять типов стандартных маркеров Свернутого Подпроцесса. Маркер Подпроцесса, изображенный на фигуре 10.25, может сочетаться с оставшимися четырьмя маркерами: Маркером Цикла (Loop Marker), Многоэкземплярным Маркером (Multiple-Instance Marker), Маркером Компенсации (Compensation Marker) и Маркером Ad Hoc (Ad-Hoc Marker). Свернутый Подпроцесс может содержать от одного до трех вышеуказанных Маркеров. Комбинации Маркеров могут быть любыми, кроме сочетания Маркеров Цикличности и Многоэкземплярного, — эти Маркеры не могут изображаться одновременно (см. фигуру 10.28).

  • Маркер Цикла ДОЛЖЕН БЫТЬ выполнен в виде небольшой стрелки, острие которой загнуто в направлении, противоположном направлению самой стрелки.
    • Маркер Цикла МОЖЕТ сочетаться с любым другим Маркером Подпроцесса, кроме Многоэкземплярного
  • Многоэкземплярный Маркер ДОЛЖЕН БЫТЬ выполнен в виде трех параллельных вертикальных линий.
    • Многоэкземплярный Маркер МОЖЕТ сочетаться с любым другим Маркером Подпроцесса, кроме Маркера Цикла.
  • Маркер Ad Hoc ДОЛЖЕН БЫТЬ выполнен в виде тильды.
    • Маркер Ad Hoc МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.
  • Маркер Компенсации ДОЛЖЕН БЫТЬ выполнен в виде двух треугольников, повернутых влево (как кнопка перемотки назад на проигрывателе).
    • Маркер Компенсации МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.
  • Все вышеописанные Маркеры при совместном отображении ДОЛЖНЫ БЫТЬ сгруппированы и располагаться в центре нижней части графического элемента Подпроцесса.

Цикл Многоэкземплярность Компенсация Ad-Hoc Компенсация + Ad—Hoc

Фигура 10.28 – Маркеры Свернутого Подпроцесса

Свернутый Подпроцесс в BPMN 2.0 относится к Встроенному Подпроцессу, описанному в BPMN 1.2. Повторно используемый Подпроцесс в BPMN

1.2 относится к Действию типа Вызов, описанному в BPMN2.0. Фигура 10.29 представляет собой диаграмму классов Подпроцесса.

Фигура 10.29 — Диаграмма классов элемента SubProcess

Элемент SubProcess наследует атрибуты и ассоциации элементов Activity (см. таблицу 10.3) и элемента FlowElementContainer (см. таблицу 8.45). Таблица 10.20 содержит информацию о дополнительных атрибутах элемента SubProcess.

Таблица 10.20 – Атрибуты элемента SubProcess

Название атрибута

Описание/использование

triggeredByEvent: boolean = false

Данный атрибут указывает на то, что данный Подпроцесс работает с Событиями.

· Значение «false» указывает на то, что Подпроцесс является стандартным.

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

triggeredByEvent: boolean = false

Данный атрибут обусловливает наличие списка Артефактов, хранящихся в Подпроцессе.

ReusableSub—Process (CallActivity) Повторно используемый Подпроцесс (Вызов)

Повторно используемый Подпроцесс, описанный в BPMN 1.2, относится к Действию типа Вызов, используемому для вызова предопределенного Подпроцесса.

Событийный Подпроцесс (Event Sub-Process)

Событийным Подпроцессом называется специфический Подпроцесс, используемый внутри Процесса (Подпроцесса). Такой Подпроцесс имеет атрибут triggeredByEvent с установленным значением «true».

Такой

Подпроцесс не является частью Стандартного потока операций, включенного в родительский Процесс, и не имеет входящих или исходящих Потоков операций.

  • Событийный Подпроцесс НЕ ДОЛЖЕН иметь входящих или исходящих Потоков операций.

Событийный Подпроцесс МОЖЕТ появляться (один раз или многократно) или НЕ появляться в ходе выполнения родительского Процесса. Отличие такого Подпроцесса от стандартного состоит в том, что стандартный Подпроцесс в качестве триггера использует Поток операций, а Событийный Подпроцесс — Стартовое событие. Всякий раз, когда какое-то Стартовое событие запускается во время выполнения родительского

Процесса, запускается и Событийный Подпроцесс.

  • Стартовое событие Событийного Подпроцесса ДОЛЖНО иметь определенный триггер.
    • Стартовое событие (EventDefinition) ДОЛЖНО БЫТЬ одного из следующих типов: Сообщение, Ошибка, Эскалация, Компенсация, Условие, Сигнал, Множественный.
  • Событийный Подпроцесс ДОЛЖЕН содержать одно или более Стартовое событие.

Такой Подпроцесс изображается в виде прямоугольника с закругленным углами (установленное в BPMN отображение графического элемента Подпроцесс).

  • Событийный Подпроцесс представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен одинарной тонкой пунктирной линией (см. фигуры 10.30 и 10.31).
    • Текст, цвет, размер, а также линии, используемые для изображения данного Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм». Однако следует учитывать следующее исключение:
      • Если Событийный Подпроцесс является свернутым, то Стартовое событие в таком Подпроцессе будет являться маркером и отображаться в левом верхнем углу фигуры Подпроцесса (см. фигуру 10.30).

Фигура 10.30 – Графический элемент Свернутый Событийный Подпроцесс

Фигура 10.31 – Графический элемент Развернутый Событийный Подпроцесс

Запуск Событийного Подпроцесса может привести к следующим последствиям в родительском Процессе:

  1. Родительский Процесс прерывается.
  2. Родительский Процесс продолжает выполняться (не прерывается).

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

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

Фигура 10.32 –Событийные Подпроцессы внутри родительского Подпроцесса

Транзакция (Transaction)

Транзакцией называется специфический тип Подпроцесса, который демонстрирует определенное поведение, контролируемое посредством протокола транзакции (например, WS-Transaction). Граница графического элемента Транзакция выполнена двойной линией (см. фигуру 10.33).

  • Транзакция представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен двойной тонкой линией.
    • Текст, цвет, размер, а также линии, используемые для изображения данного Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм».

Фигура 10.33 –Подпроцесс Транзакция

Фигура 10.34 – Свернутый Подпроцесс Транзакция

Элемент TransactionSub-Process наследует атрибуты и ассоциации элемента Activity (см. таблицу 10.3) за счет взаимосвязи с Подпроцессом. Таблица 10.21 содержит информацию о дополнительных атрибутах и ассоциациях элемента TransactionSub-Process.

Таблица 10.21 – Атрибуты и ассоциации элемента TransactionSub-Process

Название атрибута

Описание/использование

method: Transaction- Method

Данный атрибут определяет метод, используемый для совершения Транзакции или её отмены. Для выполняемых процессов данный атрибут ДОЛЖЕН содержать особый URL, например, http://schemas.xmlsoap.org/ws/2004/10/wsat for WS-AtomicTransaction, orhttp://docs.oasis-open.org/ws-tx/wsba/2006/ 06/AtomicOutcome для WS-BusinessActivity. Для сохранения совместимости с BPMN 1.1 данный атрибут также может иметь значения «##compensate», «##store» и «##image».

Использование Транзакции может привести к следующим результатам:

  1. Удачное завершение. Отображается в виде Стандартного потока операций, отходящего от Транзакции.
  2. Неудачное завершение (с использованием События Отмена). При отказе от выполнения Транзакции Действия, находящиеся внутри данной Транзакции, подвергнуться действиям отмены: например, будет выполнена компенсация определенных Действий, или произойдет возврат к Процессу (для получения более подробной информации о компенсации смотрите соответствующий раздел документа). Обратите внимание, что никакой другой механизм остановки Транзакции (например, использование Событий Ошибка и Таймер или каких-либо Действий, не предусмотренных Транзакцией) не повлечет за собой компенсацию. Промежуточное событие Отмена, соединенное с границей Действия, оказывает влияние на направление хода Процесса после того, как произошел возврат и была выполнена компенсация. Это Событие может быть использовано только в том случае, если оно соединено с границей Подпроцесса Транзакции. Оно не может быть использовано в рамках Стандартного потока операций или не прикрепляется к Подпроцессу, не являющемуся Транзакцией. Существует два механизма, способных сигнализировать об отмене Транзакции:
    • Поток операций Транзакции достигает Промежуточного события Отмена. Это Событие используется только для такого типа Подпроцессов.
    • Сообщение об отмене может быть получено посредством протокола транзакции, поддерживающего выполнение данной Транзакции.
  3. Риск (Опасность). Появление Риска означает, что какое-то действие в Транзакции выполняется крайне неверно, и это ведет к тому, что стали невозможны ни удачное завершение, ни отмена. Риски отображаются посредством Промежуточного события Ошибка. При появлении Риска выполнение текущего Действия прекращается без возможности компенсации, а Поток операций возобновляется от Промежуточного события Ошибка.

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

Спонтанный Подпроцесс (Ad-Hoc Sub-Process)

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

Графический элемент Спонтанный Подпроцесс содержит маркер, выполненный в виде знака тильды и располагающийся в центре нижней части фигуры Подпроцесса (см фигуру 10.35 и 10.36).

  • Маркер Спонтанного Подпроцесса ДОЛЖЕН БЫТЬ выполнен в виде тильды.
    • Маркер Ad Hoc МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.

Фигура 10.35 – Графический элемент Свернутый Спонтанный Подпроцесс

Фигура 10.36 – Графический элемент Развернутый Спонтанный Подпроцесс

Элемент Ad-HocSub-Process наследует атрибуты и ассоциации элемента Activity (см. таблицу 10.3) за счет взаимосвязи с Подпроцессом. Таблица 10.22 содержит информацию о дополнительных ассоциациях элемента Ad-HocSub-Process.

Таблица 10.22 – Ассоциации элемента Ad-HocSub-Process

Название атрибута

Описание/использование

completionCondition: Expression

Данный атрибут определяет условия, при которых завершается Процесс. Значение «true» указывает на то, что Процесс будет завершен.

ordering: AdHocOrdering = Parallel { Parallel | Sequential }

Данный атрибут указывает на то, будут ли Действия, включенные в Процесс, выполняться параллельно или НЕОБХОДИМО последовательное их выполнение. Значением по умолчанию является «parallel». Значение «sequential» ограничивает одновременное выполнение нескольких Действий. В данном случае в определенный период времени может быть выполнено лишь одно Действие. Если выбрано значение «parallel», то одновременно может выполняться любое количество Действий, от нуля и более.

cancelRemaining- Instances: boolean = true

Данный атрибут используется только в том случае, если для вышеописанного атрибута ordering установлено значение «parallel». Указывает на то, будут ли отменены запущенные экземпляры Действий, если значение атрибута completionCondition становится «true».

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

Примерами Процессов, входящих в состав Спонтанного Подпроцесса, являются разработка кода (на низком уровне), поддержка клиентов, а также написание главы книги. Рассмотрим, к примеру, написание главы для книги. Мы видим, что данный Процесс включает следующие Действия: поиск темы, составление текста, редактирование текста, создание дизайна, графическое оформление текста, оформление ссылок и т.д. (см. фигуру 10.37). В таком Процессе МОЖЕТ наблюдаться определенная зависимость Задач друг от друга, например, редактирование текста не может происходить раньше его написания. Однако такая корреляция между экземплярами Задачам по написанию и редактированию текста не обязательна. Редактирование может возникать нерегулярно и зависит от текста, полученного в результате выполнения нескольких экземпляров Задачи по написанию текста.

Фигура 10.37 – Спонтанный Подпроцесс написания главы для книги

Хотя в Спонтанном Подпроцессе структура не определена, в его детали все же может быть добавлена информация о последовательности Действий или корреляции данных. К примеру, можно расширить вышеописанный Спонтанный Подпроцесс написания главы для книги путем добавления в него Объектов данных, Ассоциаций или Потоков операций (см. фигуру 10.38).

Однако использование в Спонтанном Подпроцессе элементов потока должно осуществляться со следующими ограничениями, не имеющими отношения к использованию элементов в Подпроцессах других типов:

  • В список элементов BPMN, которые ДОЛЖНЫ использоваться в Спонтанном Подпроцессе, входит Действие.
  • В список элементов BPMN, которые МОГУТ использоваться в Спонтанном Подпроцессе, входят: Объект данных, Поток операций, Ассоциация, Ассоциация данных, Группа, Поток сообщений (может являться как целью, так и результатом), Шлюз, Промежуточное событие.
  • В список элементов BPMN, которые НЕ ДОЛЖНЫ использоваться в Спонтанном Подпроцессе, входят: Стартовое событие, Конечное событие, Переговоры (графически), Соединители переговоров (графически), Действия Хореографии.

Фигура 10.38 – Спонтанный Подпроцесс написания главы для книги с отображением последовательности Действий и зависимых данных

Объект данных, предоставленный для Задач на входе, является дополнительным ограничением для выполнения этих Задач. В данном случае Исполнители, хотя и решают, когда будут выполнены Задачи, уже ограничены в действиях тем, что не могут начать выполнение Задачи без соответствующих данных. Наличие Потока операций между Задачами (например, между разработкой дизайна и оформлением текста в соответствии с дизайном) устанавливает зависимость, согласно которой вторая Задача ДОЛЖНА быть выполнена после выполнения первой. Это не означает, что вторая Задача должна выполняться незамедлительно, но лишь то, что она ДОЛЖНА выполняться после того, как будет завершена первая Задача.

Проблемой для BPM стало отслеживание статуса Спонтанного Подпроцесса. Как правило, Процессы такого типа контролируются при помощи приложений для групповой работы (например, e-mail). BPMN позволяет моделировать Процессы, необязательные для выполнения, хотя определенные механизмы для выполнения процессов, способные отслеживать Спонтанные Подпроцессы, существуют. Исходя из этого, Спонтанный Подпроцесс будет завершен при определенных условиях, которые указываются посредством установки значения для атрибута completionCondition, определяющего, в свою очередь, атрибуты Процесса, корректируемые Действием данного Процесса.

<<предыдущая содержание следующая>>

Данные материалы предназначены исключительно для ознакомления в личных целях.Любое воспроизведение, копирование, а так же коммерческое и некоммерческое использование материалов должно согласовываться с авторами материалов ([email protected]). Допускается использование материалов сайта без уведомления авторов, но с явным указанием источника.

www.elma-bpm.ru

подпроцесс — Викисловарь

Содержание

  • 1 Русский
    • 1.1 Морфологические и синтаксические свойства
    • 1.2 Произношение
    • 1.3 Семантические свойства
      • 1.3.1 Значение
      • 1.3.2 Синонимы
      • 1.3.3 Антонимы
      • 1.3.4 Гиперонимы
      • 1.3.5 Гипонимы
    • 1.4 Родственные слова
    • 1.5 Этимология
    • 1.6 Фразеологизмы и устойчивые сочетания
    • 1.7 Перевод
    • 1.8 Библиография
В Викиданных есть лексема подпроцесс (L147007).

Морфологические и синтаксические свойства[править]

падежед. ч.мн. ч.
Им.подпроце́ссподпроце́ссы
Р.подпроце́ссаподпроце́ссов
Д.подпроце́ссуподпроце́ссам
В.подпроце́ссподпроце́ссы
Тв.подпроце́ссомподпроце́ссами
Пр.подпроце́ссеподпроце́ссах

под-про-це́сс

Существительное, неодушевлённое, мужской род, 2-е склонение (тип склонения 1a по классификации А. А. Зализняка).

Корень: —.

Произношение[править]

  • МФА: [pətprɐˈt͡sɛs]

Семантические свойства[править]

Значение[править]
  1. процесс, являющийся частью другого процесса ◆ Отсутствует пример употребления (см. рекомендации).
Синонимы[править]
Антонимы[править]
Гиперонимы[править]
  1. процесс
Гипонимы[править]

Родственные слова[править]

Ближайшее родство

Этимология[править]

Происходит от ??

Фразеологизмы и устойчивые сочетания[править]

Перевод[править]

Список переводов

Библиография[править]

Interrobang.svg Для улучшения этой статьи желательно:
  • Добавить описание морфемного состава с помощью {{морфо-ru}}
  • Добавить пример словоупотребления для значения с помощью {{пример}}
  • Добавить синонимы в секцию «Семантические свойства»
  • Добавить сведения об этимологии в секцию «Этимология»
  • Добавить хотя бы один перевод в секцию «Перевод»

ru.wiktionary.org

подпроцесс — это… Что такое подпроцесс?

  • подпроцесс — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN subrun …   Справочник технического переводчика

  • КВАРК-ГЛЮОННЫЙ ПОДПРОЦЕСС — в квантовой хромодинамике процесс взаимодействия кварков и глюонов на малых расстояниях, определяющий сечение жёстких процессов с участием адронов. Напр., в процессе рождения в адрон адронном соударении пары мюонов с большой относит. энергией К.… …   Физическая энциклопедия

  • BPMN — (англ. Business Process Model and Notation, нотация и модель бизнес процессов)   система условных обозначений (нотация) для моделирования бизнес процессов. Разработана Business Process Management Initiative (BPMI) и поддерживается… …   Википедия

  • ГЛЮОНЫ — (от англ. glue клей), гипотетич. электрически нейтр. ч цы, со спином 1 и нулевой массой покоя, являющиеся переносчиками сильного вз ствия между кварками. В совр. теории сильного вз ствия квантовой хромодинамике предполагается существование восьми …   Физическая энциклопедия

  • ПАРТОНЫ — (от лат. pars, род. падеж partis часть), составляющие адронов, проявляющиеся в процессах с большой передачей четырёхмерного импульса, в частности в глубоко неупругих процессах. В модели П. считается, что адрон участвует в реакциях лишь нек рой… …   Физическая энциклопедия

  • Бизнес-моделирование — (деловое моделирование)   деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т. д.) …   Википедия

  • Бизнес моделирование — деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный подпроцесс в процессе… …   Википедия

  • Моделирование бизнес-процессов — Бизнес моделирование деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный… …   Википедия

  • Моделирование бизнеса — Бизнес моделирование деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный… …   Википедия

  • ИНТЕГРАЦИЯ — (Integration) процесс, с помощью которого части соединяются в целое; на личностном уровне состояние организма, когда все составляющие элементы индивида, его черты или качества действуют согласованно как единое целое.Юнг использовал этот термин… …   Словарь по аналитической психологии

  • управление мощностями бизнеса — (ITIL Continual Service Improvement) (ITIL Service Design) В контексте ITSM, управление мощностями бизнеса – это подпроцесс управления мощностями, отвечающий за понимание будущих потребностей бизнеса для использования в плане мощностей. См …   Справочник технического переводчика

    • normative_ru_en.academic.ru

    Декомпозиция бизнес процессов и характеристики

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

    Итак, процесс можно разбить на более мелкие части:

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

    Операция. Это самое простое действие в процессе. “Простое” означает, что его не надо детализировать. Если процесс не имеет вложенных подпроцессов, то его механизм реализации как раз и представляет собой цепочку операций. Когда мы готовим посуду для приготовления обеда, то выполняем простые операции: достать кастрюлю, налить в нее воду, поставить на плиту и так далее. Нет смысла подробно объяснять, что значит «налить воду в кастрюлю», а значит, это операция.

     

    Декомпозиция бизнес процессовБизнес процесс, подпроцессы и операции

    Насколько необходимо детализировать процессы?

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

    Группировка операций и подпроцессов.

    Иногда необходимо объединить некоторые операции или подпроцессы – чтобы ими было легче оперировать. К примеру, можно выделить:

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

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

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

    Характеристики бизнес процесса.

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

    1. Результативность – достигает процесс необходимых результатов или нет. Если в результате процесса «Приготовление пирога» получился яблочный пирог, то процесс результативен.
    2. Эффективность – сколько ресурсов затрачивает процесс на получение результата. Если вы знаете, что на приготовление пирога должно уйти 0,5 кг яблок, а было потрачено 2 кг, то процесс неэффективен.
    3. Определенность – если процесс описан в каком-то документе, и то, как он выполняет в действительности, соответствует тому, что написано, значит, процесс определен. Если пирог был приготовлен полностью по рецепту, все ок.
    4. Повторяемость – важнейшая характеристика! Она показывает, может ли процесс получать одинаковые результаты из раза в раз. Если повар постоянно выдает разные яблочные пироги, что-то не так с процессом. Или с поваром.:)
    5. Адаптируемость – характеристика гибкости бизнес процесса, т. е. способности меняться в зависимости от условий. Можно ли быстро заменить яблоки на груши? Можно. Значит, процесс адаптируем.
    6. Длительность – время, которое необходимо для выполнения процесса. Иными словами, промежуток времени между началом процесса и его завершением.
    7. Стоимость – это совокупность всех затрат выполнения процесса 1 раз. Для этого необходимо подсчитать, сколько продуктов мы затратили на приготовление пирога, сколько стоит время повара, который его готовил, а также сколько стоит использование инструментов и посуды.

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

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

    Вернуться на Главную?

    rzbpm.ru

    Проектирование модели бизнес-процессов | Открытые системы. СУБД

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

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

    Какие могут быть критерии декомпозиции сквозного процесса на подпроцессы и как описать механизм связывания подпроцессов в цепочку? Ответы на эти вопросы помогут аналитику правильно проектировать архитектуру процесса, сделав его работу менее субъективной, превратив ее в инженерную деятельность.

    Текущее состояние

    Часто сквозные процессы делят на модули, исполняемые целиком внутри организационных единиц компании, — их называют бизнес-процессами подразделения [1]. Такой способ локализации бизнес-процесса в рамках одного структурного подразделения свойственен функциональному подходу к управлению организацией и может противоречить основной цели моделирования — переходу к процессному управлению. Рекомендуется выявлять процессы с помощью цепочек создания ценностей [2]. Для этого предлагается: выявить клиентов компании; определить, какие продукты потребляют эти клиенты; определить поток преобразования продуктов или услуг, итогом которого является результат, ценный для клиента компании. Если компания выпускает материальный продукт, то определение цепочки создания ценности является относительно простой задачей, однако если компания предоставляет  услугу, то обнаружение цепочки ее создания существенно сложнее.

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

    В качестве критерия разделения сквозного процесса на цепочку взаимодействующих подпроцессов ряд авторов советуют анализировать выходы одного этапа процесса и входы следующего [4]. Действительно, если вход и выход соотносятся как 1:1, то процесс можно рассматривать как монолитный, но если соотношение имеет вид 1:М или М:1, то это свидетельствует о разделении процесса на подпроцессы.

    Таким образом, на сегодняшний день нет общепринятого критерия деления сквозного процесса на подпроцессы, и при отсутствии системного подхода аналитики полагаются на интуицию, а не на методологию. Как следствие, многие модели содержат ошибки, например до 20% моделей, включенных в справочник референтных моделей SAP, ошибочны [5].

    Объект управления

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

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

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

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

    Декомпозиция процесса

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

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

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

    Примеры деления на подпроцессы

    Рассмотрим типичный пример процесса заключения договора в нотации BPMN [6]. В примере имеются две точки старта, причем одна из них ведет в середину процесса, и несколько завершающих событий, некоторые из которых находятся в середине процесса (рис. 1). Сквозной процесс имеет два объекта управления: коммерческое предложение и договор — внимательный аналитик увидит смену объекта управления и предположит, что сквозной процесс распадется на два подпроцесса: «Согласовать коммерческое предложение» и «Заключить договор».

     

    Рис. 1. Сквозной процесс от заявки до договора
    Рис. 1. Сквозной процесс от заявки до договора

     

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

    • объявление о начале кампании по сбору заявок на номинацию;
    • заявка на номинацию, каждая заявка может содержать имена нескольких кандидатов;
    • список отобранных кандидатов на присуждение премии, один на всех номинантов;
    • запросы экспертам, по каждому кандидату из списка в отдельности;
    • отчет по списку кандидатов, содержит заключение по каждому номинанту;
    • результат голосования по списку, определяет одного лауреата премии.

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

    Этапы исполнения процесса

    Мы разделили сквозной процесс на подпроцессы, ориентируясь на смену объекта управления, однако получившиеся в результате подпроцессы могут оказаться достаточно большими и может возникнуть потребность их повторной декомпозиции на более мелкие фрагменты. Без потери общности будем считать, что у процесса есть только один объект управления. Рассмотрим алгоритм разбиения, выделив основные этапы жизненного цикла объекта управления.

    Декомпозиция процесса по этапам жизненного цикла объекта управления позволяет расположить этапы исполнения в естественном порядке следования. Они связаны безусловными переходами и образуют основной сценарий исполнения процесса [8], который не предполагает показывать альтернативные маршруты и варианты ветвления. Поэтому следующим шагом нужно уточнить модель: расширить — добавить в основной сценарий пропущенные варианты исполнения и углубить — детализовать каждый из подпроцессов. Можно оформить каждый этап как подпроцесс в нотации BPMN, тогда основной сценарий будет изображаться цепочкой подпроцессов, связанных безусловными переходами (рис. 2). Например, объект управления «Заказ» имеет следующие этапы жизненного цикла: оформление, проверка реализуемости, согласование условий, исполнение, передача заказчику и завершение финансовых расчетов. Затем основной сценарий следует уточнить: (а) расширить — добавить пропущенные варианты исполнения, (б) углубить — детализовать каждый из подпроцессов.

     

    Рис. 2. Основной сценарий исполнения процесса
    Рис. 2. Основной сценарий исполнения процесса

     

    Моделирование организационных обязанностей

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

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

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

     

    Псевдороли при организационном взаимодействии
      Псевдороль Функция
    1. Распределяющий Оценка задания, установка приоритетов и сроков
    2. Диспетчеризация, отбор и назначение исполнителя в соответствии с критериями
    3. Возложение поручения на выбранного  исполнителя 
    4. Исполнитель Выполнение функционального поручения
    5. Информируемый Координация работы
    6. Проверяющий Проверка качества выполненных работ
    7. Визирующий Утверждение результата своей подписью
    8. Передача задания на следующий этап обработки

     

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

     

    Рис. 3. Организационное взаимодействие участников
    Рис. 3. Организационное взаимодействие участников

     

    ***

    Предложенные критерии и метод последовательной декомпозиции процесса, предполагающий выделение объектов управления, рассмотрение этапов жизненного цикла каждого из объектов и выделение функций организационного взаимодействия участников, позволяют создать иерархическую модель, на верхнем уровне которой имеется самое общее представление о ходе процесса, а все детали спрятаны на нижних. Предлагаемые критерии объективны и измеряемы, что исключает субъективность при их применении. Полученная модель оказывается удобной для анализа разными категориями пользователей: бизнес видит суть процесса, изучая диаграммы верхнего уровня; эксперты предметной области смогут разобраться в подробностях, используя детализацию; разработчики найдут важные подробности на диаграммах нижнего уровня. Такая архитектура процесса максимально защищает модель от возможных модификаций, поскольку локализует изменения рамками соответствующего подпроцесса. Она помогает увидеть сходство разных процессов и свести их к единому сценарию, что улучшает управление. Подпроцессы нижнего уровня оказываются повторно используемыми, а модульная архитектура процесса оказывается удобной при автоматизации бизнеса.

    Литература

    1. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. — М.: Манн, Иванов и Фербер, 2012.
    2. Сооляттэ А.Ю., Репин В. В. Цепочка создания ценности — основа для построения сети бизнес-процессов компании // Финэксперт.
    3. Silver B., BPMN Method and Syle, 2009.
    4. Sharp А., McDermott P., Workflow Modeling. Artech House Publishers, 2001.
    5. Mendling J., Neumann G., Van der Aalst W., Understanding the Occurrence of Errors in Process Models Based on Metrics // In: Proceedings of the OTM Conference on Cooperative information Systems (CoopIS 2007). Berlin: Springer-Verlag, 2007.
    6. Белайчук А. Процессный паттерн: Cнова здравствуйте! [Электронный ресурс]. URL: mainthing.ru/ru/item/537/#more-537. 2012. (Из BPM-блога «Главное не результат, главное процесс»). 
    7. OMG. BPMN 2.0 by Example. OMG Document Number: dtc/2010-06-02. www.omg.org/spec/BPMN/2.0/examples/PDF
    8. Федоров И.Г. Системный подход к выявлению бизнес-процессов методом «сверху вниз» // Прикладная информатика. — 2012. No. 5 (41), — C.5–13.

    Игорь Федоров ([email protected]) — профессор, Московский государственный университет экономики, статистики и информатики (Москва).

    Поделитесь материалом с коллегами и друзьями

    www.osp.ru

    10.2.5. Подпроцесс

    Графический язык моделирования бизнес-процессов BPMN. Версия 2.0

    <exclusiveGateway gatewayDirection=»Diverging»/> <sequenceFlow sourceRef=»OrderApprovedDecision» targetRef=»OrderAndShipment»>

    <conditionExpression>Was the Order Approved?</conditionExpression> </sequenceFlow>

    <sequenceFlow sourceRef=»OrderApprovedDecision» targetRef=»TerminateProcess»> <conditionExpression>Was the Order NOT Approved?</conditionExpression>

    </sequenceFlow>

    <endEvent> <terminateEventDefinition/>

    </endEvent>

    <parallelGateway gatewayDirection=»Diverging»/>

    <sequenceFlow sourceRef=»OrderAndShipment» targetRef=»OrderHandling»/> <sequenceFlow sourceRef=»OrderAndShipment» targetRef=»ShipmentHandling»/>

    <task name=»Order Handling»/>

    <task name=»Shipment Handling»/>

    <sequenceFlow sourceRef=»OrderHandling» targetRef=»OrderAndShipmentMerge»/> <sequenceFlow sourceRef=»ShipmentHandling» targetRef=»OrderAndShipmentMerge»/> <parallelGateway gatewayDirection=»Converging»/> <sequenceFlow sourceRef=»OrderAndShipmentMerge» targetRef=»ReviewOrder»/> <userTask name=»Review Order»>

    <potentialOwner>

    <resourceRef>tns:departmentalReviewer</resourceRef> <resourceParameterBinding parameterRef=»tns:buyerName»>

    <formalExpression>getDataInput(‘order’)/address/name</formalExpression>

    </resourceParameterBinding>

    </potentialOwner>

    </userTask>

    <sequenceFlow sourceRef=»ReviewOrder» targetRef=»EndProcess»/> <endEvent/>

    </process>

    </definitions>

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

    Далее будут рассмотрены различные типы Подпроцессов.

    Встроенный Подпроцесс (Embedded Sub-Process (Sub-Process))

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

    Подпроцесс представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен одинарной тонкой линией.

    o Текст, цвет, размер, а также линии, используемые для изображения Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм». Однако следует учитывать следующее исключение:

    Одинарная жирная линия в изображении границ Подпроцесса ДОЛЖНА означать использование данного графического элемента в качестве Действия Вызов

    (Подпроцесс).

    167

    http://www.elma-bpm.ru

    Графический язык моделирования бизнес-процессов BPMN. Версия 2.0

    Пунктирная линия в изображении границ Подпроцесса ДОЛЖНА означать использование данного графического элемента в качестве Событийного Подпроцесса.

    Двойная линия в изображении границ Подпроцесса ДОЛЖНА означать использование данного графического элемента в качестве Подпроцесса Транзакции.

    Подпроцесс может быть свернутым (Collapsed Sub-Process), при этом его детали скрыты (см. фигуру 10.25). Подпроцесс также может быть развернутым (Expanded Sub-Process), при этом его детали отображаются внутри Процесса, в котором данный Подпроцесс содержится (см. фигуру 10.26). В случае, если Подпроцесс является свернутым, то используется маркер, позволяющий отличить Подпроцесс от Задачи.

    Маркер Подпроцесса ДОЛЖЕН изображаться в виде небольшого квадрата, расположенного в центре нижней части графического элемента и заключающего в себе знак «+».

    Фигура 10.25 – Графический элемент Свернутый Подпроцесс

    Фигура 10.26 – Графический элемент Развернутый Подпроцесс

    Подпроцессы используются для создания контекста для управления исключением, применяемым к группе Действий. Подобным образом выполняется управление Компенсацией.

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

    Стартового и Конечного Событий необязательным.

    Фигура 10.27 – Развернутый Подпроцесс, выступающий в роли «параллельного блока».

    168

    http://www.elma-bpm.ru

    Графический язык моделирования бизнес-процессов BPMN. Версия 2.0

    BPMN различает пять типов стандартных маркеров Свернутого Подпроцесса. Маркер Подпроцесса, изображенный на фигуре 10.25, может сочетаться с оставшимися четырьмя маркерами: Маркером Цикла (Loop

    Marker), Многоэкземплярным Маркером (Multiple-Instance Marker), Маркером Компенсации (Compensation

    Marker) и Маркером Ad Hoc (Ad-Hoc Marker). Свернутый Подпроцесс может содержать от одного до трех вышеуказанных Маркеров. Комбинации Маркеров могут быть любыми, кроме сочетания Маркеров Цикличности

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

    Маркер Цикла ДОЛЖЕН БЫТЬ выполнен в виде небольшой стрелки, острие которой загнуто в направлении, противоположном направлению самой стрелки.

    o Маркер Цикла МОЖЕТ сочетаться с любым другим Маркером Подпроцесса, кроме

    Многоэкземплярного

    Многоэкземплярный Маркер ДОЛЖЕН БЫТЬ выполнен в виде трех параллельных вертикальных линий. o Многоэкземплярный Маркер МОЖЕТ сочетаться с любым другим Маркером Подпроцесса,

    кроме Маркера Цикла.

    Маркер Ad Hoc ДОЛЖЕН БЫТЬ выполнен в виде тильды.

    oМаркер Ad Hoc МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.

    Маркер Компенсации ДОЛЖЕН БЫТЬ выполнен в виде двух треугольников, повернутых влево (как кнопка перемотки назад на проигрывателе).

    oМаркер Компенсации МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.

    Все вышеописанные Маркеры при совместном отображении ДОЛЖНЫ БЫТЬ сгруппированы и располагаться в центре нижней части графического элемента Подпроцесса.

    Цикл

    Многоэкземплярность

    Компенсация

    Ad-Hoc

    Компенсация + Ad-Hoc

    Фигура 10.28 – Маркеры Свернутого Подпроцесса

    Свернутый Подпроцесс в BPMN 2.0 относится к Встроенному Подпроцессу, описанному в BPMN 1.2. Повторно используемый Подпроцесс в BPMN 1.2 относится к Действию типа Вызов, описанному в BPMN 2.0.

    Фигура 10.29 представляет собой диаграмму классов Подпроцесса.

    169

    http://www.elma-bpm.ru

    Графический язык моделирования бизнес-процессов BPMN. Версия 2.0

    Фигура 10.29 — Диаграмма классов элемента SubProcess

    Элемент SubProcess наследует атрибуты и ассоциации элементов Activity (см. таблицу 10.3) и элемента FlowElementContainer (см. таблицу 8.45). Таблица 10.20 содержит информацию о дополнительных атрибутах элемента SubProcess.

    Таблица 10.20 – Атрибуты элемента SubProcess

    Название атрибута

    Описание/использование

     

     

    triggeredByEvent: boolean = false

    Данный атрибут указывает на то, что данный

     

    Подпроцесс работает с Событиями.

     

    Значение «false» указывает на то, что

     

    Подпроцесс является стандартным.

     

    Значение «true» указывает на то, что

     

    Подпроцесс работает с Событиями и

     

    является причиной возникновения

     

    дополнительных ограничений.

     

     

    triggeredByEvent: boolean = false

    Данный атрибут обусловливает наличие списка

     

    Артефактов, хранящихся в Подпроцессе.

     

     

    Reusable Sub-Process (Call Activity) Повторно используемый Подпроцесс (Вызов)

    Повторно используемый Подпроцесс, описанный в BPMN 1.2, относится к Действию типа Вызов, используемому для вызова предопределенного Подпроцесса.

    Событийный Подпроцесс (Event Sub-Process)

    Событийным Подпроцессом называется специфический Подпроцесс, используемый внутри Процесса (Подпроцесса). Такой Подпроцесс имеет атрибут triggeredByEvent с установленным значением «true».

    Такой Подпроцесс не является частью Стандартного Потока Операцйий, включенного в родительский

    Процесс, и не имеет входящих или исходящих Потоков Операций.

    Событийный Подпроцесс НЕ ДОЛЖЕН иметь входящих или исходящих Потоков операций.

    170

    http://www.elma-bpm.ru

    Графический язык моделирования бизнес-процессов BPMN. Версия 2.0

    Событийный Подпроцесс МОЖЕТ появляться (один раз или многократно) или НЕ появляться в ходе выполнения родительского Процесса. Отличие такого Подпроцесса от стандартного состоит в том, что стандартный Подпроцесс в качестве триггера использует Поток операций, а Событийный Подпроцесс —

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

    Стартовое Событие Событийного Подпроцесса ДОЛЖНО иметь определенный триггер. o Стартовое событие (EventDefinition) ДОЛЖНО БЫТЬ одного из следующих типов:

    Сообщение, Ошибка, Эскалация, Компенсация, Условие, Сигнал, Множественный.

    Событийный Подпроцесс ДОЛЖЕН содержать одно или более Стартовое Событие.

    Такой Подпроцесс изображается в виде прямоугольника с закругленным углами (установленное в BPMN отображение графического элемента Подпроцесс).

    Событийный Подпроцесс представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен одинарной тонкой пунктирной линией (см. фигуры 10.30 и 10.31).

    o Текст, цвет, размер, а также линии, используемые для изображения данного Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм». Однако следует учитывать следующее исключение:

    Если Событийный Подпроцесс является свернутым, то Стартовое Событие в

    таком Подпроцессе будет являться маркером и отображаться в левом верхнем углу фигуры Подпроцесса (см. фигуру 10.30).

    Фигура 10.30 – Графический элемент Свернутый Событийный Подпроцесс

    Фигура 10.31 – Графический элемент Развернутый Событийный Подпроцесс

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

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

    171

    http://www.elma-bpm.ru

    Графический язык моделирования бизнес-процессов BPMN. Версия 2.0

    Фигура 10.32 –Событийные Подпроцессы внутри родительского Подпроцесса

    Транзакция (Transaction)

    Транзакцией называется специфический тип Подпроцесса, который демонстрирует определенное поведение, контролируемое посредством протокола транзакции (например, WS-Transaction). Граница графического элемента Транзакция выполнена двойной линией (см. фигуру 10.33).

    Транзакция представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен двойной тонкой линией.

    o Текст, цвет, размер, а также линии, используемые для изображения данного Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм».

    172

    http://www.elma-bpm.ru

    Графический язык моделирования бизнес-процессов BPMN. Версия 2.0

    Фигура 10.33 –Подпроцесс Транзакция

    Фигура 10.34 – Свернутый Подпроцесс Транзакция

    Элемент Transaction Sub-Process наследует атрибуты и ассоциации элемента Activity (см. таблицу 10.3) за счет взаимосвязи с Подпроцессом. Таблица 10.21 содержит информацию о дополнительных атрибутах и ассоциациях элемента Transaction Sub-Process.

    Таблица 10.21 – Атрибуты и ассоциации элемента Transaction Sub-Process

    Название атрибута

    Описание/использование

     

     

    method: TransactionMethod

    Данный атрибут определяет метод,

     

    используемый для совершения Транзакции или

     

    её отмены. Для выполняемых процессов

     

    данный атрибут ДОЛЖЕН содержать особый

     

    URL, например,

     

    http://schemas.xmlsoap.org/ws/2004/10/wsat for

     

    WS-AtomicTransaction, или http://docs.oasis-

     

    open.org/ws-tx/wsba/2006/ 06/AtomicOutcome для

     

    WS-BusinessActivity. Для сохранения

     

    совместимости с BPMN 1.1 данный атрибут

     

    также может иметь значения «##compensate»,

     

    «##store» и «##image».

     

     

    Использование Транзакции может привести к следующим результатам:

    173

    http://www.elma-bpm.ru

    Графический язык моделирования бизнес-процессов BPMN. Версия 2.0

    1.Удачное завершение. Отображается в виде Стандартного Потока Операций, отходящего от

    Транзакции.

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

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

    o Поток операций Транзакции достигает Промежуточного события Отмена. Это Событие

    используется только для такого типа Подпроцессов.

    o Сообщение об отмене может быть получено посредством протокола транзакции, поддерживающего выполнение данной Транзакции.

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

    Промежуточного события Ошибка.

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

    Спонтанный Подпроцесс (Ad-Hoc Sub-Process)

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

    Графический элемент Спонтанный Подпроцесс содержит маркер, выполненный в виде знака тильды и располагающийся в центре нижней части фигуры Подпроцесса (см фигуру 10.35 и 10.36).

    Маркер Спонтанного Подпроцесса ДОЛЖЕН БЫТЬ выполнен в виде тильды.

    o Маркер Ad Hoc МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.

    Фигура 10.35 – Графический элемент Свернутый Спонтанный Подпроцесс

    174

    http://www.elma-bpm.ru

    Графический язык моделирования бизнес-процессов BPMN. Версия 2.0

    Фигура 10.36 – Графический элемент Развернутый Спонтанный Подпроцесс

    Элемент Ad-HocSub-Process наследует атрибуты и ассоциации элемента Activity (см. таблицу 10.3) за счет взаимосвязи с Подпроцессом.

    Таблица 10.22 содержит информацию о дополнительных ассоциациях элемента Ad-HocSub-Process.

    Таблица 10.22 – Ассоциации элемента Ad-HocSub-Process

    Название атрибута

    Описание/использование

     

     

    completionCondition: Expression

    Данный атрибут определяет условия, при

     

    которых завершается Процесс. Значение «true»

     

    указывает на то, что Процесс будет завершен.

     

     

    ordering: AdHocOrdering = Parallel { Parallel |

    Данный атрибут указывает на то, будут ли

    Sequential }

    Действия, включенные в Процесс, выполняться

     

    параллельно или НЕОБХОДИМО

     

    последовательное их выполнение. Значением

     

    по умолчанию является «parallel». Значение

     

    «sequential» ограничивает одновременное

     

    выполнение нескольких Действий. В данном

     

    случае в определенный период времени может

     

    быть выполнено лишь одно Действие. Если

     

    выбрано значение «parallel», то

     

    одновременно может выполняться любое

     

    количество Действий, от нуля и более.

     

     

    cancelRemainingInstances: boolean = true

    Данный атрибут используется только в том

     

    случае, если для вышеописанного атрибута

     

    ordering установлено значение «parallel».

     

    Указывает на то, будут ли отменены

     

    запущенные экземпляры Действий, если

     

    значение атрибута completionCondition

     

    становится «true».

     

     

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

    Примерами Процессов, входящих в состав Спонтанного Подпроцесса, являются разработка кода (на низком уровне), поддержка клиентов, а также написание главы книги. Рассмотрим, к примеру, написание главы для книги. Мы видим, что данный Процесс включает следующие Действия: поиск темы, составление текста, редактирование текста, создание дизайна, графическое оформление текста, оформление ссылок и т.д. (см. фигуру 10.37). В таком Процессе МОЖЕТ наблюдаться определенная зависимость Задач друг от друга, например, редактирование текста не может происходить раньше его написания. Однако такая корреляция между экземплярами Задачам по написанию и редактированию текста не обязательна. Редактирование может возникать

    175

    http://www.elma-bpm.ru

    Графический язык моделирования бизнес-процессов BPMN. Версия 2.0

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

    Фигура 10.37 – Спонтанный Подпроцесс написания главы для книги

    Хотя в Спонтанном Подпроцессе структура не определена, в его детали все же может быть добавлена информация о последовательности Действий или корреляции данных. К примеру, можно расширить вышеописанный Спонтанный Подпроцесс написания главы для книги путем добавления в него Объектов данных, Ассоциаций или Потоков операций (см. фигуру 10.38).

    Однако использование в Спонтанном Подпроцессе элементов потока должно осуществляться со следующими ограничениями, не имеющими отношения к использованию элементов в Подпроцессах других типов:

    В список элементов BPMN, которые ДОЛЖНЫ использоваться в Спонтанном Подпроцессе, входит

    Действие.

    В список элементов BPMN, которые МОГУТ использоваться в Спонтанном Подпроцессе, входят:

    Объект данных, Поток операций, Ассоциация, Ассоциация данных, Группа, Поток сообщений (может являться как целью, так и результатом), Шлюз, Промежуточное событие.

    В список элементов BPMN, которые НЕ ДОЛЖНЫ использоваться в Спонтанном Подпроцессе,

    входят: Стартовое событие, Конечное событие, Переговоры (графически), Соединители переговоров (графически), Действия Хореографии.

    Фигура 10.38 – Спонтанный Подпроцесс написания главы для книги с отображением последовательности Действий и зависимых данных

    Объект данных, предоставленный для Задач на входе, является дополнительным ограничением для выполнения этих Задач. В данном случае Исполнители, хотя и решают, когда будут выполнены Задачи, уже

    176

    http://www.elma-bpm.ru

    studfile.net

    подпроцесс — с русского на все языки

  • подпроцесс — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN subrun …   Справочник технического переводчика

  • КВАРК-ГЛЮОННЫЙ ПОДПРОЦЕСС — в квантовой хромодинамике процесс взаимодействия кварков и глюонов на малых расстояниях, определяющий сечение жёстких процессов с участием адронов. Напр., в процессе рождения в адрон адронном соударении пары мюонов с большой относит. энергией К.… …   Физическая энциклопедия

  • BPMN — (англ. Business Process Model and Notation, нотация и модель бизнес процессов)   система условных обозначений (нотация) для моделирования бизнес процессов. Разработана Business Process Management Initiative (BPMI) и поддерживается… …   Википедия

  • ГЛЮОНЫ — (от англ. glue клей), гипотетич. электрически нейтр. ч цы, со спином 1 и нулевой массой покоя, являющиеся переносчиками сильного вз ствия между кварками. В совр. теории сильного вз ствия квантовой хромодинамике предполагается существование восьми …   Физическая энциклопедия

  • ПАРТОНЫ — (от лат. pars, род. падеж partis часть), составляющие адронов, проявляющиеся в процессах с большой передачей четырёхмерного импульса, в частности в глубоко неупругих процессах. В модели П. считается, что адрон участвует в реакциях лишь нек рой… …   Физическая энциклопедия

  • Бизнес-моделирование — (деловое моделирование)   деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т. д.) …   Википедия

  • Бизнес моделирование — деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный подпроцесс в процессе… …   Википедия

  • Моделирование бизнес-процессов — Бизнес моделирование деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный… …   Википедия

  • Моделирование бизнеса — Бизнес моделирование деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный… …   Википедия

  • ИНТЕГРАЦИЯ — (Integration) процесс, с помощью которого части соединяются в целое; на личностном уровне состояние организма, когда все составляющие элементы индивида, его черты или качества действуют согласованно как единое целое.Юнг использовал этот термин… …   Словарь по аналитической психологии

  • управление мощностями бизнеса — (ITIL Continual Service Improvement) (ITIL Service Design) В контексте ITSM, управление мощностями бизнеса – это подпроцесс управления мощностями, отвечающий за понимание будущих потребностей бизнеса для использования в плане мощностей. См …   Справочник технического переводчика

    • translate.academic.ru

    No related posts.

    Leave a Reply