Управление принятием решений отвечает на вопрос о власти, а не о логике. Его центральная идея заключается в том, что участие и власть — это разные вещи: многие люди могут законно вносить свой вклад в решение, в то время как только один человек принимает окончательное решение. Модель RAPID компании Bain, представленная Полом Роджерсом и Марсией Бленко в Harvard Business Review в 2006 году, разделяет роли Рекомендовать, Согласовать, Выполнить, Внести вклад и Принять решение, делая права вето явными и отличными от консультативного вклада. GitLab назначает Непосредственно Ответственного Лица для каждого решения и проекта, при этом власть и ответственность находятся у одного названного человека, даже если многие вносят свой вклад. Netflix назначает информированного капитана для значительных решений, который собирает мнения и экспертизу, но в конечном итоге принимает решение, сочетая это с нормой активного поиска несогласия, а не предположения, что молчание означает согласие. Все три являются ответами на один и тот же вопрос. Управление принятием решений не оценивает, была ли логика, стоящая за решением, обоснованной — это качество решения — и не определяет, было ли решение выполнено, что является эффективностью решения.

Управление решениями определяет, кто принимает решения, кто вносит вклад, кто утверждает и как решение эскалируется. Оно отвечает на один вопрос и только на один: кто здесь имеет полномочия?
Последнее обновление: 2026-07-29
Самая дорогая неопределенность в большинстве организаций заключается не в том, что решать, а в том, кто принимает решение. Управление решениями отделяет вклад от полномочий: многие люди могут законно вносить предложения, в то время как только один человек принимает окончательное решение. Все остальное — встречи, эскалация, одобрение — вытекает из правильного разделения этих понятий.
Большинство параличей принятия решений — это провал управления, замаскированный под анализ. Решение застревает не потому, что отсутствуют доказательства, а потому, что никто не может с уверенностью сказать, чье это решение — поэтому все консультируются со всеми, права вето обнаруживаются слишком поздно, и один и тот же вопрос обсуждается снова и снова.
Это не конкурирующие теории, а скорее три организации, отвечающие на один и тот же вопрос на разных уровнях формальности.
Отделяет Rекомендацию, Aсогласие, Pроизводство, Iнформацию и Dекрет. Его реальный вклад заключается в том, чтобы сделать Согласие — вето — явным и отличным от консультативной Информации, и настаивать на едином Решении. Введено Роджерсом и Бленко в Кто имеет D? (HBR, 2006).
Один назначенный человек несет ответственность и подотчетность за решение или проект, даже если многие вносят свой вклад. GitLab сочетает это с письменными записями решений, потому что в распределенной организации недокументированное решение фактически не произошло.
Для значительных решений один человек собирает мнения и экспертизу, а затем принимает решение. В паре с поиском несогласия — активным запросом на несогласие, а не трактованием молчания как поддержки, что является режимом неудачи, который в противном случае вызывает единоличный решатель.
Управление определяет, кто принимает решения. Оно намеренно молчит о том, что им было сказано — и ясный решающий, получивший отфильтрованную картину, все равно будет ошибаться.
Участники добавляют аргументы в структурированное дерево, а не в поток. Решатель видит доводы за и против, приписанные к делу, вместо того чтобы опираться на то, что появилось за последние десять минут.
Цепочка вопросов и ответов делает оспаривание предположения нормальным шагом в рабочем процессе, а не актом противостояния — механизмом, стоящим за поиском несогласия.
Решение, причины, возражения и то, какие из них остались без ответа — доступные для получения, когда решение будет пересмотрено, а оригинальные участники уйдут.
Когда решение поднимается на уровень выше, дерево аргументов движется вместе с ним. Следующий принимающий решение наследует рассуждения, а не начинает обсуждение заново.
Управление и рассуждение являются взаимодополняющими. Назначение владельца без улучшения информации, которая доходит до них, приводит к уверенным решениям, основанным на плохой информации.
Зонтик: как управление, доказательства, культура и обучение объединяются в одну систему.
Скорость и выполнение — насколько быстро принимаются решения и затем действительно реализуются.
Скажут ли люди решающему что-то неудобное.
Как решение и его обоснование остаются доступными для поиска спустя месяцы.
Модели прав на принятие решений, сравниваемые бок о бок.
Готовые к аудиту следы решений для регулируемых сред.
Определение прав на принятие решений в организации: кто принимает решения, кто вносит предложения, кто имеет право вето, кто осуществляет реализацию и как решение поднимается на более высокий уровень. Это отвечает на вопрос о полномочиях, отличая его от того, было ли обоснование правильным или было ли решение выполнено.
Управление касается власти — кто принимает решения. Качество решения касается рассуждений — были ли обоснования, альтернативы, доказательства и логика надежными. Решение может иметь безупречное управление и низкое качество, или наоборот. Они дополняют друг друга, а не являются альтернативами.
Модель прав на принятие решений от Bain, разделяющая Рекомендовать, Согласовать, Выполнить, Внести и Решить. Ее отличительная особенность заключается в том, что Согласовать — это подлинное вето — явно отделено от консультативного Внесения, при этом настаивая на едином Решателе, а не на комитете.
DRI — это назначенное лицо, обладающее полномочиями и ответственностью за решение или проект, что зафиксировано в справочнике GitLab. Многие люди могут вносить свой вклад, но один человек отвечает за результат. GitLab связывает это с письменными записями решений из-за своей распределенной модели работы.
Нет, и путать их — это распространенная и дорогостоящая ошибка. Многие люди могут вносить свои мнения и экспертизу, в то время как одно лицо принимает решение. Стремление к консенсусу там, где это никогда не было обещано, приводит к медленным решениям и недовольству, когда кто-то в конечном итоге все равно принимает решение.
Обычно это делается путем классификации решений по обратимости, финансовым рискам, стратегической важности и регуляторному воздействию, а затем установления порогов. Принцип заключается в том, чтобы соотнести объем процесса с стоимостью ошибки, а не с уровнем старшинства того, кто задает вопрос.
Роджерс, П., & Бленко, М. (2006). У кого есть D? Как четкие роли в принятии решений улучшают организационную эффективность. Harvard Business Review.
Модель RAPID — стандартная ссылка для разделения ввода и полномочий.
View source →Бленко, М. У., Манкинс, М. С., & Роджерс, П. (2010). Решайте и выполняйте: 5 шагов к прорывным результатам в вашей организации. Издательство Harvard Business Review.
Права на принятие решений в контексте эффективности организационных решений.
View source →GitLab Handbook — Непосредственно ответственные лица.
Практика DRI, задокументированная GitLab, включая ее связь с письменными записями решений.
View source →Культура Netflix — осведомленный капитан и поиск инакомыслия.
Собственное описание Netflix о владении решениями в сочетании с активно запрашиваемым несогласием.
View source →Четкая власть помогает только в том случае, если информация, доходящая до принимающего решение, полная. Структурируйте аргументы — включая те, которые никто не хотел поднимать.
Начать бесплатно