Управление изменениями бизнес-процессов в организации

Кому может быть интересно

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

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

Тема управления изменениями появилась не вчера. Однако ее актуальность стала проявляться последние 3-5 лет. Причинами этого в том числе стали политические и экономические события, принципиально изменившие привычные каноческие модели бизнесов в России. Те модели бизнесов, а вместе с ними и процессного управления, которые сложились в 2000-х: сильная ориентированность и зависимость от европейского импорта.

До эпохи COVID-19 (2020) эти модели оставались достаточно устойчивым и сильным изменениям не подвергались. Но после этих событий, и событий, последовавших за ними чуть позднее, российский бизнес был вынужден перестраиваться под новые условия. Это, в свою очередь, потребовало перенастройку бизнес-моделей, а вместе с ними и всех систем, включая процессное управление.

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

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

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

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

Важные вводные

• Мой опыт
  • обратная связь по рекомендациям основана на личном опыте описания и внедрения процессного управления БП консультанта по управлению изменениями в региональных торговых и торгово-производственных компаниях.
• Из практики чаще всего ситуация выглядит:
  • привычные ожидаемые функции IT, задействованные в типовых проектах по анализу бизнес-процессов, в этих компаниях сильно ограничены, а где-то отсутствуют в принципе;
  • штатные отделы для описания и анализа процессного управления полностью отсутствовали. Для этих функций привлекались обычные сотрудники.

Анализ бизнес-процессов. Начало.

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

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

Практика и диагностика.

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

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

По ситуации 1 (когда что-то описано): замечательно, если в качестве ответов удается получить те, что приводится в статье.

Но почти повсеместно это вызывает сложность. Почему? Потому что:

• не всегда удается найти того, кто и ради чего описал процесс. Чаще всего это заканчивается: «Поступило распоряжение сверху», «Кто-то когда-то описал»;
• такие вопросы, как «цели бизнеса», как правило, мало известны большинству участников процесса. И даже руководителям среднего звена (а они часто – владельцы процессов, хотя и не знают об этом…);
• цели «улучшений» неочевидны, так как часто формулируются «чем больше/меньше, тем лучше» и не факт, что будут внедрены (ибо описать не означает внедрить);

Как справедливо отмечается в статье начинать анализ необходимо с “as Is”.

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

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

• синхронизируется инфополе о процессе всеми его участниками (все согласны с ответами на обязательные вопросы (в т.ч. ценность, архитектура, входы/выходы, потребитель, и т.д.). Пример таких такого подхода, например, рассматривается в статье “Входы и выходы бизнес-процесса: как правильно определить границы и избежать типичных ошибок”
• определяются зоны риска и последствия невыполнения или некорректного выполнения процесса («что будет, если…» и будет ли что-либо…)

Такой подход способен дать первые, быстрые и понятные выгоды анализа:

- «Время и нервы». В 90% случаев это сразу выявляет немало постоянно возникающих проблем из-за разного восприятия и рассогласованности действий («а народ-то не знал, что так нужно…»).

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

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

По ситуации 2 (не описаны совсем): тогда анализ начинается с их идентификации

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

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

Приоритеты.

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

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

Практика и диагностика.

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

Какие процессы считать приоритетными и по каким критериям?

Подробно критерии и методика ранжирования процессов описаны в Методике ранжирования и приоритета бизнес-процессов.

Приоритетные - те, что формируют главную ценность. Поэтому в подавляющем большинстве торговых/торгово-производственных бизнесов, где я работал, как консультант, такой end-to-end процесс – «Продажи» (он же «Реализация», он же «обработка «Заявки» и т.д.).

Он формирует главную ценность для клиента – отработку запроса с результатом получения товара и/или услуги в обмен на деньги. Но это не означает, что другими процессами можно не заниматься. Это вопрос приоритезации.

В том, что он «end-to-end» процесс и кроется главная проблема. Так как часто содержит вложенные и связанные подпроцессы. Поэтому его описание/диагностика/анализ занимает много времени и других ресурсов.

А еще анализ одного «end-to-end» процесса практически всегда приводит к изменению остальные.

В других случаях приоритет в выборе процессов там, где “болит” больше всего. Это может быть и локальный процесс. Однако, в 99% случаях изменить только его не получится. Он - производная от основного «end-to-end», а значит, изменили его - нужно редактировать и основной «end-to-end».

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

Как правило, основным ограничением описания является время. Даже в случае, когда Заказчик (в т. ч. и внутренний/корпоративный) соглашается со сроками описания в несколько месяцев, он ожидает результата «чем скорее, тем лучше». При этом еще и часто путая результат описания с результатом внедрения.

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

Опыт решения.

Как быть в такой ситуации? Запускать параллельно основной «end-to-end» и 1-2 локальных небольших (внутри одной бизнес-функции). Например, БП «Маркетинговые исследования» или «Закрытие запроса на вакансию».

В результате можно получить первые описанные/проанализированные процессы достаточно быстро, приступив к их внедрению. Это снимет вечное «когда мы увидим хотя бы какой-то результат?». Тогда как основной «end-to-end» будет описываться/анализироваться своим чередом.

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

Управление изменениями бизнес процессов в организации и кросс функциональные команды.

Рекомендация 3: Анализ бизнес-процессов требует кросс-функциональной команды. В нее должны входить представители всех ключевых функций, которые участвуют в end-to-end процессе, а также эксперт по предметной области и владелец процесса.

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

Практика и диагностика.

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

Готовая основа для такого разговора — Положение о владельце процесса с закреплёнными статусом, функциями и правами.

Опыт решения.

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

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

Но проблема всплывала с неожиданной стороны: часто руководителем проекта (РП) по описанию БП назначают сотрудника, который не является даже руководителем структуры. Этими вопросами просто неохота никому заниматься. Нет на это ни выделенных структур, ни руководителей (о чем писалось в вводных к статье).

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

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

Привлечение внешнего консультанта

Рекомендация 4: Консультант полезен, если внутри компании нет метода или опыта. Он даёт практики, примеры и структуру. Но консультант не заменит внутренней экспертизы по специфике компании. Поэтому:

- используем консультантов как поставщиков практик и шаблонов;

- обязательно вовлекаем внутреннюю команду, чтобы адаптировать решения;

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

Практика и диагностика.

Рассматриваю ситуацию взаимодействия с консультантом с обеих сторон:

1. Со стороны компании. Главные ожидания при взаимодействии с консультантом - повышение производительности при решении задачи за счет экономии времени и сокращения рисков. Другими словами “быстрее и правильнее”. Разумеется, с учетом специфики бизнеса. Консультант, владеющий методологиями, инструментами и опытом решения аналогичных задач при взаимодействии с командой компании должен помочь обеспечить эту производительность.

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

Опыт решения.

Главный риск компании:

• купить “воздух”;
• начать работать не с тем, не так;
• получить не то.

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

Главный риск консультанта:

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

Решение:

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

Блиц (короткая рекомендация - короткий ответ)

Заключение.

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

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