Alex_496Вам, как владельцу ERP / АБС / CRM - нужны все эти доп. напруги помимо своего функционала?
Ну я же не про технику писал!! Все ваши аргументы про равноудаленность MDM от прочих систем я понимаю я поддерживаю.

Я задавал вопрос про организацию выделенного управления НСИ, которая будет принимать заявки и своими руками что-то в системе управления НСИ/MDM править.

Зачем это подразделение?

В чем красота получившегося бизнес-процесса: инициатор изменения -> заявка (ручная по почте? в 3-й системе?) -> супермены из управление НСИ -> система MDM?

Разве не лучше: инициатор изменения -> заявка на изменение внутри MDM (по сути драфт новой записи или иерархии) -> автоматические проверки в MDM -> владелец справочника (из соответствующего бизнеса, или аналитик из основной системы-потребителя типа ERP/CRM). Меньше участников, участники лучше понимают задачи учета, в которых используются справочники.

Я на самом деле видел службы НСИ в различных конторах и именно поэтому не считаю их единственно правильным способом организации во всех ситуациях. Там где я видел они по сути были отдельной группой аналитиков в рамках поддержки какой-то основной системы типа SAP, Oracle EBS или Siebel. Под громким названием "централизованное НСИ" подразумевалась всего лишь поддержка модуля большой системы, в целях функционирования этой системы с минимальным учетом интересов остальных потребителей.

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

Т.е. у меня в основном MDS как контроль над справочниками и
интеграционными линками для нужд DWH.

У вас MDS -- насколько я понял -- почти трансакционная фронт-енд аппликация,
с реал-тайм конкурентными апдейтами...

...достаточно разные задачи...
Интересно было бы сравнить сценарии использования.

Опишу мой кейс. Моя основная сфера деятельности -- аналитические приложения типа бюджетного планирования и консолидации на продуктах Oracle Hyperion. Архитектура приложений -- кубы. Измерения кубов часто берутся "из головы" и не содержатся ни в одной другой системе-источнике. Кубов с течением времени становится много.

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

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

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

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

Вендор не предоставляет в составе данных продуктов действительного удобного инструмента для управления всеми этими вещами в масштабах нескольких кубов. Остается только Excel. Или за хорошие деньги Oracle Data Relationship Management .

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

Криво сформулировал:
Roman Kolchin- измерения частые, не реже одного раза в месяц;
В том то и дело, что изменения НЕ частые, но периодические и с очень жесткими требованиями по срокам.

Кто-нибудь решает подобные задачи?

Пока самое лучшее, что я использовал для этих целей -- Oracle Data Relationship Management .
Основной конкурент, не привяазанный к тому же ни к какому вендору аналитических и ERP-шных приложений -- это Orchestra Networks .

Есть еще удобные инструменты и красивые подходы к решению этих задач?

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

Юрий КудрявцевСейчас начинаем сравнивать Orchestra DMX и MDS для одного заказчика, интересно будет посмотреть, насколько плоха Orchestra внутри и насколько хорош стал MDS.
В правильном MDM для аналитики должна быть возможность моделировать все что угодно без использования Excel.

Что было полезно, когда я внедрял Oracle Data Relationship Management:
- быстрое добавление новых атрибутов без необходимости блокировки справочников;
- контекстно-зависимый состав атрибутов элементов справочников -- возможность варьировать состав и значения атрибутов в зависимости от принадлежности элемента к определенной иерархии (при этом элемент может входить в любое кол-во иерархий), от типа хранения в иерархии (лист/узел верхнего уровня);
- динамические значения атрибутов с возможностью получения различных значений в зависимости от контекста, от взаимного расположения элементов, от переменных среды;
- разграничения доступа на просмотр и редактирование для иерархий, ветвей иерархий, отдельных атрибутов и групп атрибутов;
- транзакционность любых изменений с возможности получения состояния иерархии на любой момент времени и сохранения исторического значения в виде новой иерархии;
- diff, copy-paste, merge межу различными иерархиями и различными версиями одной и той же иерархии;
- экспорт/импорт справочников в виде лога транзакций -- то есть возможность импорта элементов справочников в виде последовательности команд типа "добавить узел", "задать значение свойства X";
- ну и конечно полный Drag-n-Drop и WSWYG с адекватной производительностью для сотен тысяч узлов :)

На момент когда я плотно работал с Oracle DRM этого еще не было, но сейчас есть и имхо это полезный функционал -- процесс внесения изменений внутри mdm-инструмента с возможностью формировать заявки на изменение в виде новых версий иерархий и утверждения изменений с использованием diff/copy-paste/merge. У Oracle'а сейчас для этого используется отдельный модуль -- Oracle Data Relationship Governance.

Еще я не касался вопросов интеграции, поэтому авторитетно сказать, что должно уметь API не скажу. Но Oracle дорабатывает API в _КАЖДОМ_ новом патче. Так что там, очевидно, есть чего развивать.

В материалах с конференций встречал такой кейс использования Oracle DRM:
- бизнес-юезр заходит в DRM, создает "контейнер" — новую мега-иерархию, в котрую закидывает куски существующих иерархий в виде веток от корня;
- после этого пользователь жамкает на кастомную кнопку;
- для пользователя создается куб... да-дам! COGNOS (на тот момент еще не TM1, вроде) и в него загружаются данные в соответствии с выбранными иерархиями.

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

Кстати, про OrchestraNetworks я узнал из внутренних Oracle'вых презентация по DRM -- в них OrchestraNetworks EBX5 была названа основным конкурентом. Это было года четыре назад и тогда ни DRM ни EBX5 не были в Гартнере и их сложно был реально сравнивать.

No PasaranПосмотрите Ataccama RDM.
Спасибо.
Мб есть презентации или видео с демонстрацией его возможностей? В идеале, чтобы демонстрировали описанный мной функционала.

У Andrew White, аналитика Gartner'а по теме MDM, вышла статья , описывающая различия в сценариях использования ПО для управления мастер-данными -- Master Data Management (MDM) vs Application Data Management (ADM).

Как оказалось, потребности и задачи, которые я описывал выше в этой теме, да и с которыми я чаще всего сталкивался в различных компаниях, наблюдая их со стороны, относится к области названной Application Data Management (ADM). Это задачи и инструменты, связанные с управлением данными какого-то одного приложения или пакета приложения одной платформы типа ERP или DWH.

Конечно, с чисто технической точки зрения MDM и ADM это игра слов. Но при решении организационных вопросов о запуске проекта, обосновании цены и выборе конкретного программного решения удобно пользователями компактными емкими терминами.

По мнению автора статьи фундаментальное различие между MDM и ADM -- это то, сколько процессов и сколько различных систем завязано на *DM систему. Если много систем и много процессов -- то это MDM, а если одна (или полторы, например одна мега-ERP и пара ее сателлитов) -- это ADM. Отсюда следуют все остальные различия.

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

Функционал MDM в принципе может быть не очень юзер-френдли при условии, что система обеспечивает нужную связанность данных для кучи бизнес-процессов и систем. То есть с убогостью интерфейса можно мириться, если ценность в другом. Тут я вспоминаю MDM HUB'ы от Oracle'а с очень глубокой ритейловой, промышленной и еще рядом узких специализаций, но c совершенно отвратным UX.

С другой стороны система класса ADM обычно выбирается для затыкания "дыр" в функционале какой-то основной системы, типа SAP, Oracle E-Business Suite или платформы аналитических приложений типа Oracle Hyperion или IBM Cognos. В этом случае ценность ADM системы заключается в том, на сколько эффективно затыкаются эти "дыры", поэтому важность хорошего интерфейса пользователя возрастает стократ. Но при этом, тк речь идет об автоматизации всего лишь одной системы или одного бизнес-процесса, то и цена вопроса ожидается существенно ниже, чем у полноценной MDM системы. Собственно, в своей практике я ровно с этим и сталкиваюсь.

Продолжая тему,
уважаемые ALL, вы в своей практике больше сталкивались с системами, или по крайней мере видели потребности в необходимости каких систем, класса *DM: ADM vs MDM.

essbase.ruRoman Kolchin,

Еще не раскрыта тема работы с натуралкой ) - площадь офиса , расстояние до , и т.д. и т.п.
Ищи приложения (не MDM) по работе с соответствующими объектами.

essbase.ruRoman Kolchin,

Еще не раскрыта тема работы с натуралкой ) - площадь офиса , расстояние до , и т.д. и т.п.
ORACLE SITE HUB

No PasaranНашел вот такое видео.
А вообще если интересно, то могу показать вживую.
Спасибо. Не очень похоже на Hyperion DRM, но вроде почти все что нужно есть.

А какой ценник именно на модуль RDM? Как он лицензируется?

PS. Вживую показывать пока не надо -- прямо сейчас нет задачи под этот инструмент, поэтому не надо тратить время. Но если задача возникнет, то обязательно воспользуюсь предложением :)

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

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

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

Где здесь дешевизна и эффективность?

bbx1389"номенклатура продуктов ведется только в ERP"
хорошо если у вас одна ERP, а не n с неполностью пересекающимся ассортиментом, например по разным странам. Хорошо когда продуктовых менеджеров не пару десятков, а хотя бы 10, и меняются они не каждый квартал. Атрибутов продукта может быть под сотню. Хорошо, если правила проверки простые и их можно реализовать в программе. Хорошо если бизнес-процессы связанные с отдельными атрибутами , хотя бы можно диаграммой на 1 листе описать. Ну и т.д.

"продукты в ERP ведут люди, разбирающиеся в производственном учете" -это кто?
"продукты в ERP ведут люди, разбирающиеся в производственном учете" -- это люди, которые разбираются в соответствующих бизнес-процессах и их данных в ERP. Если имеем дело с одной ERP, то это люди связанные с этой ERP, если ERP несколько -- то люди из разных ERP.

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

Собственно, весь западный рынок MDM построен на идее дать разным людям общий инструмент управления разделяемыми данными.