![](https://habrastorage.org/storage2/8e8/aa5/363/8e8aa5363a6f5a73ff66f58456775bcc.jpg)
О таком умном словосочетании, как «разделение полномочий» говорят часто. Но все ли знают, как его применять на практике, и кому удается этим реально воспользоваться? Приглядевшись внимательно, делаем вывод, что такое явление происходит по большому счету, в компаниях частного сектора, в особенности тех, кто работает с иностранным клиентом.
Именно из-за «бугра» до нас дошла любопытная аббревиатура под названием RACI. При этом, зачастую перед ней можно наблюдать разного рода умности а-ля «матрица» или «модель». Что это и с чем его едят, попытаюсь объяснить читателю далее. Возможно, кому-то уже повезло работать в коллективах, где каждый знает свои обязанности и область ответственности – за таких людей можно только порадоваться. При этом лично я верю, что далеко не у всех всё идеально в сфере разделения полномочий. Для таких людей данная статья может оказаться полезной.
Итак, что же представляет собой RACI матрица? Эта аббревиатура разбивается на четыре конкретных роли:
- Responsible (на матрице отмечается буквой R) – ответственный непосредственно за выполнение работы
- Accountable (A) – подотчетный, такую роль может занимать только один человек на одной задаче
- Consulted (C) – один сотрудник или группа, с которыми проводятся консультации касательно задачи и мнения которых должно учитываться
- Informed (I) – сотрудники, уведомляемые о выполнении конкретной задачи.
Также, существует два расширенных варианта модели.
RACI-VS, здесь добавляются 2 роли:
- Verifies(V) – один сотрудник или группа, проверяющие соответствие результата выполнения задачи согласованным заранее допустимым критериям
- Signs off (S) – утверждает сдачу продукта заказчику (выполнения задачи). Данную роль можно совместить с подотчетной ролью.
При использовании варианта модели RASCI, появляется одна новая роль:
Supportive (S) – предоставляет дополнительные ресурсы для выполнения работы, такой как поддержка внедрения продукта, к примеру.
С одной стороны – «много букв» и ничего не ясно. С другой – дабы стало понятней, хочу на примере показать, как выглядит сама RACI матрица.
![](https://habrastorage.org/storage2/c59/453/a5d/c59453a5de3ac9895c99e9116623e182.png)
Не надо быть «Кэпом», чтобы понять, что шапка таблицы отображает список функциональных ролей, ответственных за ту или иную задачу или же участвующих непосредственно в принятии решения. Пункты «Activity 1-5» являют собой собственно функции, опускающиеся на плечи вышеуказанных ролей.
Для того, чтобы понимать, по какому принципу такая табличка должна рисоваться, а также как ее использовать на практике (в реальных проектах), рекомендуется уделить должное внимание следующему порядку действий при построении матрицы:
- Определяем список необходимых активностей/процессов в поставленной задаче (проекте)
- Определяем и указываем функциональные роли (людей, которые заинтересованы или которых тем или иным образом касается данная задача)
- Собираем митинг и назначаем RACI коды (собственно — буквы) конкретным ролям, непосредственно разграничиваем ответственности
- Определяем несоответствия (например, слишком много ответственных либо отсутствие таковых)
- Описываем таблицу и собираем отзывы
- Контролируем выполнение назначенных ролей
Допускаю, что кому-то будет нелегко ассоциировать латинские буквы с теми функциями, которые под ними подразумеваются. Тем не менее, не советовал бы использовать их русские варианты – вполне вероятно, что возникнет путаница, станет еще сложнее разобраться, что к чему.
Ну и напоследок, после того, как мы закончили разработку RACI модели, не помешало бы и проанализировать результаты.
По функциональным ролям, анализировать можем, отвечая на такие вопросы:
- Много «А» — правильно ли распределены обязанности? Есть ли в наличии «узкие места»?
- Много «R» — не многовато ли мы ответственности повесили на одну роль?
- Отсутствие пустых ячеек в таблице – действительно ли эта роль должна быть вовлечена в такое количество задач?
Также, не забудьте провести анализ по выполняемым активностям:
- Более одного «А» — только одна роль должна быть подотчетной
- Отсутствие «А» — необходимо найти подотчетного
- Более одного «R» или отсутствие такового – кто-то должен быть ответственный, однако нам не нужно, чтобы ответственность была широко распределена – есть риск того, что задача не будет выполнена
- Много «С» — стоит ли нам консультироваться с многими ролями и будет ли это эффективно?
- Отсутствие «С» и «I» — правильно ли у нас установлены коммуникации?
На этом и хотелось бы остановиться, дабы не навевать читателю скуку. Насколько адекватным является такое распределения функций, ровно, как и пользоваться ли такой моделью – судить Вам. Заработает ли оно в постсоветских реалиях – вопрос спорный. Однако, работая с иностранным заказчиком, RACI матрица станет не только не лишней, но и даст четкое понимание всем о происходящих в проекте активностях и людях, выполняющих их. А заказчик, как известно, в своем большинстве, хочет четко знать, кто и за что несет ответственность в поставленной им задаче.
Также хотелось бы упомянуть о том, что RACI матрица ни в коем случае не является инструментом для определения козла отпущения, хотя бы потому, что люди, согласившиеся потратить время на ее составление, априори должны понимать ее цель и назначение.
P.S. Было бы интересно в комментариях услышать мнения читателей о возможности использовании такого средства распределения функций, а также поделиться личным опытом – у кого таковой есть.
UPD. По просьбе пользователя Sibarit попытаюсь на быструю руку привести пример использования модели на конкретно взятой задаче.
Допустим, у нас есть авиакомпания, которая на своем сайте собирается внедрить систему online check-in. Глобальные активности, необходимы к выполнению в контексте задачи, будут приблизительно следующие: сбор требований к системе; дизайн решения; непосредственная разработка решения (development); внедрение; собственно – стадия “production”; оптимизация решения.
Далее — определяем список функциональных ролей, в данной задачи возможны такие варианты: внутренний сервис провайдер (IT отдел авиакомпании) или же внешний сервис провайдер в случае отсутствия первого; ISP – компания предоставляющая хостинг для сайта авиакомпании; бизнес подразделение авиакомпании (представляющее интересы заказчика); финансовое подразделение (бухгалтерия); сервис менеджер (в зависимости от размеров организации, может входить во внутренний IT отдел); команда разработчиков (в зависимости от размеров организации, может входить во внутренний IT отдел).
Попробуем расставить RACI коды соответственно ролям и выполняемым ими активностям (ясно, что данный процесс проходит при участии всех сторон).
![](https://habrastorage.org/storage2/d67/2ef/ad4/d672efad40726a725e8fb4042fbe3543.jpg)
Таким образом будут распределены роли и фунции в данной задачи. Сразу хочу заметить, что в этом и любом другом проекте, варианты матрицы могуть быть разные, в зависимости от специфических потребностей разных компаний. Недаюсь, после такого примера у читателей будет более полное представление и возможностях использования RACI матрицы.