Превратите размытое «мы отвечаем вместе» в явное участие по значимым результатам и решениям — не делая вид, что четыре буквы создают полномочия или компетенции.
За одну минуту
В строках RACI стоят результаты или решения, в столбцах — роли:
- R — Responsible: выполняет или координирует работу;
- A — Accountable: принимает результат или решение и обладает соответствующим полномочием;
- C — Consulted: даёт необходимый вклад до завершения;
- I — Informed: получает результат или существенное обновление.
Для результата с единым владельцем обычно нужен один A. R может быть несколько. Consultation — двустороннее и ограниченное по сроку, information — одностороннее. Пустая ячейка нормальна.
RACI — операционное соглашение. Оно не выдаёт бюджет, не отменяет regulation, не доказывает компетентность, не описывает все hand-offs и не заменяет decision log.
Какую проблему решает
Команды поздно обнаруживают, что «мы» означало «никто», два руководителя считали себя владельцами, а десять reviewers ожидали veto. Матрица делает участие обсуждаемым. Её ценность — в проверке полномочий и реальных сценариев, а не в заполнении каждой клетки.
Когда применять
Используйте RACI, когда:
- несколько функций создают один результат;
- работа застревает на review;
- запуск требует операционных и governance-ролей;
- ответственность изменилась после реорганизации или автоматизации;
- поставщик или control function участвует в определённых точках.
Когда не применять
Не используйте RACI до определения работы, для маскировки конфликта полномочий, назначения A комитету без механизма решения, карты каждой мелкой операции, вместо контроля capacity и segregation of duties или для stakeholder strategy. Для последнего используйте Карту стейкхолдеров.
Необходимые входы
- ограниченный процесс, этап проекта или governance-цикл;
- наблюдаемые deliverables и decisions;
- устойчивые роли;
- формальные права, делегирования и control obligations;
- ограничения competence, capacity и segregation of duties;
- ожидания срока consultation и approval;
- владелец эскалации и триггер пересмотра.
Пошаговый процесс
1. Определите границы
Назовите старт, завершение, use case и исключения. Одна матрица должна быть обозримой.
2. Запишите строки результата
Используйте «одобрить запуск пилота» или «проверить privacy impact», а не «маркетинг» и не сотни microtasks.
3. Используйте роли как столбцы
Роли переживают смену людей. Внешние и control roles добавляйте только там, где они реально участвуют.
4. Назначьте R
Укажите, кто делает или координирует работу. При нескольких R дополнительно опишите lead и hand-offs.
5. Назначьте A
Для каждой строки с ownership укажите одну роль, которая вправе принять результат или решить. Если authority отсутствует — эскалируйте, а не придумывайте A.
6. Добавьте C и I выборочно
Для C определите, какой вклад и к какому сроку нужен. I получает результат или существенное изменение.
7. Проверьте структуру
Найдите строки без R или A, несколько A, перегруженные роли, скрытые veto через C и тотальные I.
8. Проверьте полномочия и контроли
Сопоставьте матрицу с политиками, делегированием, regulation, договором и segregation of duties. Workshop их не отменяет.
9. Проиграйте сценарии
Пройдите обычный случай, исключение и срочный сбой: кто действует, кто решает, какие evidence нужны и куда идёт escalation.
10. Опубликуйте операционную версию и пересматривайте
Свяжите утверждённую матрицу с workflow и decision log. Измеряйте delay, rework и unresolved escalations. Пересматривайте после изменений ролей, scope и controls.
Взгляд через AI и автоматизацию
AI может извлекать кандидатов на роли и результаты из утверждённых документов, искать строки без R/A, перегруженные столбцы и различия версий. Он не должен выводить полномочия из должности, назначать accountability без подтверждения, нарушать separation of duties, считать сгенерированную таблицу политикой или одобрять выпуск, платёж и публикацию.
Визуальная модель
Интерактивный пример
Компания запускает AI-assisted service desk. Operations настраивает workflow, IT интегрирует, Legal и Security проверяют, Customer Service отвечает за сервис, vendor предоставляет модель. План говорит «совместное одобрение всеми», поэтому никто не знает, кто принимает production risk.
Для строки «одобрить production launch» A — уполномоченный service owner, если делегирование действительно даёт право. Operations и IT — R по сбору evidence и release; Security и Legal — C по определённым требованиям; vendor — C по ограничениям; support teams — I до cutover. Если security approval является отдельным обязательным gate, это отдельная строка. Если authority ни у кого нет, конфликт эскалируется до назначения A.
Заметки фасилитатору
- Сначала строки, потом буквы.
- Спрашивайте «кто вправе принять результат?», а не «кто старше?»
- Подтверждайте A делегированием.
- Для C задайте цель и время ответа.
- Оставляйте ненужные клетки пустыми.
- Репетируйте исключение.
Ожидаемый результат
- ограниченная responsibility matrix;
- наблюдаемые результаты и решения;
- подтверждённые R, A, C, I;
- исключения authority и controls;
- правила consultation и escalation;
- владелец версии и триггер пересмотра;
- метрики delay и rework.
Типичные ошибки
- Несколько A без механизма принятия.
- A без реального полномочия.
- R интерпретируется как «виноват».
- Все назначены C.
- Все назначены I.
- RACI используют как process map.
Чек-лист качества
- Границы и исключения явны.
- Строки — значимые результаты или решения.
- Столбцы — устойчивые роли.
- У требуемого результата есть R и действительный A.
- A обладает реальным полномочием.
- Цель и срок C определены.
- Controls и segregation of duties сохранены.
- Матрица проверена сценариями и имеет owner/trigger.
Шаблон
| Результат или решение | R | A | C | I | Полномочие / evidence | Срок / escalation |
|---|---|---|---|---|---|---|
| Наблюдаемый output | Кто делает? | Кто принимает? | Чей input нужен до? | Кому нужен результат? | Какое delegation или control? | Когда и куда эскалировать? |
Проверка знаний
Вопрос: в строке два A, потому что оба руководителя отказываются делегировать. Что делать?
Ответ: разрешить механизм принятия или эскалировать конфликт полномочий до начала работы. Буква не решит governance-проблему.
Связанные методы
- Stakeholder Mapping
- Vroom-Yetton-Jago Decision Model
- Value Stream Mapping
- Process Decision Program Chart
- OKR
Источники
- Project Management Institute. PMI Lexicon of Project Management Terms, Version 5. https://www.pmi.org/-/media/pmi/documents/registered/pdf/pmbok-standards/pmi-lex-pm-terms.pdf?rev=447328d841c249af985d14177ddd5f95 (откроется в новой вкладке)
- PMI. “Stakeholder Management + RACI: A Practical Guide for Project Teams.” https://www.pmi.org/es-es/disciplined-agile/sitecore/content/pmiheadless/home/blog/blog-posts/2026/07/27/15/54/stakeholder-management-raci (откроется в новой вкладке)
- ISO 21502:2020. https://www.iso.org/standard/74947.html (откроется в новой вкладке)
Профиль метода
- Основная задача: прояснить участие в определённой работе и решениях.
- Главный артефакт: проверенная матрица результатов и ролей.
- Граница решения: RACI не создаёт authority, capacity и competence.
- Стандарт доказательности: делегирование, правила контролей, подтверждение носителей ролей и репетиция.
- Триггер пересмотра: изменения ролей, scope, workflow, authority или controls.