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

A — Accountable

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

R — Responsible

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

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

• определяют, что конкретно нужно сделать для реализации проекта и сколько времени это займёт (в рамках условий, поставленных «сверху»);
• составляют список необходимых ресурсов;
• участвуют в согласовании и утверждении технической документации;
• анализируют ход выполнения проекта и промежуточные результаты;
• предоставляют руководителю отчёты о проделанной работе.

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

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

Классический способ построения матрицы

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

Как было отмечено, для разработки МО традиционно используется методика RAСI: Responsible (отвечает), Accountable (утверждает), Consult before doing (консультирует), Inform after doing (информируется). Модель RACI широко распространена в проектной деятельности. Более того, эта форма рекомендована руководством PMBOK в качестве матричных диаграмм.

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

Пример матрицы RACI из руководства PMBOK

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

1. Не перегружена ли роль ответственностью, если в одном столбце много R?
2. Справится ли сотрудник (участник команды) с порученным объемом работ, если для него практически все ячейки заполнены?
3. Можно ли ликвидировать проектную роль, если нет R или A?
4. Корректно ли распределена ответственность, если в столбце много А?
5. Кто несет ответственность за работу, если в строке нет R?
6. В каждой ли строке только одно А?
7. Обоснованы ли многочисленные консультации по одной работе, если С несколько?

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

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

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

• много R — скорее всего, человеку придётся разрываться между несколькими задачами, что негативно скажется на скорости и результатах работы;
• много A — сотрудник «получает по шее» за всех; рекомендуется распределить ответственность более равномерно;
• нет ячеек R и A — повод задуматься о целесообразности этой должности как таковой (по сути, вы платите специалисту, который не делает ничего);
• нет пустых ячеек — опять же проблема перенагрузки, не каждый способен одновременно выполнять столько задач.

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

• много R — возможно, имеет место дублирование функций, и кто-то из членов команды выполняет ненужную работу;
• много A — происходит «размывание» ответственности и путаница при сдаче проектов;
• много C — обсуждения значительно тормозят рабочий процесс (нужно ждать, пока все внесут свои правки и замечания, находить компромиссы и т. д.);
• нет I — может быть сигналом к тому, что одной задачей занимается слишком много исполнителей, что также замедляет выполнение проекта.

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

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

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

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

1. Конечно, в первую очередь при управлении проектом. Самый правильный момент создания RACI матрицы – на этапе планирования проекта. Поможет избежать кучи проблем и недопониманий в дальнейшем.
2. При разработке нового или формализации существующего бизнес-процесса. При создании RACI матрицы для существующего процесса как правило выясняется много нового и интересного.
3. При создании нового продукта, когда процессов как таковых еще нет. Если договориться на берегу, кто тут за продажи, а кто за производство – есть вероятность даже не поругаться и как минимум продукт запустить.
4. В любой другой ситуации, когда надо жестко разграничить, кто и за что отвечает и в чем участвует (а иногда – и в чем не участвует, см.вариации RACI ниже).

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

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

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

Матрица — ответственность

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

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

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

В табл. 13.5.1 показан пример матрицы ответственности. Роли в примере указывают вид участия подразделения в работе: О — ответственный исполнитель, И — исполнитель, П — приемка работ, К — консультации.
 

В табл. 4.6 показан пример матрицы ответственности. Роли в примере указывают на вид участия подразделения в работе: О — Ответственный исполнитель, И — Исполнитель, П — Приемка работ, К — Консультации.
 

В табл. 4.6 показан пример матрицы ответственности. Роли в примере указывают вид участия подразделения в работе: О — ответственный исполнитель, И — исполнитель, П — приемка работ, К — консультации.
 

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

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

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

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

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

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

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

Изменения

Есть также много изменений к значению типов участия RACI:

RACI (альтернативная схема)

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

:; Ответственный

:: Ответственные за исполнение задачи. Должен быть точно один человек с этим назначением на каждую задачу.

:; Помогает

:: Те, кто помогает завершению задачи.

:; с Которым консультируются

:: Те, мнения которых разыскиваются; и с кем есть двухсторонняя коммуникация.

:; Информированный

:: Те, кто в курсе на прогрессе; и с кем есть односторонняя коммуникация.

ARCI (решения)

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

:; Одобряет

:: Уполномоченный одобрить ответ на решение.

:; Рекомендует

:: Ответственный, чтобы рекомендовать ответ на решение.

:; с Которым консультируются

:: Те, мнения которых разыскиваются; и с кем есть двухсторонняя коммуникация.

:; Информированный

:: Те, кому сообщают после решения, сделаны; и с кем есть односторонняя коммуникация.

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

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

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

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

• разработка ТЗ;
• развертывание прототипа системы;
• опытная эксплуатация и т.п.

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

Схема декомпозиции проектной задачи по внедрению продукта Y

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

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

Вариант упрощенной матрицы ответственности

Цена внедрения матрицы компетенций

• 4 часа на первую версию, т.е. декомпозицию;
• 1 час на то, чтобы все свести в одну таблицу;
• 0,5 часа и пара кружек пива HR-эксперту, который рассказал, что это называется матрицей компетенций, и можно было не изобретать велосипед и потратить еще меньше времени.

Dev Team

• Первичная оценка, мозговые штурмы — 3-4 часа на каждого эксперта (у нас было 4 эксперта) — время усредненное, потому что не все эксперты постоянно сидели в одной комнате и общались.
• На само составление матрицы, в том числе на приведение разработчиков и скиллов, на настройку формул макроса, чтобы можно было удобно пользоваться таблицей, навешивать дополнительные метрики и формулы — ушло 6 часов работы.
• Время на дополнительное выверение теста. У нас уже был квиз для новичков. Пришлось его немного раздуть и сделать универсальным, чтобы он подходил и для senior’ов. На переписывание этого квиза ушло 2 часа у knowledge-менеджера и 2 у тимлида.
• Самая затратная часть — это оценка путем экзамена (квиза в 3-4 раунда). Это занимает много времени, потому что в квизе больше 100 вопросов, которые идут по профилям.
• Время на корректировку метрик — еще 2 часа. Если у вас есть дополнительные методики оценки, у вас может уйти чуть больше времени в этом пункте.

Что осталось за кадром?

1. В реальности, к сожалению, размер матриц не всегда кратен размерам микроядра, потому края матриц приходится обрабатывать особым образом. Для чего приходится реализовывать микроядра разных размеров.
2. Для разных типов процессоров реализуются разные наборы микроядер и функций переупорядочивания. Также свои микроядра будет для чисел с двойной точностью и для комплексных чисел. К счастью, зоопарк микроядер ограничен только ими и на верхнем уровне код достаточно универсальный.
3. Микроядра часто пишут прямо на ассемблере. Также проводят дополнительное разворачивание циклов. Но это не приводит к существенному ускорению — основные оптимизации заключаются в эффективном использовании кэшевой иерархии памяти процессора.
4. Для матриц малого размера (по любому измерению) применяют особые алгоритмы — иногда переупорядочивание не эффективно, иногда нужно применять другой порядок обхода матриц. А иногда и реализовывать особые микроядра.
5. В обобщенном алгоритме матричного умножения все три матрицы могут быть транспонированы. Казалось бы число возможных алгоритмов возрастает в 8 раз! К счастью применение переупорядочивания входных данных, позволяет для всех случаев обойтись унивесальными микроядрами.
6. Практически все современные процессоры — многоядерны. И библиотеки матричного умножения используют многопоточность для ускорения вычислений. Обычно для этого используется еще 1-3 дополнительных цикла, в которых происходит разбиение задач по разным потокам.

Похожие:

Инструкция, руководство по применению