— Елена, как можно кратко сформулировать изменения в вашем подходе к локализации иностранных АБС? Елена Лукутина: Прежде всего хочу отметить то, что осталось неизменным. Наш подход состоит не во внедрении АБС в чистом виде, а в построении ИТ-ландшафта, в котором главным элементом является иностранная АБС. Для успеха проекта необходимо продумать ИТ-архитектуру, в которую будет вписана иностранная АБС, определить, как новая АБС будет интегрирована с другими системами, которые есть или будут работать в банке, какие компоненты нужно разработать дополнительно, какие доработки необходимо сделать в АБС, какая информация будет передаваться между системами, как будет формироваться отчетность — все это вопросы исключительной важности. Если исполнитель проекта продумывает и создает ИТ-ландшафт, а не просто локализует АБС, то и у него, и, главное, у клиента возникнет гораздо меньше сложностей как во время проекта, так и в ходе промышленной эксплуатации иностранной АБС. При внедрении иностранной АБС банкам нужен комплексный подход к учету российской специфики. Помимо требований ЦБ к формированию отчетности, есть требования Росфинмониторинга к проверке операций на финансовую чистоту. Известно также, что иностранные АБС испытывают сложности с поддержкой функциональности по расчету резервов по требованиям ЦБ. Как правило, возникают специфические вопросы обмена информацией между западной и российской АБС. Мы пришли к убеждению, что оптимальный способ локализации иностранной АБС — вынести функции, связанные с российской спецификой, во внешние модули, в отдельные компоненты, а обязательную отчетность формировать средствами хранилища данных. И сегодня мы можем предложить рынку набор компонент собственной разработки, которые закрывают все названные вопросы. Применение этих компонент — новое в нашем подходе. Их использование в нужных участках существенно ускоряет процесс разработки целевой ИТ-архитектуры и реализацию проекта по внедрению иностранной АБС. Нужно сказать, что в проекте, который мы реализовали в банке «БНП Париба Восток», большая часть этих компонент уже используется. Банк принял решение внедрить в качестве основной АБС систему Atlas2, которая является корпоративным стандартом группы BNP Paribas. Соответствие российским требованиям обеспечено за счет ряда компонент: модуля локализации Neoflex GL, который приводит данные системы в соответствие с РПБУ, модуля финансового мониторинга AML, отвечающего требованиям ФСФМ. Мы организовали в «БНП Париба Восток» формирование отчетности на базе хранилища данных. ИТ-ландшафт, включающий эти компоненты, уже находится в промышленной эксплуатации.

— Какими принципами вы руководствуетесь при локализации иностранных АБС? Елена Лукутина: Во-первых, мы не рекомендуем вносить в западную систему все российские требования и российский бухгалтерский учет, потому что, как правило, такие изменения затрагивают функции ядра иностранной АБС и требуют больших затрат времени и ресурсов на доработку системы. Во-вторых, как я уже отметила, мы стараемся выносить «российскую специфику» во внешние компоненты. В частности, мы рекомендуем вынести функции формирования отчетности в хранилище данных. В третьих, включаемые в ИТ-ландшафт системы мы связываем интеграционным решением. Наконец, мы как консультанты в каждом конкретном проекте подбираем наилучшее решение для создания ИТ-ландшафта, исходя из требований банка.

— Какое место в вашем подходе занимает теперь российская АБС? Елена Лукутина: Здесь наш подход изменился. Раньше мы, как правило, рядом с западной системой ставили полноценную российскую систему, которая полностью отвечала за российский учет, а также, как правило, за отчетность и за российские платежи. То есть, мы включали в ландшафт две равноценные АБС — иностранную и российскую. Мы строили между двумя этими системами достаточно сложное интеграционное решение, которое полностью синхронизировало в них все операции. Это приводило к необходимости создания серьезного блока, обеспечивающего реконсиляцию данных. И на создание, и на поддержку всей этой архитектуры уходило достаточно много ресурсов, как наших, так и банка. Сегодня мы больший вес переносим на западную АБС, уменьшаем функциональность российской АБС, сокращаем дублирование информации. В частности, рублевые платежи мы все чаще рекомендуем переносить в иностранную АБС, а вопросы российской отчетности решать с помощью хранилища данных.Таким образом, интеграционное решение облегчается: в нем остаются традиционные для него функции — передача, преобразование и обогащение данных, управление таблицами соответствия данных между западным и российским учетом, а также некоторые реконсиляционные функции. Реконсиляция при таком подходе требует уже существенно меньше времени и в основном проводится на уровне счетов и остатков по ним, без учета сделок и платежей. Фактически сокращение дублирования информации означает уменьшение количества изменений, которые синхронно вносятся и в российскую, и в иностранную систему. Решение становится менее затратным и в дальнейшей эксплуатации. Сейчас в своих проектах мы используем только некоторые компоненты российской АБС — в основном это российская главная книга. Есть и альтернативный вариант. Иногда, в зависимости от задач клиента, мы строим ландшафт без использования российской АБС. За последние четыре года мы накопили значительный опыт адаптации иностранной АБС к российской специфике и воплотили его в наборе программных модулей Neoflex Localization Set. В него входят модуль трансформации данных к российским требованиям, российская главная книга Neoflex GL, модуль расчета резервов по требованиям Банка России. Я имею в виду положения 254-П и 283-П. В него входит также модуль противодействия мошенничеству, который реализует требования 115-ФЗ, 321-П.

— Что побудило «Неофлекс» разработать российскую главную книгу Neoflex GL? Елена Лукутина: Neoflex GL создана специально для того, чтобы эффективно решать задачи трансформации западного учета в российский. Это не тяжелая транзакционная система, а легкий модуль с возможностью просмотра и редактирования данных российского учета — простое и изящное решение. Преимущество Neoflex GL — в серьезной проработке трансформационного блока. В западной системе не всегда есть 20-значные счета, проводки с привычным для нас дебетом и кредитом. Но при этом в ней, как правило, есть операции, из которых можно получить все необходимые для российского учета данные. Если использовать российскую АБС, то нужно будет на каждом проекте специально создавать блок трансформации, и он будет внешним относительно системы. Потому мы и сделали Neoflex GL, чтобы каждый раз не изобретать велосипед, тратя на это ресурсы наши и заказчика. Помимо этого в состав Neoflex GL входит и набор типовых учетных процедур — переоценка, урегулирование парных счетов, распределение счетов по символам кассового плана и так далее.

— Помимо требований ЦБ, есть еще требования Службы по финансовому мониторингу. Каким образом вы их учитываете? Елена Лукутина: В Neoflex Localization Set входит специальный модуль, который позволяет собирать необходимую информацию и формировать отчеты для Росфинмониторинга. Задачи поиска мошенников и отслеживания мошеннических операций, как правило, решаются в корпоративных системах или средствами специализированных AML-систем. Наш модуль решает вопрос локализации, мы не конкурируем с большими системами. Мы лишь добавляем к ним компоненту, которая формирует необходимую информацию в соответствии с российскими требованиями.

— Как вы решаете проблему поддержки иностранными АБС расчета резервов? Елена Лукутина: Расчет резервов по 254-П и 283-П — ахиллесова пята большинства иностранных систем в российских условиях. Мы искали решение этой задачи вне иностранной АБС. Используя данные главной книги и хранилище данных, которое формирует обязательную отчетность, задачу расчета резервов решить достаточно легко. Как я уже упоминала, в Neoflex Localization Set входит специализированный модуль расчета резервов по требованиям Банка России, который позволяет оперативно рассчитывать резервы.

— Создание хранилища данных — сложный проект. Насколько эффективно для банка включать в проект локализации иностранной АБС этап создания хранилища для формирования обязательной отчетности? Елена Лукутина: Раньше большинство банков формировали обязательную отчетность из основной учетной системы — российской АБС. Сейчас, когда банки используют для поддержки разных направлений бизнеса специализированные решения, возникает необходимость формировать отчетность по данным нескольких систем. Кроме усложняющейся ИТ-архитектуры, актуальными становятся вопросы производительности и объемов операций. И становится очевидным, что если собирать в одну транзакционную систему все бухгалтерские операции, всю информацию о проводимых сделках, обеспечить работу нескольких сотен пользователей и одновременно формировать глубокие аналитические отчеты, то система, которая за это отвечает, должна быть очень мощной. Поэтому во всем мире предпочитают решать задачи разных типов в разных системах — работу пользователей обеспечивать некоторой транзакционной системой, а отчетность получать из аналитических систем, специально предназначенных для формирования отчетов по требованиям регуляторов или по требованиям самого банка. Сталкиваясь с задачей построения хранилища данных для формирования обязательной отчетности, мы предлагаем банкам идти по пути создания универсального хранилища данных, т.е. хранилища, которое в последующем можно будет использовать для подготовки не только обязательной отчетности, но и управленческих отчетов, налоговых отчетов и отчетов по МСФО. И нужно сказать, что такой подход уже подтвердил свою жизненность на практике. В «Русфинансбанке» мы начали с системы обязательной отчетности, и сейчас на базе этого хранилища разрабатываем компоненты для формирования управленческой отчетности. А в «Ханты-Мансийском банке» мы создали хранилище для формирования управленческой отчетности, и теперь банк поставил перед нами задачу его расширения для формирования обязательной отчетности. В уже упомянутом банке «БНП Париба Восток» внедрение корпоративной системы, поддерживающей западные правила учета, потребовало создания хранилища для формирования обязательной отчетности. В одном крупном российском банке мы сейчас делаем проект, который инициирован в связи с внедрением в банке иностранной АБС. В ходе проекта мы должны определить, как будут в ИТ-архитектуре банка решены вопросы отчетности: какие компоненты будут задействованы в формировании отчетности, какие нужно предъявить требования к этим компонентам. И мы предлагаем банку строить систему формирования отчетности также в технологии хранилища данных. В наших проектах по созданию хранилищ мы используем готовый продукт Neoflex Reporting, который позволяет реализовать в хранилище всю специфику российского банковского учета. Он содержит бизнес-модель хранилища детальных данных, унифицированный программный интерфейс загрузки данных, средства контроля качества загружаемых в хранилище данных, процедуры аллокации, витрины данных и более 200 готовых отчетов, включая отчеты ЦБ и МСФО, аналитические, налоговые, внутренние и проверочные отчеты. Сейчас мы реализуем проект по созданию хранилища данных для обязательной отчетности в крупном международном банке. Использование этого продукта позволило нам добиться впечатляющих результатов — всего через 6 месяцев после старта проекта была запущена в промышленную эксплуатацию первая очередь системы построения обязательной отчетности, которая обеспечивает формирование отчетов, касающихся работы банка с кредитами.

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

Ссылка на материал

Источник: Аналитический банковский журнал


Поделиться

Вернуться к списку публикаций