Миграция на новое MDM-решение за одну ночь. Кейс «Ренессанс банка»

Некоторое время назад мы провели довольно сложную операцию по замене технологически устаревшей системы управления клиентскими данными (MDM) на новое MDM-решение «Единый клиент». В рамках данной статьи я хочу рассказать об основных предпосылках, задачах и вехах данного проекта.

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

«Единый клиент» — платформа от HFLabs, собирающая эталонные базы клиентов из различных систем заказчика (крупного бизнеса и органов власти). В рамках «Ренессанс банка» «Единый клиент» был интегрирован через микросервисы с системой дистанционного банковского обслуживания, кредитным конвейером, розничной АБС, CRM и другими системами банка.

Предпосылки перехода на новое MDM-решение

Главным драйвером перехода на MDM «Единый клиент» стали требования Центрального банка по формированию отчетности АСВ (Агентство по страхованию вкладов, Закон «О страховании вкладов в банках Российской Федерации» № 177-ФЗ), где требуется высокое качество клиентских данных. Для успешного формирования отчета АСВ необходимо, чтобы количество клиентов-дубликатов в банковских системах было близко к нулевым значениям. Кроме того, демографические и контактные данные клиентов должны быть актуальными и соответствовать государственным стандартам.

Внедрение нового решения позволило выстроить бизнес-процессы по работе с клиентскими данными в соответствии с поправками к законам «О персональных данных» (№ 152-ФЗ), «О государственной регистрации недвижимости» (№ 218-ФЗ), «О рекламе» (№ 38-ФЗ) за счет улучшения алгоритмов идентификации клиентов в продажах банковских продуктов, максимальной автоматизации процессов дедупликации (устранение избыточных копий) и деперсонализации клиентов, применения новых функций контроля действительности документов, удостоверяющих личность (ДУЛ) клиентов.

В России «Единый клиент» от компании HFLabs является одним из самых известных MDM-решений. На рынке MDM-систем присутствуют и другие и игроки, в том числе 1С: MDM «Управление нормативно-справочной информацией», «ЮниДата» — Платформа управления данными, НСИ «Semantic MDM».

Чем банковские методы работы с данными отличаются от других сфер

Требования к идентификации клиентов в коммерческих банках жестко регламентируются законодательством в отличие от других сфер экономики: торговли, образования, медицины, транспорта. В частности, банк должен соблюдать требования, изложенные в Положении Центробанка № 499-П «Об идентификации кредитными организациями клиентов, представителей клиента, выгодоприобретателей и бенефициарных владельцев в целях противодействия легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма». При этом для оптимального построения процесса продаж банковских продуктов и их сервисного обслуживания необходимы максимальная гибкость и расширенные возможности в поиске клиентов, изменении/редактировании их данных.

Преимущества MDM-системы (Master Data Management) для банков:

• MDM-система выстраивает процесс идентификации, поиска и редактирования данных клиентов так, чтобы соблюсти законодательные ограничения и предоставить бизнесу удобные варианты управления данными.
• MDM отделяет процесс создания и идентификации клиента от процесса поиска клиента, что позволяет предоставлять на выбор системам-потребителям штатные методы взаимодействия в целях получения искомого результата без доработок на их стороне или с минимальными доработками.
• Поиск в MDM возможен как по каждому отдельному атрибуту, так и по их совокупности.
• Мультипликатор поиска. Точность поиска повышается при увеличении набора атрибутов.
• Поиск доступен как по действующим, так и по потенциальным клиентам.
• «Машина времени». Поиск информации по клиенту на любую дату в прошлом.
• Идентификация клиентов в MDM работает по «гарантированным» правилам, использующим заданные группировки клиентских атрибутов, что позволяет найти клиента даже в случае, когда он умышленно не сообщает об имеющихся в банке договорах/счетах на другие (устаревшие) анкетные данные.
• Специальные правила слияния/обновления атрибутов клиентских данных в MDM защищают от сохранения в карточках клиентов ошибочных или некачественных данных.

Какой функционал должен быть у MDM-системы для банков

В нашем понимании эффективное MDM-решение должно включать возможность деперсонализации и группового изменения клиентских данных, использовать собственную базу и не требовать модификации систем-источников. Высокая результативность системы по управлению клиентскими данными напрямую зависит от ее производительности и отказоустойчивости. В связи с текущими требованиями к импортозамещению в части критической инфраструктуры необходимо, чтобы MDM-решение поддерживало не только СУБД Oracle/MSSQL, но и PostgreSQL.

Как мы разрабатывали требования к интеграционным потокам и модели данных

Для начала мы проанализировали и описали состояние текущих процессов, в которых используются клиентские записи. При проектировании интеграционного решения стремились уменьшить количество точек интеграции. Кроме того, мы учли необходимость реализации «обратного потока» — проброску измененной клиентской записи обратно в учетные системы. Также уделили большое внимание масштабируемости и производительности MDM-системы. Что касается набора клиентских атрибутов, как я упоминал выше, он должен быть гибким и конфигурируемым. Внедряемое решение должно иметь адаптированную для банковской сферы модель данных, спроектированную с учетом российской специфики.

О проектировании, тестировании и внедрении

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

Далее последовал этап разработки. При этом, как обычно происходит при крупных внедрениях, ввиду того что банк не мог остановить реализацию критичных задач, связанных с клиентскими данными, приходилось постоянно нагонять в новом решении те объемы изменений, которые реализовывались в старом. Лишь когда решение подошло к этапу тестирования, был объявлен «code freeze» на изменения в старом решении.

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

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

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

С учетом больших объемов данных (десятки миллионов клиентских записей) потребовалась отдельная процедура инкрементальной загрузки в новую систему, которую тоже пришлось реализовывать.

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

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

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

Читайте также:

Банковский сектор Азербайджана: взгляд со стороны клиента

Чек-лист: 8 шагов на пути к новому MDM-решению для банков

1. Определитесь с выбором: самостоятельная разработка или коробочное решение. Если вам нужно серьезное МДМ-решение и у вас нет нескольких лет и огромного бюджета — даже не думайте о самостоятельной разработке подобного продукта. Если вас удовлетворит ограниченная функциональность, и работа с клиентскими данными не является одной из ключевых частей вашего процесса — то вполне можно подумать о самостоятельной разработке.
2. Предусмотрите резервы бюджета и времени на изменения, связанные как с новинками законодательства, которые, скорее всего, появятся за время внедрения, так и с ошибками проектирования — на таких комплексных проектах они неизбежны.
3. Предусмотрите code freeze на этапе разработки и тестирования проекта для всех процессов, связанных с клиентскими данными, иначе вы постоянно будете отставать и никогда не внедритесь.
4. Тщательно проанализируйте бизнес-архитектуру и процессы, связанные с клиентскими данными. Потратьте время на разработку детальных требований, особенно в части потоков клиентских данных между различными системами.
5. Внедрение МДМ — проект, который стоит реализовывать по классической водопадной схеме. Ведь вам понятен результат, к которому нужно прийти, и не нужны эксперименты. Нужно всего лишь (казалось бы, как просто!) проработать детали и уложиться в сроки и бюджет.
6. Выделите максимально возможное время на проектирование и тестирование, а потом умножьте его на три. Процессы работы с клиентскими данными обычно сильно переплетены с другими ключевыми процессами организации, и при внедрении новой системы вам, по сути, нужно будет проверить их все для успешного результата.
7. Приготовьтесь внедрять методом «большого взрыва». Так как поддержка потоков клиентских данных одновременно в два решения по разным процессам, связанным с клиентскими данными, представляет собой довольно сложную задачу (нужна постоянная репликация), то одномоментное переключение является оптимальным решением. Разумеется, это накладывает дополнительные требования к этапу тестирования и контроля качества ПО (см. выше про умножение на три).
8. Отрепетируйте процедуру отката к старой MDM-системе. Для обеспечения безопасного внедрения необходимо заранее подготовиться к ситуации, когда не просто что-то пошло не так «после перерезания ленточки», а когда ваша поддержка и разработка не смогли справиться с проблемой в приемлемые для бизнеса сроки. Чтобы не «положить» бизнес организации окончательно, нужна комплексная процедура отката, а также полноценная репетиция оного. В случае необходимости откат должен быть выполнен быстро и без потери данных и функциональности.