Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Моделирование бизнес-процессов. Учебное пособие.pdf
Методология IDEF включает в себя несколько методологий модели-
рования, которые имеют графическое представление.
1. Методология IDEF0 – описывает функциональную модель, которая
складывается из структуры и функций системы, а также потоков матери-
альных и информационных объектов, которые связывают эти функции.
2. Методология IDEF1 – описывает информационную модель, кото-
рая складывается из структуры и информационных потоков, поддержива-
ющих функции системы.
3. Методология IDEF2 – описывает динамические модели, которые
отображают изменение поведения функций, ресурсов и информации во
времени.
К текущему моменту наибольшее распространение получила мето-
дология IDEF0. В основе данной методологии лежит концепция структур-
ного анализа и проектирования SADT (Structured Analysis & Design
Technique), разработанная Дугласом Т. Россом. В основу концепции зало-
жен графический язык описания (моделирования) систем, обладающий
следующими свойствами [2, с. 6]:
‒ отображение в полном объеме производственных, управленческих
и других процессов и операций предприятия на всех уровнях декомпозиции;
‒ обеспечение точного описания объектов моделирования и толкования этого описания;
‒ обеспечение взаимодействия между аналитиками, разработчиками
и заказчиком;
‒ простота в понимании и изучении;
‒ интеграция с инструментами машинной графики (например, с программным средством Design/IDEF 3.7).
Вышеописанные свойства языка сыграли значительную роль в выборе
методологии IDEF0 в качестве основного средства определения требова-
ний и функций системы, а также проектирования самой системы, отвечающей заданным требованиям и реализующей заявленные функции.
41
Визуально модель представляет собой совокупность диаграмм и фрагментов текста. Главный элемент модели – это функциональный блок,
представляющий собой активность (действие, операцию, процесс); графи-
ческим обозначением функционального блока является прямоугольник.
Блоку обязательно присваивается наименование в виде глагола или отгла-
гольного существительного, например, «Спроектировать макет», «Форми-
рование отчета». Дуги (материальные объекты или информация) предна-
значены для визуализации связей функциональных блоков с внешним
окружением и изображаются в виде линий со стрелками на конце. Дуги
могут быть нескольких типов [20, с. 18]:
1) дуги типа «вход» отображают потоки материальных и информаци-
онных объектов, необходимых для выполнения функции блока (например,
сырье, материалы);
2) дуги типа «выход» отображают потоки материальных и информа-
ционных объектов, которые являются результатом выполнения функции
(оказанная услуга, изготовленное изделие);
3) дуги типа «управление» » отображают условия и документы, ре-
гламентирующие выполнение функции (законы, нормативные акты, ре-
гламенты);
4) дуги типа «механизм» отображают ответственных за выполнение
функций, а также средства их выполнения (персонал, программное обес-
печение, оборудование).
Основной функциональный блок и назначение системы описываются
с помощью контекстной диаграммы. Контекстная диаграмма является
начальной вершиной древовидной структуры совокупности диаграмм.
В контекстной диаграмме задаются цель проектирования системы и точка
зрения, под которой следует понимать виденье системы сотрудником, от-
ветственным за моделируемую работу в целом. Благодаря контекстной
диаграмме выявляется объект моделирования. Каждая модель имеет только одну контекстную диаграмму. Контекстную диаграмму можно декомпозировать, т. е. более детально описывать ее функциональный блок. Бло-
ки, которые были получены в результате детализации основного блока,
42
также могут быть декомпозированы на более подробные блоки нижних
уровней. Таким образом, модель IDEF0 включает в себя иерархически
взаимосвязанные диаграммы верхних и нижних уровней.
Для указания положения той или иной диаграммы или блока приме-
няются номера узлов. Например, блок с нумерацией А0 на контекстной
диаграмме А0 декомпозируется на блоки с нумерацией А1, А2, А3….Аn.
Блок А1 декомпозируется на диаграмме А1 на блоки с нумерацией А11,
А12…А1n. По общим рекомендациям каждая диаграмма включает в себя
от трех до шести блоков, которые располагаются в виде «лестницы». Так,
в нотации IDEF0 реализуется принцип доминирования, который подразумевает влияние одного блока на другой с соблюдением приоритетности
выполнения по времени или важности.
Помимо отношений между блоками по принципу доминирования
в методологии IDEF0 выделяют еще пять типов отношений, а именно:
управление, выход-вход, обратная связь по управлению, обратная связь по
входу, выход – механизм.
Отношения по типам «управление» и «выход-вход» описывают прямые взаимодействия между блоками. Отношение по типу «управление»
возникает в том случае, когда выход одного блока оказывает управляющее
воздействие на другой блок с меньшим доминированием. Отношение по
типу «выход-вход» возникает при соединении выхода одного блока с входом другого блока с меньшим доминированием.
Отношения по типам «обратная связь по управлению» и «обратная
связь по входу» описывают взаимодействия, предполагающие итерации,
когда выход функции оказывает воздействие в будущем на выполнение
других функций с большим доминированием, что в свою очередь сказыва-
ется на исходной функции по истечении какого-то времени. Отношение
по типу «обратная связь по управлению» появляется в том случае, когда
выход одного блока оказывает управляющее воздействие на другие блоки
с большим доминированием. Отношение по типу «обратная связь по вхо-
ду» возникает в том случае, когда выход одного блока становится входом
для другого блока с большим доминированием [2, c. 26].
43
Отношение «выход-механизм» описывает такой тип взаимодействия
между блоками, когда выход одного блока преобразовывается в средство
достижения цели для другого блока. Данный тип связи имеет место быть
при возникновении в модели процессов распределения ресурсов, подго-
товки средств труда, приобретения оборудования и т.д.
Все вышеперечисленные типы отношений между функциональными
блоками диаграммы обозначаются стрелками. Существуют отношения
между текущей диаграммой и другими диаграммами, которые являются
внешними по отношению к текущей. Такие стрелки называются гранич-
ными. На дочерних диаграммах граничные стрелки появляются автомати-
чески, если они заданы на родительских диаграммах. Исключение состав-
ляют те граничные стрелки, которые затуннелированы. Туннелирование
стрелок осуществляется в двух случаях:
1) для того чтобы отобразить малозначимые стрелки на диаграммах
нижнего уровня, при условии отсутствия необходимости отображения
этих стрелок на родительской диаграмме (тип туннелирования «не-в-
родительской-диаграмме»);
2) для того чтобы не допустить чрезмерной загруженности диаграмм,
при условии использования стрелки родительской диаграммы во всех
функциональных блоках дочерней диаграммы без исключения (тип тун-
нелирования «не-в-дочерней-работе»).
В методологии IDEF0 применяется система маркирования, которая
позволяет специалисту точно определить связи, возникающие между диа-
граммами. Такая схема маркирования носит название ICOM-кодирования;
аббревиатура расшифровывается по первым буквам английских эквива-
лентов понятий: вход (Input), управление (Control), выход (Output) и механизм (Mechanism). ICOM-коды, однозначно идентифицирующие граничные стрелки, имеют префиксы, которые определяются типом стрелки
(I, C, O, M), а также соответствующие порядковые номера. В ICOM-коде
буква следует перед порядковым номером. В свою очередь, порядковый
номер определяет относительное положение точки соединения стрелки
с блоком родительской диаграммы. В том случае, когда блоки дочерней
44
диаграммы декомпозируются дальше, на каждую новую диаграмму необ-
ходимо установить новые ICOM-коды, которые будут связывать гранич-
ные стрелки этих диаграмм со стрелками родительских блоков. Бывают
случаи, когда буквенная часть ICOM-кода может меняться в процессе пе-
рехода с родительской диаграммы на дочернюю диаграмму. Так, стрелка
управления на родительской диаграмме может являться входом на дочер-
ней диаграмме.
Можно выделить основные правила описания модели бизнес-процессов с применением методологии IDEF0:
1. В модели должна быть описана контекстная диаграмма, которая
содержит только один блок.
2. Блоки на диаграммах должны располагаться по принципу домини-
рования.
3. Диаграммы декомпозиции могут включать от трех до шести бло-
ков, поскольку такое количество блоков позволяет поддерживать опти-
мальный уровень читаемости и понимания диаграмм.
4. Все блоки, которые были декомпозированы, должны иметь ссылки
на дочерние диаграммы.
5. Наименования функций и стрелок должны быть строго уникаль-
ными. Совпадение наименований говорит об отображении одних и тех же
данных.
6. Необходимо соблюдать максимальное расстояние между блоками
и не допускать избыточного пересечения стрелок для повышения уровня
читаемости диаграммы.
7. Каждая функция должна иметь как минимум одну стрелку по типу
«управление» и одну стрелку по типу «выход», при этом у функции может
не быть ни одной стрелки по типу «вход».
8. Слияние стрелок происходит в том случае, если они представляют
начальные данные и источник этих данных не обозначен на диаграмме.
9. Обратная связь должна быть изображена при минимальном числе
линий и пересечений.
45
10. Объединение стрелок происходит в том случае, если они имеют
один источник или приемник или эти стрелки отображают связанные
данные.
11. Присоединение стрелок к блокам лучше осуществлять в одной
и той же позиции, поскольку это упростит чтение диаграммы.
12. Необходимо применять возможности ветвящихся стрелок, чтобы
повысить уровень наглядности диаграмм.
Пример диаграммы в нотации IDEF0 представлен на рис. 3.2.
Рис. 3.2. Пример диаграммы в нотации IDEF0
Благодаря применению нотации IDEF0 при описании бизнес-процессов можно создать полноценную наглядную бизнес-модель предприятия, состоящую из связанных диаграмм и детализированных потоков
данных.
46
3.2.2. Методология моделирования EPC
Нотация EPC (Event-Driven Process Chain – цепочка процессов, управляемая событиями) была создана в 1992 году Институтом информационных систем при Саарском университете в Германии [3, с. 6]. Данная нота-
ция разрабатывалась в рамках научного исследования. Одним из главных
разработчиков являлся профессор Август-Вильгельм Шеер (основатель
компании IDS Scheer, которая выпускает программные средства семейства
ARIS). Нотация EPC построена на реализации алгоритмов взаимодействия
в процессе выполнения той или иной операции. Бизнес-процесс в данной
нотации графически представлен в виде упорядоченного графа событий
и действий. Основными элементами методологии EPC являются:
• события, начинающие и завершающие действия;
• действия (бизнес-функции), которые составляют сценарий выпол-
нения бизнес-процесса;
• операторы ветвления/слияния;
• исполнители, участники и владельцы действий;
• интерфейсы процессов;
• ресурсы и результаты выполнения действий (товарно-материальные
ценности, документы, базы данных и др.).
Благодаря наличию такого элемента как «событие», нотацию EPC
можно представить неким развитием нотации IDEF3. Событие – это свер-
шившийся факт, смысловая нагрузка которого заключается в том, что ин-
формационный объект приобретает связанный с конкретной бизнесфункцией статус, воздействующий на ход выполнения бизнес-функции.
Событие имеет свойство передавать управление от одной бизнес-функции
к другой, а также быть результатом выполнения бизнес-функции. Бизнесфункция (действие) представляет собой операцию, которую необходимо
выполнить над объектом для получения конечного результата. Последова-
тельность выполнения бизнес-функций определяется их расположением
на диаграмме. События позволяют установить начальное и конечное со-
стояния бизнес-функции, а также отношение, которое будет переводить
47
бизнес-функцию из одного состояния в другое. Поэтому события всегда
являются начальными и конечными блоками на диаграммах EPC. Моди-
фикация статуса объекта может проявиться как при первом появлении
этого объекта (например, «Получено задание на выполнение заказа»), так
и при изменении его состояния (например, «Задание на выполнение заказа
отправлено в доработку»). Бывают ситуации, когда событие может запу-
стить выполнение нескольких функций одновременно, в то же время бы-
вает так, что выполнение бизнес-функции приводит к наступлению сразу
нескольких событий. Такие циклы обработки в методологии EPC принято
отображать с помощью операторов ветвления/слияния. В нотации EPC
используется три типа операторов ветвления/слияния, каждый из которых
имеет свое предназначение:
1) оператор ветвления/слияния «XOR» – бизнес-функция может ини-
циировать наступление только одного из событий; событие может наступить в результате выполнения только одной из бизнес-функций;
2) оператор ветвления/слияния «OR» – бизнес-функция может ини-
циировать наступление либо одного из событий, либо сразу нескольких
событий; событие может наступить в результате выполнения либо одной
из бизнес-функций, либо сразу нескольких бизнес-функций;
3) оператор ветвления/слияния «AND» – бизнес-функция может ини-
циировать наступление сразу нескольких событий; событие может наступить в результате выполнения сразу нескольких бизнес-функций.
Для отображения на диаграммах EPC исполнителей, владельцев
и участников используются субъекты. Любой исполнитель, владелец или
участник представляет собой организационную единицу. К организацион-
ным единицам относятся подразделения, должности, роли внешних субъ-
ектов. Элемент «Субъект» является обязательным, поэтому каждое дей-
ствие должно соотноситься с каким-либо субъектом.
Еще одним обязательным элементом в методологии EPC считается
интерфейс процесса. Этот элемент принят для обозначения внешнего (по
отношению к текущей диаграмме) процесса или внешней бизнес-функции.
48
Интерфейс процесса применяется для того, чтобы указать характер взаи-
мосвязи между бизнес-функциями:
• обозначение предыдущей или следующей функции по отношению
к диаграмме анализируемой функции;
• обозначение функции, откуда поступает или куда передается объект.
Для повышения наглядности отображения информационных и материальных потоков используются следующие элементы: электронные
и бумажные документы, товарно-материальные ценности, базы данных
и др. Данные элементы сопровождают выполнение действий (бизнесфункций) или демонстрируют результаты их выполнения. В то же время
необходимо понимать, что использование большого количества различ-
ных объектов может повлиять на читаемость диаграммы и сделать ее че-
ресчур перегруженной. Таким образом, можно сделать вывод, что данная
нотация имеет интуитивно понятный набор элементов и позволяет описы-
вать достаточно сложные процессы нижних уровней.
Для проектирования бизнес-процессов в нотации EPC используется специализированное программное обеспечение, например система ARIS, инструменты Business Studio и Microsoft Visio. Несмотря на то, что цвета и обо-
значения второстепенных элементов в зависимости от выбранного инстру-
мента могут отличаться, общие правила реализации нотации выдержаны.
При описании бизнес-процессов нижнего уровня с применением методологии EPC можно руководствоваться следующим упрощенным алгоритмом:
1. Определение начального и конечного событий процесса;
2. Добавление действий и промежуточных событий на диаграмму
процесса;
3. Добавление документов, информации, товарно-материальных цен-
ностей, необходимых для выполнения процесса и отображения его ре-
зультатов; добавление субъектов и описание их связей с бизнесфункциями;
4. Оценка и анализ полноты исполнения описанного бизнес-процесса.
Если представлен исчерпывающий набор бизнес-функций, формируется
документ, содержащий требования к выполнению процесса; в противном
49
случае бизнес-функции, нуждающиеся в более полном описании, декомпозируются дальше.
Можно выделить основные правила описания модели бизнес-процес-
сов с применением методологии EPC:
1. Диаграмма процесса должна иметь начальное и конечное события.
Начальное событие следует за интерфейсом процесса; конечное событие
может находиться перед интерфейсом процесса.
2. Функции и события необходимо располагать на диаграмме соглас-
но принципу чередования, т. е. четкого следования друг за другом.
3. Рекомендуемое количество функций не должно превышать 20, об-
ратная ситуация может свидетельствовать о неправильном выделении
функций верхнего уровня.
4. Функции и события должны иметь по одной входящей и исходя-
щей связи для отражения хода процесса.
5. Операторы ветвления/слияния и события, которые окружают функ-
цию на текущей диаграмме, должны быть начальными/конечными собы-
тиями и операторами ветвления/слияния на диаграмме декомпозиции этой
функции.
6. Диаграмма не может содержать объектов, у которых нет ни единой
связи.
7. Оператор слияния должен иметь как минимум две входящие связи
и одну исходящую связь; оператор ветвления должен иметь только одну
входящую связь и как минимум две исходящие связи.
8. В том случае, если оператор имеет входящую связь от события, он
должен обладать исходящей связью, которая относится к функции; в слу-
чае если оператор имеет входящую связь от функции, он должен обладать
исходящей связью, которая относится к событию.
9. За одиночным событием может следовать только оператор «AND».
10. Недопустимо одновременное ветвление/слияние функции и события.
11. Оператор ветвления и оператор слияния должны совпадать по ти-
пу. Допустим вариант несовпадения типов операторов в том случае, когда
оператор ветвления имеет тип «AND», а оператор слияния – «OR».
50