Ключевые концепции моделирования бизнес-процессов
- Вопрос 1. Что такое модели процессов и для чего они применяются?
- Вопрос 2. Какие существуют взгляды на бизнес-процессы?
- Вопрос 3. Как выбирать нотации для моделирования?
- Вопрос 4. Как учитывать фреймворки и референтные модели в проекте моделирования?
- Вопрос 5. Как собирать информацию о процессе для целей моделирования?
- Вопрос 6. Кто участвует в проекте моделирования?
- Вопрос 7. Какова связь между взглядами, нотациями и уровнями моделей?
- Конспект главы
Из Свода знаний BPM CBOK 4.0
Модели процессов являются упрощенным представлением действий. Они служат средством отображения различных аспектов бизнес-процесса и применяются для описания, анализа и проектирования процессов. Модели могут отражать текущее состояние процесса, предложения по изменению и финальное состояние.
Вопрос 1. Что такое модели процессов и для чего они применяются?
Ответ
Модели процессов — это упрощённое представление действий, составляющих бизнес-процесс. Они служат средством отображения различных аспектов бизнес-процесса и применяются для широкого круга задач.
Назначение моделей процессов:
graph TD
classDef purpose fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
classDef desc fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px
subgraph "Назначение моделей процессов"
P1[Описание<br/>процессов] --> D1[Документирование того,<br/>как работа выполняется]
P2[Анализ<br/>процессов] --> D2[Выявление проблем,<br/>узких мест, потерь]
P3[Проектирование<br/>процессов] --> D3[Создание целевого<br/>состояния]
P4[Обсуждение<br/>и обучение] --> D4[Общий язык для<br/>коммуникации]
P5[Согласование] --> D5[Достижение консенсуса<br/>между заинтересованными<br/>сторонами]
P6[Формирование<br/>требований] --> D6[Основа для разработки<br/>ИТ-систем]
P7[Имитационное<br/>моделирование] --> D7[Валидация и проверка<br/>изменений]
end
class P1,P2,P3,P4,P5,P6,P7 purpose
class D1,D2,D3,D4,D5,D6,D7 desc
Состояния процесса в моделях:
graph LR
classDef state fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
classDef result fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
S1[Текущее состояние<br/>«Как есть»<br/>As-Is] --> S2[Предложения<br/>по изменению<br/>To-Be варианты]
S2 --> S3[Финальное состояние<br/>«Как будет»<br/>Target To-Be]
class S1,S2,S3 state
Применение моделей:
| Применение | Описание |
|---|---|
| Описание | Документирование текущего или целевого состояния процесса |
| Анализ | Выявление проблем, узких мест, потерь, дублирования |
| Проектирование | Создание нового или улучшенного процесса |
| Обсуждение | Общий язык для коммуникации между заинтересованными сторонами |
| Обучение | Наглядный материал для введения в должность и повышения квалификации |
| Согласование | Достижение консенсуса между разными группами |
| Формирование требований | Основа для разработки ИТ-систем и автоматизации |
| Имитационное моделирование | Валидация и проверка изменений до внедрения |
Комментарий эксперта
Игорь Владимирович Краев: «Модель — это не самоцель. Это средство для решения конкретных задач. В книге «Государство как система» Том 1 я подчёркиваю: «Сначала — карта потока, потом — показатели». Модель без цели — это просто картинка. Модель, созданная для анализа узких мест, — это инструмент управления. Всегда задавайте вопрос: «Для чего мы создаём эту модель?» Если у вас нет ответа — не моделируйте [citation:Том 1, Часть II]».
Вопрос 2. Какие существуют взгляды на бизнес-процессы?
Ответ
Процессная модель может содержать несколько уровней и отражать различные взгляды на бизнес-процесс, отличающиеся рамками, степенью детализации, целевой аудиторией и предназначением.
Три основных взгляда:
graph TD
classDef view fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
classDef desc fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px
classDef audience fill:#fff3e0,stroke:#e65100,stroke-width:2px
subgraph "Три взгляда на процессы"
V1[Взгляд предприятия<br/>Enterprise View] --> D1[Высокоуровневый взгляд<br/>на кросс-функциональные<br/>процессы]
V2[Взгляд бизнеса<br/>Business View] --> D2[Взгляд владельца процесса,<br/>бизнес-контекст, границы]
V3[Операционный взгляд<br/>Operational View] --> D3[Взгляд операционного<br/>менеджера на потоки работ]
end
V1 --> A1[Высшее руководство,<br/>стратеги]
V2 --> A2[Владельцы процессов,<br/>руководители бизнеса]
V3 --> A3[Операционные менеджеры,<br/>исполнители]
class V1,V2,V3 view
class D1,D2,D3 desc
class A1,A2,A3 audience
Сравнение взглядов:
| Взгляд | Уровень | Аудитория | Ключевой вопрос | Основное содержание |
|---|---|---|---|---|
| Предприятие | Стратегический | Высшее руководство | Чем занимается организация? | Сквозные процессы, стратегия, взаимодействие |
| Бизнес | Тактический | Владельцы процессов | Как процессы создают ценность? | Подпроцессы, функции, границы, ответственность |
| Операционный | Операционный | Менеджеры, исполнители | Как выполняется работа? | Потоки работ, действия, задачи, шаги |
Соответствие взглядов и уровней моделей:
| Взгляд | Уровень модели | Нотации |
|---|---|---|
| Предприятие | Уровень 1 | VSM, IDEF0, цепочка Портера |
| Бизнес | Уровень 2 | BPMN (descriptive), EPC |
| Операционный | Уровень 3–5 | BPMN (analytical), блок-схемы с дорожками, UML |
Комментарий эксперта
Игорь Владимирович Краев: «Разные люди видят процесс по-разному. Руководитель видит стратегию, владелец процесса видит логику, исполнитель видит свои задачи. В книге «Государство как система» Том 2 я описываю процессную команду, где каждый член команды имеет свой взгляд. Главное — чтобы эти взгляды были согласованы и интегрированы. Без этого каждый будет говорить о «своём» процессе, и у вас не будет единой картины. Репозиторий — это способ связать эти взгляды в единое целое [citation:Том 2, Глава 9]».
Вопрос 3. Как выбирать нотации для моделирования?
Ответ
Существует множество различных нотаций и методов моделирования. Выбранная нотация должна соответствовать целям проекта, задачам текущего и потребностям следующих этапов проекта.
Критерии выбора нотации:
graph TD
classDef criteria fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
classDef question fill:#fff3e0,stroke:#e65100,stroke-width:2px
subgraph "Критерии выбора нотации"
C1[Цели проекта] --> Q1[Что мы хотим получить<br/>от моделирования?]
C2[Задачи текущего<br/>этапа] --> Q2[Что нужно прямо сейчас?]
C3[Потребности следующих<br/>этапов] --> Q3["Что понадобится позже (имитация, исполнение)?"]
C4[Аудитория] --> Q4[Кто будет использовать<br/>модель?]
C5[Уровень детализации] --> Q5[Какой уровень подробности<br/>необходим?]
end
class C1,C2,C3,C4,C5 criteria
class Q1,Q2,Q3,Q4,Q5 question
Выбор нотации по целям:
graph LR
classDef goal fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
classDef notation fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
subgraph "Выбор нотации по целям"
G1[Быстрое согласование] --> N1[Блок-схемы, SIPOC]
G2[Стратегический обзор] --> N2[VSM, IDEF0, цепочка Портера]
G3[Детальный анализ] --> N3[BPMN, EPC]
G4[ИТ-требования] --> N4[UML, DMN]
G5[Автоматизация] --> N5["BPMN (executable)"]
G6[Бережливое производство] --> N6[VSM]
end
class G1,G2,G3,G4,G5,G6 goal
class N1,N2,N3,N4,N5,N6 notation
Ключевые принципы выбора нотаций:
| Принцип | Описание |
|---|---|
| Соответствие целям | Нотация должна решать задачи проекта, а не быть «модной» |
| Универсальность | Некоторые нотации более универсальны и способны удовлетворить широкий спектр потребностей |
| Комбинация нотаций | Иногда целям проекта лучше соответствует не одна нотация, а комбинация нескольких |
| Стандартизация | Использование стандартных нотаций обеспечивает долгосрочные преимущества |
Комментарий эксперта
Игорь Владимирович Краев: «Нотация — это язык. Не заставляйте бизнес-руководителей читать UML, а программистов — рисовать блок-схемы. Выбирайте нотацию под аудиторию и под задачу. В книге «Государство как система» Том 1 я использую разные нотации для разных уровней: VSM для стратегии, BPMN для анализа, UML для ИТ. Комбинируйте нотации, но будьте последовательны. И помните: нотация — это средство, а не цель [citation:Том 1, Часть II]».
Вопрос 4. Как учитывать фреймворки и референтные модели в проекте моделирования?
Ответ
Если проект должен следовать определённому фреймворку, определите требования в этой части на раннем этапе. Для определённых областей есть доступные референтные модели, способные помочь в моделировании.
Учёт фреймворков:
graph TD
classDef step fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
classDef result fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
subgraph "Учёт фреймворков в проекте"
S1[Определить требования<br/>фреймворка на раннем<br/>этапе] --> R1[Избежать переделок<br/>и несоответствий]
S2[Выбрать фреймворк<br/>под потребности<br/>организации] --> R2[TOGAF, Zachman,<br/>DoDAF, FEAF]
S3[Использовать референтные<br/>модели для типовых<br/>областей] --> R3[SCOR, APQC PCF,<br/>цепочка Портера]
end
class S1,S2,S3 step
class R1,R2,R3 result
Фреймворки и референтные модели по областям:
| Область | Фреймворк/Референтная модель | Применение |
|---|---|---|
| Архитектура предприятия | TOGAF, Zachman, DoDAF | Общая структура моделирования |
| Управление цепями поставок | SCOR | Стандартные процессы и метрики |
| Классификация процессов | APQC PCF | Единый язык, бенчмаркинг |
| Стратегический анализ | Цепочка Портера | Обзорный взгляд на бизнес |
Комментарий эксперта
Игорь Владимирович Краев: «Фреймворк — это не ограничение, это ускорение. В книге «Государство как система» Том 3 я описываю типовые процессы для всех уровней управления — это референтные модели для госсектора. Используйте готовые решения, где они есть. Не изобретайте велосипед для того, что уже стандартизировано. Но адаптируйте фреймворк под свою организацию — слепое копирование так же плохо, как и полное игнорирование [citation:Том 3, Глава 21]».
Вопрос 5. Как собирать информацию о процессе для целей моделирования?
Answer
Процедуры сбора информации сильно варьируются от проекта к проекту и могут включать произвольные комбинации методов. Приступая к проекту моделирования, команда может выбрать подход сверху-вниз, снизу-вверх или от середины.
Подходы к сбору информации:
graph TD
classDef approach fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
classDef desc fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px
subgraph "Подходы к сбору информации"
A1[Сверху-вниз<br/>Top-Down] --> D1[Начинается со стратегии,<br/>движется к деталям]
A2[Снизу-вверх<br/>Bottom-Up] --> D2[Начинается с операций,<br/>движется к стратегии]
A3[От середины<br/>Middle-Out] --> D3[Начинается с ключевых<br/>процессов, расширяется<br/>в обе стороны]
end
class A1,A2,A3 approach
class D1,D2,D3 desc
Методы сбора информации:
graph LR
classDef method fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
classDef desc fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px
subgraph "Методы сбора информации"
M1[Наблюдение] --> D1[Прямое наблюдение за<br/>реальным процессом]
M2[Интервью] --> D2[Глубинные беседы<br/>с экспертами]
M3[Опросы] --> D3[Структурированные<br/>опросники]
M4[Очные объяснения] --> D4[Групповые обсуждения<br/>и фасилитация]
M5[Онлайн-объяснения] --> D5[Веб-конференции,<br/>онлайн-сессии]
M6[Документация] --> D6[Изучение регламентов,<br/>инструкций, отчётов]
end
class M1,M2,M3,M4,M5,M6 method
class D1,D2,D3,D4,D5,D6 desc
Выбор подхода:
| Подход | Когда использовать | Преимущества | Риски |
|---|---|---|---|
| Сверху-вниз | Когда есть чёткая стратегия, нужно связать её с процессами | Стратегическая согласованность | Может не учитывать операционные реалии |
| Снизу-вверх | Когда стратегия неясна, нужно понять реальное положение дел | Операционная точность | Может не увидеть стратегическую картину |
| От середины | Когда есть ключевые процессы, которые нужно расширить | Баланс стратегии и операций | Требует больше времени на координацию |
Комментарий эксперта
Игорь Владимирович Краев: «Я рекомендую подход «от середины». Начинайте с ключевых процессов, которые создают основную ценность. Поняв их, вы можете двигаться вверх — к стратегии, и вниз — к деталям. В книге «Государство как система» я называю это «найти ограничение системы». Определите главный процесс, который создаёт проблему, разберитесь с ним, а потом расширяйтесь. И помните главное правило: «Пройди процесс ногами». Никакие интервью не заменят личного наблюдения [citation:Том 1, Часть II]».
Вопрос 6. Кто участвует в проекте моделирования?
Ответ
К участию в проекте моделирования могут привлекаться эксперты по стратегии, руководители, эксперты предметной области и аналитики различной специализации. Внедрение процесса часто требует профессиональных навыков в области управления изменениями.
Участники проекта моделирования:
graph TD
classDef role fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
classDef desc fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px
subgraph "Участники проекта моделирования"
R1[Эксперты по<br/>стратегии] --> D1[Обеспечивают связь<br/>со стратегией]
R2[Руководители] --> D2[Обеспечивают ресурсы<br/>и принимают решения]
R3[Эксперты предметной<br/>области] --> D3[Предоставляют знания<br/>о процессе]
R4[Аналитики различной<br/>специализации] --> D4[Моделируют, анализируют,<br/>документируют]
R5[Специалисты по<br/>управлению изменениями] --> D5[Обеспечивают внедрение<br/>и адаптацию]
end
class R1,R2,R3,R4,R5 role
class D1,D2,D3,D4,D5 desc
Роли в проекте моделирования:
| Роль | Функция | Когда требуется |
|---|---|---|
| Спонсор проекта | Обеспечивает ресурсы, принимает стратегические решения | Всегда |
| Руководитель проекта | Управляет сроками, бюджетом, командой | Всегда |
| Фасилитатор | Ведёт обсуждения, обеспечивает вовлечение | При групповой работе |
| Бизнес-аналитик | Собирает информацию, моделирует процессы | Всегда |
| Системный аналитик | Обеспечивает связь с ИТ-требованиями | При автоматизации |
| Эксперты предметной области | Предоставляют знания о процессе | Всегда |
| Специалист по управлению изменениями | Обеспечивает внедрение | При внедрении изменений |
Комментарий эксперта
Игорь Владимирович Краев: «Моделирование — это командная работа. В книге «Государство как система» Том 2 я описываю состав процессной команды: руководитель проекта, бизнес-аналитик, ведущий обсуждений, внутренний координатор. И к ним добавляются эксперты — люди, которые реально работают в процессе. Без экспертов модель будет красивой, но бесполезной. Без специалиста по управлению изменениями внедрение провалится. Убедитесь, что у вас есть все роли [citation:Том 2, Глава 9]».
Вопрос 7. Какова связь между взглядами, нотациями и уровнями моделей?
Ответ
Взгляды, нотации и уровни моделей взаимосвязаны и должны быть согласованы в проекте моделирования.
Связь взглядов, нотаций и уровней:
graph TD
classDef view fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
classDef level fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef notation fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
subgraph "Связь взглядов, нотаций и уровней"
V1[Взгляд<br/>предприятия] --> L1[Уровень 1] --> N1[VSM, IDEF0,<br/>цепочка Портера]
V2[Взгляд<br/>бизнеса] --> L2[Уровень 2] --> N2["BPMN (descriptive), EPC"]
V3[Операционный<br/>взгляд] --> L3[Уровни 3-5] --> N3["BPMN (analytical), блок-схемы, UML"]
end
class V1,V2,V3 view
class L1,L2,L3 level
class N1,N2,N3 notation
Сводная таблица:
| Взгляд | Уровень | Цель | Нотации | Аудитория |
|---|---|---|---|---|
| Предприятие | 1 | Стратегическое планирование | VSM, IDEF0, цепочка Портера | Высшее руководство |
| Бизнес | 2 | Управление процессами | BPMN (descriptive), EPC | Владельцы процессов |
| Операционный | 3–5 | Исполнение и автоматизация | BPMN (analytical), блок-схемы, UML | Менеджеры, исполнители, ИТ |
Комментарий эксперта
Игорь Владимирович Краев: «Связь между взглядами, нотациями и уровнями — это архитектура вашего моделирования. В книге «Государство как система» я описываю процессную иерархию: стратегическая карта → карта потока → BPMN → задачи. Каждый уровень имеет свой язык. Не путайте их: на стратегическом уровне не нужна детальная BPMN, на операционном — не нужна стратегическая карта. Используйте правильный язык на каждом уровне [citation:Том 1, Часть II]».
Конспект главы
| Раздел | Ключевая идея |
|---|---|
| Модели процессов | Упрощенное представление действий. Применяются для описания, анализа, проектирования, обсуждения, обучения, согласования, формирования требований, имитации |
| Состояния моделей | «Как есть» → варианты «как должно быть» → финальное «как будет» |
| Три взгляда | Предприятие (стратегический), бизнес (тактический), операционный (исполнительский) |
| Выбор нотаций | По целям проекта, задачам текущего и следующих этапов. Возможна комбинация нотаций |
| Фреймворки | Определить требования на раннем этапе. Использовать референтные модели для типовых областей |
| Сбор информации | Подходы: сверху-вниз, снизу-вверх, от середины. Методы: наблюдение, интервью, опросы, очные/онлайн-объяснения |
| Участники | Эксперты по стратегии, руководители, эксперты предметной области, аналитики, специалисты по управлению изменениями |
| Связь взглядов, нотаций и уровней | Взгляд определяет уровень и аудиторию, уровень определяет нотацию |
Главная мысль главы
Моделирование бизнес-процессов — это не про создание красивых картинок. Это про создание общего языка, понимания и основы для управления. Ключ к успешному моделированию — правильный выбор взгляда, нотации и уровня детализации под конкретную задачу. Модель должна отвечать на вопрос, который вы задаёте, а не быть «полной» или «правильной» в абстракции. Как сказано в книге «Государство как система»: «Методологическая культура — это способность воспринимать мир как систему взаимосвязанных процессов и управлять этой системой осознанно» [citation:Том 4, Глава 30].
Готовы систематизировать моделирование процессов в вашей организации
Мы помогаем руководителям компаний и органов власти систематизировать подход к моделированию процессов: от выбора нотаций до построения процессной иерархии и интеграции взглядов. Обучаем команды и разрабатываем корпоративные стандарты моделирования.
Запишитесь на бесплатную консультацию — проведём экспресс-диагностику вашего подхода к моделированию и покажем, как сделать его системным и эффективным.