Описание бизнес-процессов для бизнес-аналитика

Роль бизнес-аналитика и цели описания процессов

Зачем бизнес-аналитику уметь описывать процессы

Бизнес-аналитик (БА) помогает организации понять, согласовать и улучшить то, как выполняется работа. Большая часть этой работы происходит вокруг бизнес-процессов — повторяющихся цепочек действий, которые превращают вход (запрос, данные, материалы) в выход (результат, услугу, продукт).

Когда процесс не описан, он существует только в головах людей. Это приводит к типичным проблемам:

разные сотрудники выполняют «один и тот же» процесс по-разному

ожидания бизнеса и возможности ИТ не совпадают

сложно оценить сроки и стоимость изменений

ошибки повторяются, потому что непонятно, где именно «ломается» процесс

Описания процессов делают работу компании наблюдаемой и обсуждаемой: появляется общий язык для бизнеса, ИТ, руководителей и исполнителей.

Что такое «описание бизнес-процесса»

Описание бизнес-процесса — это структурированное представление:

цели процесса

границ (где начинается и где заканчивается)

участников и их ответственности

шагов и правил выполнения

входов и выходов

используемых систем и данных

вариантов (исключений), рисков и контрольных точек

Описание может быть в разных формах:

текстовый регламент или инструкция

таблица (шаг — исполнитель — вход — выход)

схема/диаграмма процесса

комбинация нескольких видов

Важно: диаграмма сама по себе — не цель. Цель — добиться понимания и согласия всех ключевых участников.

Роль бизнес-аналитика в работе с процессами

Бизнес-аналитик не «рисует схемы», а управляет пониманием процесса.

Основные обязанности бизнес-аналитика

выявлять, как процесс реально выполняется сейчас (как есть)

фиксировать проблемы и причины (узкие места, ошибки, лишние шаги)

согласовывать единое видение процесса между участниками

проектировать улучшенный процесс (как должно быть) вместе с бизнесом

переводить изменения процесса в требования к ИТ-системам и регламентам

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

!БА как связующее звено между бизнесом, ИТ и другими стейкхолдерами

Кто такие стейкхолдеры

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

Задача БА — учесть их цели и ограничения, а также обеспечить согласование.

Цели описания процессов

Цели зависят от контекста проекта. Один и тот же процесс можно описывать по-разному, если меняется цель.

Прозрачность и единое понимание

Описания помогают договориться о базовых вещах:

что является началом и концом процесса

кто что делает и за что отвечает

какие результаты считаются правильными

Это особенно важно, когда процесс проходит через несколько подразделений.

Улучшение и оптимизация

Чтобы улучшать, нужно сначала увидеть текущую картину.

Типовые направления улучшений:

убрать лишние шаги и ожидания

снизить количество ошибок и возвратов

автоматизировать рутинные действия

перераспределить ответственность

Автоматизация и внедрение ИТ-решений

Очень часто описания процессов нужны для:

внедрения CRM/ERP/ECM и других систем

разработки или доработки внутренних сервисов

интеграций между системами

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

Регламентация и соответствие требованиям

Некоторые процессы описывают, чтобы:

выполнить внутренние стандарты качества

обеспечить соответствие аудиту и проверкам

снизить операционные риски

В таких случаях особенно важны контрольные точки, роли, правила и фиксация решений.

Уровень детализации: что считать «достаточно подробно»

Правильная детализация — это та, которая позволяет достичь цели без лишней сложности.

Практический ориентир:

для обсуждения с руководителями обычно нужна обзорная схема и ключевые метрики

для исполнителей — понятные шаги, роли, входы/выходы и исключения

для ИТ — события, правила, данные, интеграции, варианты и ошибки

Признак чрезмерной детализации: диаграмма превращается в «простыню», которую никто не читает и не может согласовать.

Признак недостаточной детализации: участники согласны «в целом», но при уточняющих вопросах выясняется, что они понимают шаги по-разному.

«Как есть» и «как должно быть»

В процессной работе часто используют два состояния:

As-Is (как есть) — реальная текущая работа, включая обходные пути

To-Be (как должно быть) — целевой процесс после улучшений

Зачем нужны оба:

As-Is помогает понять причины проблем и реальные ограничения

To-Be задаёт направление изменений и основу для требований, регламентов и обучения

Важно не путать: To-Be — это не «идеально на бумаге», а реалистично с учётом ограничений (люди, бюджет, сроки, законодательство, ИТ-ландшафт).

Что именно описывает бизнес-аналитик: ключевые элементы процесса

Ниже — базовый «чек-лист» элементов, которые обычно фиксируют.

| Элемент | Что это означает | Пример вопроса БА | |---|---|---| | Цель процесса | ради чего существует процесс | «Какой результат считаем успехом?» | | Триггер (событие старта) | что запускает процесс | «Что должно произойти, чтобы началась работа?» | | Результат (выход) | что получаем на выходе | «Каким должен быть итоговый артефакт/статус?» | | Границы | что входит и не входит | «Где заканчивается ответственность команды?» | | Роли | кто участвует и за что отвечает | «Кто принимает решение/утверждает?» | | Шаги | последовательность действий | «Что делаем до/после проверки?» | | Правила | условия и политики | «В каких случаях отклоняем заявку?» | | Исключения | нестандартные ветки | «Что делаем, если данных нет/ошибка?» | | Системы и данные | где выполняется работа и что используется | «В какой системе создаём заявку и какие поля обязательны?» |

Качество описания процесса: признаки хорошей работы

Хорошее описание процесса обычно:

понятно целевой аудитории (бизнесу и/или ИТ)

имеет явные границы, роли и результат

согласовано со стейкхолдерами и не противоречит реальности

содержит правила и исключения, критичные для результата

поддерживает цель (оптимизация, автоматизация, регламент и т.д.)

Ключевой критерий для БА: описание должно позволять принять решение (что менять, что автоматизировать, как измерять успех).

Нотации и стандарты: что важно знать на старте

В этом курсе мы будем опираться на практичные подходы к описанию, а не только на «красивые схемы». Тем не менее, полезно понимать, что существуют стандарты.

BPMN (Business Process Model and Notation) — распространённая нотация для схем процессов (события, задачи, шлюзы, дорожки ролей). Спецификацию поддерживает OMG.

BABOK — свод знаний по бизнес-анализу от IIBA; полезен для понимания роли БА, техник и результатов.

Полезные источники:

BPMN 2.0.2 (OMG)

IIBA и BABOK

Как будет устроен курс дальше

Чтобы научиться корректно описывать процессы, мы последовательно пройдём путь, который повторяется в реальных проектах:

постановка цели и определение границ процесса

выявление участников и сбор информации (интервью, наблюдение, документы)

описание As-Is: шаги, роли, правила, исключения

моделирование и оформление (текст, таблицы, диаграммы)

согласование и валидация с участниками

проектирование To-Be и связь с требованиями к изменениям

В следующей статье мы начнём с практической базы: как выбирать границы процесса, определять начало/конец и не смешивать несколько процессов в одном описании.

Сбор информации: интервью, наблюдение, анализ документов

Зачем бизнес-аналитику «добывать факты», а не «рисовать процессы»

В предыдущей статье мы говорили, что задача бизнес-аналитика — добиться общего понимания процесса As-Is (как есть) и подготовить основу для улучшений и требований. Для этого нужно сначала собрать достоверную информацию о том, как работа устроена в реальности.

Главная ошибка новичка: описывать процесс по представлениям одного человека или по «официальному регламенту», не проверяя, как процесс выполняется на самом деле. Поэтому в процессной работе используется триангуляция — подтверждение фактов минимум из двух независимых источников: люди (интервью), реальная работа (наблюдение), следы процесса (документы и данные).

!Триангуляция источников для точного описания процесса

Подготовка к сбору информации

Определите цель и границы

Ещё до интервью и наблюдений зафиксируйте минимальный контекст:

цель описания (оптимизация, автоматизация, регламентация)

начало и конец процесса (границы ответственности)

ожидаемый результат описания (например: схема + таблица шагов + список проблем)

Если границы не определены, сбор информации расползётся: вместо одного процесса вы начнёте собирать «всё про работу отдела».

Составьте карту стейкхолдеров и ролей

Нужно понять, у кого какие знания:

исполнители знают реальную последовательность шагов, обходные пути и ошибки

руководители знают цели, метрики, боли и приоритеты

смежные команды знают точки передачи и причины возвратов

ИТ/поддержка знает ограничения систем, частые инциденты, интеграции

Подготовьте «скелет» будущего описания

Удобный минимальный шаблон (его можно вести в заметках во время работы):

| Блок | Что фиксировать | Пример вопроса/артефакта | |---|---|---| | Триггер | что запускает работу | «Что должно случиться, чтобы вы начали?» | | Вход | что нужно для старта | заявка, письмо, файл, звонок | | Результат | чем заканчиваем | статус, документ, отгрузка, решение | | Роли | кто участвует | исполнитель, согласующий, контролёр | | Шаги | что делаем по порядку | действия + в какой системе | | Правила | условия и политики | лимиты, критерии отказа | | Исключения | нестандартные ветки | нет данных, ошибка, срочно | | Метрики/боли | где «дорого/долго/часто ошибаемся» | время цикла, возвраты, очереди |

Интервью: как говорить так, чтобы получить факты

Когда интервью особенно полезны

Интервью — основной способ быстро собрать картину процесса, особенно если:

процесс распределён по нескольким ролям и подразделениям

важно понять решения и бизнес-правила (почему так, а не иначе)

нужно выявить исключения, риски и «серые зоны» ответственности

Кого интервьюировать и в каком порядке

Практичная последовательность:

владелец процесса или руководитель направления (цели, границы, метрики, проблемы)

ключевые исполнители (реальные шаги, исключения, обходные пути)

смежные роли (точки передачи, критерии возврата)

ИТ/поддержка/безопасность/комплаенс (ограничения, доступы, контроль)

Типы вопросов, которые реально помогают

Используйте сочетание вопросов:

открытые: «Опишите, как вы обрабатываете заявку от начала до конца»

уточняющие: «Что происходит после регистрации?», «Кто именно утверждает?»

про правила: «По каким критериям отклоняете?», «Какие поля обязательны?»

про исключения: «Что делаете, если клиент не ответил?», «Если система недоступна?»

про факты и артефакты: «Покажите пример заявки/письма/шаблона»

Важно разделять:

как должно быть (официально)

как есть (реально)

Полезная формулировка: «Как это происходит в большинстве случаев?» и «А в каких случаях бывает по-другому?».

Мини-сценарий интервью (структура встречи)

Чтобы интервью не превратилось в «разговор обо всём», держите структуру:

контекст: цель описания и границы процесса

основной поток: шаги от триггера до результата

решения и правила: где выбирают вариант, кто принимает решение

исключения: возвраты, ошибки, спорные случаи

инструменты и данные: системы, документы, статусы, поля

проблемы и идеи улучшений: что болит, где теряем время

валидация: кратко пересказать услышанное и договориться о следующем шаге

Фиксация результатов интервью

Лучше всего работает связка:

короткий протокол (1–2 страницы): что обсудили, ключевые факты, вопросы

список открытых вопросов (что нужно уточнить)

черновик процесса (таблица шагов или набросок схемы)

При этом важно отделять факты от интерпретаций:

факт: «согласование занимает до 2 дней, потому что руководитель утверждает раз в день»

интерпретация: «руководитель медленно работает»

Наблюдение: как увидеть реальный процесс

Что такое наблюдение и зачем оно нужно

Наблюдение — это изучение процесса «вживую»: вы смотрите, как сотрудник выполняет работу, какие системы открывает, какие данные ищет, где ждёт, где ошибается.

Наблюдение особенно полезно, когда:

есть разрыв между регламентом и реальностью

много ручных действий в системах (копировать-вставить, сверки)

высока доля исключений и «неформальных договорённостей»

Форматы:

теневое сопровождение (shadowing): вы наблюдаете за сотрудником во время работы

пошаговый разбор на примере кейса: сотрудник проходит процесс на реальной/типовой заявке

Как проводить наблюдение безопасно и корректно

Риски наблюдения — не только организационные, но и этические (данные клиентов, персональные данные). Базовые правила:

заранее согласовать формат и длительность

объяснить цель: «мы улучшаем процесс, не оцениваем вашу работу»

не записывать чувствительные данные (или обезличивать)

фиксировать действия и причины, а не «оценки»

Что фиксировать во время наблюдения

Удобный чек-лист:

последовательность действий (что за чем)

где возникает ожидание (очередь, согласование, зависимость)

какие данные вводятся/проверяются и где берутся

какие поля обязательны и почему

какие обходные пути используются (Excel, мессенджеры, личные списки)

точки передачи (кому и как передают результат)

типичные ошибки и как их исправляют

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

Анализ документов и данных: «следы» процесса

Что относится к документам и данным процесса

Это любые артефакты, которые процесс создаёт или использует:

регламенты, инструкции, политики, чек-листы

шаблоны писем, формы заявок, договоры

отчёты, выгрузки, реестры

статусы в системах, карточки, журналы действий

логи, обращения в поддержку, причины отказов

Что можно извлечь из документов

Документы помогают быстро получить:

официальные роли и ответственность

контрольные точки и требования (например, кто имеет право утверждать)

обязательные поля и состав данных

нормативные сроки и критерии качества

Но документы часто описывают как должно быть, а не как есть. Поэтому их нужно проверять интервью и наблюдением.

Как анализировать документы практично

Подход «вопрос → документ → проверка»:

сформулировать вопрос (например: «когда мы имеем право отказать?»)

найти источник (политика, договор, инструкция, экранная форма)

извлечь правило и привязать к шагу процесса

подтвердить у исполнителя: «вы так делаете всегда? когда иначе?»

Важная техника: сопоставление терминов

Одна и та же сущность может называться по-разному в разных местах: «заявка», «обращение», «тикет», «запрос». На раннем этапе полезно завести мини-глоссарий:

термин

определение простыми словами

где используется (документ/система)

Это снижает риск, что участники «согласны», но на самом деле обсуждают разные вещи.

Как свести информацию в единое описание процесса

Признаки противоречий, которые нужно разрешить

Типичные сигналы:

разные люди называют разные точки старта/финиша

роли «перекидывают» ответственность: «это делает не наш отдел»

документ требует одно, система позволяет другое

один исполнитель говорит «всегда так», другой — «никогда так»

Техника: «сквозной кейс»

Чтобы собрать процесс целиком, выберите 1–2 реальных сценария и проведите их через все роли:

обычный кейс (самый частый)

проблемный кейс (с возвратом/ошибкой/исключением)

На каждом шаге фиксируйте:

вход и выход

кто делает

в какой системе/документе

по какому правилу выбирается дальнейшая ветка

Что должно получиться на выходе этапа сбора

Минимальный набор результатов, готовый для моделирования и согласования:

список ролей и зон ответственности

таблица шагов As-Is (хотя бы черновик)

перечень бизнес-правил и исключений

список проблем, рисков и гипотез улучшений

открытые вопросы и план уточнений

Частые ошибки и как их избегать

| Ошибка | Чем опасна | Как исправить | |---|---|---| | опираться на одного «главного эксперта» | описание становится субъективным | подтверждать факты у других ролей и по данным | | брать регламент как истину | получится «как должно быть», а не «как есть» | проверять регламент наблюдением и кейсами | | собирать только «основной поток» | при внедрении системы «всплывут» исключения | отдельно спрашивать про исключения и ошибки | | фиксировать мнения вместо фактов | трудно согласовать и измерять | записывать наблюдаемое действие/правило/артефакт | | не управлять границами | описание разрастается и не заканчивается | фиксировать старт/финиш и парковать «вне рамок» |

Полезные источники

IIBA BABOK Guide (страница стандарта)

Business Process Model and Notation (BPMN) 2.0.2 (OMG)

Что дальше по курсу

Теперь у вас есть инструменты, чтобы собрать факты для описания процесса As-Is. Следующий шаг — превратить собранную информацию в понятный артефакт: таблицу шагов и/или диаграмму (обычно в BPMN), подготовить формулировки правил и исключений и провести согласование со стейкхолдерами.

Границы процесса: контекст, SIPOC, участники и события

Зачем бизнес-аналитику начинать с границ процесса

В прошлых статьях курса мы разобрали:

роль бизнес-аналитика и цели описания процессов

как собрать факты о процессе через интервью, наблюдение и анализ документов

Следующий шаг перед тем, как делать таблицу шагов As-Is или рисовать BPMN, — зафиксировать границы процесса. Это снижает типичные риски:

вместо одного процесса вы описываете «всё, что делает отдел»

разные участники обсуждают разные «начала» и «концы» и не могут согласовать схему

требования к автоматизации расползаются, потому что in-scope не определён

Границы процесса — это договорённость со стейкхолдерами: что именно мы описываем, где начинается ответственность и где она заканчивается.

Что такое границы и контекст процесса

Границы процесса

Границы отвечают на два вопроса:

где процесс начинается и чем он заканчивается

что точно входит в процесс и что точно не входит

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

Контекст процесса

Контекст показывает окружение процесса:

кто или что запускает процесс

кто получает результат

какие внешние системы и команды участвуют через передачи

какие входы приходят извне и какие выходы уходят наружу

!Пример контекстной схемы: процесс в центре и его внешние взаимодействия

Границы через события: старт и финиш

Чтобы границы были однозначными, их фиксируют через события.

Что такое событие в процессе

Событие — это наблюдаемый факт, который важен для процесса:

что-то произошло и процесс стартует

процесс завершился конкретным результатом

случилось исключение, влияющее на ход процесса

Событие формулируют как факт, а не как действие человека.

Стартовое событие

Старт процесса описывают так, чтобы было понятно:

откуда приходит инициирование (клиент, система, сотрудник, закон, расписание)

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

Примеры корректных стартовых событий:

«Получено обращение клиента в чат»

«Поступила заявка из формы на сайте»

«Наступило 1 число месяца, запущено закрытие периода»

Примеры некорректных стартов:

«Менеджер обрабатывает заявку» (это действие, а не событие)

«Работаем с клиентом» (слишком расплывчато)

Завершающее событие

Финиш процесса — это состояние, в котором ответственность процесса заканчивается.

Примеры корректных завершающих событий:

«Клиент получил ответ и обращение закрыто»

«Договор подписан обеими сторонами и зарегистрирован в системе»

«Заявка отклонена с зафиксированной причиной»

Важный приём: завершение должно быть проверяемым по артефактам или статусам (в системе, документе, письме).

Практичный инструмент: SIPOC для фиксации границ

Что такое SIPOC

SIPOC — это простая рамка, которая помогает договориться о контуре процесса на верхнем уровне.

Расшифровка:

Suppliers: поставщики входов

Inputs: входы

Process: процесс верхнего уровня (обычно 5–7 крупных шагов)

Outputs: выходы

Customers: получатели выходов

Источник: ASQ: SIPOC

Зачем SIPOC бизнес-аналитику

SIPOC полезен до детальной схемы, потому что он:

быстро выявляет, где границы процесса спорные

показывает «внешние» зависимости и передачи

помогает собрать правильных стейкхолдеров на интервью и согласование

даёт общий язык до BPMN и регламентов

Пример SIPOC (упрощённо)

Пример: процесс «Обработка заявки на подключение услуги».

| Suppliers (поставщики) | Inputs (входы) | Process (верхнеуровнево) | Outputs (выходы) | Customers (получатели) | |---|---|---|---|---| | Клиент, Сайт, Колл-центр | Заявка, контакты, адрес, согласие на обработку данных | 1) Принять заявку 2) Проверить данные 3) Принять решение 4) Назначить исполнение 5) Уведомить клиента | Решение, заказ-наряд, уведомление, причина отказа | Клиент, Выездная служба, Биллинг |

Как читать этот SIPOC:

если поставщик или получатель не назван, вы рискуете потерять точку передачи

если входы и выходы не проверяемы, границы будут постоянно «плыть»

!Визуальная шпаргалка SIPOC и разделение in-scope/out-of-scope

Участники процесса: роли, стейкхолдеры, зоны ответственности

Чтобы границы стали рабочими, нужно определить участников.

Роль и стейкхолдер

Роль — функция в процессе (например: «Оператор», «Согласующий», «Курьер»), не обязательно конкретный человек.

Стейкхолдер — любой, кто влияет на процесс или на кого влияет процесс.

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

Минимальный набор ролей, которые стоит искать

На этапе определения границ удобно проверить, есть ли:

инициатор (кто или что запускает)

владелец результата (кто «получает ценность»)

исполнитель(и) основных шагов

принимающий решение (кто утверждает, кто может отказать)

контролёр или соблюдение требований (качество, безопасность, комплаенс)

поддерживающие роли (ИТ-поддержка, логистика, бухгалтерия)

Точки передачи как границы ответственности

Границы процесса часто проходят там, где есть передача результата:

между подразделениями

между человеком и системой

между компанией и внешним контрагентом

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

«После какого шага ваша команда больше ничего не делает по этому кейсу?»

Как сформулировать границы процесса: шаблон и порядок действий

Ниже — рабочий алгоритм, который можно применить к любому процессу.

Сформулируйте цель описания процесса (оптимизация, автоматизация, регламент).

Назовите ценность результата для получателя.

Зафиксируйте стартовое событие (триггер).

Зафиксируйте завершающее событие (результат или отказ с причиной).

Определите in-scope и out-of-scope простыми формулировками.

Соберите верхнеуровневый SIPOC.

Выпишите роли и ключевых стейкхолдеров на согласование.

Зафиксируйте интерфейсы с соседними процессами (входы и выходы на передачах).

Шаблон формулировки границ (можно вставлять в документ)

Название процесса: ...

Цель процесса: ...

Стартовое событие: ...

Завершающее событие: ...

Входит в рамки: ...

Не входит в рамки: ...

Основные роли: ...

Внешние системы и команды на передачах: ...

Основные выходы: ...

Типовые ошибки при определении границ и как их исправлять

| Ошибка | Как проявляется | Как исправить | |---|---|---| | Смешали несколько процессов | «Продажа + доставка + возвраты» в одной схеме | разделить по разным результатам и разным завершающим событиям | | Старт слишком ранний | начинают с «маркетинг привёл лид» | зафиксировать старт там, где появляется управляемый вход (например, оформленная заявка) | | Финиш слишком поздний | заканчивают на «клиент доволен» | закончить на измеримом результате (статус, документ, отправленное уведомление) | | Нет out-of-scope | «всё важно» | явно перечислить исключаемые зоны и соседние процессы | | Не обозначены передачи | «передаём куда-то дальше» | назвать получателя, формат выхода и канал передачи |

Что должно получиться на выходе этого шага

К моменту, когда вы переходите к детальному описанию As-Is, у вас должны быть:

согласованные стартовое и завершающее события

зафиксированный контекст процесса и список внешних взаимодействий

черновой SIPOC

список ролей и стейкхолдеров для интервью и валидации

список in-scope и out-of-scope (в одном абзаце, без двусмысленностей)

Это станет «рамкой», в которую дальше аккуратно лягут факты из интервью, наблюдений и документов, а затем — таблица шагов и диаграмма процесса.

Моделирование процессов: BPMN и базовые правила нотаций

Как эта тема связана с предыдущими шагами курса

На предыдущих этапах вы:

определили цель описания процесса и роль бизнес-аналитика

собрали факты через интервью, наблюдение и документы

зафиксировали границы процесса через стартовое и завершающее события, контекст и SIPOC

Моделирование процесса начинается только после этого. Иначе диаграмма получится либо слишком общей, либо спорной, либо «про всё сразу».

В этой статье разберём, как превращать собранные факты в понятную модель процесса и почему на практике чаще всего используют BPMN.

Что такое моделирование процесса

Моделирование бизнес-процесса — это описание процесса в формальном (или полуформальном) виде, чтобы его можно было:

одинаково прочитать разным людям

обсудить и согласовать

найти проблемы и улучшения

использовать как основу для требований к ИТ и регламентов

В реальных проектах обычно используют несколько уровней представления:

контур (границы, SIPOC, контекст)

логика процесса (основной поток, роли, решения, исключения)

детали исполнения (системы, данные, правила, варианты)

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

Почему BPMN используют чаще других нотаций

BPMN (Business Process Model and Notation) — распространённый стандарт описания процессов, который даёт общий язык для бизнеса и ИТ.

Плюсы BPMN для бизнес-аналитика:

хорошо показывает роли и передачи (через пулы и дорожки)

отделяет действия от событий и решений

поддерживает исключения (таймеры, ошибки) без «текста на полях»

стандарт широко известен и поддерживается инструментами

Официальная спецификация: BPMN на сайте OMG.

При этом важно помнить: BPMN — не про «красивые значки», а про однозначность.

Легенда BPMN: элементы, которые нужны в 80% моделей

Ниже — минимальный набор, которого достаточно для большинства описаний As-Is.

!Шпаргалка по основным символам BPMN

События

Событие — это факт, который происходит.

Стартовое событие: что запускает процесс (например, «Получено обращение»)

Промежуточное событие: что-то произошло по ходу процесса (например, «Истёк таймер ожидания ответа»)

Завершающее событие: чем закончился процесс (например, «Ответ отправлен и обращение закрыто»)

Практическое правило именования: событие формулируется как свершившийся факт, а не как действие сотрудника.

Действия

Задача (Task) — шаг работы, который кто-то выполняет.

Примеры хороших названий задач:

«Зарегистрировать обращение»

«Проверить данные клиента»

«Подготовить ответ»

Практическое правило именования: задача начинается с глагола.

Шлюзы

Шлюз (Gateway) — точка решения или разделения потока.

Самый частый тип:

Исключающий шлюз: выбирается один вариант из нескольких (например, «Данных достаточно?»)

Также часто нужен:

Параллельный шлюз: запуск или синхронизация параллельных веток (например, «Отправить уведомление» и «Создать задачу исполнителю» одновременно)

Дорожки и пулы

Пул (Pool) — участник процесса на уровне организации или внешней стороны (например, «Клиент» и «Компания»).

Дорожка (Lane) — роль или подразделение внутри одного пула (например, «Поддержка 1 линии», «Поддержка 2 линии»).

Связи

Sequence flow (сплошная стрелка) показывает порядок шагов внутри одного пула

Message flow (пунктирная стрелка) показывает обмен сообщениями между пулами

Association (пунктирная линия) связывает комментарии или данные с элементами

Ключевая мысль: sequence flow не должен пересекать границу пула.

Базовые правила «читаемой» модели

Ниже — правила, которые чаще всего отличают рабочую модель от диаграммы «для галочки».

Договоритесь об одном стартовом и одном или нескольких финальных событиях

старт должен совпадать с границей, согласованной ранее

финалы должны быть проверяемыми (статус, документ, отправленное сообщение)

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

Держите один уровень детализации на одной диаграмме

Если на схеме одновременно:

крупные этапы уровня SIPOC

и мелкие клики в системе

её будет невозможно читать и согласовывать.

Практичный приём: делайте верхний уровень и выносите детали в подпроцессы.

Обозначайте ответственность через дорожки

Если роль меняется, это должно быть видно:

шаг находится в дорожке той роли, которая реально выполняет действие

передача между ролями фиксируется переходом потока к следующей дорожке

Это помогает быстро находить узкие места на передачах.

Формулируйте решения как вопросы и подписывайте условия на выходах

Пример:

шлюз: «Данных достаточно?»

выходы: «Да» и «Нет»

Если условия не подписаны, участники будут «додумывать» логику по-разному.

Заводите явные ветки для исключений, которые влияют на результат

Не обязательно рисовать все редкие случаи, но нужно фиксировать те исключения, которые:

часто происходят

приводят к возвратам

создают риск или финансовые потери

критичны для автоматизации

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

Минимизируйте пересечения линий и «петли» без причины

Если схема визуально запутана, её трудно валидировать. Обычно это сигнал, что:

смешаны уровни детализации

не выделены подпроцессы

не зафиксированы границы процесса

Пример: как превратить собранные факты в BPMN

Представим, что вы описываете процесс «Обработка обращения клиента в поддержку».

Шаг 1: опора на границы

Вы уже согласовали:

стартовое событие: «Получено обращение клиента»

завершающие события: «Ответ отправлен и обращение закрыто» или «Отказано с причиной»

Шаг 2: черновик в виде таблицы шагов

Перед BPMN удобно сделать таблицу (даже в черновике), чтобы не «изобретать» поток в редакторе.

| Роль | Действие | Результат шага | |---|---|---| | Поддержка 1 линии | Зарегистрировать обращение | Обращение создано, присвоен номер | | Поддержка 1 линии | Проверить данные и историю | Понятно, можно ли ответить сразу | | Поддержка 1 линии | Принять решение: нужна 2 линия? | Выбран маршрут | | Поддержка 2 линии | Провести диагностику | Подготовлено решение или причина отказа | | Поддержка 1 линии | Подготовить и отправить ответ | Ответ отправлен | | Поддержка 1 линии | Закрыть обращение | Обращение закрыто |

Шаг 3: сборка BPMN с пулами и сообщениями

Логика модели:

отдельный пул «Клиент»

пул «Компания» с дорожками «Поддержка 1 линии» и «Поддержка 2 линии»

сообщение от клиента запускает процесс

шлюз решает, нужна ли эскалация

!Пример простой BPMN-модели с ролями, решением и передачами

Важный нюанс: если вы показываете клиента отдельным пулом, обмен с ним — это message flow, а не sequence flow.

Как понять, что модель можно выносить на согласование

Ниже — практичный чек-лист. Если хотя бы на два пункта ответ «нет», лучше доработать до встречи.

| Проверка | Вопрос к модели | |---|---| | Границы | Старт и финиш совпадают с согласованными границами? | | Роли | Каждое действие находится в дорожке того, кто реально делает шаг? | | Передачи | Все передачи между ролями и внешними участниками видны? | | Решения | У каждого шлюза есть понятный вопрос и подписанные условия веток? | | Завершение | Понятно, по каким исходам процесс завершается? | | Исключения | Критичные исключения отражены, а не спрятаны в устных комментариях? | | Читаемость | Диаграмму можно объяснить вслух за 2–3 минуты без «и тут ещё куча всего»? |

Частые ошибки новичков в BPMN

| Ошибка | Как выглядит | Чем заменить | |---|---|---| | События названы действиями | «Обработать заявку» как старт | «Получена заявка» | | Непонятные задачи | «Проверка», «Работа» | «Проверить комплектность документов» | | Шлюз без условий | ромб есть, логики нет | вопрос в шлюзе + подписи «Да/Нет» на ветках | | Смешаны уровни | на одной схеме и этапы, и клики | подпроцессы или отдельные диаграммы | | Внешние участники в тех же дорожках | клиент как дорожка внутри компании | клиент отдельным пулом + message flow | | Нет явного завершения | поток «просто заканчивается» | завершающее событие с измеримым итогом |

Чем моделировать BPMN

Инструмент выбирайте по контексту: важно, чтобы его могли открыть и понять участники.

Популярные варианты:

Camunda Modeler — бесплатный редактор BPMN, удобен для практики и проектов

diagrams.net — универсальный редактор диаграмм, можно рисовать BPMN

Bizagi Modeler — инструмент для моделирования процессов

Что дальше по курсу

После того как вы научились собирать факты, фиксировать границы и строить читаемую BPMN-модель, следующий шаг — сделать описание As-Is «полным для проекта»: дополнить модель бизнес-правилами, данными и исключениями, а затем провести валидацию со стейкхолдерами и подготовить основу для To-Be и требований к изменениям.

Текстовое описание: шаги, бизнес-правила, исключения и варианты

Зачем текстовое описание, если есть BPMN

На предыдущих шагах курса вы научились:

собирать факты о процессе (интервью, наблюдение, документы)

фиксировать границы (старт/финиш, контекст, SIPOC)

моделировать логику процесса в BPMN

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

в требованиях и регламентах нужны однозначные формулировки шагов

бизнес-правила удобнее согласовывать и версионировать как текст

исключения и варианты часто требуют деталей (условия, сроки, статусы, данные)

текст позволяет зафиксировать что именно считать выполнением шага и какой артефакт появляется на выходе

В этой статье вы освоите набор текстовых артефактов, который делает описание процесса полным для проекта: таблица шагов, каталог бизнес-правил, перечень исключений и вариантов, плюс связь этих элементов с BPMN.

!Как вместе выглядят BPMN и текстовые артефакты процесса

Какие текстовые артефакты использовать

Минимальный практичный комплект обычно такой:

Таблица шагов (основной поток процесса и при необходимости отдельные ветки)

Каталог бизнес-правил (правила решений, проверки, ограничений, расчётов)

Исключения и варианты (что идёт «не по основному пути» и как это обрабатывается)

Глоссарий и статусы (чтобы термины и состояния понимались одинаково)

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

Таблица шагов: как описывать процесс текстом

Что такое «шаг»

Шаг процесса — это минимально полезное действие, которое:

выполняет конкретная роль

приводит к наблюдаемому результату (артефакт, статус, запись в системе)

можно проверить (по данным, документу, событию)

Плохой шаг: «Обработать заявку» (непонятно что именно делаем и как понять, что сделано).

Хороший шаг: «Проверить комплектность документов и зафиксировать результат проверки в CRM».

Рекомендуемый шаблон таблицы шагов

Ниже — шаблон, который хорошо работает для описания As-Is и последующего перехода к требованиям.

| Поле | Что фиксируем | Зачем это нужно | |---|---|---| | ID шага | уникальный идентификатор, например S-01 | связывать шаги с правилами, требованиями и BPMN | | Роль | кто выполняет (роль, не ФИО) | ответственность и передачи | | Действие | глагол + объект, однозначно | чтобы шаг можно было повторить | | Вход | что нужно, чтобы начать шаг | данные/документы/события | | Выход/статус | что получаем в конце шага | критерий завершения шага | | Система/канал | где выполняется (CRM, почта, 1С) | понимание автоматизации и ограничений | | Правило (ссылка) | BR-..., если есть условия/проверки | трассируемость логики | | Комментарии | пояснения, если без них нельзя | не перегружать основное описание |

Пример таблицы шагов (упрощённо)

Пример для процесса «Обработка обращения клиента в поддержку».

| ID шага | Роль | Действие | Вход | Выход/статус | Система/канал | Правило | |---|---|---|---|---|---|---| | S-01 | Поддержка 1 линии | Зарегистрировать обращение | Сообщение клиента | Создан тикет, присвоен номер | Service Desk | BR-01 | | S-02 | Поддержка 1 линии | Проверить данные клиента и историю | Тикет, профиль клиента | Результат проверки зафиксирован | CRM, Service Desk | BR-02 | | S-03 | Поддержка 1 линии | Определить маршрут обработки | Результат проверки | Выбран маршрут: ответить или эскалировать | Service Desk | BR-03 | | S-04 | Поддержка 2 линии | Провести диагностику | Тикет с данными | Подготовлено решение/причина отказа | Внутренние системы | BR-04 | | S-05 | Поддержка 1 линии | Отправить ответ клиенту | Решение/шаблон | Ответ отправлен | Почта/чат | BR-05 | | S-06 | Поддержка 1 линии | Закрыть обращение | Отправленный ответ | Тикет в статусе «Закрыт» | Service Desk | BR-06 |

Правила хорошего текстового описания шагов

Один шаг — одна роль (если «вместе делают», разделяйте на последовательные шаги)

Название шага начинается с глагола: «Проверить», «Сформировать», «Согласовать»

В «выходе» фиксируйте проверяемый результат: статус, документ, запись

Не смешивайте уровень детализации (не добавляйте «клики по кнопкам», если вы описываете логику процесса)

Бизнес-правила: как фиксировать логику решений и ограничений

Что такое бизнес-правило

Бизнес-правило — это формализованное ограничение или условие, по которому процесс:

принимает решение (маршрут, одобрение/отказ)

проверяет данные

рассчитывает значения (тариф, срок, лимит)

обеспечивает соответствие политике или закону

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

Типы бизнес-правил, которые чаще всего встречаются

Правила маршрутизации: «если X, то идём в ветку A, иначе в B»

Правила валидации данных: «обязательные поля», «формат», «диапазон значений»

Правила полномочий: «кто имеет право утверждать»

Правила сроков: «дедлайны», «время ожидания», «эскалация по таймеру»

Правила расчётов: «как вычисляется сумма/скидка/комиссия»

Карточка бизнес-правила: шаблон

Рекомендуется заводить правила как отдельные записи.

| Поле | Пример | Зачем | |---|---|---| | ID правила | BR-03 | ссылаться из шагов, требований, тестов | | Название | «Определение маршрута обращения» | быстро понимать суть | | Формулировка | «Если обращение относится к категории X и требует диагностики, то эскалировать на 2 линию, иначе обработать на 1 линии» | однозначная логика | | Где применяется | S-03 | привязка к шагу/шлюзу | | Источник | политика, регламент, владелец процесса | откуда правило взято | | Владелец | роль/подразделение | кто подтверждает изменения | | Исключения | когда правило не действует | реальная практика | | Проверка | как подтвердить выполнение | контроль и тестирование |

Как писать правило, чтобы его можно было согласовать и автоматизировать

Формулируйте правило как проверяемое условие, избегайте оценочных слов: вместо «быстро» пишите «не позднее 2 часов»

Определяйте термины (что такое «категория X», что считается «диагностикой»)

Если правило зависит от данных, перечислите нужные поля и источник данных

Если правило приводит к отказу, фиксируйте причину отказа как значение из справочника или как текстовый шаблон

Исключения и варианты: как не потерять реальную жизнь процесса

Разница между вариантом и исключением

Эти понятия полезно разделять, иначе описание превращается в хаос.

Вариант (альтернативный сценарий) — нормальный, ожидаемый путь процесса при определённых условиях (например, «клиент — юридическое лицо», «доставка курьером вместо самовывоза»)

Исключение — отклонение из-за проблемы или нестандартной ситуации (например, «система недоступна», «данные отсутствуют», «клиент не отвечает»)

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

Как документировать варианты

Варианты удобнее фиксировать так:

в основной таблице шагов оставить «скелет» основного потока

на шаге, где появляется развилка, сослаться на вариант: V-01, V-02

для каждого варианта сделать мини-таблицу шагов или текстовую вставку «если…, то…»

Шаблон описания варианта:

| Поле | Содержание | |---|---| | ID варианта | V-01 | | Условие входа | при каких данных/событии включается | | Отличия от основного потока | какие шаги добавляются/убираются/меняются | | Роли и системы | кто участвует и где выполняется | | Итог | чем заканчивается вариант |

Как документировать исключения

Исключения полезно фиксировать рядом с тем шагом, где они возникают, и обязательно указывать обработку.

Шаблон исключения:

| Поле | Содержание | |---|---| | ID исключения | EX-02 | | Где возникает | шаг S-04 | | Событие/признак | что наблюдаем (ошибка, таймаут, отсутствие данных) | | Обработка | что делаем (повтор, эскалация, ручной обходной путь) | | Влияние на срок/результат | что меняется в SLA/итоге | | Артефакт фиксации | где записываем причину (поле, статус, комментарий) |

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

Связь текста с BPMN: как обеспечить трассируемость

Чтобы BPMN и текст не противоречили друг другу, держите простые соответствия.

| В BPMN | В тексте | |---|---| | Task (задача) | шаг S-... в таблице шагов | | Gateway (шлюз) | бизнес-правило BR-... + условия веток | | Event (событие) | формулировка старта/финиша, исключение EX-... | | Lanes (дорожки) | поле «Роль» в таблице | | Message flow | вход/выход + канал (письмо, API, звонок) |

Удобный приём: подписывать на диаграмме ID шагов и/или правил небольшими метками (S-03, BR-03). Тогда согласование идёт быстрее: участники спорят не «про стрелочку слева», а про конкретный шаг и правило.

Критерии качества текстового описания

Проверяйте описание перед согласованием по чек-листу.

У каждого шага есть проверяемый выход (статус, документ, запись)

У каждого решения есть правило и подписанные условия («Да/Нет» или значения)

Роли не «прыгают» внутри одного шага

Термины и статусы единообразны (есть глоссарий или явные определения)

Исключения, влияющие на сроки/результат/автоматизацию, зафиксированы с обработкой

Не смешаны уровни детализации (логика процесса отдельно от «как нажать кнопки»)

Что должно получиться на выходе

После применения подхода из этой статьи у вас должен быть комплект, который можно отдавать на валидацию и использовать как основу для требований:

таблица шагов основного потока с ролями, входами и выходами

каталог бизнес-правил с ID, формулировками и источниками

список вариантов и исключений с условиями и обработкой

связка текста с BPMN через идентификаторы и ссылки

Полезные источники

BPMN 2.0.2 Specification (OMG)

BABOK Guide (IIBA)

Проверка качества: полнота, непротиворечивость, трассируемость

Зачем проверять качество описания процесса

Описание процесса нужно не само по себе, а как основа для согласования, улучшений и требований к изменениям. Если артефакты процесса сделаны «примерно», то в проекте это обычно проявляется так:

разные участники читают одно и то же описание по-разному

автоматизация реализует не то, что ожидает бизнес

исключения «всплывают» поздно и ломают сроки

невозможно понять, какое правило относится к какому шагу и где оно проверяется

Поэтому бизнес-аналитику важно уметь проверять качество описания процесса по трём ключевым свойствам:

полнота: ничего критичного не забыли

непротиворечивость: артефакты и формулировки согласованы между собой и с реальностью

трассируемость: можно связать шаги, правила, исключения, элементы BPMN и требования

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

Что именно проверяем: набор артефактов процесса

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

Минимальный «пакет», который обычно попадает на проверку:

границы процесса: стартовое и завершающее события, in-scope и out-of-scope

SIPOC или контекст процесса (внешние поставщики входов и получатели выходов)

BPMN-диаграмма (поток, роли, решения, основные исключения)

таблица шагов (ID, роль, вход, выход/статус, система, ссылка на правила)

каталог бизнес-правил (ID, формулировка, где применяется, источник)

список вариантов и исключений (ID, где возникает, обработка, фиксация в системе)

глоссарий и статусы (термины, значения статусов, определения)

Полнота: как убедиться, что ничего важного не пропущено

Что такое полнота

Полнота — это наличие всей информации, без которой процесс нельзя корректно выполнить, согласовать или автоматизировать.

Важно: полнота не равна максимальной детализации. Полнота означает, что для вашей цели описания покрыты все критичные элементы.

Практичная проверка полноты по «сквозному кейсу»

Самый рабочий способ проверки: взять 1–2 реальных сценария и пройти ими весь процесс по вашим артефактам.

Рекомендуемый набор:

основной сценарий (самый частый)

сценарий с типовым отклонением (например, возврат, нехватка данных, отказ)

Во время прохода задавайте вопросы:

где появляется кейс (какое стартовое событие)

какие входы должны быть, чтобы шаг начался

кто выполняет шаг и где (роль и система)

по какому правилу выбирается ветка

какие статусы и артефакты фиксируются

как процесс заканчивается и чем это подтверждается

Если на любой вопрос невозможно ответить по документу, это признак неполноты.

Чек-лист полноты (минимум для согласования)

| Область | Что должно быть в описании | Типичный сигнал неполноты | |---|---|---| | Границы | 1 старт, 1+ финалов, in-scope/out-of-scope | «Мы ещё делаем вот это…» на согласовании | | Роли | все исполнители и принимающие решения | «Кто это утверждает?» — ответа нет | | Передачи | видны точки передачи между ролями/подразделениями/внешними сторонами | «Оно куда-то уходит дальше» | | Входы/выходы | у шагов есть вход и проверяемый выход | шаг заканчивается «ничем» | | Решения | у каждого решения есть условие и результат ветки | ромб есть, логики нет | | Исключения | отражены исключения, влияющие на срок/результат/автоматизацию | «А если система упала?» — не описано | | Данные | перечислены критичные данные и их источники | непонятно, откуда берётся поле | | Фиксация | понятно, где фиксируется результат (статус, поле, документ) | невозможно проверить выполнение |

Частая ошибка: «основной поток описан, значит всё готово»

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

что делать при отсутствии данных

таймауты ожидания (клиент не ответил, не пришёл документ)

причины отказа и где они фиксируются

ручные обходные пути и их последствия

Непротиворечивость: как убрать несостыковки

Что такое непротиворечивость

Непротиворечивость означает, что:

разные артефакты описывают один и тот же процесс одинаково

термины и статусы употребляются единообразно

логика решений не конфликтует с правилами, документами и реальной практикой

Типовые виды противоречий

| Вид противоречия | Пример | Чем опасно | |---|---|---| | BPMN vs таблица шагов | в BPMN «Согласовать», а в таблице согласование отсутствует | потеря шага в требованиях | | Правило vs реальность | правило «срок 1 день», по факту 3 дня всегда | неверные SLA и ожидания | | Роли | в тексте «делает менеджер», на схеме в дорожке «оператор» | спор ответственности | | Статусы | «Закрыт», «Выполнен», «Завершён» используются как одно и то же | ошибки в аналитике и автоматизации | | Границы | в начале статьи процесс стартует с лида, а в SIPOC — с заявки | расползание scope | | Исключения | исключение описано, но нет обработки или фиксации результата | «серые зоны» и ручные решения |

Метод: «один источник истины» для терминов и статусов

Чтобы не было споров на согласовании, заведите минимальный глоссарий и справочник статусов.

Рекомендованная структура записи:

термин или статус

определение простыми словами

где используется (система/документ)

допустимые значения (если это поле или статус)

Практическое правило: если термин участвует в бизнес-правиле, он должен быть определён.

Метод: сверка артефактов по идентификаторам

Если у шагов, правил и исключений есть ID, непротиворечивость проверяется быстрее.

Пример соглашения:

шаги: S-01, S-02…

правила: BR-01, BR-02…

исключения: EX-01, EX-02…

варианты: V-01, V-02…

Тогда в BPMN можно подписывать метки S-03 рядом с задачей, а у шлюза указывать BR-03. Если на диаграмме появился элемент без ID, он часто «теряется» в тексте и требованиях.

!Как ID связывают BPMN и текстовые артефакты

Трассируемость: как связать процесс с правилами, требованиями и проверками

Что такое трассируемость и зачем она нужна

Трассируемость — это возможность однозначно ответить на вопросы:

какое бизнес-правило управляет этим решением

какие исключения относятся к этому шагу

какое требование (или пользовательская история) реализует этот шаг процесса

какими тестами или проверками подтверждается выполнение правила

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

Минимальная трассируемость внутри описания процесса

Даже без формальных требований вы можете обеспечить базовую трассируемость так:

каждая задача в BPMN соответствует шагу S-... в таблице шагов

каждый шлюз (решение) соответствует правилу BR-...

каждое существенное исключение соответствует записи EX-... с обработкой и фиксацией

шаги и правила ссылаются на термины и статусы из глоссария

Трассируемость до требований и тестов (если это проект автоматизации)

Практичная матрица трассируемости может быть простой таблицей. Она не обязана быть «идеальной», но должна позволять проверить покрытие.

Пример структуры:

| Элемент процесса | ID | Связанное правило | Исключения | Требование/история | Проверка/тест | |---|---|---|---|---|---| | Шаг | S-03 | BR-03 | EX-01 | REQ-12 | TC-12 |

Где:

REQ-... — идентификатор требования или пользовательской истории

TC-... — идентификатор тест-кейса или критерия приёмки

Если требования в вашем проекте ведутся в трекере (например, Jira), вместо REQ-12 обычно ставят ключ задачи (например, CRM-124).

!Пример матрицы трассируемости «процесс → требования → тесты»

Частые проблемы трассируемости

| Проблема | Как выглядит | Что делать | |---|---|---| | Нет ID | «ромбик про проверку» без ссылки на правило | ввести соглашение об ID и проставить | | Правило есть, но не ясно где применяется | правило записано отдельно, без шага | в карточке правила указать шаги S-... | | Исключение не связано с шагом | исключения списком «в конце документа» | указывать «где возникает» и ссылку на шаг | | Требования не покрывают процесс | есть BPMN, но нельзя сказать, что реализовано | вести матрицу «шаг → требование» |

Как организовать проверку качества в реальной работе

Минимальный процесс проверки

Самопроверка по чек-листам полноты и непротиворечивости.

Быстрый проход «сквозного кейса» по артефактам (основной + проблемный).

Пиринговый обзор (другой аналитик или участник проекта читает и задаёт вопросы).

Валидация со стейкхолдерами: короткая встреча, где вы проходите процесс и фиксируете правки.

Финальная фиксация версии: дата, список согласующих, что изменилось.

Техника валидации: «прочитай и выполни по документу»

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

Если человек вынужден постоянно спрашивать «а что дальше?», «а где это посмотреть?», «а кто решает?», то описание не готово.

Критерий готовности: «документ позволяет принять решение»

Хорошее описание процесса должно позволять принять как минимум одно решение из вашего контекста:

согласовать текущую схему ответственности

определить, что автоматизировать и где контроль

сформулировать требования к системе

зафиксировать регламент выполнения и проверки

Если описание нельзя использовать ни для одного из этих действий, значит проверка качества выявит пробелы.

Мини-чек-лист перед тем, как отправить на согласование

| Вопрос | Ожидаемый ответ | |---|---| | Ясно ли, где начинается и заканчивается процесс? | старт и финалы сформулированы как события, проверяемы | | Можно ли пройти основной кейс без «устных пояснений»? | да, по таблице шагов и BPMN | | У каждого решения есть правило? | да, BR-... и условия веток подписаны | | Критичные исключения описаны с обработкой? | да, есть EX-... и фиксация результата | | Термины и статусы однозначны? | есть глоссарий/справочник статусов | | BPMN и текст совпадают по смыслу? | нет элементов «только на схеме» или «только в тексте» |

Полезные источники

BPMN 2.0.2 Specification (OMG)

IIBA BABOK Guide

Оформление и согласование: стандарты, шаблоны, управление изменениями

Зачем бизнес-аналитику «оформлять» процесс, если он уже описан

В предыдущих статьях курса вы прошли путь от сбора фактов и определения границ до BPMN, текстовых артефактов и проверки качества (полнота, непротиворечивость, трассируемость). На практике этого всё равно недостаточно, если описание процесса нужно использовать в работе месяцами.

Оформление и согласование решают три прикладные задачи:

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

фиксируют ответственность и договорённости (кто согласовал, на что опирались, что считается «истиной»)

позволяют управлять изменениями (как обновлять процесс без хаоса и потери трассируемости)

Эта статья про то, как превратить набор артефактов (BPMN + таблицы + правила) в управляемый результат, которому доверяют.

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

Что в этой статье считается «стандартом»

Слово стандарт в процессной работе используют в двух смыслах.

Внешний стандарт: общепринятая нотация или подход, например BPMN

Внутренний стандарт: правила вашей компании или команды, например структура документа, правила именования, версионирование, порядок согласования

Внешние стандарты полезны как «общий язык»:

BPMN 2.0.2 Specification (OMG)

IIBA BABOK Guide (страница стандарта)

Но даже если вы используете BPMN идеально, без внутренних стандартов описание быстро превратится в набор несвязанных файлов.

Минимальный пакет артефактов, который удобно оформлять как «версию процесса»

Чтобы участники и команда изменений понимали, что именно согласовано, удобно собирать «пакет процесса».

Рекомендуемый минимальный состав:

паспорт процесса (карточка процесса на 1 страницу)

границы процесса (старт, финалы, in-scope, out-of-scope)

SIPOC или контекст процесса (внешние поставщики и получатели)

BPMN-диаграмма (логика, роли, ключевые решения и исключения)

таблица шагов (шаги S-..., роли, входы, выходы, системы)

каталог бизнес-правил (правила BR-...)

список исключений и вариантов (EX-..., V-...)

глоссарий терминов и статусов

журнал изменений (что менялось между версиями)

Практическое правило: если элемент влияет на выполнение работы или на требования к системе, он должен быть внутри пакета, а не «где-то в переписке».

Внутренние стандарты, которые реально повышают качество

Ниже набор стандартов, который обычно даёт максимальный эффект при минимальных затратах.

Единые правила именования

Именование нужно для читаемости и для поиска.

Рекомендуемые соглашения:

процесс: существительное + объект, например «Обработка обращения клиента», «Согласование договора»

событие: свершившийся факт, например «Получено обращение», «Договор подписан»

задача: глагол + объект, например «Проверить комплектность документов»

шлюз: вопрос, например «Данных достаточно?»

Отдельно полезно стандартизировать формат идентификаторов:

шаги: S-01, S-02

правила: BR-01, BR-02

исключения: EX-01, EX-02

варианты: V-01, V-02

Это поддерживает трассируемость, о которой говорили в статье про качество.

Единый уровень детализации по слоям

Чтобы документы не «разрывались» между разными аудиториями, удобно договориться о слоях:

уровень контура: границы, SIPOC, контекст

уровень логики: BPMN основного потока + ключевые варианты

уровень исполнения: таблица шагов, правила, статусы, исключения

Если вы смешиваете слои в одном месте, согласование затягивается, потому что руководители спорят про «клики в системе», а исполнители не видят своей ответственности.

Единый глоссарий и справочник статусов

Глоссарий — список терминов с определениями.

Минимальная запись:

термин

определение простыми словами

где используется (система или документ)

Справочник статусов — это список допустимых статусов сущности процесса (например, «Заявка»), с определениями.

Практическая польза: снижает риск «мы договорились», когда на самом деле участники вкладывают разные смыслы в слова «закрыто», «выполнено», «обработано».

Единый формат версий и «актуальности»

Описание процесса должно отвечать на вопрос: какая версия действующая.

Рекомендуемая мета-информация в начале пакета:

версия (например 1.2)

дата вступления в силу

автор

согласующие (роли и ФИО при необходимости)

ссылка на репозиторий или папку, где лежит «единая истина»

Также полезно хранить статус документа:

черновик

на согласовании

утверждено

архив

Шаблоны: как оформить процесс, чтобы его было легко читать и согласовывать

Ниже практичные шаблоны, которые можно адаптировать под компанию.

Паспорт процесса (1 страница)

Паспорт позволяет быстро понять, что это за процесс и кто за него отвечает.

| Поле | Содержание | |---|---| | Название процесса | Коротко и однозначно | | Цель процесса | Какой результат создаём и для кого | | Владелец процесса | Роль или подразделение, отвечающее за результат | | Стартовое событие | Свершившийся факт старта | | Завершающие события | Свершившиеся факты завершения (успех и ключевые исходы) | | In-scope | Что входит | | Out-of-scope | Что не входит | | Основные роли | Кто участвует в выполнении и принятии решений | | Ключевые метрики | Что измеряем (время цикла, возвраты, ошибки) | | Основные системы | Где выполняется процесс |

Шаблон «пакета процесса» как структуры документа

Если вы ведёте всё в одном документе, удобна структура:

паспорт процесса

границы, контекст и SIPOC

BPMN-диаграмма

таблица шагов S-...

бизнес-правила BR-...

исключения EX-... и варианты V-...

глоссарий и статусы

журнал изменений

Если артефакты разнесены по файлам, структура всё равно нужна как оглавление со ссылками.

Журнал изменений (change log)

Журнал изменений нужен, чтобы можно было ответить: что изменилось и почему.

| Версия | Дата | Что изменили | Причина | Автор | |---|---|---|---|---| | 1.1 | 2026-02-01 | Добавлено EX-02, обновлено BR-03 | Участились сбои системы | БА |

Практическое правило: если меняется шаг, правило или статус, запись в журнале изменений обязательна.

Согласование: как организовать так, чтобы договориться, а не «показать диаграмму»

Согласование — это подтверждение, что описание отражает договорённую реальность и может использоваться как основа для регламентов, автоматизации или изменений.

Кто должен согласовывать

Состав согласующих зависит от цели, но обычно нужны:

владелец процесса (тот, кто отвечает за результат)

ключевые исполнители по ролям

смежные команды на передачах

ИТ или архитектор (если процесс связан с системами)

безопасность или комплаенс (если есть ограничения и контроль)

Важно различать роли:

участник валидации даёт факты и комментарии

согласующий принимает решение «да, это так»

утверждающий вводит в действие (если у компании есть формальная процедура)

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

Чтобы согласование не ушло в спор «кто как привык», заранее подготовьте:

цель описания и границы (1 абзац)

1–2 «сквозных кейса» для прохода по процессу

список открытых вопросов (то, что вы ещё не знаете)

критерии того, что считается согласованным результатом (например: «BPMN + таблица шагов + правила для шлюзов»)

Как проводить согласование эффективно

Рабочий формат встречи:

зафиксировать цель и границы (старт, финалы, in-scope)

пройти основной сценарий по BPMN (2–5 минут) и по таблице шагов (точечно)

на каждом шлюзе подтвердить правило BR-... и условия веток

подтвердить критичные исключения EX-... и обработку

договориться, что будет «базовой версией» и с какой даты она действует

зафиксировать замечания как список изменений, а не как «обсудили и забыли»

Практический приём: спорные места фиксируйте как отдельные решения, например «решение R-01: кто имеет право отклонять заявку категории X». Это ускоряет движение, даже если вы не закрыли вопрос на встрече.

!Таймбокс и структура встречи по согласованию процесса

Управление изменениями: как обновлять процесс без потери контроля

Процессы меняются почти всегда: меняются системы, оргструктура, правила, SLA. Если не управлять изменениями, появляются параллельные версии, противоречия и «устные регламенты».

Базовые понятия

Базовая версия (baseline): зафиксированная согласованная версия, на которую можно ссылаться в требованиях и регламентах

Запрос на изменение (change request): формальное описание предлагаемого изменения

Оценка влияния (impact analysis): проверка, какие шаги, правила, статусы, системы и метрики затрагиваются

Минимальный процесс управления изменениями

Ниже схема, которая подходит даже для небольших команд.

Поступает запрос на изменение (кто-то хочет «поменять процесс»).

БА фиксирует запрос в одном месте (трекер, таблица, журнал).

Выполняется оценка влияния.

Решение: принять изменение, отложить или отклонить.

Вносятся правки в артефакты.

Проводится проверка качества (полнота, непротиворечивость, трассируемость).

Согласование изменённой версии.

Публикация новой базовой версии и обновление журнала изменений.

!Процесс change control для описания бизнес-процесса

Как делать оценку влияния практично

Оценка влияния должна отвечать на вопрос: что именно надо поменять и кого затронет.

Чек-лист для оценки влияния:

какие шаги S-... меняются или добавляются

какие правила BR-... меняются и как меняется логика шлюзов

появляются ли новые исключения EX-... или меняется обработка

меняются ли статусы и справочники значений

затрагиваются ли передачи между ролями или внешними участниками

затрагиваются ли системы, интеграции, формы ввода данных

меняются ли метрики или контрольные точки

Результат оценки влияния удобно фиксировать одной таблицей:

| Объект | ID | Тип изменения | Кратко | Кого затронет | |---|---|---|---|---| | Шаг | S-03 | изменение | Добавить проверку обязательного поля | Поддержка 1 линии | | Правило | BR-03 | изменение | Новый критерий маршрутизации | Поддержка 1 и 2 линии, ИТ |

Где хранить артефакты, чтобы не плодить версии

Главная цель хранения: одна актуальная точка правды.

Практичные варианты:

корпоративная база знаний (если есть контроль версий и права доступа)

репозиторий с версионированием (если в компании принято работать через Git)

структурированная папка с правилами: права, владелец, договорённое именование файлов, журнал изменений

Независимо от инструмента, договоритесь о правилах:

где лежит актуальная версия

кто может менять

как обозначаются черновики

как публикуются утверждённые версии

Критерии готовности «оформленного» и управляемого описания

Описание процесса можно считать оформленным, если выполняются условия:

есть паспорт процесса и согласованные границы

пакет артефактов полный и согласован по смыслу (BPMN и текст не конфликтуют)

у шагов, правил, исключений есть идентификаторы

термины и статусы определены и используются одинаково

есть журнал изменений и понятный статус версии (черновик или baseline)

есть понятный порядок, как вносить изменения и кто принимает решение

Что дальше делать вам, как начинающему бизнес-аналитику

После этой статьи у вас есть практичная «рамка взрослой работы» с процессами:

вы не только описываете процесс, но и умеете выпускать управляемую версию

вы можете проводить согласование как процедуру принятия решения

вы умеете менять процесс без потери качества и трассируемости

Если вы ведёте процесс для автоматизации, следующий логичный шаг вне рамок этого курса: перевод согласованного процесса в требования (например, пользовательские истории, требования к данным, интеграциям и ролям) с сохранением связей S-..., BR-..., EX-....