Матрица ответственности в проекте для чего нужна

Методика RACI: оптимизация распределения полномочий и ответственности

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

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

Матрица RACI представляет собой простой инструмент, используемый для определения ролей и обязанностей и избежания путаницы при исполнении задач или процессов. Используется при управления проектами и для показа обязанностей в состояниях «AS-IS» и «TO-BE».

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

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

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

Таблица 1. Резюме: Критические вопросы модели

Указания к построению матрицы

Матрица ответственности выстраивается в шесть этапов:

Основными принципами принятия решений с помощью RACI являются:

Вертикальный анализ (по функциональным ролям) позволяет выявить соответствующие проблемы: Если у Вас получилось:

При горизонтальном анализе рассматриваются действия Если у вас получилось, что

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

Список литературы

1. Андерсен Б. Бизнес-процессы. Инструменты совершенствования. — М.: РИА «Стандарты и качество», 2014.

2. Деминг В. Эдвардс. Выход из кризиса. — Тверь: Альба, 2009.

3. Дрожжинов В. Реинжиниринг бизнес-процессов в компании // Ваш банкъ. Экономист. — 2012. № 2.

4. Друкер П.Ф. Практика менеджмента: Пер. с англ. — М.: Изд. дом «Вильямс», 2011.

5. Ефремов В.С. Организации, бизнес-системы и стратегическое планирование //Менеджмент в России и за рубежом. — 2013. — № 2.

6. Кальянов Г.Н. Теория и практика реорганизации бизнес-процессов. Серия «Реинжиниринг бизнес-процесса». — М.: СИНТЕГ, 2012.

Источник

RACI матрица как инструмент управления ответственностью. RACI: расшифровка

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

«Под микроскопом»: 4 ключевых роли в каждом проекте

Вам будет интересно: Как сделать описание проекта: пошаговая инструкция

Распределение задач — одна из основных обязанностей менеджера. Но на практике всё обычно выглядит иначе: руководитель просто назначает членов команды с расчётом на то, что специалисты сами решат, кто и что должен делать. Но что происходит, если были сорваны сроки или выпущен некачественный продукт? «Я этим не занимаюсь», «мне этого не говорили»… И никаких полезных действий.

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

R — Responsible

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

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

Вам будет интересно: Автоматизация бизнес-систем: инструменты и технологии

Таких людей в команде может быть несколько. Кроме того, эта роль может комбинироваться с другими. Чаще всего встречается сочетание Accountable + Resbonsible (в переводе — «ответственный + исполнитель»).

A — Accountable

«Подотчётный», или «ответственный» — это главный руководитель проекта. Именно он отвечает за то, чтобы поставленные задачи были выполнены в срок, с требуемым уровнем качества и в рамках выделенного бюджета. Кроме того, A:

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

C — Consulted

Третья роль в матрице RACI — «консультант» (его иногда также называют «куратором»). Наряду с руководителем, он принимает участие в управлении проектом, но занимается в первую очередь решением стратегических вопросов:

Вам будет интересно: Как продать акции и облигации?

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

I — Informed

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

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

Учимся строить RACI-матрицу на примере

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

1. Составляем to do-list

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

2. Выбираем участников команды

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

Вам будет интересно: Контроллинг на предприятии: инструменты, цели и задачи

3. Заполняем таблицу

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

Возьмём за основу наш пример и остановимся на этапе «Дизайн». В данном случае R — исполнитель — только один. В процессе работы он ориентируется на предварительно подготовленный прототип сайта. Поэтому системный архитектор, который занимался его разработкой, на этом этапе выполняет функцию консультанта C. Также свои пожелания могут высказывать аналитик и разработчик. Готовый дизайн утверждается с менеджером проекта (A). А вот тестировщики и системный администратор на этом этапе не принимают никаких решений, а лишь получают информацию о том, как идёт работа, а потому им присваивают роль информируемых — I.

Разновидности модели

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

Здесь к стандартным ролям добавляются ещё две:

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

В этом варианте в матрице появляется одна новая роль — Supportive (S). Её ключевые функции заключаются в обеспечении проекта дополнительными ресурсами, то есть поддержке руководителя и исполнителей.

Идеальное соотношение ролей

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

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

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

С помощью RACI менеджер может быстро обнаружить перегруженных или недостаточно занятых работников, бесполезные должности и участки работы, за которые никто не отвечает. Грамотно составленная матрица позволяет существенно повысить качество организации и контроля над выполнением проектов, а также уменьшить количество конфликтов между исполнителями («Я этим вообще не занимаюсь. «, «Это он должен был сделать. » и т. д.).

Полезные советы

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

Источник

Матрица распределения ответственности или RACI матрица – что это и зачем нужно

Еще один пост для начинающих РМов про нужный и полезный инструмент – RACI матрицу.

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

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

Часто понятие “матрица распределения ответственности” сокращают до просто “матрица ответственности”, но идеологически это не совсем верно. Даже в оригинале инструмент называется Responsibility assignment matrix, то есть подчеркивает то, что его цель – назначить или распределить ответственность. Но называть можно как угодно, вас в любом случае поймут.

Расшифровка RACI:

Пример матрицы распределения ответственности

Самый простой и наглядный пример RACI матрицы проекта “поездка на дачу” (как всегда, взято в сети):

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

А вот более “корпоративный” пример:

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

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

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

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

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

Построить RACI матрицу несложно, все, что нужно, это:

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

Поздравляю, ваша матрица распределения ответственности готова!

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

Другие виды матрицы распределения ответственности

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

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

Вот такие варианты можно встретить чаще всего:

Еще есть куча вариантов с другими буквами и проч., но концепция остается все той же.

Основные ошибки при построении матрицы распределения ответственности

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

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

Используете RACI матрицу у себя? Расскажите!

Шаблон шаблоном, но вообще RACI матрица – это одновременно про управление рисками и про работу со стейкхолдерами, а не просто бумажка ради бумажки.

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

А если вы хотите лучше работать со стейкхолдерами и уметь на них влиять – то посмотрите наш большой курс по управлению стейкхолдерами. Пакет шаблонов в подарок!

Источник

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

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

Традиционные подходы и рекомендации

В руководстве PMBOK (пятое издание) матрица ответственности имеет также иные обозначения: «матричные диаграммы», «матрица RAСI». В отечественной практике этот инструмент часто звучит как матрица распределения ответственности. Под МО в PMI-руководстве понимается некая таблица, в которой показаны ресурсы, назначенные для каждого пакета работ. В ней отображаются связи между членами команды и этапами работ.

Для заполнения МО традиционно применяется методика RAСI. Это аббревиатурное название, сформированное по первым буквам слов: «Исполнитель» (Responsible), «Ответственный» (Accountable), «Консультант» (Consult before doing), «Наблюдатель» (Inform after doing).

В зависимости от масштаба проекта PMBOK допускает использование МО на различных уровнях с разной степенью проработки ответственности членов рабочей группы. Если мы рассматриваем МО высокого уровня, то для построения матрицы привлекаются группы и подразделения команды с одной стороны и крупные компоненты ИСР – с другой. Напротив, МО низкого уровня «спускаются» до детализации распределения ответственности конкретных участников команд вплоть до уровня операций.

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

Подзадачи и ответственность

Предыдущий пример наглядно демонстрирует ситуацию размытия фокусов на ответственности. Как избежать подобной ситуации? Вспомним, коллеги, подраздел, посвященный задачам управления. В нем мы разобрали важную категорию управления – «ответственность». Тогда мы установили, что ответственность ресурса предполагает его право принять и обязанность выполнить задачу, не ссылаясь ни на какие препятствия. Позвольте напомнить пример красноярского охотника, который взялся за задачу доставить к сроку шкурки белок, битых в глаз, но под условием, что число их будет не более 45 вместо 100. Таково было его правило: браться только за то, что он способен сделать реально.

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

Обычно состав формулировок элементов таблицы соответствует функциональной доктрине управления:

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

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

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

Ответственность и полномочия: как избежать ошибок?

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

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

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

Я убежден, что менеджер проекта, который руководствуется при распределении ответственности правилом «Лучше меньше, да лучше» более успешен. Это происходит также благодаря тому, что построение МО реализуется в режиме однозначности. Поэтому каждому PM я советую начинать с более простых форм, постепенно усложняя практику применения.

Источник