Елизавета Ефремова – Руководитель как профессия. Управленческий практикум (страница 7)
Здесь же стоит ввести ещё одно важное понятие – архитектура решений. Речь идёт об устройстве системы принятия решений в организации: кто именно принимает решения, на каком уровне они принимаются, какие данные используются, как распределена ответственность и каким образом решения проходят путь от идеи до реализации. В управленческом контексте важны не отдельные решения сами по себе, а та структура, внутри которой они возникают, согласуются, задерживаются, искажаются или реализуются.
Само выражение decision architecture получило известность благодаря работам экономистов и исследователей поведенческой экономики Ричарда Талера и Касса Санстейна. В книге
Если архитектура решений не определена, организация начинает работать в режиме постоянной неопределённости. Сотрудники не понимают, кто имеет право принимать решения, руководители вмешиваются в чужие зоны ответственности, одни решения принимаются слишком медленно, другие – без необходимой информации, третьи – параллельно разными людьми, как будто компания решила провести эксперимент по выращиванию бюрократического многоглавия. В результате система управления перегружается и начинает терять управляемость не потому, что в ней нет умных людей, а потому, что в ней нет понятного порядка решения вопросов.
В практическом смысле архитектура решений включает несколько ключевых элементов. Во-первых, это распределение прав на решения: какие Вопросы решаются на уровне руководителя подразделения, какие – на уровне команды, а какие требуют участия высшего руководства. Во-вторых, это процедуры подготовки решений: кто собирает данные, кто формирует предложения, кто участвует в обсуждении, кто фиксирует итог. В-третьих, это механизмы согласования и контроля, позволяющие отслеживать последствия решений и корректировать их при необходимости. И наконец, важной частью архитектуры является правило эскалации – понимание того, когда вопрос должен быть передан на более высокий уровень управления, а когда он должен быть решён там, где возник.
Простой пример можно увидеть в обычной корпоративной ситуации. В компании запускается новый проект. Руководитель проекта считает, что имеет право самостоятельно принимать решения по бюджету и срокам. Финансовый директор ожидает, что любые изменения бюджета должны согласовываться с ним. Руководитель подразделения полагает, что кадровые решения находятся в его зоне ответственности. В результате каждое значимое действие требует дополнительных согласований, а иногда решения принимаются параллельно разными людьми. Формально никто не нарушает правила, но проект начинает двигаться медленно, конфликтно и дорого. Это и есть типичный пример отсутствия архитектуры решений: система не определяет, кто именно и на каком уровне принимает конкретные решения.
Когда же архитектура решений построена ясно, ситуация выглядит иначе. Команда проекта может самостоятельно принимать решения по срокам и распределению задач, руководитель проекта отвечает за бюджет в пределах установленного лимита, а стратегические изменения согласуются с высшим руководством. В этом случае организация не тратит энергию на бесконечные согласования, потому что правила принятия решений уже встроены в управленческую систему. Иными словами, люди начинают тратить силы не на выяснение того, кто здесь главный по каждому вопросу, а на саму работу.
Таким образом, понятие архитектуры решений позволяет увидеть управление не как цепочку отдельных управленческих актов, а как структуру, внутри которой решения возникают, согласуются и реализуются. Чем яснее эта структура, тем устойчивее работает организация и тем меньше энергии она тратит на внутренние конфликты, бюрократические задержки и управленческое взаимное недоумение.
Главная задача этой главы состоит в том, чтобы помочь руководителю изменить управленческую оптику. Перестать рассматривать управление как серию героических усилий и индивидуальных решений и увидеть его как работу по созданию устойчивой конструкции деятельности. Когда такая конструкция выстроена, организация перестаёт зависеть от постоянных подвигов отдельных людей и начинает работать как система.
Герой в управлении – признак сбоя системы
В организационной культуре героический руководитель почти всегда вызывает восхищение. Это человек, без которого «ничего не летит»: он всегда на связи, всегда в курсе, способен в последний момент спасти проект, договориться с клиентом, закрыть конфликт между подразделениями или лично исправить критическую ошибку. В кризис он вытягивает ситуацию, в аврале берёт на себя решения, при сбое лично вмешивается и восстанавливает порядок.
Со стороны такая фигура выглядит образцом управленческой силы. Его считают незаменимым, на него опираются, его боятся потерять. Однако именно в этот момент система становится максимально уязвимой.
В управленческой логике героизм почти всегда является симптомом системного дефекта. Он возникает там, где отсутствуют устойчивые механизмы распределения ответственности, принятия решений и воспроизводства действий. Руководитель начинает выполнять роль универсального компенсатора: закрывает разрывы между подразделениями, принимает решения за других, удерживает информационные потоки, подменяет процессы личным участием.
На короткой дистанции это действительно создаёт эффект высокой эффективности. Проблемы решаются быстро, клиенты довольны, проекты не останавливаются. Но на длинной дистанции подобная конструкция разрушает систему.
Команда постепенно перестаёт развиваться. Сотрудники привыкают к тому, что в сложных ситуациях решение всё равно будет принято «наверху». Ответственность начинает стекать вверх, а инициативность – исчезать. Ошибки не анализируются как системные сигналы, а исправляются в ручном режиме. Организация становится зависимой от личного ресурса одного человека.
В практике управления можно наблюдать характерную историю. В компании есть руководитель, который умеет «дожимать» любые проекты. Если сроки начинают срываться, он лично включается в работу: звонит подрядчикам, переписывает документы, согласовывает детали с клиентом. Проект в итоге удаётся завершить. Руководителя хвалят за решительность и вовлечённость.
Однако через несколько месяцев ситуация повторяется. Команда снова не успевает, снова возникают противоречия между подразделениями, снова требуется срочное вмешательство. Причина проста: система не была перестроена. Руководитель закрыл последствия, но не изменил архитектуру деятельности.
Похожая динамика возникает в организациях, где руководитель выступает главным каналом коммуникации. Сотрудники привыкли, что любые договорённости проходят через него. В результате информация перестаёт циркулировать напрямую между подразделениями. Каждый ждёт решения руководителя, даже в вопросах, которые могли бы быть решены на рабочем уровне.
Система начинает работать как узкое горлышко: все потоки проходят через одного человека.
Романтизация героизма усиливается культурными ожиданиями. Во многих управленческих культурах, особенно в постсоветском пространстве, фигура героя встроена в коллективное воображение. Руководитель, который «вытянул ситуацию», воспринимается как сильный лидер. Подвиг становится мерой управленческой ценности.
Но у такого представления есть оборотная сторона.
Организация начинает награждать не тех, кто выстраивает устойчивые процессы, а тех, кто способен в последний момент спасти ситуацию. Постепенно формируется парадоксальная динамика: чем больше подвигов совершается, тем меньше стимулов создавать систему, в которой подвиги не нужны.
Этот эффект хорошо объясняется в инженерной логике ТРИЗ – теории решения изобретательских задач. В ТРИЗ существует понятие идеальной системы. Идеальной считается такая конструкция, в которой функция выполняется, но самой системы как будто нет: она не требует дополнительных усилий, ресурсов и постоянного вмешательства.
Если применить этот принцип к управлению, становится ясно: зрелая управленческая система – это та, где деятельность продолжается без постоянных подвигов руководителя. Процессы работают, роли определены, решения принимаются на соответствующих уровнях, а информация циркулирует без необходимости личного вмешательства.