Проектирование программы 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). Напомним ключевые проблемы из предыдущих модулей:
| Проблема | Модуль | Текущее состояние |
|---|---|---|
| 15% дубликатов клиентов | M04 (Качество) | Ad-hoc проверки, нет мониторинга |
| 80+ неконтролируемых дашбордов | M03 (Метаданные) | Нет каталога, tribal knowledge |
| 152-ФЗ: нет согласий, нет классификации | M05 (Приватность) | Legal на case-by-case основе |
| Общие credentials к базам | M06 (Безопасность) | Нет RBAC, нет audit logging |
| ML-модель без governance | M08 (AI) | Нет model cards, нет fairness |
| Нет governance-ролей | M07 (Внедрение) | 0 stewards, 0 DPO |
| Нет инструментов governance | M09 (Инструменты) | Ручные скрипты |
Задача: Спроектировать программу, которая за 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) мы используем матрицу влияния/интереса:
| Стейкхолдер | Влияние | Интерес | Стратегия | Модуль-источник |
|---|---|---|---|---|
| CEO | Высокое | Низкий | Информировать (квартальный отчёт ROI) | M07 |
| VP Engineering | Высокое | Высокий | Вовлекать (weekly sync, executive sponsor) | M07 |
| Marketing Director | Среднее | Высокий | Вовлекать (customer data quality напрямую) | M04, M07 |
| Legal Counsel | Среднее | Высокий | Вовлекать (152-ФЗ compliance) | M05 |
| Data Engineers (3) | Низкое | Высокий | Поддерживать (tooling, automation) | M09 |
| Business Analysts (2) | Низкое | Среднее | Информировать (новые процессы) | M03 |
| ML Engineer (1) | Низкое | Среднее | Информировать (future AI governance) | M08 |
Шаг 4: Интеграция регуляторных требований
Из M05 (приватность и compliance) DataTech имеет два регуляторных контекста:
- 152-ФЗ (текущий) — персональные данные клиентов хранятся без надлежащих согласий, нет классификации данных, нет политики retention
- 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
Целевая модель безопасности:
- RBAC (M06, урок 1) — ролевой доступ вместо shared credentials
- Audit logging (M06, урок 3) — логирование всех операций с данными
- Encryption at rest (M06, урок 2) — шифрование столбцов с PII
- Incident response plan (M06, урок 4) — процедура реагирования на инциденты
Шаг 6: Выбор инструментов
Из M09 (инструменты) применяем послойный подход:
| Приоритет | Инструмент | Категория | Обоснование |
|---|---|---|---|
| 1 (месяц 1-2) | OpenMetadata | Каталог данных | Layer 1: visibility. 200+ таблиц без документации |
| 2 (месяц 2-4) | Great Expectations + dbt tests | Качество | Layer 2: 15% дубликатов, нет quality monitoring |
| 3 (месяц 4-6) | PostgreSQL RBAC + pgaudit | Безопасность | Layer 3: shared credentials -> RBAC |
| 4 (месяц 6-9) | Elementary | Observability | Layer 4: monitoring quality SLAs |
| 5 (месяц 9-12) | OPA/Rego | Policy engine | Layer 5: automated enforcement |
Целевая модель зрелости
Интеграция доменов: почему программа — не сумма частей
Ключевой урок 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 баллов):
| Секция | Баллы | Критерии |
|---|---|---|
| Устав (Charter) | 10 | Миссия, scope, принципы, орг-структура, decision rights, эскалация |
| Политики (Policies) | 15 | 4+ политики, classification, retention, access, quality, enforcement, review schedule |
| RACI-матрица | 10 | 5+ активностей, 4+ ролей, один accountable, responsible для всех |
| Quality Framework | 15 | 5+ dimensions, метрики, пороги, мониторинг, remediation |
| Privacy Controls | 15 | PII inventory, classification, consent, DPIA, breach procedure |
| Security Model | 15 | RBAC, audit logging, encryption, incident response, access review |
| KPIs | 10 | 5+ KPIs, targets, owners, frequency, пороги |
| Roadmap | 10 | 3+ фазы, milestones, зависимости, timeline, success criteria |
Шкала оценки:
- 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-программы — это архитектурное упражнение, объединяющее знания из всех доменов курса:
- Scope определяет, с чего начать (domain-focused для DataTech)
- Организационная модель определяет, кто принимает решения (M07)
- Стейкхолдеры определяют стратегию change management (M07)
- Регуляторные требования определяют минимальный baseline (M05)
- Модель безопасности защищает данные и обеспечивает audit trail (M06)
- Инструменты автоматизируют enforcement (M09)
- Интеграция между доменами создаёт ценность, превышающую сумму частей
В следующем уроке мы проведём assessment организации на примере BioGenesis Lab — компании Level 2, которая уже имеет частичный governance, но с существенными пробелами.