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 лучших статей).
Ключевые идеи и принципы
Принцип: пять ролей и их точные функции
Recommend (Рекомендовать) — готовит содержательный вариант решения с обоснованием; роль должна быть только одна, не коллективная — размытое авторство рекомендации размывает и ответственность за её качество.
Agree (Согласовать) — узкое, формальное право вето на конкретный аспект решения (обычно юридический, регуляторный, бюджетный); это не «мне важно высказаться», а реальная блокирующая сила, поэтому число Agree-ролей нужно держать минимальным.
Perform (Исполнить) — кто реально будет реализовывать решение после того, как оно принято.
Input (Дать вводные) — предоставляет фактуру и мнение, но БЕЗ права вето — учитывается, но не обязывает Decide согласиться.
Decide (Решить) — единственный явно названный человек с финальной ответственностью за решение.
Принцип: RAPID решает другую задачу, чем RACI
RAPID часто путают с более известной матрицей RACI (Responsible, Accountable, Consulted, Informed), но методики закрывают разные сценарии. RACI распределяет ответственность за исполнение задач внутри уже понятного процесса — там обычно ясно, кто должен сделать работу. RAPID нужен именно там, где неясно, КТО ПРИНИМАЕТ РЕШЕНИЕ по сложному, многостороннему вопросу — фокус на решении, а не на результате исполнения. У RACI формально может быть несколько «Accountable», у RAPID — только один «Decide». RACI обычно предполагает более широкое консультирование, RAPID — точечный, узкий круг Agree-ролей.
Принцип: четыре типа организационных «узких мест», где решения чаще всего застревают
Глобальное vs локальное — конфликт между централизованной стратегией и потребностями конкретного региона/подразделения.
Центр vs подразделения (функции) — штаб-квартира и бизнес-юниты тянут решение в разные стороны.
Межфункциональные конфликты — разные функциональные направления (маркетинг, продажи, продукт) видят решение по-своему.
Конфликты с внешними партнёрами — решение затрагивает не только внутренние структуры, но и внешних контрагентов/поставщиков.
RAPID особенно ценен именно в этих четырёх типах ситуаций — там, где решение объективно завязано на несколько центров интереса одновременно, и без явного распределения ролей процесс тонет в бесконечных согласованиях.
Принцип: ограничения по числу ролей — не только их наличие
Практическая методология требует не просто заполнить все пять ролей, но и держать их число в разумных пределах: Recommend — строго один человек/команда, не размытая коллективная ответственность; Agree — уместен только там, где решение реально затрагивает юридические, регуляторные или иные формально защищённые интересы, не как способ дать кому-то почувствовать себя услышанным; число Input-участников тоже стоит ограничивать — иначе фаза сбора вводных растягивается без реальной пользы для качества решения.
Принцип: пять правил внедрения RAPID в организации (Bain, 2024)
Разбивать сложные решения на компоненты — не пытаться закрыть одной RAPID-матрицей весь многосоставный стратегический вопрос сразу, а декомпозировать его на отдельные под-решения со своими ролями.
Обучать кросс-функциональные команды одновременно, а не последовательно по отделам — иначе разные части организации усваивают методику по-разному и не понимают друг друга при первом же совместном решении.
80% программы обучения — практика на реальных решениях компании, не абстрактная теория.
Видимое личное участие лидеров в обучении наравне с командой — если топ-менеджмент не проходит то же обучение, что и остальные, методика воспринимается как формальность для нижних уровней.
Итеративный пересмотр распределения ролей каждые 3-4 месяца — состав ролей для конкретного класса решений не высекается один раз навсегда.
По данным этой же практики Bain, компании с качественно выстроенным процессом принятия решений показывают втрое больший рост выручки и на 27 пунктов выше индекс удовлетворённости сотрудников по сравнению с компаниями со слабым процессом решений — методика позиционируется не как формальность документооборота, а как фактор, измеримо влияющий на бизнес-результат.
Ограничения, слепые зоны и критика
RAPID не заменяет содержательную экспертизу — матрица распределяет РОЛИ в процессе, но не гарантирует качество самой рекомендации или решения; плохая роль Recommend с формально правильно расставленными ролями остаётся плохой рекомендацией.
Избыточное формальное применение методики к простым, рутинным решениям создаёт лишнюю бюрократию — RAPID окупается именно на сложных многосторонних решениях (см. 4 типа узких мест выше), не на повседневных операционных задачах.
Методика требует организационной дисциплины на пересмотр — распределение ролей, зафиксированное один раз, устаревает по мере изменения структуры и приоритетов компании; без регулярного пересмотра (правило Bain — каждые 3-4 месяца) матрица перестаёт отражать реальность.
RAPID сама по себе не решает проблему организационной политики — если реальная властная динамика в компании расходится с формально распределёнными ролями, назначенный «Decide» может оставаться формальным, а фактическое решение — приниматься неформально в другом месте.
Типовые ошибки
Ошибка 1: несколько «D» одновременно
Финальная ответственность формально распределяется между несколькими людьми или коллективным органом («решает комитет») — это прямо противоречит сути методики и почти гарантированно ведёт к дедлоку: каждый ждёт, что решение примет кто-то другой, либо согласования тянутся бесконечно.
Как избежать: явно называть ОДНОГО конкретного человека на роль Decide — не должность/отдел/комитет, а имя.
Ошибка 2: разрастание числа «Agree»-ролей (Agree-creep)
Каждый заинтересованный участник хочет получить формальное право вето — список Agree расширяется до состава, где реальное решение оказывается заблокировано согласованиями почти со всеми подряд.
Как избежать: резервировать Agree только для реально формально защищённых интересов (юридических, регуляторных, бюджетных) — не как способ дать каждому почувствовать себя услышанным; для остальных — роль Input, не Agree.
Ошибка 3: смешение Decide и Agree
Роль, которая формально названа Agree (узкое вето), на практике ведёт себя как второй Decide — блокирует решение по собственным предпочтениям, выходящим за пределы её формальной зоны ответственности.
Как избежать: явно и заранее фиксировать, ПО КАКОМУ КОНКРЕТНО аспекту у Agree-роли есть право вето — не общее «согласование», а узкий, названный критерий.
Ошибка 4: «молчаливые» Agree/Input без срока ответа
Роли назначены, но не установлен срок, к которому Agree должен дать ответ или наложить вето, а Input — предоставить вводные — процесс решения зависает в ожидании неопределённо долго.
Как избежать: устанавливать явный дедлайн для каждой Agree/Input роли — если ответа нет к сроку, процесс продолжается без него (правило по умолчанию, зафиксированное заранее, а не решаемое постфактум).
Ошибка 5: неназначенная или формальная роль Perform
Решение принято, но никто явно не назван ответственным за его исполнение — между принятием решения и реализацией образуется разрыв.
Как избежать: заполнять Perform одновременно с остальными ролями, до принятия решения, не оставлять этот вопрос на «потом».
Ошибка 6: применение RAPID к рутинным решениям без реальной сложности
Матрица заполняется для простых операционных вопросов, где распределение ролей и так очевидно — методика превращается в лишний бюрократический ритуал.
Как избежать: применять RAPID выборочно — для решений, реально попадающих в один из четырёх типов организационных узких мест (см. блок «Ключевые идеи» выше), не ко всем решениям подряд.
Главное, что нужно знать
RAPID отвечает на вопрос «у кого D» — распределяет пять ролей (Recommend/Agree/Perform/Input/Decide) в процессе принятия ОДНОГО конкретного решения, заполняется ДО обсуждения.
Decide — всегда один явно названный человек, не коллективный орган; Agree — узкое формальное вето, не способ всех выслушать (для этого есть Input).
Отличие от RACI: RAPID про то, КТО РЕШАЕТ сложный многосторонний вопрос, RACI — про распределение ответственности за исполнение уже понятной задачи.
Главные типовые ошибки — несколько «D» одновременно и разрастание числа «Agree»-ролей (Agree-creep) — обе ведут к дедлоку согласований.
Методика особенно ценна для 4 типов «узких мест»: глобальное/локальное, центр/подразделения, межфункциональные конфликты, конфликты с внешними партнёрами — не для рутинных решений.
План внедрения
Перед совещанием: заполнение матрицы
Определить, действительно ли решение попадает в один из 4 типов организационных узких мест — если нет, RAPID, возможно, избыточен для этого случая.
Назвать ОДНОГО конкретного человека на роль Decide.
Определить роль Recommend — кто готовит содержательный вариант с обоснованием.
Ограничить список Agree только реально формально защищёнными интересами, с явным указанием, по какому именно аспекту у каждого — право вето.
Назначить Perform и зафиксировать сроки ответа для Agree/Input.
На совещании
Явно проговорить распределение ролей вслух перед началом обсуждения — не полагаться, что все и так понимают, кто есть кто.
Собрать Input без обязывающего голосования — вводные учитываются, но финальное слово остаётся за Decide.
Зафиксировать итоговое решение и явно передать его Perform-роли для реализации.
Каждые 3-4 месяца: пересмотр
Регулярно (не разово) сверять, соответствует ли текущее распределение ролей по классам решений реальной организационной структуре и приоритетам компании — состав ролей, зафиксированный один раз, устаревает по мере изменений в компании.
Как реализовать этот план с помощью фрейма «RAPID (Bain & Company)» в OrgDevTools
Фрейм RAPID в OrgDevTools — сетка из пяти цветных карточек (3 в верхнем ряду, 2 в нижнем): Recommend (💡), Agree (✋), Perform (⚙️), Input (🗣️), Decide (✅, визуально выделена градиентом как самая важная). Каждая карточка — свободный список пунктов (людей/ролей), добавляемых по одному кнопкой «+ добавить».
Вердикт фрейма построен ровно по логике методики, а не как простой счётчик заполненности: если ничего не заполнено — фрейм явно советует начать именно с Decide, «по RAPID именно этот единственный человек несёт финальную ответственность за решение» — прямая реализация принципа «сначала называем одного ответственного» из блока «Типовые ошибки» выше. Если Decide не назван при заполненных остальных ролях — явное предупреждение «решение рискует зависнуть в согласованиях». Если Decide назначен, но не описан Recommend — предупреждение, что непонятно, кто готовит содержательную рекомендацию. Только когда распределены все ключевые роли — подтверждение, что решение имеет единственного ответственного.
Заполняя Agree, вписывайте не всех, кто хочет высказаться, а только тех, у кого реально есть формальное право заблокировать решение — фрейм не проверяет это автоматически, это дисциплина заполнения из блока «Типовые ошибки» (Agree-creep) выше.