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

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

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

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

Сначала определяем, что мы вообще называем анализом процесса

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

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

Поэтому нормальный анализ отвечает как минимум на такие вопросы:

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

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

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

Проводим анализ как проект, а не как бесконечное исследование

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

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

• Каков объем анализа?
• Где границы процесса?
• Какие ресурсы есть у команды?
• Кто является ключевыми участниками и доступны ли они?
• Какие есть риски у проекта анализа?
• Что будет результатом и в каком виде?

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

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

Проверяем главный риск анализа, аналитический паралич

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

Как это выглядит в реальности:

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

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

Особенно часто это происходит в двух случаях.

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

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

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

Рабочие способы довольно приземленные:

• Заранее зафиксировать границы анализа.
• Согласовать цель анализа и ожидаемый результат.
• Определить уровень детализации, достаточный для принятия решений.
• Регулярно возвращать команду к вопросу “зачем”.
• Фокусироваться на наиболее острых и значимых проблемах, а не на всем подряд.

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

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

После этого половина “очень интересных направлений” обычно сама отваливается.

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

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

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

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

• давайте внедрим новую систему;
• давайте автоматизируем;
• давайте добавим согласование;
• давайте сделаем RPA;
• давайте вообще аутсорсить эту функцию.

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

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

Как “парковать” идеи, чтобы не потерять и не дать им увести встречу

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

Такой “паркинг идей” можно вести по-разному:

• в backlog;
• в карточке процесса;
• на странице в Confluence;
• в Excel-реестре;
• в отдельном разделе аналитического артефакта.

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

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

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

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

Оформляем результат анализа так, чтобы по нему можно было принимать решения

После анализа должен остаться не просто “объем проделанной работы”, а внятный результат. И здесь часто начинается спор: надо ли в результат анализа включать варианты дальнейших действий, или достаточно только описать текущее состояние и проблемы.

На практике крайности здесь одинаково плохи.

Если ограничиться только сухим описанием текущего состояния, заказчики почти сразу зададут логичный вопрос: “Хорошо, а что делать дальше?”

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

Поэтому рабочая логика обычно такая:

1. Сначала формируем и согласуем результаты анализа.
2. Потом на их основе переходим к разработке плана действий или к проектированию нового процесса.

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

Что обычно должно быть в результате анализа

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

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

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

Фиксируем ключевые принципы качественного анализа процессов

Если собрать основные мысли в короткий практический чек-лист, получится примерно следующее.

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

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

Нужна поддержка руководства. Особенно если процесс кросс-функциональный и затрагивает несколько подразделений. Без этого аналитик быстро упирается в стену локальных интересов.

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

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

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

Для опытных людей эти мысли звучат почти как банальность. Из серии “если устал, отдохни; если голоден, поешь”. Но в реальной работе именно такие банальности почему-то чаще всего и забываются.

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

После анализа начинается другая работа: проектирование процесса. Это уже не просто изучение текущего состояния, а создание спецификации нового или улучшенного процесса.

Здесь в фокусе оказываются:

• бизнес-цели;
• целевые показатели;
• информационные системы и платформы;
• объекты и источники данных;
• финансовые ограничения и эффекты;
• операционный контроль;
• распределение ответственности;
• варианты исполнения процесса.

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

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

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

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

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

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

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

Формулируем цели проектирования без романтики и без тумана

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

Согласовать процесс

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

Найти проблемные места

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

Повысить производительность

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

Дать рынку лучший результат

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

Встроить риск и качество

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

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

Выбираем участников проектирования процесса правильно

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

Кого обычно нужно учитывать.

Высшее руководство

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

Команда процесса или проектная команда

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

Предметные эксперты

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

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

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

Руководитель проекта

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

Фасилитатор

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

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

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

Трезво смотрим на историю с владельцами процессов

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

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

Почему так происходит:

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

Это не значит, что владельцев процессов не бывает вообще. Бывают. Есть компании, где они действительно собирают метрики, анализируют отклонения, инициируют улучшения и управляют процессом как объектом. Но это скорее признак определенной зрелости, а не стартовая настройка “по умолчанию”.

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

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

Учитываем зрелость ситуации, а не только “зрелость компании”

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

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

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

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

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

Используем простой практический чек-лист перед стартом

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

• Какова бизнес-цель анализа?
• Какой процесс или часть процесса в фокусе?
• Где границы анализа?
• Какие риски у самого анализа?
• Какой уровень детализации действительно нужен?
• Кто должен участвовать?
• Есть ли поддержка руководства?
• Какие метрики важны?
• Как будем фиксировать идеи, чтобы они не уводили в сторону?
• Какой артефакт будет результатом анализа?
• Кто и как согласует результаты?
• Когда после анализа принимается решение о проектировании изменений?

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

FAQ

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

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

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

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

Что должно быть результатом анализа процесса?

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

Когда анализ переходит в проектирование процесса?

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

Кто обязательно должен участвовать в проектировании процесса?

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

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

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

Всегда ли нужен глубокий анализ бизнес процессов перед изменениями?

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

Итог

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

Нормальная логика такая:

1. Определили цель и границы;
2. Провели анализ как проект;
3. Не попали в аналитический паралич;
4. Не смешали анализ с проектированием;
5. Согласовали результаты;
6. Только потом перешли к проектированию процесса и изменениям.

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

Если совсем коротко, то хороший анализ бизнес процессов это не “опишите нам все”. Это “помогите нам понять главное, не потерять важное и перейти к изменениям вовремя”. Вот тогда от него действительно появляется польза.