Привет! Мы уже рассказывали в блоге о том, как работаем с данными на Мосбирже. Но задач, связанных с data, равно как и её разновидностей, настолько много, что одной публикацией точно не обойтись. К примеру, мы – Кирилл Хомутов и Дмитрий Польских – в составе команды ИТ-Финансы обрабатываем данные, которые используются для формирования финансовой отчетности. Сегодня поделимся опытом, как мы научились регулярно получать, агрегировать и «приводить к общему знаменателю» миллионы транзакций из различных ИТ-систем компаний Группы «Московская Биржа».

Не все знают, но Московская биржа – это одна из компаний группы, которая занимается организацией торгов разными классами активов, учетом активов, расчетами. В группу также входят Национальная Товарная Биржа (НТБ), Национальный клиринговый центр (НКЦ), Национальный расчетный депозитарий (НРД) и несколько небольших компаний, которые выполняют узкоспециализированные сервисные функции.

Все участники группы находятся под разным регулированием, по-разному ведут бухгалтерский учёт и сдают разную отчетность. Биржи ведут учёт по стандартам для некредитных финансовых организаций (НФО). НКЦ и НРД ведут учёт уже как банки, закрывая операционный день и т.п.. А сервисные компании ведут учёт по РСБУ в соответствии с требованиями Минфина.

Нам нужно было собрать все эти «разношёрстные» учетные данные и свести в единую модель, чтобы сформировать консолидированную внешнюю отчетность по международным стандартам (МСФО). Добывать информацию приходилось из очень разных источников. Как мы это делали — читайте дальше.

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

Задача

Проект мы разделили на два этапа.

1. Сбор и трансформация всех учетных данных в Oracle для формирования консолидированной МСФО-отчётности Группы.

2. Организация ведения параллельного учёта в новой ERP-системе:
   

   1. локальный бухгалтерский учёт (НФО);

   2. налоговый учёт;

   3. учёт по международным стандартам (МСФО);

   4. управленческий учёт (MIS).

Раньше всё это было раскидано по разным системам, при этом часть учёта формировалась опосредованно – например, управленческий учёт строился на основе бухгалтерского. И мы хотели не только централизовать всю информацию по группе в одной системе, но и сделать так, чтобы для наших бирж все виды учёта имели единую точку входа — первичную транзакцию. Заодно нужно было повысить скорость обработки всех поступающих учётных данных: к примеру, документальное закрытие финансового месяца длилось 1,5 месяца, то есть, январь закрывали в марте — настолько велик был объём данных, которые по большей части обрабатывали вручную.

Решение

Понятно, что параллельное ведение учёта по нескольким стандартам, а также преобразование и консолидация большого объёма данных из разных источников — это задача для большой и многофункциональной платформы. Мы проанализировали существующие на рынке предложения. Среди претендентов были и 1С, и уже применявшаяся на бирже платформа «Контур», и продукты крупнейших вендоров, таких как Oracle, SAP, MicroSoft. Некоторые предлагали узкоспециализированную автоматизацию – например, только банковского учёта, при этом гибкость процессов — возможность самостоятельной доработки — была невелика.

Мы выбрали решение из семейства Oracle E-Business Suite R12 — Oracle Accounting Hub (Accounting Engine) и набор финансовых модулей ERP, где для формирования учета используется механизм SLA — Subledger Accountig. Эта система лучше всего подходила для решения наших главных задач: получения разнородных данных из многочисленных источников группы с приведением к единому стандарту и ведения параллельного учёта для бирж. Accounting Hub представляет собой конструктор, при помощи которого можно описать любую систему построения учета: классы и подклассы объектов, их жизненный цикл, учётные события, книги, план счетов и т.п. В систему зашиты различные алгоритмы и процессы, которые можно соединять друг с другом по своему усмотрению. А если штатных возможностей недостаточно, то можно дописать в коде необходимую функциональность.

Сбор данных

На создание системы автоматизации ушёл год. Наше бизнес-приложение состоит из модуля «Главная Книга», который агрегирует всю учётную информацию, и набора функциональных модулей для учёта разных типов операций: расчётов с поставщиками и подрядчиками, управления основными средствами и нематериальными активами, для закупок, склада и т.д.

В платформу мы внедрили универсальный алгоритм интеграции с внешними системами-источниками данных. Изначально мы интегрировали только основные системы: АБС (автоматизированные банковских системы НРД и НКЦ), 1С: Бухгалтерия (для сервисных компаний) и 1С: ЗУП (зарплата и управление персоналом), но не исключали, что в будущем придётся мигрировать различные вспомогательные системы и даже информацию из Excel.

Параллельный учёт

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

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

Интересно, что Subledger Accounting и Accounting Hub имеют один и тот же «движок», просто в Subledger Accounting уже зашита событийная модель, реализованная в рамках каждого конкретного прикладного модуля. К примеру, в модуле расчёта с поставщиками есть определённые типы операций — счета и платежи. У них есть свой жизненный цикл: создание, корректировка, отмена. То есть, набор событий, описывающих какую-то сущность — модель. Subledger Accounting знает эту модель и позволяет для каждого сочетания событий быстро и гибко настроить правила учёта.

Скорость обработки

Сложнее всего было увеличить скорость обработки данных. От банков и торгово-клиринговых систем в конце каждого месяца в каждом потоке приходит сразу до 20 млн операций. Используя все эти данные, необходимо в сжатые сроки (на четвёртый-пятый рабочий день нового месяца) предоставить бизнесу агрегированную финансовую информацию. Как мы решали задачу ускорения обработки и агрегирования? Все документы и проводки — это некие входящие события. В модуле агрегации нам удалось описать модель событий: все события, сущности и их жизненные циклы, максимально унифицировав их сочетания. Это позволило сократить количество уникальных обработок с 20 млн всего до 200 тыс. После запуска системы обработка всех входящих данных теперь занимает не более двух часов.

Пример конвейера обработки информации:

В рамках проекта нам удалось разработать методологию, регламентировать процессы сбора данных и сконфигурировать ПО таким образом, что получение полного пакета данных по Группе для формирования отчётности (управленческого пакета MIS и аналогично для IFRS) сократилось почти на месяц. Раньше данные собирались только к концу следующего за отчётным месяца, а сейчас они доступны для проверки и консолидации уже на четвёртый-пятый рабочий день. При этом качество и аналитичность получаемых данных существенно возросли. Мы забираем весь массив исходных событий и сами решаем, что и по каким правилам агрегировать. Помимо бухгалтерских счетов мы стали полноценно работать и с другими разрезами — структурным, проектным, продуктовым.

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