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

Матрица RACI решает проблему, из-за которой тонет большинство процессов: не расписанная явно ответственность приводит к тому, что задачу либо делают несколько человек параллельно и впустую, либо никто, каждый думая, что это делает кто-то другой. RACI заставляет явно назначить одну из четырёх ролей — Responsible, Accountable, Consulted, Informed — на каждую задачу процесса, устраняя саму возможность перекладывания ответственности.

Если на вопрос «кто отвечает за это?» в компании может ответить два разных человека по-разному — значит, ответственность не назначена, а только предполагается, и RACI существует именно для того, чтобы закрыть этот разрыв.

Реальный, максимально дорогой пример того, к чему приводит разделение Accountable и Responsible без явной связующей структуры, — Национальная программа информатизации NHS (National Programme for IT, NPfIT) в Великобритании, запущенная в 2002 году. Изначальная оценка стоимости составляла £2,3 млрд, позже проекции выросли до £12 млрд, а фактические траты к моменту демонтажа программы в 2011 году составили около £9,8 млрд без реализации ключевых обещанных результатов. Официальный анализ провала прямо указал на структурную причину: центральные органы определяли цели и заключали контракты (то есть держали Accountable-роль), а локальные медицинские организации отвечали за фактическое внедрение и использование систем (то есть исполняли Responsible-роль) — но между этими двумя уровнями не было работающей обратной связи: проблемы, выявленные на местах, не транслировались в изменения на центральном уровне, а решения центра не отражали операционную реальность на местах. Это ровно та ситуация, для предотвращения которой существует правило RACI «ровно один Accountable на задачу, но Accountable и Responsible должны быть явно связаны и синхронизированы» — формальное распределение ролей без реального канала связи между ними оказалось разрушительно дорогим.

Происхождение и исследовательская база

Матрица RACI (иногда RASCI, ARCI) выросла из практики проектного управления как способ явно задокументировать распределение ролей между участниками процесса или проекта — метод стал стандартным инструментом в PMBOK и большинстве современных методологий управления процессами и проектами. Насколько остро ощущается нехватка именно RACI-подхода в реальных организациях, показывает свежее эмпирическое исследование зрелости управления IT-активами на авиастроительном предприятии на Филиппинах (Montano & Maneclang, IJFMR, 2026): из десяти проверенных барьеров, опрошенных у 28 IT-специалистов компании, «отсутствие чётких ролей, ответственности и подотчётности (RACI) для этапов жизненного цикла активов между отделами» получило оценку 3,92 из 5 и вошло в категорию «значимый барьер» (Significant Challenge) — второе место среди всех препятствий, уступив только нехватке обучения персонала (3,96) и опередив даже сложность лицензирования ПО (3,86) и проблемы интеграции ИТ-систем (3,75). Другими словами, отсутствие явной RACI-матрицы регулярно оказывается более серьёзной проблемой, чем сама технология или инструменты.

Ключевые идеи и принципы

1. Принцип: Четыре роли, а не произвольные формулировки ответственности

   Responsible (исполнитель, непосредственно делает работу), Accountable (ответственный, отвечает за результат перед руководством, должен быть один на задачу), Consulted (консультируемый, чьё мнение запрашивается до принятия решения), Informed (информируемый, кого уведомляют о результате) — строго определённый набор ролей вместо расплывчатых формулировок типа «участвует» или «помогает».

2. Принцип: Ровно один Accountable на каждую задачу

   Ключевое правило RACI — на каждую задачу должен быть назначен ровно один Accountable; если Accountable больше одного, ответственность снова размывается между несколькими людьми, а если ноль — ответственности нет вообще.

3. Принцип: Матрица строится по реальному процессу, а не по формальной иерархии

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

4. Принцип: Матрица регулярно пересматривается при изменении процесса

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

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: На задачу назначено несколько человек с ролью Accountable.

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

   Как избежать

   Строго следить, чтобы на каждую задачу был назначен ровно один Accountable.

2. Ошибка 2: Матрица RACI копируется с организационной структуры без анализа реального процесса.

   Формальные роли не совпадают с тем, кто фактически принимает решения и выполняет работу, матрица не отражает реальность.

   Как избежать

   Строить матрицу по фактическим шагам процесса и реальным участникам, а не по должностной иерархии.

3. Ошибка 3: Роли Consulted и Informed путаются или не различаются на практике.

   Люди, чьё мнение должно быть учтено до решения, узнают о решении только постфактум, как Informed.

   Как избежать

   Явно фиксировать, кого нужно проконсультировать ДО принятия решения, а не только уведомить после.

4. Ошибка 4: Матрица RACI составлена один раз и не пересматривается при изменении процесса.

   Матрица создаёт иллюзию ясности, хотя реальное распределение ответственности уже изменилось.

   Как избежать

   Пересматривать матрицу RACI при любом существенном изменении процесса, участников или организационной структуры. Та же работа даёт конкретный, проверяемый план устранения именно этого барьера: создавать и уточнять детальную RACI-матрицу для каждого этапа процесса через совместные межфункциональные семинары с участием всех задействованных подразделений, встраивать её напрямую в регламенты и рабочие инструменты компании (а не хранить отдельным документом), пересматривать не реже раза в полгода на регулярных встречах по управлению, и явно привязывать подотчётность к измеримым показателям эффективности — авторы указывают ориентир в 4,0+ балла зрелости уже в первые 6 месяцев внедрения такого подхода.

5. Ошибка 5: RACI составляется для всех процессов компании без приоритизации.

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

   Как избежать

   Начинать с процессов, где перекладывание ответственности реально происходит и создаёт проблемы, и расширять охват постепенно. Стоит также заранее закладывать в приоритизацию совместное решение проблемы обучения: исследование зрелости управления IT-активами (Montano & Maneclang, 2026) показало, что нехватка обучения сотрудников (оценка барьера 3,96 из 5) и нечёткий RACI (3,92) — два теснейшим образом связанных барьера, идущих в паре друг за другом по значимости, и внедрение одной только матрицы без параллельного объяснения командам, что означает каждая роль на практике, решает лишь половину проблемы.

План внедрения

1. Неделя 1: выбрать 2-3 процесса с наиболее частыми конфликтами по ответственности для первой матрицы RACI.

2. Неделя 2: составить матрицу по фактическим шагам процесса, назначив ровно одного Accountable на каждую задачу.

3. Неделя 3: обсудить матрицу с реальными участниками процесса и скорректировать по обратной связи. Проводить это обсуждение стоит именно в формате совместного межфункционального семинара с участием представителей всех задействованных подразделений сразу, а не последовательных согласований по цепочке — такой формат прямо рекомендует исследование зрелости IT-процессов 2026 года как способ добиться реальной приверженности ролям, а не формального подписания документа.

4. Неделя 4: внедрить матрицу в работу и зафиксировать регламент её пересмотра при изменении процесса.

   Далее: постепенно расширять применение RACI на другие процессы компании. Экономический эффект от системного наведения порядка с ролями может быть ощутимым: то же исследование, комбинируя внедрение детальной RACI-матрицы с устранением остальных четырёх ключевых барьеров (качество данных, интеграция систем, обучение, сложность лицензирования), прогнозирует снижение операционных издержек на 15-30% в горизонте 2-3 лет — не за счёт одного RACI, но именно нечёткие роли авторы называют одним из пяти системообразующих барьеров, без устранения которого остальные улучшения не масштабируются.

Как реализовать этот план с помощью фрейма «Матрица ответственности RACI» в OrgDevTools

Фрейм — реальная редактируемая матрица «задачи × роли», где каждая ячейка на пересечении задачи и роли заполняется одной из четырёх букв (R/A/C/I) через выбор значения, с явной цветовой индикацией. Фрейм отслеживает соблюдение ключевого правила RACI — ровно один Accountable на каждую задачу — и не позволяет незаметно пропустить это условие.

Строгая проверка «ровно один Accountable на задачу» прямо в структуре фрейма — защита именно от того сценария, который реализовался в NPfIT: там формально Accountable-роль (центральные органы) существовала, но была структурно оторвана от Responsible-роли (локальные организации) без работающего канала обратной связи между ними — фрейм требует не просто назначить роли, а держать эту связку видимой и проверяемой в одной таблице, а не в раздельных, несвязанных структурах управления.

Книги по теме

A Guide to the Project Management Body of Knowledge (PMBOK Guide). Стандарт проектного управления, где RACI зафиксирован как один из инструментов распределения ролей.