Классическая картина для многих крупных российских компаний: рабочая группа из методологов, ИТ-архитекторов и приглашённых консультантов на несколько месяцев запирается в переговорных, чтобы создать «идеальный» регламент по управлению данными. На выходе появляется документ на 300–400 страниц: словарь из тысяч терминов, матрица ролей с десятками стюардов, пошаговые правила валидации и график заседаний совета по качеству данных на годы вперёд. Документ торжественно принимается, иногда даже переплетается в кожу. А спустя полгода дублирование номенклатуры может вырасти на 10–15 %, мастер-данные контрагентов по-прежнему содержат несколько версий одного юрлица, а отчёты продолжают врать. Data Governance умирает, не успев родиться.
Эта ситуация — не единичный инцидент, а системный диагноз. Российский бизнес, подталкиваемый регуляторами и желанием «навести порядок», массово влюбился в концепцию «золотого стандарта» данных — всеобъемлющей непротиворечивой модели, где каждое поле описано, каждый процесс стандартизован, а любые отклонения подсвечиваются дашбордами. Теоретически это привлекательно. Практически — губительно. Причина проста: управление данными не существует в вакууме документации, оно жизнеспособно только внутри конкретных сценариев использования.
Кабинетная утопия: как компании сами хоронят Governance
Корень проблемы — догматическое восприятие западных фреймворков (DAMA-DMBOK, DCAM, CMMI) без адаптации к реальной операционной среде. Бизнес начинает с попытки описать «вообще все данные», что приводит к трём фатальным ошибкам.
Паралич анализа. Проект увязает в инвентаризации. Когда перед командой стоит задача разметить критичность для 8000 атрибутов в 120 системах, неизбежно деление на «скорее важное» и «вроде важное». Реальная приоритизация отсутствует, потому что нет критерия — для какого бизнес-сценария эти данные критичны.
Оторванность от реальности. Глоссарий, рождённый в кабинете, внутренне логичен, но бесполезен для оператора, оформляющего отгрузку. Он называет контрагента «ООО Ромашка, ИНН такой-то», а не «стороной по договору типа 17Б». Governance-команда навязывает термины сверху, исполнители саботируют или игнорируют их, потому что не видят, какую боль эти правила снимают лично у них.
Бюджетное самоубийство. Когда через год спонсор видит только толстый регламент и нулевой эффект в отчётах, финансирование урезают. Governance объявляют «бюрократией», а стюарды возвращаются к своим Excel-файлам.
Ключевой провал — отсутствие связи с тем, ради чего данные существуют: с бизнес-результатом.
Сценарий как реаниматор: переворот пирамиды
Альтернатива не в отказе от методологии, а в перевороте пирамиды её внедрения. Вместо движения от модели данных к процессам следует идти от критических бизнес-сценариев к конкретным наборам данных, которые их питают. Сценарий использования — это ответ на вопрос «Какое решение на основе каких данных мы принимаем?»
Примеры таких сценариев:
-
Сценарный расчёт себестоимости при миграции. При переносе учёта из SAP в 1С:ERP критично не просто перенести проводки, а получить идентичную калькуляцию. Сценарий диктует, что не все атрибуты справочника материала важны, а только те, которые влияют на разложение затрат (статья калькуляции, нормативная цена, база распределения).
-
Консолидация клиентской базы для сквозной аналитики. Маркетингу нужен RFM-анализ по всей истории покупок после объединения CRM и биллинга. Критичный элемент — не адрес клиента, а уникальный сквозной идентификатор и правила его связывания (survivorship).
-
Автоматическая проверка благонадёжности контрагента. Перед подписанием договора система за 2 секунды должна подсветить риски. Критичны не все поля карточки, а ИНН, статус в ЕГРЮЛ, наличие в реестре дисквалифицированных лиц и цепочка владения. Именно эти поля и должны находиться под управлением.
Пять шагов к живому Data Governance
Методология внедрения на основе сценариев выстраивается последовательно.
Шаг 1. Карта сценариев, а не сущностей. Соберите владельцев процессов и задайте вопрос: «Какие пять отчётов, решений или операций приносят сегодня больше всего боли из-за плохих данных?» В ответ вы получите не абстрактный «справочник номенклатуры», а конкретную проблему: «Не могу свести дебиторку, потому что один и тот же клиент в трёх филиалах числится под разными названиями». Это и есть приоритетный сценарий.
Шаг 2. Выделение критических элементов данных. Под каждый из 3–5 отобранных сценариев выписываются поля, непосредственно участвующие в расчёте или логике. Всё, что не входит в эти поля, остаётся за периметром первой волны. Так объём работ сокращается с тысяч атрибутов до 50–80. С ними уже можно работать прицельно.
Шаг 3. Правила через бизнес-логику, а не через синтаксис. Вместо «поле должно быть строкой длиной 10 символов» правило формулируется как: «ИНН контрагента обязан проходить проверку контрольного числа ФНС до того, как запись будет использована в платёжном поручении». Такая формулировка понятна бизнесу, её легко защищать перед пользователями и можно напрямую привязать к предотвращаемому риску.
Шаг 4. Встраивание в процесс, а не в регламент. Правило должно быть автоматизировано в точке ввода данных. Если система не даёт сохранить карточку без валидного ИНН и сразу показывает предупреждение — это работает. Если она позволяет сохранить что угодно, а потом раз в месяц присылает отчёт о нарушениях — это не работает. Data Governance жив только в коде, интерфейсах и ETL-процессах.
Шаг 5. Измерение эффекта в деньгах сценария. Вместо абстрактного «процента заполненности» демонстрируются конкретные улучшения: «Сценарий закрытия периода ускорился на 2 дня» или «Количество возвратов из-за неверных реквизитов сократилось на 70 %». Именно такие цифры окупают инвестиции и дают мандат на расширение периметра.
Практический пример: от дубликатов материалов к чистому справочнику
Рассмотрим ситуацию на производстве электротехники. После миграции на новую ERP-систему справочник товарно-материальных ценностей содержал около 450 000 позиций, из которых примерно 30 % были полными или частичными дубликатами. Кабинетный подход предложил бы создание централизованной группы НСИ, которая за два года вычистит весь архив.
Вместо этого инициативная группа выбрала сценарий «Расчёт потребности в материалах для производства». Данный сценарий использует лишь три ключевых атрибута: класс материала, единицу измерения и плановый срок поставки. Остальные 40 атрибутов были временно исключены из периметра.
Полноценная чистка всего справочника не проводилась. Вместо неё было создано «чистое ядро» из 3000 наиболее критичных для производства материалов. Для них внедрили правила нормализации наименований (единый шаблон «Тип — Размер — Стандарт»), закрепили стюарда из конструкторского отдела и разработали шлюз в ERP, который не позволяет создать новый материал без одобрения стюарда, если он подпадает под шаблон. Старые дубликаты в архиве пометили флагом «Не использовать» с автоматической заменой на эталонную запись из чистого ядра во всех новых заказах.
Результат: за четыре месяца ошибки в расчёте потребности сократились на 40 %, а цех перестал получать заявки на закупку одного и того же болта у трёх разных поставщиков из-за разного написания в системе. Сценарий окупил вложенные в Governance усилия, после чего стюарды начали постепенно подключать к чистому ядру новые классы материалов.
Темпоральность как естественное продолжение живого Governance
Здесь возникает прямая связь с темой второй части цикла — медленно меняющимися измерениями (SCD). «Золотой стандарт» потому и мифический, что предполагает статичность: одна истинная версия, зафиксированная навсегда. Однако бизнес непрерывно течёт: у контрагента меняется юридический адрес, у материала — ставка НДС, у сотрудника — должность. Если Data Governance не управляет медленно меняющимися измерениями, он вновь превращается в архивную пыль.
Правильный подход — встроить SCD-стратегию прямо в сценарии. Допустим, для расчёта бонусов менеджеров по продажам необходимо знать, к какому филиалу был приписан клиент на момент сделки. Это диктует SCD Type 2 для связи «Клиент-Подразделение». Для сценария исправления опечатки в названии компании достаточно SCD Type 1. Выбор типа SCD — не техническое решение архитектора, а осознанный ответ владельца сценария на вопрос: «Имеет ли история этого изменения значение для моего решения?» Так Governance перестаёт быть сводом мёртвых правил и становится организмом, чувствительным ко времени.
Выход из трёх ловушек
Весь цикл статей посвящён тому, что данные должны служить конкретным бизнес-решениям, а не наоборот. «Синдром чистой миграции» лечится предварительным анализом и очисткой до переноса. «Иллюзия темпоральности» — обязательным внедрением SCD как части аналитической модели. А «Мифический золотой стандарт» — заменой кабинетного описания на сценарное управление, привязанное к измеримому результату.
Российский бизнес сегодня находится в уникальной точке вынужденного пересоздания ИТ-ландшафта. Это даёт шанс не просто заменить западные системы на отечественные, но и фундаментально пересмотреть отношение к информации. Данные — не побочный продукт цифровизации, а единственный стратегический актив, который не изнашивается со временем. Вопрос лишь в том, научатся ли компании управлять им не ради галочки в KPI, а ради точных, быстрых и безошибочных решений. Битва за информацию ещё не проиграна — она лишь переходит в фазу, где побеждают не героические усилия ИТ-департаментов, а прагматичный, сценарно-ориентированный Data Governance, понятный каждому сотруднику. Начните с вопроса «Какое решение мы не можем принять прямо сейчас из-за мусора в данных?» — и Governance оживёт раньше, чем будет дописан первый регламент.
P.S. Практические шаблоны и чек-листы для бизнес- и системных аналитиков я публикую в своем Telegram-канале: https://t.me/vas_yukoff
ссылка на оригинал статьи https://habr.com/ru/articles/1055014/