Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Публикации

Аналитический банковский журнал

Станет ли АБС платформой для аналитики?

Недавний кризис заставил многих отечественных разработчиков автоматизированных банковских систем (АБС) предпринять попытки диверсифицировать свои продуктовые портфели. Одно из направлений развития, по которому пошли поставщики АБС, – создание специальных инструментов и технологий для управления эффективностью бизнеса (Business Performance Management, сокр. ВРМ) и подготовки банковской отчетности. Причем путь этот продиктован не только все возрастающим, несмотря на сложные экономические условия, спросом на специальные инструменты и технологии управления, отчетности и анализа со стороны заказчиков – российских банков. Сегодня де-факто, как за рубежом, так и в нашей стране, BPerformanceM стал обязательным атрибутом успешного бизнеса. Гиганты мировой ИТ-индустрии – Oracle, SAP, IBM, Microsoft – подтвердили бизнес-перспективу технологий управления эффективностью, один за другим узаконив ВРМ-компоненты в составе своих продуктовых линеек.

Хочу напомнить, что в России это уже не первый «подход» (если выражаться «спортивным» языком) разработчиков систем операционного учета к решению аналитических и управленческих задач банковской индустрии. Докризисные попытки создать программное обеспечение для хранилищ данных и ВРМ-систем не принесли успеха практически никому. И это объяснимо, если вспомнить известную матрицу Бостонской консалтинговой группы (BCG Matrix). Рынок АБС для российских банков давно поделен, компании фокусируются на своих продуктовых флагманах – «дойных коровах», приносящих основные доходы, а от «трудных детей», требующих глубокого изучения и финансовых вложений, зачастую легче избавиться, чем тратить ресурсы на превращение их в «звезды». Вместе с тем стремительное развитие инструментов ВРМ, безусловно, требует относить их к «звездным» продуктам с высоким темпом роста потребительских характеристик и завоеванием значительной доли рынка. Отсюда – необходимость в существенных инвестициях со стороны разработчика и в подборе высокопрофессиональной команды специалистов, занимающихся созданием и внедрением ВРМ-решений.

Новые возможности или старые ошибки?

В чем же отличия «второго пришествия» АБС-ников на рынок ИТ-систем для финансового управления и отчетности? Изменилась архитектура решений, предлагаемых для автоматизации управленческих и аналитических задач. Сегодня приходится слышать, как в своих публичных выступлениях многие поставщики АБС отзываются о хранилищах данных как о технологиях «вчерашнего дня». И в соответствии с идеологией, построенной на этом ложном постулате, АБС начинают обрастать тематическими витринами данных: для подготовки управленческих отчетов – одна витрина, для регуляторных отчетов – набор других, для портфельной отчетности – третьи, для МСФО-отчетности – четвертые и т. д. В витрины помещается результат запроса к базе данных АБС либо витрина представляет собой один в один «слепок» данных АБС, относящихся к нужной предметной области. Прикладная обвязка витрины реализует необходимые расчетные алгоритмы и обеспечивает выпуск отчетов.

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

Оставим в стороне проблемы производительности АБС, нагруженной запросами от разных витрин. Главная сложность куда серьезнее: кто возьмет на себя ответственность за качество данных? Очевидно, что рассмотренный подход не позволяет согласовать данные в отдельных витринах – они выгружаются из АБС с разными целями, в разное время, посредством разных процедур и, к сожалению, с разными ошибками. При этом данные в витринах, как правило, дублируются. Так, чтобы решить задачу получения управленческой отчетности в разрезе клиентов и построить форму обязательной отчетности 0409118, необходимо загрузить данные по клиентам и в управленческую витрину и в куб для расчета концентрации кредитного риска. Поэтому очень сомнительно, что пользователи, работающие с отдельными витринами, смогут увидеть единую «корпоративную правду». Тем более не решается задача сопоставления однородных отчетных показателей в различных видах банковских отчетов, например прибыли по МСФО и по управленческой отчетности. Чтобы объяснить получившуюся разницу, потребуется сравнивать цифры на всех этапах процессов подготовки отчетов в независимых системах – от загрузки данных до вычисления отчетных показателей. Даже технически это выполнить сложно, а если учитывать «принадлежность» витрин разным подразделениям, то вообще нереально. Возникает известная проблема недоверия к цифрам в отчетах. Она заставляет банки отказываться от разобщенных, не связанных между собой витрин в пользу единого хранилища данных – основы для автоматизации управленческих задач и подготовки всех видов банковской отчетности.

Наблюдается парадоксальное явление: в то время как кредитные организации признают несостоятельность самописных отчетных систем, основанных на тематических витринах данных, их аналоги выходят на рынок в составе АБС. Что это – заблуждение или сохранение суверенитета? И в чем привлекательность «витринной» архитектуры?

«Три кита» аналитической модели данных

Рассмотрим две схемы. Одна (рис. 1) отражает архитектуру решения, объединяющего АБС и тематические витрины данных, другая (рис. 2) – АБС и единое хранилище данных. В первом случае мы видим переложение данных из транзакционной модели АБС «как есть» в тематические витрины, во втором – выполняется маппинг, то есть соотнесение данных транзакционной модели АБС с аналитической моделью хранилища данных ВРМ-системы. Таким образом, в реализации первого подхода маппинг исключается, что принципиально упрощает интеграционное решение и минимизирует время переноса данных между АБС и витринами.

Рис. 1. Архитектура «АБС + тематические витрины»

Рис. 2.  Архитектура «АБС + хранилище данных»

Но на этом преимущества «витринного» подхода заканчиваются и начинаются его недостатки.

Замечу, что изначально транзакционная модель АБС проектируется для обеспечения высокой скорости массового ввода данных в систему, модель же хранилища данных – для массового выпуска отчетности. Поэтому применение транзакционной модели в витрине, предназначенной для выполнения множества запросов к данным, не даст необходимой скорости формирования выборок и получения отчетов. Но самое главное «зеркальные» витрины сохранят все ошибки и недостаток данных, присущие АБС.

Интегрированное с АБС хранилище на основе модели данных для финансовой отрасли, альтернатива набору тематических витрин, способно устранить перечисленные изъяны.

Во-первых, отраслевая модель диктует состав объектов и атрибутов данных, необходимых и достаточных для решения комплекса управленческих и аналитических задач банка. При этом модель определяет не только пространство первичных данных, но и рассчитанных на их основе показателей. Например, банковская модель Intersoft Lab покрывает большинство потребностей в данных для построения отчетности российских кредитных организаций. По опыту, объем уточнений модели в ходе проектов не превышает 15-20 %. На старте проекта по описанию модели заказчик сумеет оценить, достаточно ли в АБС данных для реализации поставленных задач, чтобы своевременно принять организационные и технические решения для ввода или автоматической генерации и вычисления недостающих данных.

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

В-третьих, правильно спроектированная модель данных хранилища позволяет ускорить процессы консолидации и получения отчетности.

АБС и хранилище данных: интеграция в интересах заказчика

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

Обязательное условие для успешной автоматизации технологий управления и подготовки банковской отчетности – интеграция АБС и хранилища данных ВРМ-системы. Этот вывод давно не новость. В ВРМ-пакеты крупнейших мировых поставщиков входят готовые «адаптеры» для интеграции с различными учетными системами. В интересах заказчика общий язык в вопросах интеграции находят даже конкурирующие вендоры, но, увы, в банковском сегменте отечественного ИТ-рынка пока не так. Казалось бы, в чем сложность? Разработать совместное ETL-решение и синхронизировать технологию его сопровождения, чтобы одновременно с установкой патча для АБС или ХД банк получал обновление интеграционного слоя. Но похоже, что сделать такой шаг поставщики программного обеспечения для российских банков пока не готовы. А может, время все-таки уже пришло?