Бизнес-рассказ о том, как навести порядок в данных банка
От автора. Как появилась эта история
Эта история выросла не из желания написать рассказ. Она выросла из работы.
Я освежал свои знания в области Data Governance — перечитывал то, что знал, собирал разрозненные практики в целостную картину. Хотелось не просто вспомнить термины и фреймворки, а разложить всё по местам: что за чем идёт, что из чего следует, где в этой дисциплине настоящая логика.
Постепенно из этого сложилось представление о том, как выглядит управление данными на самом деле — не в теории, а в живом банке, где есть отчётность перед регулятором, сопротивление бизнеса, инциденты, сроки и люди. Этим представлением хотелось поделиться.
Формат рассказа я выбрал осознанно. Сухое описание методологии читается тяжело и запоминается плохо. А история про человека, который год за годом наводит порядок в данных, показывает то же самое — но на понятных примерах: вот первый день и письмо «срок — вчера», вот первый инцидент, вот первый аудит, вот усталость и передача дел. Так методология становится сюжетом, а роли и процессы — поступками конкретных людей.
Этот рассказ задумывался как материал для общего онбординга: чтобы тот, кто только приходит в тему, за несколько часов получил связное представление о дисциплине. Не справочник и не учебник, а маршрут — от карты данных до культуры, в которой система работает без своего создателя.
Если после этой истории вам захочется взять карту данных, назначить владельца и написать первое правило качества — значит, рассказ сработал.
Главный герой
Андрей Соколов, 38 лет. Head of Data Governance и Data Quality в крупном банке «Северный».
До этого — 7 лет в аналитике и управлении данными. Начинал как аналитик в розничном блоке, потом строил отчётность, потом дорос до руководителя направления. Его взяли в «Северный» с мандатом: навести порядок в данных, пока регулятор не навёл его сам.
Андрей — не теоретик. Он знает, как устроена АБС, как текут данные в DWH, почему бизнес не верит цифрам. Он говорит с ИТ на языке схем, с бизнесом — на языке денег и рисков, с советом директоров — на языке «сколько стоит и что будет, если не сделать».
Содержание
Часть I. Порядок из хаоса
- Первый день
- Карта
- Владельцы
- Правила
- Инцидент
- Каталог
- Контракты
- Совет
Часть II. Первый аудит
- Аудит
- Что хочет регулятор
- Пакет доказательств
- Аудит. День первый
- День второй
- День третий
- Заключение
- Что понял Андрей
Часть III. Конвейер доменов
- Домены
- Волны
- Конвейер. Шаг 1. Владелец
- Шаг 2. Границы
- Шаг 3. Критичные атрибуты
- Шаг 4. Правила
- Шаг 5. Проверки
- Шаг 6. Каталог и lineage
- Шаг 7. Инциденты
- Шаг 8. Метрики
- Волна 3. Сопротивление
- Год спустя
- Что понял Андрей
Часть IV. Культура данных
- Культура
- Три уровня обучения
- Уровень 1. Все сотрудники
- Уровень 2. Владельцы и стюарды
- Уровень 3. Аналитики и ИТ
- Культура. Что это
- Пример сверху
- KPI бизнеса
- История одного владельца
- Год спустя
- Что понял Андрей
Часть V. Возвращение регулятора
- Аудит. Возвращение
- Не готовиться
- Что изменилось
- День первый
- День второй
- День третий
- День четвёртый
- Заключение
- Что понял Андрей
Часть VI. Система, которая работает без тебя
- Три года
- Усталость
- Преемник
- Последний день
- Что понял Андрей
- Звонок
- Что стало с банком
- Новый старт
- Финал
Часть I. Порядок из хаоса
Глава 1. Первый день
Первый рабочий день Андрея начался с письма от CDO:
«Андрей, добро пожаловать. У нас 14 бизнес-доменов. В трёх — хаос. В отчётности перед ЦБ нашли расхождения. Регулятор дал месяц на объяснения. Команды DG нет — её надо собрать. Бюджет — обсуждаем. Срок — вчера. Удачи».
Андрей закрыл ноутбук, налил кофе и открыл список доменов. «Клиенты», «Кредиты», «Платежи», «Отчётность»...
Он понимал: без карты данных он не сдвинется. Без владельцев — не найдёт виноватых. Без правил — не докажет регулятору, что данные достоверны.
Глава 2. Карта
Первые две недели Андрей не трогал команду. Он ходил по кабинетам.
С ИТ-архитектором он рисовал путь данных: АБС → ETL → DWH → витрины → отчётность → ЦБ. На каждом шаге — точка, где данные могли сломаться.
С бизнесом он говорил про деньги: «Если ИНН клиента пустой — отчёт в ЦБ уходит с ошибкой. Штраф — от 300 тысяч до миллиона. Плюс предписание. Плюс репутация».
С рисками — про регуляторику: «ЦБ требует достоверность. Мы не можем доказать, откуда цифра. Это не качество — это нарушение».
К концу второй недели у Андрея была карта. На ней — 14 доменов, 47 источников, 120 витрин. И ни одного владельца.
Глава 3. Владельцы
Андрей пошёл к CDO:
— Мне нужны владельцы данных. По каждому домену. Бизнес, не ИТ. Люди, которые отвечают за смысл, а не за сервер.
— Бизнес не хочет. Говорят, это ИТ-проблема.
— Это не ИТ-проблема. Это проблема отчётности. Если владелец — ИТ, то бизнес не отвечает за цифры. А если не отвечает — значит, не контролирует.
CDO согласился. Через месяц были назначены 14 владельцев — по одному на домен. Ещё 28 стюардов — бизнес и технических. Андрей составил RACI-матрицу: один атрибут — один владелец. Никаких «мы вместе».
Глава 4. Правила
Следующий шаг — качество. Андрей собрал команду: 3 методолога, 2 аналитика, 2 DQ-специалиста. Вместе они выбрали критичные атрибуты: ИНН, сумма кредита, дата платежа, код клиента.
На каждый — правило. На каждое правило — порог. На каждый порог — владелец.
Пример: «Полнота ИНН ≥ 99,5%. Владелец — домен "Клиенты". Проверка — ежедневно. Если ниже — алерт в ServiceNow».
Андрей знал: без порога качество — это вкусовщина. Без алерта — никто не узнает. Без владельца — никто не починит.
Глава 5. Инцидент
Через три месяца — первый крупный инцидент. В отчётность ушли 12% заявок с пустым полем «Индустрия клиента».
Андрей собрал команду:
— Что случилось? — В источнике не заполняют поле. В CRM оно необязательное. — Это инцидент или проблема? — Инцидент — данные уже сломались. Проблема — в CRM поле необязательное, поэтому оно пустое. — Тушим инцидент, устраняем проблему. Инцидент — в ServiceNow. Проблему — в MIRM. RCA — на этой неделе.
RCA показал: CRM не требует поле, потому что бизнес не считал его критичным. Но для отчётности оно критично. Андрей пошёл к владельцу домена:
— Поле нужно. Либо делаем обязательным в CRM, либо заполняем вручную. Но тогда — SLA и ответственный.
Владелец согласился. Поле стало обязательным. Repeat rate по этому инциденту — ноль.
Глава 6. Каталог
Параллельно Андрей строил каталог. Не как документацию, а как рабочий инструмент.
В каталоге — все данные банка: что это, где лежит, кто владелец, откуда пришло. Бизнес-глоссарий связывал термин с полем. Lineage показывал путь: от АБС до отчёта.
Когда архитектор менял схему источника, он обязан был проверить в каталоге: что сломается. Если ломалось — релиз блокировался.
Андрей говорил команде: «Каталог — не музей. Это карта, по которой мы ходим. Если карта врёт — мы падаем».
Глава 7. Контракты
Через полгода Андрей внедрил дата-контракты. Между источником и потребителем — договор: схема, ключи, частота обновления, правила качества, владелец.
Если источник менял схему без обновления контракта — релиз блокировался автоматически. Контроль сдвинулся влево: ошибка выявлялась до того, как данные попадали в витрину.
Андрей говорил: «Раньше мы тушили пожары. Теперь мы не даём им начаться».
Глава 8. Совет
Через год Андрей стоял перед Data Committee. На слайдах — цифры:
Покрытие проверками: 78% критичных атрибутов.
SLA качества: 94% соблюдения.
MTTR: снизился с 48 до 6 часов.
Repeat rate: снизился с 22% до 4%.
Доля превентивных: выросла с 10% до 65%.
Владельцы и стюарды: назначены по всем 14 доменам.
Каталог: используется в change management и архитектурных ревью.
CDO спросил:
— Что дальше?
— Масштабирование. DQLA на все критичные бизнес-процессы. Data contracts — на все источники. И главное — бизнес должен принять ответственность за данные. Не как за проект, а как за BAU.
— Сколько нужно?
— Команда: 12 человек. Бюджет на инструменты. И мандат: DG встроен в change management и архитектурные ревью. Без мандата — это документация, а не управление.
Совет утвердил.
Эпилог части I
Андрей сидел в кабинете и смотрел на карту данных. Год назад — хаос. Сейчас — система.
Он знал: работа не закончена. Данные живут, меняются, ломаются. Но теперь есть люди, правила, инструменты. Есть владельцы, стюарды, контракты. Есть метрики, по которым видно, что всё работает.
Он открыл ноутбук и написал CDO:
«Готов план на следующий год. Масштабирование DG за пределы DWH. DQLA на критичные процессы. Data contracts на все источники. Обучение бизнеса. И — культура данных. Это не проект. Это способ работать».
CDO ответил через минуту:
«Согласовано. Погнали».
Часть II. Первый аудит
Глава 9. Аудит
Через полтора года после старта Андрея в «Северном» пришло письмо из ЦБ. Не штраф. Хуже — проверка достоверности отчётности. Три домена: «Клиенты», «Кредиты», «Отчётность». Срок — две недели. Формат — выездной.
CDO вызвал Андрея:
— Регулятор придёт с вопросами. Нам нужно доказать, что цифры в отчётах достоверны. Не «мы уверены», а «вот доказательства». Сможем?
Андрей ответил не сразу. Он знал: доказать можно только то, что задокументировано. Если процесс есть, но не описан — его нет. Если правило есть, но нет истории проверок — его нет. Если владелец есть, но не подписывал ответственность — его нет.
— Сможем, — сказал он. — Но нужно три дня, чтобы собрать пакет.
Глава 10. Что хочет регулятор
Андрей собрал команду и объяснил простыми словами:
— Регулятор не проверяет, хорошие мы или плохие. Он проверяет, можем ли мы доказать, что цифра в отчёте — правильная. Для этого ему нужно увидеть четыре вещи:
Первое. Откуда взялась цифра. Путь от источника до отчёта. Если мы не можем показать lineage — значит, не контролируем.
Второе. Кто отвечает. Владелец данных, стюард. Конкретные люди, а не «отдел».
Третье. Как проверяем. Правила качества, пороги, история проверок. Не «мы проверяем», а «вот журнал за последние 6 месяцев».
Четвёртое. Что делаем, если ошибка. Инцидент, RCA, corrective action. Не «починили и забыли», а «устранили причину, вот доказательство».
— Если хотя бы одного из четырёх нет — регулятор имеет право усомниться в достоверности. А это уже предписание.
Глава 11. Пакет доказательств
Три дня команда собирала пакет. Андрей разбил его на четыре части.
Часть 1. Lineage На каждый отчёт — карта пути данных. От АБС через ETL до витрины и отчёта. В каталоге — визуализация. Если регулятор спросит «откуда цифра» — ответ за 30 секунд.
Андрей проверил каждый узел. Нашёл две дыры: один источник не был подключён к lineage, одна трансформация не описана. Команда закрыла за сутки.
Часть 2. Владельцы На каждый домен — владелец. На каждый критичный атрибут — стюард. С подписями. Не «назначен приказом», а «ознакомлен, отвечает».
Андрей настоял: владельцы должны лично подтвердить ответственность. Не задним числом, а до аудита. Двое сопротивлялись — «это же не моя зона». Андрей показал RACI-матрицу: «Ваша. Подпись или эскалация к CDO». Подписали.
Часть 3. Правила и история На каждый критичный атрибут — DQ-правило. На каждое правило — порог. На каждый порог — история проверок за 6 месяцев.
Андрей выгрузил дашборды: coverage, pass rate, SLA качества. По трём доменам — 94%, 91%, 97%. Ниже порога — только один атрибут, и по нему уже был corrective action.
Отдельно — журнал инцидентов. Сколько было, как разбирали, что устранили. MTTR — 6 часов. Repeat rate — 4%.
Часть 4. Процесс Андрей описал, как всё работает:
Инцидент → ServiceNow → RCA → corrective action → проверка.
Дата-контракт → проверка в CI/CD → блокировка релиза при нарушении.
Change management → архитектурное ревью → DG-проверка.
К каждому пункту — пример из жизни. Не «мы делаем так», а «вот случай, вот что сделали, вот результат».
Глава 12. Аудит. День первый
Регулятор пришёл с двумя экспертами. Первый вопрос — не про цифры. Про процесс:
— Покажите, как вы понимаете, что данные в отчёте достоверны.
Андрей открыл каталог. Показал lineage: от АБС до отчёта. Показал владельца. Показал правило. Показал историю проверок. Показал журнал инцидентов.
Эксперт спросил:
— А если я возьму вот эту цифру и проверю вручную?
— Возьмите. Вот путь. Вот правило. Вот владелец. Вот проверка за вчера. Если найдёте расхождение — это инцидент, мы его разберём.
Эксперт проверил. Расхождения не нашёл.
Глава 13. День второй
Второй вопрос — про инциденты:
— Покажите, что было за последние полгода. Не только успехи. Всё.
Андрей показал всё. Включая тот случай с «Индустрией клиента». Инцидент, RCA, corrective action, изменение в CRM, повторная проверка.
Эксперт спросил:
— Почему поле вообще было необязательным?
— Потому что бизнес не считал его критичным. Мы это исправили. Владелец домена подтвердил, что поле критично для отчётности. Теперь оно обязательное. Повторных инцидентов нет.
— Докажите.
Андрей показал repeat rate по этому атрибуту — ноль за 8 месяцев.
Глава 14. День третий
Третий вопрос — самый неприятный:
— У вас 14 доменов. Мы проверяем три. Что с остальными?
Андрей не стал врать:
— Остальные в работе. По трём — полное покрытие. По семи — частичное: владельцы есть, правила есть, но coverage ниже 80%. По четырём — на этапе назначения владельцев.
— Почему не всё сразу?
— Потому что мы начали с критичных для отчётности. Это риск-ориентированный подход. Вот roadmap: к концу года — 100% по критичным доменам.
Эксперт кивнул. Он оценил не то, что всё идеально, а то, что есть план и есть прогресс.
Глава 15. Заключение
Через две недели пришёл ответ. Не предписание. Рекомендации. Три пункта:
Ускорить покрытие оставшихся доменов.
Формализовать обучение бизнеса по данным.
Усилить контроль на этапе источников.
CDO собрал совет:
— Мы прошли. Но это не победа. Это аванс. Регулятор вернётся через год.
Андрей добавил:
— И придёт уже не с тремя доменами. А со всеми. Нам нужно закрыть roadmap и встроить DG в BAU. Тогда следующий аудит будет не проверкой, а формальностью.
Глава 16. Что понял Андрей
После аудита он записал для команды пять правил:
Первое. Доказательство важнее уверенности. «Мы знаем» — не аргумент. «Вот журнал» — аргумент.
Второе. Процесс без документации — не процесс. Если не описано, значит, не существует.
Третье. Инциденты — не слабость. Слабость — скрывать инциденты. Сила — показать, как разобрал и устранил.
Четвёртое. Риск-ориентированный подход. Не всё сразу. Сначала критичное для отчётности.
Пятое. Аудит — не экзамен. Это диалог. Регулятор не враг. Он хочет убедиться, что система работает. Дай ему доказательства — и он уйдёт с рекомендациями, а не с предписанием.
Часть III. Конвейер доменов
Глава 17. Домены
После аудита прошло полгода. Андрей сидел на планёрке с CDO.
— Регулятор дал рекомендации. Три домена мы закрыли. Осталось одиннадцать. Из них семь — частично, четыре — вообще без владельцев. Нужен план: как масштабировать DG на все 14 доменов, не потеряв качество.
Андрей открыл карту данных. На ней — 14 доменов, 47 источников, 120 витрин. Он понимал: масштабирование — не про то, чтобы сделать всё сразу. Это про то, чтобы каждый домен прошёл через один и тот же конвейер. Иначе — хаос.
Он взял маркер и написал на доске:
Конвейер домена:
Назначить владельца.
Определить границы.
Выбрать критичные атрибуты.
Написать правила качества.
Настроить проверки.
Подключить к каталогу и lineage.
Встроить в инцидент-менеджмент.
Отчитаться по метрикам.
— Вот по этому конвейеру мы прогоним каждый домен. Не быстрее и не медленнее. 11 доменов за год. По одному в месяц с небольшим.
CDO кивнул:
— Начинай.
Глава 18. Волны
Андрей выписал все 14 доменов и разбил их на три волны.
Волна 1 — критичные для отчётности. Уже закрыты: «Клиенты», «Кредиты», «Отчётность».
Волна 2 — критичные для бизнеса. «Платежи», «Счета», «Карты», «Депозиты», «Скоринг», «Лимиты», «Проценты».
Волна 3 — остальные. «Маркетинг», «Каналы», «Продукты», «Сотрудники».
Андрей объяснил команде:
— Первая волна — потому что без них регулятор. Вторая — потому что без них бизнес теряет деньги. Третья — потому что без них нельзя считать себя зрелой организацией. Но порядок именно такой. Не потому что третья неважна, а потому что ресурсов на всё сразу нет.
Глава 19. Конвейер. Шаг 1. Владелец
По каждому домену — владелец из бизнеса. Не ИТ. Не аналитик. Человек, который отвечает за смысл данных и за решения, которые на них принимаются.
Андрей столкнулся с сопротивлением. «Маркетинг» — «у нас нет данных, у нас креатив». «Каналы» — «это ИТ-тема». «Сотрудники» — «это HR, не наш домен».
Он отвечал одинаково:
— Если у вас есть процессы, которые создают или используют данные — у вас есть домен. Владелец — тот, кто отвечает за результат процесса. Не за сервер. За смысл.
К концу третьего месяца владельцы были назначены по всем доменам второй волны. По третьей — по трём из четырёх. «Сотрудники» остались под вопросом: HR не считал себя частью data-ландшафта. Андрей записал это как риск и пошёл к CDO.
Глава 20. Шаг 2. Границы
Второй шаг — определить, что входит в домен, а что нет.
Андрей собрал владельцев и попросил нарисовать границы. «Клиенты» — кто такой клиент? Только физлицо? Или юрлицо тоже? А если клиент — сотрудник банка? А если он и клиент, и сотрудник?
Споры были жаркими. Андрей не торопил. Он знал: если границы размыты, правила качества будут конфликтовать. Один домен проверит одно, другой — другое.
Через неделю границы были зафиксированы. На каждый домен — карта: какие атрибуты, из каких систем, кто создаёт, кто использует.
Глава 21. Шаг 3. Критичные атрибуты
Не все атрибуты одинаково важны. Андрей ввёл правило: 20% атрибутов дают 80% риска.
С владельцами они выбрали критичные. В «Платежах» — сумма, дата, статус, получатель. В «Картах» — номер, срок действия, статус, лимит. В «Скоринге» — балл, модель, дата расчёта.
Андрей объяснял:
— Мы не будем проверять всё. Мы будем проверять то, что важно. Если ошибка в критичном атрибуте — это инцидент. Если в некритичном — это задача на потом.
Глава 22. Шаг 4. Правила
На каждый критичный атрибут — правило. На каждое правило — порог. На каждый порог — владелец.
Пример из «Платежей»:
Правило: «Сумма платежа > 0».
Порог: «100% соответствие».
Владелец: домен «Платежи».
Пример из «Скоринга»:
Правило: «Балл скоринга заполнен».
Порог: «≥ 99%».
Владелец: домен «Скоринг».
Андрей проверял каждое правило на трёх вопросах: понятно ли бизнесу, проверяемо ли технически, есть ли владелец. Если хотя бы один ответ «нет» — правило не утверждалось.
Глава 23. Шаг 5. Проверки
Правила должны работать автоматически. Андрей подключил DQ-движок. Проверки — ежедневно. Результаты — в дашборд. Алерты — в ServiceNow.
Первая неделя показала проблему: проверок стало слишком много. 300 правил по всем доменам. Алерты сыпались десятками. Команда не успевала.
Андрей пересмотрел подход:
— Не все проверки одинаково важны. Критичные — алерт сразу. Некритичные — в ежедневный отчёт. Иначе мы утонем в шуме.
Он ввёл приоритеты: P1 — алерт и инцидент. P2 — отчёт и задача. P3 — наблюдение.
Глава 24. Шаг 6. Каталог и lineage
Каждый домен — в каталоге. Каждый атрибут — с описанием. Каждый путь — с lineage.
Андрей настаивал: каталог должен быть полезен, а не просто заполнен. Если аналитик не может найти данные за минуту — каталог не работает. Если архитектор не может проверить последствия изменения — lineage не работает.
Команда прошла по каждому домену и проверила: можно ли найти, можно ли понять, можно ли проверить. Три домена пришлось переделывать: описания были формальными, lineage — неполным.
Глава 25. Шаг 7. Инциденты
Каждый домен подключён к инцидент-менеджменту. DQ-инцидент → ServiceNow → RCA → corrective action → проверка.
Андрей ввёл правило: инцидент без RCA не закрывается. Нельзя просто починить данные. Нужно понять, почему они сломались, и устранить причину.
Первый инцидент в «Картах»: 8% записей с неверным сроком действия. RCA показал: в источнике поле заполняется вручную, ошибки при вводе. Corrective action: автоматическая валидация на входе. Repeat rate — ноль.
Глава 26. Шаг 8. Метрики
По каждому домену — метрики:
Покрытие проверками.
SLA качества.
MTTR.
Repeat rate.
Доля превентивных.
Андрей сводил их в единый дашборд. Раз в месяц — отчёт CDO. Раз в квартал — Data Committee.
CDO спросил:
— Зачем тебе метрики по каждому домену? Достаточно общего.
— Нет. Общие метрики скрывают слабые домены. Если у одного 99%, а у другого 60%, среднее будет 80%. А проблема останется в одном домене.
Глава 27. Волна 3. Сопротивление
Третья волна оказалась самой сложной. «Маркетинг» не хотел правила — «мы креативные». «Каналы» не хотели владельца — «это ИТ». «Сотрудники» не хотели вообще ничего — «HR не про данные».
Андрей пошёл к CDO:
— Нужна поддержка. Без мандата третья волна не пойдёт.
CDO собрал Data Committee. Андрей выступил с коротким докладом:
— Первая волна — регулятор. Вторая — деньги. Третья — зрелость. Если мы остановимся на второй, через год вернёмся к тому, с чего начали. Потому что данные не живут в изоляции. Маркетинг использует данные клиентов. Каналы — данные платежей. HR — данные сотрудников. Без них система неполная.
Data Committee утвердил мандат: DG встроен в change management для всех доменов. Без владельца — релиз не проходит.
Глава 28. Год спустя
Через год после старта масштабирования Андрей стоял перед Data Committee.
Результаты:
14 доменов из 14 — с владельцами.
12 доменов — с полным покрытием критичных атрибутов.
2 домена — в процессе (HR и «Продукты»).
Coverage: 92% по критичным атрибутам.
SLA качества: 96%.
MTTR: 4 часа.
Repeat rate: 2%.
Доля превентивных: 78%.
Каталог: используется в change management по всем доменам.
Lineage: покрытие 95%.
CDO спросил:
— Что дальше?
— Культура. Обучение бизнеса. Чтобы владельцы не просто подписывали RACI, а понимали, за что отвечают. Чтобы аналитики не спрашивали «где данные», а шли в каталог. Чтобы DG стал частью работы, а не проектом.
— Сколько нужно?
— Год. И мандат на обучение.
Совет утвердил.
Глава 29. Что понял Андрей
После масштабирования он записал для команды пять правил:
Первое. Конвейер важнее героизма. Один и тот же процесс для каждого домена. Не быстрее, не медленнее.
Второе. Риск-ориентированный порядок. Сначала регулятор, потом деньги, потом зрелость.
Третье. Не всё сразу. 20% атрибутов дают 80% риска. Остальное — потом.
Четвёртое. Метрики по каждому домену. Среднее скрывает слабых.
Пятое. Без мандата масштабирование не работает. DG в change management — не опция, а условие.
Часть IV. Культура данных
Глава 30. Культура
После масштабирования прошёл год. 14 доменов, владельцы, правила, метрики. Система работала.
Но Андрей видел проблему. Владельцы подписывали RACI, но не понимали, за что отвечают. Аналитики шли в каталог, но только когда им напоминали. Бизнес считал DG «проектом ИТ», а не своей ответственностью.
CDO спросил:
— Метрики хорошие. Что не так?
— Метрики — это форма. Культура — это содержание. Пока бизнес не начнёт сам требовать качество, система будет держаться на мне и моей команде. А это не масштабируется.
CDO кивнул:
— Что нужно?
— Программа обучения. Не разовая. Постоянная. И мандат: DG — часть KPI бизнеса, а не только ИТ.
Глава 31. Три уровня обучения
Андрей разбил обучение на три уровня.
Уровень 1. Все сотрудники. Что такое данные, почему они важны, как каждый влияет на качество. Короткий курс — 2 часа. Обязательный для всех.
Уровень 2. Владельцы и стюарды. Как управлять данными в домене: правила, метрики, инциденты, RCA. Глубокий курс — 16 часов. С практикой на своём домене.
Уровень 3. Аналитики и ИТ. Как работать с каталогом, lineage, дата-контрактами, DQ-движком. Практический курс — 8 часов. С сертификацией.
Андрей объяснил команде:
— Нельзя научить всех всему. Но можно дать каждому то, что ему нужно. И сделать обучение обязательным, а не «по желанию».
Глава 32. Уровень 1. Все сотрудники
Андрей начал с простого. Двухчасовой курс для всех: от кассира до топ-менеджера.
Что внутри:
Что такое данные и почему они важны.
Как ошибка в данных превращается в штраф, потерю клиента или неверное решение.
Что каждый сотрудник может сделать, чтобы данные были лучше.
Куда идти, если видишь проблему.
Формат: короткие видео, примеры из жизни банка, тест на 10 вопросов.
Ключевой слайд: «Данные — это не ИТ. Это то, чем вы пользуетесь каждый день. Если вы вводите данные вручную — вы уже часть системы качества».
Андрей настоял: курс обязателен для всех. Без прохождения — нет доступа к системам. Это вызвало сопротивление, но CDO поддержал.
Глава 33. Уровень 2. Владельцы и стюарды
Это был главный уровень. 16 часов, разбитых на 8 недель по 2 часа.
Модуль 1. Роль владельца. За что отвечает, что подписывает, что делегирует.
Модуль 2. Границы домена. Как определить, что входит, что нет. Как не конфликтовать с соседними доменами.
Модуль 3. Критичные атрибуты. Как выбрать 20%, которые дают 80% риска.
Модуль 4. Правила качества. Как писать правила, которые понятны бизнесу и проверяемы технически.
Модуль 5. Метрики. Как читать дашборды, что такое SLA, MTTR, repeat rate.
Модуль 6. Инциденты. Как разбирать, как проводить RCA, как отслеживать corrective actions.
Модуль 7. Дата-контракты. Как договариваться с источниками и потребителями.
Модуль 8. Отчётность. Как готовить материалы для Data Committee.
Каждый модуль заканчивался практикой на своём домене. Владелец «Платежей» писал правила для своих атрибутов. Владелец «Карт» разбирал инцидент. Владелец «Скоринга» готовил доклад.
Андрей проверял каждую работу лично. Не чтобы оценить, а чтобы помочь.
Глава 34. Уровень 3. Аналитики и ИТ
8 часов практики. Без теории.
Что внутри:
Как найти данные в каталоге за минуту.
Как проверить lineage перед изменением.
Как работать с дата-контрактами в CI/CD.
Как настроить DQ-проверку.
Как завести инцидент в ServiceNow.
Как провести RCA.
Формат: воркшоп. Каждый участник решает реальную задачу на своём домене. В конце — сертификация: сделать задачу без подсказок.
Андрей говорил:
— Аналитик, который не умеет работать с каталогом, — это аналитик, который тратит время на поиск данных. Аналитик, который умеет, — это аналитик, который тратит время на анализ.
Глава 35. Культура. Что это
Андрей сформулировал для CDO:
— Культура данных — это когда:
Владелец сам приходит и говорит: «У меня проблема с качеством, помогите разобраться».
Аналитик сам идёт в каталог, а не спрашивает в чате.
Архитектор сам проверяет lineage перед изменением.
Бизнес сам требует метрики, а не ждёт отчёта.
Ошибка в данных — это не «проблема ИТ», а «моя проблема».
CDO спросил:
— Как этого добиться?
— Три вещи. Обучение. Пример. KPI.
Глава 36. Пример сверху
Андрей настоял: культура начинается с руководства.
CDO на каждом совете директоров говорил про данные. Не как про ИТ-тему, а как про риск и возможность. Показывал метрики. Требовал от владельцев отчёт.
CIO включил DG в архитектурные ревью. Без проверки lineage — релиз не проходит.
Финансовый директор добавил в бюджет строку на DG. Не как «затраты на ИТ», а как «снижение регуляторного риска».
Андрей говорил команде:
— Если руководство говорит одно, а делает другое, культура не появится. Нужен пример сверху. Без него — только форма.
Глава 37. KPI бизнеса
Самый сложный шаг. Андрей пошёл к CDO:
— Нужно, чтобы качество данных было в KPI бизнеса. Не только ИТ.
— Бизнес не согласится. Это не их зона.
— Это их зона. Они владельцы данных. Если данные плохие — это их ответственность.
CDO согласился. Через Data Committee провели решение: у каждого владельца домена — KPI по качеству данных. Не большой, 5–10% от общей оценки. Но достаточный, чтобы обращать внимание.
Что вошло в KPI:
Coverage критичных атрибутов.
SLA качества по домену.
Repeat rate инцидентов.
Своевременность corrective actions.
Андрей объяснил:
— KPI — не наказание. Это сигнал: данные — часть работы, а не что-то отдельное.
Глава 38. История одного владельца
Владелец домена «Маркетинг» сопротивлялся дольше всех. «У нас креатив, а не данные».
Андрей пришёл к нему с конкретикой:
— Ваш домен использует данные клиентов для кампаний. Если сегмент неверный — кампания уходит не тем. Если контакт устаревший — деньги на ветер. Это не про ИТ. Это про ваши деньги.
Владелец задумался. Через месяц он сам пришёл:
— У меня проблема. В сегменте клиентов 15% дублей. Кампании дублируются.
Андрей помог разобрать. RCA показал: данные о клиентах приходят из трёх источников, дедупликация не настроена. Corrective action: подключить MDM.
Через два месяца владелец «Маркетинга» выступал на Data Committee:
— Раньше я думал, что DG — это бюрократия. Теперь я вижу: это экономия денег и времени.
Андрей улыбнулся. Это была победа. Не метрика, а изменение мышления.
Глава 39. Год спустя
Через год после старта программы обучения Андрей стоял перед Data Committee.
Результаты:
Обучение прошли 94% сотрудников.
Владельцы и стюарды — 100%.
Аналитики и ИТ — 100% с сертификацией.
Каталог: 80% запросов — самостоятельные, без помощи команды DG.
Lineage: проверяется в 100% архитектурных ревью.
Дата-контракты: 100% критичных источников.
Инциденты: 70% заводят сами владельцы, а не команда DG.
Repeat rate: 2%.
Доля превентивных: 82%.
CDO спросил:
— Что дальше?
— Следующий уровень зрелости. DG не как проект, а как BAU. И — data literacy как часть онбординга. Чтобы каждый новый сотрудник с первого дня знал, что данные — это его ответственность.
— Сколько нужно?
— Ничего. Это уже работает.
Глава 40. Что понял Андрей
После программы обучения он записал для команды пять правил:
Первое. Обучение — не разовое. Курс для новичков, обновление для опытных. Постоянно.
Второе. Три уровня. Всем — базовое. Владельцам — глубокое. Аналитикам — практическое.
Третье. Пример сверху. Если руководство не живёт по правилам, культура не появится.
Четвёртое. KPI бизнеса. Качество данных — часть работы владельца, а не «проект ИТ».
Пятое. Культура — это когда само. Когда владелец сам приходит с проблемой. Когда аналитик сам идёт в каталог. Когда ошибка — это «моя», а не «их».
Часть V. Возвращение регулятора
Глава 41. Аудит. Возвращение
Через два года после первого аудита пришло письмо из ЦБ. Андрей открыл его без тревоги.
«Плановая проверка достоверности отчётности. Все 14 доменов. Срок — три недели. Формат — выездной».
CDO зашёл в кабинет:
— Помнишь первый раз? Тогда у нас было три домена и месяц на подготовку. Сейчас — четырнадцать и три недели. Волнуешься?
— Нет, — сказал Андрей. — В этот раз мы не готовимся. Мы просто показываем, как работаем.
CDO посмотрел на него:
— Ты уверен?
— Уверен. Если система работает — аудит это увидит. Если не работает — никакая подготовка не поможет.
Глава 42. Не готовиться
Андрей собрал команду и сказал неожиданное:
— Мы не будем готовиться к аудиту. Мы будем работать как обычно.
Команда удивилась:
— А если спросят то, к чему мы не готовы?
— Тогда ответим честно. Покажем, что есть. Если чего-то нет — скажем, что нет, и покажем план. Регулятор не ищет идеал. Он ищет управляемость.
Андрей объяснил:
— В первый раз мы собирали пакет три дня. Сейчас пакет собирается автоматически. Каталог, lineage, метрики, журнал инцидентов — всё живёт в системах. Нам не нужно ничего готовить. Нужно просто открыть.
Глава 43. Что изменилось
Андрей прошёл по чек-листу, который когда-то составил для первого аудита. Сравнил «тогда» и «сейчас».
Lineage. Тогда: 2 дыры, закрывали за сутки. Сейчас: 98% покрытие, обновляется автоматически. Дыры появляются — но их ловит система, а не человек.
Владельцы. Тогда: назначали, двое сопротивлялись. Сейчас: 14 из 14. Подписи, KPI, регулярная отчётность.
Правила и история. Тогда: 6 месяцев истории, собирали вручную. Сейчас: 2 года истории, дашборды в реальном времени.
Инциденты. Тогда: MTTR 6 часов, repeat rate 4%. Сейчас: MTTR 4 часа, repeat rate 2%, 82% превентивных.
Процесс. Тогда: описывали, как всё работает. Сейчас: работает без описания — потому что встроено в BAU.
Андрей закрыл чек-лист. Разница была не в цифрах. Разница была в том, что система работала сама.
Глава 44. День первый
Регулятор пришёл с тремя экспертами. Старший — тот же, что был два года назад.
— Андрей, здравствуйте. Помню вас. Тогда у вас было три домена.
— Теперь четырнадцать.
— Покажете?
Андрей открыл каталог. Не презентацию. Не подготовленные слайды. Живой каталог.
— Вот все домены. Вот владельцы. Вот критичные атрибуты. Вот правила. Вот история проверок. Вот lineage.
Эксперт ткнул в случайный домен — «Скоринг».
— Покажите, откуда берётся балл скоринга.
Андрей открыл lineage. Путь: скоринговая модель → API → DWH → витрина → отчёт. На каждом узле — владелец, правило, проверка.
— А если модель изменилась?
— Дата-контракт. Изменение без обновления контракта блокирует релиз. Вот журнал: три изменения за год, все через контракт.
Эксперт кивнул.
Глава 45. День второй
Второй день — инциденты.
— Покажите всё за последний год. Не только успехи.
Андрей открыл журнал. 47 инцидентов за год. Каждый — с RCA, corrective action, проверкой.
Эксперт спросил:
— Вот этот, в «Платежах». Сумма отрицательная. Что сделали?
— RCA показал: в источнике не было валидации на входе. Corrective action: добавили проверку в API. Repeat rate — ноль.
— Докажите.
Андрей показал график: после corrective action — ноль инцидентов по этому атрибуту за 9 месяцев.
Эксперт спросил:
— А этот, в «Картах»? Срок действия неверный.
— Владелец домена сам завёл инцидент. RCA показал: ручной ввод. Corrective action: автоматическая валидация. Плюс обучение для сотрудников.
— Кто завёл инцидент?
— Владелец домена. Не команда DG.
Эксперт поднял бровь:
— То есть бизнес сам?
— Да. Это часть их KPI.
Глава 46. День третий
Третий день — самый неприятный вопрос.
— У вас 14 доменов. Мы проверили три. Что с остальными?
Андрей не стал врать:
— Полное покрытие — 12 доменов. Два — в процессе: HR и «Продукты». По ним владельцы назначены, правила написаны, но coverage ниже 80%.
— Почему?
— HR позже всех вошёл в программу. «Продукты» — сложный домен, много источников. Roadmap: закрыть оба к концу квартала.
— Покажите roadmap.
Андрей открыл. Эксперт посмотрел, кивнул:
— Хорошо. Честно.
Глава 47. День четвёртый
Четвёртый день — неожиданный.
— Мы хотим поговорить с владельцами доменов. Не с вами. С ними.
Андрей не ожидал. Но не испугался:
— Конечно. Кого хотите?
— «Клиенты», «Платежи», «Маркетинг».
Андрей позвонил. Через час владельцы сидели в переговорной.
Эксперт спросил владельца «Клиентов»:
— Как вы понимаете, за что отвечаете?
— За данные о клиентах в своём домене. Полнота, уникальность, актуальность. Если что-то не так — я разбираюсь.
— А если не разберётесь?
— Эскалирую к CDO. Но сначала сам. Это моя зона.
Эксперт спросил владельца «Маркетинга»:
— Два года назад вы сопротивлялись. Что изменилось?
Владелец улыбнулся:
— Я понял, что данные — это деньги. Дубли в сегменте — потерянные кампании. Теперь я сам требую качество.
Эксперт записал что-то. Андрей сидел молча. Это была не его победа. Это была победа системы.
Глава 48. Заключение
Через неделю пришёл ответ. Не рекомендации. Заключение об отсутствии нарушений.
Три строчки:
Достоверность отчётности подтверждена.
Процессы управления данными соответствуют требованиям.
Рекомендовано тиражирование практик на другие направления.
CDO собрал совет:
— Мы прошли. Не как проверку. Как формальность.
Андрей добавил:
— Это не финал. Это подтверждение, что система работает. Но данные живут, меняются. Нам нужно продолжать.
— Что дальше?
— Следующий уровень зрелости. Data literacy в онбординге. DG как BAU. И — тиражирование на другие направления, как рекомендовал регулятор.
Совет утвердил.
Глава 49. Что понял Андрей
После второго аудита он записал для команды пять правил:
Первое. Лучшая подготовка к аудиту — работающая система. Не пакет документов, а живые процессы.
Второе. Честность важнее идеальности. Регулятор ценит не «всё идеально», а «мы знаем, где слабо, и вот план».
Третье. Бизнес должен говорить сам. Если на вопросы отвечает только Head of DG — система не работает.
Четвёртое. Аудит — это диалог. Не экзамен. Регулятор хочет убедиться, что данные управляемы. Дай ему это увидеть.
Пятое. Заключение — не финал. Это аванс на следующий год.
Часть VI. Система, которая работает без тебя
Глава 50. Три года
Прошло три года с того дня, когда Андрей получил письмо от CDO: «Команды нет, срок — вчера, удачи».
Он сидел в том же кабинете. За окном был тот же город. Но банк «Северный» был другим.
Что изменилось:
Домены. 14 из 14 — с владельцами, правилами, метриками. Плюс два новых: «Инвестиции» и «Страхование». Оба прошли конвейер за полгода.
Люди. Команда DG выросла с нуля до 18 человек. Методологи, аналитики, DQ-специалисты, владельцы инструментов. Плюс 14 владельцев доменов и 42 стюарда — по всему банку.
Процессы. DG встроен в change management, архитектурные ревью, разработку витрин и data-продуктов. Без проверки lineage — релиз не проходит. Без владельца — домен не существует.
Инструменты. Каталог, глоссарий, lineage, DQ-движок, дата-контракты, интеграция с ITSM. Всё работает. Не как проект, а как BAU.
Культура. 96% сотрудников прошли обучение. Data literacy — часть онбординга. Владельцы сами приходят с проблемами. Аналитики сами идут в каталог. Ошибка в данных — это «моя», а не «их».
Метрики:
Coverage критичных атрибутов: 96%.
SLA качества: 97%.
MTTR: 3 часа.
Repeat rate: 1,5%.
Доля превентивных: 85%.
Каталог: 90% запросов — самостоятельные.
Аудит. Два года подряд — заключение об отсутствии нарушений. Регулятор рекомендовал тиражировать практики на другие направления.
Глава 51. Усталость
Андрей сидел в кабинете и понимал: он устал.
Не от работы. От того, что всё держится на нём. Да, система работала. Но он был её сердцем. Владельцы шли к нему. CDO советовался с ним. Регулятор спрашивал его.
Он вспомнил правило, которое сам сформулировал: «Культура — это когда система работает без тебя».
Система работала. Но без него — не до конца.
Он пошёл к CDO:
— Мне нужен преемник. Не потому что я ухожу. Потому что я не должен быть незаменимым.
CDO посмотрел на него:
— Ты уверен?
— Уверен. Если я уйду завтра, система должна выжить. Иначе я построил не систему, а зависимость.
Глава 52. Преемник
Андрей выбрал Марину. Она пришла в команду два года назад — методолог, потом руководитель направления. Она знала домены, владельцев, инструменты. Она говорила с бизнесом на его языке. Она умела говорить «нет» и обосновывать.
Андрей начал передачу. Не за неделю. За полгода.
Что он передал:
Домены. Марина провела ревью по каждому. Познакомилась с владельцами. Проверила правила, метрики, инциденты.
Команду. Андрей познакомил её с каждым. Объяснил, кто за что отвечает, у кого какие сильные стороны.
Стейкхолдеров. CDO, CIO, финансовый директор, риски, регуляторика. Марина провела с каждым отдельную встречу.
Процессы. Change management, архитектурные ревью, Data Committee. Марина присутствовала на всех.
Инструменты. Каталог, lineage, DQ-движок, контракты. Марина прошла обучение у команды.
Культуру. Самое сложное. Андрей объяснил: «Культура — это не то, что я делаю. Это то, что делают другие, когда меня нет. Твоя задача — не заменить меня. Твоя задача — сделать так, чтобы меня не нужно было заменять».
Глава 53. Последний день
Последний день Андрея в «Северном» был обычным. Никаких проводов. Никаких речей. Он просто передал Марине доступы и сказал:
— Система работает. Люди знают, что делать. Если что-то сломается — разберутся. Если не разберутся — позвонят. Но я надеюсь, что не позвонят.
Марина улыбнулась:
— Не позвонят.
Андрей собрал вещи. Ноутбук, блокнот, ручка. На столе осталась карта данных — та самая, которую он нарисовал в первый месяц. 14 доменов, 47 источников, 120 витрин. Теперь — с пометками, обновлениями, новыми доменами.
Он оставил её на стене. Пусть висит. Как напоминание: всё начинается с карты.
На выходе он встретил CDO.
— Спасибо, — сказал CDO. — Ты построил то, чего у нас не было.
— Я не построил, — ответил Андрей. — Я помог построить. Строили все. Я просто не мешал.
CDO засмеялся:
— Скромно.
— Честно.
Глава 54. Что понял Андрей
Через месяц после ухода Андрей сидел в кафе и записывал. Не для команды. Для себя.
Пять уроков за три года:
Первое. Начинай с карты. Без понимания, где данные и куда текут, ничего не сдвинется.
Второе. Владелец — бизнес. Не ИТ. Пока бизнес не отвечает за данные, система держится на героизме.
Третье. Конвейер важнее героизма. Один процесс для каждого домена. Не быстрее, не медленнее.
Четвёртое. Метрики — не для отчёта. Они для того, чтобы видеть слабые места. Среднее скрывает проблемы.
Пятое. Культура — это когда без тебя. Если система работает только с тобой — ты построил зависимость, а не систему.
Глава 55. Звонок
Через полгода Андрею позвонила Марина.
— Привет. Не отвлекаю?
— Нет. Что случилось?
— Ничего. Просто хотела сказать: мы прошли аудит. Заключение — без нарушений. Третий год подряд.
— Поздравляю.
— И ещё. Регулятор рекомендовал тиражировать наши практики на другие банки. Через ассоциацию.
Андрей улыбнулся:
— Это уже не ко мне.
— Знаю. Но ты был первым.
— Я был не первым. Я был тем, кто не мешал.
Марина засмеялась:
— Ты повторяешься.
— Значит, урок усвоен.
Он положил трубку. Посмотрел в окно. Где-то там, в «Северном», система работала без него. Владельцы отвечали за данные. Аналитики шли в каталог. Ошибка была «моей», а не «их».
Он улыбнулся. Это была победа. Не его. Общая.
Глава 56. Что стало с банком
Через три года «Северный» был другим банком.
Данные. Не как ИТ-тема, а как актив. Владельцы, правила, метрики. Регулятор — без нарушений. Бизнес — с ответственностью.
Люди. Data literacy — часть онбординга. Каждый новый сотрудник знал: данные — это его ответственность. Не ИТ. Его.
Процессы. DG встроен в BAU. Не проект, не инициатива. Способ работать.
Культура. Владелец сам приходит с проблемой. Аналитик сам идёт в каталог. Архитектор сам проверяет lineage. Ошибка — это «моя», а не «их».
Репутация. Регулятор рекомендовал тиражировать практики. Другие банки приезжали учиться. Марина выступала на конференциях.
Андрей читал об этом в новостях. И думал: «Я был частью этого. Не центром. Частью».
Глава 57. Новый старт
Через год Андрей начал консультировать. Не как эксперт. Как тот, кто прошёл путь.
Он приезжал в другие банки и говорил:
— Я не буду рассказывать про DAMA и DMBOK. Я расскажу, что делать в понедельник.
Он показывал карту. Конвейер. Три опоры. Восемь шагов. Пять правил.
Он говорил:
— Начинайте с карты. Назначьте владельца. Не ИТ — бизнес. Напишите правила. Настройте проверки. Подключите каталог. Встройте в инциденты. Считайте метрики. Обучайте. И — не мешайте.
Кто-то спрашивал:
— А если не получится?
— Получится. Если не сдадитесь. Первый год — самый тяжёлый. Потом система начнёт работать сама.
— А если бизнес не захочет?
— Значит, вы плохо объяснили. Говорите про деньги и риски. Не про методологию.
— А если руководство не поддержит?
— Тогда не начинайте. Без мандата DG — это документация, а не управление.
Глава 58. Финал
Андрей сидел в кафе. За окном был вечер. Он дописывал последнюю главу.
Он вспомнил первый день. Письмо от CDO. Кофе. Список доменов. Тогда казалось — невозможно.
Теперь он знал: возможно. Если делать шаг за шагом. Если не сдаваться. Если помнить, что данные — это не про технологии. Это про людей.
Он закрыл ноутбук. Посмотрел в окно. Где-то там, в «Северном», Марина проводила Data Committee. Владельцы отчитывались. Аналитики шли в каталог. Система работала.
Он улыбнулся. И пошёл домой.
Конец
Загрузка…