Анна Чернобыльская Руководитель Управления маркетинга компании «ПрограмБанк»

Возможности ПрограмБанк.XBRL – квинтэссенция опыта.pdf

Два года назад «ПрограмБанк» представил рынку свою новую разработку — «ПрограмБанк.XBRL». Система позволила формировать XBRL-отчетность в соответствии с таксономией Банка России.

Формат, в котором надо было сдавать новую отчетность, содержит более 15 000 показателей и потребовал анализа большого объема первичных данных.

Основной функционал «ПрограмБанк.XBRL»

• Поддержка таксономии Банка России и изменений в ней.
• Загрузка данных из учетных систем. Контроль качества загружаемых данных.
• Табличное представление отчетов. Адаптация системы загрузки данных при изменениях таксономии. Использование загруженных, расчетных и вводимых вручную показателей.
• Организация бизнес-процесса подготовки отчетности. Распределение работ между сотрудниками организации в соответствии с их компетенциями и областью ответственности.
• Управление процессом подготовки отчетности. Контрольные отчеты и сервисы.
• Контроль качества отчетности до передачи ее в Банк России.
• Формирование XBRL-пакета в соответствии с требованиями ЦБ.
  
  

Что показала практика?

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

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

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

Это только часть нюансов, выявленных при реализации проектов. В результате их отработки функции «ПрограмБанк.XBRL» были расширены.

Какие новые возможности появились за последнее время, и как теперь выглядит бизнес-процесс выпуска отчетности?

Новые возможности:

1. Верификация. После того как разные подразделения и сотрудники предоставили данные для отчета, следует этап верификации. Один из примеров бизнес-процесса с верификацией описан ниже.

2. Сервисные инструменты. Для минимизации времени подготовки отчетов требуются специализированные инструменты работы с данными, например, копирование данных из предыдущих периодов и обмен данными с Excel.

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

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

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

Основные принципы «ПрограмБанк.XBRL»

1. Использование промышленных СУБД и OLAP-технологии.
Необходимость анализировать большой объем первичных данных определили выбор OLAP-технологии и организацию данных в виде Хранилища с иерархией показателей.

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

3. Развитые инструменты интеграции с внешними источниками данных.
На этапе загрузки данных из учетных систем вероятность ошибок и потерь максимальна. Для решения этой проблемы используются гибкие инструменты настройки интеграции с внешними системами. Прием данных работает не только при ручном запуске, но и в автоматическом режиме с рассылкой протокола загрузки ответственным.

4. Гибкая организация бизнес-процесса подготовки отчетности.
В каждой финансовой организации могут быть свои нюансы процесса подготовки отчетности, могут меняться требования регулятора, объемы бизнеса – все это необходимо учитывать при автоматизации.

Как же выглядит бизнес-процесс выпуска отчетности?

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

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

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

Вторую линию контроля обеспечивает верификатор. Он отвечает за корректность данных отчета, а также за полноту обработки аналитиком всех результатов проверки контрольных соотношений. Аналитик может и не исправлять данные, попавшие под контроль, но тогда он должен представить обоснование, а верификатор — либо принять это обоснование, либо вернуть отчет на доработку.

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

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

Вместо послесловия

В процессе работы над новой версией «ПрограмБанк.XBRL» мы уделили максимальное внимание инструментарию и интерфейсу работы с контрольными соотношениями, поддержке версионности и сравнению версий отчетов, возможности гибко настраивать зоны ответственности за показатели в рамках отчетов, стараясь предельно упростить этот трудоемкий процесс, сделать понятным, прозрачным и управляемым.

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

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