Читать статью в pdf-формате
В 2006 году мы начали создавать линейку продуктов FLEXTERA. Базовым архитектурным принципом FLEXTERA является разделение продуктов на функциональные слои, в том числе разделение продуктового и бухгалтерского учета. Так на схеме функциональной архитектуры новой линейки продуктов появился новый сервис преобразования учета – Accounting Engine. Это была не просто дань модным архитектурным веяниям. Зависимость продуктовых систем от изменений учетного законодательства мешала нам быстро развивать продукты и качественно их сопровождать. Преимущества новой архитектуры казались очевидными.
В этой статье мы делимся знаниями и опытом, которые приобрели на пути к правильной архитектуре, и рассказываем о решении, которое создали в этом процессе.
Когда Accounting Engine нет
За 20–25 лет развития АБС сложилась традиционная для большинства из них архитектура. Это многофункциональная система, которая совмещает функции бэк-офиса, бухгалтерского и налогового учета, регуляторной и оперативной отчетности.
Что характерно для такой архитектуры?
• Единый баланс организации собирается из разнородных продуктовых систем на уровне Главной книги банка. Информация из внешних продуктовых систем на данном уровне недоступна, поэтому вся необходимая аналитика кодируется в номере лицевого счета.
• Продуктовые системы ведут свой собственный бухгалтерский учет, данные которого используются для продуктового учета. Например, в качестве остатка по депозитному договору используется остаток на соответствующем лицевом счете.
• В каждой продуктовой системе есть собственные встроенные механизмы формирования проводок и открытия счетов.
• Консолидированная отчетность организации формируется на уровне Главной книги. Дополнительные расшифровки стоят в продуктовых системах. Поэтому отчетность часто собирают вручную.
Аналогично развивались и бизнес-процессы кредитной организации, подстраиваясь и под особенности бизнеса, и под возможности АБС.
Распространено следующее распределение ролей и обязанностей пользователей системы:
• сотрудники операционного департамента кроме оформления и сопровождения операций отвечают за их бухгалтерское отражение, вносят «ручные» проводки и контролируют работу с лицевыми счетами;
• бухгалтерия отвечает за последующий контроль учета операций и при этом зачастую не имеет доступа к продуктовым системам. При сверке приходится ориентироваться на бумажные документы или отчеты из продуктовых систем;
• методология учета — это бумажный документ, который внедряет IT-служба банка, сами методологи не работают в системах, автоматизирующих правила учета;
• при появлении новых требований учетного законодательства IT-служба банка вносит изменения не только в Главную книгу, но и в продуктовые системы.
Когда Accounting Engine есть
Альтернативное решение, которое было сформулировано BIAN (Banking Industry Architecture Network) и поддержано IBM, предполагает разделение сервисов на учетные слои. Почему важно отделять продуктовый учет от бухгалтерского и какую роль в этом подходе играет решение класса Accounting Engine?
При разделении на слои в продуктовых бэк-офисных системах отсутствуют объекты учетного слоя, такие как бухгалтерские синтетические и аналитические счета, документы, транзакции двойной записи (проводки) и прочие атрибуты бухгалтерской книги. Для поддержки своих операционных функций продуктовая система опирается на продуктовые регистры, спроектированные специально для решения задачи конкретного банковского продукта. Наполнение Главной книги бухгалтерскими данными и преобразование продуктовых событий в бухгалтерский учет осуществляет Accounting Engine
Характеристики АБС, построенной по принципу разделения продуктового и бухгалтерского учета:
• продуктовые системы ориентированы исключительно на основные функции бэк-офиса. Продуктовый учет сконцентрирован на продуктовых регистрах;
• взаимодействие между продуктовыми системами и Главной книгой организовано посредством обработки продуктовых событий Accounting Engine;
• продуктовые события отражают исключительно пошаговые бизнес-процессы бэк-офиса и содержат только операционные данные;
• Accounting Engine содержит сценарии обработки продуктовых событий, правила открытия лицевых счетов и формирования бухгалтерских документов.
Изменение архитектуры АБС влияет на бизнес-процессы, распределение ответственности между бэк-офисом и бухгалтерией и подходы к сопровождению АБС следующим образом:
• сотрудники операционного блока сосредоточены на своей непосредственной функции сопровождения операций;
• бухгалтерия, осуществляя последующий контроль, имеет доступ к просмотру продуктовых операций и событий на уровне Accounting Engine и контролирует все «ручные» корректировки;
• методолог может сопровождать и менять правила бухгалтерского учета через пользовательский интерфейс Accounting Engine без привлечения IT-службы;
• продуктовые системы исключаются из контура изменений для поддержки новых требований учетного законодательства.
Как мы сделали Accounting Engine
В 2008 году после поистине героического проекта по поддержке новых требований бухгалтерского учета, который вошел в историю как проект «302-П», мы, что называется, на собственной шкуре испытали всю сложность задачи и поняли, что разделение продуктового и бухгалтерского учета — жизненно важный принцип проектирования автоматизированных систем. Мы очень хотели выстоять и в следующих учетных революциях. Так что рекомендации BIAN по этому вопросу легли на уже подготовленную почву.
Начало пути
Создание линейки FLEXTERA началось в 2006 году. Что делать с большинством новых сервисов, мы понимали. Мы знали функциональные требования к продуктам бэк-офиса. За предыдущие годы мы накопили колоссальный прикладной опыт в этом направлении. А вот наше представление об Accounting Engine основывалось на поверхностных описаниях BIAN, элементах этого функционала в линейке Diasoft FA# и мечтах об идеальном продукте.
Наше первое вИдение исходило из постулата, что Accounting Engine — это простая и быстрая «молотилка» для продуктовых событий. Сам сервис не должен быть мастер-системой для операционных данных — только для правил и настроек. Мы представляли его как своеобразное интеграционное приложение. С этого начался наш путь «по дороге из желтого кирпича» — к Accounting Engine, с которым можно будет построить архитектуру нового поколения.
Первый поворот
В первом пилотном проекте мы столкнулись с обстоятельствами, которые заставили нас пересмотреть предыдущий подход к решению задачи. Продуктовая система, являющаяся для нас источником событий, депозитный бэк-офис французского производства, не имела функционала для связи лицевых счетов и проводок с договорами и операциями. Кроме того, она не формировала набор событий с необходимым для российского учета атрибутным составом. Например, в событии заключения депозитного договора продуктовая система передавала идентификатор клиента, но не передавала форму собственности и резидентство. Такой поворот на нашем пути привел к тому, что в сервисе Accounting Engine появились новые функции: полное сохранение связей между продуктовыми объектами, событиями и объектами учета, а также обогащение события необходимыми для учета атрибутами.
Второй поворот
Особенностью следующего проекта стала задача поддержки учета по РПБУ в некредитной финансовой организации. С одной стороны, процесс настройки был простым — в этом стандарте отсутствуют лицевые счета. С другой стороны, нужен был аналитический учет на уровне субконто. На этом отрезке пути мы поняли, что спроектированный ранее механизм настройки справился с задачей без существенных доработок. Accounting Engine сформировал проводки для выгрузки в NAVISION AXAPTA, а мы зафиксировали функциональную возможность поддержки правил и механизмов формирования проводок в разрезе субконто.
Серьезное испытание
Следующий проект стал серьезным испытанием для Accounting Engine. «Дорога из желтого кирпича» наконец привела нас к задаче поддержки требований бухгалтерского учета операций на финансовых рынках по требованиям IFRS. Требования проекта задали высокую планку: нужны были очень гибкие механизмы настройки, потому что учет операций на финансовых рынках крайне сложен. В результате мы доработали механизмы настройки и обработки событий, полностью изменили правила открытия лицевых счетов и настройки схем счетов и получили решение на более высоком уровне зрелости.
Кроме того, важным компонентом преобразования учета операций на финансовых рынках стал новый аналитический сервис «Инструментарий вычислений». В 90% случаев по операциям на финансовых рынках невозможно сформировать полноценный бухгалтерский учет только на базе продуктовых событий. Универсальная продуктовая система ничего не знает о расчете финансового результата, об особенностях применения метода начислений, о правилах переоценки по справедливой стоимости, амортизации затрат и т.п. Эти алгоритмы являются частью учетных стандартов, а значит, входят в платформу преобразования учета и поддерживаются в специальном сервисе — FLEXTERA «Инструментарий вычислений».
Новые вызовы
Наш текущий проект — это поддержка перехода на отраслевые стандарты бухгалтерского учета Банка России для НФО. Наконец идея Accounting Engine развернулась в полный рост. Источником продуктовых событий являются сразу несколько систем: Calypso, Diasoft FА#, 1C Казначейство. Чтобы не строить отдельное интеграционное решение для каждой системы, мы разработали стандарт продуктовых событий в формате XML для всех операций на финансовых рынках и спроектировали события, исходя из реального бизнес-процесса, без учета специфики реализации продуктовых систем. Этот подход позволяет получить интерфейс, независимый от системы источника.
Какой Accounting Engine действительно работает
В результате эволюции развития Accounting Engine получилась система, функциональные блоки которой представлены на рис.
Мы прошли большой путь и понимаем, что Accounting Engine — это не просто «молотилка», не просто интеграционная функция. Для «честного» разделения продуктового и бухгалтерского учета такого «просто» недостаточно. Мы еще идем «по дороге из желтого кирпича», но уже точно знаем, что такое Accounting Engine, который действительно работает. Мы видим новые функциональны возможности, готовы к новым вызовам и испытаниям. Уже видны башни Изумрудного города, и впереди нас ждет самое интересное.
Наталья Татарникова,
главный бизнес-архитектор департамента
«Финансовые рынки FLEXTERA» компании «Диасофт»