Почему в Siebel CRM не получится вести единую базу клиентов
Однажды банк, страховая или мобильный оператор понимает, что в клиентской базе творится хаос.
В банках вклады живут в одной системе, а кредиты — в другой. Часто банк не знает, что у должника по кредиту на 70 000 ₽ открыт депозит на 20 000 000 ₽.
Страховые хранят в базах не людей, а полисы. Сколько раз человек оформил страховку, столько у него записей. В итоге компания даже не знает, сколько у нее клиентов.
Любой бизнес с сотнями тысяч клиентов страдает от похожих проблем.
При этом компании понимают, что нужна единая база всех клиентов компании. Эта база должна хранить контактные данные клиентов, их продукты и услуги. Только так можно анализировать результаты маркетинговых кампаний, увеличивать продажи и растить бизнес.
Казалось бы, есть специальные системы для управления взаимоотношениями с клиентами — CRM. Считается, что CRM решит и проблему построения единой клиентской базы. Это большая ошибка.
HFLabs 8 раз участвовала в проектах, когда самую популярную CRM для крупного бизнеса — Oracle Siebel CRM — пытались превратить в единую систему хранения клиентских данных. Эту сложную CRM компании-интеграторы внедряют по индивидуальным проектам за большие деньги. Ни разу это не закончилось удачно.
Мечта №1. Siebel CRM будет единой точкой ввода пользовательских данных
Перед внедрением Siebel бизнес мечтает, что CRM станет единой точкой ввода пользовательских данных. Процесс предполагается следующий:
- Один раз выгружаем данные из всех систем и приводим их в порядок.
- Загружаем единую базу в Siebel CRM.
- После этого данные вносим только в Siebel.
Кажется, что с новой архитектурой дубликаты больше не появятся. Изменения будут вносить в единственный источник — Siebel
На практике все получается намного сложнее, потому что компаниям приходится переделывать все свои учетные системы под загрузку данных из Siebel. Такие доработки тянутся годами.
Банк ведет счета́ клиентов в автоматизированных банковских системах (АБС). АБС может быть несколько десятков.
Из АБС банк выгружает отчеты для регуляторов. Ошибки в отчетах грозят штрафами и, что хуже, пристальным вниманием регулятора.
Банк вынужден дорабатывать все АБС, чтобы они получали и правильно применяли обновления от Siebel. Иначе получится, например, вот что:
- В CRM ввели адрес клиента с опечаткой.
- CRM прислала адрес с опечаткой в АБС.
- АБС заменила корректный адрес, который прописан в договоре, на вариант с опечаткой.
- Ошибка попала в отчет для регулятора.
Кроме этого, чтобы сделать из Siebel CRM действительно единую точку ввода, нужно учесть абсолютно все процессы, при которых происходит этот ввод. Для бизнеса с сотнями отделений и продуктовых направлений это неподъемная задача.
Данные о клиентах корпоративных программ страхования или зарплатных проектов передают в excel-файлах. Файлы обычно напрямую загружают в учетные системы, чтобы пакетно открыть счета или оформить полисы. В CRM они не попадают.
О такой мелочи забывают во время внедрения, в итоге данные идут мимо «единой точки ввода». В базе появляются дубли и некорректные данные, которые все портят.
Десятки проблем всплывают то тут, то там. Они превращают доработку IT-инфраструктуры в бесконечный проект.
В итоге проходят годы, компания пытается доделать проект, а Siebel CRM так и не становится единой точкой ввода.
Мечта №2. Siebel CRM станет интегратором клиентских данных
Когда компания понимает, что быстрой победы не получилось, она переходит ко второму шагу: пытается сделать из Siebel CRM систему-интегратор клиентских данных.
Тут надо сказать, что для интеграции клиентских данных существует отдельный класс IT-систем — CDI (customer data integration).
У Oracle есть решение Oracle Customer Hub, которое интегрирует клиентские данные.
Но CDI-системы дороги, а еще их нужно интегрировать в инфраструктуру. Пошаговые доработки уже внедренной Siebel СRM выглядят выгоднее, чем покупка новой системы.
Мы уже рассказывали, как сложно создать собственную CDI-систему. Сейчас же посмотрим, что бывает, когда Siebel CRM работает как интегратор клиентских данных. Каждая из этих проблем полита слезами клиентов HFLabs.
Siebel удаляет объединенные карточки из учетных систем.
У банка есть клиент — Василий Покупаев. Василий оформил два депозита в разных филиалах и один кредит.
Каждый филиал ведет депозиты и кредиты в своей АБС. Таким образом, в Siebel три карточки с Василием Покупаевым.
Чтобы избавиться от дублей, компания использует стандартный DataQuality-коннектор Siebel CRM. Через коннектор подключается внешний сервис качества данных HFLabs «Фактор». «Фактор» очищает и стандартизирует данные, а также ищет дубликаты.
«Фактор» отмечает дубликаты, а Siebel CRM их объединяет. Слияние выглядит так: одна карточка становится главной, Siebel наполняет ее информацией из остальных. Остальные же карточки удаляет.
Siebel знает только один способ удалить дубликаты — собрать всю информацию о клиенте в одну карточку, а остальные удалить
Проблемы начинаются, когда учетные системы обращаются к удаленным карточкам клиента. Поскольку система не находит карту, она создает новую.
Василий приходит в «Филиал 2» пополнить депозит. Заодно операционист добавляет в карту клиента адрес vasya@mail. ru.
АБС «Депозит 2» не находит карту Василия, потому что ее удалил Siebel. АБС создает новый профиль, записывает в него данные и передает в CRM.
Удаленные карточки после обновлений снова появляются в учетных системах как дубликаты, это бесконечный процесс. Если бы поиск дубликатов запускался часто и проходил быстро, с этим можно было бы жить. Но здесь всплывает другое ограничение.
Siebel CRM слишком медленно обрабатывает дубликаты. На 20 миллионов клиентов «Фактор» обычно находит несколько миллионов дубликатов. Siebel CRM не может их переварить из-за ограничений буфера и падает с ошибками.
Такое поведение свойственно CRM не только при работе с дубликатами, а при любой загрузке данных. Нам известно два способа обхода этого ограничения.
Чтобы Siebel обработал дубликаты и не сломался, придется искать их менее строго, жертвовать качеством. Или дорабатывать CRM под чтение дублей из файлов
У обоих способов есть недостатки.
- Первый вариант — загрузить только явные дубли. Например, указать в настройках Siebel значение похожести > 90%, и «Фактор» вернет такие пары. Дедупликация пройдет без ошибок, но ценой полного поиска дублей;
- второй вариант — не использовать для загрузки буфер Siebel. «Фактор» может сохранять результат дедупликации в файл. Но чтобы научить CRM читать такой файл, нужны доработки.
Оба способа увеличивают и без того долгое время дедупликации.
Среднее число дубликатов (до 1 миллиона) Siebel CRM обрабатывает несколько дней. Поэтому операцию проводят редко, а на больших объемах от нее вообще отказываются.
Siebel CRM не умеет разъединять карточки. Карточки объединяются не всегда верно, и в CRM появляются «кентавры» — карточки, слитые из разных клиентов.
Так может произойти из-за особенностей исходной системы и интеграции с ней.
У одного из наших заказчиков есть система, в которой операционисты иногда копируют существующие, чтобы не создавать новые.
Процесс выглядит так:
- Операционист копирует существующую карточку со всей информацией, чтобы завести нового клиента.
- Система передает данные в Siebel CRM, которая определяет её как дубликат и сливает.
- Операционист изменяет данные на новые, появляется кентавр.
После внедрения Siebel привычный операционистам сценарий работы начнет порождать дубли
Еще вариант — ошибка операциониста, когда он находит однофамильца нужного клиента и меняет данные. Ситуация хоть и редкая, но опасная.
Из-за ошибки при слиянии карточек клиент видит чужой депозит в своем интернет-банке. Что делать в таком случае?
Каждый раз, когда карточки нужно разъединить, компании обращаются в техподдержку интегратора Siebel CRM или придумывают костыли. Мы видели очень экзотические способы.
У заказчика есть Siebel CRM и система «1С». Объединять карточки внутри «1С» нельзя, так как это влияет на бухгалтерскую отчетность. То есть все депозиты условного Василия Покупаева должны быть разными карточками. При этом в CRM нужен единый клиентский профиль Василия.
Чтобы не создавать дубликаты в Siebel CRM после каждого обновления карточки в «1С», интеграцию организовали хитро. В отдельную таблицу записывают, кто и с кем был объединен. Если в какой-либо карточке внутри «1С» изменяют данные, интеграция проверяет, является ли эта карточка слитой. Если да, данные не отправляются в Siebel.
Если же какие-то клиенты были слиты в Siebel CRM по ошибке, то из таблицы удаляют информацию об их объединении. Тогда со следующим обновлением карточка снова попадает в Siebel как новая.
В Siebel не получится вести единую базу клиентов
Превращение Siebel CRM в единую точку ввода затягивается на годы и не приводит к желаемому результату. На старте компании не учитывают объем доработок существующих систем и затраты на перестройку процессов.
Доработка Siebel CRM до системы интеграции пользовательских данных — проект на несколько лет с непредвиденным результатом. С одной стороны, это внутренняя разработка под вашим контролем. С другой стороны, опасно брать на себя затраты и риски создания сложного самописного продукта, его поддержку, постоянное тестирование, доработку и развитие.
Есть и третий путь — использовать готовую CDI-систему. Например, «Единый клиент». В этом случае технические проблемы уже решены, а изменять процессы или останавливать работу критичных систем нет необходимости.
HFLabs внедряет «Единый клиент» за несколько месяцев.
В одном банке из топ-10 проект длился 8 месяцев — в феврале начали, в сентябре уже запустили в промышленную эксплуатацию.
В итоге Siebel CRM получит качественную единую базу клиентов и будет заниматься своей прямой работой — управлять взаимоотношениями с ними, чтобы вы зарабатывали больше.
