Управление данными: что это такое и как контролировать качество данных

В одной компании данные о клиенте могут одновременно жить в CRM¹, учетной системе, витрине аналитиков и нескольких рабочих файлах. Пока источников немного, расхождения находят вручную. Но со временем одни и те же показатели начинают считаться по разным правилам, записи дублируются, а ответ на простой вопрос «откуда взялась эта цифра?» требует отдельного расследования.

Поначалу это скорее раздражает, чем выглядит как системная проблема. Аналитик просит уточнить источник, финансист вручную сверяет две выгрузки, сотруднику второй раз выдают доступ к тому же набору. Но когда систем становится больше, такие эпизоды начинают съедать время постоянно. При этом исправная база данных не отвечает на главный вопрос: какой версии показателя доверять и кто должен принять решение, если версии разошлись.

Data Governance² нужен как раз для этой части работы. Он закрепляет владельцев данных, общие определения, порядок доступа и правила проверки качества. Ниже разберем, чем такое управление отличается от администрирования баз данных, какие процессы приходится выстраивать постоянно, как распределяют ответственность и почему порядок в исходной информации особенно важен для проектов с искусственным интеллектом.

Что такое Data Governance простыми словами

Data Governance (англ. data governance — «управление данными») — это порядок работы с данными, который компания устанавливает для себя: кто отвечает за конкретный набор, как его описывают, кому дают доступ, как проверяют качество и что происходит с информацией дальше. Иными словами, речь не о месте хранения, а о правилах обращения с самой информацией.

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

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

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

Управление данными и управление базами данных: в чем разница

Управление базами данных решает технические задачи: чтобы СУБД работала быстро и стабильно, данные резервировались, права применялись, а после сбоя систему можно было восстановить. Управление данными смотрит на другой уровень. Здесь важны смысл поля, единые определения, ответственность за изменения и критерии, по которым набор считается пригодным для работы.

Возьмем простую карточку клиента. Администратор базы отвечает за то, чтобы таблица была доступна и запросы выполнялись без ошибок. Но кто решает, какой из двух телефонных номеров актуален? Как объединять дубли? Какой идентификатор считать основным? Это уже не технические, а бизнесовые вопросы. Если оставить их только ИТ, спор просто переместится из отчета в очередь технической команды.

Какие задачи бизнеса закрывает управление данными

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

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

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

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

Принципы управления данными

У Data Governance нет одного «секретного» принципа, который сам наведет порядок. Нужна вполне практичная дисциплина: у важных данных есть владелец, договоренности записаны, доступ выдается по понятным основаниям, а качество проверяют до того, как ошибка попадет в отчет. Не менее важно понимать происхождение показателя: из какой системы он пришел и что происходило с ним по дороге.

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

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

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

Из каких процессов состоит управление данными

С управлением данными нет точки, после которой можно сказать: «все настроили и больше не трогаем». Источники меняются, в карточках появляются новые поля, справочники объединяются, отчеты переезжают на другие витрины. Иногда маленькая правка в одной системе всплывает сразу в нескольких отчетах или моделях. Поэтому правила приходится поддерживать вместе с самими данными, а не один раз написать и положить в папку.

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

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

Кто отвечает за данные в компании: роли и зоны ответственности

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

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

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

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

Как измеряют качество данных: по каким критериям проверяют

Фразу «данные должны быть качественными» легко написать в политике, но из нее непонятно, что именно проверять. Для одного набора критично отсутствие пропусков, для другого — свежесть, для третьего — совпадение с эталонным справочником. Поэтому качество всегда раскладывают на конкретные свойства.

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

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

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

Почему без управления данными не работают проекты на основе искусственного интеллекта

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

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

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

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

Чем поддерживают управление данными: каталоги, описания и контроль качества

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

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

Автоматические проверки тоже закрывают только часть работы. Найти пустое обязательное поле, дубль или значение вне допустимого диапазона относительно просто. Гораздо сложнее договориться, какой уровень ошибки приемлем и кто должен реагировать. Это уже бизнес-решение: система может показать нарушение, но не определит цену ошибки за компанию.

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

Как внедрить управление данными в компании

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

1. Выбрать одну проблемную область данных вместо попытки охватить всю компанию сразу.
2. Составить список наборов в этой области, определить их источники, основные преобразования и тех, кто ими пользуется.
3. Назначить владельцев и договориться, где проходит граница ответственности бизнеса, ИТ и специалистов по данным.
4. Зафиксировать правила обработки, хранения и выдачи доступа, включая порядок действий в спорных ситуациях.
5. Определить критерии качества и допустимые пороги для критичных полей и показателей.
6. Настроить регулярные проверки и договориться, кто получает сигнал об отклонении, и кто разбирает причину.
7. После пилота распространить рабочую схему на соседние области, используя уже проверенные роли и шаблоны.

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

Зато после пилота становится проще понять, что действительно покупать и автоматизировать. Если проблема в поиске описаний — нужен каталог. Если основная боль в дублях клиентов — приоритетнее мастер-данные. Если поля регулярно приходят пустыми — полезнее сначала поставить проверки. Инструмент выбирается под найденный разрыв, а не под красивую архитектурную схему.

Как ИИ-сервисы Сбер2В ИИ работают с данными компании

У готовых ИИ-сервисов нет единого требования к входным данным: все зависит от задачи. Для прогноза важна сопоставимая история, для анализа звонков — записи и контекст, для оценки процесса — корректные показатели. Чем лучше компания понимает источники и правила расчета, тем меньше времени перед запуском уходит на вопросы вроде «откуда взялась эта цифра» и «почему значения расходятся».

В прогнозировании спроса особенно чувствительна история по периодам. В материалах Сбер2В ИИ для таких задач используются данные о продажах, остатках, ассортименте и промоактивностях. Если код товара менялся, акции учитывались по-разному, а часть периодов собрана по старым правилам, модель получит несопоставимую историю. Поэтому до запуска обычно приходится привести справочники и периоды к общему виду.

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

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

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

Вопросы и ответы

Чем управление данными отличается от MDM?

Data Governance задает общие правила работы с данными: роли, ответственность, доступ и требования к качеству. MD³сосредоточен уже на конкретном классе информации — мастер-данных о клиентах, товарах, поставщиках и других ключевых сущностях. Поэтому MDM может входить в общую систему управления данными, но не заменяет ее.

Что такое DAMA-DMBOK и обязательно ли следовать этой методологии?

DAMA-DMBOK⁴ — не инструкция, которую нужно внедрять пункт за пунктом. Скорее это справочник по областям управления данными: качеству, архитектуре, метаданным, Data Governance и другим темам. Компания может брать из него нужные практики и адаптировать их под свой масштаб и реальные проблемы, а не копировать всю модель целиком.

Нужно ли среднему бизнесу управление данными или это история только для корпораций?

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

Как управление данными связано с требованиями к защите персональных данных?

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

Сколько времени занимает внедрение управления данными?

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

Что делать, если подразделения не хотят открывать доступ к своим данным?

Управление данными не требует раздать доступ всем желающим. Скорее наоборот: компания должна понимать, кому и зачем он нужен. Владелец определяет допустимые сценарии и ограничения. Если подразделения не могут договориться, вопрос стоит поднимать на уровень общего процесса, а не оставлять его администратору базы, который не отвечает за бизнес-интересы сторон.

Главное об управлении данными

• Управление данными начинается с ответственности: должно быть понятно, кто принимает решение по данным и по каким правилам. Программа или каталог появляются уже после этого.
• Администрирование базы отвечает за техническую надежность хранения. Управление данными — за смысл, качество, доступ и использование информации в бизнесе.
• Минимум, который дает практический эффект: владелец набора, понятное описание, правила доступа и несколько проверок для действительно важных полей.
• Качество имеет смысл измерять только относительно задачи. Для критичных данных заранее задают порог и понятную реакцию на отклонение.
• Вместо программы на всю компанию проще взять одну проблемную область, привести ее в порядок и только после этого масштабировать рабочие правила.
• Для проектов с ИИ этот порядок особенно ценен: при повторном обучении или новом анализе не приходится заново выяснять, откуда появились данные и как именно они были подготовлены.

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