Что такое матрица ответственности проекта
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. Выбираем участников команды
Здесь нужно ответить на вопрос: «Кто будет заниматься этим проектом?». По горизонтали необходимо выписать всех сотрудников и/или отделов, которые участвуют в реализации на всех этапах, — от планирования до презентации результатов и сдачи отчёта.
| Этапы | Аналитик | Дизайнер | Сис. архитектор | Разработчик | Тестировщик | Сис. админ. | Project manager |
|---|---|---|---|---|---|---|---|
| Техническое задание | |||||||
| Прототип | |||||||
| Дизайн | |||||||
| Программный код | |||||||
| Отчёт о тестировании | |||||||
| Презентация сайта |
Вам будет интересно: Контроллинг на предприятии: инструменты, цели и задачи
3. Заполняем таблицу
После этого можно приступать к распределению функций. Для этого нужно иметь чёткое представление о каждом этапе работы и о том, как происходит работа в командах.
Возьмём за основу наш пример и остановимся на этапе «Дизайн». В данном случае R — исполнитель — только один. В процессе работы он ориентируется на предварительно подготовленный прототип сайта. Поэтому системный архитектор, который занимался его разработкой, на этом этапе выполняет функцию консультанта C. Также свои пожелания могут высказывать аналитик и разработчик. Готовый дизайн утверждается с менеджером проекта (A). А вот тестировщики и системный администратор на этом этапе не принимают никаких решений, а лишь получают информацию о том, как идёт работа, а потому им присваивают роль информируемых — I.
| Этапы | Аналитик | Дизайнер | Сис. архитектор | Разработчик | Тестировщик | Сис. админ. | Project manager |
|---|---|---|---|---|---|---|---|
| Техническое задание | R | I | C | C | I | C | A |
| Прототип | C | I | R | C | I | I | A |
| Дизайн | C | R | C | C | I | I | A |
| Программный код | C | I | C | AR | I | I | I |
| Отчёт о тестировании | C | C | C | C | AR | I | I |
| Презентация сайта | C | I | C | C | I | AR | I |
Разновидности модели
В большинстве случаев можно обойтись стандартной матрицей. Однако при работе над более сложными проектами иногда возникает необходимость в дополнительных ролях. Поэтому в последние годы появилось 2 расширенных варианта диаграммы ответственности.
Здесь к стандартным ролям добавляются ещё две:
Благодаря усиленному контролю и более тесному контакту с клиентом, данная модель оптимально подходит для технически сложных или масштабных проектов, над которыми работают десятки (или даже сотни) людей.
В этом варианте в матрице появляется одна новая роль — Supportive (S). Её ключевые функции заключаются в обеспечении проекта дополнительными ресурсами, то есть поддержке руководителя и исполнителей.
Идеальное соотношение ролей
Матрица RACI составляется не только чтобы знать, кого «репрессировать» в случае каких-то проблем. Ещё на этапе планирования с помощью этой таблицы вы можете увидеть слабые места в организации рабочего процесса.
Вертикальный анализ позволяет увидеть обязанности и полномочия каждого из участников проекта, объективно оценить уровень нагрузки:
Горизонтальный анализ, в свою очередь, демонстрирует качество организации работы на каждом этапе. Здесь тоже часто возникают проблемы:
С помощью RACI менеджер может быстро обнаружить перегруженных или недостаточно занятых работников, бесполезные должности и участки работы, за которые никто не отвечает. Грамотно составленная матрица позволяет существенно повысить качество организации и контроля над выполнением проектов, а также уменьшить количество конфликтов между исполнителями («Я этим вообще не занимаюсь. «, «Это он должен был сделать. » и т. д.).
Полезные советы
Чтобы матрица RACI выполняла свои функции и обеспечивала эффективную бесперебойную работу в компании, нужно помнить о нескольких важных моментах.
Планирование человеческих ресурсов проекта
Определение ролей проекта
При распределении ролей и ответственности, необходимых для выполнения проекта, следует учитывать следующие моменты.
Формируя команду управления проектом, необходимо определить ключевых лиц проекта, принимающих решения.
Бизнес- менеджер отвечает за успешное выполнение проекта и представляет исполнителя в его договорных отношениях с заказчиком. Менеджер проекта ( руководитель проекта ) отвечает как за успехи, так и за неудачи проекта. В его задачи входит управление сроками, стоимостью, качеством работ с целью удовлетворения ожиданий заказчика и достижения бизнес-целей исполнителя.
Команда управления проектом включает координатора проекта, администратора проекта, менеджера по конфигурации. Для крупных проектов к выполнению каждой из этих ролей могут быть привлечено нескольких человек. На небольших проектах менеджер проекта может совмещать несколько ролей. Масштабные проекты предполагают наличие менеджера по качеству, который ответственен перед бизнес-менеджером исполнителя.
В крупных проектах могут быть организованы комитет по управлению, комитет по контролю за изменениями, комитет по анализу спорных вопросов [8].
Приведенный список ключевых ролей команды управления проектом является необходимым для управления работами при внедрении информационной системы. Возможны некоторые модификации состава команды в зависимости от сложности и масштабности проекта, например, при необходимости можно включать в нее заместителя руководителя проекта, руководителей функциональных направлений (финансы, логистика, персонал и т. д.).
Состав команды управления должен быть достаточным, чтобы осуществлять [11]:
На стадии планирования в рамках процесса управления человеческими ресурсами не предусматривается долгосрочное планирование, а составляется план для реализации первого этапа проекта. Основными задачами являются разработка организационной структуры проекта и подбор персонала.
Работа по планированию организационной структуры проводится менеджером проекта со стороны исполнителя совместно с менеджером со стороны заказчика. Путем переговоров достигается соглашение об уровне, на котором должно производиться утверждение выделяемых ресурсов заказчика и обсуждение требований к членам команды исполнителя. Администратор проекта фиксирует результаты переговоров.
Иерархические организационные диаграммы являются простым и наглядным инструментом для определения иерархии подотчетности, начиная с нижнего уровня организации до руководителя проекта.
Матрица ответственности проекта
Построение матрицы ответственности
По вертикали в матрице отражаются только основные работы проекта (не ниже уровня 2-3 ИСР ), но с достаточной степенью детализации для обеспечения возможности указывать разные роли, необходимые для выполнения этих работ. Когда речь идет о крупных проектах и программах, может возникнуть необходимость разработать несколько матриц ответственности с различной степенью детализации.
С помощью кодов в ячейках на пересечении соответствующих столбцов с ролями и строк с работами проекта указать степень участия, формальные полномочия и распределение ответственности за выполнение каждой операции. Четкое указание разных уровней формальных полномочий бывает особенно полезно в ситуации, когда множество членов проектной команды желает предъявить особые требования к проекту.
| Обозначение | Расшифровка | Описание |
|---|---|---|
| Исп. (R) | Исполнитель (Responsible) | Несет ответственность за непосредственное исполнение задачи. К каждой задаче должно быть приписано не менее одного исполнителя |
| Утв. (A) | Утверждающий (Accountable) | Отвечает за конечный результат перед вышестоящим руководством. На каждую работу должен быть назначен строго один подотчетный |
| Cогл. (C) | Согласующий (Consulted) | Согласует принимаемые решения, взаимодействие с ним носит двусторонний характер |
| Н. (I) | Наблюдатель (Informed) | Его информируют об уже принятом решении, взаимодействие с ним носит односторонний характер |
| Функциональные обязанности | Куратор проекта (Спонсор) | Руководитель проекта | Архитектор системы | Администратор проекта | |||||
|---|---|---|---|---|---|---|---|---|---|
| Планирование | |||||||||
| Разработка и периодическая актуализация плана | + | + | |||||||
| Утверждение плана | + | ||||||||
| Управление командой проекта | |||||||||
| Назначение сотрудника на роль Руководителя проекта | + | ||||||||
| Формирование команды проекта | + | ||||||||
| Определение квалификационных требова ний и состава рабочих групп специалистов по функциональности ИС | + | ||||||||
| Обеспечение выделения необходимых ресурсов для выполнения проекта | + | ||||||||
| Непосредственное руководство Командой проекта | + | ||||||||
| Формирование предложений по стимулированию Команды проекта | + | ||||||||
| Обеспечение стимулирования Команды проекта | + | ||||||||
| Организация выполнения работ | |||||||||
| Организация взаимодействия с Заказчиком и обеспечение всех необходимых коммуникационных связей с другими участниками проекта | + | ||||||||
| Организация подготовки, согласования и утверждения всей технической документации, необходимой для создания ИС в рамках проекта | + | ||||||||
| Организация, проведение и документирование процедур передачи Заказчику разработанной ИС | + | + | |||||||
| Рассмотрение и утверждение регламентирующих документов, необходимых для организации и выполнения проекта | + | ||||||||
| Ведение организационно-распорядительной и отчетной документации. Поддержание в актуальном состоянии списка команды проекта | + | ||||||||
| Обеспечение команды проекта необходимыми информационными материалами | + | ||||||||
| Материально-техническое и хозяйственное обеспечение команды проекта | + | ||||||||
| Контроль хода выполнения проекта | |||||||||
| Организация и проведение совещаний по обсуждению хода работ проекта | + | ||||||||
| Подготовка и предоставление Куратору отчетов о ходе работ проекта | + | ||||||||
| Получение и анализ сводной отчетности о ходе реализации проекта | + | ||||||||
| Контроль соответствия результатов проекта Техническому заданию на разработку ИС | + | ||||||||
| Согласование фактических трудозатрат специалистов при исполнении проекта | + | + |
После утверждения матрицы ответственности все дальнейшие изменения в ней должны проходить через процедуру интегрированного управления изменениями при участии авторов первоначальной версии.
Преимущество использования структурированного подхода к изменению матрицы ответственности состоит в том, что руководитель проекта получает актуальный документ, на который он может ссылаться при возникновении тех или иных спорных ситуаций, касающихся распределения полномочий в проекте.
В частности, матрица ответственности может быть использована для распределения основных функциональных обязанностей. Так, в табл. 6.2 в левом столбце перечислены функциональные обязанности, соответствующие проектным работам, список которых составлен на основе используемой методологии и накопленного проектного опыта, а в правую часть таблицы вносится отметка о степени ответственности и участия каждого из члена группы управления проектом в исполнении соответствующей функции.
Матрица ответственности
Матрица ответственности – это таблица, которая регламентирует уровень несения ответственности сотрудника в организации при выполнении задач. Менеджер проекта несет ответственность за все происходящее в нем. Поскольку заданий много, то руководитель имеет право делегировать выполнение заданий другим сотрудникам.
Термин RACI – это аббревиатура слов:
responsible (исполнитель, И) – решает задачу, ее качественное исполнение в срок, но не отвечает за выбор метода ее решения;
accountable (ответственный, О) – несет ответственность за исполнение задания, а также имеет право принимать решения, связанные со способом ее выполнения. Только один сотрудник может нести ответственность;
consult before doing (консультант, К) – консультирует по решению вопросов проекта и ведет контроль качества исполнения;
inform after doing (наблюдатель, Н) – консультирует, но не ответственен.
Рекомендации по данной методике:
учитывать профессионализм сотрудников при составлении матрицы;
не использовать общих действий;
применять глаголы действия (оценить, решить и т.д.);
указывать основной итог действия;
использовать для выполнения краткие, соответствующие должности задания.
При построении матрицы удобно в таблицу по вертикали внести операции, а по горизонтали- имя сотрудника. После заполнения таблицы нужен ее анализ.
При вертикальном анализе может быть:
много «И». Сотрудник не может выполнять контроль большого количества действий;
если отсутствуют пустые ячейки, тогда это означает, что сотрудник не сможет эффективно выполнить большое количество действий;
нет «И» или «О». Проверить целесообразность должности;
большое количество «О». Пересмотреть задачи, и делегировать часть их другим сотрудникам.
Горизонтальный анализ:
отсутствуют либо много «И». Найти или убрать исполнителя задания;
много «О» свидетельствует о том, что много сотрудников несут ответственность за одно действие;
нет пустых ячеек – требуется пересмотреть количество исполнителей, поскольку в противном случае это замедлит процесс;
много «К» сказывается на сроках исполнения.
Такая матрица владеет наглядностью и дает возможность быстро контролировать выполнение проекта, выявить перегруженных или отдыхающих сотрудников, построить систему контроля производительности труда. Что в свою очередь повысит эффективность проекта, а также избежать конфликтных ситуаций во время распределения между сотрудниками ответственности.
Методика RACI: оптимизация распределения полномочий и ответственности
Делегирование является неотъемлемой частью роли менеджера, поэтому определение ролей и обязанностей в начале проекта очень важно. В обязанности менеджера лежит определение ожиданий людей, участвующих в проекте с самого начала.
Проекты требуют участия многих людей, но как избежать ситуации, когда люди борются против друг друга при осуществлении определенной задачи. Столь же сложным является ситуация, когда никто не берет на себя ответственность и не принимает решения. Как люди должны понимать уровень собственной ответственности? К кому можно обратиться при возникновении вопроса? Кто должен быть проинформирован при осуществления задачи или процесса? Применение модели RACI может помочь ответить на все эти вопросы.
Матрица RACI представляет собой простой инструмент, используемый для определения ролей и обязанностей и избежания путаницы при исполнении задач или процессов. Используется при управления проектами и для показа обязанностей в состояниях «AS-IS» и «TO-BE».
Матрица ответственности представляет собой особый метод определения функциональных областей, ключевых направлений деятельности, критериев принятия управленческих решений, где существуют неясности. Все разногласия, возникающие в ходе данного процесса, могут быть вынесены на общее обсуждение и впоследствии разрешены путем принятия коллективного решения.
Подобный подход позволяет менеджерам активно участвовать в систематическом процессе описания деятельности, решений, которые должны быть осуществлены, а также прояснить обязательства и обязанности, которые несет каждый участник по отношению к сфере занятости и управленческим решениям. Подобный подход позволяет содействовать естественному рабочему процессу и согласованному распределению ролей и ответственности внутри группы. Основные преимущества использования матрицы ответственности заключаются в том, чтобы прояснить разграничение ролей и ответственности как индивидуальных, так и в команде. Зачастую внутри группы возникает недопонимание, отсутствие четкой специализации и расплывчатое представление о собственных полномочиях, что приводит к ослаблению командного духа и, как следствие, к низкой производительности. Поэтому определение сфер ответственности и полномочий повышает результативность деятельности как каждого работника, так и группы в среднем.
В частности, матрица распределения ответственности дает возможность избежать дупликации выполняемых функций в коллективе. При возникновении спорных ситуаций руководитель процесса может ссылаться на конкретное лицо, отвечающее за цепочку процесса, где возникло разногласие или ошибка. Таким образом, в коллективе устанавливается более открытый метод коммуникации, основывающийся на консультировании и информировании участников процесса.
Таблица 1. Резюме: Критические вопросы модели
| Распределение ролей и обязательств | — Для лучшего понимания собственных полномочий — Для повышения эффективности коммуникаций |
| Ответственность | — Для разъяснения, кто и кому подотчетен |
| Обязательства | — Для выявления полномочий |
| Ответственность за работу | — С целью наделить сотрудников полномочиями, необходимыми для выполнения конкретной работы |
| Роль менеджера среднего звена | — Ускорить координацию выполняемых процессов с поставленными задачами |
| Утверждение | — Во избежание неопределенностей при многоразовой отчетности |
Указания к построению матрицы
| «R» Исполнитель (Responsible) | Лежит ответственность за выполнение поставленной задачи. На каждую задачу должно приходиться не менее одного Исполнителя. Степень ответственности распределяется Утверждающим |
| «A» Утверждающий (Accountable) | Перед ним производится отчет в полученном результате, имеются полномочия, как принимать, так и отвергать предложения, накладывать на них вето. На каждый проект выделяется не более одного Утверждающего |
| «С» Консультант (Consulted) | Консультация и согласование принимаемых решений. Характеризуется двусторонней связью между подразделениями |
| «I» Информируемый (Informed) | Поступает конечная информация о проделанной работе. Характеризуется односторонней связью |
Матрица ответственности выстраивается в шесть этапов:
Основными принципами принятия решений с помощью RACI являются:
Вертикальный анализ (по функциональным ролям) позволяет выявить соответствующие проблемы: Если у Вас получилось:
При горизонтальном анализе рассматриваются действия Если у вас получилось, что
Подводя итог, стоит отметить, что матрица распределения ответственности является важным элементом успешного планирования рабочего процесса. В ходе ее грамотного использоваться должна повыситься производительность на проекте, достигаемая за счет наличия Утверждающего. При умелом построении рабочего процесса сформируется сильная команда, состоящая из грамотных и натренированных игроков, способных предлагать нестандартные подходы к принятию решений. Как результат можно будет выстроить более продуктивную систему коммуникаций между всеми участниками благодаря разработке интерфейса связи (Консультант и Информированный).
Список литературы
1. Андерсен Б. Бизнес-процессы. Инструменты совершенствования. — М.: РИА «Стандарты и качество», 2014.
2. Деминг В. Эдвардс. Выход из кризиса. — Тверь: Альба, 2009.
3. Дрожжинов В. Реинжиниринг бизнес-процессов в компании // Ваш банкъ. Экономист. — 2012. № 2.
4. Друкер П.Ф. Практика менеджмента: Пер. с англ. — М.: Изд. дом «Вильямс», 2011.
5. Ефремов В.С. Организации, бизнес-системы и стратегическое планирование //Менеджмент в России и за рубежом. — 2013. — № 2.
6. Кальянов Г.Н. Теория и практика реорганизации бизнес-процессов. Серия «Реинжиниринг бизнес-процесса». — М.: СИНТЕГ, 2012.