Классификация и иерархизация данных

Организация нуждается в максимальной систематизации и упорядочении основных данных (например, основных активов, поставщиков, клиентов). Для этого требуется разделять их на группы и выделять значимые атрибуты для каждой группы. Необходимо связать данные организации с различными внешними классификаторами – государственными стандартами, отраслевыми классификаторами и т. д., а во многих случаях также иерархизировать данные. В качестве примера можно привести ситуацию, когда новый заказчик организации оказывается в том же организационном сегменте большой корпорации, что и предыдущий; в таком случае нет необходимости получать новое разрешение у службы безопасности, что экономит время и ресурсы. Деятельность по классификации и иерархизации данных производится над неструктурированными данными и может быть связана с обогащением данных.

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

 

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

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

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

 

* Кузнецов С. В., Кознов Д. В. Управление мастер-данными в рамках итеративного подхода // Онтология проектирования, 2021. Т. 11, 2 (40): 170–184. – DOI: 10.18287/2223–9537–2021–11–2–170–184.

 

Пакетный режим

Эта компонента отвечает за загрузку и обновление основных данных у потребителей в соответствии с некоторым расписанием. Многие потребители ориентированы на получение пакетных выгрузок данных в промежуточные базы («витрины данных»), c которыми они работают в своем режиме. При этом каждая витрина использует свой фрагмент модели данных. Целесообразно реализовать отдельный механизм управления такими витринами для отслеживания своевременного обновления (получения ими актуальных данных), а также для журналирования запросов на получение данных разными потребителями. Таким образом отслеживается, какие именно данные используются теми или иными потребителями и в каком режиме; какие конфликты данных возникают в связи с теми или иными источниками и как это соотносится с потреблением данных.

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

 

Подписочный режим

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

Данная компонента – программно-аналитическая.

 

Режим реального времени

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

Данная компонента – программно-аналитическая.

 

Примеры MDM-проектов

 

Использование предложенной модели можно проиллюстрировать на примере MDM-проектов, выполненных при непосредственном участии авторов (см. табл. 13.1).

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

КМТР. Проект направлен на создание системы для управления данными о материально-технических ресурсах крупной организации в энергетическом секторе. Система предназначалась для решения следующих задач: обеспечить качественными данными бизнес-процессы технического обслуживания, ремонта и управления запасами; консолидировать различную информацию за счет создания технологии стандартизации и унификации данных. В рамках проекта рассматривались данные о сырье и материалах, оборудовании, запасных частях и комплектующих изделиях, необходимых для обеспечения деятельности организации. К особенностям проекта можно отнести автоматизацию сложных регламентов организации по работе с информацией, затрагивающих более десяти различных подразделений, реализацию классификатора материальных ресурсов (классификация и иерархизация данных), построение логической модели данных.

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

 

 

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

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

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

ПДК. Проект разрабатывался для многопрофильной международной организации из сектора энергетики и тяжелой промышленности. Организация имеет сотни тысяч клиентов в разных странах мира, поэтому процедура формирования данных о новом клиенте оказывается трудоемкой. До создания MDM-решения она занимала 21 день, после – всего 8. MDM-решение позволило автоматизировать различные проверки, поиск конечных бенефициаров юридических лиц в корпоративных иерархиях, а также реализовать централизованный ввод информации. В рамках данного проекта основной акцент был сделан на инвентаризации данных, создании логической модели, позволившей решить задачу поиска дубликатов юридических лиц и поиска аффилированных лиц, а также реализации доступа к основным данным в режиме реального времени с целью ускорить целевой бизнес-процесс.

Для указанных проектов в таблице 13.2 показано, какие функциональные компоненты были реализованы в соответствующих MDM-проектах. При этом использовалась шкала:

● High – компонента является одной из основных в проекте, она бизнес-критична или технологически сложна;

● Med – компонента важна для проекта, но не является приоритетной или трудоемкой;

● Low – компонента реализована в облегченном варианте: она либо уже существует к началу проекта и требует лишь доработки, либо полная реализация компоненты вынесена в отдельный проект;

● N/A – данная компонента в рамках этого проекта не востребована.