Подпроцесс это: Глава 10. Процесс. Подпроцесс – подпроцесс — Викисловарь

Глава 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]). Допускается использование материалов сайта без уведомления авторов, но с явным указанием источника.

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

Содержание

• 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. процесс

Гипонимы[править]

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

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

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

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

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

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

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

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

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

Декомпозиция или подпроцесс?

Нередко даже в профессиональной среде путают два понятия — декомпозиция и подпроцесс. На самом деле, это далеко не одно и то же. И важно понимать разницу между этими двумя терминами.

Декомпозиция

Декомпозиция — это разложение задачи на более простые элементы. Может использоваться как в функциональном, так и в процессном моделировании.

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

Пример декомпозиции сущности А:

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

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

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

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

Подпроцесс

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

Подпроцесс А внутри процесса:

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

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

‍

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

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

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

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

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

 

Бизнес процесс, подпроцессы и операции

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

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

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

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

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

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

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

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

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

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

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

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

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

Подпроцесс – QuickBPM — HELP

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

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

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

    

Иными словами, подпроцес – это комплексная задача в рамках основного процесса. Однако стоит отметить, что элемент Запуск процесса является не самостоятельной задачей, а лишь отсылкой к другому процессу.

В подпроцесс можно вносить изменения, не затрагивая при этом основной процесс. 

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

Вкладка «Основное»

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

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

Вкладка «Входные и выходные атрибуты»

Вы можете сопоставить контекстные переменные в родительском и дочернем процессах. Обратите внимание, что сопоставить можно только переменные одного типа. 

• Входные переменные – передаются из родительского процесса в дочерний при запуске последнего.
• Выходные переменные – передаются в родительский процесс из дочернего при завершении последнего.

 

< События Сценарий >

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

подпроцесс — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 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, управление мощностями бизнеса – это подпроцесс управления мощностями, отвечающий за понимание будущих потребностей бизнеса для использования в плане мощностей. См …   Справочник технического переводчика

Корпоративные Документы и Процессы > Бизнес-процессы > Нотация бизнес-процессов

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

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

Нотация бизнес-процессов, используемая в  системе ИНТАЛЕВ: Корпоративный менеджмент как способ графического представления информации, наглядно представляет бизнес-процесс, помогает понять его сложную логику и увидеть общую картину процесса.

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

Например, процесс Снабжение можно представить следующим образом:

 

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

 

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

Пример. Процесс Снабжение.

 

Обобщенный процесс закупки

 

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

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

Но функция Закупка материалов не будет такой простой, так как в неё войдут следующие действия: поиск поставщиков, ведение договорной работы, ведение претензионной работы, оформление сопроводительных документов и т.д.

Получаем следующий результат:

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

•	Функция Закупка материалов является достаточно сложной.

В таком случае Формирование заявки, Формирование плана закупок и Передача материалов в подразделение будут являться функциями, а Закупка материалов — подпроцессом.

 

Процесс Закупки с подпроцессом Закупка материалов

 

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

Существенной возможностью, предоставляемой программно-методическим комплексом ИНТАЛЕВ: Корпоративный менеджмент, является одновременное использование одного и того же подпроцесса в различных процессах.

 

Пример. Подпроцесс Оформление заявки на выдачу денежных средств.

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

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

 

Использование одного подпроцесса несколькими процессами

 

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

 

Пример. Разделение и Слияние.

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

Определение понятий Разделение и Слияние даётся в следующем примере.

 

 

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

 

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

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

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

 

Следует учитывать, что одному Разделению должно соответствовать только одно Слияние.

 

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

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

 

Пример. Источник сигнала и Приемник в бизнес-процессе Поставка продукции.

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

 

 

Процесс, выполняемый по двум путям одновременно

 

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

Отличия Ветвления от функции:

1.	Ветвление не подразумевает выполнения действия.

2.	Путь продолжения процесса для Ветвления определяется входящим условием. Для функции путь продолжения процесса определяется на основании условия, сформированного на этапе ее выполнения.

 

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

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

 

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

 

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

 

Пример. Точка контроля в бизнес-процессе Выполнение заказа покупателя.

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

 

Процесс Выполнение заказа покупателя, использующий Точку контроля

 

См. также: