Финансовая сфера

Банковское обозрение


  • Три закона digital-банкинга
01.12.2017 Мнение

Три закона digital-банкинга

Как цифровая революция меняет представление банка о системе ДБО?


Что такое digital для клиента банка? Прежде всего это фронт-энд: интерфейс, самый известный компонент цифрового банка, на который в первую очередь обращают внимание. Именно благодаря инновациям в интерфейсе стали известны многие необанки: интернет-банк Тинькова, мобильное приложение Рокетбанка, чат Talkbank’a. Популярность среди банкиров рейтингов MarksWebb показывает, что интерфейс — это модный, хайповый элемент современного банка.

Можно ли купить digital? Достаточно частая операция, которую проделывают банки в последнее время — покупают новую систему ДБО на замену старой, создают интерфейс нового поколения, привлекают всевозможных гуру UI/UX или экспертов из MarksWebb, получают новую картинку, добавляют маркетплейс. Как им кажется, это как раз то, что нужно, чтобы получить конкурентное преимущество и стать лидером.

Увы, зачастую этого не происходит, и создание нового интерфейса особо ничего не меняет. Почему? Давайте посмотрим на первую digital-волну в банках в конце 90-х годов, для которой было характерно изначальное появление интернет-банков. Чем, собственно, занимались банки в то время? Тем, что переносили существующие объекты из бумажного, реального мира в цифровую форму. То есть брали разные клиентские документы, заявки, поручения и автоматизировали их, переводя один к одному бумажные формы документов в электронный вид. Характерные признаки этого процесса можно было увидеть в деятельности банковских аналитиков и методологов, основная обязанность которых заключалась как раз в работе с печатными формами документов как основным и наиболее верным представлением информации. Целая эпоха в развитии ДБО была посвящена тому, что в цифровом виде представляли то же самое, что и в бумажном, и основной задачей было представление бумажных документов по максимальному количеству каналов работы.

Это время прошло. Следующий шаг в сторону digital заключается в том, чтобы заново спроектировать бизнес-процессы изначально в цифровой форме. То есть нужно не просто перенести имеющиеся бумажные заявки, а сделать так, чтобы они сразу появлялись в цифровом виде; это было бы удобно клиенту и было бы правильно, а также ускорило бы все нужные и важные процессы. Все делается так, чтобы во главе всего стояло удобство пользователя, его опыт.

Но главное, ради чего все это перепроектирование ведется, — достижение возможности масштабирования. Именно в нем заключается весь смысл digital — тиражирование имеющихся процессов на гораздо большее количество клиентов. При масштабировании падает удельная себестоимость услуг, что позволяет банку увеличивать прибыль, снижая при этом цены за свои услуги и захватывая еще большую долю рынка.

Итак, три ключевые задачи, по сути, новые законы, необходимые для появления полноценного digital внутри банка, — это создание современного интерфейса, внедрение оптимизированных под digital бизнес-процессов, которые оптимизированы под работу с digital, и масштабирование этих процессов на большое количество клиентов.

Но как это все внедрить? Согласно закону Мелвина Конвея, известного разработчика ПО, сформулированному им в 1967 году и получившему позднее его имя, «организация, которая создает систему, ограничена дизайном, который копирует структуру коммуникаций в этой организации». Это означает, что программное обеспечение, разрабатываемое для построения digital-банка, будет устроено так же, как устроена ваша оргструктура, и наоборот.

Этот закон имеет обратную силу. Если вы хотите сделать какой-то принципиально новый шаг в отношении архитектуры своего программного обеспечения, то для того, чтобы войти в digital, придется поменять оргструктуру. Этот факт интуитивно осознали все необанки, которые заметили, что им проще построить систему «в чистом поле», чем делать это внутри самого банка. Ведь в этом случае вы не ограничены в своей архитектуре или оргструктуре и можете с нуля одновременно выстраивать и то, и другое. В существующую оргструктуру очень тяжело внедрить новые решения, новую архитектуру. Отсюда берет начало и практика создания «цифровых лабораторий» рядом с банком.

Оргструктура классического банка с точки зрения ДБО достаточно проста: есть бизнес — корпоративный и розничный блоки, есть «айтишники», у которых, как правило, также есть два подразделения — розничное и корпоративное. Существуют команды, которые занимаются интеграцией, безопасностью, есть колл-центры, которые обслуживают клиентов.

Программное обеспечение соответствует закону Конвея: две системы ДБО — для розничных и корпоративных клиентов, каждая со своим интерфейсом, Каждая из двух систем обслуживает разные бизнес-процессы, поэтому по-разному произведена интеграция.

Часто на конференциях или в общении с банкирами всплывает вопрос: почему на практике редки случаи работы с «физюриками» — общая система ДБО для всех видов клиентов, с единым интерфейсом работы со счетами организаций и личными счетами? Причина, опять же, в действии закона Ковея — поскольку за этих клиентов отвечают разные подразделения банка, ПО для их обслуживания разное. Для того чтобы появилось общее решение, нужно не только найти подходящее программное обеспечение с интерфейсом «физюриков», но и создать единого заказчика от бизнеса по всем видам клиентов. Без организационных изменений подобное невозможно.

Но где же во всей этой классической организации работы ДБО находятся удобство клиентов, эффективные процессы, хоть какая-то скорость изменений и, вообще, забота о клиенте? Их нет. В каждой из двух отдельных систем ДБО слишком много функциональности и требований. В них за годы работы вложены большие средства на развитие продуктовой функциональности, представление различных «бумажных» документов в цифровом виде в различных каналах. В попытке конкуренции с digital-банками объем этих вложений возрастает, системы становятся все больше. Стоимость их сопровождения и изменения также возрастает из-за этой сложности, а скорость внесения изменений падает.

Из этой ситуации есть выход, который первым нашли такие digital-лидеры, как Amazon и Netflix. Он заключается в том, чтобы сделать шаг как организационно, так и архитектурно, перейти от старой монолитной архитектуры, одного большого общего приложения, от тяжелой сложной структуры, множества занятых в работе людей к новой микросервисной архитектуре и отдельным небольшим командам, работающим по гибкой методологии.

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

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

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

Разумеется, такая схема работает при подходящей готовности системы. Должны быть отдельный API, открытая архитектура системы. Управление десятками микросервисов — отдельная задача, решение которой находится в ведении DevOps — методики, продолжающей идеи Agile в сторону внедрения и эксплуатации систем. Соответствующие программные решения позволяют тотально автоматизировать все процессы, связанные с развертыванием и последующим обслуживанием систем. «Выкатка» каждого микросервиса является на 100% автоматизированной операцией. Вместо того чтобы делать общий релиз системы ДБО, выходящий в эксплуатацию в лучшем случае раз в три месяца, вы можете выпускать новый релиз каждого микросервиса даже несколько раз в течение одного дня, при этом делать это безопасно, надежно и без остановки работы системы.

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






Новости Новости Релизы