David Mainville, Подводные камни Матрицы ролей и обязанностей перевод Елены Ступиной
02.07.2010
Библиотека ИТ инфраструктуры пропагандирует использование матрицы RACI для документирования обязанностей и ролей, задействованных в выполнении процесса. Как получить максимум пользы от ее использования? К сожалению, такой информации в руководствах не найти. Описанные в этой статье идеи о том, как сделать результаты процесса документирования более полными, помогут в разы повысить эффективность матрицы ролей и обязанностей.
RACI — это акроним. Четыре буквы означают четыре статуса, присваиваемые ролям, задействованным в выполнении процесса: Ответственный (Responsible), Подотчетный (Accountable), Консультирующий (Consulted) и Информированный (Informed). Матрица строится следующим образом. В строках располагаются деятельности, в столбцах — роли. Далее в каждую соответствующую ячейку заносятся записи о выполняемых операциях.
В книге "Проектирование услуг" (Service Design) ITIL v.3 упоминаются также два других варианта матрицы RACI, используемые для документирования обязанностей и ролей, вовлеченных в проектирование и управление процессами и услугами. В этой статье внимание сфокусировано на проблемах операционного уровня.
Матрица ролей и обязанностей (RACI) под увеличительным стеклом
Документирование процесса предполагает указание всех деятельностей и обязанностей, за которые отвечает та или иная роль. Иными словами, определяются роли, Ответственные (R) за выполнение деятельности, Подотчетные (A), то есть отвечающие за отчетность о выполнении процесса, Консультирующие (C) и Информированные (I). Консультирующих и Информированных ролей может быть как несколько, так и ни одной.
Статус "I", означающий информированность, показывает, что роль должна быть осведомлена о начале и завершении деятельности. Этому существует ряд причин. Одна из наиболее очевидных заключается в том, что начало или конец одной деятельности может быть сигналом для начала выполнения другой деятельности, возможно, в рамках другого процесса.
Следует также четко определить момент, в который это уведомление должно сработать: в начале или конце деятельности. Чтобы избежать путаницы, разумно заранее согласовать с ролью необходимость статуса информированности "I", случаи, в которых этот статус является условным, а также варианты использования полученной ролью информации. Естественно, все договоренности необходимо зафиксировать формально.
Однако не следует бесцельно присваивать статус "I" всем ролям, задействованным в процессе. Так, для ролей, уже имеющих статусы "R", "A", "C", статус информированности "I" не нужен.
(Все неусловные уведомления должны обрабатываться автоматически. Если уведомление о каком-либо решении деятельности условное, то должны быть предусмотрены две процедуры. Во-первых, это возможность обработки уведомления. Во-вторых, при необходимости обязанности по созданию данного уведомления должны быть задокументированы).
Если предполагается, что роль должна или может выполнить определенное действие в деятельности, то статус информированности "I" не используется. В этом случае применимы статусы Консультирующий "C" или Ответственный "R".
Статус Консультирующий "С" означает, что роль может дать совет или руководство по какому-либо вопросу в ходе выполнения деятельности. Разумно задокументировать, в каких случаях Информированная "I" роль может обратиться за консультацией и какую информацию потребовать. Однако если роль выполняет какое-либо действие или должна предоставить информацию в рамках деятельности, то статус Консультирующий "С" лучше не использовать. Предпочтительнее выделить это действие в отдельную деятельность, а роли назначить статус Ответственный "R". Причина заключается в том, что все согласования и утверждения должны быть обязанностями Ответственной "R", а не Консультирующей "С" роли.
По крайней мере, одна роль должна быть назначена Ответственной "R" за выполнение деятельности и одна и только одна как Подотчетная "A". При этом статусы "А" и "R" могут относиться к разным ролям. Эта рекомендация у многих вызывает сомнения. Например, почему следует разделять ответственность и отчетность? Разве не логично объединить ответственность и отчетность в одной роли? Ключ к решению проблемы заключается том, что отчетность не относится к какой-либо определенной деятельности, но предполагает контроль выходных данных, получаемых в ходе выполнения всего процесса. Более того, из документации следует, что одна и та же роль должна иметь статус Подотчетный "A" по отношению ко всем деятельностям одного процесса. Такая практика имеет смысл, если матрица RACI используется только для отображения хода исполнения процесса.
Во второй части статьи будут подробнее рассмотрены особенности использования статуса Ответственный "R".
David Mainville, консультант портала ITSMWatch
Перевод Елены Ступиной
Оригинал статьи на портале ITSMWatch
Возврат к списку