Просмотр исходного текста страницы Управление справочными данными: гибкий подход

<blockquote>
''[[:Категория:Михаил Заборов (Статьи)|Михаил Заборов]], руководитель стратегических проектов, рассказал журналу [http://www.iemag.ru/numbers/index.php?YEAR_ID=1554&ID=28834 Intelligent Enterprise] о подходах и практиках управления справочными данными в компаниях, также об ограничениях применения MDM-систем. Почему универсальная MDM-система является всего лишь одним из способов организации работы со справочными данными? Что необходимо для эффективного управления нормативно-справочной информацией организации? Об этом&nbsp; — в статье [http://www.iemag.ru/master-class/detail.php?ID=28880 Управление справочными данными: гибкий подход] на сайте и в бумажной версии журнала.''
</blockquote>

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

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

==Справочная информация и мастер-данные==
Среди множества разнообразных корпоративных данных есть их специфическая категория, которая отличается от оперативных (транзакционных) данных, — так называемые '''«справочники и классификаторы»''', или '''справочные данные.''' На них приходится в среднем около 15% от общего объема данных. Справочные данные востребованы во многих модулях и компонентах информационной системы предприятия, а их структура во многом определяет:

*язык взаимодействия различных информационных систем;

*аналитику общекорпоративной отчетности;

*настраиваемость, адаптируемость и гибкость информационных систем.

В российской практике для определения такого типа данных обычно используют термин '''нормативно-справочная информация (НСИ).''' Под '''нормативностью''' здесь понимается регламентация (обязательность) использования этих данных, а под '''справочностью''' — то, что они оформлены в виде «справочников» (подобно словарям или каталогам.

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

Классификаторы служат для разделения однородных объектов на категории и, следовательно, зависят от того, для чего и как эти данные будут использоваться. Поэтому классификаторов может быть много над одним и тем же множеством данных. Естественно, это деление отражается и в отчетах, но наиболее важно, что именно по нему происходит построение бизнес-процесса.[Alex1] 

Справочные данные, которые признаются «эталонными» и собираются из разных систем в так называемый '''«основной файл» (Master File),''' выступающий единственно верным источником информации, называются '''мастер-данными (Master Data).''' Эти данные обладают максимальной степенью нормативности, а задачи управления ими получили название Master Data Management (MDM).

==Унифицированный подход к управлению справочными данным==

Задача управления справочными данными возникает, когда приходится интегрировать несколько ИТ-систем: для обмена сообщениями или документами им необходима «общая терминология».

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

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

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

Рассмотрим самые распространенные подходы к управлению мастер-данными, являющиеся, по сути, унифицированными решениями.

===Централизованный ввод===

Это классический и самый простой в реализации способ управления мастер-данными. Все справочники ведутся в одном месте специализированной службой MDM, откуда они реплицируются в бизнес-системы (рис. 1А).

[[Файл:Pic1MDMIE.png|центр|thumb|600px|'''Рис. 1.''' Стандартные схемы работы со справочными данными]]

'''Типичные проблемы централизованного ввода'''

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

*Избыточная централизация приводит к эффекту «бутылочного горлышка» в системе MDM и снижению эффективности бизнеса.

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

''Невозможно принять товар на складе, пока специалисты службы мастер-данных не заведут товар в справочнике, заполнив все необходимые атрибуты (которых может быть несколько десятков), что занимает длительное время.''

===Федеративное управление===

Другая модель, «щадящая» по отношению к бизнес-системам, применяется в случае, когда эти системы закрыты или возможности их модификации ограничены. Бизнес-системы ничего не знают друг о друге, информация заносится в локальные справочники каждой из них независимо. Эталонного мастер-справочника не существует.

Функции системы управления справочной информацией берет на себя интеграционная шина данных, которая оказывается центральным «всезнающим» компонентом, которому известны локальные идентификаторы всех записей общих справочников во всех бизнес-системах (рис. 1Б). При обмене сообщениями она «на лету» осуществляет перекодировку из терминов одной системы в термины другой.

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

'''Типичные проблемы федеративного управления'''

*На практике закрытость систем не обеспечивается в полной мере. При каждом технологическом действии (тестировании, изменении функционала) приходится проводить инициализацию «центральной справочной системы», то есть полную выгрузку справочных данных, что обычно требует доступа к базам данных бизнес-систем. Кроме того, сами системы должны «понимать» разные состояния своих локальных данных (как то: «отправлено получателям», «изменение подтверждено получателем» и др.) и по-разному с ними работать.

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

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

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

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

===Консолидация и распространение===

При этом подходе основные объемы мастер-данных вводятся в бизнес-системах, и затем они собираются в «эталонный» справочник единой MDM-системы (рис. 1В). Там происходит очистка — фильтрация дублей и некорректных данных. Затем данные реплицируются по всем системам, включая и системы-источники (производя в них необходимые изменения и привязку к «эталонному» справочнику).

'''Типичные проблемы подхода'''

*Для управления мастер-данными необходимо создавать новые «искусственные» процессы и специализированную MDM-службу.

*Сотрудникам службы MDM, находящимся вне контекста бизнес-систем, сложно разбираться с данными, которые были в них введены. Это становится особенно явным при разрешении конфликтов из-за данных, поступивших из разных систем.

*Консолидация данных, как правило, требует сложных доработок в бизнес-системах. Например, нужно реализовать реакцию на различные состояния записи в едином справочнике.

*Приходится создавать очень сложные механизмы обратной репликации.

*Нужно каждый раз выстраивать сложные схемы разрешения конфликтов, поскольку в общем виде эта задача не решается.

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

==Гибкий подход к управлению справочными данными==

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

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

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

Далее осуществляется проектирование независимых потоков справочной информации.

*Выделяются справочные данные в тех системах, которые их ведут.

*Определяется способ управления каждым потоком (выделение мастер-данных, обмен по принципу шины, параллельный ручной ввод и т. д.).

*По возможности обеспечивается ввод и редактирование справочных данных в составе именно тех процессов, где они возникают согласно логике бизнеса.

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

*Обеспечиваются механизмы доопределения и обогащения справочных данных, если это необходимо.

Одна и та же бизнес-система может выступать одновременно и источником, и получателем справочных данных. На основании выявленных потребностей в «эталонных» справочниках проектируется система '''хранилищ мастер-данных.''' Иногда достаточно одного централизованного хранилища, но зачастую эффективнее создавать несколько хранилищ, формируя таким образом кластеры управления мастер-данными (рис. 2).

''Группу систем, которая поддерживает ассортиментное планирование будущего сезона, можно объединить в отдельный кластер данных, в хранилище которого находятся «прообразы» будущих товаров. А во второе хранилище мастер-данных, с которым работают логистические и торговые системы, товары будут выгружаться из первого только по завершении планирования. Это освободит логистические и торговые системы от «преждевременных знаний» о товарах, которые еще не поступили в продажу.''

[[Файл:Pic2MDMIE.png|thumb|600px|центр|'''Рис. 2.''' Гибкий подход к управлению справочными данными]]

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

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

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

===Автоматизация ввода справочных данных===

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

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

===Дифференцированный подход к управлению различной информацией===

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

===Значения атрибутов вводятся только тогда, когда это необходимо===

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

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

===Обогащение атрибутов===

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

''Система, отвечающая за распределение товаров по магазинам, может добавлять к данным справочников складов и магазинов свои атрибуты (лимиты, способы приемки и т. д.) для корректного управления товарным потоком.''

===Распределенное ведение справочников===

Иногда нужно разделить ведение одного справочника между различными экземплярами бизнес-систем. Для этого на уровне каждой записи в справочнике фиксируется, какая именно система за нее отвечает.

''Центральное и Южное подразделения территориально распределенной торговой сети ведут собственные версии каталогов товаров со специфическими атрибутами, которые нужны только в данном регионе. При этом общая часть каталога ведется в Центре, а Южное подразделение ведет свой локальный каталог.''

''Потоки мастер-данных могут выглядеть так: общий каталог ежедневно реплицируется из Центра на Юг для осуществления торговли. А специфические «южные» товары ведутся в локальном каталоге и раз в месяц реплицируются в Центр для формирования отчетности.''

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

===Отсутствие принудительного нормирования===

Требование обязательного наличия «эталонного» справочника является весьма сильным нормирующим действием. Иногда оно является избыточным и заставляет участников договариваться даже в тех случаях, когда в этом нет никакой необходимости. Гибкий подход позволяет избегать конфликтов, которые не обусловлены задачами бизнеса.

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

===Баланс гибкости и производительности===

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

''Целесообразно жестко зафиксировать наиболее часто используемые атрибуты товаров, такие как торговая марка или цвет. Их изменение возможно только при модификации ПО — этим достигается максимальная производительность при чтении и записи данных.''

''Остальные атрибуты (вес брутто, объем в распакованном виде и т. д.) можно размещать в универсальных структурах хранения, которые позволяют пользователю самостоятельно добавлять атрибуты к записи, не прибегая к помощи разработчиков. Так обеспечивается баланс необходимой гибкости и приемлемой производительности.''

===Репликация изменений===

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

==Индивидуальное решение из стандартных блоков==

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

[[Категория: Intelligent Enterprise (Публикации)]]
[[Категория: Михаил Заборов (Статьи)]]
[[Категория: 2013 год (Статьи)]]

{{replicate-from-custiswiki-to-lib}}