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

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

Концепция руководства данными (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 содержит как данные о годовой выручке, так и об издержках. Так как два отчета расходятся в базовом понимании бизнес-термина «Отчет о годовой прибыли», то необходимо регулирование этого понятия, что повлечет за собой корректировку одного из отчетов.