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

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

Вектор развития

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

Шкала, которая характеризует эволюцию банковского ПО для филиалов, имеет условное начало, характеризующееся полной децентрализацией, и не менее условный конец — предельную интеграцию филалов и центра. В том же направлении возрастают и инвестиции в автоматизацию филиальной сети. Это связано прежде всего с обеспечением соответствующих коммуникационных возможностей. Есть и множество других причин как технического, так и организационного характера, объясняющих малочисленность ИТ-проектов централизации филиальной сети. Сложности возникают при реализации учета операций с разновременным окончанием операционного дня, при поддержке нескольких вариантов отчетности из-за различающихся требований местных расчетно-кассовых центров или других абонентов. Кроме того, невозможно средствами АБС обеспечить сохранение настроек, принятых в головном офисе и в филиалах, в единой БД. Впрочем, последняя проблема может быть решена за счет использования хранилища данных с дискретной загрузкой (в офлайновом режиме). Кроме того, хранилище предоставляет дополнительные функции для анализа отчетности, обычно недоступные АБС. Хотя существуют и комбинированные решения.

Можно отметить несколько вариантов автоматизации, соответствующих промежуточным точкам на упомянутой выше шкале. Банк может обладать двумя типами подразделений: собственно филиалами и внутренними структурными подразделениями (ВСП). К последней категории относятся дополнительные офисы, операционные кассы, не входящие в основной кассовый узел банка, обменные пункты. То есть это отделения, также размещенные за территориальными пределами организации (головного офиса или филиала), но не имеющие собственного баланса. Операции ВСП отражаются в балансе банка/филиала, к которому оно относится. В иерархической банковской структуре на верхнем уровне находится головной офис, далее следуют филиалы и внизу располагаются ВСП. В таком контексте степень централизации филиальной сети можно рассматривать как отражение уровня информационной “федерализации” элементов иерархической структуры.

Теоретические варианты

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

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

Вместе с тем вариант с отдельными АБС требует минимальных трудозатрат на первичный запуск, поскольку открытие нового офиса подразумевает всего лишь установку стандартного ПО и обучение сотрудников. Такая структура характеризуется невосприимчивостью к техническим авариям, так как при выводе из строя одного узла остальные продолжают работать в стандартном режиме. Это же касается и угроз взлома. Однако подобный подход требует усиленного внимания к сопровождению АБС филиалов, которое производится с двойными затратами сил — как с помощью местных ИТ-специалистов, так и работниками ИТ-службы головного офиса. Управляемость банка обеспечивается на относительно низком уровне. Клиентов при этом обслуживает лишь один офис. ВСП не располагает данными о реальных остатках на счетах, а филиал до сеанса связи не имеет сведений об остатках ВСП. Довольно часто в многофилиальных банках встречается автоматическая консолидация данных из филиалов в режиме реального времени, т. е. АБС не устанавливается в филиальных ВСП, все офисы филиала работают в едином пространстве счетов и постоянно получают текущие сведения об остатках и операциях. В этом случае на ВСП-уровне присутствует только вспомогательное ПО: терминалы, почтовые системы, удаленные рабочие места.

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

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

Практические примеры

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

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

В головном отделении банка располагается информационно-аналитическая система, включающая  хранилище данных и инструментарий для работы с ним. Построена она на СУБД Oracle 10g. В филиалах накапливается информация по подчиненным отделениям, в головном банке — по всем подразделениям. Информационно-аналитическая система получает данные из OLTP-систем, которые построены на СУБД Sirius — единственной украинской СУБД, работающей в банках на протяжении последних двенадцати лет. В течение дня первичные, аналитические данные о всех операциях из подчиненных подразделений передаются в вышестоящие отделы с заданной периодичностью. При этом трафик прохождения очень незначителен. Размер пакета с информацией о тысяче проводок, со всеми реквизитами составляет порядка 100 килобайт. За счет такой компактности банк может позволить себе обновление информации столь часто, насколько посчитает это необходимым, без значительных затрат на оплату телефонного трафика.

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

1. Возможность постоянного внутреннего аудита и точечного управления в масштабах всего банка. Это актуально для таких задач, как управление кредитным портфелем, налоговый учет, планирование и контроль выполнения бюджета банка, технология валютного учета, тарификация услуг, предоставляемых клиентам и т.д.;
2. Формирование всей необходимой консолидированной отчетности  непосредственно на уровне головного отделения банка. Обеспечивается достоверность и полная согласованность отчетности по всем подразделениям, поскольку исключены возможные искажения, внесенные исполнителями на нижних уровнях. 
3. Гибкость и универсальность аналитической системы — возможность мобильного развития системы консолидированной отчетности при введении новых показателей.

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