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

Моделируем бизнес-процессы AS-IS и TO-BE так, чтобы руководители, исполнители и ИТ одинаково понимали ход работы. Схема становится основой для анализа, регламента, обучения и требований к автоматизации — а не декоративной картинкой, которую никто не использует.

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

Когда нужно описание процессов

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

Что мы моделируем

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

AS-IS фиксирует реальный процесс, включая ручные обходы и возвраты. TO-BE описывает согласованный целевой порядок и условия перехода. Между ними находится анализ проблем и решений; простое перерисовывание стрелок не является оптимизацией.

Как собираются данные

1. Определяем цель модели и границы процесса.
2. Изучаем документы, формы, отчёты и используемые системы.
3. Интервьюируем владельца и представителей разных ролей.
4. Разбираем реальные экземпляры процесса, включая исключения.
5. Готовим черновик и проводим совместную верификацию.
6. Согласуем модель, словарь и вопросы, требующие решения.

Мы не полагаемся только на утверждённый регламент или мнение одного руководителя. Фактический маршрут проверяется с исполнителями и на примерах документов, иначе модель повторит формальную картину.

BPMN без учебникового перегруза

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

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

Что получает заказчик

• перечень и границы процессов;
• схемы AS-IS и/или TO-BE согласованного уровня;
• карточки процессов с входами, результатами и владельцами;
• матрицу ролей и ответственности;
• словарь терминов, статусов и данных;
• перечень разрывов, спорных вопросов и исключений;
• регламент или рабочую инструкцию при необходимости;
• требования и пользовательские сценарии для автоматизации.

Формат передачи согласуется заранее: редактируемые исходники, экспорт для публикации и правила дальнейшего ведения. Заказчик должен иметь возможность обновлять модели после завершения проекта.

Практический пример

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

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

Что влияет на срок и стоимость

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

Архитектура процессов компании

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

Декомпозиция должна сохранять связь уровней: элемент верхней карты раскрывается отдельной схемой, а показатели нижнего процесса поддерживают результат родительского. Каталог содержит название, назначение, владельца, вход, выход, клиента, показатели и связанные документы. Это создаёт управляемую архитектуру, а не папку с несогласованными диаграммами.

От модели к регламенту и автоматизации

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

Если модель должна исполняться процессным движком, технический аналитик проверяет поддерживаемые элементы нотации, обработку ошибок и версионирование экземпляров. Бизнес-модель при этом можно сохранить более простой и связать с исполняемой реализацией.

Поддержание моделей в актуальном состоянии

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

Типовые ошибки

Стандарт моделирования

До массовой работы согласуем короткий стандарт: уровни и границы, правила именования, допустимые элементы, оформление ролей и систем, обязательные атрибуты и порядок согласования. В стандарт входят хорошие и плохие примеры. Это важнее выбора конкретного редактора: разные аналитики должны создавать сопоставимые модели.

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

Форматы совместной работы

Для известного локального процесса достаточно интервью и сессии верификации. Сквозной поток лучше моделировать на совместном воркшопе представителей функций: спорные места становятся видны сразу, а решения фиксируются отдельно от фактов AS-IS. Большой каталог создаётся волнами, начиная с карты и пилотной области.

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

Критерии готовности модели

У схемы есть цель и аудитория; границы и уровень обозначены; владелец и участники подтвердили фактический поток; исключения не спрятаны; термины согласованы; редактируемый исходник передан; назначен ответственный за изменение. Для TO-BE дополнительно подтверждаются полномочия, данные, системные возможности и план перехода.

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

Частые вопросы

Обязательно ли использовать BPMN?

Нет. BPMN нужна для подробной логики взаимодействия. Для карты или простой инструкции может быть понятнее другой формат.

Вы описываете AS-IS или сразу TO-BE?

Зависит от задачи. При существующем сложном процессе AS-IS помогает не потерять реальные ограничения. Для нового процесса можно начинать с TO-BE и явно фиксировать предположения.

Модель заменяет регламент?

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

Можно использовать модели для разработки?

Да, но к бизнес-модели добавляются данные, интерфейсы, права, нефункциональные требования и критерии приёмки.

Кто согласовывает результат?

Владелец процесса принимает модель, руководители подтверждают ответственность, исполнители проверяют фактическую применимость, ИТ — системные границы.

Получить понятную модель процесса

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

Обсудить задачу