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