Принципы руководства данными

Концепция и решаемые задачи

Концепция руководства данными (Data Governance – DG) описывает методы решения высокоуровневых стратегических задач бизнеса по работе с данными. Это процесс создания стратегии по управлению доступностью, целостностью и безопасностью данных компании на основе внутренних стандартов и правил.

Концепция Data Governance включает в себя:

  • Методики оценки данных как основных активов компании;

  • Способы организации процессов управления данными;

  • Способы создания политик/регламентов управления данными;

  • Разделение ролей специалистов в процессе руководстве данными;

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

Data Governance связана с идеями управления основными данными (Master Data Management – MDM). MDM описывает методы построения систем управления ключевыми данными, и включает в себя методы сбора и хранения данных из других систем, обеспечения качества данных и выдачи проверенных данных.

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

Решения класса DG и MDM могут работать параллельно и дополнять друг друга:

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

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

Решения класса DG предназначены для формирования подхода к практике руководства данными, позволяющей:

  • Оценить уровень зрелости управления данными и впоследствии поднять уровень;

  • Выделить ключевые цели и задачи управления данными;

  • Определить измеримые показатели качества данных;

  • Построить процессы управления данными;

  • Анализировать потоки данных и строить отчеты.

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

Онтология может создаваться разными способами. Один из самых распространенных способов с точки зрения бизнеса, это разделение данных по людям, то есть не простое классифицирование, а распределение данных по ролям и иерархиям. Например, у каждой должности – Chief Data Officer, Data Owner, Data Steward – есть своя область данных, за которую он отвечает.

Система Юниверс DG включает в себя основные решения по руководству данными и предоставляет инструменты для создания разрезов данных и моделирования информационной структуры онтологии данных, что позволяет удобно работать с определенными типами наборов данных (информационные системы, бизнес-термины, правила качества и т.д.).

Возможные виды работ с данными:

  • Создание, добавление, удаление данных и структуры данных;

  • Регламентация данных;

  • Связывание данных из разных наборов;

  • Поиск данных, их потоков и источников данных;

  • Анализ структуры данных, потоков данных и самих данных.

Сценарии работы системы класса DG

Таблица 1 – Варианты сценариев использования Юниверс DG

Сценарий

Цель

Роль

Создание бизнес-терминологии

Полное описание данных

Бизнес-пользователи:

  • Владелец информационной системы,

  • Владелец данных

Поиск данных в IT-ландшафте

Поиск данных

IT-ландшафт:

  • Аналитик,

  • Архитектор системы,

  • Специалист по качеству данных,

  • Инженер данных

Сбор разрозненной информации в одном месте

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

IT-ландшафт:

  • Аналитик,

  • Специалист по качеству данных,

  • Инженер данных

Создание структуры данных

Создание модели данных

Информационная система:

  • Владелец информационной системы,

  • Владелец данных,

  • Аналитик,

  • Архитектор системы

Анализ происхождения данных

Получение карты происхождения данных

Информационная система со сложными запросами к данным:

  • Аналитик,

  • Архитектор системы

Анализ качества данных

Обеспечение качества данных

Хранилище данных:

  • Аналитик,

  • Архитектор системы,

  • Специалист по качеству данных

Типовой сценарий 1. Контроль защиты конфиденциальных данных

Описание:

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

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

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

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

Выявление незащищенных конфиденциальных данных

Рисунок 1 – Выявление незащищенных конфиденциальных данных

На схеме выше представлен пример выявления незащищенных конфиденциальных данных. Бизнес-правила определяют, что объект "физическое лицо" с атрибутами ФИО, Адрес, Клиент – конфиденциальные данные. Разные системы запрашивают либо адрес, либо ФИО по отдельности, однако в подразделении логистики атрибуты физического лица собираются снова. При этом, в логах БД конфиденциальные данные оказываются незащищенными, что является угрозой.

Типовой сценарий 2. Работа с отчетами

Проблемы с отчетностью могут возникать по различным причинам. Вот некоторые из них:

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

  • Изменившиеся требования регуляторов.

  • Поглощение бизнеса и связанные с поглощением различия в понимании бизнес-терминов и ключевых показателей.

  • Проблемы агрегации различных единиц измерения.

  • Необходимость в единых и достоверных источниках данных и едином понимании всех бизнес-терминов для создания новых отчетов.

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

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

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

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

Регулирование отчетности годовой прибыли

Рисунок 2 – Регулирование отчетности годовой прибыли

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