Last Updated on 2021-01-26 by admin
— Расскажите, пожалуйста, что вы вкладываете в понятие «передовое IT»?
— Удивительно, но факт: невозможно написать никакую внятную IT-стратегию в отрыве от бизнеса. Все инициативы коммерческих подразделений в той или иной мере требуют оптимизации, модернизации или внедрения новых технологий, что определяет для IT другой уровень коммуникаций. Я считаю передовым такое IT, которое в общении с бизнесом оперирует не компьютерными терминами, вычислительными мощностями, системами хранения данных и топологией MSTP, а именно бизнес-показателями и тем, чем IT может помочь в их достижении. А вторая часть касается привнесения в организацию нового, что качественно меняет ее жизнь и лидирование этих изменений.
— Какие перед банком «Зенит» в ближайшей перспективе стоят бизнесовые задачи и как в их решении участвует IT?
— В ближайшей перспективе у нас удвоение активной клиентской базы в рознице, активизация кредитования малого и среднего бизнеса, изменение модели кредитования розницы. Это укрупненно стратегические направления. По сути, для IT это внедрение двух разных кредитных конвейеров для розницы и МСБ и изучение внутренних систем на предмет того, способны ли они выдержать удвоение нагрузки, что нужно менять в инфраструктуре и подходах к интеграции. Ну и плюсом к этим задачам завершение проекта, который мы делаем вместе с Unitarius, по созданию data hub — операционного хранилища данных, которое является сервисным слоем для бесперебойной работы ДБО.
— Расскажите, пожалуйста, о предпосылках создания операционного хранилища данных.
— Их всего три. Основной предпосылкой, которая привела к созданию такого хранилища, стала довольно простая мысль: чем выше уровень автоматизации взаимодействия клиента с банком, тем ближе к внутренним процессам и системам становится клиент, а значит, тем тяжелее нивелировать несовершенства этих процессов и этих систем. Поясню на примере. Вы принесли деньги в офис и хотите положить их на вклад. В банке практически может ничего не работать из IT-систем, но у вас деньги примут, выдадут приходник, договор, и вы уйдете с ощущением оказанной услуги. А потом ночью IT-специалисты будут судорожно пропихивать эти документы, чтобы все было хорошо и в дальнейшем. Это реальная правда жизни, и таких случаев много. Реализовать этот сценарий в ДБО нереально. Если у вас АБС банка, где учитываются вклады, не работает, то ДБО вам не даст внести деньги на вклад, и вы будете от этого расстраиваться.
— А нельзя наладить каким-то образом прямое взаимодействие между ДБО и внутренними системами, чтобы не было таких проблем?
— Технически любые банковские системы требуют регулярного обслуживания, в течение которого система недоступна, и, если у вас напрямую организовано взаимодействие клиента через ДБО с этой системой, клиента в это время банк обслужить не может. В быту это проявляется сплошь и рядом. Например, мы сидим с вами в ресторане, и нужно пополнить карточку с вклада или с текущего счета, чтобы расплатиться, а ДБО недоступно совсем либо дольше, чем вы готовы ждать.
— И это вторая предпосылка? Гарантированная доступность?
— Да, а третья больше внутренняя, оптимизационная. Если у вас есть такой data hub, можно распределить нагрузку, которая идет извне на системы банка и которой вы никак не можете управлять, равномерно в течение суток. Как только у вас есть этот промежуточный слой и настроено правильным образом взаимодействие между АБС и операционным хранилищем данных, не имеет значения, сколько клиентов одновременно нагружает систему в пике или вообще за определенный период времени. И это очень важная вещь, которая позволяет не сильно вкладываться в апгрейд «железа» для ДБО, где оно тяжелое, большое и очень дорогое. Вот вкратце предыстория, для чего нужен промежуточный слой, который абстрагирует взаимодействие банка с клиентом от внутренних банковских систем.
Идею я уже давно вынашивал, но как-то не возникало точки, когда прямо вот ее нужно реализовать, потому что именно такой подход к организации «бэка» для ДБО оправдан экономически и технически. Раньше удавалось нивелировать недостатки прямых интеграций ДБО с АБС, а тут как раз все звезды сошлись, и хороший проект получился.
— А есть альтернативные способы решения задачи, которую вы описали?
— Конечно, есть. Альтернатива этому — обеспечение непрерывной работы 24/7 всех внутренних бэк-офисных систем банка. Много программного обеспечения, много «железа».
— Но это же очень дорого?
— Да, дорого, но чем не альтернатива? Тут весьма простая логика: любая операция клиента должна быть отражена в бэк-офисных системах банка. И тут, как говорится, есть два пути: либо обеспечить некий промежуточный слой, в котором беспрестанно крутятся данные для выполнения этих самых операций в моменте и который умеет дождаться завершения технологических перерывов и передать нужную информацию бэк-офисным системам, либо организовать работу «бэка» без простоев.
— По сути, вы создаете некий цифровой двойник тех данных, которые лежат в конечных системах. К какому классу систем можно отнести это решение? Чем оно отличается, например, от классического хранилища?
— От классического хранилища принципиально отличается скоростью, с которой туда попадают данные, и принципами хранения. Вместо периодической загрузки данных по некому расписанию и временного гэпа по их готовности у нас молниеносный онлайн. Это, наверное, ближе к классу систем высокоскоростных баз данных, идеологически похоже на in-memory.
— Но при этом именно технологии in-memory вы не используете?
— Да, нам пока по объему это не нужно. Все-таки in-memory базы данных рассчитаны на сверхбыструю передачу данных. Вообще эта идеология и развивалась от веб-приложений, когда большое количество клиентов одновременно запрашивает данные. Просто до определенных размеров не нужно использовать этот технический инструмент, а вот подход и идеологию — вполне себе можно.
— Есть ощущение, что описанное вами можно смело назвать новой концепцией банковского IT. Раньше господствовала на рынке АБС. Потом, когда появились системы, ориентированные наконец-то на клиента, а не только на соответствие требованиям ЦБ и хранение информации, ее значимость. Теперь, исходя из вашей концепции, конечные системы станут «чуланом», куда нужно просто вовремя отгрузить данные, а вот вся «движуха» будет происходить как раз внутри этого слоя операционных данных, о котором вы рассказывали. И это фактически сведет к минимуму значимость конечных систем, включая АБС. Чувствуете ли вы себя неким новатором и человеком, который участвует в трансформации, я бы даже сказала, отрасли, а не только конкретного банка?
— Решения по организации data hub с теми целями и задачами, что я ранее описал, действительно никто не делал. И если поразмышлять, то этот проект вполне может претендовать на инновацию. Другое дело, что мое мироощущение строится на глубокой практичности и я решаю вполне конкретную и земную задачу, а не ищу самый оригинальный и новаторский путь. Тем не менее для меня этот процесс оказался интересным, увлекательным и технологичным. И я полностью с вами согласен, что реализованный нами подход достаточно новый для банковского рынка.
— Представьте, что вы прочитали об этой идее в журнале или услышали на конференции, она бы вам показалась достойной внимания? Как бы вы ее оценили?
— Я бы сказал, что это круто! Мы в «Зените» и правда сделали большой шаг в сторону того, что все декларируют, но куда еще мало кто реально ходил. Я про идею свести АБС только к учетным функциям и не работать через нее с клиентами. Я знаю, что были предприняты попытки реализовать это на уровне CRM-систем, но не очень, если честно, они удались. А использование data hub позволяет реализовать микросервисные подходы в отношении хоть АБС, хоть любой другой конечной системы.
На этой теме, собственно, многие банки очень сильно накалываются, потому что побежали в микросервисную архитектуру на радостях, уперлись в монолит АБС с требованиями ЦБ, узнали, что еще года три новую АБС писать, чтобы микросервисы взлетели, и расстроились. И промежуточный слой в виде операционного хранилища данных, и окутывание микросервисами выглядит островком здравомыслия во всей этой технологической неразберихе и бессмысленных упражнениях с переписыванием АБС.
— Вы сказали, что не получилось у банков, которые пытались обойти ограничения АБС с помощью CRM. Как вы думаете, почему?
— Скорее, вопрос не в сложностях реализации, а в дальнейшей поддержке получившейся IТ-конструкции. У АБС и СRM разные модели разработки. CRM и все передовые системы — это действительно микросервисная архитектура, слабосвязанные сервисы, DevOps, а большинство АБС — это монолитные гири, в которых очень долгие, трудные и дорогие изменения. Это, на мой взгляд, основная причина.
— То есть монолитное наследство не дает микросервисам «летать», как они задуманы?
— Если микросервисы никак это монолитное наследство не затрагивают, то они хорошо «летают». А вот как только зацепятся, то уже «взлететь» не могут.
— Правильно ли я понимаю, что операционное хранилище, по сути, содержит в себе все данные, которые нужны для клиентских операций? В него же можно встроить, например, кредитный конвейер или любые системы, так или иначе ориентированные на потребление клиентских данных?
— Чисто теоретически — да. Можно туда посадить все: и кредитный конвейер, и фронт-офис. Нужно ли это все делать в операционном хранилище или организовывать распределенное хранение и обработку информации — вопрос непростой и дискуссионный.
— А в чем сложность пускать все клиентские сервисы через ОХД? Это с идеологической точки зрения или с технологической сложно?
— Технических ограничений нет. Скорее, это из области здравого смысла. В CRM, например, есть развитый и очень правильный функционал по хранению информации взаимодействия с клиентом: какие предложения мы делали, на что он согласился, от чего отказался, кто у него родственники. Так вот, надо ли это — заново реализовывать этот функционал в операционном хранилище, либо можно взять готовую CRM-систему и интегрировать с ОХД, получая из ОХД только необходимые данные, — это как раз вопрос дискуссионный.
Я считаю, что эффективнее использовать сильные стороны существующих систем, а не увлекаться тотальным переводом всего в микросервисную архитектуру путем переделывания или «допиливания».
— Я правильно понимаю, что при этом data hub может стать для CRM как раз-таки источником данных?
— Конечно. И источником данных, и приемником информации о проведении клиентских операций, так же как для ДБО, например. Это вполне правильный, на мой взгляд, путь развития. Если бы мы реализовывали задачу автоматизации фронт-офиса, то я бы таким путем шел. В CRM из data hub передавал бы данные об остатках и сделках клиента, а в обратную сторону — информацию о ротациях клиента, которые он делает в офисе.
— Вы рассказали предысторию и концепцию проекта. Расскажите, пожалуйста, о результатах. Как вы их оцениваете и что планируете делать дальше?
— Оцениваю положительно. На текущий момент работают информационные сервисы, так что всю нужную информацию ДБО забирает из data hub и показывает клиенту. Сейчас мы вместе с Unitarius работаем как раз над процессом проведения клиентских операций через ОХД в АБС. Параллельно выросли потребности вокруг карточного фронт-офиса, кредитных конвейеров, в решении которых мы легко можем «переиспользовать» уже готовые сервисы data hub. В конечном счете эти активности скажутся на качестве клиентского опыта. Мы хотим от продуктового подхода перейти к комплексной работе с клиентом. Например, клиент просит потребительский кредит, а он по каким-то параметрам нам не подходит. При продуктовом подходе мы ему отказываем и точка, а при клиентоцентричном — ищем способы удовлетворить его потребность, например, предложив карту или кредит под залог недвижимости. Вот это и требует полного пересмотра кредитного процесса и технологий принятия решения, то есть там много всего.
— Расскажите, пожалуйста, как вы искали технологического партнера. Почему выбрали Unitarius?
— На верхнем уровне выбор состоит из двух возможных опций: пишем сами или покупаем «коробку» и адаптируем. У нас очень сильные ребята в подразделении рисков в качестве постановщиков задачи. У них очень правильные подходы, и я понимаю, чего они хотят от кредитного конвейера. Идею с «коробкой» мы быстро откинули, потому что она их ограничивала. А дальше мы пошли свои путем и определились с целевым стеком, где основная роль отводилась BPM. И тут удачно совпало, что в Unitarius активно ведется разработка платформы xBPM, стек и идеология которой совпадают с нашей целевой архитектурой и видением. Мне кто-то из коллег порекомендовал компанию, и когда потребность окончательно созрела, весь пазл и сложился. По поводу того, как компания работает, скажу: бывают накладки, куда уж без них в IT-проектах, но мне нравится очень сильная архитектурная компетенция и качество разработки.
— Известно, что Unitarius специализируется на opensource с момента основания компании. Каково ваше отношение к ПО с открытым исходным кодом, изменилось ли оно с течением времени?
— Объективно качество продуктов, которые распространялись по модели opensource, было сильно ниже. Но за последние десять лет мировое сообщество очень далеко продвинулось, и из хайпа opensource стал конкурентоспособен на рынке. Если речь идет о собственной разработке, то оpensource — здоровская вещь, которая позволяет сделать серьезные программные продукты. Очень дешево попробовать — это основная его прелесть и основное конкурентное преимущество сейчас, на мой взгляд.
— А вот насколько важно для разработчика специализироваться в конкретном оpensource? Считается, что любой может разобраться. Это действительно так просто?
— Точно надо обладать головой и руками, никуда от этого не деться. Да, разобраться можно, вопрос в том, за чей счет это будет сделано. Если есть опыт, то мы понимаем, что уже этап пройден, а теперь мы используем полученные знания у себя. А вот если этот процесс только начинается, то объективно будут проблемы.
— А что вы думаете о ценности внешнего поставщика для заказной разработки? Внутри банков, в общем-то, есть и свои сильные команды…
— Ценность в быстром старте. Как бы ни были отработаны HR-процессы, тяжело оперативно нанимать грамотные команды при открытии проектов. Сроки увеличиваются, потому что узнать, кого ты нанял, можно уже только в процессе. Поэтому, на мой взгляд, это объективно правильная тема, делать разработку с вендором, а потом в более спокойном режиме переходить на поддержку или развитие получившегося решения. Своими силами или с привлечением внешнего подрядчика — зависит от экономической целесообразности.
