Стандарты графического описания БП

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

· Семейство стандартов IDEF (в частности, IDEF0, DFD, IDEF3);

· Семейство стандартов ARIS (в частности, нотация eEPC);

· Семейство стандартов UML (Usecase diagram, activity diagram).

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

Методология	Программное обеспечение
IDEF	AllFussion Business Modeler (BPwin), MS Visio
ARIS	ARIS Toolset
UML	Rational Rose, MS Visio, ARIS Toolset
BPMN	BizAgi Modeler, BizAgi Studio, Elma

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

Кроме этого, на практике часто встречаются модели БП, подготовленные с использованием шаблона Audit diagram в программе MS Visio.

IDEF

Стандарт моделирования бизнес-процессов IDEF0 был принят в качестве такового в 1981 году. Исторически он возник из стандарта SADT (Structured Analysis and Design Teqnique), активно применявшегося с конца 60-х годов, в частности, Министерством обороны США. IDEF является аббревиатурой от ICAM DEFinition. ICAM - Integrated Computer Aided Manufacturing.

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

· IDEF0 – стандарт описания бизнес-процессов;

· DFD – диаграмма потока данных (DataFlow Diagram);

· IDEF3 – стандарт моделирования потока работ (workflow).

 

ARIS

ARIS расшифровывается как Arhitecture of Integrated Information Systems (архитектура интегрированных информационных систем). В методологию ARIS входит пять типов представлений моделей:

· Организационные модели, описывающие иерархическую структуру системы: иерархию организационных подразделений, должностей, полномочий конкретных лиц и т.д.;

· Функциональные модели, описывающие функции (процессы, операции), выполняемые в организации;

· Информационные модели (модели данных), отражающие структуру информации, необходимой для реализации всей совокупности функций системы;

· Модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели;

· Модели входов и выходов, описывающие потоки материальных и нематериальных входов и выходов процедур, включая, в частности, потоки денежных средств.

В каждом из этих типов моделей есть ряд нотаций, отличающихся методами моделирования, и число этих нотаций довольно велико. В частности, ARIS Toolset поддерживает ряд нотаций языка моделирования UML (Unified Modeling Language).

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

Нотация ARIS eEPC расшифровывается следующим образом: Extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В таблице ниже приводятся основные используемые в рамках нотации графические объекты.

 

Наименование	Описание	Графическое представление
Функция	Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.
Событие	Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций
Организационная единица	Объект, отражающий различные организационные звенья предприятия (например, управление или отдел)
Документ	Объект, отражающий реальные носители информации, например бумажный документ
Прикладная система	Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции
Кластер информации	Объект характеризует данные, как набор сущностей и связей между ними. Используется для создания моделей данных
Стрелка связи между объектами	Объект описывает тип отношений между другими объектами, например – активацию выполнения функции некоторым событием
Логическое «И»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса
Логическое «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса
Логическое исключающее «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса

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

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

На рисунке видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:

· Каждая функция должна быть инициирована событием и должна завершаться событием;

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

Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демо-версией продукта.

На рисунке ниже показано применение различных объектов ARIS при создании модели бизнес-процесса.

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

Из рисунка видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.

Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций).

UML

Аббревиатура UML расшифровывается как Unified Modeling Language (унифицированный язык моделирования).

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

Язык UML был создан в компании Rational одним из ведущих идеологов объектно - ориентированного подхода к программированию Гради Бучем (Grady Booch), совместно с Джимом Рамбо (Jim Rumbaugh) и Иваром Джекобсоном (lvar Jacobson) в 1994 году.

UML включает в себя ряд типов диаграмм, некоторые из которых могут быть использованы для моделирования бизнес-процессов. В частности, это диаграмма прецедентов (Use-case diagram) и диаграмма действий (Activity Diagram).

Диаграмма прецедентов служит для моделирования типичных сценариев работы с системой.

Диаграмма прецедентов состоит из прецедентов (use-case) - типичных взаимодействий между пользователем и компьютерной системой - и субъектов (actor) - ролей, которые пользователи играют относительно системы. Также на ней могут быть указаны отношения между прецедентами: связь расширения (extends) и связь использования (uses).

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

Выбор нотации моделирования

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

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

 

IDEF0.

В основе методологии IDEF0 лежат три основных понятия:

· Функциональный блок (Activity Box);

· Интерфейсная дуга (Arrow);

· Декомпозиция (Decomposition);

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

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

· Верхняя сторона имеет значение “Управление” (Control);

· Левая сторона имеет значение “Вход” (Input);

· Правая сторона имеет значение “Выход” (Output);

· Нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

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

 

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую “деталь” на входе в функциональный блок “Обработать на токарном станке” не имеет смысла отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных “концептуальных” интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение “туннеля” (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из “туннеля”) только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока – приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии – в таком случае, они сначала “погружаются в туннель”, а затем, при необходимости “возвращаются из туннеля”.

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

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.

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

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

· Ограничение количества подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя.

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

Очень важно при построении модели четко обозначить цель (purpose) и точку зрения (viewpoint) модели.

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

Точка зрения также влияет на содержание модели. Модель БП с точки зрения главного инженера и с точки зрения главного бухгалтера будут существенно различаться. Точка зрения – это своего рода «фильтр» для процесса.

DFD.

В основе нотации DFD лежат следующие понятия:

· Работа;

· Дуга;

· Внешняя ссылка;

· Хранилище данных.

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

Дуги. Дуги (стрелки) идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота.

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

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

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

IDEF3.

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

Основные объекты нотации IDEF3:

· Функциональный элемент/элемент поведения;

· Стрелка (линия);

· Перекресток (junction).

Функциональный элемент (элемент поведения – Unit of Behavior) – обозначает событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы.

Стрелки или линии являются отображением перемещения элементов (документов, материальных предметов) между UOB-блоками в ходе процесса.

Линии бывают следующих видов:

· Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз.

· Отношения (Relational Link)- пунктирная линия, использующаяся для изображения связей между UOB

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

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

Обозначение	Наименование	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
	Asynchronous AND	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
	Synchronous AND	Все предшествующие процессы завершены одновременно	Все следующие процессы запускаются одновременно
	Asynchronous OR	Один или несколько предшествующих процессов должны быть завершены	Один или несколько следующих процессов должны быть запущены
	Synchronous OR	Один или несколько предшествующих процессов завершаются одновременно	Один или несколько следующих процессов запускаются одновременно
	XOR (Exclusive OR)	Только один предшествующий процесс завершен	Только один следующий процесс запускается

Все перекрестки на диаграмме нумеруются.

Простейший пример диаграммы в нотации IDEF3 приводится ниже.