Может ли графическая модель описания бизнес процесса иметь несколько событий начала

В статье «Почему Visio не годится для BPMN» я писал, что грамотная модель бизнес-процесса в нотации BPMN должна быть двухуровневой:

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

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

Текстовое, табличное и графическое описание бизнес-процессов

Процитированное выше – правда, но не вся. На самом деле уровней три:

1. архитектура процесса
2. схема процесса
3. рабочие инструкции процесса

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

Пример: закупка сырья

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

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

Неопытный аналитик воспримет этот рассказ за чистую монету и изобразит процесс так, как услышал:

Рис. 1. Наивное представление процесса закупки сырья

Отношения множественности

У более искушенного процессного специалиста возникнет ряд вопросов:

• Судя по схеме на рис. 1, для каждой закупки выбирается поставщик и с ним заключается договор. Но смысл рамочного договора в том, что он заключается на длительный срок (измеряемый месяцами или даже годами), после чего по нему периодически размещаются заказы. То есть связь между договором и заказом не один-к-одному (один договор – один заказ), а один-ко-многим (один договор – ноль, один или много заказов).
• Аналогичным образом, по одному заказу осуществляется несколько поставок.
• Оплата тоже осуществляется не по схеме»одна поставка – один платеж», а в соответствии с платежным календарем предприятия. Может проводиться как несколько платежей по одному заказу (аванс и оплата), так и наоборот – один платеж по нескольким заказам. То есть связь между поставкой и оплатой имеет вид многие-ко-многим.

Для наглядности покажем отношения множественности на схеме:

Рис. 2. Отношения множественности в закупке

Здесь 1:М – соотношение один-ко-многим, М:М – многие-ко-многим.

Чтобы показать, что в ходе процесса по одной и той же процедуре обрабатывается несколько объектов, в нотации BPMN есть специальный модификатор – цикл по объектам (multi-instance). Выглядит он так:

Рис. 3. Процесс закупки с циклами по объектам

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

Но к сожалению в данном случае цикл по объектам применить не удастся. Его можно использовать только если число объектов известно заранее, до начала цикла. В данном же процессе число заказов сырья в момент заключения договора неизвестно – заказывать будем по мере необходимости. Число поставок по одному заказу более предсказуемо, но тоже не на 100%: доставку осуществляет поставщик, и график доставки может корректироваться.

Стартовые события

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

В случае подпроцесса (как на диаграммах выше) стартовое событие – «отмашка» от процесса/подпроцесса уровнем выше: завершили один подпроцесс, переходим к другому.

Но в данном случае это не так – инициатором является внешнее событие:

• заказ сырья инициируется фактом снижения запасов ниже нормативного минимума
• прием инициируется фактом прихода груза от поставщика
• оплата инициируется платежным календарем (например, еженедельно)

Событие произошло – отрабатываем его; событие не произошло – ничего не делаем. Этот сценарий в BPMN соответствует запуску процесса, а не подпроцесса.

От одного процесса к нескольким

Вывод: закупка – не один, а несколько процессов BPMN:

Рис. 4. Закупка в виде нескольких процессов

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

Недостаток схемы на рис. 4 – на ней не показаны связи между процессами. Это можно исправить:

Рис. 5. Межпроцессное взаимодействие через данные

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

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

В BPMN процессы можно изображать в виде «черных ящиков», т.е. без содержимого:

Рис. 6. Белые, но на самом деле черные ящики

Гибридная диаграмма DFD-BPMN

Диаграмма на рис. 6 корректна, компактна, но малоинформативна – к сожалению, BPMN не позволяет соединять пулы с потоками данных, поэтому мы не можем показать связь между процессами, как мы это сделали на рис. 5.

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

Диаграмма потоков данных (DFD – data flow diagram) выглядит так:

Рис. 7. Архитектура процесса закупки сырья в нотации DFD

А вот как выглядит та же диаграмма, но построенная с помощью значков BPMN:

Рис. 8. Уровень 1: архитектура процесса закупки в нотации DFD-BPMN

Детализируя ее на уровень ниже, получаем уже честный BPMN. Например, процесс «Заказ сырья»:

Рис. 9. Уровень 2: схема процесса «Заказ сырья»

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

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

Рис. 10. Уровень 3: рабочие инструкции задачи «Подготовить заказ поставщику»

Нестандартно, зато дешево, надежно и практично

Ситуация, когда то, что бизнес рассматривает как один бизнес-процесс (в данном случае – процесс закупки сырья), при моделировании в BPMN распадается на несколько процессов, является достаточно частой.

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

Существует несколько нотаций, подходящих для моделирования процессной архитектуры: IDEF0, VAD, DFD. Не вдаваясь в подробности, мне больше нравится последний.

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

Например, так может выглядеть карта процессов верхнего уровня:

Рис. 11. Карта процессов верхнего уровня (DFD-BPMN)

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

Когда нужна архитектура процесса

Всегда ли нужен уровень архитектуры процесса? Нет, не всегда.

В простых случаях процесс в понимании бизнеса – это один процесс BPMN. Примеры:

• увольнение сотрудника
• очередной отпуск
• от командировочного предписания до отчета

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

Большой размер также не является основанием разбивать процесс на несколько. Разбейте его на подпроцессы; если подпроцессы тоже слишком велики, чтобы их охватить взглядом – сделайте подпроцессы второго уровня. Число уровней подпроцессов в BPMN не ограничено.

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

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

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

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

Эти техники мы осваиваем в теории на тренингах BPMN052 или BPMN101, а на практике BPMN102 приходит полное понимание.

Хотите научиться? Бронируйте место на очередном тренинге.

Источник: bpmntraining.ru

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

Модель бизнес-процессов согласно методологии SADT создается на основе принципа декомпозиции: «…декомпозиция заключается в начальном разделении объекта на более мелкие части и последующем соединении их в более детальное описание объекта.» На верхнем уровне модели рассматриваемая система представляется виде одного процесса, например, «Деятельность по производству и продаже оборудования», далее он декомпозируется на совокупность бизнес-процессов верхнего уровня (см. пример переченя бизнес-процессов в главе 3). Каждый из бизнес-процессов верхнего уровня декомпозируется на ряд подпроцессов. В качестве критерия выделения подпроцессов второго уровня можно использовать промежуточные состояния объекта управления. Например, процесс «Продвижение и продажи» может быть декомпозирован на подпроцессы:

1. Продвижение продуктов

2. Выяснение потребности клиента

3. Заключение договора с потребителем

4. Прием текущих заказов

5. Производственное планирование

6. Организация выполнения заказа клиента

7. Организация удовлетворения претензий клиентов

8. Анализ удовлетворенности клиентов

Количество уровней декомпозиции выбирается исходя из стоящих задач и необходимой степени подробности описания. На практике используют 3-5 уровней декомпозиции.

Business Studio позволяет создавать графические модели бизнес-процессов с помощью диаграмм, выполненных в той или иной нотации моделирования. Поддерживается три типа нотаций графического моделирования – IDEF0, Процесс и Процедура. Для создания модели бизнес-процессов можно использовать любую из этих нотаций или их комбинации. Рекомендуется в зависимости от уровня процесса в модели для его описания использовать следующие нотации:

Если в модели используются метапроцессы, то уровни сдвигаются, начиная с 1.

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

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

Нотация IDEF0

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

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

Диаграмма A-0 устанавливает область моделирования и ее границу. Пример диаграммы A-0 (Рис.7):

Рис.7. Диаграмма A-0 нотации IDEF0

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

Выделение 4 видов стрелок. Выделяются следующие виды стрелок: Вход, Выход, Механизм, Управление. Входы преобразуются или расходуются процессом, чтобы создать то, что появится на его выходе. Управления определяют условия, необходимые процессу, чтобы произвести правильный выход. Выходы — данные или материальные объекты, произведенные процессом.

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

Используемые графические символы

Символ	Изображение	Описание
Блок		Блок описывает процесс. Типичный блок показан на рис. 1. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом, глагольным оборотом или отглагольным существительным. Номер блока размещается в правом нижнем углу. Номера блоков используются для идентификации на диаграмме и в соответствующем тексте.
Стрелка		Стрелки обозначают входящие и исходящие из процесса объекты (данные). Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок-стрелка, В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелки, входящие в левую сторону блока — входы. Стрелки, входящие в блок сверху — управления. Стрелки, покидающие процесс справа – выходы, т.е. данные или материальные объекты, произведенные процессом. Стрелки, подключенные к нижней стороне блока, представляют механизмы.
Туннелированная стрелка		Туннелированные стрелки означают, что данные, обозначаемые этими стрелками, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме. Стрелка, помещенная в туннель там, где она присоединяется к блоку, означает, что данные, выраженные этой стрелкой, не обязательны на следующем уровне декомпозиции. Стрелка, помещаемая в туннель на свободном конце означает, что выраженные ею данные отсутствуют на родительской диаграмме.
Внешняя ссылка		Внешняя ссылка – место, сущность или субъект, которые находятся за границами моделируемой системы. Используются для обозначения источника или приемника стрелки вне модели. На диаграммах Внешняя ссылка изображается в виде квадрата, рядом с которым показано наименование Внешней ссылки.
Междиаграммная ссылка		Элемент, обозначающий другую диаграмму. Служит для обозначения перехода стрелок на диаграмму другого бизнес-процесса без показа стрелки на вышележащей диаграмме (при использовании иерархических моделей).

Пример диаграммы процесса в нотации IDEF0 (Рис.8):

Рис.8. Диаграмма процесса нотации IDEF0

Подробнее с правилами создания нотации IDEF0 можно познакомиться в источниках [1],[2].

Нотации Процесс и Процедура

Нотации Процесс (Basic Flowchart в Microsoft Visio) и Процедура (Cross Functional Flowchart в Microsoft Visio) используются для представления алгоритма (сценария) выполнения процесса и позволяют задать причинно-следственные связи и временную последовательность выполнения действий процесса. Нотации поддерживают декомпозицию на подпроцессы, так же как и нотация IDEF0.

Различие между нотациями Процесс и Процедура состоит в том, что дополнительно к графическим элементам, применяемым в нотации Процесс, в нотации Процедура используются дорожки (Swim Lanes), обозначающие организационные единицы – исполнителей действий процесса. Это позволяет повысить наглядность диаграммы.

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

Используемые графические символы

Символ	Изображение	Описание
Действие		Прямоугольный блок обозначает действие (функцию). Внутри блока помещается название действия. Временная последовательность выполнения действий задается расположением действий на диаграмме процесса сверху вниз (слева направо на горизонтальной диаграмме Процедуры).
Решение	Рис.9 Рис.10 Рис.11	Выбор следующего выполняемого действия в зависимости от условия. Может иметь несколько входов и ряд альтернативных выходов, один и только один из которых может быть активизирован после проверки условия. Блок «Решение» должен содержать вопрос, решение или условие. Выходящие стрелки помечаются как «Да» или «Нет», или другим способом для учета всех возможных вариантов ответов. Возможны следующие виды изображения стрелок: Рис.9, Рис.10, Рис.11 Блок «Решение» аналогично элементу «Исключающее ИЛИ» (XOR) в других нотациях моделирования.
Связь предшествования	Рис.12 Рис.13	Такие стрелки обозначают передачу управления от одного действия к другому, т.е. что предыдущее действие должно закончиться прежде, чем начинается следующее. Стрелка, запускающая выполнение действия изображается входящей в действие сверху. Стрелка, обозначающая передачу управления другому (другим) действиям изображается выходящей из действия снизу (Рис.12). Если стрелка служит только для обозначения передачи управления, то имя стрелки оставляется пустым (Рис. 1). Если кроме передачи управления из предыдущего действия в следующее действие поступает Объект(ы), то стрелка именуется и в список объектов стрелки заносится соответствующий Объект(ы) (Рис.13).
Поток объектов	Рис.14 Рис.15	Используется в случаях, когда необходимо показать, что из одного действия объекты передаются в другое, при этом первое действие не запускает выполнения второго. Стрелки «Поток объектов» обозначаются стрелкой с двумя треугольниками. Если обозначение источника Объекта(ов) не важно, то такой Объект показывается стрелкой с туннелированным началом (Рис.14). Если источником Объекта(ов) является одно из действий процедуры, то такой Объект показывается с помощью стрелки, исходящей из действия-источника и входящей в действие-потребитель, для выполнения которого необходим Объект (Рис.15). При этом Действие «Регистрация в журнале «Исходящая корреспонденция» не запускает выполнение действия «Заполнение графы «Номер накладной» в журнале «Исходящая корреспонденция»
Дорожки (диаграмма Процедура)	Дорожки предназначены для отображения организационных единиц (должности, подразделения, роли) – исполнителей действий процедуры.
Сноска		Выносной элемент, предназначенный для нанесения комментариев.
Текст		Комментарий без сноски.
Терминатор	Отображает стартовую и конечные точки процедуры. В качестве названия терминаторов можно задавать названия стартового события, приводящего к началу выполнения процесса, и конечных событий, наступлением которых заканчивается выполнения процесса. Началом процедуры считается терминатор, из которого только исходят стрелки передачи управления. Концом процедуры считается терминатор, в который только входят стрелки передачи управления.
Междиаграммная ссылка		Элемент, обозначающий другую диаграмму. Служит для обозначения перехода стрелок на диаграмму другого бизнес-процесса либо процедуры без показа стрелки на вышележащей диаграмме (при использовании иерархических моделей).

Правила моделирования для нотаций Процесс и Процедура

1. На диаграмме действия располагаются сверху вниз в соответствии с временной последовательностью их выполнения.

2. На диаграмме нотации Процедура действия располагаются в соответствующих дорожках, обозначающих субъектов (должности, подразделения, роли, внешние субъекты), которые являются Исполнителями соответствующих действий.

3. Рекомендуемое количество действий на диаграмме – не более 20. Если количество действий получается значительно выше, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели.

4. Стрелки типа Связь предшествования рекомендуется делать вертикальными (при вертикальной ориентации диаграммы).

5. Стрелки поток объектов (передачи объектов) рекомендуется делать выходящими и входящими в левую/правую грани действия (при вертикальной ориентации диаграммы).

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

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

8. Стрелки «Управления» и «Механизмы» на родительской диаграмме IDEF0 (если таковая используется) туннелируются на уровне всей процедуры, как относящиеся ко всей процедуре целиком.

9. Если после выполнения действия должно быть инициировано выполнение нескольких действий, которые должны выполняться параллельно, то это обозначается с помощью нескольких исходящих стрелок Связь предшествования. На Рисунке Рис.16 после завершения Действия1 начинают выполняться Действие2 и Действие3.

Рис.16. Параллельные ветви

10. Если действие инициирует выполнение только одного из нескольких следующих действий в зависимости от определенного условия, то это показывается с помощью блока «Решение» (Рис.17).

Рис.17. Условное выполнение действий

11. Стрелки допускается объединять согласно правилам слияния стрелок методологии функционального моделирования IDEF0 [1]. Наиболее часто возникающие частные случаи:

— при присоединении одного именованного сегмента к другому(основному), основной сегмент должен содержать все объекты, принадлежащие присоединяемому сегменту. На Рис. 18 стрелка «Проект документа» содержит объект «Документ», который есть на стрелке «Исправленный документ», поэтому их слияние допускается:

Рис. 18 Объединение стрелок

— если сегменты содержат разные наборы объектов, то их слияние не допускается. На Рис. 19 стрелка «Исправленный документ, перечень исправлений» содержит два объекта – «Документ» и «Перечень исправлений», поэтому ее присоединение к стрелке «Проект документа»,которая содержит только один объект «Документ», не допускается:

Рис. 19 Объединение стрелок не допускается

Пример диаграммы нотации Процесс

Пример диаграммы нотации Процедура

Подробнее про формирование модели бизнес-процессов см. в Руководстве пользователя, глава 4 «Создание модели бизнес-процессов в Business Studio».

Объекты

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

Некоторые программы проектирования систем управления предлагают перечень объектов со стандартизованными названиями (Рис.22):

Рис.22. Справочник Объекты

Источник: infopedia.su