Спасибо за отзыв. Если честно, тоже не очень понимаю по какому принципу люди реагируют на ту или иную статью. Возможно эта тема вообще людям не очень близка, или просто не задумываются, что там может быть что-то сложное.
Ну обзор по MDM можно взять хоть Гартнеровский. По подходам к интерфейсной части, чаще всего в качестве среды настройки системы используют экосистему Eclipse, а для работы непосредственно пользователей (дата-стюардов) разрабатывают веб-интерфейс. Такая схема выглядит в целом довольно неплохо. Но есть и полностью web-based приложения, например, EBX5. Ну или 1С:MDM, если рассматривать наш рынок.
Ну обзор по MDM можно взять хоть Гартнеровский. По подходам к интерфейсной части, чаще всего в качестве среды настройки системы используют экосистему Eclipse, а для работы непосредственно пользователей (дата-стюардов) разрабатывают веб-интерфейс. Такая схема выглядит в целом довольно неплохо. Но есть и полностью web-based приложения, например, EBX5. Ну или 1С:MDM, если рассматривать наш рынок.
Расскажите, в какой из CRM-систем реализовано что-то большее, чем просто вот такая структура хранения? Какая из CRM поможет мне лучше, чем MDM собрать базу клиентов из разрозненных источников, причесать ее, поддерживать в актуальном состоянии? Какая из CRM поможет мне создать произвольные хранилища разнородной информации по разным аспектам проектов с динамически изменяемой структурой и т.д.?
Спасибо за вопрос. Ждал его :)
В 1С эти сущности действительно абсолютно правильно разделены (правда только в 2 конфигурациях — УТ11 и ERP2). Но при этом существует много сложностей для использования их в таком режиме, о котором я пишу в статье.
1. Само по себе наличие этого разделения ничего не добавляет в части повышения продаж и Знания своего клиента, т.к. все как обычно упирается Data Governance или по русски — политику управления данными. Ну не дает УТ11 или ERP2 никаких вменяемых механизмов для этого. В больших внедрениях это просто не работает.
2. Сама по себе схема 1С довольно негибкая. По причине того, что Партер и Контрагент протягиваются во все операции и регистры. Если мы вдруг осознаем, что вот этот контрагент — это на самом деле другой партнер или вот этот партнер, это не один, а два партнера или наоборот, то вероятность того, что мы возьмем и перепишем все ссылки во всех операциях и регистрах стремится к нулю.
3. Не решена проблема с контактными лицами — персоны никак не выделяются. А для нашего бизнеса это даже важнее, чем клиенты.
4. Нет возможности гибко настраивать и вести множество данных по клиентам и проектам (механизм доп.реквизитов, простите, но не подходит :)))
У Информатики и других MDM-вендоров DQ — частенько продается отдельно. Можешь покупать, можешь нет. Но для управления мастер-данными в целом DQ — критически важный механизм, равно как и ETL или ESB. Я бы не стал у себя внедрять управление мастер-данными без этих механизмов.
А по поводу изменения структуры. Это у референс-данных структура условно-постоянная. У мастер-данных она живая и меняется довольно часто. Именно поэтому MDM-системы уделяют версионированию данных и версионированию структур данных такое большое внимание.
Ну я не навязываю никому наш сценарий. Есть люди, которые выбирают глубокую доработку, а есть, которые выбирают готовые решения. У того и другого подхода есть свои плюсы и свои минусы.
Я написал в статье, что нам не хватало в CRM. В первую очередь это управление данными. Что называется Data Governance. В отличие от MDM, CRM обычно мало чего предоставляет для этого. DQ и прочие механизмы нормально представлены только в MDM. Опять же я не говорю обо всех вообще MDM или CRM. Понятно, что есть хреновые MDM, а есть CRM, где реализованы в полном объеме функции CDI.
Что еще не хватало — это ведение информации по клиенту/проекту. У нас довольно много информации агрегируется и анализируется потом. Объем и структура этих данных постоянно меняются. В MDM удобно вести как сами данные, так и версионировать изменения структур.
Данную схему реализовали для себя в нашей же компании, поэтому ничего никому продать цели не было. Была цель сделать хорошо. CRM смотрели разные, но нигде нет таких средств работы с данными, как в MDM. Кроме того, как я написал CRM у нас тоже есть и они замечательно друг-друга дополняют.
Ну могу сказать, что проблема точно не надуманная, а реально присутствовала как минимум у нас. А на самом деле за наш долгий век автоматизации предприятий различного профиля присутствовала у доброй половины наших клиентов.
Я всего лишь говорил что файловый обмен, не смотря на его старость, все еще живее всех живых. Не более того. И платформа 1С наиболее яркий его пример. Я отлично знаю все виды интеграции поддерживаемые данной платформой.
Ну и обсуждение достоинств и недостатков платформы 1С несколько уводит в сторону от самой статьи.
P.S. Журнал регистрации на базе СУБД присутствует уже более двух лет в 1С.
Ну как бы то ни было такой вид обмена, как минимум с конфигурациями 1С, все еще имеет право на жизнь и довольно широко используется. Не упомянуть его было бы не совсем правильно.
Да ценность этой статьи была бы намного выше. :) Но если серьезно, то фирма 1С до сих пор считает такой вид обмена одним из основных. Так что я бы пока не стал сбрасывать его со счетов.
MDM&RDM по факту обычно управляется в одной системе. А вот PDM — это обычно отдельные системы. В этой части MDM обычно закрывают только PIM, и то не все. Например, Informatica MDM на PIM не особо специализируется, они больше на CDI.
Это довольно устоявшаяся модель типизации MDM. Из наиболее полных книг на эту тему могу посоветовать:
https://www.amazon.com/MASTER-DATA-MANAGEMENT-GOVERNANCE/dp/0071744584/ref=sr_1_1?ie=UTF8&qid=1489757550&sr=8-1&keywords=MDM
https://www.amazon.com/Enterprise-Master-Data-Management-Information/dp/0132366258/ref=sr_1_2?s=books&ie=UTF8&qid=1489757596&sr=1-2&keywords=MASTER+DATA+MANAGEMENT
Первую из этих книг мы сейчас готовим к изданию на русском языке.
Ну так часто бывает. Сначала задача кажется простой, поэтому по-быстрому слепили базу в SQL Server, а потом начали прикручивать туда разные фишечки. Вечная дилемма — выбрать что-то готовое или написать самим.
Во многом это вопрос терминологии. Ваша терминология близка к той, которую использует 1С в своей платформе 1С: Предприятие. Но там есть еще Перечисления, Регистры сведений, Регистры накопления, Регистры расчетов, Регистры бухгалтерии, Бизнес-процессы, Задачи и другие предметные сущности, которые можно отнести к тому или иному классу данных, представленных мной.
Есть еще один нюанс. Мастер-данные — это не обязательно только «справочники», на которые ссылаются «документы». В системе MDM часто хранят, например, сводные данные по оборотам по клиенту или по сделанным им заказам. А потом эти данные анализируют для выявления, например, предпочтений клиента в тех или иных продуктах или услугах.
В 1С эти сущности действительно абсолютно правильно разделены (правда только в 2 конфигурациях — УТ11 и ERP2). Но при этом существует много сложностей для использования их в таком режиме, о котором я пишу в статье.
1. Само по себе наличие этого разделения ничего не добавляет в части повышения продаж и Знания своего клиента, т.к. все как обычно упирается Data Governance или по русски — политику управления данными. Ну не дает УТ11 или ERP2 никаких вменяемых механизмов для этого. В больших внедрениях это просто не работает.
2. Сама по себе схема 1С довольно негибкая. По причине того, что Партер и Контрагент протягиваются во все операции и регистры. Если мы вдруг осознаем, что вот этот контрагент — это на самом деле другой партнер или вот этот партнер, это не один, а два партнера или наоборот, то вероятность того, что мы возьмем и перепишем все ссылки во всех операциях и регистрах стремится к нулю.
3. Не решена проблема с контактными лицами — персоны никак не выделяются. А для нашего бизнеса это даже важнее, чем клиенты.
4. Нет возможности гибко настраивать и вести множество данных по клиентам и проектам (механизм доп.реквизитов, простите, но не подходит :)))
А по поводу изменения структуры. Это у референс-данных структура условно-постоянная. У мастер-данных она живая и меняется довольно часто. Именно поэтому MDM-системы уделяют версионированию данных и версионированию структур данных такое большое внимание.
Я написал в статье, что нам не хватало в CRM. В первую очередь это управление данными. Что называется Data Governance. В отличие от MDM, CRM обычно мало чего предоставляет для этого. DQ и прочие механизмы нормально представлены только в MDM. Опять же я не говорю обо всех вообще MDM или CRM. Понятно, что есть хреновые MDM, а есть CRM, где реализованы в полном объеме функции CDI.
Что еще не хватало — это ведение информации по клиенту/проекту. У нас довольно много информации агрегируется и анализируется потом. Объем и структура этих данных постоянно меняются. В MDM удобно вести как сами данные, так и версионировать изменения структур.
Ну и обсуждение достоинств и недостатков платформы 1С несколько уводит в сторону от самой статьи.
P.S. Журнал регистрации на базе СУБД присутствует уже более двух лет в 1С.
https://www.amazon.com/MASTER-DATA-MANAGEMENT-GOVERNANCE/dp/0071744584/ref=sr_1_1?ie=UTF8&qid=1489757550&sr=8-1&keywords=MDM
https://www.amazon.com/Enterprise-Master-Data-Management-Information/dp/0132366258/ref=sr_1_2?s=books&ie=UTF8&qid=1489757596&sr=1-2&keywords=MASTER+DATA+MANAGEMENT
Первую из этих книг мы сейчас готовим к изданию на русском языке.
Есть еще один нюанс. Мастер-данные — это не обязательно только «справочники», на которые ссылаются «документы». В системе MDM часто хранят, например, сводные данные по оборотам по клиенту или по сделанным им заказам. А потом эти данные анализируют для выявления, например, предпочтений клиента в тех или иных продуктах или услугах.