2026_01_25_ОМБП_Презентация_Лекция_1_Введение_в_моделирование_БП

1.

Федеральное государственное бюджетное образовательное учреждение высшего образования «Российский
государственный аграрный университет – МСХА имени К.А.Тимирязева»
Факультет: Институт экономики и управления АПК
Кафедра: Прикладная информатика
Дисциплина «Основы моделирование бизнес-процессов»
Лекция 1
Введение в моделирование бизнес-процессов
Основные учебные вопросы:
1. Зачем моделировать процессы: ценность для бизнеса и ИТ?
2. Понятия: процесс, подпроцесс, функция, регламент, кейс; классификация процессов.
3. Подходы и уровни моделирования: AS-IS / TO-BE, верхний уровень → детализация.
4. Нотации: BPMN (основа), кратко IDEF0/IDEF3, EPC; правила «хорошей» BPMN-схемы.
5. Мини-кейс: «Обработка заказа» (разбор границ + черновая модель).
6. Заключение.
1

2. Зачем моделировать процессы: ценность для бизнеса и ИТ?

Моделирование бизнес-процессов — это способ сделать работу
организации “видимой”: договориться, кто что делает, в какой
последовательности, по каким правилам и с каким результатом. Пока
процесс существует только «в головах» сотрудников, он управляется
плохо: знания теряются, ответственность размывается, решения
принимаются на основе отдельных мнений, а не общей картины.
Процессная модель фиксирует реальность и становится общей точкой
опоры для бизнеса и ИТ.
Зачем моделировать бизнес-процессы:
1) Прозрачность и единое понимание “как работает организация”;
2) Управляемость: ответственность, владелец процесса и контроль;
3) Оптимизация: поиск потерь, узких мест и дублирующих действий
4) Основа для автоматизации и постановки требований к ИТ-системам;
5) Стандартизация и регламентация: “работаем одинаково”;
6) Улучшение качества и снижение ошибок;
7) Управление изменениями: проще внедрять новое;
8) Обучение и передача знаний (особенно при текучести);
9) Измеримость и процессные KPI;
10) Комплаенс, аудит, безопасность;
11) Типовые ситуации, где моделирование даёт быстрый эффект.

3. Понятия: процесс, подпроцесс, функция, регламент, кейс; классификация процессов

Бизнес-процесс — это устойчивый (повторяемый) набор
взаимосвязанных действий, который преобразует вход
(заявку/данные/ресурсы/материал) в выход (результат), имеющий
ценность для клиента процесса (внешнего или внутреннего),
выполняемый по определённым правилам и подлежащий
измерению по показателям эффективности.
Основные элементы процесса:
- Триггер (событие-инициатор) — что запускает процесс: поступил
заказ, пришёл платёж, получена заявка, наступил срок.
- Вход — документы/данные/ресурсы, требуемые для выполнения.
- Действия/операции — шаги, преобразующие вход в выход.
- Решения — развилки (“если/то”), определяющие сценарий.
- Выход — результат процесса.
- Клиент — потребитель результата.
- Роли/исполнители — кто выполняет шаги.
- Ресурсы — люди, ИС, оборудование, бюджет, время.
- Контрольные точки — проверки качества, согласования, этапы
утверждения.
- Метрики/KPI — как оценивается эффективность процесса.
На вводном уровне достаточно, чтобы описать процесс формулой:
“Триггер → входы → последовательность действий с решениями →
выход → клиент + роли + метрики”.
Базовые понятия и классификация процессов
1. Что такое бизнес-процесс: определение и признаки.
2. Основные элементы процесса: “скелет” для
моделирования.
3. Процесс, подпроцесс, операция: уровни
детализации.
4. Чем бизнес-процесс отличается от похожих понятий.
5. Границы процесса: почему это ключ к корректной
модели.
6. Типы процессов по назначению (классическая
классификация).
7. Классификация процессов по уровню управления и
масштабу.
8. Классификация по степени стандартизации и
вариативности.
9. Классификация по степени автоматизации.
10. Процессные роли: владелец, участники, клиенты.
11. Показатели процесса: что измеряют и зачем.

4. Подходы и уровни моделирования: AS-IS / TO-BE, верхний уровень → детализация

Подход и уровни моделирования:
1. Подход к моделированию: от цели к модели.
2. Принцип “от общего к частному” (top-down) и обратный
путь (bottom-up).
2.1. Top-down (сверху вниз).
2.2. Bottom-up (снизу вверх).
3. Методика моделирования: типовой алгоритм (сквозной).
Шаг 1. Определить границы процесса.
Шаг 2. Определить участников и ответственность.
Шаг 3. Собрать сценарии процесса.
Шаг 4. Описать поток работ (последовательность).
Шаг 5. Зафиксировать входы/выходы и данные
Шаг 6. Определить метрики процесса.
Шаг 7. Верифицировать модель.
Шаг 8. Зафиксировать модель как артефакт.
4. AS-IS и TO-BE: ключевой подход к изменениям.
4.1. AS-IS (как есть).
4.2. TO-BE (как должно быть).
4.3. Разрыв (Gap) и план перехода.
5. Уровни моделирования: зачем они нужны.
6. Уровень 0: карта процессов организации (Process
Landscape).
7. Уровень 1: модель процесса верхнего уровня (end-to-end).
Подход и уровни моделирования:
8. Уровень 2: детализация подпроцессов.
9. Уровень 3: процедуры, инструкции, рабочие шаги.
10. Как выбирать уровень детализации (практические критерии).
1) Аудитория
2) Цель
3) Сложность и вариативность
4) Измеримость
11. Декомпозиция процессов: как “резать” правильно.
12. Горизонтальное и вертикальное моделирование.
13. Варианты представления: “модель процесса” и “модель
взаимодействий”.
14. AS-IS → TO-BE: подходы к улучшению процессов.
15. Связь уровней моделирования с автоматизацией и данными.
- Уровень 0–1: помогает определить контуры автоматизации
(какие процессы трогаем).
- Уровень 2: формирует требования к workflow, ролям, статусам,
интеграциям, данным.
- Уровень 3: превращается в инструкции, сценарии тестирования,
обучение пользователей.
16. Типовые ошибки в подходе и уровнях моделирования (как
предупреждение).

5. Нотации: BPMN (основа), кратко IDEF0/IDEF3, EPC; правила «хорошей» BPMN-схемы

Наиболее применяемые нотации в учебной и
промышленной практике (BPMN, IDEF0/IDEF3, EPC, UML
Activity), их сильные и слабые стороны, типовые области
применения и критерии выбора:
1. Зачем вообще разные нотации
Бизнес-процесс можно описать разными способами, потому
что разные нотации фокусируются на разных аспектах:
- Поток работ (workflow): последовательность шагов,
решения, параллельность, роли → BPMN, UML Activity, EPC
- Функциональная структура “что делаем”:
входы/выходы/управление/ресурсы → IDEF0
- Сценарии и последовательности “как происходит” (часто для
фиксации AS-IS) → IDEF3, BPMN
- Роли и взаимодействия участников (сообщения, границы
организаций) → BPMN Collaboration
- Документы и события (событийно-ориентированный взгляд)
→ EPC .
2. Критерии выбора нотации (главное “почему”)
2.1 Цель моделирования.
2.2 Кто читатель модели.
2.3 Уровень детализации.
2.4 Нужна ли автоматизаци.
2.5 Сложность процесса.
3. BPMN 2.0 — основной “язык процессов” для потока работ.
3.1. BPMN 2.0 — основной “язык процессов” для потока
работ.
3.2. Что BPMN описывает лучше всего?
3.3. Минимальный набор BPMN, достаточный для обучения
(уровень “введение”).
3.4. Сильные стороны BPMN.
3.5. Ограничения и риски BPMN.
3.6. Когда BPMN — лучший выбор.
4. IDEF0 — функциональная модель “что делаем и чем”
4.1. Суть IDEF0.
4.2. Где IDEF0 полезен.
4.3. Сильные стороны IDEF0.
4.4. Ограничения IDEF0.
5. IDEF3 — сценарии и “как это происходит”.
5.1. Суть IDEF3.
5.2. Где полезен IDEF3.
5.3. Плюсы и минусы.
6. EPC (Event-driven Process Chain) — события + функции
(ARIS-традиция).
6.1. Суть EPC.
6.2. Где EPC удобна.
6.3. Ограничения EPC

6. Нотации: BPMN (основа), кратко IDEF0/IDEF3, EPC; правила «хорошей» BPMN-схемы (продолжение)

Наиболее применяемые нотации в учебной и
промышленной практике (BPMN, IDEF0/IDEF3, EPC, UML
Activity), их сильные и слабые стороны, типовые области
применения и критерии выбора:
7. UML Activity Diagram — “процессы” глазами разработчика.
7.1. Когда UML Activity используют.
7.2. Плюсы UML Activity.
7.3. Минусы для бизнес-процессов.
8. Принцип комбинирования нотаций: «в каждой задаче свой
инструмент».
На практике часто строят набор взаимосвязанных моделей, а
не одну:
- Карта процессов / верхний уровень: IDEF0 или упрощённая
карта процессов
- End-to-end процесс и подпроцессы: BPMN
- Регламент/инструкции: текст + чек-лист + ссылки на BPMN
- ИТ-требования: BPMN + спецификация данных/статусов +
интеграции
Важно подчеркнуть: комбинирование — не признак слабости,
а признак зрелого подхода.
9. Что выбирать в учебных работах (рекомендации для курса)
Чтобы студентам было понятно, можно закрепить “стандарт
курса”:
- Уровень 0: карта процессов (простая схема или IDEF0контекст)
- Уровень 1–2: BPMN-модель процесса (основной сценарий +
1–2 альтернативы)
- Уровень 3: описание процедуры / чек-лист (если требуется)
Такой стандарт помогает унифицировать отчёты и критерии
оценки.
10. Нотация и аудитория: как обеспечить читаемость.
10.1. Правило “одна схема — одна мысль”.
10.2. Ограничение объёма.
10.3. Именование элементов.
10.4. Минимум “украшений”.
11. Типовые ошибки при выборе нотации
- Выбор нотации по принципу “самая сложная = самая
профессиональная”.
- Попытка описать последовательность в IDEF0 .
- BPMN без ролей (без дорожек).
- Слишком много событий/исключений в основной схеме.
- - Неправильные шлюзы.
12. Нотация и автоматизация: когда модель становится
“требованием”.
13. Практические примеры выбора нотации (чтобы “почему”
стало очевидным).

7. BPMN (Business Process Model and Notation)

BPMN (Business Process Model and Notation) —
стандартизированная графическая нотация для моделирования
бизнес-процессов. Разработана Object Management Group (OMG)
в 2004 году, в 2010 году дополнена — появилась BPMN 2.0.
С помощью BPMN можно моделировать как простые процессы —
согласование заявки или отправку уведомления, так и сложные,
включающие параллельные потоки, условия и взаимодействие
между разными подразделениями.
Некоторые элементы нотации BPMN:
Пул — представляет отдельного участника процесса,
например, компанию или подразделение. Если модель описывает
взаимодействие с клиентами или подрядчиками, каждый из них
может быть выделен в отдельный пул.
Задача — конкретное действие, которое выполняется
на каком-то шаге процесса. Например: «Обработать заказ»,
«Согласовать документ», «Выписать счёт».
Шлюз — элемент логики, позволяющий разветвлять
или объединять потоки. Используется для реализации условий
(например, если заказ больше 100 000, требуется одобрение
руководства).
События — показывают, что происходит в процессе —
когда он начинается, заканчивается или меняется. Выделяют три
ключевых вида событий:
o
Стартовое — то, с чего начинается любой
процесс.
o
Конечное — то, чем заканчивается процесс.
o
Промежуточное — всё, что происходит по ходу
процесса.
Артефакты — данные, которые используются или
появляются в рамках процесса, например, документы,
письма или базы данных.
Потоки — показывают порядок выполнения
этапов: от получения заявки к формированию товара,
затем — к отправке результата.

8. IDEF0 (Integration Definition for Function Modeling)

IDEF0 (Integration Definition for Function Modeling) — методология
функционального моделирования и одноимённая графическая
нотация. Изначально создана в рамках программы ICAM (Integrated
Computer Aided Manufacturing) для ВВС США, целью которой было
улучшение производственных процессов.
В отличие от процедурных схем, IDEF0 делает акцент не на
последовательности операций, а на логике преобразования входов
в выходы с учётом управляющих факторов и механизмов
исполнения.
Структура
В нотации IDEF0 используются блоки (прямоугольники) —
представляют функции или процессы, и стрелки — показывают
взаимосвязи между функциями и объектами.
Стрелки в IDEF0 имеют четыре основных типа:
Входы (Input) — данные или объекты, преобразуемые
функцией.
Выходы (Output) — результаты выполнения функции.
Механизмы (Mechanism) — ресурсы, используемые для
выполнения функции.
Управления (Control) — условия или правила,
определяющие выполнение функции.
Блоки располагаются в виде дерева:
Верхний уровень (A-0) — контекстная
диаграмма, показывающая основную функцию.
Уровень A0 — основная диаграмма с
главной функцией и её окружением.
Декомпозиции A0, A1, A2… —
детализация функций на более низкие уровни.

9. EPC (Event-driven Process Chain)

EPC (Event-driven Process Chain) — нотация для моделирования
бизнес-процессов, ориентированная на события и функции.
Визуализирует процессы как цепочку событий, соединённых
функциями, которые эти события вызывают или преобразуют.
В основе EPC лежат три ключевых элемента:
1.События — отражают состояния или изменения, инициирующие
выполнение функций. Примеры: «заказ получен», «отчёт
сформирован».
2.Функции — представляют собой конкретные действия или задачи,
выполняемые в рамках процесса. Например: «проверить заказ»,
«создать накладную».
3.Логические операторы — определяют последовательность
выполнения функций в зависимости от условий и событий.
Используются операторы «И», «ИЛИ», «исключающее ИЛИ».
Некоторые правила построения диаграммы EPC:
•Диаграмма должна начинаться как минимум одним стартовым
событием и завершаться как минимум одним конечным событием.
•События и функции по ходу выполнения процесса должны
чередоваться. Решения о дальнейшем ходе выполнения процесса
принимаются функциями.
•События и функции должны содержать строго по одной входящей
и одной исходящей связи, отражающей ход выполнения процесса.
•Операторы могут объединять или разветвлять только
функции или только события — одновременное
объединение/ветвление функции и события невозможно.
•Сложные процессы рекомендуется разбивать на более
мелкие и легко понятные подпроцессы, чтобы не
перегружать главную диаграмму.
•Соблюдать стандарты обозначений EPC для обеспечения
однозначного понимания нотации.

10. UML Activity Diagram (диаграмма активностей, диаграмма деятельности)

UML Activity Diagram (диаграмма активностей, диаграмма
деятельности) — это поведенческая диаграмма в нотации Unified
Modeling Language (UML). Она отображает динамические аспекты
поведения системы, показывает, как поток управления переходит от
одной деятельности к другой.
Некоторые элементы диаграммы активностей в UML:
Начальное состояние (Initial Node) — отмечает начало
выполнения процесса, обозначается заполненным чёрным кругом.
Действие (Action) — конкретное действие или задача в
процессе, обозначается прямоугольником со скруглёнными углами.
Поток управления/переход (Control Flow) — показывает
направление выполнения процесса, обозначается стрелкой.
Решение/ветвление (Decision Node) — точка выбора между
несколькими вариантами развития процесса, обозначается ромбом.
Объединение (Merge Node) — слияние нескольких веток в
одну, позволяет вернуться к общему сценарию после выполнения
альтернативных путей.
Параллельное выполнение (Fork Node) — разделяет процесс
на несколько параллельных действий, обозначается линией, из которой
выходят несколько стрелок.
Синхронизация (Join Node) — слияние нескольких
параллельных процессов в один поток, обозначается линией, в которую
входят несколько стрелок.
Объектный поток (Object Flow) — передача
данных между действиями, обозначается пунктирной
стрелкой.
Конечное состояние (Final Node) —
завершение процесса, обозначается кругом с
вложенным чёрным кругом.

11.

БОЛЬШОЕ СПАСИБО ЗА ВАШЕ ВНИМАНИЕ
Контакты
д.т.н. Потапов Борис Васильевич
Тел. +7(916) 990-34-76
E-mail: potapovb@mail.ru
11