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

Разбираем три модели межфункциональных решений и механизмы, без которых они не работают, смотрим, куда в них встраивается ИИ, и что можно изменить, сохранив действующую структуру.

Главный вывод для руководителя: механизм принятия решений — это не оргструктура. Структуру менять долго и дорого. Права на решения, правила эскалации и порядок совместного выбора можно перенастроить за несколько недель. Именно там, как правило, и прячется большая часть потерь.

Разговор начинается с конкретного заказа, а заканчивается спором о том, чьи приоритеты важнее. Коммерческий директор прав: компания может потерять клиента. Производственный директор тоже прав: ради этого заказа придётся сдвинуть другие. Финансовый директор видит дополнительные расходы. У каждого есть основания возражать, но неясно, кто вправе выбрать допустимые последствия для всей компании.

Масштаб потерь измерен. В глобальном опросе McKinsey (1259 руководителей, 2019) лишь 20% участников сказали, что их компании хорошо принимают решения. Руководители тратят на решения в среднем 37% рабочего времени, и больше половины этого времени, по их же оценке, уходит впустую. Для типичной компании из Fortune 500 это около 530 тыс. рабочих дней управленцев и порядка $250 млн зарплатного фонда в год.

McKinsey выделяет отдельный класс межфункциональных (cross-cutting) решений — частых, повторяющихся, требующих участия нескольких подразделений. С ними сталкиваются руководители всех уровней, а сильнее всего — средний уровень: 68% менеджеров среднего звена считают большую часть своего времени на решения неэффективной, против 57% у топ-менеджмента. И ещё одна находка опровергает привычный компромисс «быстро или качественно»: компании, решающие быстро, примерно вдвое чаще принимают и качественные решения.

При этом сам спор бывает необходим: он делает видимыми риски, которые одна функция не замечает. Проблема возникает, когда компания не различает три разных типа прав:

• право дать экспертную оценку — объяснить последствия для своей зоны
• право остановить недопустимое действие — если нарушены безопасность, качество или закон
• право окончательного выбора — принять последствия от имени компании

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

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

Сравним три модели через одну ситуацию на учебном примере (а не на кейсе реальной компании). Крупный клиент просит отгрузить заказ на два дня раньше. Для этого нужно изменить производственную очередь и оплатить ускоренную доставку; возможны задержки другим клиентам. Продажи, производство, логистика и финансы оценивают последствия по-разному.

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

Такой порядок оправдан, если решение выходит за утверждённый бюджет, меняет стратегические приоритеты или сталкивает цели, которые поставило само первое лицо. Руководитель должен вмешаться и тогда, когда для выбора требуется принять риск, который никому ниже принимать не разрешено.

Эскалация не порок, если она редкая и быстрая. В письме акционерам за 2016 год Джефф Безос описывал ситуации, когда у команд принципиально разные цели: продолжение переговоров само по себе расхождение не устраняет. Он предлагал рано распознавать такие случаи и быстро передавать их выше. Это позиция руководителя относительно практики своей компании, а не доказательство универсального преимущества эскалации.

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

Как настроить механизм. Начать с формата обращения. Вместо переписки на двадцать сообщений руководитель получает записку на одну страницу: что нужно решить, к какому сроку, какие есть варианты, сколько стоит каждый и какое ограничение не позволило выбрать на рабочем уровне. Ответ даётся в гарантированный срок. После решения стоит уточнить, можно ли следующий похожий случай разрешить заранее установленным правилом.

Компания заранее передаёт окончательный выбор одному человеку: руководителю сквозного процесса, продукта или инициативы. Остальные функции имеют право голоса, но не вето. Должности самой по себе недостаточно: нужны определённая область решений и полномочия, признанные всеми участниками.

В учебном примере таким человеком может стать руководитель процесса исполнения заказов. Он получает расчёт от финансов, сведения о загрузке от производства и варианты доставки от логистики. Коммерческий директор объясняет последствия для клиента. После этого ответственный выбирает вариант в пределах своего мандата.

У этой модели несколько документированных вариантов.

Владелец сквозного процесса. Идея восходит к Майклу Хаммеру: в его модели зрелости процессов (PEMM, HBR, 2007) владелец процесса — одно из обязательных условий результата. Это старший руководитель, у которого есть и ответственность, и полномочия по сквозному результату.

Лидер с единственным фокусом. Бывшие топ-менеджеры Amazon Колин Брайар и Билл Карр в книге «Working Backwards» описывают single-threaded leadership — лидера, который полностью отвечает за одну инициативу. При этом устройство команд различалось: для ряда поддерживающих функций сохранялось прямое подчинение функциональному руководителю и взаимодействие с командой инициативы по матричной связи; в других случаях участники напрямую подчинялись лидеру направления. Поэтому этот пример показывает важность выделенного лидера и доступа к ресурсам, но не доказывает, что такую модель всегда можно внедрить без изменения структуры.

Назначенный «D» по конкретному решению. Инструмент RAPID компании Bain разделяет роли: кто готовит рекомендацию, кто даёт вводные, кто обязательно согласует, кто принимает окончательное решение и кто исполняет. Центральный вопрос Bain — «у кого буква D?». В опубликованном описании подразделения Intel ECG участники заранее определили роли при выборе продуктов для дорожной карты; руководитель отмечал сокращение повторных обсуждений.

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

Advice process. В материалах проекта Reinventing Organizations описан порядок, при котором принимающий решение обязан спросить совета у экспертов и у тех, кого решение существенно затронет. Совет остаётся советом: окончательный выбор за ним. Поэтому это не совместное решение группы, а усиленный вариант единоличного решения. Слабое место такого порядка — без открытого доступа к данным процесс не работает.

Корпоративные описания показывают заявленные принципы конкретных компаний. Они не гарантируют такой же эффект в другой организации, но дают проверенные элементы конструкции.

Вернёмся к срочной поставке. Если ответственный вправе пообещать клиенту новый срок, но не может изменить очередь производства или использовать бюджет доставки, он остаётся координатором. Компания добавила ещё одного участника согласований и сохранила прежнюю зависимость от первого лица. Это самый частый сбой модели: титул есть, рычагов нет.

Чтобы модель работала, её механизм должен заранее определять четыре вещи.

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

• Обязательные ограничения. Требования безопасности, качества и законодательства не становятся предметом торга. У специалиста может быть право остановить конкретный вариант из-за нарушения такого требования. Но это не даёт ему права блокировать любой вариант, который кажется неудобным.

• Показатели функций. Если производство теряет премию за изменение графика, которое разрешил владелец процесса в интересах компании, у него появляется стимул сопротивляться. Нужен порядок учёта согласованных исключений, а при необходимости — корректировка показателей.

• Исполнение. Обратный сбой — функции формально отдали решение, но саботируют выполнение. Поэтому в RAPID отдельно прописана роль исполнителя, а в Amazon и Netflix действует правило «не согласен, но берусь».

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

Право окончательного выбора принадлежит определённой группе, но по жёсткой процедуре. Процедура заменяет руководителя: кто входит в группу, что именно она вправе решать, как предложение становится принятым и что происходит, если договориться не удалось. Это не консенсус «пока все не согласятся».

Один из документированных методов — консент в социократии. Предложение проверяют на наличие обоснованных возражений относительно общей цели. Участнику не обязательно считать вариант лучшим; важно, видит ли он основания ожидать ущерб для работы. Возражение «мне не нравится» не считается. Позицию каждого запрашивают явно: молчание не считается согласием.

От совместного установления правил важно отличать принятие отдельных операционных решений. Это различие видно в холакратии: совместная процедура определяет роли, полномочия и правила, а большинство конкретных бизнес-решений человек принимает самостоятельно в пределах своей роли. Известный пример масштабного внедрения холакратии— Zappos. Компания перешла на неё в 2013 году, а в 2015-м Тони Шей предложил сотрудникам либо полностью принять систему, либо уйти с компенсацией. Ушли 18% персонала. К 2020 году компания отошла от «чистой» холакратии. Этот опыт не стоит трактовать как проверку группового принятия каждого операционного решения: речь шла о более широкой системе распределения полномочий. Для рассматриваемой модели здесь важно совместное определение правил и границ, внутри которых отдельные решения могут оставаться единоличными.

В нашем примере собирать группу по каждому срочному заказу слишком затратно. Зато группа может установить общие правила ускорения: каким клиентам оно доступно, какие расходы допустимы, какие обязательства защищены. После этого отдельные заказы решает назначенный ответственный. Совместный выбор правил сочетается с единоличным выбором действий — пожалуй, самая практичная конструкция для иерархической компании.

Для обсуждения понадобятся общие данные о загрузке, стоимости ускорения и нарушениях сроков. Возражение «нам так неудобно» уточняют: какой ущерб ожидается и на чём основана оценка. При неприемлемых последствиях группа сужает область применения или согласует ограниченную пробу с датой пересмотра.

Нужны навыки ведения обсуждения и порядок действий при тупике. В иерархической компании можно заранее предусмотреть передачу нерешённого вопроса общему руководителю — это честный гибрид. И даже у совместного решения должны быть конкретные исполнители, сроки и человек, который проверяет результат. Иначе «мы все решили» быстро превращается в «никто не отвечает».

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

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

Но обратимость не заменяет оценку стоимости ошибки. Решение можно формально отменить и всё равно потерять деньги, доверие клиента или несколько недель работы. Поэтому делегирование учитывает не только возможность отката, но и его цену.

ИИ не добавляет четвёртую модель — он встраивается в каждую из трёх и обостряет в них вопрос ответственности. В первой модели он готовит руководителю сводку для эскалации, во второй подсказывает владельцу процесса, в третьей собирает советы и возражения.

В нашем примере ИИ может собрать данные о заказе, сравнить варианты и предложить перестановку очереди. Но система видит только часть последствий: она учтёт маржу срочного заказа и может не учесть обязательство перед клиентом, которому из-за перестановки задержат отгрузку.

Поэтому для каждого решения полезно различать три режима участия ИИ:

1. Готовит сведения — человек проверяет данные.
2. Предлагает вариант — человек проверяет ещё и основания рекомендации.
3. Исполняет сам в разрешённых пределах — дополнительно нужны границы действий, контроль последствий и возможность остановки.

Начать разумно с первого режима. Следующий шаг — ограниченная проба: система меняет очередь только для заранее определённых заказов, без нарушения подтверждённых сроков и в пределах лимита расходов.

Регулирование закрепляет ответственность за человеком. Статья 14 европейского Регламента об ИИ (AI Act) требует, чтобы высокорисковые системы можно было эффективно контролировать: понимать их ограничения, помнить о склонности чрезмерно доверять выводу системы, иметь возможность отменить или остановить её решение. ИИ в найме, оценке и управлении персоналом прямо отнесён к высокорисковым. Регламент (ЕС) 2026/1744 («Цифровой омнибус») перенёс применение этих требований для кадровых систем на 2 декабря 2027 года.

Для российских компаний ориентир — проект закона Минцифры об основах регулирования ИИ, вынесенный на обсуждение в марте 2026 года. Он вводит риск-ориентированный подход, распределяет ответственность между разработчиком, оператором, владельцем сервиса и пользователем и предусматривает уведомление человека, если автономное решение ИИ затрагивает его права. Ожидаемое вступление в силу — 1 сентября 2027 года; текст может измениться.

«Человек в контуре» — не гарантия. Исследователи предупреждают о когнитивной перегрузке и автоматизационном сдвиге: надзор человека нельзя считать единственной защитой. Картина неоднозначна: в экспериментах в Нидерландах (более 2 800 участников) слепого доверия алгоритму не обнаружили, но проявилось избирательное следование совету, когда он совпадал со стереотипами. Вывод для руководителя: ИИ не столько перекладывает решение на себя, сколько усиливает то, что человек уже был склонен решить.

Что из этого следует:

• Решение, которое затрагивает людей (найм, оценка, увольнение, распределение нагрузки), остаётся за назначенным человеком — с правом и обязанностью не согласиться с системой.
• Подтверждение «в один клик» не считается контролем. Надзирающему нужны полномочия остановить исполнение, время на проверку и доступ к исходным данным.
• Стоит отслеживать, как часто человек не соглашается с ИИ. Если никогда — это сигнал проверить, есть ли контроль на самом деле.
• Предложения системы, применённые ограничения и выполненные действия фиксируются так, чтобы через полгода можно было восстановить, почему она поступила именно так.

Масштаб изменений пока остаётся прогнозом. Gartner в июне 2025 года ожидал, что к 2028 году агентный ИИ будет автономно принимать не менее 15% повседневных рабочих решений. В том же сообщении — трезвая оговорка: более 40% проектов агентного ИИ будут закрыты к концу 2027 года из-за затрат, неясной ценности или слабого контроля рисков.

Шаг 1. Восстановите путь одного решения. Выберите решение, которое регулярно задерживается между подразделениями. Возьмите несколько последних случаев и восстановите путь каждого: когда возник вопрос, каких данных ждали, кто мог его остановить, кто поставил точку и когда началось исполнение. Станет видно, где теряется время — в подготовке информации, выборе или выполнении.

Шаг 2. Опишите механизм на одной странице вместе с участниками. Для ограниченной пробы достаточно рабочей договорённости; если меняются формальные полномочия, бюджеты или обязательные требования, нужно соответствующее утверждение.

1. Какой вопрос решаем и по какому общему результату оцениваем выбор.
2. Кто принимает решение и кого обязан выслушать до выбора.
3. Какие расходы, ресурсы и изменения приоритетов ему разрешены.
4. Какие ограничения нельзя нарушать и у кого есть право остановить недопустимый вариант.
5. В какой срок нужен выбор и при каких условиях вопрос передаётся выше.
6. Кто исполняет решение и какие обязательства других участников меняются.
7. Как участвует ИИ (готовит / предлагает / исполняет в границах) и кто проверяет его действия.

Шаг 3. Через месяц сравните. Время от появления вопроса до решения и от решения до начала исполнения. Сколько вопросов пришлось обсуждать заново, сколько переделок возникло из-за неучтённых последствий. Ускорение полезно, если оно не оплачено ухудшением результата на соседнем участке.

Когда проба сработает, её можно масштабировать: составить реестр из 15–25 решений, которые регулярно застревают на стыках, и пройти тот же путь для каждого.