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

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

Термин «мастер-данные» является дословным переводом понятия «Master Data», которое также переводят как «основные данные». Эти данные востребованы многими модулями и компонентами информационной системы. Высокая внутрисистемная значимость такой информации накладывает определенные ограничения на ее качество и, как следствие, на принципы работы с ней: можно говорить, что такие данные являются эталонными, а модуль, который их производит, — единственно верным источником.

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

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

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

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

НСИ или не НСИ?

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

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

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

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

Семь раз отмерь, один раз отрежь

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

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

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

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

Модели ведения НСИ

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

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

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

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

Сравнительный анализ

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

Рассмотрим каждую характеристику в отдельности.

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

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

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

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

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

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

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

«Звезда» в торговой сети

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

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

Что выбрать?

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

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

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

Валерий Никитин — аналитик проекта MDM направления «Торговые сети» компании «Заказные ИнформСистемы» (CustIS); vnikitin@custis.ru
Роман Алексеев — руководитель проекта MDM направления «Торговые сети» компании «Заказные ИнформСистемы» (CustIS); ralexeev@custis.ru
Михаил Заборов — руководитель направления «Торговые сети» компании «Заказные ИнформСистемы» (CustIS)


Таблица. Сравнение моделей ведения НСИ

Рис. 3. Пример архитектуры информационной системы, построенной по модели «звезда»

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF