Система подготовки банковской отчетности JFRS: новый подход к решению старой проблемы

В начале было… исследование

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

1. Большие ИТ-решения  универсального типа  плохо приспособлены для достижения  конкретных целей формирования регламентируемой  отчетности. При попытке реализации, например, списка обязательной отчетности Банка России на базе такого рода продуктов, очень быстро выясняется, что, во-первых, структуры данных хранилища требуют существенных переработок и дополнений, а, во-вторых, предлагаемые сервисы не удовлетворяют даже минимальным требованиям конечного пользователя. В результате возникает странная ситуация, когда производитель с мировым именем утверждает, что его решение позволяет формировать чуть ли не любую отчетность, но при этом, как заставить эту систему формировать ту же обязательную банковскую отчетность – далеко не очевидно.
2. Как правило, под оболочкой «Система подготовки отчетности» скрываются:
   • набор жестко запрограммированных алгоритмов, реализующих логику создания/генерирования целевых форм. Последствия: нежелательно высокая «чувствительность» конкретной  реализации  к достаточно частым изменениям порядка формирования отчетности. При таком подходе адаптация программного кода требует привлечение профессионального программиста, которому еще следует умудриться объяснить суть изменений. К тому же, сопровождение «запрограммированных» систем – дорогое удовольствие для заказчика, т.к. практически любое, даже самое незначительное изменение, требует привлечения специалистов компании-разработчика;
   • пользовательские инструменты, позволяющие довводить  то, что невозможно получить из АБС и/или иных внешних источников, функционирующих в банке. Зачастую из периода в период приходится довводить  одни и те же данные;
   • набор сервисов по межформенному и внутриформенному контролю правильности сформированных отчетов. При этом практически ничего не предлагается в части контроля достоверности исходных аналитических данных, на базе которых получаются агрегированные показатели отчетов. Также отсутствует полезная (с точки зрения дополнительного контроля) информация, касающаяся сведений, которые по тем или иным причинам  были исключены из целевого отчета. Стоит отметить, что для ответственного исполнителя отнюдь недостаточно внутриформенного и межформенного контроля: он должен быть убежден в том, что отчет построен на логически непротиворечивых данных, а также, что установленные в банке правила ведения учета соблюдены;
   • набор сервисов для ведения архивов и  обмена информацией с внешними программно-техническими комплексами. При этом возможности ведения архива крайне ограничены, и хранятся там только сами рассчитанные конечные формы (без  результатов соответствующих процедур контроля показателей отчетов).
3. С точки зрения  подготовки отчетности для современного банка имеют существенное значение следующие аспекты:
   • положения учетных политик банка;
   • правила  учета отдельных видов операций, установленные внутренними документами банка;
   • профессиональные суждения специалистов относительно экономической сущности отдельных видов операций.
     Однако существующие системы не предлагают практически никаких пользовательских инструментов для регулярного учета такого рода информации.
4. Формирование отчетности за предшествующие («исторические») отчетные периоды может превратиться в серьезную проблему, если учесть то, насколько высока вероятность различий в значениях атрибутов объектов хранилища (клиенты, счета, сделки и т.д.) текущего и «исторического» периодов! В итоге: невозможно гарантировать одинаковость результата формирования отчета «сегодня за «исторический» период» с действительными показателями того же периода. Иногда для решения данной проблемы разработчики систем  предлагают специальные процедуры «отката» на «исторически» предшествующие данные, но такой подход неэффективен и нередко становится источником дополнительных трудностей и ошибок.

К чему пришли…

Исследования, о которых говорилось  выше, явились отправной точкой при выработке нового подхода к автоматизации банковской отчетности. Командой разработчиков Департамента Прикладных Финансовых Систем были сформулированы  концептуальные основы будущей системы и начаты работы по ее реализации. В результате был создан оригинальный продукт Компании «Инфосистемы Джет» с рабочим названием JFRS (Jet Financial Reporting System), потенциальными потребителями которого являются банковские структуры, ведущие свой бизнес в России. 
Базовые компоненты системы схематично изображены на рис. 3 (в дальнейшем изложении ссылки в тексте будут относиться к составляющим (блокам) приведенной схемы).

Рис. 3. Архитектура JFRS

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

Конкретные потребности банков превыше абстрактной универсальности.
Отказ от абстрактной универсальности в пользу конкретно-целевого назначения подразумевает комплексную автоматизацию в составе JFRS исключительно трех групп отчетности – обязательной, налоговой  и в соответствии с требованиями МСФО (блок 2). Концентрация усилий и их подчинение именно  целям трех перечисленных групп привело к тому, что  все структуры хранилища и витрины данных системы разработаны  исключительно с точки зрения информационных потребностей указанных групп отчетов. В результате имеем четко структурированную (с точки зрения хранилища и витрин данных) систему, информационная полнота которой гарантируется.

Моделирование отчетов, но не их программирование. Oracle BI «свидетельствует»: времена программирования для рассматриваемого рода задач безвозвратно уходят в прошлое. На смену приходит процесс графического «конструирования» моделей отчетных форм. Как сам процесс моделирования, так и процесс редактирования/изменения готовых моделей, оказывается доступным не столько профессионалам «от IT», сколько «от бухгалтерии». Oracle BI как базовый компонент ядра JFRS (блок 1) позволяет, в большинстве случаев, конечному пользователю самостоятельно корректировать сущест­вую­щие модели по мере необходимости. 
Целям упрощения процесса моделирования служат также предлагаемые в составе JFRS механизмы синтеза  финансово-бухгалте­рских категорий (блок 3). Эти инструменты  позволяют вначале формировать привычные для финансовых работников категории и понятия (такие как: «дебиторская задолженность», «высоколиквидные активы», «денежные средства и их эквиваленты» и т.п.), а в дальнейшем использовать их в моделях отчетов. В результате интерфейс «Пользователь-JFRS» происходит на дружественном, понятном исполнителю языке. Есть и другое, не менее важное, преимущество в использовании бухгалтерских  категорий. А именно: если происходят какие-либо уточнения ранее определенных категорий/понятий, то сами модели отчетов, где эти категории/понятия используются, не потребуют никаких изменений!

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

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

Следующие инструменты призваны обеспечить в JFRS «индивидуальность» конкретного банка в части трактовки совершаемых операций и в рамках учетных политик:

• Пользовательские инструменты по настройке правил округления балансовых данных в тысячах единиц и механизм инициирования процедуры округления (блок 1). Пользователю предлагается механизм, который охватывает (с практической точки зрения) весь комплекс проблем округления: начиная от определения балансовых счетов, допускающих округление по «неарифметическим» правилам, и заканчивая  лимитом единиц, относящихся  на  балансовые счета по филиалам банка.
• Пользовательские инструменты по настройке в JFRS положений учетных политик банка (блок 1). Указанные настройки в дальнейшем могут использоваться как для контроля соблюдения требований учетных политик, так и для их интегрирования в модели отчетов (блок 1).
• Транзакционная и корректировочная машины (блок 3).  Эти механизмы призваны обеспечить относительную автономность JFRS от внешних источников информации. При этом транзакционная машина позволяет совершать проводки как в связи с реклассификацией существующих данных, так и совершение новых локальных проводок, которые отсутствуют во внешних учетных системах. Корректировочная машина предназначена для ввода недостающих данных, с одной стороны, и для корректировки имеющейся в хранилище информации – с другой. При этом изменения сохраняются для всех будущих отчетных периодов.
• Пользовательские инструменты по работе с архивными данными (блоки 3,4). В архиве JFRS размещаются как  сами отчетные формы, так и различные контрольные данные и расчетные показатели, используемые в отчетах. Наполнение архива происходит в результате подтверждения (акцепта) ответственным лицом соответствующей информации. Обеспечивается версионность хранимых в архиве отчетов как с точки зрения необходимого количества акцептованных вариантов, так и с точки зрения их сдачи/пересдачи в контролирующие органы.

Каждому объекту и атрибуту системы  –  «свидетельство о рождении, жизни и смерти»! Хронология степени  влияния любых сущностей системы на показатели отчетов является функцией самой Системы. Это означает, что пользователь может генерировать любой отчет за произвольный период в прошлом, при этом все показатели будут сформированны с учетом состояния соответствующих атрибутов именно в интересующем «историческом» периоде.

Отчетность = аналитический учет + контроль данных. Данная формула подчеркивает,  что с точки зрения реализованной в JFRS технологии,  отчетность определяют, с одной стороны, первичная информация, а с другой стороны, степень ее достоверности. Последнее обстоятельство подчеркивает сомнительную ценность тех  отчетных форм, о показателях которых нельзя с уверенностью сказать, что они соответствуют фактической  сути совершенных операций. Контроль достоверности обеспечивают следующие средства JFRS:

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

Кратко упомянем еще и о некоторые других важных компонентах JFRS:

• Управление доступом (блок 1). Является пользовательским инструментом и предназначен для разграничения  доступа ответственных исполнителей как по доступному функционалу и отчетным формам, так и относительно прочей информации.
• Аудит системы (блок 1). Основное назначение: протоколирование всех событий системы и источников инициирования этих событий.
• Планировщик заданий (блок 3). Назначение: автоматический запуск процедур по определенному графику и событиям; доставка уведомлений о событиях пользователям и  акцептованных отчетов  внешним получателям.  

Заключение или: «А что дальше?»

Система банковской отчетности JFRS многократно демонстрировалась в коммерческих банках Москвы и Екатеринбурга. Во время этих встреч практикующие специалисты, высказывая свои конструктивные замечания и предложения, тем не менее, одобрительно отзывались о концептуальных и архитектурных решениях, лежащих в основе Системы. Это положительное мнение «профессионалов от отчетности» является важным моральным стимулом для коллектива аналитиков и разработчиков JFRS в дальнейших работах по ее усовершенствованию.

В части практической реализации элементов утвержденной концепции, команда разработчиков ДПФС в настоящее время проводит интенсивные работы по отладке пользовательских инструментов и наполнению системы  конкретными отчетными формами. До конца текущего года предполагается реализация обязательной отчетности (наиболее востребованные  формы), предусмотренные Указаниями Банка России №1376-У от 16.01.2004. А год 2009-ый будет посвящен реализации в рамках JFRS налоговой и МСФО – отчетности, а также улучшению предлагаемых сервисов в рамках новой версии системы.