Анализ бизнес процессов: как спроектировать поток без потерь, очередей и лишней работы

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

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

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

Начните с единой точки ответственности и документации

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

Единое контактное лицо не обязано лично выполнять каждую операцию. Его задача другая:

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

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

Подойдёт Confluence, Notion, корпоративная база знаний или другая доступная среда. В ней полезно хранить:

• Цель и границы процесса;
• Его владельца и ключевых участников;
• Актуальную схему;
• Правила выполнения и шаблоны;
• Входы и выходы;
• Известные ограничения и принятые решения;
• Историю существенных изменений.

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

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

Разделяйте разные сценарии, а не собирайте монстра на одной схеме

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

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

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

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

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

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

Смотрите на непрерывный поток создания ценности

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

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

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

Для этого полезна карта потока создания ценности, или VSM, Value Stream Mapping. Её сильная сторона в том, что она одновременно показывает операционный поток, информационный поток и временную картину.

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

VSM помогает задать нужные вопросы:

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

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

Ищите потери, а не только нарушения регламента

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

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

Перепроизводство

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

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

Ожидание

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

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

Транспортировка и лишние передачи

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

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

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

Избыточная обработка

Избыточная обработка не всегда означает, что кто-то делает работу слишком долго. Скорее это применение неподходящего, слишком дорогого или чрезмерно сложного способа там, где достаточно простого решения.

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

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

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

Избыточные запасы и незавершённая работа

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

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

Такие запасы:

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

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

Ненужные движения

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

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

Дефекты и переделка

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

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

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

Неиспользованный человеческий потенциал

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

Это плохая идея. У исполнителей обычно есть знания о реальных исключениях, неудобных местах, скрытых задержках и точках, где работа регулярно идёт не так, как предполагает регламент.

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

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

Настройте вытягивающий поток вместо работы впрок

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

Именно на этой логике строятся многие идеи Toyota Production System. Финальная сборка формирует потребность. Предыдущий участок получает запрос и создаёт свою потребность для ещё более раннего звена. Так запрос последовательно идёт вверх по цепочке, а материалы и результаты движутся в обратную сторону.

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

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

Подбирайте размер пакета по контексту

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

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

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

Поэтому правильный вопрос звучит не «как сделать пакет минимальным?», а «какой размер пакета оптимален в этом процессе?»

При выборе полезно учитывать:

• Стоимость переключения между задачами;
• Критичность времени ожидания;
• Сроки обязательств и SLA;
• Частоту поступления работы;
• Стоимость подготовки и передачи пакета;
• Возможность выпустить результат частично;
• Нагрузку и доступность участников.

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

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

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

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

Для каждого существенного хендовера стоит проверить:

• Что именно передаётся;
• Зачем это нужно следующему этапу;
• Достаточно ли данных для начала работы;
• Нет ли лишних атрибутов;
• В какой форме результат удобнее получить;
• Когда он должен поступить;
• Кто отвечает за качество передачи.

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

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

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

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

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

Двойной ввод почти гарантированно создаёт проблемы:

• Данные начинают расходиться;
• Часть атрибутов отсутствует в одной из систем;
• Непонятно, какой источник считать актуальным;
• Управленческая отчётность становится сомнительной;
• Возникает дополнительная работа по сверке и исправлению.

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

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

Соберите результаты анализа в рабочий план улучшений

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

Рабочая последовательность может быть такой:

1. Определяем границы процесса, клиента, результат и владельца.
2. Разделяем принципиально разные сценарии и убираем лишнюю сложность со схемы.
3. Строим картину потока: операции, передачи, буферы, ожидание, данные.
4. Ищем потери: перепроизводство, ожидание, транспортировку, избыточную обработку, запасы, лишние движения, дефекты и неиспользованный потенциал людей.
5. Находим ограничения и причины накопления очередей.
6. Проверяем размер пакетов и правила запуска работы.
7. Согласуем входы, выходы, шаблоны и критерии качества передачи.
8. Устраняем двойной ввод и определяем первичные источники данных.
9. Вовлекаем исполнителей и тестируем изменения на реальном процессе.

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

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

Частые вопросы про анализ бизнес процессов

С чего начать анализ бизнес процессов?

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

Нужно ли всегда разделять разные сценарии на отдельные процессы?

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

Чем VSM отличается от обычной BPMN-схемы?

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

Почему избыточные запасы опасны не только для производства?

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

Всегда ли нужно уменьшать размер пакета до одной единицы?

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

Что значит однократная регистрация информации?

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

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