Всем привет! Меня зовут Дима Зыков, я – архитектор офиса корпоративной архитектуры Росбанка.

Сегодня я расскажу, как мы меняем IT-ландшафт в банке на примере обновления Главной книги – основной системы банка, обеспечивающей автоматизацию бухгалтерского учёта и хранение данных по операциям в соответствии с правилами и требованиями бухгалтерского учета Банка России.

Предыстория проекта

У Главной книги есть 2 основные функции: обработка бизнес событий с последующим превращением их в события бухгалтерского учета и хранение уже трансформированных по правилам учёта Банка России событий.

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

Практика прошлых лет в банковской среде показывала, что реализацию алгоритмов бухгалтерского учета можно легко совмещать с реализациями логики продуктового учета в одних системах, и это не вызывало трудностей в сопровождении и развитии таких систем. Однако со временем количество и разнообразие банковских продуктов увеличивалось, что привело к тому, что продуктового учета в системах CORE BANKING сегмента становилось всё больше и больше. Логика бухгалтерского учета, строго регулируемая регулятором в лице Банка России, неминуемо начала всё больше накладывать ограничения на изменения и развитие в продуктовой логике. Требования бизнеса росли, менялась динамика и факторы рынка.

На первых этапах многие банки решали данную проблему внедрением дополнительных АБС в CORE BANKING сегмент архитектуры, а бухгалтерский учет консолидировали в заранее выбранной мастер системе с главной книгой, либо в вынесенной в сторону системой для формирования регуляторной отчетности и отдельными бухгалтерскими движками. Всё это приводило к тому, что сложность таких ИТ-ландшафтов увеличивалась и с каждым новым внедрением ситуация только усугублялась, увеличивая time-to-market и снижая эффективность возврата инвестиций.

Рисунок 1. Один из многих вариантов IT-архитектуры в эпоху частых глобальных трансформаций в Банках

В какой-то момент мы поняли, что монолитная архитектура CORE BANIKNG систем изжила своё и на её смену начали приходить сервис-ориентированные архитектуры. Необходимость трансформации ИТ-ландшафта стала очевидной, поэтому мы в Росбанке решили запустить стратегическую программу по трансформации IT-ландшафта.

В рамках программы перед нами стояли следующие проблемы, которые предстояло решить:

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

Реализация

Мы начали с разработки методики трансформации, принципов и правил, по которым она будет проходить. Разработали несколько сценариев развития ИТ-архитектуры и из них выбрали оптимальный, по оценке корпоративной архитектуры.

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

В рамках программы по трансформации IT-ландшафта были выделены основные фазы внедрения новой главной книги.

Первая фаза подразумевает внедрение только модуля главной книги и её параллельной работы вместе с действующими АБС. Такой режим работы будет дублировать функциональности систем, но позволит обкатать решение от вендора и более уверенно перейти на него уже с внедрением следующей фазы.

Рисунок 2. High-Level-Architecture (далее HLA) первого этапа внедрения новой Главной книги Банка, этапа зеркалирования

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

Рисунок 3. Целевая архитектура (HLA) в рамках проекта внедрения новой Главной книги Банка

Такой двухфазный подход позволит снизить риски при работе на сердце живого «пациента» и сделать переход к новой архитектуре менее болезненным.

Сейчас проект внедрения Главной книги находится в стадии активной разработки.

Что это нам даст?

Разделение бухгалтерского и продуктового учета, что в своё время даст возможность развиваться продуктовым платформам самостоятельно, реализуя свою, независимую от регуляторных требований бухгалтерского учета логику во всём её разнообразии.
Возможность быстрой реакции на изменение требований регуляторов в плане бухгалтерского учета, т.к. вся логика бухгалтерского учета реализована в одной системе.
Простые механизмы закрытия бухгалтерского дня и распределенные механизмы закрытия операционного дня в продуктовых системах.
Возможность более детально исследовать TCO каждой отдельной бизнес системы.
Повысится прозрачность в процессах и, как следствие, увеличится скорость реакции на требования бизнеса.
В среднесрочной перспективе начнет снижаться time-to-market при росте сложности и количества банковских продуктов.
Повысится уровень возможностей дальнейшего развития экосистемы банка.

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

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

Трансформация IT-ландшафта в банке