- 2012
Станет ли АБС платформой для аналитики?
Юлия Амириди (Intersoft Lab) уверена, что поручать решение аналитических задач АБС – это путь, ведущий в никуда. Подробности – на страницах «Аналитического банковского журнала» № 8/2012.
Недавний кризис заставил многих отечественных разработчиков автоматизированных банковских систем (АБС) предпринять попытки диверсифицировать свои продуктовые портфели. Одно из направлений развития, по которому пошли поставщики АБС, – создание специальных инструментов и технологий для управления эффективностью бизнеса (Business Performance Management, сокр. ВРМ) и подготовки банковской отчетности. Причем путь этот продиктован не только все возрастающим, несмотря на сложные экономические условия, спросом на специальные инструменты и технологии управления, отчетности и анализа со стороны заказчиков – российских банков. Сегодня де-факто, как за рубежом, так и в нашей стране, BPerformanceM стал обязательным атрибутом успешного бизнеса. Гиганты мировой ИТ-индустрии – Oracle, SAP, IBM, Microsoft – подтвердили бизнес-перспективу технологий управления эффективностью, один за другим узаконив ВРМ-компоненты в составе своих продуктовых линеек.
Хочу напомнить, что в России это уже не первый «подход» (если выражаться «спортивным» языком) разработчиков систем операционного учета к решению аналитических и управленческих задач банковской индустрии. Докризисные попытки создать программное обеспечение для хранилищ данных и ВРМ-систем не принесли успеха практически никому. И это объяснимо, если вспомнить известную матрицу Бостонской консалтинговой группы (BCG Matrix). Рынок АБС для российских банков давно поделен, компании фокусируются на своих продуктовых флагманах – «дойных коровах», приносящих основные доходы, а от «трудных детей», требующих глубокого изучения и финансовых вложений, зачастую легче избавиться, чем тратить ресурсы на превращение их в «звезды». Вместе с тем стремительное развитие инструментов ВРМ, безусловно, требует относить их к «звездным» продуктам с высоким темпом роста потребительских характеристик и завоеванием значительной доли рынка. Отсюда – необходимость в существенных инвестициях со стороны разработчика и в подборе высокопрофессиональной команды специалистов, занимающихся созданием и внедрением ВРМ-решений.
Новые возможности или старые ошибки?
В чем же отличия «второго пришествия» АБС-ников на рынок ИТ-систем для финансового управления и отчетности? Изменилась архитектура решений, предлагаемых для автоматизации управленческих и аналитических задач. Сегодня приходится слышать, как в своих публичных выступлениях многие поставщики АБС отзываются о хранилищах данных как о технологиях «вчерашнего дня». И в соответствии с идеологией, построенной на этом ложном постулате, АБС начинают обрастать тематическими витринами данных: для подготовки управленческих отчетов – одна витрина, для регуляторных отчетов – набор других, для портфельной отчетности – третьи, для МСФО-отчетности – четвертые и т. д. В витрины помещается результат запроса к базе данных АБС либо витрина представляет собой один в один «слепок» данных АБС, относящихся к нужной предметной области. Прикладная обвязка витрины реализует необходимые расчетные алгоритмы и обеспечивает выпуск отчетов.
По своей архитектуре такое решение ничем не отличается от отчетных модулей, которые создают рядом с АБС специалисты банков. Локальные витрины содержат ограниченный набор данных и показателей для решения задач конкретного подразделения или сотрудника – например показатели управленческого баланса, подготовленные исключительно для финансового департамента, или данные только по кредитному портфелю для розничного бизнеса и т. п. Это относительно простой способ обеспечить бизнес-пользователей необходимой информацией, к которому прибегают ИТ-службы банков, когда сам фактор получения доступа к данным является критическим.
Оставим в стороне проблемы производительности АБС, нагруженной запросами от разных витрин. Главная сложность куда серьезнее: кто возьмет на себя ответственность за качество данных? Очевидно, что рассмотренный подход не позволяет согласовать данные в отдельных витринах – они выгружаются из АБС с разными целями, в разное время, посредством разных процедур и, к сожалению, с разными ошибками. При этом данные в витринах, как правило, дублируются. Так, чтобы решить задачу получения управленческой отчетности в разрезе клиентов и построить форму обязательной отчетности 0409118, необходимо загрузить данные по клиентам и в управленческую витрину и в куб для расчета концентрации кредитного риска. Поэтому очень сомнительно, что пользователи, работающие с отдельными витринами, смогут увидеть единую «корпоративную правду». Тем более не решается задача сопоставления однородных отчетных показателей в различных видах банковских отчетов, например прибыли по МСФО и по управленческой отчетности. Чтобы объяснить получившуюся разницу, потребуется сравнивать цифры на всех этапах процессов подготовки отчетов в независимых системах – от загрузки данных до вычисления отчетных показателей. Даже технически это выполнить сложно, а если учитывать «принадлежность» витрин разным подразделениям, то вообще нереально. Возникает известная проблема недоверия к цифрам в отчетах. Она заставляет банки отказываться от разобщенных, не связанных между собой витрин в пользу единого хранилища данных – основы для автоматизации управленческих задач и подготовки всех видов банковской отчетности.
Наблюдается парадоксальное явление: в то время как кредитные организации признают несостоятельность самописных отчетных систем, основанных на тематических витринах данных, их аналоги выходят на рынок в составе АБС. Что это – заблуждение или сохранение суверенитета? И в чем привлекательность «витринной» архитектуры?
«Три кита» аналитической модели данных
Рассмотрим две схемы. Одна (рис. 1) отражает архитектуру решения, объединяющего АБС и тематические витрины данных, другая (рис. 2) – АБС и единое хранилище данных. В первом случае мы видим переложение данных из транзакционной модели АБС «как есть» в тематические витрины, во втором – выполняется маппинг, то есть соотнесение данных транзакционной модели АБС с аналитической моделью хранилища данных ВРМ-системы. Таким образом, в реализации первого подхода маппинг исключается, что принципиально упрощает интеграционное решение и минимизирует время переноса данных между АБС и витринами.
Рис. 1. Архитектура «АБС + тематические витрины»
Рис. 2. Архитектура «АБС + хранилище данных»
Но на этом преимущества «витринного» подхода заканчиваются и начинаются его недостатки.
Замечу, что изначально транзакционная модель АБС проектируется для обеспечения высокой скорости массового ввода данных в систему, модель же хранилища данных – для массового выпуска отчетности. Поэтому применение транзакционной модели в витрине, предназначенной для выполнения множества запросов к данным, не даст необходимой скорости формирования выборок и получения отчетов. Но самое главное «зеркальные» витрины сохранят все ошибки и недостаток данных, присущие АБС.
Интегрированное с АБС хранилище на основе модели данных для финансовой отрасли, альтернатива набору тематических витрин, способно устранить перечисленные изъяны.
Во-первых, отраслевая модель диктует состав объектов и атрибутов данных, необходимых и достаточных для решения комплекса управленческих и аналитических задач банка. При этом модель определяет не только пространство первичных данных, но и рассчитанных на их основе показателей. Например, банковская модель Intersoft Lab покрывает большинство потребностей в данных для построения отчетности российских кредитных организаций. По опыту, объем уточнений модели в ходе проектов не превышает 15-20 %. На старте проекта по описанию модели заказчик сумеет оценить, достаточно ли в АБС данных для реализации поставленных задач, чтобы своевременно принять организационные и технические решения для ввода или автоматической генерации и вычисления недостающих данных.
Во-вторых, модель данных задает требования к процедурам диагностики целостности, полноты, согласованности и достоверности информации, поступающей в хранилище. Выполнение проверочных процедур обычно распределено между ETL-процессом, процессом перемещения данных из Stage-области хранилища в область постоянного хранения, а также процессом вычисления прикладных показателей. Диагностика качества и исправление выявленных ошибок на каждом этапе обработки данных обеспечивает их достоверность и доверие к информации в хранилище.
В-третьих, правильно спроектированная модель данных хранилища позволяет ускорить процессы консолидации и получения отчетности.
АБС и хранилище данных: интеграция в интересах заказчика
Очевидно, что основанные на транзакционной идеологии АБС никогда не смогут стать платформой для решения аналитических задач. Не будет выходом и формирование вокруг АБС тематических витрин данных. «Ахиллесовой пятой» подобного рода архитектуры является неизбывное недоверие к данным, качество которых невозможно гарантировать.
Обязательное условие для успешной автоматизации технологий управления и подготовки банковской отчетности – интеграция АБС и хранилища данных ВРМ-системы. Этот вывод давно не новость. В ВРМ-пакеты крупнейших мировых поставщиков входят готовые «адаптеры» для интеграции с различными учетными системами. В интересах заказчика общий язык в вопросах интеграции находят даже конкурирующие вендоры, но, увы, в банковском сегменте отечественного ИТ-рынка пока не так. Казалось бы, в чем сложность? Разработать совместное ETL-решение и синхронизировать технологию его сопровождения, чтобы одновременно с установкой патча для АБС или ХД банк получал обновление интеграционного слоя. Но похоже, что сделать такой шаг поставщики программного обеспечения для российских банков пока не готовы. А может, время все-таки уже пришло?
Автор: Ю. Амириди
Источник: Аналитический банковский журнал, 2012, № 8, с. 104-106