Комментарии 18
Всё верно написано. MDM это основополагающая «система информационного порядка» в бизнесе. Когда «всё понял» — ясно, что именно с неё лучше и начинать автоматизировать бизнес. И тем не менее, почти все выбирают дорогу «граблей»: сначала автоматизируем «бардак», а после приходим к осознанию содеянного. Даже наглядный (в т.ч. инсайдерский) западный опыт, хоть и много чему учит, но «учатся мало» на нём.
По крайней мере, в SAP, есть возможность применения более широких аналитик по контрагентам (BP) и ведения разного рода отношений. Хоть все склады, куда отгружать, заводи. Привязка через роли БП осуществляется. Так что проблема надуманная, и связана скорее всего с тем, что ERP выбиралась без учета реальных потребностей бизнеса, либо настроена перректально.
Ну могу сказать, что проблема точно не надуманная, а реально присутствовала как минимум у нас. А на самом деле за наш долгий век автоматизации предприятий различного профиля присутствовала у доброй половины наших клиентов.
Если в системном ландшафте только ERP и CRM, и между ними есть интеграция, то можно было выстроить процессы и потоки данных так, чтобы единой точкой ввода для данных о контрагентах был CRM. А процессы согласования и там можно настроить. Без внедрения MDM.
В вашем же варианте, количество систем увеличилось без особой необходимости. Да, продали MDM, молодцы. Это и было целью?
P.S.Это в случае, если CRM нормальный, а не студенческая поделка. Если же функционал CRM убогий, то получается ситуация, что клиент ССЗБ, сэкономив на CRM получил в нагрузку более дорогой продукт. Насколько я помню, практически у всех вендоров MDM лицензии одни из самых дорогих.
В вашем же варианте, количество систем увеличилось без особой необходимости. Да, продали MDM, молодцы. Это и было целью?
P.S.Это в случае, если CRM нормальный, а не студенческая поделка. Если же функционал CRM убогий, то получается ситуация, что клиент ССЗБ, сэкономив на CRM получил в нагрузку более дорогой продукт. Насколько я помню, практически у всех вендоров MDM лицензии одни из самых дорогих.
Данную схему реализовали для себя в нашей же компании, поэтому ничего никому продать цели не было. Была цель сделать хорошо. CRM смотрели разные, но нигде нет таких средств работы с данными, как в MDM. Кроме того, как я написал CRM у нас тоже есть и они замечательно друг-друга дополняют.
Какие именно средства?
Workflow? он везде
DQ — так это и в MDM в зачаточном состоянии, есть отдельные продукты
Кастомизация — ну тут вообще зоопарк решений.
Проверка на дубликатов — настраивается.
Механизмы консолидации и т.п. — в данном решении не использовались.
На мой взгляд, правильнее было идти от процесса, а не от систем. Определить задачи, нереализуемые в текущем ландшафте, посмотреть, как из реализовать в имеющемся софте, а уж потом принимать решение — глубокая доработка либо внедрение MDM.
Часто доработать тот же SAP ERP проще и дешевле, чем внедрять MDM.
Если же целью было создание демо-стенда, то лучше было подобрать более релевантный сценарий.
Workflow? он везде
DQ — так это и в MDM в зачаточном состоянии, есть отдельные продукты
Кастомизация — ну тут вообще зоопарк решений.
Проверка на дубликатов — настраивается.
Механизмы консолидации и т.п. — в данном решении не использовались.
На мой взгляд, правильнее было идти от процесса, а не от систем. Определить задачи, нереализуемые в текущем ландшафте, посмотреть, как из реализовать в имеющемся софте, а уж потом принимать решение — глубокая доработка либо внедрение MDM.
Часто доработать тот же SAP ERP проще и дешевле, чем внедрять MDM.
Если же целью было создание демо-стенда, то лучше было подобрать более релевантный сценарий.
Ну я не навязываю никому наш сценарий. Есть люди, которые выбирают глубокую доработку, а есть, которые выбирают готовые решения. У того и другого подхода есть свои плюсы и свои минусы.
Я написал в статье, что нам не хватало в CRM. В первую очередь это управление данными. Что называется Data Governance. В отличие от MDM, CRM обычно мало чего предоставляет для этого. DQ и прочие механизмы нормально представлены только в MDM. Опять же я не говорю обо всех вообще MDM или CRM. Понятно, что есть хреновые MDM, а есть CRM, где реализованы в полном объеме функции CDI.
Что еще не хватало — это ведение информации по клиенту/проекту. У нас довольно много информации агрегируется и анализируется потом. Объем и структура этих данных постоянно меняются. В MDM удобно вести как сами данные, так и версионировать изменения структур.
Я написал в статье, что нам не хватало в CRM. В первую очередь это управление данными. Что называется Data Governance. В отличие от MDM, CRM обычно мало чего предоставляет для этого. DQ и прочие механизмы нормально представлены только в MDM. Опять же я не говорю обо всех вообще MDM или CRM. Понятно, что есть хреновые MDM, а есть CRM, где реализованы в полном объеме функции CDI.
Что еще не хватало — это ведение информации по клиенту/проекту. У нас довольно много информации агрегируется и анализируется потом. Объем и структура этих данных постоянно меняются. В MDM удобно вести как сами данные, так и версионировать изменения структур.
DQ в MDM все-таки в зачаточном состоянии, у того же САПа или Информатики рекомендуется использовать для этих целей отдельное ПО.
Если модель данных часто меняется, то видимо надо где-то посмотреть и понять, почему так происходит. Все-таки мы ведем условно-постоянные данные, если про MDM говорим. На одним из моих недавних проектов (достаточно крупная международная компания, в первой тройке на рынке) добавление новых полей происходило с частотой 2-3 поля в год по всем управляемым объектам, включая транзакционные данные. И связано было с расширением функционала.
Если модель данных часто меняется, то видимо надо где-то посмотреть и понять, почему так происходит. Все-таки мы ведем условно-постоянные данные, если про MDM говорим. На одним из моих недавних проектов (достаточно крупная международная компания, в первой тройке на рынке) добавление новых полей происходило с частотой 2-3 поля в год по всем управляемым объектам, включая транзакционные данные. И связано было с расширением функционала.
У Информатики и других MDM-вендоров DQ — частенько продается отдельно. Можешь покупать, можешь нет. Но для управления мастер-данными в целом DQ — критически важный механизм, равно как и ETL или ESB. Я бы не стал у себя внедрять управление мастер-данными без этих механизмов.
А по поводу изменения структуры. Это у референс-данных структура условно-постоянная. У мастер-данных она живая и меняется довольно часто. Именно поэтому MDM-системы уделяют версионированию данных и версионированию структур данных такое большое внимание.
А по поводу изменения структуры. Это у референс-данных структура условно-постоянная. У мастер-данных она живая и меняется довольно часто. Именно поэтому MDM-системы уделяют версионированию данных и версионированию структур данных такое большое внимание.
Цитата: «правильнее было идти от процесса, а не от систем».
Это значит, сначала узнать, что Заказчик хочет дом из «круглых кирпичей» (как у него до автоматизации БП часто и выглядит), а потом вы вместе начинаете искать среди готовых решений «круглокирпичные». И понятно, что не находите и совместно соглашаетесь на «потом доработать напильником». (уже, наверное, понятно, что тут я не согласен с вашей цитатой) Имхо, стоит всё же показывать/пояснять, как на текущих предлагаемых ИТ решениях и их возможностях можно выстроить БП без внесения в них изменений и что менять, как ни крути, нужно и придётся. Иначе (если снять розовые очки и оценить все риски), чем крупнее Заказчик, тем острее он чувствует, что где-то его всё-таки «поимели» (не видя полного желаемого результата) и начинает выкручиваться из ситуации уже финансово (способов — масса, вплоть до не заплатить совсем или вернуть частично или все деньги — будет зависеть от степени «обиды» и жадности клиента).
Это значит, сначала узнать, что Заказчик хочет дом из «круглых кирпичей» (как у него до автоматизации БП часто и выглядит), а потом вы вместе начинаете искать среди готовых решений «круглокирпичные». И понятно, что не находите и совместно соглашаетесь на «потом доработать напильником». (уже, наверное, понятно, что тут я не согласен с вашей цитатой) Имхо, стоит всё же показывать/пояснять, как на текущих предлагаемых ИТ решениях и их возможностях можно выстроить БП без внесения в них изменений и что менять, как ни крути, нужно и придётся. Иначе (если снять розовые очки и оценить все риски), чем крупнее Заказчик, тем острее он чувствует, что где-то его всё-таки «поимели» (не видя полного желаемого результата) и начинает выкручиваться из ситуации уже финансово (способов — масса, вплоть до не заплатить совсем или вернуть частично или все деньги — будет зависеть от степени «обиды» и жадности клиента).
Ну если для вас проводить обследование значит поверить заказчику на слово («дом из круглых кирпичей»), а не вникать в суть проблемы («нужен дом без углов в соответствии с принципами феншуя»), то кто ж виноват в этом? Хотя чем крупнее компания-внедренец, тем чаще именно так и происходит.
С тем, что по всем вариантам надо детально и на пальцах показывать возможные последствия, думаю никто не будет спорить.
С тем, что по всем вариантам надо детально и на пальцах показывать возможные последствия, думаю никто не будет спорить.
Вам интересно будет узнать, что я в такой крупной компании выполнял роль руководителя проекта от Заказчика и как раз был инициатором, в частности внедрения MDM. Другими словами, с одной стороны я выступаю на стороне Заказчика перед Подрядчиком, а с другой, я точно также, как и Подрядчик нам, полноценно сдаю результаты проекта своему руководству (а не просто прикрываю ему задницу и выполняю его KPI, чем грешат многие другие — одна из главных, имхо, причин всех плохих проектных результатов). Так вот, бороться «с круглыми кирпичами» приходилось уже мне самому и сложившимися у нас БП (здесь, кстати, очень важен размер своего административного ресурса в компании-внедренце), когда я сам разобрался и понял, каким «это должно стать». И честно признаюсь, борьба шла во многом не в мою пользу. Так что, сложившаяся рыночная ситуация, когда Подрядчики спешат «продать коробку», а не получившие желаемого Заказчики спешат «меньше или ничего» за неё заплатить — мне очень не удивительна. Полностью конструктивного диалога между П. и З. — не происходит (но мог бы).
Дополнительно, тайминги по шагам согласования MDM также не покажет. И не каждый workflow.
В типовых продуктах 1С также давно (лет 5 точно) реализовано 2 сущности — контрагенты и партнеры, причем они могут быть связаны как один контргаент — один партнер, один контрагент — несколько партнеров (сеть розничных магазинов), несколько контрагентов — один партнер (описанный в статье и самый частый случай — несколько юрлиц в лице одного предприятия)
Спасибо за вопрос. Ждал его :)
В 1С эти сущности действительно абсолютно правильно разделены (правда только в 2 конфигурациях — УТ11 и ERP2). Но при этом существует много сложностей для использования их в таком режиме, о котором я пишу в статье.
1. Само по себе наличие этого разделения ничего не добавляет в части повышения продаж и Знания своего клиента, т.к. все как обычно упирается Data Governance или по русски — политику управления данными. Ну не дает УТ11 или ERP2 никаких вменяемых механизмов для этого. В больших внедрениях это просто не работает.
2. Сама по себе схема 1С довольно негибкая. По причине того, что Партер и Контрагент протягиваются во все операции и регистры. Если мы вдруг осознаем, что вот этот контрагент — это на самом деле другой партнер или вот этот партнер, это не один, а два партнера или наоборот, то вероятность того, что мы возьмем и перепишем все ссылки во всех операциях и регистрах стремится к нулю.
3. Не решена проблема с контактными лицами — персоны никак не выделяются. А для нашего бизнеса это даже важнее, чем клиенты.
4. Нет возможности гибко настраивать и вести множество данных по клиентам и проектам (механизм доп.реквизитов, простите, но не подходит :)))
В 1С эти сущности действительно абсолютно правильно разделены (правда только в 2 конфигурациях — УТ11 и ERP2). Но при этом существует много сложностей для использования их в таком режиме, о котором я пишу в статье.
1. Само по себе наличие этого разделения ничего не добавляет в части повышения продаж и Знания своего клиента, т.к. все как обычно упирается Data Governance или по русски — политику управления данными. Ну не дает УТ11 или ERP2 никаких вменяемых механизмов для этого. В больших внедрениях это просто не работает.
2. Сама по себе схема 1С довольно негибкая. По причине того, что Партер и Контрагент протягиваются во все операции и регистры. Если мы вдруг осознаем, что вот этот контрагент — это на самом деле другой партнер или вот этот партнер, это не один, а два партнера или наоборот, то вероятность того, что мы возьмем и перепишем все ссылки во всех операциях и регистрах стремится к нулю.
3. Не решена проблема с контактными лицами — персоны никак не выделяются. А для нашего бизнеса это даже важнее, чем клиенты.
4. Нет возможности гибко настраивать и вести множество данных по клиентам и проектам (механизм доп.реквизитов, простите, но не подходит :)))
А что мешало сразу сделать сущность с набором атрибутов вроде «группа» или «алиас» (в смысле "=то же самое"), которые и фильтры и аналитика уже сами обработают потом как надо? И уже сам конкретный атрибут для сущности и называть «контрагент»/«партнёр»/«контактное лицо» или ещё как вздумается.
Часто CRM-система не является отдельной системой, а входит в ERP-систему предприятия.
Вы точно в России работаете? А выборка какая у вас клиентов?
Ну и в принципе, большая часть того о чем вы пишете реализована в современных CRM. Причем давно.
Со стороны кажется как будто вы изобрели велосипед.
Расскажите, в какой из CRM-систем реализовано что-то большее, чем просто вот такая структура хранения? Какая из CRM поможет мне лучше, чем MDM собрать базу клиентов из разрозненных источников, причесать ее, поддерживать в актуальном состоянии? Какая из CRM поможет мне создать произвольные хранилища разнородной информации по разным аспектам проектов с динамически изменяемой структурой и т.д.?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«MDM vs CRM» или кто поможет больше продать?