В Сбербанке запущена система «Единый клиент Сбербанка» на базе IBM InfoSphere Master Data Management (MDM) Server с набором интеграционной логики и средствами первоначальной загрузки данных. Важную роль в реализации проекта сыграли специалисты компании «Аплана». На вопросы журнала «Банковские технологии» ответил Георгий Алексеевич Семянников, начальник отдела систем управления клиентскими данными ЦК Развития CRM Технологий Департамента развития аналитических решений и системных сервисов компании «Сбербанк-Технологии».
«Банковские технологии»: Георгий Алексеевич, давайте начнем с истории. Насколько мы поняли, проект по внедрению MDM-системы начался в 2010 г.?
Георгий Семянников: Да, в сентябре 2010 г. открылся проект по клиентам корпоративного блока, а розничное направление началось на год раньше. Я работаю в Сбертехе с октября 2011 г. на позиции начальника отдела, до этого работал руководителем проекта по корпоративному направлению. И тогда, и сейчас я курирую MDM-системы. Изначально мы занимались и клиентскими MDM-системами, и другими темами, например, продуктовыми справочниками, но сейчас локализовались на клиентских MDM-системах, клиентских решениях.
Проект начинался с «пилота», в процессе которого были усовершенствованы алгоритмы обработки, стандартизации и восстановления данных, разработан процесс контроля качества данных и ручной выверки данных, не подлежащих автоматической обработке. Обрабатывая эту базу, мы поняли реальные объемы и качество тех данных, с которыми придется работать.
На сегодняшний день система передана в промышленную эксплуатацию, мы собрали 100% информации по физлицам, а это больше 110 млн записей, почти все трудоспособное население России! По юридическим лицам собрано и обработано около 95% информации.
«Б.Т.»: Какие преимущества дает внедрение такого класса систем?
Г. С.: MDM — это система, которая позволяет построить единый профиль клиента для того, чтобы мы его могли использовать во фронтовых или в бэк-офисных системах или в качестве основы для проведения маркетинговых кампаний, а также для формирования отчетности.
Сбербанк, крупнейший банк России, обладает большим количеством источников данных в виде различных бэк-офисных и фронт-офисных систем, в каждой из которых ведется какая-то работа с клиентами. В одной системе сотрудник банка вводит информацию по клиентам Дальневосточного банка, касающуюся их депозитов. В другой системе вводится и обрабатывается информация по кредитам. В третьей системе — по ценным бумагам. В четвертой системе отслеживаются какие-либо сделки на инвестиционном рынке. И вся эта информация собирается в хранилище данных для построения правильной управленческой отчетности. Клиент, физическое или юридическое лицо, может быть уникальным или многоликим в каждой из этих систем. И чтобы понять, с кем мы работаем, чтобы понять, что один и тот же клиент обладает счетом, кредитом и такими-то продуктами, нужно эту информацию о клиенте собрать и сопоставить.
Только после этого мы сможем понять, что это Иванов Иван Иванович, или ООО «Ромашка», или крупнейший российский энергетический холдинг, включающий множество юридических лиц, которые входят в этот холдинг. Или, скажем, многофилиальная транспортная компания. Чтобы понять, что все филиалы к ней относятся, и, наоборот, разделить эти филиалы между собой и понять, что это не одна головная компания, нужно решить множество задач. Возможно, данные в различные системы вводились в разные периоды времени, в разных системах и разными людьми. В некоторых системах на каждый кредит открывалась новая карточка клиента. В других случаях сливались 2 территориальных банка. и клиенты «задваивались». К примеру. Московский банк собирался из 17 филиалов, и у нас наблюдалась картина, когда в кредитной системе было 17 одних и тех же клиентов. Это для банка было — да и сейчас остается — проблемой. Ее и решает MDM-система.
«Б.Т.»: Как именно она ее решает и какую информацию при этом использует?
Г. С.: Мы загружаем к себе информацию из различных источников и обрабатываем ее, Применяем алгоритмы стандартизации, нормализации данных. Например, возьмем адрес. Из одной строки разбираем его на город, улицу, дом, офис. Потом сравниваем это со справочником адресов России. Соответственно выставляем коды качества сравнения исходного адреса со справочником. Берем идентификационные атрибуты компании, если мы говорим о юридических лицах. Смотрим, верен ли ИНН, нужное ли количество разрядов, выполняется ли контрольная сумма.
Даже название компании бывает введено в разных местах по-разному. Где-то используется просто аббревиатура, где-то — название полностью, а где-то — с указанием формы собственности. Наша задача: выделить организационно-правовую форму, короткое название и полное. Потом система смотрит единый госреестр юридических лиц и индивидуальных предпринимателей, находит компанию там, проверяет ее атрибуты. Если они у нас неактуальны или введены с ошибками, предлагается эти данные восстановить. По результатам сравнения клиентских данных с реестром проставляются коды качества, на основании которых можно судить об уровне качества всей клиентской базы банка.
«Б.Т.»: Требуется ли участие человека?
Г. С.: В большинстве случаев не требуется, по крайней мере, по потоку ежедневных изменений. С подавляющим большинством задач система справляется в автоматическом режиме. Человек нужен только там. где сама система не в состоянии решить вопрос с конфликтом данных, где данных явно недостаточно или они введены с серьезными ошибками и не поддаются обработке с помощью алгоритмов, Например, когда название — от одной компании, а ИНН — от другой.
Вручную с таким потоком данных не справиться. Только по физическим лицам и ИП поток — более полутора миллионов изменений ежедневно. По юридическим лицам данных приходит меньше, но и цена ошибки там выше, поэтому именно по юридическим лицам у нас налажен процесс выверки данных с ручной обработкой, где система сама не справится. Этим занимается относительно небольшая группа дата-стюардов в Центре сопровождения клиентских операций.
«Б.Т.»: Давайте разберем на примере, как работает система. Вот, например, есть у компании адрес «в одну строку» — г. Москва, Проектируемый проезд № 4338, дом 8, корпус 1, офис 15. Система справится с обработкой такого адреса?
Г. С: Приведенный пример очень простой. Куда сложнее, если в адресе есть, помимо дома и корпуса, разнообразные владения, строения и т. д. Бывает и так: указано «офис с 1 по 15». В этом случае система обрабатывает эту запись и выдает ее с определенным кодом качества как требующую проверки. Возможно, юридический адрес будет восстановлен из иных источников, например из ЕГРЮЛ.
«Б.Т.»: MDM является единой точкой доступа к обработанным данным или она как-то взаимодействует с другими системами-поставщиками информации в обратном направлении?
Г. С.: Конечно взаимодействует! Данные по новым клиентам и изменениям транслируются в CRM-системы. Мы также отдаем этот «золотой профайл» для использования в центральном хранилище данных. Также бизнес использует эти данные для поиска клиентов и выдачи кредитов.
Мы не так давно достигли такого большого охвата, и различные потребители внутри банка должны убедиться, что все корректно, что мы данные не только не портим, но действительно улучшаем, что с ними можно работать. В перспективе же MDM-система будет являться единственным местом, где хранятся эталонные клиентские записи, и откуда все остальные системы смогут эти записи забирать.
«Б.Т.»: Можете рассказать вкратце о технических решениях, на базе которых вы строите MDM?
Г. С.: В основе — решение IBM InfoSphere Master Data Management Server. Эта система позволяет дедублицировать и обогащать информацию о клиентах путем сбора данных из первичных источников и сравнения с «золотой записью» клиента, используя при этом передовые технологии и методики.
За обеспечение качества данных отвечает Российский модуль стандартизации «Фактор». «Фактор» позволяет проводить стандартизацию и нормализацию клиентских данных. Основной особенностью системы является возможность обогащения клиентских данных информацией из справочников ЕГРЮЛ и ЕГРИП, КЛАДР и других.
Кроме того, в «Факторе» реализована система кодов качества, которая позволяет классифицировать данные по параметрам их качества, получать количественные характеристики проблем в первичных данных.
За первичную загрузку данных отвечает решение IBM InfoSphere DataStage, позволяющее производить пакетные загрузки данных из систем-источников.
В качестве корпоративной сервисной шины был выбран продукт IBM WebSphere Message Broker — система интеграции, обеспечивающая синхронизацию данных между MDM-системой и смежными системами.
«Б.Т.»: Но ведь мало выбрать решение, нужно его внедрить, а самое главное — настроить и описать правила и методики работы с ним...
Г. С.: Да, именно поэтому для реализации решения мы обратились к квалифицированным партнерам. По корпоративному направлению одним из основных подрядчиков с самого начала стала компания «Аплана». Их специалисты описывали и разрабатывали требования к нормализации, стандартизации клиентских данных и их очистке, правилам дедубликации данных, выполняли тестирование и оказывали консалтинговые услуги.
После того как процесс контроля качества данных был построен, командой «Апланы» была разработана технологическая схема процесса контроля качества клиентских данных корпоративных клиентов, обучены сотрудники и выверка данных была передана на сторону банка. В настоящий момент коллеги из «Апланы» осуществляют поддержку нашей команды и разрабатывают рекомендации по усовершенствованию процесса контроля качества данных, ведь проект еще не завершен.
Говоря простым языком, партнеры написали как инструкции для человека, занимающегося ручной выверкой данных, так и функциональные требования для самой АС: «если случилась такая-то ошибка, делай так». Это тяжелый труд, но без него создание MDM-системы невозможно.
«Б.Т.»: Каково ближайшее будущее MDM-системы Сбербанка?
Г. С.: В ближайших наших планах — проведение повторной стандартизации всей клиентской базы ЮЛ, что должно привести к резкому повышению качества данных. Постоянно ведется доработка правил автоматической дедубликации и стандартизации данных. Планируется подключение новых систем-источников к MDM, осуществление поисковых запросов из различных банковских систем к MDM, и в перспективе система, как я уже говорил, станет основным хранилищем клиентских данных. Несмотря на достигнутые результаты, нам еще предстоит очень много работы!
Банковские технологии, №05, 2015