Введение

T+2M в SwiftRide. Top-down sweep дал 30 кандидатов CDE; bottom-up — ещё 12 уникальных. 42 кандидата — слишком много для интуитивной приоритизации. Часть конфликтует: у 5 кандидатов неясная атрибуция владельца (несколько бизнес-юнитов заявляют права или никто); у 3 есть технический владелец, но нет бизнес-владельца; у 6 есть бизнес-владелец, но конфликтующие назначения steward.

Выявление без валидации со стейкхолдерами — это инженерное упражнение, не программа governance. Big 4 на pre-IPO ревью будет проверять не «есть ли список CDE», а «кто подотчётен; кто одобрил; кто сможет защитить каждое решение в интервью». Без процесса со стейкхолдерами все 42 кандидата — это неутверждённый черновик.

Этот урок — методика программы интервью. Выход — валидированный список кандидатов с явной атрибуцией владельца; вход для approval workflow (M4.5).

Открытые vs структурированные вопросники

Открытое discovery-интервью

Цель: обнаружить unknown unknowns. Стейкхолдер добровольно делится сигналами, которые ни top-down, ни bottom-up не выявят.

Формат: 45-60 мин с бизнес-владельцем. Записи + запись голоса (с согласия). Открытые вопросы, без чек-листа.

Примеры вопросов:

• «Расскажите своими словами: чем занимается ваше подразделение, какие решения вы делаете, что нужно знать для защитимых решений?»
• «Какие данные вам нужны в первые 5 минут утра? Что было бы катастрофой, если они неверны?»
• «Какие инциденты за последние 12 месяцев наиболее болезненные? Какие данные были вовлечены?»
• «Если ваша команда данных исчезла на 4 недели, какие 3 дашборда / датасета вы бы запросили первыми?»
• «Какие данные используются для компенсирующих решений (“кому списать премию-fee”; “какого водителя suspend”) — не обязательно видимых в отчётах?»

Выход: ~5-15 уникальных упоминаний данных на интервью. Сверить с существующим списком кандидатов. Чисто новые упоминания → добавить в bottom-up.

Где лучше: ранняя фаза выявления (Фаза 1-2). Старшие бизнес-владельцы (главы бизнес-юнитов, главы Risk Office, лид Compliance).

Структурированное validation-интервью

Цель: валидировать кандидатов, уже в списке. Решить вопросы атрибуции владельца, классификации, периметра.

Формат: 30-45 мин. Предварительно разосланный лист кандидатов. Чек-лист вопросов.

Примеры вопросов на кандидата:

• «Подтверждаете ли вы, что этот датасет критичен для вашего процесса?»
• «Кто бизнес-владелец — вы или другая роль?»
• «Кто делегированный data steward — кто принимает повседневные решения по качеству / определениям / изменениям?»
• «Какие регуляции / контракты требуют точности этих данных?»
• «Какой максимальный бизнес-эффект искажения / простоя этого датасета?»
• «Какие downstream-зависимости вы знаете?»
• «Какой материальный порог для эскалации в случае инцидента?»

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

Где лучше: Фаза 3 (T+2M-T+3M) — после первичного sweep.

RACI для выявления CDE

Выявление CDE — мультистейкхолдерный процесс. RACI проясняет ожидания:

Принципы RACI:

• Один Accountable на CDE на роль. Бизнес-владелец — ровно один человек / роль. Data steward — ровно один. Не «команда XYZ» как Accountable.
• R может быть много — выявление коллаборативно.
• CDO Office Accountable за процесс, не за контент каждого CDE. Domain Lead + Business Owner — за контент.

BCBS 239 Principle 1 требует подотчётность совета директоров + senior management за архитектуру риск-данных. RACI — операционная манифестация этой подотчётности.

3 скрипта интервью

Скрипт A — Business Owner

Целевая аудитория: глава бизнес-юнита, глава Risk Office, лид Compliance. Длительность: 45-60 мин открытое первичное; 30-45 мин структурированная валидация.

Открытие (5 мин):

«Спасибо за встречу. Я работаю над программой CDE. Цель — задокументировать критические data assets организации с явной атрибуцией владельца. Ваше подразделение — [бизнес-юнит]. Вы — подотчётны за бизнес-результаты [бизнес-юнита]. Мы хотим узнать, какие данные критичны для вас. Ваши ответы помогут составить реестр. После этой встречи я пришлю короткий док с tentative CDE для вашего бизнес-юнита; жду ваш sign-off.»

Открытая фаза (25 мин):

• «Расскажите своими словами: чем занимается [бизнес-юнит], какие решения вы делаете еженедельно?»
• «Какие 3-5 data points вам нужны для еженедельного бизнес-ревью?»
• «Какие инциденты за последние 12 месяцев наиболее болезненные? Какие данные были вовлечены?»
• «Если данные были неверны, кого это коснулось бы первым — клиента, регулятора, аудитора, совет директоров?»
• «Какие дашборды / отчёты вы получаете еженедельно? Кто их автор?»
• «Кто владеет этими данными с вашей точки зрения — внутри [бизнес-юнита] или вовне?»

Структурированная фаза валидации (15 мин):

• Показать предварительно разосланный список кандидатов, релевантных бизнес-юниту.
• «Из этого списка — какие подтверждаете как критичные?»
• «Кто будет бизнес-владельцем на CDE?»
• «Кто будет data steward (операционным)?»
• «Какие регуляторные импликации вы видите?»
• «Какой материальный порог искажения / простоя?»

Закрытие (5 мин):

• Подтвердить следующие шаги. Назначить follow-up при необходимости.
• Отправить заметки в течение 24ч на ревью.

Скрипт B — Data Engineer / Platform owner

Целевая аудитория: старший дата-инженер на систему, лид Data Platform. Длительность: 30-45 мин структурированно.

Открытие (5 мин):

«Я координатор программы CDE. Нужен ваш технический вход: для следующих датасетов — что мы знаем о lineage, атрибуции владельца, контролях. Часть этой работы — починить пробелы lineage, выявленные в bottom-up sweep.»

Вопросы на кандидата:

• «Подтверждаете ли вы имя датасета / FQN?»
• «Какие upstream-источники?»
• «Какие downstream-потребители?»
• «Lineage на уровне колонок инструментирован OpenLineage? Если нет — где пробел?»
• «Какое выравнивание владельца в метаданных OpenMetadata — текущее поле Business Owner заполнено?»
• «Какие DQ-тесты запущены против датасета (dbt tests, GE, Soda)?»
• «Эволюция схемы — есть workflow одобрения изменений схемы?»
• «Какой SLA на надёжность пайплайна? Количество отказов за последние 90д?»
• «Обработка чувствительных данных — присутствует ли masking / tokenisation?»
• «Применена ли политика retention — автоматически ИЛИ ad-hoc?»

Закрытие: зафиксировать пробелы (lineage, метаданные атрибуции владельца, DQ, retention) — открытые задачи на пайплайн.

Скрипт C — Auditor / Internal Audit

Целевая аудитория: лид Internal Audit, потенциально внешний аудитор для предпросмотра методологии. Длительность: 45-60 мин структурированно.

Открытие (5 мин):

«Я координатор программы CDE. Мы публикуем методологию + первичный реестр. Хочу собрать перспективу Internal Audit — что нам стоит сделать иначе, чего не хватает, где защитимость слаба.»

Вопросы по методологии:

• «Методология — top-down + bottom-up + hybrid. Что вы думаете про баланс?»
• «Соответствие top-down PCAOB AS 2201 ¶.21 — какие пробелы?»
• «Вселенная отчётности — все релевантные отчёты обследованы? (Income Statement / Balance Sheet / IFRS 18 / ROPA / AI Act / DORA / Pillar 3 cascade / AMLR.)»
• «Покрытие lineage — частичное (62% T+2M). Приемлемо для текущей фазы?»
• «Сигналы использования bottom-up — взвешенное ранжирование защитимо?»

Вопросы по процессу:

• «Дизайн approval workflow — достаточен?»
• «Тайм-бокс 4-8 недель для первичного инвентаря — реалистично для масштаба SwiftRide?»
• «Путь разрешения конфликтов — ясный?»
• «Полнота документации — достаточна для защитимости?»
• «Каденс обновления (ежегодный + по триггерам) — уместный?»

Оценка готовности к аудиту:

• «Будь я внешним аудитором, какие 3 вопроса я задал бы первыми?»
• «Если есть инцидент в AML-мониторинге SwiftPay — может ли выявление проследить evidence?»
• «Какие 3 улучшения вы бы приоритизировали?»

Закрытие: зафиксировать находки; обновить методологию, если материально; задокументировать accept / decline с обоснованием по находке.

Разрешение конфликтов

Конфликт A — два стейкхолдера претендуют на владение

Пример: глава бизнес-юнита Rides и глава бизнес-юнита SwiftAds оба претендуют на владение trip-records (Rides — операционно; SwiftAds — связано с атрибуцией).

Путь разрешения:

1. Идентифицировать основного потребителя. Основной потребитель trip records — операционно Rides + признание выручки (Finance). SwiftAds — производный use case атрибуции.
2. Применить правило владения (по референсу M1.4 из data-governance-course): один data owner на data asset. Выбирать на основе того, кто определяет бизнес-правила.
3. Результат: глава бизнес-юнита Rides — data owner ядра trip_records. SwiftAds получает регулируемый доступ; производная таблица атрибуции (fct_swiftads_attribution) — отдельный CDE с владением SwiftAds.
4. Задокументировать решение: обоснование в реестре CDE; обоих стейкхолдеров перекрёстно как Consulted.

Конфликт B — нет владельца

Пример: tax_withhold_per_period — нет чёткого бизнес-владельца. Finance говорит «Tax-команда»; Tax-команда маленькая (3 человека в Treasury), претендует, что это владение дата-инжиниринга; Engineering претендует, что это process / business ownership.

Путь разрешения:

1. Эскалировать в Data Council. CDO Office представляет.
2. Data Council решает на основе: какая роль подотчётна за регуляторный выход (1099 / VAT filing). Ответ: Treasury через Tax Manager.
3. Импликации ресурсов: у Tax Manager нет полосы — Data Council выделяет 50% полосу аналитика данных Treasury как формального data steward; Tax Manager — бизнес-владелец. Задокументировать в реестре CDE.

Конфликт C — владелец оспаривает классификацию CDE

Пример: глава бизнес-юнита Marketing претендует, что cohort_retention_data — CDE; CDO Office после скоринга критичности (M1.4) считает не-CDE (D2 Regulatory 1, D1 Financial 2).

Путь разрешения:

1. Применить вердикт M1.4 — не-CDE по фреймворку.
2. Задокументировать защиту: бизнес-юнит Marketing видит высокую ценность (корректно), но критерии материальности / регуляторики / кросс-регулятора не достигнуты. Внутренние стейкхолдеры могут считать важным — периметр программы CDO материально другой.
3. Результат: не-CDE для реестра CDE. Бизнес-юнит Marketing продолжает stewardship внутри своего домена без оверлея контролей уровня CDE. Задокументировать обоснование.

Конфликт D — Engineering и Business не согласны по технической точности

Пример: Business Owner утверждает, что driver_earnings_v3 точны; DQ-тесты Engineering показывают 0.3% дельту сверки за последние 30д (повторение паттерна SwiftPay 2024).

Путь разрешения:

1. Данные побеждают. Evidence DQ — первичная истина.
2. Действие: классифицировать CDE как статус under_review в ожидании починки Engineering. Business Owner в курсе; подписанное бизнес-определение не исключает проблему качества данных.
3. Документировать: открытая задача — Engineering расследовать 0.3% дельту до T+2M. Повторно валидировать после починки.

Тайм-боксинг — типичный график

ECB RDARR Guide May 2024 + надзорные приоритеты ECB 2025-2027 — ремедиация RDARR. Только ~14% банков полностью соответствуют. Программное время — типичный первичный инвентарь:

Фактически SwiftRide: T0 → T+3M = 12 недель на первую итерацию; расширенный периметр (пост-первичный) продлевается до T+6M T+9M через квартальные циклы.

Критично: не растягивать тайм-бокс выявления бесконечно. Первичный инвентарь должен быть тайм-боксирован, чтобы поддерживать импульс + форсировать решения о закрытии. После тайм-бокса → опубликовать baseline; последующие циклы обновления улучшают покрытие.

Выход → вход для approval workflow

Выход интервью со стейкхолдерами:

• Валидированные кандидаты — атрибуция владельца подтверждена; конфликты разрешены.
• Журнал разрешения конфликтов — какие конфликты выявлены; как разрешены; обоснование решения.
• RACI на CDE — Business Owner + Data Steward + Engineering point-of-contact + связной Compliance / Legal.
• Пробелы документации — пробелы lineage, DQ, retention, метаданных атрибуции владельца.
• Сводка закрытия тайм-бокса — что сделано, что отложено на следующий цикл, почему.

Вход для M4.5 — approval workflow (proposed → under_review → approved → maintained → retired).

Антипаттерны

”Разберёмся с владением позже”

Симптом: кандидат опубликован без назначенного владельца — placeholder “TBD”.

Почему плохо: TBD = никто. Аудитор находит, доверие к программе страдает.

Исправление: решение о владении требуется до approve. Эскалировать в Data Council, если не можем разрешить.

”Отправил форму, ответа нет”

Симптом: опросник стейкхолдерам отправлен; 30% ответов; остальные — “не ответили”.

Почему плохо: асинхронное выявление — неполное. Выявление — активное вовлечение, не пассивный сбор.

Исправление: планировать живые интервью; нет ответа = эскалировать спонсору или Data Council.

”Валидация только инженером”

Симптом: выявление завершено без интервью с бизнес-владельцами; только технические метаданные.

Почему плохо: отсутствует бизнес-семантика; смысл + пороги эскалации — только бизнес-владелец может артикулировать.

Исправление: обязательное интервью с бизнес-владельцем на кандидата CDE.

”Только открытые” / “Только структурированные”

Симптом: все интервью открытые (без тайм-бокса; долго); или все по чек-листу (пропускает unknown unknowns).

Исправление: hybrid — открытые рано (Фаза 1-2), структурированная валидация поздно (Фаза 3).

”Internal Audit исключён”

Симптом: выявление завершено без консультации с Internal Audit.

Почему плохо: отсутствует независимый вызов; неожиданность аудитора при формальном ревью.

Исправление: включить Internal Audit в консультацию по процессу; задокументировать accept / decline по находке.

Итоги

• Два типа интервью: открытые (обнаружить неизвестное; старшие бизнес-владельцы; Фазы 1-2) + структурированные (валидировать кандидатов; Фаза 3).
• RACI 9 ролей: Data Council (A: финальное одобрение), CDO Office (A: процесс), Domain Lead, Business Owner, Data Steward, Engineering, Compliance, Internal Audit, External Audit.
• Один Accountable на роль на CDE — Business Owner = один человек / роль; Data Steward = один.
• 3 скрипта: Business Owner (45-60 мин открытое + 30-45 мин структурированное) · Engineer / Platform (30-45 мин структурированное техническое) · Auditor (45-60 мин методология + аудит-готовность).
• Разрешение конфликтов: двойная претензия на владение → правило основного потребителя; нет владельца → эскалация в Data Council; спор о классификации → применить фреймворк M1.4; разногласие engineering-business → данные побеждают.
• Тайм-боксинг: 4-8 недель первичный для средней организации (SwiftRide); 2-4 малой; 6-12 мес. крупный банк. Форсировать закрытие.
• SwiftRide T+2M-T+3M: 15-25 интервью; 42 кандидата → валидированы; конфликты разрешены; RACI назначен.
• Антипаттерны: TBD владелец; только async; только инженер; только открытые-или-структурированные; Internal Audit исключён.
• Выход → вход для approval workflow M4.5.
• Следующий урок (M4.5): модель данных реестра CDE + approval workflow — требуемые поля, версионирование, state machine, YAML-схема.