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

1. 3. Моделирование бизнес процессов

2. 3.1. Определение бизнес процесса

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

3.

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

4.

• В UML бизнес процесс определяется
как набор действий (активностей),
целью которых является производство
некоторого продукта для заказчика или
рынка.

5.

• Для
моделирования
бизнес-процессов
широко используются следующие стандарты:
– IDEF0 (Integration Definition for Function Modeling);
– BPMN (Business Process Modeling Notation).
• Эти
стандарты
представляют
собой
графическую нотацию для описания и
моделирования бизнес-процессов.
• Стандарт IDEF0 реализован в таких пакетах
как IDEF0.EM Tool, IDEF0\Doctor, BPWin,
Office Visio 2007.

6. 3.2. Стандарт IDEF0

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

7.

• Применимость стандарта IDEF0:
– моделирование информационных систем
для их анализа, разработки,
реинжиниринга, интеграции и сборки;
– моделирование бизнес-процессов
предприятий для их анализа;
– моделирование процессов (методологий)
разработки программного обеспечения.

8.

• Результатом применения стандарта
IDEF0 является модель.
• Модель состоит из диаграмм, текста
и словаря терминов, имеющих
перекрестные ссылки друг на друга.
• Диаграммы - основной компонент
модели.
• Все
функции
и
взаимодействия
отображаются на диаграммах в виде
прямоугольников (функции) и стрелок
(взаимодействия).

9.

• Основные элементы стандарта IDEF0:
– функциональный блок;
– интерфейсная дуга.

10.

• Функциональный блок (Activity Box):
– изображается в виде прямоугольника;
– представляет некоторую функцию,
рассматриваемую в рамках системы;
– название функционального блока должно
иметь глагольное наклонение.

11.

• Интерфейсная дуга (Arrow):
– изображается в виде стрелки;
– обозначает элемент (объект или
документ), который обрабатывается
функциональным блоком или влияет на
функциональный блок;
– название дуги должно быть оборотом
существительного.

12.

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

13.

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

14.

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

15.

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

16.

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

17.

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

18.

Декомпозиция контекстной диаграммы

19.

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

20. 3.3. Стандарт BPMN

• BPMN
определяет
графические
элементы для моделирования бизнес
процессов. Моделью бизнес процесса
является
графическая
диаграмма,
которая состоит из активностей
(activities,
works)
и
потоков
управления (flow controls), которые
определяют
порядок
исполнения
активностей.

21.

• BPMN
предназначена
для
моделирования
только
бизнес
процессов
и
не
поддерживает
моделирование структуры организации
и функциональных требований.
• BPMN
ориентирована
на
моделирование двух базовых типов
бизнес-процессов:
– сотрудничество (collaborations) или
публичный (public) бизнес процесс;
– внутренний (internal) или частный
(private) бизнес процесс.

22.

• Сотрудничество это бизнес процесс,
которые
представляет
собой
взаимодействие нескольких участников
этого бизнес процесса.
• Частный вид сотрудничества бизнес
процесс B2B (business to business).
• Внутренний бизнес процесс это
бизнес процесс, которые происходит
внутри организации и невидим вне этой
организации.

23.

• Графические элементы BPMN:
– элементы потока (flow elements);
– соединительные элементы (connecting
elements);
– разделители (swimlanes);
– артефакты (artifacts).

24. Элементы потока

• Активность или действие (activity) –
это работа, которая исполняется внутри
бизнес процесса.
• Обозначения для активности:

25.

• Событие
(event)
–
это
что-то
происшедшее во время исполнения
бизнес процесса и повлиявшее на
последовательность
или
продолжительность активностей.
• Различаются три типа событий:
– начальное (start);
– промежуточное (intermediate);
– конечное (end).

26.

• Обозначения событий:

27.

• Слияния-разъединения (gateway) –
используются
для
слияния
и
разъединения
потока
активностей.
Различаются следующие типы слиянийразъединений:
– слияние-разъединение (gateway)
– ветвление-соединение (fork / join);
– inclusive decision / merge

28.

• Обозначение слияний-разъединений:

29.

• Соединительные элементы включают
три типа соединений:
– последовательности потока (sequence
flow) – показывает последовательность
исполнения активностей бизнес процесса;
– потока сообщений (message flow) –
показывает поток сообщений между
участниками бизнес процесса;
– ассоциации (association) – используется
для соединения информации и артефактов
с объектами бизнес процесса.

30.

• Обозначение соединительных
элементов:

31.

• Разделители включают элементы двух
типов:
– пулы (pools) – это соглашения между
предпринимателями для устранения
конкуренции, здесь отдельная часть бизнес
процесса;
– подразделения (lanes) – это части пула
для организации активностей внутри пула.

32.

• Обозначаются подразделения
следующим образом:

33.

• Артефакты
объектов:
включают
три
типа
– объекты данных (data objects) – это
объекты, которые содержат информацию о
бизнес-процессе, но на исполнение бизнес
процесса не влияют;
– группы (groups) – используются для
группирования объектов в бизнеспроцессе;
– аннотации (annotations) – объекты для
представления дополнительной
информации о бизнес-процессе.

34.

• Обозначение артефактов:

35. Пример бизнес процесса с нормальным потоком

36. Пример бизнес процесса с пулами

37. 3.4. Моделирование бизнес процессов в UML

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

38. Профиль Эрикссона-Пенкера для моделирования бизнес процессов в UML

39.

• Для моделирования бизнес процессов в
системе SPARX EA используется
профиль Эриксонна-Пенкера (EricssonPenker),
в
котором
определены
следующие стереотипы:
– для активности определен стереотип
<<Business process>> - бизнес процесс;
– для объектов, которые инициируют
исполнение бизнес процесса, определен
стереотип <<Event>> - событие.

40.

• - для связи бизнес-процесса с объектами, от которых
зависит его исполнение, определены следующие
стереотипы для отношения зависимости:
– <<goal>> цель – связывает бизнес процесс с причиной, изза которой организация выполняет бизнес процесс;
– <<supply>> обеспечить – связывает бизнес процесс с
объектами, которые содержат информацию для обеспечения
исполнения бизнес процесса;
– <<input>> ввод – связывает бизнес процесс с объектами,
которые используются (обрабатываются) в процессе
исполнения бизнес процесса.
– <<output>> вывод – отмечает объекты, которые являются
результатом исполнения этого бизнес процесса;
– <<control>> управление – связывает бизнес процесс с
объектами, которые управляют бизнес процессом.

41. Пример бизнес-процесса разработки программной системы

analysis Analysis v iew
Удовлетворение
требований
заказчика
«goal»
Спецификация
программной
системы
Разработка программной
системы
«output»
«input»
«supply»
Разработчики
«supply»
Средства
разработки
Программная
система