Ведь CRM– это система управления отношениями с клиентами. Широко известно, что она из себя представляет, каким способом она позволяет поднять продажи; чего от неё стоит ждать, а чего –ждать не стоит. Часто CRM-система не является отдельной системой, а входит в ERP-систему предприятия.
MDM – это система управления мастер данными или нормативно-справочной информацией. Принято считать, что она предназначена для централизации управления мастер-данными, обеспечивает функциональные системы (CRM, ERP, WMS, TMS и прочие) непротиворечивыми и полными данными, которые нужны для формирования отчетности, выполнения бизнес-функций и т.п. Другими словами, MDM выполняет сервисную обеспечивающую функцию по сбору, централизованному хранению и распространению информации о мастер-данных. Но, на самом деле, это соответствует истине лишь отчасти.
Чтобы далеко не ходить за примером, приведу случай из жизни компании, совладельцем которой я являюсь (причем мне кажется, что этот пример является абсолютно типовым, и подобные ситуации встречались и у многих наших партнеров и клиентов).
Так вот, моя компания, занимаясь внедрением CRM и MDM-систем у своих клиентов, очевидно имела потребность как-то этих клиентов находить, заинтересовывать и продавать им свои продукты и услуги.
Исходно в компании была внедрена ERP-система, имеющая встроенную подсистему CRM, в которой и велась информация о контрагентах, их контактных лицах, возможностях продажи, прошедших и запланированных активностях и т.д. Система также имела BI-возможности.
При том, что работа менеджеров по продажам была полностью автоматизирована, тем не менее, имелись проблемы, из-за которых мы не могли сказать, что правильно управляем отношениями с клиентами.
Дело вот в чем. В нашей ERP-системе (равно как и в основной массе известных мне ERP-систем) данные о клиентах компании хранились в справочнике контрагентов, которые являются по сути не клиентами компании, а их юрлицами. Если у клиента имеются несколько юрлиц, то у нас в справочнике контрагентов появляются несколько записей. При этом все взаимодействия, возможности продаж, контактные лица, договорные отношения и все документы привязаны именно к контрагентам (то есть, к юрлицам и договорам). Таким образом, клиент как управленческая бизнес-сущность, которая интегрирует в себя все эти данные, в системе отсутствовала.
Аналогичная ситуация была и с контактными лицами. Один и тот же человек мог быть указан 10 раз как контактное лицо для 10 юрлиц, возможно, даже не относящихся к одному клиенту. В результате не было никакой связи этих 10 контактных лиц между собой, и мы просто не представляли, что на самом деле это один и тот же человек. Надо ли говорить, что контактная информация также была очень противоречива.
Кроме того, отсутствовал большой блок исторической информации, необходимой для понимания клиента, которую невозможно было перенести из старых систем по причине полного несоответствия структуры и контентного состава контрагентов и номенклатуры.
В результате мы зачастую не понимали, КТО НАШ КЛИЕНТ: чем он занимался и чем занимается сейчас, какую он имел и имеет структуру в организации, кто в нем работал раньше и работает сейчас, что ему предлагали, куда его приглашали, что и на какую сумму он у нас купил и т.д.
Без этой информации мы видели только «часть слона» и не могли нормально наладить отношения с клиентом. Таким образом, нам надо было научиться выделять клиента как бизнес-сущность и привязать все данные по клиенту к этой бизнес сущности.
Мы рассматривали разные варианты, но единственно возможным решением всех перечисленных выше задач стал вариант внедрения функциональности MDM-системы в домене CDI (Customer Data Integration).
Читатель спросит, а почему единственным? А почему нельзя было взять внедрить «навороченную» Аналитическую CRM, где есть возможность вести такую «централизованную» информацию по клиенту, и решить все перечисленные проблемы? Отвечу.
Использование MDM-функциональности для решения задачи Знания Своего Клиента имеет некоторые существенные плюсы.
Основной плюс MDM заключается в том, что обычно CRM-системы не имеют нормальных средств работы c данными по клиентам и инструментов нормализации этих данных. Данные собираются из разных систем, являются разрозненными, их надо идентифицировать, стандартизировать, обогащать, дедублицировать, синхронизировать и т.д. В MDM-системах есть механизмы работы с внешними базами данных (база ЕГРЮЛ, СПАРК), механизмы стандартизации адресов, ФИО, телефонов, е-мейлов. Без этих механизмов даже наличие функционала хранения этих данных в CRM-системе абсолютно бесполезно.
Еще существенный плюс MDM – это то, что MDM-системы позволяют довольно гибко настраивать структуру хранения данных о клиентах. В каждой компании данные о клиентах, которые она считает важными, сильно различаются. Например, в нашей компании ведутся данные обо всех программных продуктах клиентов, типах и сроках их поддержки, даже если они были куплены где-то в другом месте. Кроме того, мало хранить эти данные, нужно еще версионировать как сами данные, так и структуру этих данных, т.к. они сильно меняются со временем.
Также несомненным плюсом MDM-систем является то, что MDM-системы могут выявлять явные и неявные соответствия между физическими лицами, между организациями, между физическими лицами и организациями, а также их изменения. Можно прослеживать, кто, где, когда и с кем работал, кто кого знает. Также не секрет, что топ-менеджеры больших организаций у всех на виду и частенько меняют места работы. Эта информация должна выявляться, фиксироваться и создавать дополнительные возможности для продажи.
И четвертым, несомненно важным плюсом, стало наличие в MDM встроенных средств интеграции – ETL и ESB. Эти механизмы просто необходимы для сбора всех сведений о клиентах из разных систем-источников. Особенно в части возможности сопоставления данных из других источников с данными по клиентам.
Соответственно, с помощью MDM для CDI мы решили следующие задачи:
1. В кратчайшие сроки мы смогли преобразовать нашу схему, где центральной сущностью является юрлицо и договор, в схему, где центральной сущностью является клиент. Мы идентифицировали всех клиентов, связали с ними юрлица, договора, контактных лиц, документы и всю другую информацию.
2. Мы смогли выделить «персон», т.е. физических лиц, и связать их с контактными лицами клиентов. Теперь мы отслеживаем передвижения не контактных лиц, а конкретных персон: где они работают, куда переходят и т.д. Можем отслеживать неявные соответствия, кто кого знает, и кто с кем когда-либо работал.
3. Мы смогли создать гибкие и полные хранилища дополнительной информации по клиентам и персонам, которая требуется для продажи. В нашем случае это информация о проектах и их параметрах, информация об используемом программном обеспечении и т.д.
4. Мы смогли агрегировать данные из различных источников (например, из старой системы) и сопоставить их с текущими данными.
5. Мы обеспечили механизм ведения и поддержки данных о клиентах в актуальном состоянии.
Кроме всего вышеперечисленного, внедрение механизмов MDM сподвигло нас взглянуть на проблему более комплексно, чем когда мы внедряли CRM. Фактически под этот проект был инициирован еще один проект по созданию корпоративной политики регулирования данных (Data Governance). Но об этом можно написать еще одну большую статью.
Поэтому в нашем случае MDM – это не сервисная и обеспечивающая функция для других систем, а полноценная система, несущая свою вполне конкретную бизнес-функциональность для многих отделов:
1. Отдел маркетинга использует данные MDM для построения аналитических отчетов. Теперь фактически в едином источнике собраны все данные о клиентах: можно понять, сколько у нас клиентов, какие программные продукты они используют, какие проекты в каких отраслях и регионах были реализованы, какие параметры у этих проектов, все доходные и расходные показатели по клиентам и проектам. Это дает полную информацию для принятия стратегических и тактических маркетинговых решений.
2. Отдел телемаркетинга (кол-центр) использует данные MDM для обзвона и рассылки писем. Когда клиент не был выделен как центральная сущность, было много ошибок, когда звонили одному и тому же клиенту дважды и трижды (по количеству юрлиц). Кроме того, не было полной информации (агрегированной из разных систем), которая требовалась для сегментации клиентов и принятия решения о приглашении их на то или иное мероприятие или о предложении им тех или иных услуг. Теперь можно очень точно и адресно (без повторов и накладок) рассылать письма и обзванивать клиентов, что существенно уменьшает недовольство клиентов и экономит наше время.
3. Отдел продаж. Клиентский менеджер из отдела продаж теперь может получать всю информацию по клиенту в целом, что дает ему больше шансов предложить правильный продукт и грамотно построить стратегию продажи. Кроме того, теперь отдельно ведется мониторинг и поддержание связи с лицами, принимающими решения, когда они переходят в другие компании.
4. Производственные департаменты могут вести информацию о клиентах, их контактах и быть в курсе событий. А также формировать агрегированные данные о проектах для последующего анализа.
Меня многие коллеги-айтишники спрашивают, а как нам обосновать «бизнесу» необходимость внедрения MDM-системы? Ведь это техническая обеспечивающая функция. Так вот – нет, это вполне конкретная функциональная бизнес-система, которая сама по себе может принести колоссальную добавленную стоимость многим подразделениям.
И отдельно хочу оговориться, для тех, кто, может быть, не до конца меня понял:
1. Я не хочу сказать, что нужно внедрять MDM вместо CRM, я пишу о роли MDM в построении отношений с клиентами и о том, что эта роль вполне сопоставима с ролью CRM. Понятно же, что и в нашей компании CRM отлично функционирует, выполняя СВОИ функции.
2. Говоря про MDM как бизнес-систему, я не имею в виду, что бизнес-пользователи обязательно должны работать непосредственно внутри MDM (такое, кстати, тоже бывает, но не часто), я имею в виду, что бизнес-пользователи работают с функциями и данными MDM. У нас, например, все пользовательские интерфейсы реализованы внутри ERP, чтобы пользователю было удобно и не требовалось переключаться между системами, но все функции и данные – это забота MDM.
3. Я пишу про свой опыт и опыт многих компаний, которые сталкивались с такой задачей, и не исключаю, что в природе встречаются ситуации, в которых это не работает.
Максим Власов, директор по развитию
Комментарии (18)
CyaN
05.06.2017 14:52По крайней мере, в SAP, есть возможность применения более широких аналитик по контрагентам (BP) и ведения разного рода отношений. Хоть все склады, куда отгружать, заводи. Привязка через роли БП осуществляется. Так что проблема надуманная, и связана скорее всего с тем, что ERP выбиралась без учета реальных потребностей бизнеса, либо настроена перректально.
AXELOT-IT
05.06.2017 14:55Ну могу сказать, что проблема точно не надуманная, а реально присутствовала как минимум у нас. А на самом деле за наш долгий век автоматизации предприятий различного профиля присутствовала у доброй половины наших клиентов.
CyaN
05.06.2017 16:27Если в системном ландшафте только ERP и CRM, и между ними есть интеграция, то можно было выстроить процессы и потоки данных так, чтобы единой точкой ввода для данных о контрагентах был CRM. А процессы согласования и там можно настроить. Без внедрения MDM.
В вашем же варианте, количество систем увеличилось без особой необходимости. Да, продали MDM, молодцы. Это и было целью?
P.S.Это в случае, если CRM нормальный, а не студенческая поделка. Если же функционал CRM убогий, то получается ситуация, что клиент ССЗБ, сэкономив на CRM получил в нагрузку более дорогой продукт. Насколько я помню, практически у всех вендоров MDM лицензии одни из самых дорогих.AXELOT-IT
05.06.2017 16:44Данную схему реализовали для себя в нашей же компании, поэтому ничего никому продать цели не было. Была цель сделать хорошо. CRM смотрели разные, но нигде нет таких средств работы с данными, как в MDM. Кроме того, как я написал CRM у нас тоже есть и они замечательно друг-друга дополняют.
CyaN
05.06.2017 16:59Какие именно средства?
Workflow? он везде
DQ — так это и в MDM в зачаточном состоянии, есть отдельные продукты
Кастомизация — ну тут вообще зоопарк решений.
Проверка на дубликатов — настраивается.
Механизмы консолидации и т.п. — в данном решении не использовались.
На мой взгляд, правильнее было идти от процесса, а не от систем. Определить задачи, нереализуемые в текущем ландшафте, посмотреть, как из реализовать в имеющемся софте, а уж потом принимать решение — глубокая доработка либо внедрение MDM.
Часто доработать тот же SAP ERP проще и дешевле, чем внедрять MDM.
Если же целью было создание демо-стенда, то лучше было подобрать более релевантный сценарий.AXELOT-IT
05.06.2017 18:21Ну я не навязываю никому наш сценарий. Есть люди, которые выбирают глубокую доработку, а есть, которые выбирают готовые решения. У того и другого подхода есть свои плюсы и свои минусы.
Я написал в статье, что нам не хватало в CRM. В первую очередь это управление данными. Что называется Data Governance. В отличие от MDM, CRM обычно мало чего предоставляет для этого. DQ и прочие механизмы нормально представлены только в MDM. Опять же я не говорю обо всех вообще MDM или CRM. Понятно, что есть хреновые MDM, а есть CRM, где реализованы в полном объеме функции CDI.
Что еще не хватало — это ведение информации по клиенту/проекту. У нас довольно много информации агрегируется и анализируется потом. Объем и структура этих данных постоянно меняются. В MDM удобно вести как сами данные, так и версионировать изменения структур.CyaN
05.06.2017 20:04DQ в MDM все-таки в зачаточном состоянии, у того же САПа или Информатики рекомендуется использовать для этих целей отдельное ПО.
Если модель данных часто меняется, то видимо надо где-то посмотреть и понять, почему так происходит. Все-таки мы ведем условно-постоянные данные, если про MDM говорим. На одним из моих недавних проектов (достаточно крупная международная компания, в первой тройке на рынке) добавление новых полей происходило с частотой 2-3 поля в год по всем управляемым объектам, включая транзакционные данные. И связано было с расширением функционала.AXELOT-IT
06.06.2017 09:58У Информатики и других MDM-вендоров DQ — частенько продается отдельно. Можешь покупать, можешь нет. Но для управления мастер-данными в целом DQ — критически важный механизм, равно как и ETL или ESB. Я бы не стал у себя внедрять управление мастер-данными без этих механизмов.
А по поводу изменения структуры. Это у референс-данных структура условно-постоянная. У мастер-данных она живая и меняется довольно часто. Именно поэтому MDM-системы уделяют версионированию данных и версионированию структур данных такое большое внимание.
AlexTOPMAN
05.06.2017 19:39Цитата: «правильнее было идти от процесса, а не от систем».
Это значит, сначала узнать, что Заказчик хочет дом из «круглых кирпичей» (как у него до автоматизации БП часто и выглядит), а потом вы вместе начинаете искать среди готовых решений «круглокирпичные». И понятно, что не находите и совместно соглашаетесь на «потом доработать напильником». (уже, наверное, понятно, что тут я не согласен с вашей цитатой) Имхо, стоит всё же показывать/пояснять, как на текущих предлагаемых ИТ решениях и их возможностях можно выстроить БП без внесения в них изменений и что менять, как ни крути, нужно и придётся. Иначе (если снять розовые очки и оценить все риски), чем крупнее Заказчик, тем острее он чувствует, что где-то его всё-таки «поимели» (не видя полного желаемого результата) и начинает выкручиваться из ситуации уже финансово (способов — масса, вплоть до не заплатить совсем или вернуть частично или все деньги — будет зависеть от степени «обиды» и жадности клиента).CyaN
05.06.2017 19:57Ну если для вас проводить обследование значит поверить заказчику на слово («дом из круглых кирпичей»), а не вникать в суть проблемы («нужен дом без углов в соответствии с принципами феншуя»), то кто ж виноват в этом? Хотя чем крупнее компания-внедренец, тем чаще именно так и происходит.
С тем, что по всем вариантам надо детально и на пальцах показывать возможные последствия, думаю никто не будет спорить.AlexTOPMAN
05.06.2017 20:35Вам интересно будет узнать, что я в такой крупной компании выполнял роль руководителя проекта от Заказчика и как раз был инициатором, в частности внедрения MDM. Другими словами, с одной стороны я выступаю на стороне Заказчика перед Подрядчиком, а с другой, я точно также, как и Подрядчик нам, полноценно сдаю результаты проекта своему руководству (а не просто прикрываю ему задницу и выполняю его KPI, чем грешат многие другие — одна из главных, имхо, причин всех плохих проектных результатов). Так вот, бороться «с круглыми кирпичами» приходилось уже мне самому и сложившимися у нас БП (здесь, кстати, очень важен размер своего административного ресурса в компании-внедренце), когда я сам разобрался и понял, каким «это должно стать». И честно признаюсь, борьба шла во многом не в мою пользу. Так что, сложившаяся рыночная ситуация, когда Подрядчики спешат «продать коробку», а не получившие желаемого Заказчики спешат «меньше или ничего» за неё заплатить — мне очень не удивительна. Полностью конструктивного диалога между П. и З. — не происходит (но мог бы).
CyaN
05.06.2017 17:06Дополнительно, тайминги по шагам согласования MDM также не покажет. И не каждый workflow.
pelenur1
06.06.2017 09:58В типовых продуктах 1С также давно (лет 5 точно) реализовано 2 сущности — контрагенты и партнеры, причем они могут быть связаны как один контргаент — один партнер, один контрагент — несколько партнеров (сеть розничных магазинов), несколько контрагентов — один партнер (описанный в статье и самый частый случай — несколько юрлиц в лице одного предприятия)
AXELOT-IT
06.06.2017 10:59Спасибо за вопрос. Ждал его :)
В 1С эти сущности действительно абсолютно правильно разделены (правда только в 2 конфигурациях — УТ11 и ERP2). Но при этом существует много сложностей для использования их в таком режиме, о котором я пишу в статье.
1. Само по себе наличие этого разделения ничего не добавляет в части повышения продаж и Знания своего клиента, т.к. все как обычно упирается Data Governance или по русски — политику управления данными. Ну не дает УТ11 или ERP2 никаких вменяемых механизмов для этого. В больших внедрениях это просто не работает.
2. Сама по себе схема 1С довольно негибкая. По причине того, что Партер и Контрагент протягиваются во все операции и регистры. Если мы вдруг осознаем, что вот этот контрагент — это на самом деле другой партнер или вот этот партнер, это не один, а два партнера или наоборот, то вероятность того, что мы возьмем и перепишем все ссылки во всех операциях и регистрах стремится к нулю.
3. Не решена проблема с контактными лицами — персоны никак не выделяются. А для нашего бизнеса это даже важнее, чем клиенты.
4. Нет возможности гибко настраивать и вести множество данных по клиентам и проектам (механизм доп.реквизитов, простите, но не подходит :)))
AlexTOPMAN
06.06.2017 15:50А что мешало сразу сделать сущность с набором атрибутов вроде «группа» или «алиас» (в смысле "=то же самое"), которые и фильтры и аналитика уже сами обработают потом как надо? И уже сам конкретный атрибут для сущности и называть «контрагент»/«партнёр»/«контактное лицо» или ещё как вздумается.
Mimus_spb
06.06.2017 10:40Часто CRM-система не является отдельной системой, а входит в ERP-систему предприятия.
Вы точно в России работаете? А выборка какая у вас клиентов?
Ну и в принципе, большая часть того о чем вы пишете реализована в современных CRM. Причем давно.
Со стороны кажется как будто вы изобрели велосипед.AXELOT-IT
06.06.2017 11:14Расскажите, в какой из CRM-систем реализовано что-то большее, чем просто вот такая структура хранения? Какая из CRM поможет мне лучше, чем MDM собрать базу клиентов из разрозненных источников, причесать ее, поддерживать в актуальном состоянии? Какая из CRM поможет мне создать произвольные хранилища разнородной информации по разным аспектам проектов с динамически изменяемой структурой и т.д.?
AlexTOPMAN
Всё верно написано. MDM это основополагающая «система информационного порядка» в бизнесе. Когда «всё понял» — ясно, что именно с неё лучше и начинать автоматизировать бизнес. И тем не менее, почти все выбирают дорогу «граблей»: сначала автоматизируем «бардак», а после приходим к осознанию содеянного. Даже наглядный (в т.ч. инсайдерский) западный опыт, хоть и много чему учит, но «учатся мало» на нём.