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

Введение: зачем нужно описание процессов

Принято считать, что автоматизация бизнес-процессов тесно связана с их моделированием и описанием. Раньше это было отдельным крупным направлением со своими методами. Вы наверняка слышали такие аббревиатуры, как IDEF (Integrated Definition), ARIS (Architecture of Integrated Information Systems) или BPMN (Business Process Model and Notation).

Однако описание бизнес-процессов — это ценность не только для автоматизации. Это создание процессного актива — базы знаний о том, как работает или будет работать организация. Такая модель позволяет увидеть возможности для улучшения и сформировать взгляд на будущее процесса.

Три роли описания процессов в автоматизации

Если моделирование все же предпринимается для автоматизации, использовать его можно тремя способами:
1. Как источник точных знаний. При проектировании информационной системы необходимо досконально понимать устройство бизнес-процесса. Модель служит этим документированным знанием.
2. Как основу для анализа изменений. Если вы внедряете решение, опирающееся на референтную модель (типовой отраслевой шаблон), то старые процессы вас не интересуют. На основе новой модели вы оцениваете: что изменится, кого и чему нужно переобучать и какие новые требования возникнут к персоналу.
3. Как исполняемую программу. Это более радикальный подход, при котором описание процесса должно быть формально интерпретируемым. Это означает, что специальное программное обеспечение без участия человека превращает модель в работающее приложение.

Формальные нотации и BPMN

Когда модель должна стать программой, она превращается в разновидность языка программирования, который интерпретируется однозначно и автоматически. Яркий пример — нотация управления бизнес-процессами (BPMN, Business Process Model and Notation) .

Ее разработала профессиональная организация Object Management Group (OMG) . Это некоммерческий консорциум, известный также созданием унифицированного языка моделирования (UML, Unified Modeling Language) . BPMN — это очень сложная и разветвленная нотация.
Рассмотрим пример диаграммы простейшего взаимодействия пациента и врача. Пациент отправляет запрос, поликлиника отвечает. На схеме этот простой диалог изображен множеством кружков, сплошных и пунктирных стрелок. Такая детализация нужна, чтобы убрать любую двусмысленность: механический интерпретатор способен превратить эту картинку в реальную программу.

Практический взгляд и проблема выбора

Главный вопрос при описании процесса: с какой целью оно составляется и кто будет им пользоваться?

Мой практический опыт показывает, что формальные описания вроде IDEF или ARIS крайне редко решают реальные задачи для бизнес-заказчиков. Это хорошая школа для студентов или бизнес-аналитиков, но конечным пользователям такие модели дают очень мало.

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

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

Процессный взгляд и качество

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

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

Краткие итоги

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

В рамках автоматизации выделяются три уровня зрелости использования моделей. Первый, базовый уровень — модель как документация и источник требований для проектирования. Второй уровень — модель как инструмент управления изменениями и обучения при переходе на референтные процессы. Третий, наиболее технически сложный уровень, превращает модель в исходный код. Здесь возникает понятие формально исполнимой спецификации, что подводит к обсуждению BPMN. Демонстрация диаграммы визита к врачу служит не для обучения нотации, а для иллюстрации ключевого тезиса: платой за отсутствие двусмысленности и возможность автоматической интерпретации является колоссальная сложность визуального представления.

Центральным конфликтом выступает столкновение формального и текстового подходов. Выдвигается прагматичный и критический тезис: строгие нотации (IDEF, ARIS) неэффективны в коммуникации с заказчиком. Причина не в интеллектуальных ограничениях пользователей, а в фундаментальном противоречии между скоростью создания модели и динамикой изменений бизнес-среды. Время, потраченное на выверение формальной диаграммы, приводит к тому, что она становится историческим документом, а не рабочим инструментом. Истинная ценность для лица, принимающего решения, лежит в повествовательной текстовой фиксации, допускающей быстрое прототипирование и согласование.

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