Матрица ответственности бизнес процесса это

Эффективность ролей участников бизнес-процессов. Матрица ответственности RACI

В статье приведено описание процедуры формирования матрицы ответственности RACI. Рассмотрены основные структурные составляющие матрицы и инструменты анализа эффективности ролей участников бизнес-процесса.

Построение системы бизнес-процессов, которая показывает высокую операционную эффективность является ключевой целью компании и ее руководства. Эффективность процессной модели компании зависит от ряда факторов, главным из которых является четкое распределение обязанностей и зон ответственности среди участников бизнес-процессов. Наиболее универсальным инструментом анализа и систематизации функциональных ролей участников бизнес-процессов является матрица RACI.

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

• «R» – Исполнитель (Responsible);
• «A» – Утверждающий (Accountable);
• «С» – Консультант (Consulted);
• «I» – Информируемый (Informed).

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

Матрица RACI или Матрица ответственности

Шаблон матрицы RACI представлена на рисунке №1.

Рисунок №1 – Матрица распределения ответственности RACI

Первое, что необходимо понимать при формировании матрицы RACI, операции, которые вносятся в матрицу должны иметь ключевое значение для бизнес-процесса. Например, не стоит перечислять операции по внутренней коммуникации между сотрудниками компании (за исключением передачи конечного выхода процесса); посещение совещаний, планерок, летучек и иных подобных мероприятий; и многие другие операции, которые не несут ценности для формирования конечного результата процесса. Матрица RACI должна быть удобным и понятным инструментом, поэтому нельзя перегружать ее большим количеством информации.

Все участники бизнес-процесса должны быть отражены в матрице RACI. Необходимо рассматривать бизнес-процесс целиком без исключений. В противном случае результат анализа эффективности ролей участников бизнес-процесса будет необъективным и лишенным ценности. Анализ матрицы RACI осуществляется в двух направлениях по вертикали и по горизонтали.

• Много «R». В этом случае необходимо рассмотреть возможность разгрузки сотрудника, который отвечает за выполнение большого объема работ.
• Нет «R» или «A». Возможно, стоит исключить этого участника из цепочки бизнес-процесса.
• Много «A» . Большое количество согласований, возможно существует ряд «узких мест» процесса, поэтому необходимо инициировать мероприятия по оптимизации.

• Нет «R». Никто не несет ответственности за результат операции.
• Много «R». Необходимо сконцентрировать ответственность за выполнение операции, иначе присутствует риск невыполнения операции.
• Много «A». Только один участник бизнес-процесса может утверждать результат операции.
• Нет «A». Необходимо определить ответственного за утверждение результата операции.
• Много «C». Необходимо определить важность консультации такого количества участников.
• Нет «C» или «I». В компании отсутствует канал внутренней коммуникации между участниками бизнес-процесса.

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

Источник: dzen.ru

Матрица ответственности процесса

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

Зеленым цветом отображается исполнитель динамической зоны ответственности .
Флажками можно обозначить роли исполнителей:

Владелец — сотрудник, полностью отвечающий за весь процесс. Это означает, что владелец несет ответственность не только за результат, то есть продукт процесса, но также за ход его выполнения и удовлетворенность клиентов бизнес-процесса. Владелец может быть выбран из исполнителей зон ответственности процесса или добавлен вручную из оргструктуры . В качестве владельца процесса могут быть выбраны следующие элементы оргструктуры: должность или группа сотрудников . У процесса может быть только один владелец (один сотрудник или одна группа сотрудников).

Участник — исполнитель одной из зон ответственности. Участники процесса видят экземпляры этого процесса в разделе Мои процессы в веб-приложении. Эта роль назначается по умолчанию всем исполнителям зон ответственности.

Информируется — сотрудник, информируемый о ходе процесса организационными мерами. Такой сотрудник не взаимодействует с процессом в системе ELMA, однако информация о нем попадает в документацию по процессу и регламент процесса .

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

Кроме ролей, назначаемых в матрице ответственности, пользователям автоматически назначаются роли в веб-приложении:

Инициатор — пользователь, запустивший экземпляр бизнес-процесса.

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

Контекстное меню матрицы ответственности

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

Рис. 2. Вкладка «Матрица ответственности» карточки процесса. Контекстное меню списка исполнителей
Контекстное меню содержит следующие элементы:

Добавить — позволяет добавить нового участника процесса. В открывшемся диалоговом окне необходимо выбрать элемент оргструктуры (рис. 3).

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

Рис. 3. Вкладка «Матрица ответственности» карточки процесса. Окно выбора исполнителя

Верхняя панель инструментов

Верхняя панель инструментов вкладки Матрица ответственности карточки процесса состоит из общих блоков , находящиеся на любой из вкладок процесса и блоков, присущих определенной вкладке.

Блок «Действия вкладки Матрица ответственности»

Позволяет добавить нового участника процесса. В открывшемся диалоговом окне необходимо выбрать элемент оргструктуры (рис. 3).

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

Источник: www.elma-bpm.ru

«Я не ответственный, я — Responsible» — как объяснить бабушке, что такое RACI-матрица

Приехала я год назад к друзьям играть в настолки. А они ссорятся. Из-за того, что Маша сказала Саше вынести мусор / убрать носки / погулять с хомяком, а он не сделал, потому что тупо забыл. Рассказала я Саше и Маше про ToDoList и таск-трекеры и нарисовала им на холодильнике импровизированную асану. Маша наклеила стикеры с задачами и сроками, Саша терпеливо кивнул.

Настолки состоялись.

Недавно я снова заглянула в гости. Стикеры на холодильнике висят, а Маша и Саша опять ссорятся. Точнее, громко выясняют, кто хотел починить стол / вывести холодильник / искупать кота, кто по-факту должен был это делать, и почему до сих пор ничего не сделано. Я промолчала, т.к. в чужие семейные разборки со своим PMBOK-ом не лезут.

Но потом решила, что всё нормально, лезут, т.к. вспомнила, что видела RACI-матрицу для распределения ответственности с шуточным объяснением через поездку семьи на дачу. Полезла искать эту картинку для Саши с Машей, нашла, а в ней куча ошибок:

Простите. Не могу промолчать. Не надо так.

Общая суть

Есть в проектном менеджменте такой инструмент — RACI матрица PMBOK Guide (9.1.2.1 Organization Charts and Position Descriptions, Matrix-based charts)

RACI — это аббревиатура:

R — Responsible
A — Accountable
C — Consulted
I — Informed

И вокруг этой матрицы есть путаница. Responsible и Accountable можно перевести на русский язык одинаково — ответственный, иногда это можно использовать как синонимы, но не в RACI matrix. В матрице ответственности между Responsible и Accountable семантическая пропасть, вот вам мостик через неё.

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

Responsible — тот, кто будет выполнять этап, прям физически, к примеру, Вася делает кликабельный прототип приложения. Он Responsible за этап проекта «прототипирование».

Accountable — тот кто апрувит результат и отвечает за него. В некоторых вариациях звучит как Authorize. В зависимости от команды, это может быть менеджер Васи, может быть старший дизайнер Васи, а если в команде 2,5 человека, то это может быть и сам Вася. Но такая практика сгодится только для супер-маленьких команд, не надо к ней прилипать.

Informed и Consulted тоже кажутся близки по смыслу. Основное отличие в том, что у C двусторонняя коммуникация в проекте, а у I — односторонняя. C может влиять на проект, а I — нет.

Я нашла в сети еще объяснения RACI матрицы, на бытовых примерах из жизни:

И в обоих шуточных примерах допущены ошибки при составлении, которые в реальном проекте могут мешать. Ниже всего два раздела, рекомендации — «как стоит делать», и чек-лист для проверки — «как не стоит делать».

Рекомендации по составлению матрицы

Я порылась в Википедии, почитала, что пишут иностранные коллеги и собрала все рекомендации по составлению матрицы.

1. В RACI матрицу включают не фичи продукта, а этапы проекта, хотя их еще называют таски/задачи. Это может быть задача по разработке, проектированию, подготовке отчетности по завершению проекта, но не задача «передвинуть кнопочку.
2. Матрица лучше работает, когда рассматривают от 10 до 25 этапов проекта.
3. Этап проекта должен выражаться через конкретный глагол, вроде «провести ревью», «опубликовать отчет», «оценить сроки», «составить расписание», «собрать данные», «утвердить концепцию».
4. В матрице лучше использовать роли, а не имена. Если завтра Васю сбивает автобус, пусть это цинично, но его роль будет исполнять другой человек.
5. Разрабатывать RACI матрицу лучше группой от 4 до 10 человек. Из одной головы можно неверно оценить ситуацию, а слишком большое количество человек — просто долго и сложно для обсуждения. Но перед утверждением RACI матрицы, каждый, кто будет в ней участвовать, должен увидеть свою роль и согласиться с ней.
6. Лучше устанавливать A и R на минимальный соответствующий уровень.
7. Назначать на A — Accountable, т.е. наделять ответственностью можно только человека с полномочиями.
8. Сведите к минимум позиции I и С.
9. Если вы составили матрицу, то оповестите всех участников проекта о матрице, об их роли в проекте и уточните, уточните, согласны ли они с этой ролью. Если нет, матрицу придется дорабатывать.
10. RACI матрицу иногда приходится обновлять по ходу проекта, т.к. она может устареть.

Проверка матрицы

Проверяют матрицу по двум направлениям: по вертикали и по горизонтали. Вот чек-лист, как проверить свою RACI матрицу на вшивость.

Вертикальная (по ролям)

Т.е. оценивается насколько сбалансированы роли в проекте

Слишком много R

Проверочный вопрос: «Вывезет человек на этой роли так много задач?»

Нет пустых мест

Проверочный вопрос: «Человеку в этой роли действительно необходимо участвовать во всех этапах проекта?»

Слишком много A

Проверочный вопрос: «Можно ли снизить количество процессов, в которых человек в этой роли принимает решение и отчитывается за них?»

Нет R или A

Проверочный вопрос: «Это нужная роль? Можно ли перераспределить часть ответственности на другие роли или передать часть ответственности с других ролей на эту?»

Двойные позиции A/R, или A/I

A/R, A/C, R/C — возможная картина для очень маленькой компании, но лучше избегать.
A/I, R/I, C/I- свидетельствует о непонимании RACI матрицы как инструмента.

Общая картина

Проверочный вопрос: «Соответствует ли количество ответственности на проверяемой роли уровню подготовки человека / его вовлеченности в проект?

Горизонтальная (по этапам)

По сути просматриваем, есть на каждом этапе чувак, который будет принимать решение, который будет это выполнять, и т.д.

Нет R

Нет исполнителя данного этапа. Проверочный вопрос: «Кто будет это делать?»

Слишком много R

Работа может замедлиться. Проверочный вопрос: «Можно ли разбить этап на более конкретные задачи, чтобы снизить количество исполнителей в этапе?»

Нет A

Нет ответственных, нет выполненной работы. Проверочный вопрос: «У кого есть полномочия из участников проекта, чтобы принять окончательное решение и иметь дело с последствиями данного этапа?» Т.е. кто отдает команду в каком направлении атаковать, и кому снесут голову с плеч, если направление оказалось неверным.

Больше, чем одна A

Первое правило RACI матрицы — только одна А для каждого этапа проекта.

Все ячейки заполнены на каждом этапе

Проверочный вопрос: «Действительно ли нужны все участники проекта на каждом этапе? Есть при преимущества от их участия?»

Нет C/I

Возможно вы кого-то забыли. Проверочный вопрос: «Вы учли всех участников проекта? Коммуникация между «отделами» налажена? Могут ли отделы начать выполнять какой-то этап параллельно или без учета последних изменений? »

Слишком много C

Замедляет проект. Проверочные вопросы: «Действительно нужно консультироваться со всеми C? Затраты часов на эти консультации окупаются? Можно просто проинформировать эти роли?»

Слишком много I

Проверочные вопросы: «Приносит ли это информирование пользу проекту? Или просто создает лишние созвоны и совещания? Можно информировать людей на этих ролях только в исключительных обстоятельствах? Можно ли отказаться от информирования людей на этих ролях?»

Много двойных позиций

Да, в маленькой команде могут возникать «двойные позиции», к примеру, когда на одном и том этапе один человек и выполняет задачу R и принимает по ней конечное решение A. Но такая формулировка может показывать непонимание матрицы, задач, команды, ответственности.

Непоняточки

Т.к. матрица разделяет Responsible и Accountable, то складывается впечатление, что R не несет ответственность за свои действия. Дело в том, что на каждом этапе может быть много R, и нужен человек, который может решать, соответствует ли результат поставленной задаче. R отвечает только за свою работу, а A чаще отвечает за работу других. Если полетят головы, то начинать будут с A.

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

RACI матрица не регулирует, будет ли C (консультант) давать консультацию только по запросу, или он будет сам вмешиваться в проект, когда сочтет, что его консультация необходима, и позже сможет убедиться, что его рекомендации реализовали.

Еще есть неоднозначность с тем, кто будет отправлять информацию I или получать информацию от C, и отчитываться ему о результатах. Тоже, на ваше усмотрение.

Ошибки из примера

А теперь, с чек-листом, я проведу проверку шуточной матрицы из интернетов, из-за которой я начала писать:

Горизонтальная проверка (по этапам)

− Подготовить машину.

Нет R (исполнителя), того, кто будет это делать: пойдет выгонять машину из гаража, проверять масло и т.д.

+ Купить еду.

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

± Взять игрушки.

Если речь идет о детских игрушках (в такой маленькой команде, как семья), скорее всего сыну пришлось бы взять на себя и A и R. Вряд ли папа смог бы его проконсультировать о том, какие игрушки сын любит. И вряд ли семья вызвала бы маму на ковёр, если бы сын поехал без игрушек.

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

+ Взять одежду.

Все окей: мама скомандовала всем взять теплые кофты, все взяли теплые кофты. Все в порядке.

− Взять алкоголь

Та же ошибка, что и с подготовкой машины, нет R. Непонятно, кто побежит в магазин за пивом. Да и польза этапа для всего проекта сомнительная. Убираем этот этап.

+ Замариновать шашлык

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

+ Взять рассаду

Тоже все в порядке. Бабушке на даче нужна рассада, она отправила папу с сыном таскать ящики с рассадой. Мама дает ценные советы, как эти ящики поставить в багажник так, чтобы рассада доехала до дачи. Всё сходится.

− Взять инструмент

Опять нет R, кто этим будет заниматься — непонятно.

− Оценить погоду

Сын решил, что важно посмотреть, будет ли на выходных дождь. И опять, кто этим будет заниматься — неизвестно, т.к. R не назначили.

Итого, 4 или 5 из 9 этапов требуют корректировки.

Вертикальная проверка (по ролям)

Участвует абсолютно в каждом этапе проекта. При горизонтальной проверке, на этапе «Подготовить машину» нет R. Папа — единственный компетентный член семьи, так что ему придется совмещать A и R. Вероятно, эта роль перегружена, и надо перераспределить часть задач на других членов команды.

В целом роль выглядит сбалансированной, но т.к. в ходе горизонтальной проверки, мы нашли этапы, на которых нет R (исполнителей), Мама может стать R на этапе «Оценить погоду». Если мама маленькая и хрупкая (некомпетентная), то она не сможет стать R на этапе «Взять инструмент», но обычно мама знает, где что лежит, так что может выступить C (консультантом).

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

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

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

В итоге, получаем матрицу без очевидных ошибок:

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

• RACI matrix
• RACI матрица
• матрица ответственности
• проектный менеджмент
• управление проектами
• управление командой
• планирование
• распределение ответственности

Источник: habr.com

Матрица распределения ответственности или RACI матрица – что это и зачем нужно

Еще один пост для начинающих РМов про нужный и полезный инструмент – RACI матрицу.

Что такое матрица распределения ответственности или RACI матрица?

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

Часто понятие “матрица распределения ответственности” сокращают до просто “матрица ответственности”, но идеологически это не совсем верно. Даже в оригинале инструмент называется Responsibility assignment matrix, то есть подчеркивает то, что его цель – назначить или распределить ответственность. Но называть можно как угодно, вас в любом случае поймут.

Расшифровка RACI:

1. R (Responsible) – тот, кто будет делать работу. Например, модуль Х будет писать разработчик Вася. Для каждой задачи должен быть как минимум один “R”, можно больше.
2. A (Accountable) – тот, кто примет итоговую работу и будет нести за нее ответственность. Принимать у Васи модуль Х и отвечать перед руководителем проекта головой за то, что он заработает, будет его тимлид Петя. “А” для каждой задачи должен быть только один, отсутствовать “А”, также как и “R”, в задаче не может. В исключительных случаях (обычно для совсем маленьких команд) “А” и “R” будут одним и тем же человеком, тогда достаточно указать просто “А”. Но вообще это нехорошая практика.
3. C (Consulted) – тот, кто будет в обязательном порядке консультировать остальных при выполнении задачи. Чтобы модуль Х работал как надо, и Васе и Пете надо будет согласовать свои идеи по реализации с Инной, главной за информационную безопасность в компании, и Еленой, архитектором проекта. “C” в задаче может быть, а может и не быть.
4. I (Informed) – тот, кто должен быть в курсе принимаемых решений или хода выполнения задачи, но влиять на них никак не будет. Руководитель поддержки Иван, которого пользователи уже запинали в ожидании модуля Х, будет грустно читать статусы и рассылки о ходе разработки модуля, смотреть таски в JIRA и тяжело вздыхать. По аналогии с “C”, “I” в задаче может быть, а может и не быть.

Пример матрицы распределения ответственности

Самый простой и наглядный пример RACI матрицы проекта “поездка на дачу” (как всегда, взято в сети):

Непонятно, правда, зачем тут безответственный кот, но ладно, пусть будет. Ну и в матрице – имена, а не роли, что вполне ок для проекта масштаба семьи.

А вот более “корпоративный” пример:

Тут, как вы видите, приведены уже роли, а не люди, плюс используется цветовая кодировка (что лишнее, как по мне).

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

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

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

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

Разработка матрицы распределения ответственности

Построить RACI матрицу несложно, все, что нужно, это:

1. Определить и выписать по вертикали задачи/промежуточные результаты проекта, шаги бизнес-процесса или другой набор действий, для которого вы хотите обозначить ответстенных.
2. Определить и выписать по горизонтали все роли или конкретных людей.
3. Проставить “А” для каждой задачи. Этот пункт, кстати, здорово прочищает мозги, так как сказать, “кто будет делать – легко”, а вот “за кем будет последнее слово” – уже сложнее.
4. Проставить “R” для каждой задачи.
5. Посмотреть на остальные роли/людей, прикинуть, нужно ли будет с ними консультироваться или хотя бы держать в курсе происходящего, и проставить соответствующие буквы.

Делать все это, конечно, стоит с командой, а не в гордом одиночестве, чтобы потом не удивляться, что ваша идеальная картина мира не совпала с реальностью.

Поздравляю, ваша матрица распределения ответственности готова!

Само составление – примитивнее некуда, а вот согласование – гораздо интереснее. Тут же начинается политика и прочие замечательные вещи, поэтому при разработке RACI матрицы стоит эту перспективу сразу учитывать.

Другие виды матрицы распределения ответственности

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

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

Вот такие варианты можно встретить чаще всего:

• RASCI – к обычной RACI добавляется S (Support), то есть тот, кто будет помогать ответственному (R) выполнять задачу.
• RACIQ – к обычной RACI добавляется Q (Quality), то есть тот, кто будет проверять результат на предмет соответствия заявленному качеству.
• RACI-VS – к обычной RACI добавляется V (Verifier) и S (Signatory), которые, соответственно, будут принимать продукт с точки зрения критериев приемки и согласовывать передачу его в эксплуатацию.
• RACIO (или CAIRO, просто буквы в другом порядке) – к обычной RACI добавляется O (Out of the loop), или тот, кого в задаче видеть вообще не хотят (чтобы сразу его выпилить, ну, например, не хотим мы, чтобы архитектор Елена мешалась под ногами у разработчика Васи). В жизни такого не видела, но очень хотела бы.
• И так далее.

Еще есть куча вариантов с другими буквами и проч., но концепция остается все той же.

Основные ошибки при построении матрицы распределения ответственности

Вариантов “как из RACI матрицы сделать бессмысленную бумажку” много, но вот самые частые и поэтому самые любимые:

1. Указываем везде спонсора (ну или хотя бы заказчика или любого топ-менеджера на выбор) в качестве “А”. В итоге большим дядям не до вас, ничего толком не принято, ответственных нет.
2. Пихаем по несколько букв в одну клетку матрицы. Нет, такие редкие исключения, конечно, бывают, но если у вас вся матрица пестрит A/R и C/I – значит, вы сами не разобрались то ли с инструментом, то ли с ответственностью.
3. Всех информируем изо всех сил. Или со всеми консультируемся. И в итоге получаем массу лишней коммуникации и генерацию белого шума в проекте или процессе.
4. Использование имен вместо ролей. Мало того, что придется переделывать при любом изменении в команде, так еще и потом для истории этот документ будет бессмысленным.

Ну вот, наверное и все. Вроде бы простая вещь, но без нее намного хуже, чем с ней, честное слово.

Используете RACI матрицу у себя? Расскажите!

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

Шаблон шаблоном, но вообще RACI матрица – это одновременно про управление рисками и про работу со стейкхолдерами, а не просто бумажка ради бумажки.

Если вы хотите узнать больше о рисках и о том, как с ними работать – вы можете приобрести наш большой курс по управлению рисками. Шаблон реестра рисков проекта и чек-лист для идентификации рисков в подарок!

А если вы хотите лучше работать со стейкхолдерами и уметь на них влиять – то посмотрите наш большой курс по управлению стейкхолдерами. Пакет шаблонов в подарок!

В избранное

Информация полезна? Поддержи развитие проекта!

На кофе и новые материалы для читателей блога 🙂

Мы в соц. сетях. Подпишись!
Выбор по тегу

Еще статьи

Юлия Бажанова
Редактор проекта, РМР, ICP-PPM
24 ноября 2022
Юлия Бажанова
Редактор проекта, РМР, ICP-PPM
09 ноября 2022
Юлия Бажанова

Редактор проекта, РМР, ICP-PPM
04 ноября 2022

—> —> I agree to the terms and conditions—>
Sorry that something went wrong, repeat again!
Отправить Отмена

2 комментария

9:56 дп1 июня, 2020 Светлана Дунаева

Как раз в связи с пуском большой программы проектов в компании пытаемся наладить работу с RACI матрицей руководителей проектов и использование ее в практике управления проектами, и вот тут возникло небольшое непонимание:

1. На уровне руководства решено было представить верхнеуровнево матрицу распределения ответственности по отделам- Эксплуатация, Производство, Внедрение, а вот роль РП отдельно выделили. На вопрос, почему бы тогда не отразить и роли других участников, поступил ответ: тогда матрица получиться очень масштабной и плохо читаемой. Цель была укрупненно представить какое подразделение за что отвечает. Мне кажется, что эта практика не очень полезная, даже в укрупненном масштабе, т.к. дьявол всегда в деталях, и как правило много “политических” вопросов возникает, когда начинаешь решать конкретные задачи, хотя на верхнем уровне вроде бы как и все отлично выглядит.

2. “если у вас вся матрица пестрит A/R” – как раз по роли РП такая ситуация очень частая, если говорить о задачах, связанных с управлением проектом. Возможно, здесь нужно рассмотреть конкретные ситуации, что бы понять, где такая практика допустима, где показывает, что “вы сами не разобрались то ли с инструментом, то ли с ответственностью”.

11:30 дп3 июня, 2020 Юлия Бажанова

Светлана, отвечу по пунктам:
1. Я категорически против такой коллективной безответственности, толку от этой матрицы примерно ноль. Попробуйте предложить тогда уж указать в матрице руководителей этих департаментов, а с них уже конкретное делегирование стрясти. В письменной форме, конечно же, тогда хоть будет на кого пальцем показать при необходимости=)) Вот сколько таких матриц видела – ни одна не работала, и спасибо еще, если не вредила.
2. A/R – вариант нормы, если для вас это работает, более того – чем меньше проект, тем чаще это норма. Другой вопрос – что в это A вкладывается. Действительно ли РМ у вас “A” за, например, финансовый план проекта, как РМ сделает – так и будет? Или все-таки спонсор и заказчик в итоге его утвердят и перед менеджментом отвечать будут, если что? Ну и так далее.

Источник: upravlenie-proektami.ru