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

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

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

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

Начинаем не со схемы, а с плана внедрения

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

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

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

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

Поэтому в плане внедрения должны быть предусмотрены мероприятия по:

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

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

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

Определяем, что именно будет затронуто

Под системами не стоит понимать только ИТ. В анализ бизнес процессов стоит включать все функциональные области, на которые повлияет изменение:

• Информационные системы и интеграции;
• Организационную структуру;
• Роли и зоны ответственности;
• Регламенты, инструкции и формы документов;
• Метрики, отчётность и контрольные процедуры;
• Смежные процессы и подразделения.

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

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

Проверяем процесс до массового запуска

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

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

Продумываем нестандартные сценарии

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

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

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

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

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

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

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

Фиксируем критерии успешного пилота

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

Полезно заранее разделить обратную связь на три корзины:

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

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

Используем имитационное моделирование там, где оно действительно полезно

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

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

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

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

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

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

Смотрим на процесс снаружи, а не из любимого отдела

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

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

Анализ бизнес процессов с позиции outside-in помогает задать правильные вопросы:

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

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

Определяем ценность до того, как начинаем что-то убирать

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

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

Один и тот же продукт может быть ценен разным клиентам по-разному. Условное дерево в парке даёт пожилой паре тень, детям место для игры, а кому-то красивый фон для фотографии. Сам объект один, но ожидания разные. Поэтому недостаточно сказать «у продукта есть ценность». Надо разобраться, какая именно ценность нужна конкретному сегменту.

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

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

Проверяем нормативы и не оптимизируем нарушение закона

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

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

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

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

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

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

Перед тем как сокращать переходы, нужно понять:

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

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

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

Для более системной работы с этой темой пригодится материал «Анализ бизнес-процессов и проектирование изменений».

Учитываем реальность организационной структуры

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

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

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

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

Главный вывод: принципы не заменяют мышление

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

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

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

1. Понимаем, какую проблему и для кого решаем.
2. Смотрим на процесс, клиента и всю связанную систему.
3. Проектируем изменение с учётом ролей, инструментов, рисков и ограничений.
4. Готовим людей, данные, документацию и каналы обратной связи.
5. Тестируем не только счастливый путь, но и отклонения.
6. Запускаем пилот, измеряем результат и отделяем блокеры от бантиков.
7. Масштабируем только то, что действительно работает.

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

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

Когда нужно начинать планировать внедрение изменений?

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

Чем опытная эксплуатация отличается от тестирования?

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

Нужно ли всегда сокращать количество передач ответственности?

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

Для каких процессов подходит имитационное моделирование?

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

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

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

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