RAPID: модель ролей в принятии решений (Bain & Company)

RAPID — матрица из пяти ролей в процессе принятия конкретного решения (Recommend, Agree, Perform, Input, Decide), которую заполняют ДО совещания, а не постфактум. Главная цель методики — заменить размытое «мы решили коллективно» на явный ответ на вопрос «у кого D» (у кого право финально решать) — фраза, вынесенная в заголовок оригинальной статьи Bain & Company и ставшая нарицательной в англоязычной консалтинговой практике.

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

Авторы методики — Пол Роджерс и Марсия Бленко, партнёры Bain & Company. Впервые модель системно описана в статье «Who Has the D? How Clear Decision Roles Enhance Organizational Performance», Harvard Business Review, январь 2006 года. Расширенная версия методики с прикладными инструментами внедрения изложена в книге Бленко, Роджерса и Джона Мехиа «Decide & Deliver: Five Steps to Breakthrough Performance in Your Organization» (2010). На русском языке статья 2006 года входит в сборник переводов «Методы принятия решений» издательства «Альпина Паблишер» (2017, серия Harvard Business Review — 10 лучших статей).

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

1. Принцип: пять ролей и их точные функции

   В отличие от общей практики делегирования полномочий, которая распределяет постоянную область ответственности руководителя на будущее, RAPID назначает роли под КОНКРЕТНОЕ решение и может отличаться от решения к решению — один и тот же человек в одном вопросе может быть Decide, а в другом — только Input.

2. Принцип: RAPID решает другую задачу, чем RACI

   RAPID часто путают с более известной матрицей RACI (Responsible, Accountable, Consulted, Informed), но методики закрывают разные сценарии. RACI распределяет ответственность за исполнение задач внутри уже понятного процесса — там обычно ясно, кто должен сделать работу. RAPID нужен именно там, где неясно, КТО ПРИНИМАЕТ РЕШЕНИЕ по сложному, многостороннему вопросу — фокус на решении, а не на результате исполнения. У RACI формально может быть несколько «Accountable», у RAPID — только один «Decide». RACI обычно предполагает более широкое консультирование, RAPID — точечный, узкий круг Agree-ролей. Подробный разбор самой матрицы RACI и её типовых ошибок — в отдельной статье про матрицу ответственности RACI — методики стоит применять последовательно: RAPID сначала определяет, кто решает конкретный сложный вопрос, а RACI затем распределяет ответственность за исполнение уже принятого решения внутри процесса.

3. Принцип: четыре типа организационных «узких мест», где решения чаще всего застревают

   • Глобальное vs локальное — конфликт между централизованной стратегией и потребностями конкретного региона/подразделения.

   • Центр vs подразделения (функции) — штаб-квартира и бизнес-юниты тянут решение в разные стороны.

   • Межфункциональные конфликты — разные функциональные направления (маркетинг, продажи, продукт) видят решение по-своему.

   • Конфликты с внешними партнёрами — решение затрагивает не только внутренние структуры, но и внешних контрагентов/поставщиков.

   RAPID особенно ценен именно в этих четырёх типах ситуаций — там, где решение объективно завязано на несколько центров интереса одновременно, и без явного распределения ролей процесс тонет в бесконечных согласованиях. Какой именно из четырёх типов узкого места доминирует в конкретной компании, во многом определяется её структурой — сильно дивизиональные организации чаще сталкиваются с конфликтом «центр vs подразделения», а матричные — с межфункциональными конфликтами; подробнее о том, как структура порождает предсказуемые паттерны таких конфликтов — в статье про организационные архетипы Минцберга.

4. Принцип: ограничения по числу ролей — не только их наличие

   Практическая методология требует не просто заполнить все пять ролей, но и держать их число в разумных пределах: Recommend — строго один человек/команда, не размытая коллективная ответственность; Agree — уместен только там, где решение реально затрагивает юридические, регуляторные или иные формально защищённые интересы, не как способ дать кому-то почувствовать себя услышанным; число Input-участников тоже стоит ограничивать — иначе фаза сбора вводных растягивается без реальной пользы для качества решения.

5. Принцип: пять правил внедрения RAPID в организации (Bain, 2024)

   • Разбивать сложные решения на компоненты — не пытаться закрыть одной RAPID-матрицей весь многосоставный стратегический вопрос сразу, а декомпозировать его на отдельные под-решения со своими ролями.

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

   • 80% программы обучения — практика на реальных решениях компании, не абстрактная теория.

   • Видимое личное участие лидеров в обучении наравне с командой — если топ-менеджмент не проходит то же обучение, что и остальные, методика воспринимается как формальность для нижних уровней.

   • Итеративный пересмотр распределения ролей каждые 3-4 месяца — состав ролей для конкретного класса решений не высекается один раз навсегда.

   По данным этой же практики Bain, компании с качественно выстроенным процессом принятия решений показывают втрое больший рост выручки и на 27 пунктов выше индекс удовлетворённости сотрудников по сравнению с компаниями со слабым процессом решений — методика позиционируется не как формальность документооборота, а как фактор, измеримо влияющий на бизнес-результат. а как инструмент, напрямую влияющий на измеримые бизнес-результаты, а не только на субъективное ощущение прозрачности процесса.

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

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

1. Ошибка 1: несколько «D» одновременно

   Финальная ответственность формально распределяется между несколькими людьми или коллективным органом («решает комитет») — это прямо противоречит сути методики и почти гарантированно ведёт к дедлоку: каждый ждёт, что решение примет кто-то другой, либо согласования тянутся бесконечно.

   Как избежать

   явно называть ОДНОГО конкретного человека на роль Decide — не должность/отдел/комитет, а имя.

2. Ошибка 2: разрастание числа «Agree»-ролей (Agree-creep)

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

   Как избежать

   резервировать Agree только для реально формально защищённых интересов (юридических, регуляторных, бюджетных) — не как способ дать каждому почувствовать себя услышанным; для остальных — роль Input, не Agree.

3. Ошибка 3: смешение Decide и Agree

   Роль, которая формально названа Agree (узкое вето), на практике ведёт себя как второй Decide — блокирует решение по собственным предпочтениям, выходящим за пределы её формальной зоны ответственности.

   Как избежать

   явно и заранее фиксировать, ПО КАКОМУ КОНКРЕТНО аспекту у Agree-роли есть право вето — не общее «согласование», а узкий, названный критерий.

4. Ошибка 4: «молчаливые» Agree/Input без срока ответа

   Роли назначены, но не установлен срок, к которому Agree должен дать ответ или наложить вето, а Input — предоставить вводные — процесс решения зависает в ожидании неопределённо долго.

   Как избежать

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

5. Ошибка 5: неназначенная или формальная роль Perform

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

   Как избежать

   заполнять Perform одновременно с остальными ролями, до принятия решения, не оставлять этот вопрос на «потом».

6. Ошибка 6: применение RAPID к рутинным решениям без реальной сложности

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

   Как избежать

   применять RAPID выборочно — для решений, реально попадающих в один из четырёх типов организационных узких мест (см. блок «Ключевые идеи» выше), не ко всем решениям подряд.

Как измерить эффект

• Доля решений с единственным назначенным «Decide»: без исключений — наличие более одного человека с ролью Decide по одному вопросу сигнализирует нарушение самого базового правила метода.

• Время от постановки вопроса до принятого решения: сокращение цикла для решений, ранее застревавших в одном из четырёх типов организационных узких мест.

• Число участников роли Agree на решение: контролируемое, небольшое число — рост числа Agree-ролей со временем (Agree-creep) сигнализирует размывание дисциплины метода.

• Регулярность пересмотра матриц ролей: соответствие правилу Bain о пересмотре каждые 3-4 месяца, а не разовое заполнение при внедрении метода.

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

1. Перед совещанием: заполнение матрицы

   • Определить, действительно ли решение попадает в один из 4 типов организационных узких мест — если нет, RAPID, возможно, избыточен для этого случая.

   • Назвать ОДНОГО конкретного человека на роль Decide.

   • Определить роль Recommend — кто готовит содержательный вариант с обоснованием.

   • Ограничить список Agree только реально формально защищёнными интересами, с явным указанием, по какому именно аспекту у каждого — право вето.

   • Назначить Perform и зафиксировать сроки ответа для Agree/Input.

2. На совещании

   • Явно проговорить распределение ролей вслух перед началом обсуждения — не полагаться, что все и так понимают, кто есть кто.

   • Собрать Input без обязывающего голосования — вводные учитываются, но финальное слово остаётся за Decide.

   • Зафиксировать итоговое решение и явно передать его Perform-роли для реализации.

3. Каждые 3-4 месяца: пересмотр

   Регулярно (не разово) сверять, соответствует ли текущее распределение ролей по классам решений реальной организационной структуре и приоритетам компании — состав ролей, зафиксированный один раз, устаревает по мере изменений в компании.

Как реализовать этот план с помощью фрейма «RAPID (Bain & Company)» в OrgDevTools

Фрейм RAPID в OrgDevTools — сетка из пяти цветных карточек (3 в верхнем ряду, 2 в нижнем): Recommend (💡), Agree (✋), Perform (⚙️), Input (🗣️), Decide (✅, визуально выделена градиентом как самая важная). Каждая карточка — свободный список пунктов (людей/ролей), добавляемых по одному кнопкой «+ добавить».

Вердикт фрейма построен ровно по логике методики, а не как простой счётчик заполненности: если ничего не заполнено — фрейм явно советует начать именно с Decide, «по RAPID именно этот единственный человек несёт финальную ответственность за решение» — прямая реализация принципа «сначала называем одного ответственного» из блока «Типовые ошибки» выше. Если Decide не назван при заполненных остальных ролях — явное предупреждение «решение рискует зависнуть в согласованиях». Если Decide назначен, но не описан Recommend — предупреждение, что непонятно, кто готовит содержательную рекомендацию. Только когда распределены все ключевые роли — подтверждение, что решение имеет единственного ответственного.

Заполняя Agree, вписывайте не всех, кто хочет высказаться, а только тех, у кого реально есть формальное право заблокировать решение — фрейм не проверяет это автоматически, это дисциплина заполнения из блока «Типовые ошибки» (Agree-creep) выше.

Книги по теме

Paul Rogers, Marcia Blenko — «Who Has the D? How Clear Decision Roles Enhance Organizational Performance» (Harvard Business Review, январь 2006). Первоисточник методологии — статья, познакомившая широкий менеджерский рынок с RAPID на основе клиентской практики Bain & Company.

Paul Rogers, Marcia Blenko, Michael Mankins — «Decide & Deliver: Five Steps to Breakthrough Performance in Your Organization» (Bain & Company / Harvard Business Press, 2010). Развёрнутое изложение метода с прикладными кейсами.