Внедрение современных инструментов Data Governance (управления данными) часто воспринимается как финальная точка в построении культуры работы с данными. Компании инвестируют в Data Quality-проверки (качества данных), создают каталоги данных и выстраивают красивые дашборды, которые сигнализируют о полном порядке. Однако на практике бизнес часто обнаруживает, что за фасадом «зеленых галочек» скрывается хаос: отчеты не сходятся, ключевые метрики вызывают вопросы, а доверие к аналитике падает. Этот разрыв между формальным качеством данных и их реальной ценностью для бизнеса приводит к финансовым потерям и неверным управленческим решениям. 

Меня зовут Сергей Петриченко. Я продуктовый менеджер VK Data Platform. В этой статье я покажу типовой путь компании и расскажу, как сделать работу с данными не самоцелью для ИТ, а инструментом, который полезен для бизнеса.

Типовой сценарий работы с данными 

Зачастую компании выстраивают работу с данными по схожему принципу: многие проходят через одинаковые этапы, сталкиваются с типовыми проблемами и наступают на одни и те же грабли. Это позволяет выделить типовой пайплайн развития событий. В качестве основы для статьи мы возьмем именно такой усредненный сценарий. Это поможет наглядно продемонстрировать, почему стандартные подходы часто заводят в тупик и где именно происходит подмена понятий между технической задачей и бизнес-целью.

Первые сложности и запрос от бизнеса

Зачастую путь развития процессов работы с данными начинается с выявления очевидных проблем. Например, когда при попытке узнать, что происходит с данными в продукте, или при сдаче регуляторной отчетности цифры не сходятся.

Обнаружив подобные расхождения, бизнес-подразделение (например, в лице продакт-менеджера) формулирует гипотезу о «плохих» данных и обращается в ИТ с запросом на их актуализацию и повышение качества.

ИТ, в свою очередь, начинает внедрение проверок качества данных, фокусируясь на технических метриках: точность, объем и актуальность. В результате через несколько спринтов ИТ сообщает бизнес-командам, что задача решена: проверки внедрены, витрины промаркированы, а дашборды показывают зеленые галочки, сигнализируя о стопроцентном качестве данных.

Проблемы после внедрения Data Quality

Спустя какое-то время при попытке использовать эти «качественные» данные начинают вскрываться системные ошибки. Например, отчет по клиентам без адресов показывает подозрительно малое их количество. При детальном разбирательстве выясняется, что проверка была настроена примитивно: система лишь верифицировала наличие любого значения в поле «Адрес» (not null). Если в поле попадало некорректное значение, например «Город», «643» или бессвязный набор символов, данные формально считались валидными. То есть проверки формально были, но они никак не решают задачи бизнеса. 

В этот момент появляется запрос на добавление бизнес-проверок.

Бизнес-проверки и их слепые зоны

Следующим логичным шагом становится расширение правил проверки. К техническим метрикам добавляются бизнес-правила, которые позволяют выявлять логические аномалии в данных. Например, система начинает проверять, что дата открытия договора меньше текущей даты, а срок действия паспорта актуален на сегодняшний день и действительно принадлежит конкретному клиенту.

Однако даже после внедрения бизнес-проверок попытки построить сводный отчет могут заканчиваться неудачей. Проблема кроется в фундаментальном свойстве данных — контекстуальности.

Выясняется, что определения одного и того же объекта, например «клиента», кардинально различаются в зависимости от бизнес-юнита и продукта. Например:

• для одного подразделения клиент — это авторизованный пользователь с договором и полным профилем;

• для другого (например, для медиасервиса) — даже анонимный посетитель, о котором известен только его Cookie. 

У таких разных сущностей различается атрибутивный состав, для них требуются разные проверки качества и подходы к работе.

Это делает создание единых, централизованных правил проверки практически невозможным. Более того, базовые метрики, которые кажутся универсальными, также начинают считаться по-разному. Например, показатель DAU (Daily Active Users) для одного продукта — это уникальное целевое действие в приложении, а для другого — просто факт открытия приложения или нажатия на элемент интерфейса. В результате построить кросс-бизнес-юнитовую отчетность становится невозможно.

Таким образом, как бы ни улучшалось техническое качество данных, на выходе это не дает должного результата. Без единого бизнес-контекста любые проверки остаются локальными и неполными. Устранить такое расхождение возможно только при унификации понятий и контекста. То есть возникает потребность в едином бизнес-глоссарии.

Появление бизнес-глоссария

Бизнес-глоссарий — единый реестр терминов, который фиксирует внутрикорпоративные определения так, чтобы все команды оперировали идентичными понятиями. Каждому термину дается однозначное, согласованное со всеми подразделениями определение и привязка к конкретной отчетности.

Основная цель создания бизнес-глоссария — понять и зафиксировать, как именно рассчитывается каждая метрика, чтобы убедиться в корректности конечных цифр. Например, в рамках внедрения глоссария может выясниться, что в компании существует 40 различных определений понятия «клиент», которые противоречат друг другу. Задача глоссария — устранить этот хаос.

Однако, даже когда работа над глоссарием будет завершена, а все определения зафиксированы, нельзя гарантировать, что все данные качественные. Нюанс в том, что важно понимать, откуда берутся сами данные, насколько они актуальны, как сформированы витрины и так далее.

Таким образом, все предыдущие оптимизации и процессы не могут дать результат без инвентаризации всех информационных активов компании.

Инвентаризация и дата-каталог

Инвентаризация информационных активов — это сложная и масштабная организационная задача. Она подразумевает не просто технический сбор сведений, а выявление и описание всех источников данных, витрин и отчетов, которыми оперирует компания, с целью понять их назначение, владельцев и степень актуальности.

Для систематизации этой работы и создается дата-каталог. Это инструмент, который становится единым реестром и точкой доступа к знаниям о данных. Он позволяет связать бизнес-термины из глоссария с реальными источниками, отследить происхождение данных (Lineage) и объединить эту информацию с результатами проверок качества.

Параллельно с созданием каталога в компании часто появляется роль CDO (Chief Data Officer, директор по обработке данных), который назначается ответственным за данные. Часто это происходит по принципу «крайнего»: например, владельца DWH (Data Warehouse, хранилище данных) назначают CDO. Причем для него и его команды устанавливаются конкретные KPI по наполнению каталога (например, «описать более 80% активов»). 

Дальнейшие проблемы

Даже после появления дата-каталога, его наполнения, выделения роли CDO и создания актуальных витрин с «зелеными флажками» бизнес нередко обнаруживает, что качество и точность принимаемых решений не улучшаются. Желаемого результата от данных нет, и вся проделанная на предыдущих этапах работа остается незаметной с точки зрения бизнес-эффективности: проверки качества бегают, дашборды выглядят идеально, но данные как вызывали вопросы, так и вызывают. Возникает разрыв: у ИТ все работает, а у бизнеса проблемы остаются.

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

Причем отсутствие методологии может скрывать под собой целый комплекс системных проблем.

• Проектный подход вместо постоянного процесса. Вместо создания непрерывного процесса управления данными компания запускает проект с четким началом и концом. К моменту его завершения часть данных уже устаревает, проверки требуют актуализации, и без поддерживающих процессов система быстро теряет ценность.

• Высокий порог входа и низкое вовлечение. Инструменты внедряются формально, а конечным пользователям не объясняют их ценность. В результате аналитики воспринимают новый каталог или глоссарий не как помощника, а как дополнительную бюрократическую нагрузку — и игнорируют его.

• Неопределенные цели и метрики успеха. Вместо бизнес-показателей (например, сокращение времени на подготовку отчета) используются технические: процент описанных таблиц или количество внедренных проверок. Это позволяет отчитаться об успехе проекта, но не приносит реальной пользы бизнесу.

• Фокус на инструментах, а не на бизнес-инициативе. Вся работа превращается в очередную ИТ-задачу по поддержке инфраструктуры. Команды фокусируются на отказоустойчивости и обновлениях, упуская из виду главную цель — превращение данных в бизнес-актив.

Таким образом, инструменты остаются лишь средством автоматизации хаоса, а не инструментом для наведения порядка. Без методологии, которая определяет процессы, роли и цели, любая технологическая инициатива обречена на провал.

Что сделать для достижения бизнес-целей

Чтобы данные стали приносить реальную бизнес-ценность, важно глубоко менять паттерны и подходы к работе с ними на всех уровнях компании. Как правило, это предполагает ряд системных мер.

• Привязка к бизнес-стратегии и поддержка руководства. Инициатива по управлению данными должна быть стратегической и поддерживаться сверху. Причем это долгосрочный проект с горизонтом планирования в среднем около двух лет, и требовать от него мгновенного результата — ошибка.

• Четкое распределение ролей и ответственности. Недостаточно просто назначить ответственных. Им необходимо объяснить их роль, полномочия и обязанности. Человек должен понимать, что он делает и зачем, а не просто «отбывать» задачу по описанию витрин.

• Встраивание процессов в повседневную работу. Работа с данными (поиск, потребление, актуализация) должна стать естественной частью бизнес-процессов, а не отдельной, разовой процедурой.

• Единый глоссарий и каталог как связка. Эти инструменты должны работать вместе: глоссарий дает единые определения, а каталог связывает их с реальными источниками и витринами, обеспечивая контекст.

• Мониторинг и улучшение. Внедренные процессы необходимо постоянно отслеживать и улучшать, используя корректные KPI, которые напрямую связаны с изначальными бизнес-целями (например, сокращение времени на подготовку отчета).

• Обучение и культура. Необходимо системно обучать сотрудников работе с данными и инструментами. Важно донести ценность этой работы до каждого — от разработчика до топ-менеджера — и сформировать культуру, в которой каждый понимает свою ответственность за данные, которые он потребляет и генерирует.

Если успешно реализовать упомянутые меры и сделать их соблюдение системным, выстроив связку «технологии + методология», можно получить связную экосистему управления данными, которая обеспечивает:

• Интеграцию инструментов. Все сервисы (каталог, DQ, BI) работают как единый механизм, обмениваясь данными и метаданными без ручной обработки.

• Единую версию правды. Бизнес оперирует согласованными данными и метриками, что исключает споры между подразделениями о том, «чьи цифры верны».

• Прозрачность сквозь всю цепочку. Отчет позволяет проследить путь данных от источника до финального значения, понимая все преобразования (End-to-end Lineage).

• Устойчивое качество и быстроту реакции. Данные остаются актуальными, а новые запросы бизнеса обрабатываются за дни, а не месяцы благодаря отлаженным процессам.

• Соответствие требованиям и снижение рисков. Упрощается прохождение аудитов и соблюдение корпоративных требований за счет понятного владения данными и контроля их качества.

Фактически только в таком случае данные начнут действительно работать на бизнес: помогать оптимизировать процессы и получать дополнительную прибыль.

Что в итоге

Данные — один из ключевых активов современной компании, но это не значит, что они сами по себе способны приносить пользу или прибыль. Даже идеально структурированные, подготовленные и очищенные данные в сочетании с готовой инфраструктурой для хранения и аналитики не будут работать, если специалисты на местах не будут их использовать, не будут понимать, почему это важно и как это делать.

Поэтому, чтобы данные приносили реальную пользу, бизнес должен работать и выдвигать инициативы совместно с ИТ, а инструменты Data Governance должны применяться исключительно в связке с методологией, ролевыми моделями и процессами. Только такая синергия превращает пассивный информационный актив в реальный инструмент для достижения бизнес-целей.

Например, именно этого подхода мы стараемся придерживаться при разработке продуктов VK Tech — чтобы они не просто решали задачи ИТ-команды, а объединяли технологии и методологию, позволяя строить единую систему и работать на достижение бизнес-целей.

Один из примеров подобной реализации — наш фреймворк, который объединяет процессы создания витрины, ее описания и настройки актуализации. То есть аналитик может создать витрину, описать ее и задать частоту обновления, после чего данные автоматически попадают в каталог. В результате вместо трех разрозненных процессов мы создаем один сквозной, по итогам которого получаем работающую витрину, которая становится активом компании.