Повсеместное распространение сети Интернет, мобильных устройств, быстрое внедрение цифровых технологий, в том числе за счет огромного влияния гигантов вроде Amazon или Google, привело к созданию виртуальной среды обитания и обеспечило грандиозный сдвиг в поведении людей.

Банки должны предложить клиентам обслуживание аналогичное тому, которое они привыкли получать в Интернете. Операции клиента должны проводиться в несколько кликов мыши, обрабатываться в реальном времени, круглосуточно, семь дней в неделю, 365 дней в году.

Для банков встает вопрос, как перей-
ти от традиционной банковской модели, с классическими офисами, выстроенными стандартными многоуровневыми бизнес-процессами, c набором неповоротливых банковских систем, тяжелым водопадным процессом поставки программного обеспечения, на продуктив к предоставлению онлайн-услуг в режиме 24х7?

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

Пример такой программы – «Индустриализация 2.0» – приведен ниже.

 

 

 

 

 

Обслуживание клиента должно быть омниканальное, одинаковое во всех каналах, с возможностью начать обслуживание клиента в одном канале и продолжить в другом.

Для реализации такого подхода Банку необходим отдельный класс middleware-решений (омниканальная платформа), обеспечивающий единый процесс обслуживания клиентов в любом канале – офисе, фронтальном решении, интернет-банке, АТМ-устройстве, мобильном приложении, call-центре. Омниканальная платформа должна быть интегрирована с основными банковскими системами. В этой платформе должен быть реализован единый механизм информационной безопасности и доступа к сервисам. Также необходимо организовать единый согласованный доступ к данным о клиенте. Цель внедрения такой платформы – обеспечение такого ландшафта ИТ-систем, при котором ~90% клиентских задач будут решаться именно на этом слое middleware без затрагивания неповоротливых бэковых систем.

 

При общении с клиентом необходимо научиться определять причину его обращения. Этому может помочь наличие либо действующей CRM, либо сведение в онлайн-режиме информации по клиенту из различных информационных систем и предоставление через онлайн-сервисы, например на базе Hadoop.

В быстро меняющемся мире необходимо управлять постоянно меняющимися приоритетами задач. Необходимо активно работать над улучшением взаимодействия Бизнеса и ИТ-служб, что в свою очередь приведет к большому количеству положительных результатов и выгод. Именно поэтому кроме стандартного Waterfall необходимо активно развивать гибкие методики разработки (Agile), например на базе методологии Scrum, и активно использовать внутри ИТ – DevOps.

После организации Pipeline-вывода программного обеспечения на продуктив Банк получит ускорение выпуска продуктов на рынок, т.е. улучшит Time-To-Market.

 

Это современный архитектурный подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными, используя легковесные механизмы, в основном HTTP. Эти сервисы строятся вокруг бизнес-потребностей и должны развертываться независимо с использованием полностью автоматизированной среды. Необходимо использовать правильный инструмент для каждой определенной работы. Разбивая монолитные приложения на сервисы, или разрабатывая новый сервис, мы должны иметь выбор, на чем проводить разработку (например Java, .Net или другие языки программирования, более подходящие под текущую задачу).

Такой подход позволяет использовать гибкие методики разработки.

Ниже приведено сравнение подходов Монолитная архитектура и Микросервисная архитектура.

 

 

•          Сразу предполагается использование принципов Continuous Delivery

•          Возможность правильного разделения на модули

•          Автономность команды и ее ответственность за конкретный сервис

•          Возможность организации независимого релизного процесса

•          Независимое масштабирование

•          Вариативность используемых технологий.

 

Для быстрой интеграции со сторонними компаниями / партнерами Банк должен предоставлять свои интерфейсы в виде Open API:

-           REST интерфейс для интеграции приложений внешних систем с системами Банка

-           Вспомогательные сервисы для отладки и тестирования (mock services)

-           Простая документация с примерами использования

Пример:

http://api-sandbox.homecredit.ru

 

 

 

По информации от Mobile Marketing Association Asia, из 6,8 млрд человек на планете 5,1 владеют мобильным телефоном и только 4,2... владеют зубной щеткой.

Банковские услуги должны оказываться через мобильные приложения. Разработку новых продуктов нужно начинать с мобильных решений и только после разработки мобильного решения – переносить на другие платформы (пример Мой кредит).

Нацеленность на мобильные решения приводит к появлению новых ролей в Банке – дизайнеров UI (разработка должна идти от дизайна интерфейса, а не интерфейс натягиваться постфактум на разработанное решение).

 

 

 

Процесс поставки программного обеспечения на продуктив должен быть максимально автоматизирован, убраны все накладные расходы на мердж кода, сборку дистрибутива и его деплой на все виды тестовых сред. Должен быть реализован подход Continuous Delivery. Тестирование должно быть максимально автоматизировано (например – с использованием Behavior-Driven Development подхода). Поскольку для обеспечения безопасности все приложения, выкладываемые в интернет необходимо проводить через pen-test, то для устранения больших накладных расходов в цепочку прогоняемых тестов разрабатываемого программного обеспечения необходимо встроить сканеры проверки стандартных веб-уязвимостей (для устранения проблем безопасности на ранних этапах). Также важным является проведение автоматизированного нагрузочного тестирования оттестированного функционально программного обеспечения.

При развитии продуктовой линейки новые программные решения необходимо делать сразу на новом технологическом стеке, обеспечивающем основные преимущества технологических компаний: скорость, облачная разработка, отсутствие простоев продуктивной среды (бездаунтаймный деплой), инфраструктура как код.

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

 

•          использовать версионирование описания используемой инфраструктуры;

•          проводить полное тестирование;

•          использовать внутренние code styles для описания инфраструктуры;

•          использовать принцип Continues Delivery и для описания инфраструктуры.

Важными направлениями развития являются infrastructure as a service и network as a service.

Ниже приведены примеры текущего банковского стэка технологий и предполагаемое изменение стэка технологий после программы индустриализации.

 

 

В Блоке информационных технологий должно быть Research & Development подразделение, занимающееся исследованием новых технологий. После проведения пилотных проектов необходимо быстро переносить удачные технологии на продуктив.

Текущими интересными темами для проведения пилотных проектов являются использование чат-ботов в социальных сетях / мессенджерах (например, на базе открытого Microsoft API или нативного API мессенджеров) или технологий Machine Learning при анализе данных.

 

Данные в Банке должны быть не просто Big, а еще и Smart. ИТ-службы должны накапливать и предоставлять для внутреннего анализа все возможные данные по клиенту во всех возможных разрезах. Необходимо предоставлять аналитический доступ к данным по клиенту в онлайн- и офлайн-режиме, как к единичным записям, так и к пакетам или агрегатам данных. Сохранять данные нужно в концепции Data Lake, в том виде, в каком пришли. И здесь на помощь приходит програмное решение Hadoop.

 

Для анализа SmartData необходимо использовать Machine Learning, а в дальнейшем смотреть на появление доступных систем искусственного интеллекта, в том числе на их интеграцию через OpenApi.

 

Необходимо уменьшить стоимость владения существующими системами, в том числе переводя их на использование программного обеспечения с открытым исходным кодом (например, PostgeSql в части БД, apache software в части middleware). Процесс перехода нужно начинать с наименее критических бизнес-систем и по мере накопления опыта, как с точки зрения разработки, так и с точки зрения сопровождения, – переводить на open source на более критические системы. Инфраструктуру также необходимо виртуализировать на базе open source стека (например, на базе KVM).

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

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

 

Технологическое перевооружение накладывает особые требования на привлечение вендоров / или компаний партнеров. Необходимо существенно изменять условия стандартных договоров Time & Materials / Fixed Prices. Преимущественно необходимо заключать краткосрочные контракты.

 

Перед стартом программы «Индустриализация 2.0» нужно определить и согласовать основные цели и KPI’S, которые компания ставит перед собой как минимум на следующие 3–5 лет.

Для успешного внедрения программы безусловно необходимо заранее заручиться поддержкой высшего руководства компании, определив под нее центральное место в Бизнес и ИТ-стратегиях Банка на ближайшие годы.

Программа индустриализации – это смена технологий, подходов, команд, систем, и все это необходимо сделать в максимально короткие сроки, и эти технологии будут во многом определять дальнейшее развитие компании на следующие 5–10 лет минимум.

Банк Хоум Кредит идет в ногу со временем, строит digital banking, в том числе за счет создания market place с партнерами из малого и среднего бизнеса, и предлагает свое сотрудничество.