Клиенты — это основной актив банка, и от
того, насколько точны и полны данные о них, зависит успех всего бизнеса.
ХМБ Открытие запустил проект «Единый клиент» для всех банков группы. О
его ходе и первых результатах «Б.О» рассказал Алексей Благирев, директор
по развитию систем аналитики и отчетности этой организации
— Алексей, проекты по
упорядочиванию клиентской базы вели многие финансовые
организации, включая Сбербанк, но не всегда успешно. Почему
в «Открытии» пришли к этому проекту именно сейчас?
— С переходом развития бизнеса
в плоскость интеграционных задач у нас возникла потребность
в качественном рывке и решении, которое смогло бы
синхронизировать ключевую клиентскую аналитику в
разрозненных системах и обеспечить ею все ключевые
бизнес-процессы банка. Мы выбрали единый подход по
управлению качеством, который состоял из трех ключевых
компонентов (доменов, так мы называем их): клиенты,
справочники и продукты. Вместе они создают ту основу, с
которой мы начали выстраивать единую модель по управлению
корпоративными данными и извлечения из них ценности. В банке
смотрят на данные, прежде всего, как на ключевой актив,
который создает ценность в бизнесе, и поэтому выстраивают
долгосрочную стратегию его развития и управления.
Мы начали с пилота, который
позволил выявить и измерить эффект от инвестиций в этот
проект. Получалось, что за счет выявления дублей
эффективность работы повысится на 33%. В первую очередь
повышается контактность. У нас есть различные «следы»
клиента, которые сохраняются в разных системах: мобильные
номера, адреса и т.д. Стоит отметить, что адреса не
проверялись по единым классификаторам РФ (например, КЛАДРу)
полноценно, и это была первая головная боль, которую мы
устраняли.
Система состоит из трех
компонентов, один из которых стандартизирует все, что
относится к значениям переменных о клиенте, то есть это
телефоны, адреса, окончания имен, отчеств, и он выявляет
определенные проблемы с этим. По сути, в пилоте мы
пропустили все клиентские записи через систему и показали,
сколько у нас в действительности клиентов. То есть
«отрезвили» бизнес реальными цифрами.
— Как вы позиционировали
преимущества проекта?
— Любая современная организация
представляет набор ключевых функций, которые, будучи
бизнес-центрированными, мало взаимодействуют и отчасти
конкурируют между собой. Обычно внутри банка нет брокера,
который консолидировал бы ценность с точки зрения
корпоративных данных, поэтому нам пришлось выступить этим
брокером.
Мы пообщались с командами
ключевых бизнес-направлений и выяснили влияние повышения
контактности на результат направления. Например, как
повлияет на сбор просроченной задолженности повышение
контактности на 1%. Помимо этого, привязка к адресу дает
GPS-координаты, и можно выстроить более качественную
логистику, то есть экономим на расходах по сбору
задолженности.
Для розничной команды это,
прежде всего, розничный конвейер, риски, сегментация и
экономия на телемаркетинге.
У нас единый домен, в котором
есть и юридические и физические лица, поэтому мы можем очень
качественно выявлять взаимосвязи между ними. Это позволяет
идентифицировать потенциальные зарплатные проекты.
В качестве дополнительного
форм-фактора в базе клиентов были выявлены домохозяйства,
которым мы теперь можем предлагать интересные банковские
решения. Муж, жена, дети, бабушки и дедушки — мы знаем все
эти взаимосвязи.
Мы также провели детальную
работу над обязательными полями, которые заполняются
клиентом в анкете на банковское обслуживание, и смогли
снизить ввод некачественной информации. Это важно, потому
что если у нас вводятся некачественные данные по клиенту, мы
фактически тратим деньги на запрос в НБКИ «вхолостую».
Вот так, по крупицам,
постепенно удалось встроить этот проект и заинтересовать
ключевых менеджеров участвовать в этом действительно важном
проекте.
Решение достаточно новое для
рынка и для банка, поэтому было проделано очень много работы
по продвижению этой системы внутри — мы провели много
воркшопов, демонстраций, индивидуальных встреч с каждым из
ключевых менеджеров. В итоге у нас организовалась регулярная
рабочая группа по управлению качеством данных, куда включили
представителей всех основных бизнес-линий. На этих встречах
мы принимаем решения: как двигаться в отношении единой
корпоративной стратегии по управлению данными.
— Сколько вы должны заработать
на этом проекте и за какое время?
— Наибольшая окупаемость
выходит за счет подразделения риск-менеджмента, потому что
именно там оптимизируются большие расходы. А сейчас
экономический тренд такой, что коллекторам придется много
работать, и качественные контактные данные просто
необходимы.
Повысить контактность, в
принципе, можно на 15%. Но при этом зависимость между
контактностью и сбором просроченной задолженности
нелинейная, у клиента есть дубли, и чистый эффект при
«схлопывании» будет 7–8%. Но все равно это существенная
сумма, которая окупает проект. Затраты четырехкратно
окупаются только за счет коллекшна.
Если говорить про следующий по
важности участок, то это идентификация подозрительных
операций. У нас был отдельный проект, когда мы центрировали
черные списки в единую систему справочников. Это отдельное
решение, но оно связано с «Единым клиентом» — система знает,
подозрительный клиент или нет, и АБС, обращаясь к «Единому
клиенту», может блокировать операции, если клиент
подозрительный. Те же функции интегрируются и в кредитный
конвейер — когда человек пришел в офис и подал заявку,
операционисты сразу же видят, подозрительный он или нет.
— То есть вы внесли в «Единого
клиента» клиентов всех банков группы?
— Нет, мы внесли только черные
списки.
— Почему вы не перенесли в
систему и всех остальных клиентов?
— Это следующий этап. У нас
идет активная работа с компаниями финансовой группы
«Открытие». Мы прорабатываем юридические аспекты
использования этого решения.
— Есть ведь и более продвинутые
системы идентификации мошенников — например, как в
Сбербанке, на основе фотографий. Один из видов мошенничества
— когда в паспорте переклеивают фотографию и затем на него
берут кредит.
— У биометрии большая
погрешность. Вот в Сбербанке сейчас внедрили «школу
будущего», там для идентификации используется отпечаток
руки. Погрешность по отпечатку руки — сотые доли процента.
Погрешность идентификации по лицу — до 3%. То есть мы можем
потерять 3% хороших клиентов.
— Лучше отказать 3%, чем дать
кредит мошенникам и потерять деньги.
— Не согласен. У меня есть
знакомый, который работает в достаточно крупной нефтяной
компании. Он хотел взять кредит, ему отказали. Он позвонил в
банк, и когда начали выяснять причину, оказалось, что
отказали не потому, что у него плохой кредитный рейтинг, а
потому, что система показала, что у него недействительный
паспорт. Видимо, здесь была ошибка во внешнем сервисе,
который предоставляет ФМС.
— Но это проблема не в системе
банка, а в сервисе онлайн-проверки паспорта через сервис ФМС.
Многие банки жалуются, что часто сервис не работает или
работает не так. При этом, даже если человек пришел с
полученной сегодня справкой, что его паспорт действителен, —
банк ему откажет, потому что у системы приоритет.
— Да, именно поэтому в
премиальном сегменте нужно принимать каждое решение
индивидуально. Ведь упущенный доход для банка может быть
достаточно большим. Ошибки в качестве данных могут привести
к печальным последствиям.
— «Единый клиент» как-то вязан
с AML?
— По AML в банке есть несколько
ключевых решений, которые мы сейчас перерабатываем. Это
будет совершенно новое решение, которое сможет выявлять
подозрительных лиц по сценариям с использование сценариев и
риск-стратегий.
— Как «Единый клиент»
интегрирован в IT-ландшафт банка?
— У нас позиция следующая: мы
выносим все механизмы качества данных из хранилища вовне,
чтобы управлять ими на уровне корпоративного ландшафта, то
есть управлять качеством на уровне банка в целом, а не
только на уровне хранилищ. При этом хранилище не может брать
персональные данные из других первичных систем, мы запретили
ему это делать — все эти данные хранятся только в «Едином
клиенте». Система содержит идентификаторы всех ключевых
систем, которые были интегрированы с «Единым клиентом»,
поэтому мы можем больше ниоткуда не брать клиентскую
аналитику, то есть для хранилища мы существенно сокращаем
точки интеграции.
«Единый клиент», который мы для
краткости называем CDI (Customer data integration),
представляет собой решение, обогащающее данные вне
хранилища. Он собирает данные из многих систем в реальном
времени, «перерабатывает» их и рождает портрет клиента.
Мы реализуем интеграцию решения
по двум отдельным направлениям: фронт-офис (CRM) и бэк-офис.
Так, фронт-офис в реальном времени обращается к CDI, чтобы
найти клиента и определить, есть у нас такой клиент или нет,
и запускает процесс верификации, а бэк-офис впоследствии
получает карточку клиента, которая уже совпадает с ЮДК.
— Как транзакции, операции,
продукты и т.д. связываются с клиентом?
— Это отдельное решение, так
называемая концепция модулярного кэша. Мы работаем над
системой, которая позволит связывать все эти компоненты и
снять нагрузку с бэка, чтобы эту связь можно было включать в
выписки мобильного банка, интернет-банка и использовать, в
том числе для хранилища. Пока это решение не завершено, и за
это у нас отвечает бэк.
— Если вы снимете нагрузку с
бэка, сохранится ли онлайн?
— Да, конечно. Есть решение,
которое позволяет это сделать in-memory.
— То есть вам придется купить
дорогостоящий in-memory appliance?
— Во-первых, он не
дорогостоящий. Во-вторых, мы сейчас разговариваем с
крупнейшими компаниями на тему того, что текущая модель
лицензирования более не- состоятельна. Мы не планируем
крупные CAPEX-платежи в сторону крупных вендоров, поэтому мы
пересматриваем модель сотрудничества.
— Хотите идти в облака?
— Нет, мы не рассматриваем
модель SaaS, нам интересна модель частного облака внутри
наших ЦОДов. Существует так называемая модель разделения
прибыли (revenue sharing), которая позволяет поделиться
частью получаемого дохода в случае, если проект совместный.
— Есть компании, которые уже
готовы так работать?
— Мы обсуждаем это с крупными
вендорами. У меня вчера была встреча с одним из
руководителей представителя крупного европейского региона, и
они заявили о готовности попробовать.
— От чего зависит сумма,
которой вы с ними делитесь?
— Модель еще не определена.
Если абстрагироваться от конкретного бизнеса, то revenue
sharing — это какая-то часть от того дохода, который можно
дополнительно получить, если технология будет применена.
— Но сначала надо этот доход
выделить.
— Понятно, что это не всегда
просто. Нам интересно, можем ли мы это попробовать. Сейчас
очевидно, что нет смысла говорить про огромный CAPEX, потому
что крупные платежи в условиях текущей экономической
ситуации несостоятельны. В принципе, эта модель была
несостоятельна и в прошлом, и в позапрошлом году, просто все
не хотели откровенно это признавать.
— Как «Единый клиент»
интегрировался с остальными системами?
— Мы выбрали два подхода: один
— для бэк-офисных систем и второй — для фронт-офиса. В бэке
все было достаточно просто. Самое сложное, что потребовалось
от всех участников банка, — понять бизнес-процесс,
описывающий, как мы работаем с нашим клиентом, и найти точки
оптимизации.
Прежде всего, определили
шесть-семь ключевых бизнес-процессов, то есть, по сути,
взяли цикл жизни клиента в банке — от момента его прихода к
нам (идентификации) до ухода по каким-либо причинам. Мы
стали рассматривать эти ключевые процессы и выявлять
реперные точки, куда можно встроить «Единого клиента».
Сначала процесс выглядел очень простым: фронт заходит в CDI
в момент появления клиента и автоматически проверяет, есть
такой клиент или нет. Дальше, в зависимости от ответа,
выполняются определенные действия. Потом происходит процесс
верификации, подтверждения клиентских данных. Мы
договорились, что в CDI данные мы забираем после того, как
определена их качественность.
В качестве интеграционного слоя
мы используем корпоративную шину данных, выкладывая в
очереди формируемые изменения.
— Как вы можете быть уверены,
что операционист, у которого появилось множество новых
обязательных полей, не забьет туда вместо данных условного
Иван Иваныча какое-нибудь «блабла», чтобы система от него
«отвязалась», и он быстрее смог оформить кредит?
— Во-первых, фронт-офис не
позволит это сделать, а если по каким-то причинам это
произойдет, то мы это сразу видим в реальном времени.
Во-вторых, внутри процесса есть люди, которые отвечают за
контроль, верификацию и качество клиентских данных. Кстати,
один из самых интересных моментов в проекте: мы создали
внутри банка группу дата-стюардов.
Для работы с данными, которые
попали в CDI в пограничное условие (то есть клиент непонятно
найден или нет), требуется ручной разбор и сверка с
юридическим делом клиента (ЮДК). Поэтому была сформирована
команда, которая полностью занимается работой с ошибками и
разбором пограничной зоны — некий аналог helpdesk только для
качества данных.
— На каком «железе» работает
вся эта система?
— Это обычные сервера среднего
уровня, то есть с точки зрения ТСО все достаточно экономно.
Мы распределяем нагрузку: частично стандартизация и
преобразование происходит внутри системы, преобразование на
уровне онлайн-интеграции ложится на шину данных, а часть
нагрузки приходится на уровень источников данных.
— Как строился проект?
— Первое, с чего начали, — это
выделение опытного менеджера для этого проекта. Основная
сложность была в формировании скоупа требований, а также
интеграции проекта в релизную модель развития источников со
стороны IT. Источники регулярно дорабатывались в релизном
цикле под требования бизнес-подразделений. Это поначалу
чем-то напоминало попытку запрыгнуть на постоянно
удаляющийся паровоз. При этом мы сами старались избегать
участия в релизной модели, прибегая к гибким методам
разработки (agile).
Модель развития IT была
сфокусирована вокруг обеспечения производственного цикла
релизов, поэтому, чтобы провести ту или иную интеграцию,
регулярно происходила балансировка ресурсов. Мы сравнивали
ценность от внедрения того или иного решения и выбирали
оптимальный вариант.
Формально проект стартовал в
апреле 2014 года. До этого был подготовительный этап —
описание требований, фиксирование единой модели данных.
Дальше начали строить интерфейсы, проводить интеграцию и
т.д.
У любого банка в ландшафте
присутствуют системы-динозавры, с которыми нужно провести
интеграцию. И на это обычно уходит большая часть времени,
так как не всегда ранее проработанные архитектурные подходы
могут сработать на месте. Например, мы планировали
использовать активный адаптер шины: шина сама обращается в
источник и забирает те данные, которые ей нужны. Ранее такая
технология в банке не применялась, поэтому возникал вопрос о
нагрузке на источники. Мы хотели использовать единый подход,
но по факту для устаревшей части ландшафта выбрали в итоге
более изящные решения, поскольку на практике этот метод
оказался малоэффективным. Первая фаза проекта была завершена
к концу октября (то есть на все ушло около полугода), и
интегрировали две ключевые системы обслуживающие юрлиц и
физлиц к CDI (на текущий момент систем уже девять).
— Система была внедрена вначале
в банке «Открытие»?
— Да, но завершили мы проект
уже в реорганизованном банке — «ХМБ Открытие». Решение
«Единый клиент» позволило нам пройти эту интеграцию
безболезненно.
— На сколько процентов
пересекались клиенты в разных банках?
— Мы сжали базу филиалов
приблизительно на 30%. Но во многом за счет дублей внутри
одного банка. Пересечение оказалось не очень большим.
— То есть на данный момент вы
слили вместе клиентские системы для Ханты-Мансийского Банка
и Банка «Открытие» и будете постепенно добавлять остальные
банки, организуя централизованную систему?
— Да, совершенно верно. Но это
касается только клиентских данных. Мы не хотели бы туда
заносить данные о транзакциях, сделках и т.д. Посмотреть
продуктовый профиль клиента можно в другом решении, которое
мы сейчас прорабатываем.
— Какие отзывы вы получили от
бизнес-подразделений?
— Сначала они не поверили, что
это случилось! Это же не просто «свет в комнате включили» —
требуется постепенное осознание того, что реальность
изменилась.
Мы запустили серию отчетности о
том, как выглядит наш клиент: например, его самый частый
день рождения, кто он по профессии и где живет, какой
уровень контактности и сколько удалось восстановить
телефонов благодаря CDI.
У всех большие планы. Частично
люди по-прежнему работают в некоторых старых схемах, как
привыкли, но это ненадолго.
— А почему вы не запретили им
это делать?
— Мы делаем это не сразу, чтобы
избежать революционной модели. Чем более органично
встраивается модель развития, тем крепче она будет в будущем
держаться в бизнес-процессе.
— При этом данные не
дублируются? В принципе, люди могут работать в разных
системах?
— Да, сама модель позволяет
организовать так называемую децентрализированную модель
управления качеством с помощью CDI. То есть система
работает, получая на вход как хорошие данные, так и полный
«мусор». Даже если подразделения совершают ошибки, вводят
плохие данные, мы их все равно улучшаем. Поэтому мы
постепенно начинаем налаживать с бизнес-подразделениями
процессы, которые позволяют снять с них нагрузку, попутно
улучшая качество.
Если сотрудник вбивает карточку
клиента руками, то теперь постепенно перестает это делать,
взамен получая данные из CDI. Так мы освобождаем время
сотрудника, которое можно использовать для решения других
задач. А заняться есть чем. Например, появилась возможность
сегментировать клиентов.
Первое, что сделали
бизнес-подразделения, — взяли все данные, которые мы собрали
о клиенте, посмотрели на них и наконец-то сформировали
список качественной информации, которая им нужна, чтобы
правильно определить сегмент. И сейчас на основании этих
данных мы будем создавать в лаборатории набор для
исследований, чтобы бизнес-пользователи смогли «поиграть» с
ним и построить на основе этого модель продаж.
bosfera.ru
23.04.2015
