Анализ бизнес процессов в проектировании: как довести модель до регламента, IT и пилота

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

Раздел 6.3 ABPMP CBOK «Составляющие проектирования процессов» как раз про это: что и в какой логической последовательности делать, чтобы моделирование превратилось в рабочую трансформацию, а не осталось обсуждением «на уровне макета». Ниже собрали эту логику как практическое руководство: шаги и решения, которые помогают пройти путь от подготовки до тестирования и опытной эксплуатации.

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

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

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

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

• Приоритеты по процессам (что именно трансформируем первым);
• Области ограничений (что нельзя трогать или какие рамки проекта нельзя нарушать).

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

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

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

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

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

• Перечень задач в ходе процесса;
• Перечень шагов, которые проходит процесс.

Авторы отдельно подчеркивают: не стоит начинать с нагромождения IT-атрибутов, исполнителей и всех возможных параметров. Если все проходит гладко и сразу понятно, можно добавлять детали, но основной путь лучше строить «без лишнего шума».

Как именно мы определяем действия, чтобы модель была рабочей:

• Сначала выделяем основной сценарий и базовые действия.
• Дальше используем подходы к параллельности и выносим части в подпроцессы.
• После того как структура действий понятна, добавляем атрибуты и то, что их окружает (роли, исполнители, данные).

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

Не мельчим: один исполнитель, один «черный ящик» вместо микроскопа

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

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

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

Уровень абстракции нужен всегда. Мы стараемся не мельчить без причины, потому что задача модели это помочь договориться, а не «все измерить микрометром».

Оптимизация тоже не «внутри кнопки»: сначала процесс, потом операции

Разговор про действия автоматически приводит к вопросу оптимизации. Здесь важна логика:

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

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

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

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

На этом этапе мы делаем то, что обычно спасает и от спорных решений, и от «полетов фантазии». Это сравнение.

Минимально необходимая база:

• Смоделировать процесс «как есть» (текущую реальность);
• Смоделировать процесс «как будет» (целевую модель);
• Сравнить две модели, чтобы понять, что именно улучшить и зачем.

Сравнение нужно не только аналитически. Оно нужно, чтобы:

• Объяснить улучшения стейкхолдерам;
• Показать эффект и результат людям, которые влияют на процесс и отвечают за решение;
• Обосновать изменения, когда появляются вопросы «почему так» или «а какие последствия для нас».

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

Для чего полезны сценарии и вариации

Цель сравнения это не всегда найти «один единственный» идеальный процесс. Часто полезно рассмотреть несколько сценариев, вариаций исполнения и затем сравнить их.

В описываемом подходе сценарии помогают:

• Посмотреть разные варианты исполнения;
• Оценить стоимость выбранной вариации (в терминах инструментария и расчетов);
• Выбрать вариант, который отвечает приоритетам трансформации.

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

Когда сравнение помогает «обрубить» неправильную автоматизацию

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

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

И вот тут сравнение выступает якорем: оно возвращает к вопросу цели и проблематики.

Проектирование на физическом уровне: «как» вместо «за что»

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

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

В практике это означает, что мы учитываем:

• Цели, ради которых мы проектируем процесс;
• Степень детализации там, где это дает ценность;
• Масштаб изменений.

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

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

Бизнес-правила: мозги процесса, которые должны быть умными, а не многословными

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

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

В модели такие правила обычно проявляются как:

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

Слишком много развилок это красный флаг

Проблемы при установке правил типовые:

• Правила могут быть сложными;
• Правила могут не закрывать риски;
• Они могут не приносить профита;
• И самая «любимая» ловушка это желание отразить в схеме абсолютно все развилки и мелочи сразу.

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

Но задача аналитика не просто перенести правило на схему. Надо разобрать:

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

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

Зачем правила нужны на самом деле

Правила обычно применяются, чтобы:

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

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

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

Хорошее правило не многословное. Оно отвечает на вопрос «зачем?». И чем сложнее система, тем проще должны быть правила. Частая ошибка это когда:

• Система сложная;
• А правила еще сложнее;
• В итоге получается путь в никуда.

Практическая формула проверки:

• Каждую развилку проверяем вопросом «зачем это сделано»;
• Выясняем, что правило должно извлечь или защитить;
• Не пытаемся описать всю вселенную сразу.

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

ИТ-инфраструктура: контекст решения, данные и автоматизация только после «обкатки»

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

• Как это работает;
• Возможно ли автоматизировать;
• Какие данные доступны и где они живут;
• Какие есть требования по безопасности, NDA и конфиденциальности.

Но в практической интерпретации обсуждается более прикладной взгляд: ИТ-инфраструктура это уровень контекста решения.

Что именно нужно прояснить с IT

Три блока, которые лучше всего держать в голове:

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

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

Ключевой принцип: «автоматизируй только то, что уже обкатано»

Одна из самых сильных мыслей в обсуждении это предупреждение:

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

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

Звучит простое, но жесткое правило: IT стоит привлекать тогда, когда процесс можно гарантированно автоматизировать, а не просто когда идея кажется привлекательной.

Пример практической «протяжки»

В качестве кейса приводили ситуацию, когда строили регулярный менеджмент и захотели фиксировать результаты встреч с ключевыми клиентами. Сначала сделали простую Google-форму, которая менялась «миллиард раз» во время уточнений. Данные собирались в таблицу, отчеты формировались для руководителя и для сотрудника.

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

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

Считать IT панацеей нельзя

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

• Не нужно ничего автоматизировать, а достаточно правильно настроить работу в рамках текущего процесса;
• Иногда дешевле нанять человека, чем обслуживать «слой» IT вокруг задачи;
• Иногда автоматизация вообще не закрывает проблему, потому что проблема была в другом месте процесса.

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

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

План внедрения, тестирование и пилот: превращаем модель в реальность

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

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

С практической стороны план внедрения должен отвечать на вопросы:

• Кто участвует в изменениях и как распределяются ответственности;
• Какие артефакты готовы к запуску (регламенты, инструкции, правила, модель);
• Что именно тестируем и как оцениваем результат;
• Как организуем пилот: где границы и какие метрики успеха.

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

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

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

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

• Подготовка: у нас есть результаты анализа, приоритеты и ограничения проекта.
• Действия в целевой модели: определяем шаги без микроскопа, выбираем уровень абстракции, учитываем параллельность и подпроцессы.
• Сравнение: фиксируем «как есть» и «как будет», сравниваем сценарии и объясняем эффект стейкхолдерам.
• Физический уровень: уточняем «как», не дробим операции без ценности.
• Правила: описываем точки решений, проверяем «зачем?», не перегружаем мелкими развилками.
• ИТ-инфраструктура: выясняем системы, данные, конфиденциальность и лишь потом планируем автоматизацию.
• Автоматизация без паники: сначала обкатка процесса, потом IT; автоматизация должна быть инвестицией с положительной выгодой.
• Внедрение: план, тестирование, опытная эксплуатация и пилот, с понятными метриками и границами.

FAQ по проектированию и анализу бизнес процессов

Нужно ли моделировать сразу с IT-атрибутами, исполнителями и деталями?

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

Как понять, на каком уровне абстракции описывать действия?

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

Зачем обязательно сравнивать «как есть» и «как будет»?

Чтобы выявить, что именно улучшится, объяснить эффект стейкхолдерам и принять решения на основе разницы текущей и целевой моделей. Сравнение помогает и руководству, и тем, кто влияет на процесс, увидеть результат в терминах «было и станет».

Когда можно переходить к оптимизации операций, а не только процесса?

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

Что делать, если в процессе много развилок и «исторических» правил?

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

Можно ли сразу автоматизировать целевую модель?

Обычно нет. Лучше сначала «обкатать» процесс, протянуть его через простые инструменты, стабилизировать данные и поведение людей, а потом переносить в полноценную IT-автоматизацию. Автоматизация плохого процесса делает его плохим автоматизированным процессом.

Как оценивать, стоит ли автоматизировать шаг?

В обсуждении подчеркивается финансовая логика: автоматизация это инвестиция, значит нужна положительная выгода. Можно сравнивать варианты в денежном выражении (например, через P&L), потому что с деньгами проще сравнивать альтернативы, чем с ощущениями.

Заключение: модель это не цель, а дисциплина и платформа для внедрения

Мы возвращаемся к простой формуле: моделирование помогает договориться и дисциплинировать процесс, но ценность появляется только тогда, когда мы доводим проектирование до внедрения. Поэтому анализ бизнес процессов это не просто «снять картинку», а создать путь от подготовки и определения действий до правил, ИТ-контекста и пилотного запуска.

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

Статья подготовлена по встрече книжного клуба Stormbpmn, где мы разбирали раздел 6.3 ABPMP CBOK. Запись эфира есть на YouTube, а все главы с видео и статьями собраны в «Разборе BPM CBOK».