Мудрый Экономист

Подходы к созданию и внедрению автоматизированных систем формирования отчетности

"МСФО и МСА в кредитной организации", 2014, N 4

Каковы организационные и технические задачи, возникающие при создании и внедрении автоматизированных систем формирования отчетности? Какие факторы являются источниками проблем: номенклатура отчетности и требования к ней, объем данных, отсутствие атрибутивности, форматы отчетов? Что представляют собой четыре типа архитектуры систем формирования отчетности и инструментарий, имеющийся в распоряжении проектировщиков, разработчиков и пользователей?

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

Но по мере ее развития, расширения линейки продуктов и увеличения объема банковских операций, роста числа клиентов стали необходимы не только учет результатов банковских операций, но и оперативная регистрация реализованных продуктов, их учет по различным параметрам, обработка в течение всего жизненного цикла (расчет и начисление процентов, расчет величины рисков и резервов, закрытие или изменение категории продуктов и т.п.).

У владельцев банков возникла потребность в оперативном управлении деятельностью с использованием управленческой отчетности. Старый подход, основанный на изучении ведомости остатков по счетам и баланса, перестал удовлетворять менеджеров. Им потребовался анализ операций и их результатов с возможностью как агрегированного, так и детального рассмотрения данных, "прогонки" их через различные математические модели оценки рисков (пассивная эволюция, внутреннее ценообразование, расчет доходности портфелей и операций).

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

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

Задачи, решаемые системами формирования отчетности

Каковы же задачи, возникающие при автоматизации формирования банковской отчетности? Ответ на этот вопрос можно найти в табл. 1.

Таблица 1

Виды отчетности и требования к ее содержанию

Виды отчетности

Требования к отчетности

Отчетность для регулятора (в т.ч. отчетность в соответствии с МСФО)

Жесткие сроки сдачи.

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

Высокая цена ошибки.

Разнообразие форматов (бумажных и электронных)

Оперативная отчетность и средства последующего контроля

Относительно стандартная номенклатура отчетности (выписки, операционные и сводные ордера, оборотно-сальдовые ведомости и т.п.).

Жесткие сроки: большинство отчетов включается в документы дня и должно выпускаться и контролироваться в операционной деятельности.

Уровень рисков от ошибок выше среднего, т.к. на основе отчетов принимаются операционные решения, но возможен перекрестный контроль по отчетам разного типа.

Отсутствуют требования по форматам

Управленческая отчетность

Большое разнообразие отчетов, индивидуально определяемых менеджментов банков.

Требования к срокам формируются внутренними документами банка.

Риски от ошибок средние, т.к. критические по суммам операции неоднократно проверяются разными подразделениями, выявляющими несоответствия и неточности.

Требования к формату не жесткие

Клиентская отчетность

Небольшая номенклатура стандартизованных отчетов (платежные отчеты, выписки, справки).

Сроки формирования и подачи отчетности регулируются договором, срыв которого неприятен, но не всегда критичен (репутационные риски).

Риски от ошибок в отчетности ниже среднего и в основном носят репутационный характер.

Требования к форматированию, определяемые престижем, брендом, отношениями с клиентами.

Требуется интеграция с каналами обслуживания (банкоматы и терминалы, ДБО и т.п.)

Как видно из табл. 1, основные задачи при формировании отчетности сводятся к четырем измерениям:

  1. соблюдению заданных сроков формирования отчетности;
  2. наличию данных и их параметров, необходимых для каждого отчета;
  3. качеству (точности) данных при формировании отчета;
  4. соблюдению заданного формата.

Естественно, что все эти задачи решаются при наличии ограничений в ресурсах (человеческих и материальных) и возможностей технической платформы информационной системы банка. Какие проблемы этому мешают?

Проблемы, возникающие при автоматизации формирования отчетности

Рассмотрим источники проблем, возникающих при формировании отчетности.

Большая номенклатура разнородной отчетности

Эта проблема существует практически как философская категория материи в известном произведении классика - "объективная реальность, которая дана человеку в ощущениях".

Регуляторы по собственной инициативе или следуя внешним требованиям (например, Базельского комитета по банковскому надзору), пытаются охватить разнообразной отчетностью все сферы деятельности банка. Перечень отчетов, содержащихся в Указании Банка России от 12.11.2009 N 2332-У с принятыми на момент написания статьи поправками, включает 75 отчетов. И пусть не все из них должны формироваться из АБС, но и оставшееся число незначительным не назовешь. Сюда нужно добавить виды отчетности перед другими регуляторами (налоговым органом, финмониторингом и т.д.), которые в сумме дают примерно эквивалентное количество.

Внутренние отчеты отчасти совпадают с обозначенным выше списком (в крайнем случае требуют иного формата вывода), но по количеству видов управленческой отчетности могут не уступать списку Банка России. И чем универсальнее банк, чем больше перечень его услуг и продуктов, тем разнообразнее его отчетность.

Отсюда проблема реализации: поставщики "стандартных" АБС в основном предлагают системы с минимально необходимым набором отчетности (которую можно сформировать на основе тех наборов и параметров данных, которые имеются в АБС) и в дальнейшем все усилия направляют на поддержание в актуальном состоянии ее форматов и наполнения, отслеживая изменения, вносимые регуляторами. Они физически не могут успевать за ростом номенклатуры, а в большинстве случаев в их АБС просто отсутствуют данные, по которым можно сформировать новый отчет. И внести эти данные не так просто.

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

Таким образом, система подготовки отчетности должна иметь встроенные инструментальные средства разработки и отладки отчетов.

Изменчивость требований к отчетности

Эта проблема - продолжение предыдущей. Как регуляторы, так и внутренние потребители (особенно - управленческой отчетности) часто меняют состав отчетности, ее наполнение, правила (алгоритм) ее формирования.

Поставщики по мере сил и возможностей стараются поддерживать актуальность встроенной в АБС отчетности и решают эти вопросы в рамках договоров сопровождения. Отчеты, созданные банком "хозяйственным" способом, поддерживаются силами и ресурсами банка. Поэтому система подготовки отчетности должна позволять оперативно вносить в нее соответствующие корректировки, поддерживая при этом управление версиями - на определенный отчетный год может понадобиться строго определенная версия отчета.

Большой объем исходных данных

Как правило, в промышленных АБС рабочая база содержала данные в режиме оперативного доступа (OLTP - Online Transaction Processing, обработка транзакций в реальном времени), в лучшем случае - с обособлением данных за один финансовый год. На этих данных проводились оперативные банковские транзакции и формировалась текущая отчетность. Данные за прошлые годы хранились в отдельных базах в режиме архивного доступа.

С увеличением количества клиентов и объемов операций рос и объем базы данных АБС.

Формирование отчетов по большим объемам "сырых" (не агрегированных в целях отчетности) данных требует больших вычислительных мощностей и времени. Рано или поздно наступает момент, когда процесс формирования отчетности начинает тормозить операционную работу банка и требуются срочные меры, чтобы преодолеть это "бутылочное горло" системы.

Данную проблему решают по-разному:

Логичнее все же выносить отчетные данные из транзакционной системы и работать с ними на отдельных мощностях.

Отсутствие у данных необходимой для отчетов атрибутивности

Так как российские АБС создавались как системы бухгалтерского учета, они практически не имели дополнительной атрибуции для таких объектов, как клиент, обрабатываемый банковский продукт или совершаемая транзакция (операция). Бухгалтерский учет, по сути, одномерен: параметром группировки остатка на лицевом счете является балансовый счет. Качество "материала" практически не учитывается.

По мере развития банковской системы и методов надзора возникла потребность классифицировать данные по продуктам и операциям в зависимости от клиента, его бизнес-сегмента (бизнес-линии - в терминах Базель II), внешних и внутренних рейтингов клиентов и финансовых инструментов (например, ценных бумаг), качества обслуживания клиентом приобретенных у банка финансовых продуктов, бизнес-сути обслуживаемых финансовых инструментов и т.д.

Для примера достаточно посмотреть на отчетность согласно МСФО, методику расчета капитала, обязательных нормативов или даже формирования публикуемой отчетности, где кроме "линейного" преобразования остатков счетов в новые регистры существуют многочисленные дополнительные атрибуты учитываемых объектов и связанные с их значением условные преобразования данных. Для такого продвинутого анализа требуется уже многомерный учет.

Увы, внесение подобной дополнительной атрибутивности в монолитные АБС сопряжено с большими проблемами, так как структуры, требующие такой атрибутивности, входят, как правило, в ядро АБС (Core Banking), изменения которого могут повлечь за собой замедление АБС и вообще повлиять на ее работоспособность. Не случайно доработки ядра АБС являются самыми дорогими элементами сопровождения, если они вообще возможны.

Однозначного решения здесь, увы, нет.

В соответствии с современными тенденциями развития архитектур информационных систем прогрессивным путем является разделение информационных систем по видам сервисов (SOA - Service Oriented Architecture, архитектура, ориентированная на сервисы/услуги) со связыванием их в "сервисный ландшафт" через системы обмена сообщениями (шина данных и т.п.). Эту концепцию поддерживает ассоциация BIAN (Banking Industry Architecture Network, архитектура для банковской индустрии), активно разрабатывающая бизнес-модель информационного взаимодействия внутренних сервисов банка при его функционировании (BIAN Service Landscape).

Разнородность систем, используемых для обработки однородных по сути данных

Как правило, в информационную систему банка, кроме АБС, входит огромное число слабо интегрированных или неинтегрированных систем, обслуживающих разные продукты и наборы данных, зачастую связанных с одними и теми же клиентами, а иногда и банковскими продуктами.

В банке эксплуатируются системы, используемые для разных бизнес-сегментов (корпоративные/розничные операции): АБС, CRM (Customer Relationship Management, системы управления отношениями с клиентом) и т.п.

В результате идентификационные данные одного и того же клиента в разных системах (например, в АБС и CRM) отличаются. В лучшем случае существует слабоуправляемая матрица соответствия одних кодов другим.

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

Если системы "разнесены" или различаются, у них все равно должен быть объединяющий центр, поддерживаемый на техническом и, что немаловажно, организационно-регламентном уровне.

Несогласованность ("загрязненность") данных

Как правило, в филиалах банка используются разные экземпляры одной и той же АБС, и, как правило, в них не согласованы справочники по информации, используемой для агрегации отчетности согласно МСФО.

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

Проблема не нова: в области обработки данных даже закрепились термины "грязные данные" и "очистка данных", а также появился специальный класс информационных систем ETL (Extract, Transform, Load - "извлечение, преобразование, загрузка").

Кроме технических средств очистки существенно облегчает жизнь регламентация процедур по внесению справочных и прочих общих для банка данных в информационные системы.

Несовпадение значений атрибутов однородных по сути данных, из разных источников.

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

Попытка получения сводной отчетности без кросс-согласования продуктов приведет к формированию разреженной "диагональной" матрицы "филиал - продукт - результат", в то время как 80 - 90% продуктов обычно совпадают и по сути, и по условиям, но об этом "никто не знает" (не задумывается).

Регламентированным образом необходимо наводить порядок в бизнесе. Автоматизация хаоса может дать только автоматизированный хаос.

Необходимость одновременного использования оперативных и архивных данных

Одной из важных задач является получение отчетов, имеющих временной охват данных, хранящихся в базах с разным "оперативным/архивным" статусом. Например, для понимания нового разреза финансовых результатов по сегментной отчетности в рамках отчетности согласно МСФО нужна выписка по счету за несколько лет или за год, но оперативные данные охватывают квартал, а остальные уже лежат в архиве текущего года.

Вариантами выполнения работ могут быть:

Разные форма и форматы одинаковых по сути отчетов для разных заказчиков

Отчеты, содержащие одни и те же данные, но для разных заказчиков, зачастую имеют разные требования к формату.

Например, выписка по счету:

При "прямом" подходе к реализации это выливается:

Современные тенденции создания систем продвигают принцип MVC (Model - view - controller, модель - представление - поведение), то есть максимального разделения данных, их представления и бизнес-логики.

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

Архитектуры систем отчетности и инструментарий

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

Для простоты выделим четыре типа архитектуры систем формирования отчетности. Как видно из табл. 2, существует множество информационно-архитектурных подходов к решению задач формирования отчетности, имеющих свои преимущества и недостатки.

Таблица 2

Четыре типа архитектуры систем формирования отчетности

Типы архитектур информационных систем

Основные характеристики

Преимущества

Недостатки

  1. Монолитные системы (функционал отчетности в составе АБС/ERP)

Исторически сложившийся вариант формирования отчетности непосредственно в рамках функционала АБС

Функционал от одного поставщика.

Нет проблем с согласованием структур данных.

Ограничение номенклатуры отчетности той, что реализована поставщиком.

Большая нагрузка на систему обработки текущих операций при формировании отчетов

Организационно-техническими мерами можно минимизировать рассогласование данных в разных экземплярах АБС

и, как следствие, замедление или невозможность операционной работы.

Привязка к поставщику при изменении требований к формату или содержимому отчетов.

Сложности внесения дополнительных атрибутов и параметров в ядро системы (дорого, а подчас и невозможно).

Проблемы формирования консолидированной/комплексной отчетности из-за необходимости ручной интеграции данных из разных типов систем

  1. Сборщики разнородных данных

Системы построены на основе формирования отчетности, на основе централизованных наборов предварительно настроенных объектов "бизнес-логики" (клиент, счет, остаток и т.п.), привязанных к "своему" источнику данных, формально не имеющему ограничений на его вид, формат данных и структуру. При формировании отчета каждый объект запрашивает свои данные и передает их в согласованном формате "сборщику" отчета

Возможность настройки каждого объекта под специфику источника (например, запрос остатков по счетам из баз с разной структурой, запрос из источника любого формата, вплоть до структурированного, но текстового файла).

Формально за настройку бизнес-объектов отвечают программисты, а отчеты из готовых объектов формируют бизнес-подразделения

Остается проблема нагрузки запросами базы оперативных данных.

Скорость формирования отчета определяется скоростью источников, т.к. используются запросы к первичным необработанным данным.

Чувствительность к отсутствующим параметрам агрегации данных

  1. Хранилища данных

Специализированные базы данных, предназначенные для обособленного хранения; и первичной обработки данных для отчетности, сбрасываемых из оперативных баз данных разнородных систем. Могут содержать многомерные агрегированные данные, формируемые по различным атрибутам (измерениям) первичных данных (многомерный гиперкуб, OLAP, Online analytical processing, аналитическая обработка в реальном времени). Требует очень хорошей проработки модели корпоративной базы данных и требуемых показателей для формирования отчетности

Автономная система/база данных, с вычислительной мощностью, управляемой независимо от транзакционной системы.

Возможность получения и интеграции данных из множества систем.

Встроенная или независимая ETL-система сбора и очистки данных.

Наличие многомерных агрегированных данных, что существенно убыстряет процесс формирования отчетности по сводным данным.

Формирование практически любых по форме и содержанию отчетов за счет "витрин данных", обеспечивающих "уровень представления" системы, относительно независимый от "уровня хранения данных", Возможность рассматривать как агрегированную информацию, так и при необходимости опускаться до рассмотрения деталей (принцип Drill Up/Drill Down).

Наличие промышленных платформ от ведущих производителей программного обеспечения.

Открытые протоколы, а значит, возможность создавать специализированные системы отчетности, построенные на основе предопределенных объектов, связанных с единицами хранения

Очень большая чувствительность к внесению изменений в структуру базы данных (особенно в многомерные гиперкубы). Добавление нового измерения может потребовать пересчета всех агрегированных значений.

Проблемы с загрузкой данных, у которых не хватает значений параметров агрегации, т.е. которые не полностью соответствуют модели корпоративных данных.

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

  1. Распределенные архитектуры (специализированные системы отчетности, шины передачи данных)

Развитие идеи хранилищ данных. Являются автономными системами, связанными с другими информационными системами по шине данных, принимающими данные для формирования отчетности в виде сообщений от других систем, проводят их разборку и сохранение в соответствующих структурах данных. Если пришедшее сообщение соответствует согласованному формату, то это гарантирует минимум ошибок при разборе и обработке данных. Уровень представления реализуется в виде витрин данных

Бурно развивающаяся, модная тенденция в построении информационных систем на основе SOA. Поддерживается международной ассоциацией BIAN.

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

Возможность организовать алгоритмическую обработку и контроль данных с неполной параметризацией

Концепция еще "сырая", отработанных промышленных информационных систем мало и они находятся на начальной стадии развития.

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

Желательно, чтобы вся информационная система банка была построена на подобной архитектуре, т.к. в систему отчетности свои данные должны передавать все информационные системы, задействованные в обработке банковских операций и продуктов

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

Таблица 3

Инструментарий формирования отчетности

Функция инструментальных средств

Описание инструментального средства

Отчетность на оперативных данных (OLTP)

Системы отчетности, встроенные в АБС/ERP-системы

Отчетность на агрегированных (аналитических) данных (OLAP)

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

Хранилища данных (DWH)

Системы, реализующие хранение и обработку корпоративных данных, поступивших из внешних информационных систем. Могут хранить как нормализованные данные транзакционных систем, так и результаты OLAP обработки

Загрузка и очистка данных (ETL)

Специализированные системы, предназначенные для сбора, преобразования в нужный формат, проверки и загрузки данных в хранилища

Витрины данных (уровень представления)

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

Системы бизнес-интеллекта/бизнес-аналитики (BI/BA)

Системы, позволяющие на основе накопленных данных при помощи математических моделей проводить аналитическую обработку данных

Формирование бизнес-показателей (BPM, EPM, CPM (Business/Enterprise/Corporate Performance Management)

Системы, аналогичные системам бизнес-интеллекта, но в основном ориентированные на формирование набора бизнес показателей деятельности предприятия, позволяющих принимать управленческие решения

Преобразование форматов отчетности (XML, XSLT, XBRL и др.)

Системы, позволяющие на основе первично сформированного отчета реализовывать разные форматы его представления для передачи разным потребителям.

Например, выписку из лицевого счета, необходимую в разных форматах, при однократном формировании ее в виде структурированного текстового файла в формате XML (eXtensible Markup Language - расширяемый язык разметки) с использованием шаблонов в формате XSLT (eXtensible Stylesheet Language Transformations - языка преобразования XML-документов) можно преобразовать в набор разных XML-документов, содержащих только данные, необходимые конкретному потребителю, которые, в свою очередь, преобразуются в документы необходимого формата (текстовые, электронные таблицы, веб-сайты, pdf и т.п.).

Возможно преобразование отчетности в формат, использующий специализированные языки разметки на основе XML: отчеты для ФНС, международную отчетность, размеченную с использованием XBRL (eXtensible Business Reporting Language - расширяемый язык деловой отчетности), и т.д.

Data Mining

Буквально: добыча (полезных) данных. Системы обработки, как правило, структурированных данных сложной природы для выявления в них закономерностей и формирования математических моделей или управленческих рекомендаций

Big Data

Буквально: обработка огромных данных. Системы обработки структурированных и неструктурированных данных огромных объемов (типа поисковых систем Интернет), выявления в них закономерностей и взаимных связей. Пример - системы контекстной рекламы в Интернете на основе анализа интересов пользователей, посещаемых ими ресурсов и т.п.

М.Б.Винников

Консультант

по IT-системам