Проектирование программы Data Governance

Введение

Программа Data Governance — это не набор инструментов, а организационная система. Успех зависит не от выбора каталога данных или платформы мониторинга, а от того, как спроектирована сама программа: какой подход выбран, как распределены роли, кто принимает решения. В этом уроке мы разберём ключевые архитектурные решения, которые определяют судьбу governance-программы.

Top-Down vs Bottom-Up: два подхода к запуску

Top-Down (сверху вниз) — инициатива идёт от руководства (CDO, CTO, CEO). Создаётся формальная программа, утверждаются политики, назначаются роли. Затем программа внедряется в организации.

Bottom-Up (снизу вверх) — инициатива идёт от практиков (Data Engineers, Analysts). Команда данных начинает формализовать существующие практики, документировать процессы и устанавливать стандарты. Затем эти практики масштабируются.

Гибридный подход

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

Сценарий: DataTech Solutions (ДатаТех Солюшенз)

DataTech находится на Level 1 (Initial) — governance-программа отсутствует полностью. VP Engineering понимает проблему (15% дубликатов клиентов, отсутствие каталога, нет классификации данных), но CDO в компании нет.

Решение DataTech — гибридный подход:

1. Bottom-Up стартовая точка: Data Engineer Алексей начинает документировать 200+ таблиц PostgreSQL, устанавливать naming conventions и базовые quality checks
2. Top-Down легитимизация: VP Engineering представляет бизнес-кейс (ROI 300%) на борде, получает executive sponsorship
3. Формализация: VP Engineering назначается и.о. CDO, создаётся Data Council из 4 человек

Без bottom-up практики DataTech не знала бы, с чего начать. Без top-down поддержки Алексей не смог бы заставить маркетинг соблюдать naming conventions.

Модели организации программы

Централизованная модель

Centralized Governance (централизованное руководство) — все решения о данных принимает единая центральная команда. Data Governance Office (DGO) определяет политики, стандарты и контролирует их соблюдение.

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

Федеративная модель

Federated Governance (федеративное руководство) — решения принимаются на уровне доменов. Каждый домен имеет своего Data Steward (распорядитель данных), который определяет правила для своей области. Центральная команда координирует общие стандарты.

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

Гибридная модель

Центральные политики + доменная автономия в реализации. Центральная команда устанавливает guardrails (граничные условия), а домены реализуют в рамках этих условий.

Для DataTech (Level 1, 500 сотрудников, 4 домена данных):

DecisionMatrix показывает, что централизованная модель наиболее подходит на старте: единые стандарты, контролируемое внедрение, простая структура. По мере роста до Level 2-3 DataTech перейдёт к гибридной модели.

Governance Council: структура и функции

Data Governance Council (совет по управлению данными) — ключевой управляющий орган программы. Council принимает стратегические решения, утверждает политики, разрешает конфликты между доменами.

Состав Council

Типовой состав для организации размера DataTech (500 сотрудников):

Cadence и формат

• Ежемесячно — стандартное заседание (90 минут): review KPIs, обсуждение новых инициатив
• Ежеквартально — стратегическое заседание (3 часа): пересмотр roadmap, бюджет
• Ad-hoc — при критических инцидентах или срочных решениях

Data Steward: ключевая операционная роль

Data Steward (распорядитель данных) — человек, отвечающий за качество и governance данных в своём домене. Steward — это связующее звено между governance-программой и повседневной работой с данными.

Типы Stewards

Выбор подхода к Stewardship

Для DataTech на Level 1 оптимален part-time Domain Steward: существующие сотрудники (аналитик, Data Engineer) выделяют 20% времени на stewardship. Это позволяет начать немедленно без найма, используя доменные знания этих людей.

Для сравнения: FinSecure Bank (ФинСекьюр Банк)

FinSecure на Level 3 использует full-time Business Data Stewards — выделенные позиции в каждом из 5 доменов (клиенты, транзакции, риски, compliance, аналитика). Каждый steward подчиняется CDO напрямую и имеет 47 политик для enforcement. Проблема FinSecure: 2 stewards на 30 человек в команде данных и 800+ таблиц Oracle — enforcement остаётся неоднородным.

Итоги

• Top-down vs Bottom-up — на практике наиболее успешен гибридный подход: executive sponsorship + bottom-up практики
• Централизованная модель — для организаций Level 1-2 с небольшой командой данных
• Федеративная модель — для зрелых организаций (Level 3+) с выделенными доменными командами
• Гибридная модель — наиболее распространённый подход, центральные guardrails + доменная автономия
• Governance Council — управляющий орган с ежемесячными заседаниями, утверждает стратегию и разрешает конфликты
• Data Steward — ключевая операционная роль, связующее звено между программой и практикой

В следующем уроке мы рассмотрим Stakeholder Engagement — как вовлечь заинтересованных лиц, построить RACI-матрицу governance-активностей и преодолеть сопротивление изменениям.