С чего начать управление клиентскими данными в компании

Как повысить качество клиентских данных и ускорить их обработку? Такой вопрос встает перед IT-подразделением компании, когда ее клиентская база переваливает за миллион. Как правило, организации идут по одной из трех дорожек: самописное решение, покупка коробочного продукта у вендора или адаптация уже имеющихся в компании приложений под решение задач, связанных с клиентскими данными. Расскажем об особенностях и подводных камнях каждого из этих вариантов.

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

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

Решение, которое отвечает за управление клиентскими данными, относится к классу CDI (Customer Data Integration). Обычно от такой системы ожидают умение проверять и обогащать клиентские данные, собирать их из разных источников в одну карточку и формировать эталонную запись. CDI поддерживает и обратное распространение, когда чистые данные из эталонной карточки клиента поступают в другие системы. 

Адаптация имеющихся систем 

Обнаружив, что клиентская база нуждается в обработке, компании нередко решают пойти по самому простому, как им кажется, пути и «допилить» уже имеющиеся приложения. Задачи, которые обычно решает CDI, пытаются переложить на CRM, хранилище (DWH) или интеграционные шины (ESB) и ETL. 

Если говорить про CRM, то главная ее задача — управление взаимоотношениями с клиентами, а вовсе не качество данных. В архитектуре, где есть CDI, CRM выступает одним из источников и потребителей контактных данных, и информации о клиенте. Но несмотря на это, по данным Gartner, до половины бюджета проектов CRM тратится на борьбу с качеством данных, а больше половины неудачных проектов вызваны попыткой сделать из CRM систему CDI. Если компания начинает работать с качеством клиентских данных в CRM, это почти всегда означает увеличение штат дата-стюардов, допиливание программных интерфейсов, увеличение требуемых IT-мощностей. Бонусом становится возможность самостоятельно управлять самописным решением. 

Что касается хранилища (DWH), то его основная проблема в том, что решать проблему с качеством данных в момент их загрузки довольно сложно. А из некачественных сведений формируется некачественная аналитика. Кроме того, преобразования данных, сделанные ради загрузки в хранилище, никак не попадают обратно, в исходные системы. С точки зрения CDI, хранилище — одна из систем-потребителей информации. Как правило, хранилищу интересна информация о том, какие идентификаторы в каких исходных системах имеет каждый клиент.

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

Самописный CDI 

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

Если компания склоняется к такому пути, рекомендуем тщательно взвесить ресурсы команды. Так, в одном из банков в инхаус-разработке были задействованы 12 сотрудников: пять разработчиков, четыре аналитика и IT-архитектор. Они внедряли и развивали проект на протяжении четырех лет. Даже если предположить, что банк дополнил стандартный CDI дополнительными функциями из других областей MDM (давайте условно вычтем два года работы), то при самой скромной оценке проект обошелся ему примерно в 72 млн рублей. Такую цифру банк получил, сложив примерную заработную плату 12 сотрудников за пару лет (12*3 млн в год*2 года).

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

Вендорское решение

Делая выбор в пользу вендорского решения, компания получает продукт, специально созданный для работы с клиентскими данными.

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

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

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

• Политика лицензирования. Что случится, если количество записей, запросов, пользователей или ядер превысит оговоренное в лицензии? Как убедиться, что не превышен объем используемых лицензий? Каковы условия их продления и расширения? Есть ли ограничения? Иногда политика лицензирования привязана к количеству процессоров, и на этапе закупки компания может указывать небольшое их количество для снижения цены. При запуске в промышленную эксплуатацию может оказаться, что процессоров недостаточно.
• Необходимые мощности. Уточните, что делать, если их не хватит? Как решение масштабируется?
• Доработка и сопровождение продукта. Задайте вопрос вендору, кто может доработать ядро продукта и как быстро? Можно ли доработать продукт силами компании, и какие риски в этом случае могут возникнуть? От чего зависит стоимость поддержки? Какие SLA у вендора на исправление ошибок? Какие штрафные санкции? Как много времени понадобится, если ошибка возникнет в ядре продукта? 

Только получив внятные ответы на все вопросы и оценив результаты пилота, приступайте к реализации проекта вместе. Рассчитывайте, что он может занять от 3 месяцев до года. 

Автор: Михаил Берёзин, директор по продуктам HFLabs