Всем привет! Меня зовут Дима Зыков, я – архитектор офиса корпоративной архитектуры Росбанка.
Сегодня я расскажу, как мы меняем 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 при росте сложности и количества банковских продуктов.
- Повысится уровень возможностей дальнейшего развития экосистемы банка.
Наш вариант решения данной проблемы не является единственно верным, и каждый банк по-своему может решать данные проблемы. Это один из примеров, как лечатся стандартные «болячки» ИТ-ландшафтов многих банковских организаций.
В следующей статье я расскажу про первые проблемы интеграции между системами, с которыми мы столкнулись в рамках данного проекта, и про то, как мы их решали.