Вы отвечаете за результат. А ресурсами управляет кто-то другой
Представьте обычную управленческую ситуацию.
Руководитель клиентского сервиса отвечает за то, чтобы заявка клиента обрабатывалась не более двух часов. KPI установлен, ответственный назначен, команда сформирована и обучена.
Но для выполнения этого KPI нужны:
- доступность CRM;
- работа API смежной системы;
- своевременная передача данных;
- решение ИТ-инцидентов;
- соблюдение сроков бухгалтерией.
При этом CRM находится в зоне ответственности ИТ, API обслуживает другой департамент, а данные предоставляет ещё одно подразделение.
Когда заявка обрабатывается по времени больше установленного норматива, возникает вопрос: «Почему руководитель клиентского сервиса не обеспечил результат?»
Но если посмотреть на ситуацию системно, возникает другой вопрос: «Какими ресурсами и правами он реально располагал для достижения этого результата?»
И здесь обнаруживается одна из самых серьёзных проблем управления:
Ответственность за результат часто не обеспечивается властью над ресурсами, от которых этот результат зависит.
В должностной инструкции можно написать «обеспечить», «организовать», «контролировать». Можно установить KPI. Но если критические ресурсы находятся вне зоны распоряжения руководителя, сама формулировка ответственности ничего не меняет.
Поэтому предлагается вот такое решение:
Зону ответственности руководителя можно не только назначать — её можно проектировать, динамически определять и управлять ею. А одним из инструментов такого проектирования может быть система управленческих контрактов.
1. Ответственность — это не перечень задач
Традиционный подход к зоне ответственности обычно выглядит так: руководителю назначают подразделение, функции, задачи и KPI. Но в реальной системе управления между задачей и результатом находятся ресурсы.
Например, KPI — среднее время обработки заявок — 2 часа. Чтобы выполнить его, нужны: данные + ИТ-система + сотрудники + время + регламент + доступ к решениям. Если хотя бы один критический ресурс находится за пределами управленческих полномочий руководителя, возникает разрыв.
Поэтому более точная модель выглядит так:
Цель → необходимые ресурсы → права распоряжения → действия → результат
И отсюда следует простой принцип: нельзя устойчиво требовать от руководителя результата, если он не имеет необходимых ресурсов или права распоряжаться ими.
Это не означает, что руководитель должен контролировать абсолютно всё. Это означает, что для каждого критического ресурса должно быть понятно, кто им распоряжается и на каких условиях он предоставляется тому, кто отвечает за результат.
2. Где возникает разрыв ответственности
Разрыв возникает, когда ответственность за результат есть, а управленческого механизма воздействия на критический ресурс нет. На практике встречается несколько вариантов.
1. Ответственность есть, ресурса нет. Руководитель отвечает за сокращение срока обработки заявки, но ему не выделяют необходимое количество сотрудников.
2. Ресурс есть, но права распоряжения нет. Сотрудник формально находится в подразделении руководителя, но решения о его загрузке принимает другой руководитель.
3. Ресурс находится у смежника. Для выполнения результата необходима ИТ-система, которой управляет другой департамент.
4. Ресурс обещан, но обязательства не зафиксированы. «ИТ обычно помогает быстро» — это не управленческий механизм.
5. Результат определён, а условия его достижения — нет. Руководитель отвечает за срок, но не определено, какие входные данные и в какие сроки должны поступать.
6. Задача делегирована, а право принимать решения — нет. Сотруднику говорят: «Сделай», но не дают полномочий изменить необходимые параметры процесса.
Во всех этих случаях проблема выглядит как проблема человека. Но часто это дефект системы управления.
3. Что такое управленческий контракт
Здесь важно сразу сделать оговорку. Контракт в данной модели — не обязательно юридический договор. Это управленческая фиксация отношений между сторонами: кто, кому, какой ресурс, в каком объёме, когда и на каких условиях предоставляет для достижения определённого результата.
Например:
ИТ-департамент предоставляет клиентскому сервису:
- доступность CRM — не менее 99,5%;
- время реакции на критический инцидент — не более 15 минут;
- время восстановления — не более 30 минут.
Это уже не «помогите клиентскому сервису». Это конкретное обязательство по предоставлению ресурса. И если CRM недоступна два часа, причина отклонения становится видимой в системе управления.
4. Контракт как механизм передачи права распоряжения
В логике ресурсно-целевого моделирования контракт можно рассматривать как протокол передачи права распоряжения ресурсом от одного участника системы к другому.
В самом простом виде:
Поставщик → ресурс → Потребитель
Но для управления этого недостаточно. Нужно понимать:
- когда передаётся ресурс;
- кто его передаёт;
- кому;
- сколько;
- чего именно;
- в каком объекте этот ресурс используется;
- для достижения какой цели.
Поэтому контракт связывает между собой несколько элементов управления:
цель + объект + ресурс + работа + время + правила
Именно эта связь делает контракт управленческим инструментом, а не просто договорённостью.
5. Сквозной пример
Вернёмся к клиентскому сервису.
Цель: обрабатывать 95% заявок клиентов не более чем за 2 часа.
Для этого необходимы:
Ресурс / Кто контролирует
- Сотрудники клиентского сервиса — Руководитель сервиса
- CRM — ИТ-департамент
- Данные клиента — Коммерческий блок
- Финансовые данные — Бухгалтерия
- Правила обработки — Руководитель сервиса
Теперь возникает вопрос: может ли руководитель клиентского сервиса отвечать за результат целиком? Если он отвечает за KPI, но не имеет права распоряжаться CRM, то ответ — только частично.
Здесь появляется контракт между ИТ и Клиентским сервисом: предоставить ресурс «доступность CRM» на уровне 99,5% в течение месяца, с временем реакции на критический инцидент не более 15 минут.
Теперь зависимость формализована. Если CRM была доступна — руководитель сервиса отвечает за свою часть результата. Если CRM была недоступна четыре часа — система позволяет увидеть, что причина отклонения находилась за пределами его зоны распоряжения.
Это принципиальное изменение. Контракт не снимает ответственность, он делает её управляемой.
6. Зона ответственности как граница власти
Отсюда можно сформулировать основной тезис:
Зона ответственности руководителя — это не список задач и не набор KPI. Это граница, внутри которой у него есть необходимые права распоряжения ресурсами для достижения закреплённых результатов.
Эта граница не обязательно совпадает с организационной структурой. Она может пересекать несколько подразделений.
Например, руководитель клиентского сервиса может отвечать за клиентский результат, хотя необходимые для него ресурсы находятся у ИТ, бухгалтерии, логистики, коммерческого блока.
В этом случае его зона ответственности фактически формируется не только подчинёнными ему сотрудниками, но и системой контрактов со смежными владельцами ресурсов.
Именно поэтому организационная структура и зона ответственности — не одно и то же.
7. Зону ответственности можно проектировать
Это, пожалуй, самое важное практическое следствие модели.
Когда организации создают новое подразделение или назначают нового руководителя, обычно задают вопрос: «Какие функции мы ему передадим?» В ресурсно-целевой логике вопрос другой:
«За какое изменение состояния объекта он должен отвечать и какие ресурсы необходимы для этого изменения?»
Дальше можно пройти цепочку:
Цель → Какое состояние объекта должно измениться? → Какие ресурсы необходимы? → Кто ими распоряжается? → Какие права нужно передать? → Какие контракты необходимо создать? → Какой становится зона ответственности руководителя?
Таким образом, ответственность становится конфигурируемой. Мы не просто назначаем её человеку. Мы проектируем условия, в которых он действительно может достигать результата.
8. Четыре направления согласования контракта
Хороший управленческий контракт должен быть согласован сразу в нескольких направлениях.
1) Сверху вниз — цели и практики. Что руководство требует получить и какие правила определяют способ работы? Риск: цель размыта или практика устарела.
2) От потребителя — требование к результату. Что должен получить конечный потребитель? Риск: вместо измеримого результата появляются «хотелки».
3) От поставщика — доступность ресурсов. Что поставщик ресурса гарантирует? Риск: ресурс обещан только устно.
4) К исполнителю — возможность выполнить работу. Какие действия должен выполнить исполнитель и какими ресурсами он для этого обеспечен? Риск: задача передана, а право принимать необходимые решения — нет.
Получается своеобразный управленческий крест:
Цель → Контракт → (Потребитель — Ресурс — Исполнитель) ← Поставщик
Если хотя бы одно из направлений не согласовано, контракт может оказаться формальным.
9. Как руководителю использовать модель на практике
Не обязательно сразу строить сложную цифровую модель. Можно начать с простого реестра.
Контракт / Поставщик / Потребитель / Ресурс / SLA / Состояние / Блокер
- CRM / ИТ / Клиентский сервис / Доступность системы / 99,5% / Подписан / —
- Данные клиента / Коммерческий блок / Сервис / Данные / ≤ 10 мин / Отклонение / Задержка
- Финансовая проверка / Бухгалтерия / Сервис / Решение / ≤ 30 мин / Возможен / —
Такой реестр быстро показывает то, чего не видно в должностных инструкциях: от каких внешних ресурсов зависит результат руководителя.
10. Семь вопросов для диагностики зоны ответственности
Чтобы продиагностировать зону ответственности, возьмите любой результат, за который отвечает руководитель, и задайте семь вопросов:
- Какой конкретный результат должен быть получен?
- Какой объект должен изменить своё состояние?
- Какие ресурсы необходимы для этого изменения?
- Кто распоряжается каждым ресурсом?
- Есть ли у руководителя необходимое право распоряжения?
- Если ресурс находится у другого подразделения — существует ли контракт?
- Что происходит, если ресурс не предоставлен в установленном объёме или сроке?
Если на вопросы 5–7 нет ясного ответа, скорее всего, перед вами разрыв зоны ответственности.
Заключение. Ответственность нужно не назначать, а обеспечивать
Традиционная система управления часто действует по принципу: «Вот вам KPI. Теперь отвечайте». Ресурсно-целевая логика предлагает другой подход: «Вот результат. Давайте определим, какие ресурсы необходимы, кто ими распоряжается и какие права должны быть переданы, чтобы этот результат действительно можно было получить».
Контракт в этой модели становится связующим элементом между целью, ресурсом, правом распоряжения, работой и результатом. А система контрактов формирует реальную границу управляемости руководителя.
Отсюда три ключевых принципа:
- Если критический ресурс находится вне зоны распоряжения, то должна существовать договорённость о его предоставлении.
- Если руководитель отвечает за результат, то необходимые для него права и ресурсы должны быть определены.
- Если система регулярно создаёт ответственность без власти — проблема находится не в человеке, а в конструкции управления.
Поэтому зону ответственности руководителя стоит рассматривать не как строку в должностной инструкции и не как набор KPI. Зона ответственности — это спроектированная система прав, ресурсов, целей и контрактов, внутри которой руководитель действительно способен управлять результатом.
И именно поэтому ответственность можно не только назначать, её можно моделировать, проверять и перепроектировать.