Просмотр исходного текста страницы Автоматизация бэк-офиса банка: 3D-представление

[[Категория:Андрей Борейко (Статьи)]]
[[Категория:Андрей Гермейер (Статьи)]]
[[Категория:Банковская автоматизация]]
[[Категория:Банки и технологии (Публикации)]]
[[Категория:2003 год (Статьи)]]
* [[:Категория:Андрей Борейко (Статьи)|Андрей Борейко]], заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».
* [[:Категория:Андрей Гермейер (Статьи)|Андрей Гермейер]], ведущий эксперт управления банковских технологий ООО «Заказные ИнформСистемы».
* «Автоматизация бэк-офиса банка: 3D-представление»<ref>"Банки и технологии", № 6-2003.</ref>


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

== Постановка проблемы ==

=== В поисках бэк-офиса ===

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

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

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

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

=== Различие понятий фронт- и бэк-офиса ===

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

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

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

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

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

== Вектор первый: продукт или комбинация продуктов ==

=== Монопродуктовый бэк-офис ===

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

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

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

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

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

=== Многопродуктовый (комбинированный) бэк-офис ===

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

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

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

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

== Вектор второй: глубина учета ==

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

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

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

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

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

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

Кстати, интересно и то, что отделы ''S.W.I.F.T.'' с этой точки зрения также работают с учетной системой: ведь, по сути, стандарт S.W.I.F.T. представляет собой не что иное, как специальный план счетов, коды которого группируют под собой упорядоченные типы банковских платежных и сервисных документов. Успех S.W.I.F.T. во всем мире, может быть, и определен тем, что этот стандарт продуман в целом именно как план счетов с четкими наборами своих аналитических признаков для каждого типа документа как синтетического счета. Оцените в этом смысле качество российской платежной системы с ее фрагментарными макетами — разница со стандартом S.W.I.F.T. будет весьма наглядной.

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

== Вектор третий: полнота контроля и управления ==

Функции контроля и управления финансовыми активами в банках осуществляют кредитный комитет, позиционеры по коррсчетам, общее казначейство (ресурсы филиалов, касс отделений), казначейство дилинга (позиции, риски и лимиты) и т. п. Характерные задачи бэк-офиса при управлении группами активов — построение отдельных и интегрированных ''Cash Flow'', оперативное снабжение и возврат ресурсов от подразделений банка, обслуживание механизма лимитирования по видам активов. Крайне интересно здесь то, что название бэк-офис для таких структур достаточно условно — у них нет своих фронт-офисов, каналов в хранилища и во внешний мир.

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

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

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

== Синтез: 3D-представление ==

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

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

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

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

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

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

* Во-вторых, очевидно то, что сложные проекты, четко ориентированные относительно существующих возможностей и потребностей банка, успешнее всего будут реализованы на принципах заказной разработки при условии, что технологии разработчика позволят обеспечить целостность и развиваемость системы. Возможно, когда-нибудь, когда бизнес-процессы активного большинства российских банков будут детально изучены и описаны, а средства разработки и СУБД повсеместно стандартизованы и практически неотличимы, разработчикам тиражных АБС удастся вырастить свой «кубик» до такой степени, что он поглотит все возможные варианты. Но тем временем и потребности, скорее всего, вырастут, и технологии не будут стоять на месте. Так что гонка «коробок» за проектными решениями будет повторяться снова и снова.

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

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

[[Image:Автоматизация бэк-офиса - 3D-представление (2003).gif|center|Рисунок. Автоматизация бэк-офиса: 3D-представление]]

== Ссылки ==
<references />

{{replicate-from-custiswiki-to-lib}}