RACI – Матрица распределения ответственности

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

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

Как раз для этого в проектах используются матрицы RACI.

Что такое RACI

Матрица RACI (она же матрица ответственности) – это специальная таблица, в соответствии с которой распределяются ответственность и роли по ключевым задачам внутри проекта. Фактически это формализованный инструмент управления отношениями в команде.

Матрица RACI предполагает четыре основных типа ответственности:

R (от слова «Responsible», дословный перевод — «несущий ответственность» или «обязанный») – участник команды, исполняющий роль непосредственного исполнителя. То есть тот, кто делает основную работу по выполнению задачи. Без такой роли задача не может быть выполнена. Обратите внимание, роль Responsible не ограничивает сотрудника в возможности делегирования задачи другим исполнителям.

A (от слова «Accountable», дословный перевод — «отчитывающийся») – участник команды, ответственный за задачу в целом. Это своего рода «куратор», тот, от чьего мнения зависит окончательное утверждение результата работы исполнителя. Он должен одобрить завершение задачи. У отдельно взятой задачи может быть не более одного куратора (с ролью Accountable).

C (от слова «Consult», хотя во многих источниках делается уточнение «Consult before doing», дословный перевод — «консультирующий до исполнения») – участник команды или сторонний эксперт, который помогает исполнителю прояснить важные вопросы и нюансы. В отличие от куратора, консультант не несёт никакой ответственности за исполнение задачи, но в его интересах сделать так, чтобы задача была решена как можно эффективнее.

I (от слова «Informed», тоже часто делается уточнение «Inform after doing», дословный перевод — «оповещаемый или информируемый после исполнения») – участник, которого нужно поставить в известность о том, что задача завершена. Заметьте, это не обязательно должен быть руководитель проекта. Это может быть сотрудник, ответственный за последующие задачи, ожидающий завершения промежуточных работ. «Информируемых» участников может быть несколько.

Ещё одна важная деталь – у каждого члена команды может быть совмещено несколько ролей (сфер ответственности), если это не противоречит другим условиям распределения.

Пример матрицы RACI

Вот так может выглядеть матрица распределения ответственности в проекте:

Ещё вариант матрицы RACI:

Можно заметить, что по некоторым задачам исполнители совмещают ответственность не только за исполнение, но и за отчётность (утверждение результата). Это значит, что участник команды не будет никого ждать с целью сдать работу, он сдаёт её самому себе.

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

Для чего используется методика RACI

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

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

У участника команды нет ролей R и A. Возникает логичный вопрос – «А чем тогда занимается этот сотрудник? Только консультирует и информирует?». Получается, что реальной нагрузки по задачам у него нет.
Один и тот же сотрудник проходит с ролью R по многим задачам. Получается, что на него завязано исполнение сразу нескольких задач. Если задачи критические, то это слишком большая ответственность, её нужно распределить между другими участниками. Любо роль такого участника нужно продублировать. Условно, если это дизайнер, то дизайнеров должно быть два или более.
У одной задачи слишком много принимающих (утверждающих результат). Такое недопустимо. Получается, что исполнителю вместо того, чтобы брать в работу новую задачу, нужно заниматься согласованием то с одним, то с другим… В идеале за приёмку результата по конкретной задаче должен отвечать кто-то один.
Один сотрудник совмещает разные статусы и роли ответственности. По несерьёзным (некритическим) задачам это ещё может быть допустимо, но для задач с повышенной ответственностью и объёмом так делать нельзя. Лучше всего, когда за приёмку и утверждение отвечает кто-то другой (это как дополнительный взгляд со стороны).
Слишком много «консультантов/экспертов» и лиц, которых нужно уведомлять об окончании работ. Желательно минимизировать такие роли. Иначе получается эффект «нескольких голосов в одной голове». Консультанты нужны только там, где недостаточно профильных знаний и экспертности исполнителя. Назначать их просто так не стоит.

Модификации матрицы – RASCI, RACIQ и RACI-VS

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

S (от слова «Support», дословный перевод — «поддержка или поддерживающий») – участник команды, который помогает исполнителю в его работе. Фактически так можно обозначать лиц, которым была делегирована задача или часть работ по её реализации. При такой схеме можно уйти от «пробелов», когда в реальности сотрудник работает над задачей, а в матрице RACI у него соответствующего статуса нет, ведь не он ответственный за исполнение.

Q (от слова «Quality», дословный перевод — «качество») – участник команды, ответственный за проверку качества задачи. Применяется проектах, ориентирующихся на управление качеством (например, бережливое производство или Lean-управление, тотальное управление качеством, оно же TQM, метод шести сигм).

VS (от слов «Verifier», то есть «верификатор», и «Signatory», «подписывающий») – это участники, которые нужны при схемах разделения ролей, отвечающих за проверку задач на соответствие критериям, изложенным в описании продукта, а также за окончательную передачу проекта заказчику.

Существуют и другие модификации матриц RACI:

PARIS (устаревшая матрица, включала роли участника, подотчётного, «требующего проверки», ответственного за ввод данных и за согласование).
PACSI (версия матрицы для команд и организаций с правом вето сразу у нескольких участников).
RASIC или RASCI (здесь роль исполнителя разделяется на две дополнительные сущности – основной ответственный и его поддерживающие).
RASI (здесь нет консультантов, они заменены на «поддержку»).
RACI + F (стандартная матрица RACI дополняется ролью Facilitate, условно это тренер или ментор, оказывающий содействие в реализации).
CAIRO или RACIO (добавляется роль участников «вне цикла», Out of the loop).
DACI (предполагает роли «управляющий», «утверждающий», «содействующий» и «информируемый»).
RAPID (можно перевести как «БЫСТРЫЙ», включает роли «рекомендующего», «одобряющего», «выполняющего», «информирующего» и «принимающего решение»).
RATSI (роли «ответственного», «решающего/имеющего власть», «исполнителя», «поддержки» и «информируемого»).
DRASCI (расширяет модель RASCI ролью управляющего).
PDQA (опирается на роли работы над объёмом, обработки зависимостей/координации, за обработку исключений и ответственности за принятие решений).
DCI (упрощённая схема, состоящая только из ролей принятия решения, консультирования и информирования).
RASCEIO (собирает максимум из возможных ролей).

Выводы и рекомендации

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

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

Более удобным и масштабируем инструментом можно назвать профильные BPM-системы, такие как Projecto. С ними управление проектом, распределение ответственности и задач становится наглядным. А прогресс работы можно отслеживать в динамике.