💸 Архитектура RACI: Почему два «Ответственных» убивают процесс
Самая распространенная ошибка при внедрении матрицы RACI — формальный подход к заполнению ячеек. Без четкого разделения этих понятий матрица превращается в очередную бюрократическую таблицу, которая не решает проблему принятия решений.
R (Responsible) vs A (Accountable): В чем разница? 🟣 R (Исполнитель) — это руки процесса. Это тот, кто физически выполняет задачу, пишет код, готовит документ, проводит встречу. Исполнителей может быть несколько (группа разработчиков, отдел маркетинга). 🟣 A (Ответственный за результат) — это голова процесса. Это лицо, которое несет персональную ответственность за итог: успех или провал. Именно этот человек принимает финальное решение («утверждаю» / «не утверждаю») и отвечает за него перед высшим руководством.
🔦 Золотое правило: На каждый этап процесса может быть только один человек с ролью A. Если вы назначаете двух «Ответственных» (например, «Коммерческий директор и Директор по производству»), вы создаете ситуацию коллективной безответственности. При возникновении проблемы каждый будет ожидать решения от другого, или они будут блокировать процесс взаимными вето. Наличие двух букв «A» в одной строке матрицы делает инструмент нерабочим.
Алгоритм распределения ролей в кросс-функциональных процессах
Чтобы матрица работала на стыке подразделений, следуйте жесткой последовательности:
🧎♀️ Декомпозиция: Разбейте процесс на атомарные действия (глагол + существительное: «Утвердить бюджет», «Подготовить макет»). Не используйте обобщения типа «Управление проектом».
🧎 Назначение «А»: Для каждого действия найдите единственного владельца результата. Обычно это руководитель функции, на выходе которой лежит результат этапа.
🧎♂️ Назначение «R»: Определите, кто конкретно выполняет работу. Если исполнителей много, убедитесь, что у них есть внутренний лидер, координирующий их усилия для сдачи работы владельцу «A».
🏃♀️ Фильтрация «C» и «I»: Включайте консультантов (C) только если их мнение критично до принятия решения. Информируемых (I) — только если результат этапа влияет на их работу. Избыток «C» ведет к бесконечным согласованиям, избыток «I» — к информационному шуму.
Давайте рассмотрим на примере: как цикл согласования сократился с 5 дней до 4 часов Ситуация: Производственная компания столкнулась с критическими задержками в запуске новых партий. Согласование спецификаций занимало до 5 рабочих дней. Диагноз: В матрице процесса «Утверждение спецификации» роль «A» была присвоена коллегиально: «Главный инженер и Директор по качеству». Формулировка в регламенте: «Согласовывается обоими руководителями». На практике документы лежали у того, кто был занят, или возвращались при малейшем расхождении мнений. Решение: Роль «A» была передана единолично Главному инженеру как владельцу технического результата. Директор по качеству переведен в роль «C» (консультант): его виза обязательна до передачи документа на финальное утверждение, но право вето заменено на обязанность предоставить мотивированное заключение в течение 2 часов. Результат: Цикл согласования сократился до 4 часов. Конфликты перешли из плоскости «кто подпишет» в плоскость профессиональной дискуссии на этапе консультации.
Также читайте предыдущие посты по этой теме: 🟣 Диагностика хаоса: Как выявить скрытые дублирования функций до внедрения RACI 🟣 Инструмент: Карта рисков процесса (перед внедрением RACI)
📌 А если хотите попрактиковаться в этой теме — Регистрируйтесь на наш интенсив по оргдизайну, который пройдет с 23 по 26 марта. Один из кейсов будет посвящен внедрению матрицы RACI для устранения размытых ролей и ответственности
В этом посте были ссылки, но мы их удалили по правилам Сетки
