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

Иллюстрация: Shutterstock

Справочная информация и мастер-данные

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

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

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

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

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

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

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

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

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

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

В результате возникает необходимость в серьезной перестройке бизнеса — без весомых на то причин и с вероятными негативными последствиями. Часто всё управление мастер-данными сосредотачивается в единой точке — централизованной MDM-системе, где создается хранилище «эталонных» данных.

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

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

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

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

• Процесс ввода мастер-данных оторван от бизнес-процессов, в которых эти данные естественным образом возникают. Информацию зачастую вводят люди, плохо представляющие себе, как и для чего она будет использоваться.
• Избыточная централизация приводит к эффекту «бутылочного горлышка» в системе MDM и снижению эффективности бизнеса.
• Зачастую при вводе мастер-данных требуется заполнение большого количества обязательных атрибутов, которые использоваться в бизнес-процессах будут значительно позже.

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

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

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

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

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

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

• На практике закрытость систем не обеспечивается в полной мере. При каждом технологическом действии (тестировании, изменении функционала) приходится проводить инициализацию «центральной справочной системы», то есть полную выгрузку справочных данных, что обычно требует доступа к базам данных бизнес-систем. Кроме того, сами системы должны «понимать» разные состояния своих локальных данных (как то: «отправлено получателям», «изменение подтверждено получателем» и др.) и по-разному с ними работать.
• Сложность конструкции, включающей адаптеры, интеграционную шину и правила перекодировки, зачастую превосходит интегральную сложность самих бизнес-компонентов ИТ-системы.
• Затрудняется диагностика обнаруженных ошибок в справочных данных, поскольку в процессе задействовано слишком много систем. Без привлечения ряда технических специалистов разобраться с ними практически невозможно.
• Такую конструкцию очень трудно модифицировать — разворачивать изменения и обновления, создавать дополнительные тестовые среды под локальные задачи и т.д. Бо?льшая часть подобных действий потребует вовлечения всех ИТ-систем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Об авторе:

Михаил Заборов, заместитель генерального директора по стратегическим проектам, группа компаний CUSTIS.