Интервью с CDO: как выстроить взаимодействие CIO и директора по данным

Типичная картина: компания нанимает директора по данным, очерчивает круг амбициозных задач — от «единого источника правды» до предиктивной аналитики, — и почти сразу возникает трение. Не потому, что кто-то некомпетентен. А потому, что никто заранее не провёл границу: где заканчиваются полномочия CIO (инфраструктура, надежность, эксплуатация) и начинается зона ответственности CDO (качество, семантика, ценность данных). Если эту границу не зафиксировать на старте, компания быстро получает дублирующиеся проекты, конфликт приоритетов и споры о том, кто же на самом деле «владеет» данными.

Почему тема CIO и CDO стала критичной

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

На практике CIO и CDO чаще всего сталкиваются в четырех точках:

• данные как корпоративный актив;
• платформы хранения и обработки;
• аналитика и отчетность для бизнеса;
• безопасность и качество данных.

Если эти точки не описаны в модели управления, взаимодействие быстро превращается в переговоры «по ситуации», а не в системную работу. По сути, CIO начинает нести ответственность за результат, на который он не может влиять напрямую, а CDO вынужден продавливать требования через несогласованные приоритеты. Это классический пример организационного долга, который накапливается быстрее технического.

Чем отличаются CIO и CDO

CIO отвечает за технологическую основу компании: инфраструктуру, приложения, интеграции, надежность сервисов, ИТ-бюджет и эксплуатацию. CDO фокусируется на данных как на продукте управления: качестве, доступности, моделях владения, правилах использования и ценности для бизнеса. Иными словами, CIO строит завод, а CDO отвечает за качество продукции, которую этот завод выдаёт, и за то, чтобы она была нужна рынку.

Коротко о различиях

Такая разница не означает конкуренцию. Напротив, чем раньше компания разделит зоны ответственности и договорится о совместных артефактах управления, тем меньше будет конфликтов на уровне проектов, бюджетов и приоритетов. И тем выше шанс, что data-driven трансформация не останется только в слайдах.

Где чаще всего возникает конфликт

Самая типичная ошибка — когда компания запускает направление data management, но не определяет, кто владелец платформ, кто отвечает за качество данных и кто согласует изменения в источниках. В результате CDO обещает бизнесу сквозную аналитику, а CIO вынужден отвечать за техническую реализацию без права влиять на требования. Это создаёт токсичную петлю: бизнес недоволен скоростью, ИТ-блок перегружен переделками, а CDO не может гарантировать качество данных.

Основные причины конфликтов

• Размытая ответственность за данные и ИТ-платформы.
• Разные KPI: у CIO часто надежность и сроки, у CDO — качество и ценность данных.
• Параллельные инициативы: разные команды внедряют похожие витрины, справочники и отчеты, не видя общей картины.
• Слабая архитектурная дисциплина: решения принимаются локально, без общей целевой модели и без учета влияния на остальной ландшафт.

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

Как распределить зоны ответственности

Лучший способ снизить напряжение — формально зафиксировать, где заканчивается зона CIO и где начинается зона CDO. Без формальной рамки любые договорённости держатся на личных отношениях, а это рискованно при смене участников. Инструменты здесь — матрица ответственности, постоянно действующий архитектурный комитет и единый перечень корпоративных данных, который синхронизируется с бизнес-глоссарием.

Практическая схема

• CIO владеет технологической платформой, интеграциями, эксплуатацией, резервированием и доступностью. Он гарантирует, что системы работают с оговоренным SLA и что архитектурные изменения не разрушают ландшафт.
• CDO владеет правилами работы с данными, качеством, семантикой показателей, каталогом данных и требованиями к аналитике. Он определяет, что считать «чистыми данными» и как измерять их пригодность для бизнес-решений.
• Совместная зона — выбор архитектуры data platform, приоритеты развития и контроль результатов для бизнеса. Это зона, где технические ограничения встречаются с бизнес-требованиями к аналитике.

Что обязательно нужно зафиксировать

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

Как выстроить рабочее взаимодействие

Чтобы CIO и CDO не мешали друг другу, им нужен не просто регулярный созвон, а единый управленческий механизм. Я видел, как компании тратят месяцы на согласование меморандумов, но так и не запускают реальное взаимодействие. Секрет в том, чтобы строить его не вокруг ролей, а вокруг общих целей бизнеса и конкретных артефактов: дорожной карты, архитектурных принципов и набора метрик, понятных CEO.

Рабочая модель из пяти шагов

1. Согласовать общую цель

Цель должна быть не технической, а бизнесовой: сокращение времени подготовки отчетности, повышение точности прогноза, снижение потерь из-за ошибок данных. Например, не «внедрить data lake», а «обеспечить CFO план-факт за два дня, а не за две недели».

2. Определить владельца данных

Для каждого критичного домена данных нужен владелец со стороны бизнеса и ответственный со стороны ИТ. Без института владельцев data governance остается формальностью: регламенты написаны, но на практике данные продолжают жить своей жизнью.

3. Ввести единый backlog

Все инициативы по данным и ИТ должны попадать в один портфель и приоритизироваться по общей шкале ценности для бизнеса. Иначе CIO и CDO будут конкурировать за ресурсы, и вместо синергии получится борьба бюджетов.

4. Настроить архитектурный комитет

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

5. Вести общие метрики

Если у CIO только SLA по доступности, а у CDO только количество построенных витрин, бизнес не поймет, есть ли реальный эффект. Нужны метрики ценности: время получения отчета, доля корректных записей, сокращение ручных операций, скорость запуска нового аналитического продукта.

Какие KPI стоит использовать

Плохая практика — оценивать CIO и CDO по разным, слабо связанным метрикам. Тогда каждый оптимизирует свой участок и не отвечает за общий результат. На уровне CEO это выглядит так: ИТ-служба отчитывается о 99,9% доступности, CDO — о запуске десяти новых витрин, а финдиректор по-прежнему вручную перепроверяет цифры. Гораздо полезнее использовать смешанную систему KPI, где есть и технологические, и бизнес-показатели.

Пример набора KPI

• доля данных с подтвержденным владельцем — показывает зрелость governance;
• уровень качества данных по критичным атрибутам — сколько записей не требуют ручной очистки;
• время подготовки управленческой отчетности — от запроса до готового дашборда;
• количество инцидентов, связанных с данными — ошибки, расхождения, утерянные записи;
• время вывода нового отчета или витрины — скорость реакции на запрос бизнеса;
• процент автоматизированных процессов обработки данных — доля ETL/ELT без ручного вмешательства.

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

Какие документы нужны на старте

Чтобы взаимодействие не зависело от личных договоренностей, его нужно закрепить документально. Это особенно важно в компаниях, где цифровая трансформация уже вышла за рамки одного ИТ-проекта и затрагивает несколько функций. Документы здесь — не бюрократия, а инструмент масштабирования модели управления: новые команды и руководители должны быстро входить в контекст, не изобретая колесо.

Минимальный набор артефактов

• модель распределения ответственности (RACI по ключевым объектам управления);
• каталог критичных данных с привязкой к источникам и владельцам;
• архитектурные принципы — какие решения допустимы, а какие нет (например, прямой доступ к транзакционным системам);
• регламент изменения данных и витрин — как вносятся изменения и кто их согласует;
• дашборд общих метрик, на который смотрит топ-менеджмент;
• план развития data platform, синхронизированный с дорожной картой ИТ-ландшафта.

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

Как проводить интервью с CDO

Если вы готовите интервью с директором по данным, полезно уходить от общих вопросов вроде «как вы видите роль данных» и спрашивать о реальных механизмах управления, конфликтах и архитектурных компромиссах. Тогда материал получится не формальным, а практическим и ценным для CIO, CEO и CDO. Вопросы ниже можно использовать как остов деловой беседы или как чек-лист для самодиагностики тем, кто только выстраивает эту функцию.

Вопросы, которые дают содержательную беседу

• Как вы разделяете ответственность между ИТ и функцией данных?
• Какие конфликты между CIO и CDO возникают чаще всего и как вы их разрешаете?
• Кто должен владеть качеством данных: бизнес, ИТ или data office?
• Как вы измеряете пользу от data initiatives, чтобы бизнес не воспринимал их как ИТ-затраты?
• Какие архитектурные решения помогают избежать дубляжа систем и «зоопарка» витрин?
• Что меняется в управлении, когда данные становятся корпоративным активом, а не побочным продуктом транзакций?
• Какие ошибки компании совершают при запуске роли CDO?
• Как выстраивается взаимодействие с CEO и финансовым директором, особенно в вопросах бюджетирования?

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

Типовые ошибки компаний

Ошибка 1. Назначить CDO без полномочий

Если у директора по данным нет влияния на источники, качество и правила использования данных, роль быстро деградирует до аналитического координатора. Он может красиво рисовать архитектуру данных, но не может добиться её реализации. Симптом: CDO есть, а данные в отчетах продолжают расходиться.

Ошибка 2. Оставить CIO «крайним» за все техническое

Когда CIO отвечает и за платформу, и за качество данных, и за аналитику, а CDO существует отдельно в роли «стратега», границы ответственности размываются. Наступает паралич: CDO говорит «это не ко мне, это к ИТ», а ИТ отвечает «мы не владеем семантикой».

Ошибка 3. Развивать data initiatives без архитектуры

Без целевой архитектуры компания плодит витрины, интеграции и отчеты, которые плохо совместимы друг с другом. Каждое бизнес-подразделение строит свой «уголок аналитики», а потом оказывается, что интеграционная шина не выдерживает нагрузки, а данные противоречат друг другу.

Ошибка 4. Оценивать успех по количеству проектов

Количество внедренных витрин не говорит о качестве управления. Гораздо важнее, насколько быстрее бизнес получает точные данные и принимает решения. Я видел компании с одной хорошо организованной data platform, которые обходили конкурентов с десятком разрозненных решений именно за счёт целостности данных.

Как понять, что взаимодействие работает

Хорошее взаимодействие CIO и CDO видно не по презентациям, а по операционным признакам. Если они есть, значит модель управления действительно функционирует, а не просто красиво описана в регламентах. Эти признаки — что-то вроде «лакмусовой бумажки» для CEO и совета директоров, которые хотят понять реальное положение дел.

Признаки зрелой модели

• споры о данных решаются по регламенту, а не через эскалацию к CEO;
• бизнес получает одинаковые показатели в разных системах и не перепроверяет их в Excel;
• новые витрины и отчеты создаются за дни, а не за месяцы, потому что платформа и семантика готовы;
• меньше ручной сверки и исправлений — данные чистые на входе;
• архитектурные решения согласуются до запуска проекта, а не после первых инцидентов;
• CIO и CDO говорят с бизнесом одним языком ценности, а не на языках доступности и количества справочников.

Еще один важный маркер — на совещаниях по данным CIO и CDO не перебивают друг друга, а дополняют. Это признак того, что граница ответственности осознана и принята.

FAQ

Кто должен быть главнее: CIO или CDO?

Главенство зависит от организационного контекста, но на практике важнее не иерархия, а четкое разделение ответственности и общий контур принятия решений. Без него даже прямое подчинение CDO CEO не спасет от конфликтов с ИТ.

Может ли CDO подчиняться CIO?

Да, если компания делает акцент на технологической платформе данных и CIO обладает достаточной экспертизой в data management. Но даже в этой модели нужно отдельно закреплять полномочия CDO по качеству и владению данными, иначе операционные приоритеты ИТ будут всегда перевешивать стратегические задачи по данным.

Нужен ли CDO в небольшой компании?

Если данных немного и аналитика проста, отдельная роль может быть избыточной — с задачами справится сильный data architect или лид аналитики. Но как только появляются несколько разрозненных источников, регулярная отчетность для руководства и data-driven решения, функция CDO становится критичной, пусть даже поначалу и совмещенной.

С чего начать выстраивание взаимодействия?

С карты ответственности: кто владеет данными, кто отвечает за платформу, кто согласует изменения и какие KPI считаются общими. Это документ на одну-две страницы, но он должен быть подписан как минимум CIO и CDO, а в идеале — утвержден CEO.

Что важнее всего для успеха?

Не количество систем и не объем данных, а единая модель управления, где CIO и CDO работают на один бизнес-результат. Эта модель должна быть видна на уровне метрик, регламентов и архитектурных решений. Без неё любое взаимодействие будет держаться на личных отношениях, а это ненадежно в долгосрочной перспективе.