Опыт создания DataHub для обеспечения операционными клиентскими данными сервиса ДБО

Илья Кучугин

Директор блока ИТ банк "Зенит"

За последние 10-15 лет ДБО из модного аксессуара превратилось в один из основных источников банковского сервиса, к которому клиенты предъявляют самые жесткие требования по скорости отклика, доступности, многообразию функционала. В передовых ИТ это способствует появлению новаторских идей и концепций, которые выходят за рамки принятого миропорядка. Об одной из них мы поговорили с Ильей Кучугиным, директором блока информационных технологий банка «Зенит».

Расскажите, пожалуйста, что вы вкладываете в понятие «передовое ИТ»?
Илья Кучугин: Удивительно, но факт — невозможно написать никакую внятную ИT-стратегию в отрыве от бизнеса. Все инициативы коммерческими подразделений в той или иной мере требуют оптимизации, модернизации или внедрения новых технологий, что определяет для ИТ другой уровень коммуникаций. Я считаю передовым такое ИТ, которое в общении с бизнесом оперирует не компьютерными терминами, вычислительными мощностями, системами хранения данных и топологией MSTP, а именно бизнес-показателями и тем, чем ИТ может помочь в их достижении. А вторая часть касается привнесения в организацию нового, что качественно меняет ее жизнь и лидирование этих изменений.

Какие перед банком «Зенит» в ближайшей перспективе стоят бизнесовые задачи, и как в их решении участвует ИТ?
И.К.: В ближайшей перспективе у нас удвоение активной клиентской базы в рознице, активизация кредитования малого и среднего бизнеса, изменение модели кредитования розницы. Это укрупненно стратегические направления. По сути, для ИТ – это внедрение двух разных кредитных конвейеров для розницы и МСБ и изучение внутренних систем на предмет того, способны ли они выдержать удвоение нагрузки, что нужно менять в инфраструктуре и подходах к интеграции. Ну, и плюсом к этим задачам завершение проекта, который мы делаем вместе с Unitarius, по созданию data hub – операционного хранилища данных, которое является сервисным слоем для бесперебойной работы ДБО.

Расскажите, пожалуйста, о предпосылках создания операционного хранилища данных.
И.К.: Их всего три. Основной предпосылкой, которая привела к созданию такого хранилища, стала довольно простая мысль: чем выше уровень автоматизации взаимодействия клиента с банком, тем ближе к внутренним процессам и системам становится клиент, а, значит, тем тяжелее нивелировать несовершенства этих процессов и этих систем. Поясню на примере. Вы принесли деньги в офис и хотите положить их на вклад. В банке практически может ничего не работать из ИT-систем, но у вас деньги примут, выдадут приходник, договор, и вы уйдете с ощущением оказанной услуги. А потом ночью ИT-специалисты будут судорожно пропихивать эти документы, чтобы все было хорошо и в дальнейшем. Это реальная правда жизни, и таких случаев много. Реализовать этот сценарий в ДБО нереально. Если у вас АБС банка, где учитываются вклады не работает, то ДБО вам не даст внести деньги на вклад, и вы будете от этого расстраиваться.

А нельзя наладить каким-то образом прямое взаимодействие между ДБО и внутренними системами, чтобы не было таких проблем?
И.К.: Технически, любые банковские системы требуют регулярного обслуживания, в течение которого система не доступна, и, если у вас напрямую организовано взаимодействие клиента через ДБО с этой системой, клиента в это время банк обслужить не может. В быту это проявляется сплошь и рядом. Например, мы сидим с вами в ресторане и нужно пополнить карточку со вклада или с текущего счета, чтобы расплатиться, а ДБО недоступно совсем, либо дольше, чем вы готовы ждать.

И это вторая предпосылка? Гарантированная доступность?
И.К. Да, а третья больше внутренняя, оптимизационная. Если у вас есть такой data hub, можно распределить нагрузку, которая идет извне на системы банка и которой вы никак не можете управлять, равномерно в течение суток. Как только у вас есть этот промежуточный слой и настроено правильным образом взаимодействие между АБС и операционным хранилищем данных, не имеет значения, сколько клиентов одновременно нагружает систему в пике или вообще за определенный период времени. И это очень важная вещь, которая позволяет не сильно вкладываться в апгрейд железа для ДБО, где оно тяжелое, большое и очень дорогое. Вот вкратце предыстория, для чего нужен промежуточный слой, который абстрагирует взаимодействие банка с клиентом от внутренних банковских систем.
Идею я уже давно вынашивал, но как-то не возникало точки, когда прям вот ее нужно реализовать, потому что именно такой подход к организации бэка для БДО оправдан экономически и технически. Раньше удавалось нивелировать недостатки прямых интеграций ДБО с АБС, а тут как раз все звезды сошлись, и хороший проект получился.

А есть альтернативные способы решения задачи, которую вы описали?
И.К.: Конечно есть. Альтернатива этому – обеспечение непрерывной работы 24/7 всех внутренних бэк-офисных систем банка. Много программного обеспечения, много железа.

Но это же очень дорого?
И.К.: Да, дорого, но чем не альтернатива. Тут весьма простая логика: любая операция клиента должна быть отражена в бэк-офисных системах банка. И тут, как говорится, есть 2 пути: либо обеспечить некий промежуточный слой, в котором беспрестанно крутятся данные для выполнения этих самых операций в моменте и который умеет дождаться завершения технологических перерывов и передать нужную информацию бэк-офисным системам, либо организовать работу бэка без простоев.

По сути, вы создаете некий цифровой двойник тех данных, которые лежат в конечных системах. К какому классу систем можно отнести это решение? Чем оно отличается, к примеру, от классического хранилища?
И.К.: От классического хранилища принципиально отличается скоростью, с которой туда попадают данные, и принципами хранения. Вместо периодической загрузки данных по некому расписанию и временного гэпа с по их готовности, у нас молниеносный онлайн. Это, наверно, ближе к классу систем высокоскоростных баз данных, идеологически похоже на in-memory.

Но при этом именно технологии in-memory вы не используете?
И.К.: Да, нам пока по объему это не нужно. Все-таки in-memory базы данных рассчитаны на сверхбыструю передачу данных. Вообще эта идеология и развивалась от web-приложений, когда большое количество клиентов одновременно запрашивает данные. Просто до определенных размеров не нужно использовать этот технический инструмент, а вот подход и идеологию — вполне себе можно.

Есть ощущение, что описанное вами можно смело назвать новой концепцией банковского IT. Раньше господствовала на рынке АБС. Потом, когда появились системы, ориентированные на клиента, а не только на соответствие требованиям ЦБ и хранение информации, ее значимость. Теперь, исходя из вашей концепции, конечные системы станут «чуланом», куда нужно просто вовремя отгрузить данные, а вот вся «движуха» будет происходить как раз внутри этого слоя операционных данных, о котором вы рассказывали. И это фактически сведет к минимуму значимость конечных систем, включая АБС. Чувствуете ли вы себя неким новатором и человеком, который участвует в трансформации, я бы даже сказала отрасли, а не только конкретного банка?
И.К.: Решения по организации data hub с теми целями и задачами, что я ранее описал, действительно никто не делал. И, если поразмышлять, то этот проект вполне может претендовать на инновацию. Другое дело, что мое мироощущение строится на глубокой практичности, и я решаю вполне конкретную и земную задачу, а не ищу самый оригинальный и новаторский путь. Тем не менее, для меня этот процесс оказался интересным, увлекательным и технологичным. И я полностью с вами согласен, что реализованный нами подход достаточно новый для банковского рынка.

Представьте, что вы прочитали об этой идее в журнале или услышали на конференции, она бы вам показалась достойной внимания? Как бы вы ее оценили?
И.К.: Я бы сказал, что это круто! Мы в «Зените» и правда сделали большой шаг в сторону того, что все декларируют, но куда еще мало кто реально ходил. Я про идею свести АБС только к учетным функциям и не работать через нее с клиентами.Я знаю, что были предприняты попытки реализовать это на уровне CRM-систем, но не очень, если честно, они удались. А использование data hub позволяет реализовать микросервисные подходы хоть в отношении АБС, хоть любой другой конечной системы.
На этой теме, собственно, многие банки очень сильно накалываются, потому что побежали в микросервисную архитектуру на радостях, уперлись в монолит АБС с требованиями ЦБ, узнали, что еще года 3 новую АБС писать, чтоб микросервисы взлетели, и расстроились. И промежуточный слой в виде операционного хранилища данных и окутывание микросервисам выглядит островком здравомыслия во всей этой технологической неразберихе и бессмысленных упражнениях с переписыванием АБС.

Вы сказали, что не получилось у банков, которые пытались обойти ограничения АБС с помощью CRM, как вы думаете, почему?
И.К.: Скорее, вопрос не в сложностях реализации, а в дальнейшей поддержке получившейся ИТ-конструкции. У АБС и СRM разные модели разработки. CRM и все передовые системы – это действительно микросервисная архитектура, слабосвязанные сервисы, DevOps, а большинство АБС – это монолитные гири, в которых очень долгие, трудные и дорогие изменения. Это, на мой взгляд, основная причина.

То есть, монолитное наследство не дает микросервисам летать, как они задуманы?
И.К.: Если микросервисы никак это монолитное наследство не затрагивают, то они хорошо летают. А вот как только зацепятся, то уже взлететь не могут.

Правильно ли я понимаю, что операционное хранилище, по сути, содержит в себе все данные, которые нужны для клиентских операций. В него же можно встроить, например, кредитный конвейер или любые системы, так или иначе ориентированные на потребление клиентских данных?
И.К.: Чисто теоретически – да. Можно туда посадить все: и кредитный конвейер, и фронт-офис. Нужно ли это все делать в операционном хранилище или организовывать распределенное хранение и обработку информации – вопрос непростой и дискуссионный.

А в чем сложность пускать все клиентские сервисы через ОХД? Это с идеологической точки зрения или с технологической сложно?
И.К.: Технических ограничений нет. Скорее, это из области здравого смысла. В CRM, например, есть развитый и очень правильный функционал по хранению информации взаимодействия с клиентом: какие предложения мы делали, на что он согласился, от чего отказался, кто у него родственники. Так вот надо ли это заново реализовывать этот функционал в операционном хранилище либо можно взять готовую CRM-систему и интегрировать с ОХД, получая из ОХД только необходимые данные, – это как раз вопрос дискуссионный.
Я считаю, что эффективней использовать сильные стороны существующих систем, а не увлекаться тотальным переводом всего в микросервисную архитектуру путем переделывания или «допиливания».

Я правильно понимаю, что при этом Data Hub может стать для CRM источником данных?
И.К.: Конечно. И источником данных, и приемником информации о проведении клиентских операций также, как для ДБО, например. Это вполне правильный, на мой взгляд, путь развития. Если бы мы реализовывали задачу автоматизации фронт-офиса, то я бы таким путем шел. В CRM из data hub передавал бы данные об остатках и сделках клиента, а в обратную сторону — информацию о ротациях клиента, которые он делает в офисе.

Вы рассказали предысторию и концепцию проекта. Расскажите, пожалуйста, о результатах. Как вы их оцениваете и что планируете делать дальше?
И.К.: Оцениваю положительно. На текущий момент работают информационные сервисы, так что всю нужную информацию ДБО забирает из data hub и показывает клиенту. Сейчас мы вместе с Unitarius работаем как раз над процессом проведения клиентских операций через ОХД в АБС. Параллельно выросли потребности вокруг карточного фронт-офиса, кредитных конвейеров, в решении которых мы легко можем переиспользовать уже готовые сервисы data hub.В конечном счете эти активности скажутся на качестве клиентского опыта. Мы хотим от продуктового подхода перейти к комплексной работе с клиентом. Например, клиент просит потребительский кредит, в он по каким-то параметрам нам не подходит. При продуктовом подходе мы ему отказываем и точка, а при клиентоцентричном – ищем способы удовлетворить его потребность, например, предложив карту или кредит под залог недвижимости. Вот это и требует полного пересмотра кредитного процесса и технологий принятия решения, т.е. там много всего.

Расскажите, пожалуйста, как вы искали технологического партнера? Почему выбрали Unitarius?
И.К.: На верхнем уровне выбор состоит из 2 возможных опций: пишем сами или покупаем коробку и адаптируем. У нас очень сильные ребята в подразделении рисков в качестве постановщиков задачи. У них очень правильные подходы, и я понимаю, чего они хотят от кредитного конвейера. Идею с коробкой мы быстро откинули, потому что она их ограничивала. А дальше мы пошли свои путем и определились с целевым стеком, где основная роль отводилась BPM. И тут удачно совпало, что в Unitarius активно ведется разработка платформы xBPM, стек и идеология которой совпадают с нашей целевой архитектурой и видением. Мне кто-то из коллег порекомендовал компанию, и когда потребность окончательно созрела, весь пазл и сложился. По поводу того, как компания работает, скажу – бывают накладки, куда уж без них в ИТ-проектах, но мне нравится очень сильная архитектурная компетенция и качество разработки.

Известно, что Unitarius специализируется на opensource с момента основания компании. Каково ваше отношение к ПО с открытым исходным кодом, изменилось ли оно с течением времени?
И.К.: Объективно качество продуктов, которые распространялись по модели opensource, было сильно ниже. Но за последние 10 лет мировое сообщество очень далеко продвинулось и из хайпа opensource стал конкурентоспособен на рынке. Если речь идет о собственной разработке, то оpensource здоровская вещь, которая позволяет сделать серьезные программные продукты. Очень дешево попробовать — это основная его прелесть, и основное конкурентное преимущество сейчас, на мой взгляд.

А вот насколько важно для разработчика специализироваться в конкретном оpensource?  Считается, что любой может разобраться. Это действительно так просто?
И.К.: Точно надо обладать головой и руками, никуда от этого не деться. Да, разобраться можно, вопрос в том, за чей счет это будет сделано. Если есть опыт, то мы понимаем, что уже этап пройден, а теперь мы используем полученные знания у себя. А вот, если этот процесс только начинается, то объективно будут проблемы.

А что вы думаете о ценности внешнего поставщика для заказной разработки? Внутри банков в общем-то есть и свои сильные команды…
И.К.: Ценность в быстром старте. Как бы не были отработаны HR-процессы, тяжело оперативно нанимать грамотные команды при открытии проектов. Сроки увеличиваются, потому что узнать, кого ты нанял, можно уже только в процессе. Поэтому, на мой взгляд, это объективно правильная тема, делать разработку с вендором, а потом в более спокойном режиме переходить на поддержку или развитие получившегося решения. Своими силами или с привлечением внешнего подрядчика — зависит от экономической целесообразности.

Оставьте заявку на консультацию!