Проектирование программы Data Governance: от требований до запуска

Введение

В модулях M01-M09 мы изучали отдельные домены Data Governance (управление данными): от фундаментальных концепций (M01) и архитектуры данных (M02) до AI-governance (M08) и инструментов (M09). Теперь объединяем все домены в единую программу для конкретной организации.

Capstone-модуль отличается от предыдущих: здесь нет новой теории. Вместо этого мы применяем знания из всех модулей к реальным организационным сценариям. Первый урок — проектирование программы с нуля для DataTech Solutions (ДатаТех Солюшенз).

Сценарий: DataTech Solutions — с нуля к Level 3

DataTech Solutions (ДатаТех Солюшенз) — e-commerce компания на Level 1 (Initial). Напомним ключевые проблемы из предыдущих модулей:

Задача: Спроектировать программу, которая за 18 месяцев переведёт DataTech с Level 1 на Level 3 (Defined).

Шаг 1: Определение scope программы

Scope (объём) программы — первое архитектурное решение. Из M07 (проектирование программы) мы знаем три подхода:

• Enterprise-wide: все данные, все системы, все команды
• Domain-focused: один или несколько доменов данных
• System-focused: конкретные системы и pipeline’ы

Для DataTech (500 сотрудников, 7 человек в data-команде) правильный выбор — domain-focused с прогрессивным расширением:

Фаза 1 (0-6 месяцев): Customer Data Domain — решаем проблему 15% дубликатов и 152-ФЗ compliance.

Фаза 2 (6-12 месяцев): Product + Analytics Domain — наводим порядок в 80+ дашбордах и ClickHouse warehouse.

Фаза 3 (12-18 месяцев): Enterprise-wide + AI Governance — покрываем ML-модели и оставшиеся системы.

Шаг 2: Выбор организационной модели

Из M07 мы рассматривали три модели: централизованную, федеративную и гибридную. Для DataTech нужна гибридная модель с постепенным усилением центра:

Ключевые роли (из M07, урок 2 — стейкхолдеры):

• VP Engineering (и.о. CDO) — executive sponsor, бюджет, эскалация
• Data Council — VP Engineering + Senior DE + Business Analyst + Legal Representative
• Data Stewards — 2 доменных стюарда (Customer, Product)
• DPO — ответственный за 152-ФЗ (нанять к 3-му месяцу)

Шаг 3: Карта стейкхолдеров

Из M07 (урок 2) мы используем матрицу влияния/интереса:

Шаг 4: Интеграция регуляторных требований

Из M05 (приватность и compliance) DataTech имеет два регуляторных контекста:

1. 152-ФЗ (текущий) — персональные данные клиентов хранятся без надлежащих согласий, нет классификации данных, нет политики retention
2. GDPR (будущий, 12 месяцев) — планируется выход на рынок ЕС

Governance-программа должна включить:

• Инвентаризация PII (M05, урок 1) — первые 2 месяца
• Классификация данных (M05, урок 3) — параллельно с инвентаризацией
• Управление согласиями (M05, урок 2) — месяцы 3-6
• DPIA процесс (M05, урок 4) — к 6-му месяцу

Шаг 5: Модель безопасности

Из M06 (безопасность и контроль доступа) критические проблемы DataTech:

• Общие credentials — все используют один пароль к PostgreSQL
• Нет audit logging — невозможно отследить, кто что менял
• Нет encryption — PII хранятся в plaintext

Целевая модель безопасности:

1. RBAC (M06, урок 1) — ролевой доступ вместо shared credentials
2. Audit logging (M06, урок 3) — логирование всех операций с данными
3. Encryption at rest (M06, урок 2) — шифрование столбцов с PII
4. Incident response plan (M06, урок 4) — процедура реагирования на инциденты

Шаг 6: Выбор инструментов

Из M09 (инструменты) применяем послойный подход:

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

Интеграция доменов: почему программа — не сумма частей

Ключевой урок capstone-модуля: governance-программа — это система, а не набор изолированных инициатив. Каждый домен связан с другими:

• Качество (M04) зависит от метаданных (M03): quality checks привязаны к dataset owners из каталога
• Приватность (M05) зависит от классификации (M05) и безопасности (M06): RBAC enforcement на основе PII classification
• AI governance (M08) зависит от lineage (M03) и качества (M04): model cards требуют lineage training data и quality metrics
• Инструменты (M09) зависят от процессов (M07): tool adoption без governance процессов — shelfware

Рубрика оценки программы

Полноценная governance-программа оценивается по 8 секциям (100 баллов):

Шкала оценки:

• 90-100: Level 4 (Optimized) — excellence
• 80-89: Level 3 (Defined) — strong program
• 70-79: Level 2 (Managed) — adequate
• 60-69: Level 1 (Initial) — needs improvement
• < 60: Not viable — fundamental gaps

Итоги

Проектирование governance-программы — это архитектурное упражнение, объединяющее знания из всех доменов курса:

1. Scope определяет, с чего начать (domain-focused для DataTech)
2. Организационная модель определяет, кто принимает решения (M07)
3. Стейкхолдеры определяют стратегию change management (M07)
4. Регуляторные требования определяют минимальный baseline (M05)
5. Модель безопасности защищает данные и обеспечивает audit trail (M06)
6. Инструменты автоматизируют enforcement (M09)
7. Интеграция между доменами создаёт ценность, превышающую сумму частей

В следующем уроке мы проведём assessment организации на примере BioGenesis Lab — компании Level 2, которая уже имеет частичный governance, но с существенными пробелами.