Alex_496Затем нужно определиться по какому, по каким критериям лучший продукт из направления MDM.
Например, бюджет MDM (поставка+ коннекторы) стоит 1млн. евро, ухты, круть! Для кого-то важна элитарность из "закрытость" продукта и потому можно торговаться по з.п. или релокации в Лондоны. Для кого-то важна распространенность продукта и цена лицензий =0. Другой будет радоваться функциональности GUI.А где-то пишут свой MDM полностью с 0.
Чувство элитарности, большой бюджет и радость от GUI это какие-то неправильные критерии :)

Вот например, когда я выше писал про юзер-френдли GUI в Orchestra Networks EBX5 и Oracle DRM, я имел в виду не просто радость от лицезрения рюшечек и бантиков на экране, а ситуации когда нужен GUI, удобный для моделирования иерархических справочников конечными пользователями.

Оба эти инструмента (я внедрял DRM, а EBX5 видел в презентациях и видео) действительно позволяют по принципу WYSWYG настроить иерархию любой сложности минимальным количеством кликов мышки, сопоставить ее узлы с элементами справочников внешних систем и задать произвольные свойства, включая расчетные на спец. языке. В их GUI есть все для ручной работы -- и версионность иерархий, и транзакционность изменений с откатами произвольной цепочки транзакций и удобный diff между версиям и даже copy-paste в веб-интерфейсе, позволяющий копировать огромные ветки справочников, не прибегая к экспорту в Excel/CSV. В общем, все сделано для удобство человека который будет с этим работать.

Так что если для какого-то сценария работы требуется работа конечных пользователей со справочниками, то DRM/EBX5 отлично подойдут. И я с трудом представляю сколько потребуется усилий (и итераций переделки GUI), если разрабатывать такое с нуля.

Исходный сценарий под который создавался Oracle DRM (Razza Dimension Server в девичестве) -- это управление изменениями справочников и управление мэппингами между справочниками масштабных ERP систем при слиянии компаний.

HF тоже знаменит не красивыми слайдами, а надежным решением задачи дедупликации клиентских данных для фин сектора в России. Если известные вам задачи очистки адресных данных решаются запросами к Яндексу, и так действительно выгодно делать, то вам просто повезло :)

Alex_496Рюшечки?
в каком MDM пользователи при вводе данных могут видеть одновременно:
1. системное наименование атрибутов (английское) например, RM
2. бизнес-наименование (желательно локализованное в зависимости от страны если транснац. компания), Менеджер сопровождения
3. бизнес-описание атрибута (тоже локализованное), в котором бы храгилось описание что значит Менеджер привлечения.
Чтобы описания атрибутов хранились централизованно, а не где-то в устаревших BRD файлах Word

Чтобы десятки пользователей однозначно понимали что вводить, а не в другое поле, например, Менеджер


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


и чтобы GUI не был пресыщен, перегружен меню и кнопками, чтобы могли сразу работать самые обычные пользователи

p.s. документации и руководства пользователей у нас не любят читать
Вы обрисовали картину интенсивного ввода данных кучей низкоквалифицированных пользователей.
Это не про MDM. Рисуйте для них спец. интерфейс.

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


Alex_496Roman Kolchin,

?
кстати, как HF в автомате обработает следующие адреса (пишу схематично)
1). так почтупает адрес обьекта в доме на пересечении улиц
Город, Улица1/Улица2 дом 56/23

2). тут к. 2 - то ли квартира, то ли корпус, последние цифры - почтовый индекс
РБ, г. НазваниеГорода, такой-то обл., д. 167 лит. "а" к. 2 пом. 4, 189456

3) тут значит дома 123, 124, 125, вдоль которых павильон
Город, Мира 123-125, пав. 6

4)
трасса Москва - Тула, 125ый км у магазина Подорожник

5)
Город, пр. Просторный, ТЦ Ашан, 3 эт., оф. 2а

и подобных чудных адресов на выборке 250тыс. записей составляет 7%
Я не внедрял и не использовал HF. Я лишь критиковал вашу его оценку -- то что вы его заочно ругали. По моему опыту многолетние продажи и внедрения являются достаточным обоснованием успешности продукта. Скорее всего HF Labs и стригут купоны с рынка и завышают цены, эксплуатируя свой брэнд. Но задачи они должны решать хорошо, иначе бы они столько не просуществовали бы на таком узком рынке -- они же не бодишоп и не интегратор при госах.

No PasaranНовый отчет Gartnera очень странный. Я участвовал в проекте по Orchestra EBX (в Европе, в России вроде внедрений нет), и категорически снова не хочу трогать эту технологию. За симпатичным front-end спрятан убогий back-end, остутствующий DQ, куча ограничений по интеграции и ооогромные проблемы с производительностью и масштабируемостью. Orchestra подходит для PIM и мелких справочников и иерархий, но категорически не подходит для задач CDI (Customer Data Integration) - как такой продукт, игнорирующий CDI, мог стать лидером MDM для меня загадка.
Спасибо, очень интересно! Вы EBX внедряли для какой задачи?

Мне кажется, что и CDI и управление справочниками и иерархиями важны независимо. Ну как ERP и CRM -- и то и другое части единой инфраструктуры компании, но сравнивать их не корректно.



No PasaranКстати, гартнер чудит не первый раз. Если посмотреть на квадрант по DQ, то там тоже хорошо - там Ataccama представлена аж 2 раза в 2 квадрантах -в Visionary и Leaders - один раз под своим брендом, а второй раз под брендом Information Builders. Дело в том, что Information Builders продает решение Ataccama под своим брендом по договору OEM (iWay DQS = Ataccama DQC), как один и тот же продукт мог оказаться в разных квадрантах для всех загадка :).
Гартнер, похоже, сам софт не ставит, а пользуется презентациями. И больше упирает на отзыва клиентов. Наверное, отзывы клиентов Information Builders были более хорошими. Хотя конечно это залет :)

George NordicRoman KolchinХотя конечно это залет :)Никак нет, Ром. Abiliti to execute - это же не к продукту относится. К сожалению, мало иметь хороший продукт - надо уметь его распространять, внедрять, поддерживать... И при этом показывать финансовые результаты. Да еще и чтобы клиенты были довольны. Там в отчете же есть все критерии оценки.
Хм, логика в таком подходе действительно есть. А еще знаешь похожие примеры?

essbase.ruДавайте различать
1) мастер дату (справочники измерений)
2) нормативную информацию - описание объектов .

Т.е. первое это перечень. второе свойства.
Давай не придумывать новые термины :)

essbase.ruЗадам вопрос еще раз
как вы управляете справочниками измерений. (1)
Мне тоже очень интересно, кто и как с измерениями управляется?

Загружаете as is из источников первичных данных?
Вставляете вручную в таблицы хранилища?
А если справочники нужно часто менять по требованиям бизнес-пользователей?

javajdbc...я делаю или MDS или набор Екселовских файлов. Если MDS то пользователи
(business owners, data stewards) сами заносят через MDS портал, или через
Шарепоинт-МДС портал или через MDS-Ексел плагин.
Дальше вполне стандартно > SSIS > DWH dimensions > cubes

Иногда MDS не охота разворачивать, тогда просто я создаю набор
Мастер-Листов -- множество Ексел (или Ексел 2003 или CSV) файлов.
Файлы хранятся на Шарепоинте и в другом обшедоступном месте.
Бизнесс пользователи вносят изменения сами.
По уведомлению я копирую новый Мастер Лист в специальную папку
откуда SSIS ежедневно читает фаил в стейж и дальше как и в случае с MDS.

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

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

Мне самому больше нравится Excel. Но часто он становится перегружен формулами (отображение "бизнес" атрибутов на "технические" атрибуты) и его сложнее валидировать онлайн -- приходится писать VBA код и поддерживать его в актуальном состоянии у всех пользователей-редакторов.

Вы как с такими сложностями справляетесь?

bbx1389если шире смотреть, то лучший результат на проектах с запуском централизованного управления НСИ. Т.е. создается специальная служба , ей вменяется в обязанности отвечать за качество\полноту и т.п. данных . Все изменения через заявки в эту службу.
Поясните в чем преимущество такого подхода? Он же ни чем не отличается от классики (не MDM) -- "все клиенты у нас в CRM" или "номенклатура продуктов ведется только в ERP". То есть какой-то домен мастер-данных (набор справочников) ведется в одной системе. Классика даже более качественные данные дает -- в CRM клиентами занимаются специалисты, которые разбираются в отношениях с клиентами, а продукты в ERP ведут люди, разбирающиеся в производственном учете, а универсальные "специалисты НСИ" не пытаются объять все.

Alex_496у вас 4 CRM, 2 back/ биллинга и еще N наколенных систем и в каждой своя кодировка продуктов, разное качество, ответственность за ввод данных клиентов. в одной CRM клиенты чаще актуализируются, в другой редко. Связать все со всеми системами между собой - ценник адский и годы согласований и работ, ищщо ж разные подрядчики...
ой, аццкий угарЯ не про архитектуру интеграции систем спрашивал. А про подход с выделенным "управлением НСИ". В чем его преимущество?

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