Кто такие стейкхолдеры и как с ними работает IT-директор (CIO)

Управление стейкхолдерами (Stakeholder Management) — одна из ключевых управленческих компетенций IT-директора. Особенно если CIO отвечает не только за инфраструктуру, но и за цифровую трансформацию, автоматизацию бизнес-процессов и IT-бюджет.

При этом за довольно сложным английским термином скрывается вполне понятная управленческая деятельность.

Разберём на примерах производственного холдинга, где есть 1С, CRM, склады, производство, логистика и несколько подразделений.

Кто такие стейкхолдеры

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

Проще говоря:

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

Например, вы решили внедрить новую систему согласования платежей в 1С.

В проекте участвуют:

• Финансовый директор — хочет контролировать платежи и бюджеты.
• Генеральный директор — хочет прозрачности финансов.
• Главный бухгалтер — хочет корректного отражения операций.
• Руководители подразделений — хотят быстро согласовывать заявки.
• Сотрудники — хотят удобный интерфейс.
• Разработчики 1С — должны реализовать функциональность.
• Собственник — заинтересован в снижении финансовых рисков.

Все перечисленные — стейкхолдеры одного проекта.

Но у каждого свои интересы, ожидания, полномочия и представления о том, каким должен быть результат.

Именно этим необходимо управлять.

---

Кто является стейкхолдерами IT-директора

У CIO стейкхолдеров существенно больше, чем у обычного руководителя IT-проекта.

Их можно разделить на несколько групп.

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

Например, главный бухгалтер может не финансировать проект внедрения CRM, но существенно влиять на его реализацию, если CRM интегрируется с 1С.

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

---

Зачем IT-директору управлять стейкхолдерами

Представим ситуацию.

Вы как IT-директор хотите внедрить автоматическое бюджетирование заказов в 1С.

Технически задача понятна:

1. Заказ создаётся в системе.
2. Проверяется доступный бюджет.
3. При превышении бюджета запускается дополнительное согласование.
4. После согласования разрешается оплата.

Но возникают противоречия.

Финансовый директор:
«Ни один платёж не должен проходить без контроля бюджета».

Коммерческий директор:
«Нельзя задерживать закупки, иначе мы сорвём поставки клиентам».

Главный бухгалтер:
«Нельзя менять порядок проведения документов, это нарушит учёт».

Генеральный директор:
«Нужно внедрить систему за два месяца и не останавливать работу».

Разработчики:
«На качественную реализацию потребуется четыре месяца».

Здесь нет исключительно технической проблемы.

Есть конфликт интересов.

Если CIO просто начнёт программировать по требованиям финансового директора, проект может столкнуться с сопротивлением других подразделений.

Именно поэтому IT-директор должен заниматься Stakeholder Management.

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

Что это даёт бизнесу

Управление стейкхолдерами позволяет:

• Снижать сопротивление изменениям.
• Предотвращать конфликты между подразделениями.
• Быстрее согласовывать решения.
• Получать ресурсы на проекты.
• Не допускать постоянного изменения требований.
• Повышать вероятность успешного внедрения.
• Обеспечивать принятие новых систем пользователями.

По сути, CIO превращает разрозненные запросы подразделений в согласованную программу IT-развития компании.

---

Основные практики Stakeholder Management

Теперь самое интересное: что конкретно должен делать IT-директор?

Существует несколько распространённых практик.

Практика №1. Stakeholder Mapping — карта стейкхолдеров

Это определение всех заинтересованных сторон и оценка их влияния.

Один из наиболее распространённых инструментов — матрица Power / Interest Matrix.

Она оценивает два параметра:

• Power — насколько человек способен влиять на проект.
• Interest — насколько человек заинтересован в результате.

Получаются четыре категории.

Пример для CIO

Высокое влияние + высокая заинтересованность

Генеральный директор, финансовый директор, руководитель подразделения — заказчика проекта.

С ними необходимо регулярно обсуждать ход проекта, риски и решения.

Высокое влияние + низкая заинтересованность

Например, собственник компании, который не участвует в деталях автоматизации.

Ему нужны краткие отчёты об экономическом эффекте, бюджете и критических рисках.

Низкое влияние + высокая заинтересованность

Сотрудники, которые ежедневно работают в новой системе.

Их необходимо привлекать к тестированию и обучению.

Низкое влияние + низкая заинтересованность

Подразделения, которых проект затрагивает косвенно.

Для них достаточно периодических уведомлений.

Что получает CIO

Конкретную карту:

Это помогает понять, с кем нужно работать особенно плотно.

---

Практика №2. Stakeholder Engagement — вовлечение заинтересованных сторон

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

Например, при внедрении CRM:

• Коммерческий директор определяет цели.
• Руководители продаж согласовывают бизнес-процессы.
• IT определяет архитектуру.
• Финансовый директор согласовывает бюджет.
• Пользователи участвуют в тестировании.
• CEO утверждает ключевые изменения.

Важно, чтобы каждый участвовал на соответствующем уровне.

Распространённая ошибка CIO: согласовать проект с генеральным директором и считать, что этого достаточно.

На практике руководители подразделений могут заблокировать внедрение, если их интересы проигнорированы.

---

Практика №3. Communication Management — управление коммуникациями

Это системная организация общения со стейкхолдерами.

Для разных участников нужна разная информация.

Например:

Обратите внимание на важное различие.

Генеральному директору обычно неинтересно:

«Выполнена интеграция REST API между CRM и ERP».

Ему интересно:

«Теперь менеджеры видят актуальные остатки товаров непосредственно в CRM, что сокращает время обработки заказов».

Одна из компетенций CIO — переводить технические результаты на язык бизнес-ценности.

---

Практика №4. Expectation Management — управление ожиданиями

Очень важная компетенция IT-директора.

Предположим, коммерческий директор говорит:

«Нам нужна интеграция CRM с 1С через две недели».

Разработчики оценивают задачу в шесть недель.

Плохой вариант поведения CIO:

«Хорошо, постараемся».

Через две недели начинается конфликт.

Правильный вариант:

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

Вы предлагаете реалистичные альтернативы.

Основные инструменты

• Согласование требований.
• Определение границ проекта (Scope).
• Фиксация сроков и бюджета.
• Управление изменениями (Change Management).
• Согласование критериев приёмки.
• Регулярная демонстрация результатов.

Главная цель — не допускать разрыва между ожиданиями бизнеса и реальными возможностями IT.

---

Практика №5. RACI — распределение ответственности

Это ещё один инструмент, который часто встречается в вакансиях CIO и IT Project Manager.

RACI помогает определить, кто отвечает за выполнение работы, кто принимает окончательное решение, с кем нужно консультироваться и кого информировать.

Расшифровка:

Пример: внедрение CRM

В конкретной компании распределение может отличаться.

Но суть в том, чтобы не возникала ситуация:

«Я думал, что это должен был согласовать финансовый директор».

Или:

«Почему IT самостоятельно изменило бизнес-процесс?»

В хорошо организованном проекте такие вопросы решаются заранее.

---

Практика №6. Управление конфликтами интересов

Для CIO это особенно актуально.

IT-ресурсы практически всегда ограничены.

Предположим, у вас три крупных запроса:

Все руководители считают свои задачи приоритетными.

Но у IT есть только 200 часов доступной мощности в ближайшем периоде.

Что делает CIO?

Не выбирает задачу исключительно по принципу «кто громче требует».

Он предлагает объективные критерии приоритизации.

Например:

• Экономический эффект.
• Стратегическая значимость.
• Срочность.
• Риски невыполнения.
• Трудозатраты.
• Зависимости между проектами.

Затем формирует рейтинг задач и согласовывает его с руководством.

Здесь появляется ещё одна практика — IT Steering Committee

IT Steering Committee — управляющий комитет по IT.

В него могут входить:

CEO, CFO, CIO и руководители ключевых бизнес-направлений.

На заседаниях комитета рассматривают:

1. Портфель IT-проектов.
2. Приоритеты автоматизации.
3. Бюджеты.
4. Критические риски.
5. Конфликты ресурсов.
6. Решения о запуске или остановке проектов.

Например, комитет собирается один раз в месяц.

CIO готовит материалы и предлагает решения.

Комитет утверждает приоритеты.

Это позволяет сделать IT не обслуживающим подразделением, которое выполняет все запросы подряд, а полноценным участником управления бизнесом.

---

Практика №7. Управление изменениями (Organizational Change Management)

Это не совсем то же самое, что Stakeholder Management, но тесно с ним связано.

Предположим, вы внедрили новую систему контроля закупок.

С технической точки зрения всё работает.

Но сотрудники продолжают согласовывать закупки в Excel и мессенджерах.

Почему?

Потому что:

• Люди не понимают преимуществ.
• Руководители не требуют использовать систему.
• Пользователи не обучены.
• Новые процессы неудобны.
• Сотрудники опасаются усиления контроля.

IT-проект технически завершён, но бизнес-результат не достигнут.

Поэтому CIO необходимо работать с заинтересованными сторонами ещё до внедрения.

Одна из известных моделей управления изменениями — ADKAR:

Например, при внедрении нового процесса в 1С вы не просто выпускаете инструкцию.

Вы объясняете руководителям, зачем нужна система, обучаете сотрудников, организуете поддержку и контролируете фактическое использование.

---

Как это выглядит в повседневной работе CIO

Теперь объединим всё в реальный управленческий процесс.

Представим, что вы IT-директор производственного холдинга.

В компании одновременно идут 15 проектов автоматизации.

Еженедельно

Вы проводите встречи с ключевыми руководителями подразделений.

Обсуждаете:

• Что сделано.
• Что запланировано.
• Какие возникли проблемы.
• Какие решения требуются от бизнеса.
• Изменились ли приоритеты.

Параллельно работаете с IT-командой и подрядчиками.

Ежемесячно

Проводите встречу с CEO/CFO.

Представляете:

Цифры условные.

Ежеквартально

Проводите стратегическую встречу.

Рассматриваете:

• Достижение целей цифровизации.
• ROI ключевых проектов.
• Изменение бизнес-приоритетов.
• IT-риски.
• Новые инициативы.
• Перераспределение бюджета.

Именно такая деятельность обычно подразумевается в вакансиях под фразами:

«Опыт управления ключевыми стейкхолдерами на уровне C-level».

---

Чем Stakeholder Management отличается от обычного управления проектами

Это принципиальный момент.

Они пересекаются, но не заменяют друг друга.

Project Management отвечает на вопрос: «Как реализовать проект?»

Stakeholder Management отвечает на вопрос: «Как обеспечить поддержку заинтересованных сторон и согласовать их интересы для достижения результата?»

Для CIO обе компетенции обязательны.

---

Лист инструментов CIO

Шесть инструментов, которые дают наибольшую практическую пользу.

Важно: не обязательно создавать шесть отдельных документов.

Для среднего производственного холдинга вполне достаточно:

1. Реестра IT-проектов. В нём фиксируются заказчики, ответственные, сроки, бюджеты и статусы.

2. Карты ключевых стейкхолдеров. Кто влияет на решения, какие у него интересы и как с ним взаимодействовать.

3. Регулярного IT-комитета. На нём принимаются решения о приоритетах и ресурсах.

4. Ежемесячного отчёта CIO. Он показывает руководству результаты работы IT на языке бизнеса.

Эти четыре элемента уже позволяют построить достаточно зрелую систему взаимодействия IT с бизнесом.

---

Три уровня зрелости взаимодействия IT с бизнесом

На третьем уровне CIO уже не просто реагирует на запросы.

Он может самостоятельно прийти к коммерческому директору и предложить:

«Мы теряем время при обработке заказов. Предлагаю интегрировать CRM с учётной системой. Это позволит сократить цикл обработки заказов и снизить операционные затраты».

Затем CIO согласовывает инициативу с руководителями, защищает бюджет, организует внедрение и контролирует достижение результата.

Это и есть зрелый Stakeholder Management в работе IT-директора.