Откуда приходят «кентавры», которые топчут клиентскую базу

На Geektimes вышла статья разгневанного клиента «Альфастрахования»: он увидел в своем личном кабинете чужие полисы и персональные данные.

В комментариях увлеченно обсуждают причины утечки.

В реальности ключи базы данных и разработчики не при чем: автор статьи наткнулся на типичного «кентавра». Так разработчики CDI-систем называют клиентские карточки, объединяющие данные разных людей.

Посмотрим, как эта проблема возникает и как ее решить.

Почему проблема не в базе данных

Если у офлайн-бизнеса с миллионами клиентов больше одного продукта, то клиентские данные гарантированно хранятся в разных IT-системах. У каждой своя степень заполненности, свой формат и качество данных.

Страховые ведут разные виды полисов в разных базах данных. Совместить в одной учетной системе ОСАГО и ДМС невозможно.

В банке кредиты и депозиты разносят в разные автоматизированные банковские системы (АБС). Кроме кредитов и депозитов у банка еще десятки продуктов.

В любой учетной системе, пусть компания хранит полисы или банковские счета, основной сущностью является продукт.

Оформляя при выезде за рубеж страховку, вы каждый раз создаете новую запись в учетной системе полисов ВЗР.

Никакой базы данных клиентов у крупного бизнеса попросту нет.

Что происходит, когда крупный бизнес становится клиентоориентированным

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

Мудрый бизнес не изобретает велосипед, а покупает профессиональное CDI-решение.

Чтобы условный Сергей Владимирович Иванов увидел все свои условные полисы в онлайн-кабинете, CDI-система делает следующее:

1. Собирает клиентские данные из всех IT-систем компании.
2. Приводит данные к стандартизированному виду.
3. Находит дубликаты клиентских записей.
4. Объединяет гарантированные дубликаты.

«Кентавры» зарождаются на шагах 3 и 4, с ними и будем разбираться.

Чтобы найти дубликаты, нужно понять, каких клиентов считать похожими.

Правила бывают простые: «ФИО, даты рождения и паспорт совпадают». Часто они намного сложнее: «ФИО похожи с вероятностью 70-80, хотя бы один адрес похож с вероятностью 90-100, даты рождения совпадают».

Набор правил зависит от специфики бизнеса, очень важно ее понимать. Например, свои «пакеты» условий мы собирали 12 лет и собираем до сих пор.

Часть правил «гарантированные» — найденные по ним дубликаты система объединяет автоматически.

«Негарантированные» дубликаты CDI-система отправляет на разбор дата-стюардам.

Дубликаты, которые система не объединила и отправила дата-стюардам, называются «серой зоной». Чем больше «серая зона», тем меньше порядка. Из-за нее компания даже не может посчитать клиентов, не говоря о более сложных вещах.

Сложнейшая задача при объединении дублей: подобрать порог «гарантированности» дублей. Он должен быть таким, чтобы все данные клиента слились в одну карточку, а однофамильцы и похожие личности остались снаружи. Здесь и появляется конфликт интересов.

В жизни CDI-проект — дело далеко не только техники. За внедрением и промышленной эксплуатацией IT-системы стоят люди. Они работают в разных отделах, у них разные задачи в компании, разные представления об идеальной картине мира. В конце концов, разные KPI.

Чисто техническая задача по внедрению и поддержке CDI-системы превращается в игру престолов и битву королей.

Из-за чего CDI-проект превращается в перетягивание каната

Первая задача CDI-системы — построить «золотую» базу клиентов. Но просто так от неё пользы мало, её нужно использовать. Бизнес-подразделения компании хотят это делать по-своему.

На решение влияет слишком много факторов, CDI-проект затягивается. Кажется, что правильного ответа нет.

Как правильно

Мы в HFLabs нашли, как решить проблему с порогом «гарантированности» и «кентаврами». Прежде всего нужно принять: никакого порога не существует.

Клиентские данные в любом бизнесе постоянно меняются: появляются новые продукты и процессы, подразделения и филиалы. Правила работы с дубликатами нужно менять вместе с ними. Не получится один раз все настроить и забыть.

Поэтому мы все время говорим с потребителями данных внутри компании-заказчика, выясняем потребности. Анализируем данные, изменения в них. Ищем закономерности и проверяем гипотезы на тысячах тестов. Если нашли ошибку, откатываемся на предыдущую версию и разъединяем объединенные карточки. А потом снова анализируем.

Чтобы поддерживать порядок в клиентских данных, нужно вкладываться каждый день. Иначе наступит хаос.

Другого рецепта качественной мастер-базы у нас нет.