Практические шаги при формировании матриц ответственности

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

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

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

Постановка задачи формирования матриц

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

Чем масштабнее задача, чем больше функций она затрагивает, тем выше должен быть уровень принятия решения о запуске проекта. Если речь идет о работе внутри одного функционального направления, например, блока Производство, то в принципе достаточно решения руководителя функции — Директора по производству или Заместителя Генерального директора по производству. Такое решение необязательно выносить на более высокий уровень.

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

Формальное решение, с одной стороны, кажется излишней бюрократией, но во многих компаниях по-другому просто ничего не работает. В рамках проекта, о котором я писал выше, у нас были примеры, когда мы выходили с запросом о формировании матриц на уровень ГД-2, ГД-3 — и руководители на этих уровнях в принципе ничего не знали о поставленной задаче. Это, к сожалению, болезнь многих крупных холдингов и корпораций, когда информация очень медленно спускается на уровень среднего менеджмента. В этом случае протокол или решение СД позволяет создать пространство для диалога и в принципе начать решать задачу по формированию матриц.

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

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

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

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

Третье условие — нужно понимать, какова основная роль функционального направления в работе компании. Какие ожидания есть у руководства, какие сложности возникали в последнее время. Об этом мы говорили в предыдущей статье — важно быть бизнес-партнёром, находиться в контексте происходящего в компании, понимать, какие «косяки» вылезали в функциональном направлении в последнее время. Неплохо, например, посмотреть КПЭ функционального руководителя, понять, что для него важно и что беспокоит. Реальные ситуации помогут перейти от общих слов к конкретике, наполнить матрицу смыслом и сделать рабочим инструментом для решения практических задач и разрешения потенциальных конфликтных ситуаций (которые неизбежно возникают в любой компании).

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

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

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

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

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

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

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

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

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

Следующий практический вывод: уровень декомпозиции – достаточен для задачи.

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

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

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

Третий практический вывод: соответствие матрицы текущей нормативной документации.

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

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

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

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

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

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

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

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

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

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

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

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