Матрица ответственности RACI: как распределить роли между отделами
Матрица ответственности RACI помогает договориться, кто выполняет работу, кто отвечает за её результат, с кем нужно посоветоваться и кому сообщить о завершении. Она полезна там, где в одной задаче участвуют несколько отделов и сотрудники передают работу друг другу.
Я советую начинать с одного процесса, в котором регулярно возникают споры: кто должен подготовить данные, принять результат или предупредить клиента. Возьмите конкретный случай и распределите роли на его этапах. Так вы быстрее обнаружите пробелы, чем при попытке сразу описать всю компанию.
Что означает RACI
В описании RACI от Atlassian выделены четыре роли:
- R — Responsible. Исполнитель: готовит результат и выполняет согласованную работу.
- A — Accountable. Ответственный за итог: обеспечивает завершение задачи и принимает окончательное решение в пределах своих полномочий.
- C — Consulted. Участник консультации: даёт сведения и профессиональное заключение до решения.
- I — Informed. Получатель информации: узнаёт о решении или результате, чтобы учитывать их в своей работе.
Для одной задачи выбирают одного A. Исполнителей R может быть несколько, если понятно, какую часть делает каждый.
Разница между R и A проще всего видна на подготовке предложения клиенту. Менеджер собирает документ и вносит расчёты — это работа R. Руководитель продаж отвечает за готовность предложения и разрешает отправить его на согласованных условиях — это роль A. Руководитель может сам выполнить часть работы, но его ответственность за итог от этого сохраняется.
Буква C означает необходимость получить мнение человека. Если без его разрешения действие запрещено, запишите отдельный этап согласования и назначьте для него A. Иначе сотрудник будет считаться консультантом на бумаге и фактически блокировать весь процесс.
Когда стоит составить матрицу ответственности
Хороший повод — повторяющийся спор на границе отделов. Например, продавец обещает клиенту срок, руководитель исполнения узнаёт об этом после оплаты, а менеджер сопровождения должен объяснить задержку. Каждый участник может добросовестно делать свою часть, но порядок передачи решения остаётся неясным.
Другой сигнал — собственник постоянно соединяет сотрудников вручную. Ему пересылают переписку, просят найти исполнителя, уточнить у коллег статус и решить, чьё слово последнее. Я бы разобрал несколько таких обращений: на каком именно шаге людям понадобилось вмешательство руководителя?
При этом RACI не определяет приоритет задачи, срок её выполнения или требования к качеству. Эти договорённости нужно записывать отдельно. Если сотрудник знает свою роль, но у него одновременно три срочные задачи, руководителю всё равно придётся решить, какую выполнять первой.
Для простой работы одного человека обычно достаточно понятного задания. Матрица становится полезнее, когда результат зависит от нескольких участников. Саму передачу задачи сотруднику я разобрал в статье о делегировании и контроле. Здесь разберём взаимодействие людей из разных отделов.
Как составить RACI для одного процесса
Я предлагаю собирать матрицу вместе с теми, кто выполняет работу. Руководитель задаёт границы процесса и принимает спорные решения. Сотрудники объясняют, какие действия и передачи данных происходят в действительности.
Сначала назовите результат каждого этапа
Слишком широкая строка «работа с клиентом» мало помогает. У неё десятки действий и несколько разных результатов. Полезнее выделить этапы: проверить комплектность заявки, подтвердить срок исполнения, подготовить предложение, передать заказ в работу.
Формулируйте результат так, чтобы его можно было принять. Например: «срок подтверждён руководителем исполнения и записан в карточке заказа». Участникам будет понятно, какой факт позволяет двигаться дальше.
В своей работе я исхожу из трёх вопросов: что запускает задачу, как сотрудники её выполняют и что должны получить на выходе. После этого можно закреплять порядок работы и назначать ответственного. Если сам результат ещё не определён, распределение букв лишь зафиксирует разные представления людей.
Укажите роли и конкретных сотрудников
В строках рабочей таблицы перечислите результаты этапов, в столбцах — участников. В ячейках поставьте R, A, C или I; пустая ячейка означает, что постоянное участие человека на этом этапе не требуется.
Для повторяющегося процесса удобно использовать должности: менеджер продаж, руководитель исполнения, финансовый менеджер. Рядом нужен актуальный список людей, которые занимают эти роли, и порядок замещения на время отсутствия. Для разового проекта можно сразу указать имена.
Затем задайте каждому участнику практический вопрос: «Что вы сделаете, когда этот этап начнётся?» Ответ должен описывать действие. Формулировка «буду участвовать по мере необходимости» оставляет неопределённость.
Договоритесь о полномочиях и передаче работы
К каждой спорной строке я бы добавил короткое пояснение: что получает исполнитель, кому передаёт готовый результат и в каком случае сообщает о проблеме.
Допустим, менеджер вправе предложить клиенту только подтверждённый срок. Если клиент просит выполнить заказ быстрее, менеджер передаёт запрос руководителю исполнения. Пока тот не оценил загрузку, обещание клиенту не даётся.
Отдельно договоритесь о сроке ответа консультанта. Если данные нужны к полудню, это должно быть известно человеку с ролью C. При задержке исполнитель сообщает A, что решение пока невозможно и какие сведения отсутствуют. Молчание коллеги само по себе не означает согласия.
Пример RACI: передача заказа из продаж в исполнение
Рассмотрим условную сервисную компанию. Продажами занимается менеджер, коммерческие условия утверждает руководитель продаж, работу команды планирует руководитель исполнения, оплату проверяет финансовый менеджер. Это пример распределения ролей; в вашей компании полномочия могут отличаться.
Проверить заявку клиента
R — менеджер продаж. A — руководитель продаж. C — руководитель исполнения, если нужно уточнить требования к услуге. I — на этом этапе отдельное уведомление другим сотрудникам не требуется.
Результат: в карточке заявки записаны состав услуги, исходные данные и ожидания клиента. Если сведений недостаточно, менеджер уточняет их до расчёта предложения.
Подтвердить возможность и срок выполнения
R и A — руководитель исполнения: он проверяет загрузку и отвечает за реалистичность подтверждённого срока. C — менеджер продаж, который объясняет ограничения клиента. I — руководитель продаж.
Результат: руководитель исполнения записал срок и условия, при которых команда сможет его выдержать. Совмещение R и A здесь означает, что один человек выполняет проверку и отвечает за её итог.
Подготовить и отправить предложение
R — менеджер продаж. A — руководитель продаж. C — финансовый менеджер по условиям оплаты и руководитель исполнения по составу работ. I — остальные участники получают сведения после принятого решения, если это влияет на их работу.
Результат: клиенту отправлена версия предложения с подтверждёнными условиями. Если в ходе переговоров клиент меняет объём услуги, менеджер возвращает изменения на проверку срока и стоимости.
Проверить поступление оплаты
R и A — финансовый менеджер, если у него есть доступ к данным и полномочия подтвердить платёж. C — менеджер продаж при неясном назначении платежа. I — руководители продаж и исполнения.
Результат: оплата сопоставлена с заказом и отмечена в его карточке. Скриншот платёжного поручения от клиента сам по себе не заменяет проверку поступления денег.
Принять заказ в исполнение
R — менеджер продаж, который передаёт согласованный комплект сведений. A — руководитель исполнения, который принимает заказ в работу. C — финансовый менеджер по статусу оплаты. I — руководитель продаж.
Результат: руководитель исполнения подтвердил, что получил актуальные условия, исходные данные и сведения об оплате. Если чего-то не хватает, он называет недостающие пункты и возвращает заказ менеджеру на уточнение.
В этом примере отдельно виден переход между отделами. Отправленное сообщение ещё не подтверждает, что следующий участник получил всё необходимое и принял работу. Это подтверждение стоит сделать явным.
Какие ошибки обнаружить до запуска
Чаще всего обсуждение застревает на слове «ответственный». Один сотрудник понимает его как обязанность всё сделать, другой — как право проверить чужую работу. Сначала согласуйте расшифровку ролей на понятном примере, затем обсуждайте распределение.
Если на один результат претендуют два руководителя, выясните, какие решения они принимают. Возможно, в строке объединены две задачи: подтвердить техническую возможность и разрешить коммерческие условия. Разделите результаты. Если решение действительно общее, договоритесь, кто разрешает разногласие и кто фиксирует итог.
Ещё одна ошибка — назначить A человеку, который не может получить данные или повлиять на срок. Я бы проверил это вопросом: «Что он вправе сделать, если исполнитель занят другой работой?» Иногда нужно изменить порядок согласования приоритетов или дать доступ к данным. Одной записи в таблице для этого недостаточно.
Обратите внимание и на собственника. Если он указан как A почти в каждой строке, сотрудники по-прежнему будут ждать его решений. Выберите несколько типовых ситуаций, определите допустимые условия и передайте право решать их руководителям. Исключения, которые действительно требуют вашего участия, перечислите отдельно.
Как проверить матрицу на реальной работе
До общего запуска возьмите один недавно завершённый заказ и пройдите по его истории. Кто запросил исходные данные? Кто подтвердил срок? Когда изменились условия? Кто первым узнал об изменении? Сопоставьте ответы с предложенным распределением ролей.
Затем разберите сбой: консультант не ответил вовремя, исполнитель заболел или клиент поменял задание. Участники должны назвать следующий шаг и человека, который примет решение. Если ответ снова звучит как «спросим у собственника», проверьте, действительно ли вопрос требует вашего участия.
На первых новых заказах я советую отмечать только конкретные затруднения: потерянную передачу данных, спор о полномочиях, ожидание ответа, возврат из-за неполного комплекта. По этим случаям понятнее, что исправлять. Сам факт заполнения матрицы ещё ничего не говорит о качестве работы.
Назначьте человека, который обновит распределение ролей при смене сотрудников или порядка работы. У команды должна быть одна действующая версия с датой изменения. Иначе на следующем спорном заказе каждый откроет свой документ.
Начать можно с ближайшей передачи заказа между двумя отделами. Соберите её участников, определите принимаемый результат и договоритесь, кто делает работу, кто принимает итог и что происходит при задержке. После одного реального прохода исправьте найденные пробелы. Такая проверка покажет, где людям действительно не хватало ясности, а где требуется решение о загрузке, навыках или полномочиях.
