---

Внедрение систем класса BPM (Business Performance Management) должно освободить квалифицированных специалистов от рутинных вычислений, позволив им сосредоточиться непосредственно на аналитике, данные которой могли бы быть использованы при принятии управленческих решений. Однако внедрение подобных систем требует оптимизации существующих бизнес-процессов в банке. При этом неизбежно выявляются трудности функционального и управленческого характера. Специалистами компании РДТЕХ, предлагающей услуги по внедрению бизнес-приложений Oracle Financial Services Applications, на собственном опыте создания BPM-систем в финансовых организациях выработаны методики по предотвращению возможных осложнений при реализации проектов на практике.

Выбор между скоростью внедрения и качеством

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

Особенности автоматизации бюджетирования

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

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

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

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

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

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

Для предотвращения подобных критических ситуаций необходимо, чтобы в банках велся учет сделок по всем видам банковских продуктов.

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

Доработка информации из систем-источников
Для решения проблемы отсутствия учета сделок, необходимого для решения задач управленческого учета, BPM-система должна позволять гибко настраивать алгоритмы расчета финансового результата по тем или иным банковским продуктам. В связи с этим либо в системах-источниках банка, либо в самом хранилище должен быть механизм разметки проводок по операциям (продуктам). Например, если выбран вариант с хранилищем, компания РДТЕХ предлагает клиенту механизм, позволяющий классифицировать проводки банка по продуктам с использованием определенных аналитических признаков. При этом возможна настройка разных видов разметок для разных подразделений в зависимости от их задач.

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

Управленческий учет в контексте МСФО
Предлагаемый компанией РДТЕХ модуль управленческого учета тесно интегрирован с модулем подготовки отчетности по МСФО. Например, расчет финансового результата по ценным бумагам и по срочным валютным сделкам обязательно осуществляется с учетом принципов МСФО.

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

Когда одним из этих трех способов обеспечено качество данных в хранилище, решить задачу подготовки управленческой отчетности не составляет большого труда. Для облегчения данного процесса в бизнес-приложениях Oracle Financial Services Applications, внедряемых компанией РДТЕХ, создана логическая модель банковской деятельности, предусматривающая все структуры сделок и предоставляющая шаблоны для занесения информации в требуемой форме.

Особенности подготовки отчетности для Банка России (Центрального банка)

Положение 302-П
Последние нововведения по подготовке отчетности для ЦБ связаны с выходом положения ЦБР № 302-П "О правилах ведения бухгалтерского учета в кредитных организациях, расположенных на территории Российской Федерации" и новых указаний Банка России 1881-У, 1948-У. Модуль "Отчетность ЦБ", реализованный компанией РДТЕХ на платформе Oracle Financial Services Applications (OFSA), доработан в соответствии с новыми требованиями и соответствует актуальной нормативно-правовой базе Банка России, которая с 01.01.2008 года должна использоваться всеми коммерческими банками для подготовки внешней отчетности.

Впрочем, трудности с подготовкой отчетности для ЦБ сохраняются. Хотя сами правила 302-П вышли еще в 2007 г., требования к форме отчетности для ЦБ все еще уточняются самим Банком России. Банкам надо быть готовым к тому, что требования будут меняться по ходу реализации проекта.

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

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

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

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

Требования территориальных управлений ЦБ
Усложнить процесс подготовки отчетности для ЦБ может также разница в требованиях к одной и той же форме, предъявляемых в разных территориальных управлениях Центробанка. Например, для одного территориального управления: сначала необходимо сделать 101 форму, потому что ее сложно округлить, а потом под нее подогнать 501 и 603 форму, к которым нет таких жестких требований по округлению. В то же время в другом территориальном управлении: требуется, чтобы сначала 501 и 603 формы округлялись практически арифметически, после чего данные из 501 формы заносятся в 101.

Модуль "Отчетность ЦБ", разработанный компанией РДТЕХ, обладает гибким набором возможностей для учета нюансов, характерных для каждого территориального управления.

Особенности ведения нормативно-справочной информации

Сопоставление данных из разных справочников
Если банк крупный и многофилиальный, как правило, в разных его филиалах стоят разные учетные системы. Соответственно, один и тот же справочник в филиалах может иметь совершенно разное содержание и структуру. Поэтому в таких банках нет единого бизнес-процесса управления нормативно-справочной информацией (НСИ). Из-за несогласованности справочных данных в различных АБС банка не удается сформировать качественную управленческую отчетность.

Для решения данной проблемы у корпорации Oracle есть базовые инструменты для создания систем класса Master Data Management (MDM), предусматривающие наличие главного экземпляра данных, по которому будут равняться все локальные системы. Внедрение MDM-решения по управлению НСИ и его интеграция с BPM-системой - уже сложившаяся тенденция среди крупных банков.

Компания РДТЕХ предлагает интегрированное с хранилищем OFSA решение, уже адаптированное под крупные банки. Особенностью нашей системы НСИ является гибкий подход к количеству поддерживаемых источников для синхронизации, а также количеству потребителей синхронизованной эталонной информации. Существуют различные форматы представления данных системам, которые являются потребителями информации. Отличительная особенность системы НСИ - простота добавления справочников при появлении новых положений в банках. Ведение справочников в системе НСИ не требует программирования, все делается через настройки интерфейса.

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

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

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

Если это централизованное ведение, мастер-справочник ведется непосредственно в модуле по управлению НСИ. При децентрализованном ведении первоисточниками являются другие информационные системы, а система НСИ синхронизирует поступающие из них данные.

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

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

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