Сопоставление существующих и описанного подходов

 

В главе 8 мы уже говорили о том, что за последние годы создано значительное количество референтных моделей и методологий управления данными в организациях[435],[436],[437].

Ряд методологий сфокусирован на ПО в сфере MDM[438]. Подход, описанный выше, отличается от этих методологий тем, что не зависит от конкретного базового MDM-продукта.

В работе О’Kейна и Морана[439] предложена модель для построения системы MDM в организации, которая включает семь блоков: концепцию, стратегию, метрики, информационное управление, оргвопросы и роли, ЖЦ информации, а также инфраструктуру. Эта модель предназначается для ранних стадий внедрения MDM, однако она ориентирована на стратегию «сверху вниз», покрывая всю деятельность организации по внедрению MDM. Функциональная модель, предложенная в данной главе, предназначается для использования при реализации итеративной стратегии, ориентированной на удовлетворение конкретных потребностей организации, которые выражаются в терминах MDM.

В свою очередь, в труде Мартина Офнера и его коллег[440] предлагается модель для анализа жизненного цикла основных данных в организации с целью определить недостающие виды деятельности. Основными компонентами модели являются: портфолио данных; проектирование данных и системы; управление данными; поддержка данных. Эта модель слабо связана с программной частью MDM-решения, а также не рассматривает уникальные задачи организации по внедрению MDM.

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

Кроме того, предполагается выполнить перевод (отображение) функциональности типового MDM-решения на различные MDM-продукты, а также осуществить более тесную интеграцию подхода с областью управления знаниями[441],[442].

 

Пример архитектуры информационных систем, основанной на комплексном 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.