Консолидация клиентской базы – цель или средство? Опыт одного внедрения

В то же время снижение операционных затрат и повышение эффективности могут быть достигнуты за счет внедрения CRM-решения: сократятся время и стоимость разработки маркетинговых программ и программ лояльности (ПЛ). Кроме того, уменьшение расходов достигается благодаря стандартизации и автоматизации процессов продаж, а продуманные сценарии взаимодействия с клиентом непосредственно на местах гарантируют повышение операционной эффективности.

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

Но даже если следовать этой стратегии, в ходе работы могут возникать негативные ситуации: клиенты получают низкое качество обслуживания из-за разрозненности и неполноты информации о них, поставщики и контрагенты сталкиваются с огромными издержками, например, в связи с потерей скидок от объема из-за ошибок в расчетах. Некачественные и недостоверные данные негативно влияют на характеристики отчетно-аналитической информации и, соответственно, на качество и своевременность принятия бизнес-решений, а ИТ не только несет большие затраты на устранение дублей в клиентской базе, но и часто срывает сроки запуска «тяжелых информационных проектов» по причине большого расхождения данных. Из этого следует вывод: правильная стратегия развития бизнеса может быть основана только на единой нормализованной и полноценной базе данных о клиентах (360 Degree View of the Customer).

Рис. 1. Принцип работы решения

Для повышения качества и обслуживания, и отчетно-аналитической информации, предназначенной для принятия оперативных управленческих решений, необходимо создание единой централизованной системы управления основными данными клиентов. Oracle Customer Hub (OCH) – это инструмент, который позволяет собирать и поддерживать полную, точную и достоверную информацию о них и передавать ее во все операционные и аналитические приложения. Это решение является частью комплекса продуктов компании Oracle по управлению основными данными компании (MDM – Master Data Management).

С точки зрения архитектуры OCH и Siebel CRM – части единой системы. Это позволяет быстро запустить проект по управлению основными данными и интеграции с другими бизнес-приложениями компании для создания единого представления о клиентах. Главный принцип работы комплексной системы заключается в следующем: при централизованном хранении основная информация извлекается из различных систем, гармонизируется, дополняется, уточняется и записывается в эталонное хранилище – OCH. При ее изменении, удалении или добавлении в любом из приложений обновленные данные из OCH отправляются подписчикам, т.е. системам, использующим эту информацию в своей деятельности.

Рис. 2. Использование базы данных CRM для Oracle Customer Hub

Подходы к внедрению

Существуют два варианта внедрения решения, которые различаются принципом размещения модуля OCH. Первый предполагает, что модуль внедряется поверх базы данных Oracle Siebel CRM, дополняя её структуры. В этом случае в одной системе совмещаются 2 функции: CRM и MDM.

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

Во втором случае для OCH создается отдельная база данных. И CRM становится потребителем/источником информации для модуля, как и другие внешние системы. Соответственно, CRM и MDM разделяются по отдельным БД (серверам).

Этот вариант предпочтителен, хотя и более затратен за счет необходимости дополнительных работ по развертыванию новой базы, настройке дополнительного обновления базы CRM и защите персональных данных. Однако его использование позволит сократить риск деградации производительности пользовательских приложений за счет разделения потоков запросов от пользователей CRM и внешних систем. А самое главное: при таком подходе не требуется изменение ни текущих процессов, ни существующих систем, что позволяет провести проект безболезненно для бизнес-пользователей.

Рис. 3. Использование отдельной базы данных для OCH

Проверка в действии

Не так давно наша команда создала консолидированную клиентскую базу в одном из российских банков, внедрив для этого OCH. Ниже мы приводим детали этого проекта.

До его начала в банке отсутствовали единые система и требования к данным о клиентах. Обмена клиентской информацией между удалёнными подразделениями не было, срезы данных отправлялись в головной офис на периодической основе, их очистка была предусмотрена в ограниченном функционале, а дедупликация производилась на основании неочищенных данных по упрощенному алгоритму, который не обеспечивал нужного качества.

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

На первом этапе проекта были загружены клиентские данные 6 филиалов банка, проведена оценка уровня их качества, выявлены основные проблемные зоны и предложены варианты решения. После этого были реализованы основные технологические механизмы интеграции, очистки и объединения.
На втором этапе (после сбора и анализа статистики) механизмы обеспечения качества данных были скорректированы, автоматические процедуры преобразования доработаны. Затем мы произвели загрузку данных клиентов из остальных филиалов. 
В ходе проекта была создана работоспособная технологическая платформа консолидированной клиентской базы, готовая к тиражированию и дальнейшему развитию. После постановки требований к обеспечению качества контроля ввода клиентских данных и согласования обновленной методики их обработки проект вступит в следующую фазу.
Создание клиентской базы стало фундаментом для успешной реализации таких проектов, как построение кредитного конвейера, ведение групп взаимосвязанных заемщиков, модернизация контакт-центра, Soft-Collection, полномасштабное внедрение CRM-системы.

Задачи и функции решения

Создание консолидированной клиентской базы было необходимо для сбора и поддержки полной, точной, достоверной информации о них и ее передачи во все операционные и аналитические приложения (более 70 источников/получателей информации). Объектом автоматизации являлись данные о клиентах, с которыми должны были осуществляться следующие действия: ввод, изменение, удаление, копирование, дедупликация. Итак, основные задачи системы – это создание и хранение мастер-карточек по клиентам, репликация информации, повышение качества данных, а также предоставление единого сервиса их поиска, получения и актуализации. Теперь поговорим о базовых функциях решения:

1. Первоначальная загрузка данных в OCH. Сначала вся информация для передачи в OCH выгружается из систем-источников, после этого «грязные» данные загружаются в решение Oracle, их очистку и дедупликацию осуществляет сторонний продукт. И наконец OCH выгружает очищенные данные и реплицирует их обратно в системы-источники.
2. Периодическое получение изменений из системы-источника в режиме offline. Процесс очень похож на предыдущий, но, в отличие от первоначальной загрузки, система выгружает только измененные данные.
3. Репликация изменений в системы-источники в режиме offline.
4. Для восстановления информации после сбоев в системах-источниках предусмотрен режим, в котором осуществляется выгрузка всех обновленных данных по конкретной системе (т.е. по клиентам, имеющим записи в ней).
5. Хранение истории изменений данных: например, из какой системы поступило то или иное изменение. Также сохраняются идентификатор сотрудника, инициировавшего обновление, и информация о том, были ли данные, которые находятся в мастер-карточке, изменены в процессе автоматической очистки.
6. Создание идентификаторов клиентов. Здесь все просто – каждой уникальной мастер-карточке присваивается свой номер.
7. Хранение справочника внешних систем и идентификаторов клиентов в них. В OCH существует справочник внешних систем, а также информация о том, с какими идентификаторами в каких системах-источниках есть записи об этих клиентах.

Oracle Customer Hub также осуществляет интерактивное взаимодействие с внешними системами. Например, возможна выдача клиентских данных по запросу бизнес-приложений. Когда система-инициатор отправляет запрос в режиме online с указанием параметров поиска, OCH ищет мастер-карточки, соответствующие им, и формирует ответ (возможно, несколько записей). В случае, если в OCH не нашлось мастер-карточек, указывается, что записей не найдено. При получении ответа в системе-инициаторе отображаются результаты поиска. Пользователь выбирает нужную карточку, и приложение отправляет еще один запрос в OCH с указанием ее уникального идентификатора. Результатом второго запроса являются данные мастер-карточки конкретного клиента. OCH ищет карточку, соответствующую указанному идентификатору и возвращает ответ, содержащий нужные данные, при этом OCH поддерживает поиск по историческим данным.

Мастер-карточка клиента также может изменяться по запросу из внешней системы. Сначала приложение отправляет запрос в режиме online с указанием ее идентификатора в OCH и изменяемых клиентских данных. При этом проверяется право системы на изменение каждого поля данных и производится очистка. Клиентские данные, которые можно автоматически скорректировать при очистке, обновляются и сохраняются в мастер-карточку. Информация, которую нельзя автоматически изменять по результатам очистки, сохраняется отдельно. После этого во внешнюю систему отправляется ответ с положительным результатом сохранения данных и информацией об итогах очистки.

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

Также необходимо упомянуть об основных сервисных функциях системы.

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

Во-вторых, возможна периодическая дополнительная очистка какого-либо параметра во всей БД. Ее необходимость может возникать, например, при изменении данных одного из справочников или правил очистки.

Качество данных

Стоит отметить, что основной проблемой при создании консолидированной клиентской базы в банке стало большое количество данных, требующих ручной обработки, – от 9 до 55% всех записей. Главные причины этого – их недостаточная стандартизация (в том числе при вводе в системы back-office), ошибки в загружаемых данных и слишком жесткие правила проверки в ОСН. Наиболее критичными зонами при анализе правил стандартизации в исходных системах оказались телефоны (короткие телефоны без кодов, ошибки в заполнении, перепутаны мобильные и городские) и адреса. В результате доработки процедур стандартизации в OCH и правил ввода информации в системы back-office количество необработанных данных значительно уменьшилось и достигло приемлемого уровня.

Таким образом, эффект от создания консолидированной клиентской базы можно разделить на 2 составляющие. Для бизнеса в краткосрочной перспективе он малоощутим, поскольку не автоматизируются важные, «продающие», бизнес-процессы. В то же время он становится ощутимым в средне- и долгосрочной перспективе, поскольку значительно повышается уровень обслуживания клиентов, а вместе с ним растет и прибыль. Поэтому, на наш взгляд, есть причины рассматривать такие проекты как средство для достижения поставленных целей. Для ИТ же результат ощутим сразу после запуска интегрированного решения в эксплуатацию, поскольку резко падают затраты на доработку и отладку приложений, использующих данные клиентов, например, системы аналитической и обязательной отчетности, CRM-системы и т.д. И можно рассматривать такой проект уже как самостоятельную цель. В любом случае выгоды от внедрения систем консолидации клиентских данных очевидны. Так важно ли знать – цель это или средство, если результаты говорят сами за себя?