Методы и способы проектирования процессов. IDEF-модели и их ограничения.

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

Бизнес-процесс – последовательность действий (подпроцессов), направленная на получение заданного результата, ценного для организации.

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

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

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

Ключевыми понятиями процессного подхода являются:

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

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

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

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

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

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

Для того чтобы разработать модель бизнес-процессов необходимо:

· Выявить набор объектов управления.

· Выбрать подход к описанию бизнес-процессов.

· Выбрать конфигурацию модели (моделей) бизнес-процессов.

· Разработать модель (модели) бизнес-процессов.

· Заполнить параметры процессов.

· Выбрать и назначить процессам показатели эффективности деятельности.

· Оценить время и стоимость выполнения процессов и провести их оптимизацию (при необходимости).

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

Таблица 2.1 Подходы к созданию моделей бизнес-процессов

Таблица 2.2 Возможные варианты моделей

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

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

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

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

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

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

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

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

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

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

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

Таблица 2.3 Нотации моделирования

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

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

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

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

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

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

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

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

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

Название/Графический символ	Описание
Рис. 2.2 Процесс	Процесс обозначается прямоугольным блоком. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом, глагольным оборотом или отглагольным существительным. Номер блока размещается в правом нижнем углу. Номера блоков используются для идентификации на диаграмме и в соответствующем тексте.
Рис. 2.3 Стрелка	Стрелки обозначают входящие и исходящие из процесса объекты (данные). Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок-стрелка. В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелки, входящие в левую сторону блока - входы. Стрелки, входящие в блок сверху - управления. Стрелки, покидающие процесс справа – выходы, т.е. данные или материальные объекты, произведенные процессом. Стрелки, подключенные к нижней стороне блока, представляют механизмы.
Рис. 2.4 Туннелированная стрелка   Рис. 2.5 Туннелированная стрелка	Туннелированные стрелки означают, что данные, передаваемые с помощью этих стрелок, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме. Стрелка, помещенная в туннель там, где она присоединяется к блоку, означает, что данные, выраженные этой стрелкой, не обязательны на следующем уровне декомпозиции. Стрелка, помещаемая в туннель на свободном конце, означает, что выраженные ею данные отсутствуют на родительской диаграмме. Туннелированные стрелки могут быть использованы на диаграммах процессов в нотациях IDEF0, Процесс, Процедура.
Рис. 2.6 Внешняя ссылка	Элемент обозначает место, сущность или субъект, которые находятся за границами моделируемой системы. Внешние ссылки используются для обозначения источника или приемника стрелки вне модели. На диаграммах Внешняя ссылка изображается в виде квадрата, рядом с которым показано наименование Внешней ссылки. Внешние ссылки могут быть использованы на диаграммах процессов в нотациях IDEF0, Процесс, Процедура.
Рис. 2.7 Междиаграммная ссылка	Элемент, обозначающий другую диаграмму. Междиаграммная ссылка служит для обозначения перехода стрелок на диаграмму другого бизнес-процесса без отображения стрелки на вышележащей диаграмме (при использовании иерархических моделей). В качестве междиаграммной ссылки не может выступать диаграмма EPC. Междиаграммные ссылки могут быть использованы на диаграммах процессов в нотациях IDEF0, Процесс, Процедура.
Рис. 2.8 Процесс-ссылка	Элемент обозначает ссылку на процесс, описанный в другой модели. Наиболее часто повторяющиеся процессы в рамках модели бизнес-процессов могут быть выделены в качестве типовых в отдельную папку в Навигаторе. Диаграмма типового процесса формируется один раз в одном месте Навигатора. Далее на любой диаграмме может быть использован процесс-ссылка на типовой процесс. Параметры типового процесса заполняются непосредственно в свойствах типового процесса. Постоянный список субъектов, принимающих участие в выполнении типового процесса, формируется также в свойствах типового процесса. Список субъектов, принимающих участие при выполнении типового процесса в рамках вышележащего процесса, формируется в свойствах процесса-ссылки на типовой процесс. Процессы-ссылки могут быть использованы на диаграммах процессов в любых нотациях.
Рис. 2.9 Сноска	Выносной элемент, предназначенный для нанесения комментариев. Элемент может быть использован на диаграммах процессов в любых нотациях.
Рис. 2.10 Текст	Комментарий без сноски. Элемент может быть использован на диаграммах процессов в любых нотациях.

Рис. 2.11 Пример диаграммы процесса в нотации IDEF0

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

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

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

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

Название/Графический символ	Описание
Рис. 2.12 Действие	Действие обозначается с помощью прямоугольного блока. Внутри блока помещается название действия. Временная последовательность выполнения действий задается расположением действий на диаграмме процесса/процедуры сверху вниз (слева направо на горизонтальной диаграмме процедуры).
Рис. 2.14 Решение   Рис. 2.15 Решение	Элемент, обозначающий выбор следующего действия в зависимости от выполнения условия. Блок «Решение» может иметь несколько входов и ряд альтернативных выходов, один и только один из которых может быть активизирован после проверки условия. Блок «Решение» должен содержать вопрос, решение или условие. Выходящие стрелки помечаются как «Да» или «Нет», или другим способом для учета всех возможных вариантов ответов. Блок «Решение» аналогичен элементу «Исключающее ИЛИ» (XOR) в других нотациях моделирования.
Рис. 2.16 Связь предшествования	Стрелки «Связь предшествования» обозначают передачу управления от одного действия к другому, т.е. предыдущее действие должно закончиться прежде, чем начнется следующее.
Рис. 2.17 Связь предшествования   Рис. 2.18 Связь предшествования	Стрелка, запускающая выполнение действия, изображается входящей в действие сверху. Стрелка, обозначающая передачу управления другому (другим) действию, изображается выходящей из действия снизу. Если стрелка служит только для обозначения передачи управления, то имя стрелки оставляется пустым. Если кроме передачи управления из предыдущего действия в следующее действие поступает Объект(ы), то стрелка именуется и в список объектов стрелки заносится соответствующий Объект(ы).
Рис. 2.19 Поток объектов Рис. 2.20 Поток объектов Рис. 2.21 Поток объектов	Стрелки «Поток объектов» используются в случаях, когда необходимо показать, что из одного действия объекты передаются в другое, при этом первое действие не запускает выполнения второго. Стрелки «Поток объектов» обозначаются стрелкой с двумя треугольниками. Если обозначение источника Объекта(ов) неважно, то такой Объект показывается стрелкой с туннелированным началом. Если источником Объекта(ов) является одно из действий процедуры/процесса, то такой Объект показывается с помощью стрелки, исходящей из действия-источника и входящей в действие-потребитель, для выполнения которого необходим Объект. При этом действие «Регистрация в журнале «Исходящая корреспонденция» не запускает выполнение действия «Заполнение графы «Номер накладной» в журнале «Исходящая корреспонденция».
Рис. 2.22 Дорожки (диаграмма Процедура)	Дорожки предназначены для отображения организационных единиц (должности, подразделения, роли) – исполнителей действий процедуры.
Рис. 2.23 Событие Рис. 2.24 Событие	События отображают стартовые точки процесса/ процедуры, приводящие к началу выполнения процесса/процедуры, и конечные точки, наступлением которых заканчивается выполнение процесса/процедуры. Началом процесса/процедуры считается событие, из которого только исходят стрелки передачи управления. Концом процесса/процедуры считается событие, в которое только входят стрелки передачи управления.

Пример диаграмм в нотациях Процесс и Процедуры приведены ниже.

Рис. 2.25 Пример диаграммы в нотации Процесс

Рис. 2.26 Пример диаграммы в нотации Процедура

Нотация EPC (Event-Driven Process Chain – событийная цепочка процессов) используется для описания процессов нижнего уровня. Диаграмма процесса в нотации EPC, представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её, а также проведена декомпозиция на более низкие уровни. Декомпозиция может производиться только в нотации EPC.

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

Название/Графический символ	Описание
Рис. 2.27 Функция	Блок представляет собой функцию – действие или набор действий, выполняемых над исходным объектом (документом, ТМЦ и прочим) с целью получения заданного результата. Внутри блока помещается наименование функции. Временная последовательность выполнения функций задается расположением функций на диаграмме процесса сверху вниз.
Рис. 2.28 Событие	Событие – состояние, которое является существенным для целей управления бизнесом и оказывает влияние или контролирует дальнейшее развитие одного или более бизнес-процессов. Элемент отображает события, активизирующие функции или порождаемые функциями. Внутри блока помещается наименование события.
Рис. 2.29 Стрелка	Стрелка отображает связи элементов диаграммы процесса EPC между собой. Связь может быть направленной и ненаправленной в зависимости от соединяемых элементов и типа связи.
Рис. 2.30 Оператор AND («И») Рис. 2.31 Оператор AND («И») Рис. 2.32 Оператор AND («И»)   Рис. 2.33 Оператор AND («И») Рис. 2.34 Оператор AND («И»)	Оператор «И» используется для обозначения слияния/ветвления как функций, так и событий. Если завершение выполнения функции должно инициировать одновременно несколько событий, то это обозначается с помощью оператора «И», следующего после функции и перед событиями. На рисунке завершение выполнения Функции одновременно инициирует события: Событие 1 и Событие 2. Если событие происходит только после обязательного завершения выполнения нескольких функций, то это обозначается с помощью оператора «И», следующего после функций и перед одиночным событием. На рисунке Событие произойдет только после обязательного завершения Функции 1 и Функции 2. Если функция может начать выполняться только после того, как произойдут несколько событий, то это обозначается с помощью оператора «И», следующего после событий и перед функцией. На рисунке Функция начнет выполняться только после того, как произойдут Событие 1 и Событие 2. Если одно событие может инициировать одновременное выполнение нескольких функций, то это обозначается с помощью оператора «И», следующего после события и перед функциями. На рисунке Событие одновременно инициирует выполнение Функции 1 и Функции 2.
Рис. 2.35 Оператор OR («ИЛИ»)   Рис. 2.36 Оператор OR («ИЛИ»)   Рис. 2.37 Оператор OR («ИЛИ») Рис. 2.38 Оператор OR («ИЛИ»)	Оператор «ИЛИ» используется для обозначения слияния/ветвления функций и для слияния событий. По правилам нотации EPC после одиночного события не может следовать разветвляющий оператор «ИЛИ». Если завершение выполнения функции может инициировать одно или несколько событий, то это обозначается с помощью оператора «ИЛИ», следующего после функции и перед событиями. На рисунке завершение выполнения Функции 1 может инициировать 3 вида ситуаций: только Событие 1, только Событие 2, одновременно и Событие 1, и Событие 2. Если событие происходит после завершения выполнения одной или нескольких функций, то это обозначается с помощью оператора «ИЛИ», следующего после функций и перед одиночным событием. На рисунке Событие может произойти либо после завершения выполнения Функции 1, либо после завершения выполнения Функции 2, либо после завершения выполнения и Функции 1, и Функции 2. Если функция может начать выполняться после того, как произойдет одно или несколько событий, то это обозначается с помощью оператора «ИЛИ», следующего после событий и перед функцией. На рисунке Функция может начать выполняться либо после того, как произойдет Событие 1, либо после того, как произойдет Событие 2, либо после того, как произойдут оба события: Событие 1, и Событие 2.
Рис. 2.39 Рис. 2.40 Оператор XOR («Исключающее ИЛИ») Рис. 2.41 Оператор XOR («Исключающее ИЛИ») Рис. 2.42 Оператор XOR («Исключающее ИЛИ»)	Оператор «Исключающее ИЛИ» используется для обозначения слияния/ветвления функций и для слияния событий. По правилам нотации EPC после одиночного события не может следовать разветвляющий оператор «Исключающее ИЛИ». Если завершение выполнения функции может инициировать только одно из событий в зависимости от условия, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего за функцией и перед событиями. На рисунке Функция инициирует либо только Событие 1, либо только Событие 2. Если событие происходит сразу после завершения выполнения либо одной функции, либо другой, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего после функций и перед одиночным событием. На рисунке Событие может произойти либо сразу после завершения выполнения Функции 1, либо сразу после завершения выполнения Функции 2. Если функция может начать выполняться сразу после того, как произойдет либо одно событие, либо другое, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего после нескольких событий и перед функцией. На рисунке Функция может начать выполняться сразу после того, как произойдет либо Событие 1, либо Событие 2.
Рис. 2.43 Интерфейс процесса     Рис. 2.44 Диаграмма Процесса 1   Рис. 2.45 Диаграмма Процесса 2	Элемент, обозначающий внешний (по отношению к текущей диаграмме) процесс или функцию. Используется для указания взаимосвязи процессов: обозначает предыдущий или следующий процесс по отношению к диаграмме рассматриваемого процесса; обозначает процесс, откуда поступил или куда передается объект. Внутри блока помещается наименование внешнего процесса. На рисунке показано, что договор является результатом выполнения процесса «Заключение договора». На рисунке показано, что после окончания Процесса 1 (и наступления Событие 1) начинает выполняться Процесс 2. На диаграмме Процесса 2 показано, что перед началом Процесса 2 был завершен Процесс 1, инициировавший Событие 1.
Рис. 2.46 Бумажный документ	Используется для отображения на диаграмме бумажных документов, сопровождающих выполнение функции. Внутри блока помещается наименование бумажного документа.
Рис. 2.47 Электронный документ	Используется для отображения на диаграмме электронных документов, сопровождающих выполнение функции. Внутри блока помещается наименование электронного документа.
Рис. 2.48 ТМЦ	Используется для отображения на диаграмме товарно-материальных ценностей (ТМЦ), сопровождающих выполнение функции. Внутри блока помещается наименование ТМЦ.
Рис. 2.49 Информация	Используется для отображения на диаграмме информационных потоков, сопровождающих выполнение функции. Внутри блока помещается наименование информационного потока.
Рис. 2.50 Информационная система	Используется для отображения на диаграмме информационной системы, поддерживающей выполнение функции. Внутри блока помещается наименование информационной системы.
Рис. 2.51 Модуль информационной системы	Используется для отображения на диаграмме модуля информационной системы, поддерживающего выполнение функции. Внутри блока помещается наименование модуля информационной системы.
Рис. 2.52 Функция информационной системы	Используется для отображения на диаграмме функции информационной системы, поддерживающей выполнение функции. Внутри блока помещается наименование функции информационной системы.
Рис. 2.53 База данных	Используется для отображения на диаграмме базы данных, сопровождающей выполнение функции. Внутри блока помещается наименование базы данных.
Рис. 2.54 Термин   Рис. 2.55 Термин	Используется для отображения на диаграмме терминов, используемых в организации и сопровождающих выполнение функции. Внутри блока помещается наименование термина. Элемент может быть также использован для обозначения статусов бумажных/электронных документов и других элементов справочника «Объекты деятельности». На рисунке статус документа «Акт выполненных работ» устанавливается с помощью термина «Подписанный».
Рис. 2.56 Набор объектов	Используется для отображения на диаграмме наборов объектов, сопровождающих выполнение функции. Внутри блока помещается наименование набора объектов.
Рис. 2.57 Прочее	Используется для отображения на диаграмме потоков объектов, которые нельзя отнести ни к одной из предопределенных групп справочника «Объекты деятельности». Внутри блока помещается наименование прочего объекта.

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

Таблица 2.7 Типы связей Процесса

Талица 2.8 Типы связей Субъекта

Таблица 2.9 Типы связей События

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

Таблица 2.11 Типы связей Документа

Элемент, с которым устанавливается связь	Тип связи
Процесс	предоставляет входные данные
Событие	устанавливает
Субъект	используе 12345678910Следующая ⇒ ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры... Что будет с Землей, если ось ее сместится на 6666 км? Что будет с Землей? - задался я вопросом... Система охраняемых территорий в США Изучение особо охраняемых природных территорий(ООПТ) США представляет особый интерес по многим причинам... Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем... Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: