Восходящая «Звезда» MDM

Валерий Никитин: аналитик проекта MDM направления «Торговые сети» компании «Заказные ИнформСистемы»

Роман Алексеев: руководитель проекта MDM направления «Торговые сети» компании «Заказные ИнформСистемы»

Михаил Заборов: руководитель направления «Торговые сети» компании «Заказные ИнформСистемы»

Журнальная версия статьи опубликована в «Директор информационной службы (CIO.RU)», №9 (сентябрь) 2008, стр.50-53.

Быстрые темпы развития ИС, предназначенных для ведения НСИ, не дают возможности разработчикам договориться о терминологии и разобраться во множестве существующих решений. Анализ рынка приводит к выводам о том, что российским компаниям для ведения НСИ больше других подходит модель «Звезда».

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

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

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

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

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

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

НСИ или не НСИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Синхронизация

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

Ответственность

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

Единообразие

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

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

Собственные атрибуты

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

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

Потребители

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

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

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

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

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

Что выбрать

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

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

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

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Восходящая «Звезда» MDM»

Персональные инструменты

Просмотры