Книга: Ценность ваших данных
Назад: Глава 12. Обеспечение доступности и обслуживание данных: основы
Дальше: Глава 14. Обеспечение доступности и обслуживание данных: развитие
Глава 13. Управление основными данными: практика внедрения
В предыдущей главе нами была рассмотрена функциональная область «Справочные и основные данные». В этой главе, с учетом фундаментальной роли указанной области в построении цепочек ценности и поставок данных, мы более подробно остановимся на такой важной теме, как внедрение управления основными данными.
Обсуждая референтную модель управления цепями поставок (SCOR-модель), мы, в частности, говорили от том, что в ней есть специальный раздел, описывающий лучшие практики. Практика – это уникальный способ настройки процесса или совокупности процессов. Уникальность может быть связана с автоматизацией процесса, используемыми в процессе специальными навыками или технологией, уникальной последовательностью выполнения операций процесса или уникальным способом распределения процессов между организациями и их взаимодействия. Важность учета передовых практик подчеркивается и в «Сегодняшней повестке дня для совета директоров» (см. главу 7).
На сегодняшний день внедрение MDM не является типовой, проработанной задачей, поскольку организации, особенно крупные, имеют большое количество особенностей. В этой связи представляется крайне полезным изучение действующих в этой области практик.
В данной главе предлагается функциональная модель MDM, которая должна помочь в первичной оценке и согласовании работ в так называемых итеративных MDM-проектах на самых ранних стадиях. Внимание сосредоточено на создании ИТ-инфраструктуры по поддержке MDM, ее наладке и выполнении необходимых аналитических работ (очистка и консолидация данных, классификация и иерархизация и т. д.). В дальнейшем эти аналитические работы должны выполняться в организации на постоянной основе с помощью внедренной ИТ-инфраструктуры, и задачей-максимум является полная автоматизация этих работ. Ориентируясь на программно-аналитические аспекты MDM, мы здесь намеренно не касаемся вопросов изменения бизнес-процессов и практик работы с данными в организации, обучения персонала и пр.
В качестве иллюстрации описываемого подхода в главе представлено несколько реальных индустриальных MDM-проектов, выполненных с использованием предложенной модели.
В завершающем разделе приведен пример архитектуры информационных систем крупной компании. Архитектура ориентирована на специфику телекоммуникационной отрасли и основана на комплексном MDM-решении, которое, в частности, может быть построено с применением предлагаемой в главе модели.
13.1. Две стратегии внедрения MDM
Известны две принципиально разные стратегии внедрения MDM: «сверху вниз» и итеративная стратегия.
Стратегия «сверху вниз» подразумевает следующую последовательность действий:
● создание стратегической MDM-концепции для организации;
● формирование требований к MDM-решению;
● внедрение и доработка существующего на рынке MDM-инструментария;
● выполнение необходимых организационно-административных работ;
● эксплуатация и сопровождение MDM-решения.
Как правило, стратегия «сверху вниз» осуществляется посредством серии проектов, которые выполняются различными внешними компаниями.
Итеративная стратегия подразумевает внедрение MDM для решения конкретной задачи с дальнейшим наращиванием MDM-функционала и (или) реализацией MDM для других сегментов данных организации, т. е. для решения других задач. При этом внедрение MDM за пределами одного конкретного MDM-проекта зависит от многих условий, в том числе от оправдания ожиданий организации от данного проекта, от наличия других задач, свободных средств, заинтересованных людей и т. д. Именно такая цепочка MDM-проектов и дает название всей стратегии – итеративная стратегия внедрения MDM.
Первую стратегию можно сопоставить с технологией push: внедрение инновации происходит на основе некоторой передовой технологии, которая должна решить различные, в том числе и не известные на данный момент проблемы организации. Вторую стратегию можно сопоставить с технологией pull: драйвер внедрения инноваций – сама организация, точнее, определенные ее задачи. Не отвергая первой стратегии, авторы ориентируются на вторую, как менее рисковую и позволяющую достичь конкретных практических результатов в обозримые сроки.
При реализации MDM-проекта в рамках итеративной стратегии возникает задача перевода требований заказчика на язык MDM, получивший значительное развитие. Если задача, имеющаяся у организации-заказчика, хорошо переводится в термины MDM, то для ее решения можно использовать имеющийся на рынке MDM-инструментарий, что существенно сокращает затраты на такой проект. При этом на практике оказывается, что заказчик, как правило, не владеет MDM-терминологией и часто под видом MDM-проектов пытается представить проекты иного класса или заказать реализацию MDM-решения с нуля. Ошибки здесь приводят к коллизиям, растянутым срокам и денежным потерям.
13.2. Ключевые процессы MDM и архитектура MDM-решения
Управление основными данными ориентировано на сбор и накопление данных из различных информационных систем – источников данных, консолидацию данных и их распределение (доставку) информационным системам – потребителям данных.
Можно выделить следующие ключевые процессы MDM в организации:
● управление моделью данных;
● сбор и накопление данных;
● проверка, стандартизация и обогащение данных;
● разрешение конфликтов данных (разрешение сущностей);
● использование данных.
Практика MDM в организации должна быть поддержана специальным ИТ-решением, созданным и внедренным в организацию. Важнейшая составляющая MDM-решения – центральный репозиторий данных (хаб). В него собираются данные, являющиеся кандидатами в основные данные, они надлежащим образом обрабатываются и доставляются потребителям. Определены четыре варианта архитектуры хаба данных.
1. Индексная архитектура: на хабе хранятся только соответствующие ссылки (индексы) данных; это актуально для данных, которые нельзя копировать или перемещать.
2. Консолидирующая архитектура: данные регулярно загружаются в хаб, обрабатываются, и при этом обеспечивается доступ потребителей к этим данными.
3. Централизованная архитектура во всем подобна предыдущей, но в этом случае дополнительно хаб выполняет задачу разового ввода данных, и далее все изменения данных делаются непосредственно на хабе (информационные системы попадают в разряд потребителей).
4. Смешанная архитектура реализует сочетание консолидирующей и централизованной архитектур для различных основных данных организации. Если какие-то фрагменты данных организации запрещено перемещать, то для них может использоваться индексная архитектура.
Существует большое количество готового программного инструментария по созданию MDM-решений. Прежде всего, это такие продукты как SAP MDG, Informatica MDM, IBM InfoSphere MDM, которые ориентированы на решение стандартных задач MDM. Однако разнообразие практических задач столь велико, что некоторые производители (например, «Юнидата» и пр.) предлагают программные «конструкторы», которые позволяют получить MDM-решения для конкретных потребностей организаций.
13.3. MDM-проекты
На практике проекты в области MDM часто принимают за обычные ИТ-проекты. И требуется определить, что задачи организации имеют ярко выраженную MDM-специфику, что позволяет применить готовый MDM-инструментарий, а также привлечь компании-интеграторы, специализирующиеся на таких проектах.
Запрос организации имеет MDM-специфику, когда заказчику необходим сбор, обогащение и консолидация данных из различных источников, а также выдача этих данных различным потребителям, использующим их далее для обеспечения бизнес-деятельности. Источники могут находиться как в самой организации, так и вне ее. Например, требуется обогатить данные о клиентах организации информацией, собранной в соцсетях. Требование наличия нескольких потребителей для созданных основных данных менее жесткое и иногда не выполняется. Как правило, в организации существует критический бизнес-процесс, для эффективного исполнения которого требуются качественные обогащенные и консолидированные данные из различных источников. Например, речь может идти о процедуре проверки новых клиентов или спорных транзакций в банке.
С другой стороны, организации может быть и не нужен MDM-проект. Во-первых, когда речь идет об обработке однородных данных – например, сформированных посредством ввода одним или несколькими операторами. Такие проекты могут потребовать: создания логической модели данных, валидацию и очистку данных, обеспечение доступа к данным в различных режимах и т. д. Но при этом отсутствует главная задача MDM – консолидация данных из разных источников. Если для такой задачи операторный ввод данных заменить автоматизированным поступлением тех же данных из разных источников, то она приобретает MDM-специфику. Во-вторых, «вне юрисдикции» MDM-проектов лежат запросы на реализацию сложного бизнес-функционала. Такой функционал должен быть вынесен из MDM-решения в отдельные информационные системы, а MDM-проект заканчивается доставкой основных данных потребителям.
Следует отметить, что MDM-специфика должна быть основной в проекте. Если этой специфики нет или она лишь частично присутствует, но является не главной, то данный ИТ-проект не является MDM-проектом.
13.4. Состав MDM-решения
В результате реализации MDM-проекта у организации-заказчика появляется MDM-решение, которое включает в себя: MDM-систему (программную часть решения); новые регламенты по работе с данными; обученных сотрудников организации, которые умеют использовать MDM-систему в соответствии с новыми регламентами; налаженный и запущенный процесс управления основными данными. Последний пункт важен, поскольку все может иметься в наличии, но деятельность по MDM в организации отсутствует. Например, из-за нерешенных вопросов безопасности или противоречий внутренних регламентов, или в силу большой загруженности сотрудников, которые должны участвовать в MDM. Таким образом, MDM-решение – это осуществляющаяся в организации деятельность, налаженная и обеспеченная всем необходимым.
MDM-система представляет собой развернутое в организации готовое программное обеспечение, которое реализует основные функции MDM – хаб данных, консолидацию и пр. Главная часть этого ПО – базовый MDM-продукт, а также дополнительный набор ПО для решения частных вопросов. Наличие многофункционального готового ПО, которое следует лишь настроить и развернуть у организации-заказчика, существенно снижает стоимость и риски MDM-проекта. Однако некоторую часть MDM-системы приходится дорабатывать в рамках проектных мероприятий, чтобы отразить особенности организации, которые не удается покрыть стандартным инструментарием.
13.5. Описание модели
После первой оценки потребностей заказчика необходимо провести их детальный анализ в терминах MDM. Для этого предлагается специальная функциональная модель. Она описывает типовое MDM-решение, включая в себя максимальный объем функциональности, с тем чтобы можно было выбрать необходимые компоненты, которые нужно реализовать в данной ситуации.
Для удобства использования модель представлена с помощью метафоры полного жизненного цикла основных данных и состоит из трех этапов: сбор, обработка и доставка данных. Эти фазы содержат функциональные компоненты, каждый из которых описывает блок работ по управлению основными данными. Таким образом, функциональные компоненты модели включают в себя работы по наладке MDM и работы, выполняемые в рамках дальнейшего функционирования MDM-решения.
Например, при реализации одной из главных компонент модели «Консолидация данных» нужно:
● выполнить работы по наладке: наладить ПО, поддерживающее соответствующее рабочее место аналитика, определить правила для разрешения конфликтов и выполнить первый раз консолидацию данных из источников данных организации;
● осуществлять консолидацию данных в рамках дальнейшего функционирования MDM, поскольку далее данные из источников будут продолжать поступать на хаб данных.
Предлагаемая модель ориентируется на внедрение в организации новой ИТ-системы на основе готовых инструментов, которые могут быть настроены и доработаны под особенности задач заказчика. Поэтому каждая компонента модели имеет программную и аналитическую части. Часть функционала компоненты выполняет соответствующее ПО, а часть – человек (аналитик). Работы по наладке компоненты целесообразно разделить на наладку/реализацию некоторого ПО и выполнение аналитических функций. Например, создание логической модели МД – аналитическая функция, а очистка данных – программно-аналитическая. В последнем случае речь идет о создании и программной реализации специальных правил очистки, которые применимы именно для этих данных, именно для этой организации, и применении этих правил, включая анализ результатов, возможно создание новых правил. При этом используется готовое ПО, но отдельные специальные правила, ориентированные на специфику данных организации, могут быть реализованы в виде дополнительного ПО, созданного в рамках MDM-проекта.
Основные пакеты модели
● Сбор данных. В этот пакет включены компоненты, отвечающие за идентификацию данных-кандидатов в основные данные, так называемых сырых данных, а также за их дальнейший анализ и предварительную обработку. Сюда же входит доступ к различным источникам данных.
● Обработка данных. В этот пакет включается функционал по созданию и хранению основных данных в хабе данных, включая создание и поддержку логической модели данных, а также выполнение классификации, иерархизации. В хаб поступают предварительно обработанные сырые данные, полученные из источников данных. Здесь они обрабатываются, становясь основными данными.
● Доставка данных. В этот пакет включены функциональные компоненты, отвечающие за доставку основных данных системам потребителям. Источники и потребители данных могут совпадать полностью или частично. При этом оказывается важным решение вопросов разделения прав доступа к данным, а также реализация различных режимов доставки данных потребителям. Выделяют следующие режимы доставки: пакетный, режим реального времени и подписочный режим.
Предложенная модель ориентирована на сценарий не только одноразовой загрузки данных, но и на их повторяющееся обновление в хабе с учетом поступления новых «сырых» данных из источников.
Пакеты и функциональные компоненты модели представлены на рисунке 13.1.
* Кузнецов С. В., Кознов Д. В. Управление мастер-данными в рамках итеративного подхода // Онтология проектирования, 2021. Т. 11, 2 (40): 170–184. – DOI: 10.18287/2223–9537–2021–11–2–170–184.
13.5.1. Инвентаризация данных
В рамках этого пакета производится идентификация источников данных, а также определяется, какие именно данные из этих источников нужно преобразовывать в основные данные. Необходимо определить точный состав основных данных. Чем больше разнообразие данных, тем сложнее (и, следовательно, дороже) будет MDM-проект. При этом собирают лишь те атрибуты, которые будут востребованы потребителями данных. Важно провести типизацию данных, выяснить реальную заполняемость каждого существенного атрибута и его типовые значения. В этом пакете также определяется уровень доверия к различным источникам данных. Возможна ситуация, что некоторый источник имеет очень низкую степень доверия, в частности, он может хранить данные, которые давно не обновлялись. Обращаться к нему следует лишь в крайнем случае. Эта функциональная часть – преимущественно аналитическая.
13.5.2. Организация доступа к источникам данных
Поскольку сырые данные, которые должны использоваться для создания основных данных, находятся в различных источниках данных организации-заказчика, то для создания MDM-решения необходимо организовать программный доступ к этим данным. В большинстве случаев загрузка данных является многоразовой процедурой и должна выполняться регулярно во время функционирования MDM-решения. Для автоматизации этой процедуры необходимо решить технические задачи, так как источники данных часто реализованы на разных платформах и могут не иметь программных интерфейсов доступа. Эта функциональная часть – преимущественно программная. Объем работ здесь во многом зависит от того, насколько обмен данными налажен в организации (например, уже могут быть внедрены технологии передачи данных между различными информационными системами организации).
13.5.3. Очистка данных
Под очисткой данных понимается устранение ошибок в данных и нормализация данных из различных источников перед их загрузкой в хаб. Это необходимо, поскольку в противном случае будет непросто искать в данных дубликаты, а также выполнять их консолидацию. Очистка данных – трудоемкий процесс. Первичная очистка, включая нормализацию и приведение значения всех атрибутов к единому формату, не является затратной, однако она значительно упрощает дальнейшие шаги по консолидации данных и восстановлению связей между сущностями.
Эта компонента – программно-аналитическая. На практике часто требуется программная доработка таких инструментов для корректной работы с различными форматами данных организации, либо реализация специальной логики по очистке информации. Например, источник данных может хранить несколько значений в одном атрибуте, и тогда требуется разделить эти значения по соответствующим полям. Для этого нужно разработать специальное ПО, которое выполнит это разделение.
13.5.4. Обогащение данных
Может оказаться, что для пользователей основных данных требуется дополнить имеющиеся в источнике данные, например, информацией из открытых источников.
Данная компонента – программно-аналитическая, поскольку требует анализа и разметки соответствующих данных из источника, а также реализации программного доступа к публичным источникам для обогащения данных.
13.5.5. Логическая модель
Эта компонента предназначена для создания и сопровождения логической модели основных данных. Такая модель должна отражать структуру консолидированных данных со всеми атрибутами, собранными из различных источников организации. Модель необходима для дальнейшей обработки основных данных, а также их доставки потребителям. Один из важнейших шагов при создании логической модели – восстановление/обнаружение различных связей в данных, которые отсутствовали в источнике, но появляются при консолидации.
Деятельность по созданию логической модели является аналитической. Она должна быть поддержана соответствующим ПО, включающим средства визуализации, перечисления атрибутов и связей между сущностями, а также программной связи созданной модели данных с соответствующим отражением ее элементов в источниках и (или) потребителях данных. При этом некоторые аспекты этого инструментария требуется дорабатывать под конкретный проект: например, в качестве источника и потребителя может выступать уже функционирующая информационная система, в которой модель данных жестко задана (типичный случай – ERP-система), и тогда доставка новых значений для существующих атрибутов будет требовать специальной программной реализации.
13.5.6. Консолидация данных
Эта функциональная компонента отвечает за загрузку данных из разных источников на хаб и выполнение консолидации реальных данных в соответствии с созданной логической моделью.
Процесс загрузки производится автоматически, с использованием соответствующих инструментов. При его выполнении возникают конфликты, которые разрешаются следующими способами.
● «Вручную» – эксперт предметной области разрешает конфликт; этот способ применяется для критических данных (например, юридических), где ошибки недопустимы и поэтому автоматические алгоритмы разрешения конфликтов неприемлемы.
● Семантический (онтологический) подход, который применяется для данных, которые хранятся в виде онтологий. Если фрагмент данных из источника попадает с другими фрагментами в одну онтологию, то эти фрагменты являются консолидированными.
● Методы искусственного интеллекта, в частности методы машинного обучения, которые обучаются на типичных ситуациях, чтобы разрешать возникающие в процессе консолидации конфликты автоматически.
● Смешанные стратегии – например, с помощью алгоритмов искусственного интеллекта экспертам представляется на одобрение предварительные варианты разрешения конфликтов. Такой подход может снизить трудоемкость процедуры разрешения конфликтов без снижения качества.
Загрузка данных из источника может осуществляться одноразово, например, в случае централизованной архитектуры хаба данных или при наличии источников, которые прекратили свою работу, но содержат ценные данные. Иначе помимо первичной загрузки требуется организовать регулярное обновление основных данных.
Данная компонента – программно-аналитическая. Программной частью является доработка ПО деятельности аналитика по консолидации данных для работы со специфическими данными, а также для реализации уникальных правил консолидации и правил разрешения конфликтов. Если используются алгоритмы искусственного интеллекта, то они должны быть адаптированы под конкретную задачу. Например, это могут быть обновляемые или самонастраиваемые правила для разбора конфликтов данных при консолидации.
13.5.7. Классификация и иерархизация данных
Организация нуждается в максимальной систематизации и упорядочении основных данных (например, основных активов, поставщиков, клиентов). Для этого требуется разделять их на группы и выделять значимые атрибуты для каждой группы. Необходимо связать данные организации с различными внешними классификаторами – государственными стандартами, отраслевыми классификаторами и т. д., а во многих случаях также иерархизировать данные. В качестве примера можно привести ситуацию, когда новый заказчик организации оказывается в том же организационном сегменте большой корпорации, что и предыдущий; в таком случае нет необходимости получать новое разрешение у службы безопасности, что экономит время и ресурсы. Деятельность по классификации и иерархизации данных производится над неструктурированными данными и может быть связана с обогащением данных.
Данная компонента – аналитическая в части создания правил иерархизации и классификации. Она должна быть поддержана соответствующим ПО, которое позволяет осуществлять отладку этих правил на малом количестве данных и далее применять их к полному объему данных. Для подсказок аналитику и создания полуавтоматической классификации данных все больше используют различные методы искусственного интеллекта, в частности методы машинного обучения.
13.5.8. Права доступа к данным
Потребители данных могут находиться в различных бизнес-контурах организации и иметь разные права доступа к данным. В рамках этой компоненты требуется определить стратегию прав доступа к основным данным и выполнить ее реализацию. Здесь необходимо полагаться на существующие в организации роли и связанные с ними права, взаимодействуя со службой безопасности организации.
Данная компонента включает работы, которые не являются трудоемкими и оказываются преимущественно аналитическими: политика разграничения прав доступа к основным данным реализуется средствами администрирования информационной системы. Однако создание соответствующей спецификации (какие данные и кому должны быть доступны) – ответственная работа, требующая глубокого знания данных и бизнес-процессов, а также структуры организации.
* Кузнецов С. В., Кознов Д. В. Управление мастер-данными в рамках итеративного подхода // Онтология проектирования, 2021. Т. 11, 2 (40): 170–184. – DOI: 10.18287/2223–9537–2021–11–2–170–184.
13.5.9. Пакетный режим
Эта компонента отвечает за загрузку и обновление основных данных у потребителей в соответствии с некоторым расписанием. Многие потребители ориентированы на получение пакетных выгрузок данных в промежуточные базы («витрины данных»), c которыми они работают в своем режиме. При этом каждая витрина использует свой фрагмент модели данных. Целесообразно реализовать отдельный механизм управления такими витринами для отслеживания своевременного обновления (получения ими актуальных данных), а также для журналирования запросов на получение данных разными потребителями. Таким образом отслеживается, какие именно данные используются теми или иными потребителями и в каком режиме; какие конфликты данных возникают в связи с теми или иными источниками и как это соотносится с потреблением данных.
Данная компонента имеет программную часть по наладке/реализации интерфейса MDM-системы с соответствующими потребителями. Аналитическая часть заключается в определении тех потребителей и тех частей основных данных, которые нуждаются именно в такой стратегии.
13.5.10. Подписочный режим
В рамках этого режима каждый потребитель подписывается на определенный фрагмент основных данных (часть логической модели или множество сущностей и их атрибутов). Далее формируется одна или несколько очередей, куда выгружаются наиболее актуальные данные после их очередного обновления. После этого все потребители считывают свои обновления из той или иной очереди согласно своей подписке. Сложность реализации подписочной модели состоит в том, что необходимо либо повторно использовать существующий механизм очередей, которым уже пользуются потребители, либо доработать соответствующие информационные системы для использования очередей MDM-решения.
Данная компонента – программно-аналитическая.
13.5.11. Режим реального времени
Данная компонента включает функционал по доставке основных данных потребителям в режиме реального времени, т. е. непосредственно после изменения данных. Такой режим часто трудно реализовать из-за конфликтов на стороне потребителя, поскольку соответствующая информационная система может временно блокировать доступ к фрагменту данных из-за выполнения некоторой операции, и это приведет к задержкам с обновлением записи в рамках MDM. Например, на сайтах телекоммуникационных компаний часто есть функция проверки возможности подключения той или иной услуги по адресу. Потенциальный клиент заходит на сайт компании, вводит свой адрес (возможно, с ошибками) и выбирает интересующую его услугу, например широкополосный доступ в интернет. Промедление с ответом сайта критично, т. к. клиент может уйти к конкуренту. Поэтому такая проверка адреса становится задачей поиска данного адреса (очистка от опечаток) и указанной услуги в режиме реального времени.
Данная компонента – программно-аналитическая.
13.6. Примеры MDM-проектов
Использование предложенной модели можно проиллюстрировать на примере MDM-проектов, выполненных при непосредственном участии авторов (см. табл. 13.1).
В приведенном далее описании выполненных проектов курсивом выделены компоненты функциональной модели, которые были в фокусе разработчиков.
КМТР. Проект направлен на создание системы для управления данными о материально-технических ресурсах крупной организации в энергетическом секторе. Система предназначалась для решения следующих задач: обеспечить качественными данными бизнес-процессы технического обслуживания, ремонта и управления запасами; консолидировать различную информацию за счет создания технологии стандартизации и унификации данных. В рамках проекта рассматривались данные о сырье и материалах, оборудовании, запасных частях и комплектующих изделиях, необходимых для обеспечения деятельности организации. К особенностям проекта можно отнести автоматизацию сложных регламентов организации по работе с информацией, затрагивающих более десяти различных подразделений, реализацию классификатора материальных ресурсов (классификация и иерархизация данных), построение логической модели данных.
ПК. Проект выполнялся для крупной телекоммуникационной организации и был нацелен на консолидацию информации по следующим направлениям: по продуктовым предложениям (услугам) для различных сегментов заказчиков; по проверке технических возможностей подключения услуг; по объединению финансовой информации из систем биллинга и бухгалтерской отчетности. Основной акцент был сделан на инвентаризации данных о продуктах компании из различных источников, а также на создании единой логической модели основных данных с последующей консолидацией. Построено итоговое дерево продуктов компании с различными характеристиками, включая финансовые, для дальнейшего анализа отделом продаж и финансистами (классификация и иерархизация данных).
КТУ. Основной задачей проекта была консолидация товаров и услуг, закупаемых крупной транспортной организацией. Было необходимо объединить информацию из различных классификаторов товаров и составить перечень услуг подрядчиков. Внутренним заказчиками этого MDM-решения стала служба закупки организации. В ходе проекта были идентифицированы по своему атрибутивному составу товары и услуги, имеющие различные цены. В результате были созданы монетарные метрики, т. е. подсчитана итоговая экономия организации по закупкам ввиду того, что требуемые товары и услуги стали закупаться по гарантированным минимальным доступным ценам автоматически. Фокус проекта был на консолидации данных о закупаемых товарах, разграничении прав и обеспечении доступа к данным в рамках подписочного режима.
СКБ. Проект разрабатывался для организации, занимающейся продажей модных товаров, и предназначался для сегментирования клиентской базы и поддержки продаж в премиальном сегменте. Целью проекта было выявление клиентов из клиентской базы организации, которые активны в социальных сетях и имеют много подписчиков. Организация хотела заручиться их лояльностью с помощью дополнительных скидок и других мотивационных акций с целью получить больше потенциальных покупателей – подписчиков этих клиентов. В рамках проекта был сделан акцент на обогащение и консолидацию данных.
ЛКГ. Данный проект разрабатывался для городской государственной службы управления с целью создания умного личного кабинета горожанина. Требовалось выполнить интеграцию личного кабинета с многочисленными информационными системами федерального и регионального уровня с целью извлечения профильной информации о горожанине, например, сведений о его транспортных средствах, недвижимости или банковских счетах. Важными особенностями проекта была информационная безопасность и разделение прав доступа к данным, а также получение основных данных в режиме реального времени и в рамках подписочной модели.
ПДК. Проект разрабатывался для многопрофильной международной организации из сектора энергетики и тяжелой промышленности. Организация имеет сотни тысяч клиентов в разных странах мира, поэтому процедура формирования данных о новом клиенте оказывается трудоемкой. До создания MDM-решения она занимала 21 день, после – всего 8. MDM-решение позволило автоматизировать различные проверки, поиск конечных бенефициаров юридических лиц в корпоративных иерархиях, а также реализовать централизованный ввод информации. В рамках данного проекта основной акцент был сделан на инвентаризации данных, создании логической модели, позволившей решить задачу поиска дубликатов юридических лиц и поиска аффилированных лиц, а также реализации доступа к основным данным в режиме реального времени с целью ускорить целевой бизнес-процесс.
Для указанных проектов в таблице 13.2 показано, какие функциональные компоненты были реализованы в соответствующих MDM-проектах. При этом использовалась шкала:
● High – компонента является одной из основных в проекте, она бизнес-критична или технологически сложна;
● Med – компонента важна для проекта, но не является приоритетной или трудоемкой;
● Low – компонента реализована в облегченном варианте: она либо уже существует к началу проекта и требует лишь доработки, либо полная реализация компоненты вынесена в отдельный проект;
● N/A – данная компонента в рамках этого проекта не востребована.
13.7. Сопоставление существующих и описанного подходов
В главе 8 мы уже говорили о том, что за последние годы создано значительное количество референтных моделей и методологий управления данными в организациях,,.
Ряд методологий сфокусирован на ПО в сфере MDM. Подход, описанный выше, отличается от этих методологий тем, что не зависит от конкретного базового MDM-продукта.
В работе О’Kейна и Морана предложена модель для построения системы MDM в организации, которая включает семь блоков: концепцию, стратегию, метрики, информационное управление, оргвопросы и роли, ЖЦ информации, а также инфраструктуру. Эта модель предназначается для ранних стадий внедрения MDM, однако она ориентирована на стратегию «сверху вниз», покрывая всю деятельность организации по внедрению MDM. Функциональная модель, предложенная в данной главе, предназначается для использования при реализации итеративной стратегии, ориентированной на удовлетворение конкретных потребностей организации, которые выражаются в терминах MDM.
В свою очередь, в труде Мартина Офнера и его коллег предлагается модель для анализа жизненного цикла основных данных в организации с целью определить недостающие виды деятельности. Основными компонентами модели являются: портфолио данных; проектирование данных и системы; управление данными; поддержка данных. Эта модель слабо связана с программной частью MDM-решения, а также не рассматривает уникальные задачи организации по внедрению MDM.
В качестве дальнейшего развития предлагаемого подхода планируется детальная разработка методик оценки функционала MDM-проектов на ранних стадиях, а также создание детальных метрик сложности MDM-решений.
Кроме того, предполагается выполнить перевод (отображение) функциональности типового MDM-решения на различные MDM-продукты, а также осуществить более тесную интеграцию подхода с областью управления знаниями,.
13.8. Пример архитектуры информационных систем, основанной на комплексном MDM-решении
Одной из самых требовательных к инструментарию работы с данными групп заказчиков являются телекоммуникационные компании, которым необходимо на постоянной основе обеспечивать своих абонентов целым перечнем телекоммуникационных и ИТ-услуг и связывать огромный поток данных в рамках единого стройного механизма взаимодействия инфраструктуры и программных продуктов.
Даже обобщенная высокоуровневая схема поражает воображение грандиозностью и сложностью как самих систем, так и их взаимодействия друг с другом. Еще более сложен процесс общения этих систем на уровне данных, объем которых даже оценить непросто. В отдельных архитектурных сегментах создаются, накапливаются и обновляются столь разнородные и специализированные сведения, что зачастую только специалисты в каждой конкретной системе смогут ответить, с какими данными и по каким алгоритмам эти системы живут.
Попробуем разобраться, как же все-таки устроена жизнь данных в компаниях, принадлежащих к одной из самых сложных и высокотехнологичных отраслей постиндустриальной экономики, являющейся пионером в предоставлении клиентам сервисной модели.
Принципиальное значение имеет прежде всего выделение информационных источников, от управления которыми зависит весь процесс управления данными, как основными, так и транзакционными. Необходимо отметить, что, учитывая объем обрабатываемых сведений и важность привязки транзакционных данных к основным, для обеспечения большинства процессов телекоммуникационных компаний целесообразно рассматривать внедрение единого платформенного решения по управлению данными в масштабах всей организации, поскольку данные из различных систем (в первую очередь основные данные) сильно переплетены и зависимы друг от друга. Обеспечив работу с данными в одном месте (в среде единого инструментария) возможно обеспечить эффективное управление ими и, следовательно, большинством бизнес-процессов различных подразделений.
Рассмотрим домен (предметную область) «Клиентский каталог» (рис. 13.2). Соответствующая ему подсистема, функционирующая на базе единой платформы, обеспечивает управление данными клиентов, поддерживая их корректность, интероперабельность, чистоту, полноту, формат и другие требования к данным для работы с ними в информационных системах. Подсистема интегрирована с информационными системами, в которых имеются данные о клиентах в различных «разрезах» и представлениях, что позволяет платформе управления данными собрать все эти данные, провести их обработку, обогатить основную запись дополнительными сведениями (адрес, модели устройств, тип предоставляемых услуг и т. д.) и «опубликовать» – сохранить «золотую запись» в платформе и обеспечить ее распространение в информационные системы-получатели (они же могут быть и источниками, в таком случае данные будут актуализированы).
Остановимся коротко еще на нескольких подсистемах на базе платформы управления данными, отвечающих за основные домены телекоммуникационной компании.
Подсистема «Продуктовый каталог» реализует функциональность работы с основными данными, на основе которых предоставляются услуги, обеспечиваются расчеты с абонентами, а также предоставляется возможность оперативного изменения тарифных планов (рис. 13.3).
Подсистема «Каталог объектов сетевой и ИТ-инфраструктуры» обеспечивает сбор и работу с данными, позволяющими управлять всеми техническими объектами, посредством которых предоставляются телекоммуникационные сервисы. Чаще всего это сложное технологическое оборудование, состоящее из различных технологических подсистем. Подсистемы, работающие с данными этого домена, обеспечивают полное описание оборудования в сети и на складах оператора, поддержку данного оборудования, описание всех неисправностей и ремонтов, произведенных силами оператора или подрядчиков, информацию о сроках и наименовании гарантийной поддержки и многое другое (рис. 13.4).
«Адресный каталог» – подсистема, поддерживающая качество данных об адресах абонентов, дилеров, нахождения оборудования, складов, а также детальное описание оборудование и предоставляемых услуг по каждому конкретному адресу (рис. 13.5).
«Каталог контрагентов и номенклатуры закупок» – отдельная интерпретация решения «Единого каталога товаров, работ и услуг» с гораздо более широким функционалом, позволяющим не только обеспечивать данными подсистемы закупок, но и работать с данными из информационных систем поддержки оборудования (учитывающих множество параметров устройств, как работающих «на сети», так и находящихся на складе). Каталог также формирует «единое пространство данных» для производственных систем и систем экономического учета и бюджетирования (рис. 13.6).
Отдельно следует упомянуть, что платформы управления данными могут быть реализованы как для работы исключительно операторов данных, так и иметь свои интерфейсы для работы с отдельными категориями пользователей, предоставляющие возможность оперативного отображения максимально широкого состава данных по конкретной предметной области. В качестве примера на рисунках 13.7 и 13.8 представлены подобные интерфейсы клиентского каталога телекоммуникационного оператора.
ПРАКТИЧЕСКИЙ ПРИМЕР
Опыт реализации MDM-проектов в «Телеком Дубль» показал целесообразность использования итеративного подхода, описанного в этой главе.Не вызывает сомнения и оптимальность применения архитектуры, основанной на комплексном MDM-решении. В частности, если говорить о клиентском домене, система управления основными данными содержит все сведения о клиенте в виде «золотых записей». Сюда относится информация как о самом клиенте, так и об использованных им тарифах и услугах, всех договорах, нормативных актах, сервисах и командах, которые этими сервисами управляют. Имея под рукой сведения такого объема и уровня детализации, «Телеком Дубль» может, например, формировать максимально приближенные к реальности KPI для каждого сотрудника.
Литература к главе 13
• Андриченко А. Н. Тенденции и состояние управления справочными данными в машиностроении // Онтология проектирования, 2012. 2 (4): 25–35.
• Голубев С. С., Лоцманов А. Н., Кузин А. Ю., Соловьев В. Г., Козлов А. Д., Григорьев Б. А. Отраслевая система государственной службы стандартных справочных данных нефтегазового комплекса // Законодательная и прикладная метрология. 2020. 3: 12–16.
• Немцов Э. Ф. ИСУЖТ и нормативно-справочные данные // Автоматика, связь, информатика, 2020. 2: 15–18.
• Чигиринский Ю. Л. Методика повышения надежности справочных данных // Известия Волгоградского государственного технического университета, 2011. 13 (86): 55–61.
• Янченко Г. А. К вопросу о стандартизации справочных данных плотностных свойств горных пород // Горный информационно-аналитический бюллетень (научно-технический журнал), 2011. 8: 111–115.
• Khatri V., Brown C. Designing data governance // Communications of the ACM, 2010. 53 (1).
• Ladley J. Data Governance: How to Design, Deploy, and Sustain an Effective Data Governance Program: 2nd Edition. Academic Press, 2020.
• Silvola R., Jaaskelainen O., Kropsu-Vehkapera H., Haapasalo H. Managing one master data – Challenges and preconditions // Industrial Management & Data Systems, 2011. 111 (1): 146–162.
• Zmud R. W. An Examination of ‘Push-Pull’ Theory Applied to Process Innovation in Knowledge Work // Management Science, 1984. 30 (6): 727–738.
Назад: Глава 12. Обеспечение доступности и обслуживание данных: основы
Дальше: Глава 14. Обеспечение доступности и обслуживание данных: развитие
