Моделирование бизнес-процессов

1. МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ

МОДЕЛИРОВАНИЕ БИЗНЕСПРОЦЕССОВ

2. Вопросы:

1. Эволюция подходов к моделированию и управлению бизнеспроцессами.
2. Понятие моделирования бизнес-процессов.
3. Методология функционального моделирования IDEF0.
4. Диаграмма потока данных DFD.
5. Нотации Процесс и Процедура.
6. Нотация EPC.

3. Эволюция подходов к моделированию и управлению бизнес-процессами

Первая волна:
Фредерика Тейлора «Принципы научного управления».
Используются блок-схемы, ориентированные графы, сети Петри, методологии
SADT, IDEF, DFD.
Попытки автоматизации бизнес-процессов.
Вторая волна:
M. Хаммера и Д. Чампи «Реинжиниринг корпорации: манифест революции в
бизнесе».
Появление систем управления потоками работ WfMS (Workflow Management
Systems) 2-го поколения.
Третья волна:
Г. Смит и П. Фингар «Управление бизнес-процессами: третья волна».
Появление систем управления бизнес-процессами BPMS.
Стремление к стандартизации.

4. Эволюция подходов к моделированию и управлению бизнес-процессами

Третья волна
Вторая волна Первая волна
Моделирование бизнес-процессов
Совершенствование деятельности
Использование ИТ
1920–80-е гг. Анализ способов выполнения 1980-е
гг.
Всеобщее
управление
работ. Рационализация трудовых операций. качеством. Непрерывность изменений.
Модели на бумаге. Низкая автоматизация
Научный подход. Последовательное
совершенствование
1990-е гг. ПО для построения диаграмм и
анализа процессов в статике. Ручной
реинжиниринг.
Единовременное
создание
модели. Автоматизация: КИС с поддержкой
потоков работ (WfMS, ERP)
2000-е гг. Ориентированное на бизнеспроцессы
ПО.
Исполняемые
модели.
Итеративная
оптимизация.
Средства
моделирования интегрированы в BPMS.
Имитационное моделирование и анализ
моделей в динамике. Конвертирование моделей.
Стандартизация методологий
1970–90-е гг. Система управления
базами
данных.
Совместное
использование
данных.
Приложения, обращающиеся к
базам данных
1990-е гг. Реинжиниринг бизнес- 1990-е
гг.
Распределенные
процессов. Дискретность изменений.
вычисления.
Совместное
Ненаучный
подход.
Радикальное использование
функций.
преобразование
Распределенные приложения
2000-е
гг.
Управление
бизнеспроцессами (BPM). Непрерывность
изменений. Гибкость, адаптивность.
Научный
подход.
Итеративное
совершенствование
2000-е гг. Системы управления
бизнес-процессами.
Совместное
исполнение
бизнес-процессов.
Распределенные бизнес-процессы

5.

6. Методологии построения исполняемых моделей разрабатываются и выпускаются организациями по стандартизации и международными

консорциумами:
OASIS (Organization for the Advancement of Structured Information Standards):
в спецификации ebXML и BPEL, стандарты для электронного бизнеса на
базе XML и веб-сервисов;
OMG (Object Management Group): стандарты BPMN и UML, MDA и CORBA;
W3C (World Wide Web Consortium): стандарты WS-CDL, WSCI, спецификации
XML, технологии веб-сервисов;
WfMC (Workflow Management Coalition): стандарты Wf-XML и XPDL.
Изначально методологии BPML и BPMN были созданы консорциумом
BPMI.org (Business Process Management Initiative), дальнейшее развитие
BPML было прекращено в пользу BPEL, в 2005 г. произошло слияние
BPMI.org с OMG, и в настоящее время работы над BPMN ведутся в рамках
OMG.

7. Пояснение:

• Язык BPML дополняет язык реализации бизнес-процессов (Business Process Execution Language,
сокр. BPEL). BPML может использоваться для определения детальных бизнес-процессов,
исполняемых при вызове каждого web-сервиса. BPML преобразует («мэппирует») бизнесоперации в обменные сообщения. Этот язык может использоваться для определения
корпоративных бизнес-процессов, комплексных web-сервисов и многостороннего
сотрудничества. В разработке BPML-спецификаций участвует целый ряд организаций: CSC,
Intalio, SAP, Sun, SeeBeyond, Versata и др.
• UML (Unified Modeling Language — унифицированный язык моделирования) —
язык графического описания для объектного моделирования в области разработки
программного обеспечения, моделирования бизнес-процессов, системного проектирования и
отображения организационных структур.
• Концепция MDA (Model Driven Architecture) призвана обеспечить общую основу для описания и
использования большинства существующих стандартов, не ограничивая разработчиков в
выборе конкретных технологий.
• CORBA (Common Object Request Broker Architecture — общая архитектура брокера объектных
запросов; типовая архитектура опосредованных запросов к объектам) — технологический
стандарт написания распределённых приложений, продвигаемый консорциумом (рабочей
группой) OMG и соответствующая ему информационная технология.
• Web Services Choreography Description Language (WS-CDL). Спецификация предназначена для
создания сценариев взаимодействия Web-сервисов в рамках общего бизнес-протокола.

8. Современный этап

Технологии автоматизации межкорпоративного взаимодействия:
бизнес-бизнес (Business-to-Business, B2B);
ebXML (Electronic Business using extensible Markup Language, ISO 15000).
Наращивание функционала систем Workflow.
Переход от задач описания процессов к задачам совершенствования по
параметрам стоимости, качества и времени выполнения.
Использование системы сбалансированных показателей (BSC — Balanced
ScoreCard) для обеспечения контроля результативности через наборы
ключевых показателей результативности (KPI — Key Performance
Indicators).

9. Понятие моделирования бизнес-процессов

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

10. Понятие моделирования бизнес-процессов

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

11. Понятие моделирования бизнес-процессов

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

12. Понятие моделирования бизнес-процессов

Модель, как правило, содержит следующие сведения о бизнес-процессе:
набор составляющих процесс шагов – бизнес-функций;
порядок выполнения бизнес-функций;
механизмы контроля и управления в рамках бизнес-процесса;
исполнителей каждой бизнес-функции;
входящие документы/информацию, используемые каждой бизнесфункцией;
исходящие документы/информацию, генерируемые каждой бизнесфункцией;
ресурсы, необходимые для выполнения каждой бизнес-функции;
документацию/условия, регламентирующие выполнение каждой бизнесфункции;
параметры, характеризующие выполнение бизнес-функций и процесса в
целом (KPI).

13. Понятие моделирования бизнес-процессов

Подходы к построению
моделей БП
Структурообразующий
элемент
Функциональный
Объектноориентированный
бизнес-функция,
действие,
операция
объект
(клиент, заказ,
услуга)

14. Понятие моделирования бизнес-процессов

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

15. Понятие моделирования бизнес-процессов

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

16. Понятие моделирования бизнес-процессов

17. Методология функционального моделирования IDEF0

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

18. Методология функционального моделирования IDEF0

1960-х гг. Дуглас Росс (Массачусетский технологический институт, компания SoftTech):
методология структурного анализа и проектирования SADT (Structured Analysis and
Design Technique).
конец 1970-х гг. Министерство обороны США, программа интегрированной
компьютерной поддержки производства ICAM (Integrated Computer-Aided
Manufacturing): принята значительная часть SADT.
в 1970-х гг. появился целый набор таких методов под общим названием IDEF
(первоначально ICAМ DEFinition, затем Integrated DEFinition).
1981 г. Технология SADT, переименованная в IDEF0, получила статус федерального
стандарта США (последняя редакция выпущена Национальным Институтом По
Стандартам и Технологиям США NIST – National Institute of Standards and Technology в
1993 г.,).

19. Методология функционального моделирования IDEF0

IDEF0 – методология функционального моделирования, снабженная наглядным
графическим языком и позволяющая представить моделируемую систему в виде
набора взаимосвязанных функций. Как правило, является первым этапом
изучения системы;
IDEF1 – методология моделирования информационных потоков внутри
системы, позволяющая отображать и анализировать их структуру и
взаимосвязи;
IDEF1X (IDEF1 eXtended) – методология построения реляционных структур.
Относится к типу методологий «сущность-взаимосвязь» (Entity-Relationship –
ER) и, как правило, применяется для моделирования реляционных баз данных,
имеющих отношение к рассматриваемой системе;

20. Методология функционального моделирования IDEF0

IDEF3 – методология описания процессов, происходящих в системе. Описывает
сценарий и последовательность операций для каждого процесса. Близка к
алгоритмическим методам построения схем процессов и стандартным средствам
построения блок-схем (построение блок-схемы в программе MS Word);
IDEF4 – методология объектно-ориентированного проектирования. Реализует
объектно-ориентированный анализ больших систем, предоставляя пользователю
графический язык для изображения классов, диаграмм наследования, таксономии
методов;
IDEF5 – методология онтологического исследования сложных систем. Систему можно
описать с помощью определенного словаря терминов и правил, на основании которых
могут быть сформированы достоверные утверждения о состоянии рассматриваемой
системы в некоторый момент времени. На базе этих утверждений формируются
выводы о дальнейшем развитии системы и производится ее оптимизация.

21. Методология функционального моделирования IDEF0

Элемент – функциональный блок.

22. Методология функционального моделирования IDEF0

Элемент – стрелка (интерфейсная дуга).
Стрелки могут быть:
Входящие Input – вводные, которые ставят определенную задачу (вход).
Исходящие Output– выводящие результат деятельности (выход)
Управляющие (сверху вниз) Control– механизмы управления (положения, инструкции и
др.).
Механизмы (снизу вверх) Mechanism
– используется для того, чтобы произвести необходимую работу (обеспечение,
ресурсы).
Каждая сторона четырехугольника определяет тип стрелки.
Каждая стрелка на дочерней диаграмме должна соответствовать стрелкам на
родительской диаграмме.

23. Методология функционального моделирования IDEF0

Граничные стрелки
помечаются с
помощью ICOMметок:
Input,
Control,
Output,
Mechanism.

24. Методология функционального моделирования IDEF0

Принципы моделирования:
− функциональной декомпозиции;
− ограничения сложности;
− контекста.

25. Принцип декомпозиции

Родительская диаграмма
Дочерняя диаграмма

26. Ограничение сложности

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

27. Принцип контекста

Моделирование бизнеспроцесса начинается с
построения контекстной
диаграммы.
На диаграмме отображается
только один блок – главная
бизнес-функция
моделируемой системы.
Данные о
преподавателе
и учебных
дисциплинах
Нормативные
документы
Планировать учебную
нагрузку
преподавателя
А0
Сотрудники
кафедры
Спланированная
учебная нагрузка
преподавателя

28. Методология функционального моделирования IDEF0

Нумерация диаграмм:
Происходит сверху вниз
— от диаграммы
верхнего уровня к
диаграммам нижнего
уровня.
Каждая диаграмма
нижнего уровня
получает свой номер на
основе номера
родительской
диаграммы верхнего
уровня.

29. Методология функционального моделирования IDEF0

Ветвление и
слияние стрелок

30. Методология функционального моделирования IDEF0

Туннелирование

31.

Рамка
(каркас)
диаграммы

32. Методология функционального моделирования IDEF0

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

33. Методология функционального моделирования IDEF0

Построение модели:
Шаг 1. Построение модели «как есть».
Шаг 2. Определение бизнес-правил.
Шаг 3. Построение модели «как должно быть».
Шаг 4. Распределение ресурсов.

34. Методология функционального моделирования IDEF0

Определение
бизнес-правил

35. Методология функционального моделирования IDEF0

Направлена на анализ функциональных аспектов и позволяет
ответить на вопрос: «Что делает система?».
Подходит для описания бизнес-процессов верхнего уровня и
позволяет отразить управление процессами, обратные связи и
информационные потоки.
Существует целый ряд программных инструментов,
поддерживающих функциональное моделирование в стандарте
IDEF0:
BPwin и ERwin, ERwin Process Modeler (Computer Associates),
IDEF0.EM Tool (ИП Ориентсофт), Design/IDEF (MetaSoftware).

36. Методология функционального моделирования IDEF0

37. Диаграмма потоков данных DFD

DFD (Data Flow Diagram, 1979 г.) представляет иерархию функциональных процессов,
связанных потоками данных.
Цель — продемонстрировать, как каждый процесс преобразует свои входные данные в
выходные, а также выявить отношения между этими процессами.
Как и в IDEF0, основу методологии DFD составляет графический язык описания
процессов.
Используется при построении функциональной модели TO-BE.
Распространенные графические нотации DFD:
Йордана – Де Марко (Эд Йордан (Yourdon) и Том де Марко (DeMarko));
Гейна Сарсона (Gane Sarson).

38. Диаграмма потоков данных DFD

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

39. Диаграмма потоков данных DFD

DFD должна наглядно ответить на вопросы:
- из чего состоит информационная система?
- что нужно, чтобы обработать информацию?

40. Диаграмма потоков данных DFD

Элементы:
1. Процесс (англ. Process), т.е. функция или последовательность действий,
которые нужно предпринять, чтобы данные были обработаны.
2. Внешние сущности (англ. External Entity). Любые объекты, которые не
входят в систему, но являются для нее источником информации либо
получателями какой-либо информации из системы после обработки
данных.
3. Хранилище данных (англ. Data store). Внутреннее хранилище данных
для процессов в системе.
4. Поток данных (англ. Data flow). В нотации отображается в виде
стрелок, которые показывают, какая информация входит, а какая
исходит из того или иного блока на диаграмме.

41.

Графические
элементы DFD

42.

Нотация
Гейна Сарсона

43.

44. Диаграмма потоков данных DFD

Требования к оформлению процесса:
• Каждая функция (процесс) должна иметь идентификатор;
• Название процесса нужно формулировать согласно формуле:
Название процесса = Действие + Объект, над которым действие
осуществляется
Например, если эта работа связана с действием по продаже продукции, то
ее нужно назвать <Продать продукцию>.
• Название работы должно быть по возможности кратким и состоять из 23 слов.

45. Диаграмма потоков данных DFD

Требования к оформлению потока:
• Название потока нужно формулировать согласно формуле:
Название потока = Объект, представляющий поток + Статус объекта
Если речь идет о продукции, которую отгрузили клиенту, то поток можно
назвать <Продукция, отгруженная> или <Продукция, отгруженная
клиенту>. В данном случае <Продукция> это объект, представляющий
поток, а <отгруженная клиенту> — статус объекта.
• Название должно быть по возможности кратким и состоять из 2-3 слов.

46. Диаграмма потоков данных DFD

Требования
нумерации:
Внешние сущности
(External Entity).
Хранилище данных
(Data store).

47. Диаграмма потоков данных DFD

Требования к построению:
• Нет ограничения по количеству элементов, которые могут находиться на одной диаграмме.
Чем больше элементов на диаграмме, тем сложнее ее читать. Рекомендация: количество
процессов на диаграмме не должно быть больше семи.
• Имеет смысл строить DFD-диаграмму линейно, с выделением уровней функций, сущностей,
хранилищ.
• Каждый процесс должен иметь хотя бы один вход и один выход.
• Процесс обработки данных должен иметь внешнюю входящую стрелку (данные от внешней
сущности).
• Стрелки не могут связывать напрямую хранилища данных, все связи идут через процессы.
• Все процессы должны быть связаны либо с другими процессами, либо с другими
хранилищами данных. Процессы не существуют сами по себе, а потому результат должен
куда-то передаваться.

48. Диаграмма потоков данных DFD

Основной принцип построения – принцип декомпозиции.
DFD-модель включает в себя три документа, которые ссылаются друг на
друга:
1.Графические диаграммы.
2.Миниспецификация.
3.Словарь данных.

49. Диаграмма потоков данных DFD

50. Диаграмма потоков данных DFD

Шаг 1. Построение контекстной диаграммы.
Уровень системы

51. Диаграмма потоков данных DFD

Шаг 1. Построение контекстной диаграммы.
В некоторых случаях стоит построить несколько контекстных диаграмм с
иерархией:
• наличие большого количества внешних сущностей (десять и более);
• распределенная природа системы;
• многофункциональность системы с уже сложившейся или выявленной
группировкой функций в отдельные подсистемы.

52. Диаграмма потоков данных DFD

Шаг 2. Детализация подсистем на контекстной диаграмме.
Правила:
• балансировки — при детализации процесса дочерняя диаграмма в
качестве внешних источников/приемников данных может иметь только
те компоненты (подсистемы, процессы, внешние сущности, накопители
данных), с которыми имеет информационную связь соответствующий
процесс на родительской диаграмме;
• нумерации — при детализации процессов должна поддерживаться их
иерархическая нумерация.
• семи — для того, чтобы диаграмма легко читалась, количество функций
на диаграмме не должно быть больше семи. Например, процессы,
детализирующие процесс с номером 12, получают номера 12.1, 12.2,
12.3 и т.д.

53. Диаграмма потоков данных DFD

Шаг 2. Детализация подсистем на контекстной диаграмме.
Уровень подсистемы

54. Диаграмма потоков данных DFD

Шаг 2. Детализация подсистем на контекстной диаграмме.
Уровень процесса

55. Диаграмма потоков данных DFD

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

56. Диаграмма потоков данных DFD

Шаг 3. Миниспецификация.
Требования:

57. Диаграмма потоков данных DFD

Шаг 4. Создание Словаря данных.
Определенным образом организованный список всех элементов данных системы с их
точными определениями, что дает возможность различным категориям пользователей (от
системного аналитика до программиста) иметь общее понимание всех входных и
выходных потоков и компонент хранилищ.
Определения элементов данных в словаре осуществляются:
• описанием значений потоков и хранилищ, изображенных на DFD;
• описанием композиции агрегатов данных, движущихся вдоль потоков, т.е. комплексных
данных, которые могут расчленяться на элементарные символы (например, АДРЕС
ПОКУПАТЕЛЯ содержит ПОЧТОВЫЙ ИНДЕКС, ГОРОД, УЛИЦУ и т.д.);
• описанием композиции групповых данных в хранилище;
• специфицированием значений и областей действия элементарных фрагментов
информации в потоках данных и хранилищах;
• описанием деталей отношений между хранилищами.

58. Диаграмма потоков данных DFD

Шаг 4. Создание Словаря данных.
Определяются структура и содержание всех потоков данных и хранилищ
данных, которые присутствуют на диаграммах.
Для каждого потока в словаре хранятся: имя потока, тип, атрибуты.
Например, при моделировании документооборота вводятся сведения о
структуре и реквизитном составе документов.

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

Нотация Basic FlowChart (BFC, Процесс, простая блок-схема) применяется
для моделирования отдельных процессов компании, а также на
нижнем уровне модели бизнес-процессов, например, совместно с IDEF0.
Представляет алгоритм выполнения процесса и является нотацией
класса workflow.
Позволяют задать причинно-следственные связи и временную
последовательность выполнения действий процесса.
1921 г. – американский инженер Франк Банкер Гилбрет представил
первый структурированный метод для документирования потоков
процесса (flow process chart) для членов Американского общества
инженеров-механиков (American Society ofMechanical Engineers , ASME).

60. Нотация Процесс

Графические элементы нотации BFC:
Начало процесса/ Конец процесса
Ручной процесс
Автоматизированный процесс.
Бумажный документ. В каждом блоке этого типа, помимо названия, должен быть обязательно указан код
печатного документа. В отдельной таблице, прилагаемой к диаграмме, по коду должны восстанавливаться
шаблон и процедуры заполнения печатной формы.
Ручной (с клавиатуры, сканера) ввод данных в автоматизированную систему. Блок этого типа должен
обязательно иметь связь с блоком типа 7 с указанием соответствующей подсистемы и т.д.
Автоматизированная система, электронное хранилище данных. В тексте блока такого типа обязательно должно
быть указано название Модуля, Подсистемы, Системы и т.д.
Решение (выбор). Текст в этом блоке должен предполагать ответы «Да» или «Нет». Отступление допускается,
если при этом вопрос и варианты ответов становятся более понятными (например, возможен вопрос: «Как
клиент оплачивает заказ?»-и варианты ответа: «Наличными», «Через банк»).
Архив. Значок размещается в том подразделении, где ведется архив.
Соединитель страниц. Если символ находится в конце страницы, он должен содержать номер следующей
страницы. Если значок расположен в начале – указывается номер предыдущей страницы.
Соединитель с другим процессом. Должен содержать код процесса (указывается в заголовке диаграммы перед
именем процесса).

61. Нотация Процесс

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

62. Нотация Процесс

Требования к построению BFC:
Если две или более линий объединятся в
одну, то место объединения должно быть
смещено.
Вместо одного символа с соответствующим
текстом могут быть использованы несколько
символов с перекрытием изображения.
Выходящие из блоков документы не должны
теряться.
Рекомендуемое количество блоков на
диаграмме ≤ 30.

63. Нотация Процесс

Преимущества BFC
Недостатки BFC
Простота и наглядность Ограниченное число
описания
графических элементов
Быстрое описание
процесса
Не требует специальных
знаний

64. Нотация Процедура

Нотация Cross Functional Flowchart (CFC, Процедура , функциональная
блок-схема, кросс-функциональная схема, перекрестно-функциональная
диаграмма) отображает процесс на нижнем уровне бизнес-модели.
Разработана в 1990-ых гг. на основе диаграмм, которые использовались
для представления алгоритмов и описания логики компьютерных
программ.
Процедура отображает детальный алгоритм выполнения бизнеспроцесса, участников бизнес-процесса и их взаимодействие в рамках
Процедуры.

65. Нотация Процедура

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

66. Нотация Процедура

Графические элементы CFC:

67. Нотация Процедура

Преимущества CFC
Недостатки CFC
Простота и наглядность описания Ограниченное число графических
элементов
Быстрое описание процесса
Отсутствие визуальных значков
для моделирования движения
документов и статусов
Не требует специальных знаний Невозможность экспорта
моделей в BPMS для
автоматизации
Интеграция с IDEF0 по потокам
объектов

68. Нотация CFC

69. Нотация EPC

Нотация Event-Driven Process Chain (EPC, событийная цепочка процессов)
используется для описания процессов на разных уровнях.
Представляет упорядоченную комбинацию событий и функций.
Для каждой функции могут быть определены начальные и конечные
события, участники, исполнители, материальные и документальные
потоки, сопровождающие её.
Может быть проведена декомпозиция (например, в нотациях EPC или
BPMN).
Нач. 1990-ых гг. – EPC-метод разработан Августом-Вильгельмом Шеером
(August-Wilhelm Scheer) в рамках работ над созданием методологии ARIS
(Architecture of Integrated Information Systems, Архитектура
интегрированных информационных систем).
Методология EPC существует в разных интерпретациях (ARIS, Microsoft
Visio, Business Studio, Bflow).

70. Нотация EPC

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

71. Нотация EPC

Основные графические элементы EPC:
Оператор
AND ("И")
Оператор "И" используется для обозначения слияния/ветвления
как функций, так и событий.
Оператор
OR
("ИЛИ")
Оператор "ИЛИ" используется для обозначения
слияния/ветвления функций и для слияния событий.
Оператор
XOR
("Исключа
ющее
ИЛИ")
Оператор "Исключающее ИЛИ" используется для обозначения
слияния/ветвления функций и для слияния событий

72. Нотация EPC

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

73. Нотация EPC

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

74. Нотация EPC

Основные графические элементы EPC:
База
данных
Используется для отображения на диаграмме базы данных,
сопровождающей выполнение функции. Внутри блока
помещается наименование базы данных.
Термин
Используется для отображения на диаграмме объектов,
сопровождающих выполнение функции. Наименования этих
объектов - термины, используемые в организации.
Набор
объектов
Используется для отображения на диаграмме наборов объектов,
сопровождающих выполнение функции, например,
"Документация по проекту". Внутри блока помещается
наименование набора объектов.
Прочее
Используется для отображения на диаграмме потоков объектов,
которые нельзя отнести ни к одной из предопределенных групп
справочника "Объекты деятельности". Внутри блока помещается
наименование прочего объекта.

75. Нотация EPC

Основные графические
элементы EPC:

76. Нотация EPC

Основные графические элементы EPC:
https://sites.google.com/site/anisimovkhv/learning/pris/lecture/tema8/tema
8_3
http://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeli
ng/epc_notation

77. Нотация EPC

Типы связей между объектами на диаграмме процесса в нотации EPC
(http://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeli
ng/epc_notation):
• процесса;
• субъекта;
• программного продукта;
• документа;
• базы данных;
• информации;
• товарно-материальных ценностей (ТМЦ);
• терминов;
• операторов.

78. Нотация EPC

Правила моделирования:
1. Диаграмма функции должна начинаться как минимум одним
стартовым событием) и завершаться как минимум одним конечным
событием.
2. События и функции по ходу выполнения процесса должны
чередоваться. Решения о дальнейшем ходе выполнения процесса
принимаются функциями.
3. Рекомендуемое количество функций на диаграмме – не более 20. Если
количество функций диаграммы значительно превышает 20, то
существует вероятность, что неправильно выделены процессы на
верхнем уровне и необходимо произвести корректировку модели.
4. События и функции должны содержать строго по одной входящей и
одной исходящей связи, отражающей ход выполнения процесса.

79. Нотация EPC

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

80. Нотация EPC

Правила моделирования:
6. На диаграмме не должны присутствовать объекты без единой связи.
7. Каждый оператор слияния должен обладать хотя бы двумя входящими
связями и только одной исходящей, оператор ветвления - только одной
входящей связью и хотя бы двумя исходящими. Операторы не могут обладать
одновременно несколькими входящими и исходящими связями.
8. Если оператор обладает входящей связью от элемента "событие", то он
должен обладать исходящей связью к элементу "функция" и наоборот.
9. За одиночным событием не должны следовать операторы OR или XOR.
10. Операторы могут объединять или разветвлять только функции или только
события. Одновременное объединение/ветвление функции и события
невозможно.
11. Оператор, разветвляющий ветки, и оператор, объединяющий эти ветки,
должны совпадать. Допускается также ситуация, когда оператор ветвления
AND, оператор объединения OR .

81. Нотация EPC

Допустимые ситуации

82. Нотация EPC

Недопустимая ситуация

83. Нотация EPC

Алгоритм построения диаграммы:
Шаг 1. Определить начальное и конечное события.
Шаг 2. Добавить действия и соответствующие им промежуточные
события.
Шаг 3. Присоединить документы и (или) информацию, которая
необходима для выполнения каждого этапа (входы) и документы,
которые являются результатами работы на каждом этапе (выходы).
Добавить связи с исполнителями и с обозначением ролей.
Распространенная роль – «выполняет».
Другие: «утверждают результат», «отвечает за техническую часть»,
«должен быть уведомлен о нестандартном завершении» и т.п.
Шаг 4. Оценить полноту и качество схемы. Проанализировать,
все ли варианты исполнения процесса учтены в схеме.

84. Нотация EPC

Алгоритм построения диаграммы:
Пример первого шага

85. Нотация EPC

Алгоритм построения диаграммы:
Пример второго шага

86. Нотация EPC

Алгоритм построения диаграммы:
Пример третьего шага

87. Нотация EPC

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

88. Степень детализации процесса в нотациях