Что такое интегрированная банковская система?

"Если на клетке слона написано "буйвол" - не верь глазам своим"
Козьма Прутков

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

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

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

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

Интегрированность и платформа

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

Получившие в недавнее время широкое распространение системы на базе Btrieve безусловно являются технологическим шагом вперед по сравнению с вышеперечисленными платформами, хотя Btrieve все же трудно назвать масштабируемой, профессиональной СУБД, пригодной для построения информационных систем корпоративного уровня. Кроме того, более внимательный взгляд на предлагаемые Btrieve-системы показывает, что многие из них унаследовали свою архитектуру и изрядную часть кода от своих предшественников, написанных на Clipper или Clarion, что во многом обьясняет столь большую популярность Btrieve среди фирм, писавших ранее на этих платформах. Действительно, механически перенести существующую Clarion-систему под использование менеджера записей Btrieve относительно несложно, а вот для использования в качестве СУБД Oracle или Progress придется серьезно переосмыслить всю архитектуру системы.

Дело в том, что корпоративные СУБД и сопутствующие им средства разработки были изначально направлены на создание интегрированных, многопользовательских систем; развитые словари данных поощряют серьезное отношение к системному анализу и моделированию данных, а средства разработки оптимизированы для коллективной разработки сложных систем в рамках единой и продуманной идеологии. Именно разница в идеологиях делает невозможным механический перенос существующей системы для персонального компьютера на профессиональную платформу, а стиль программирования, сложившийся в тех фирмах, где каждый програмист пишет и сопровождает свою "программу", никак не связанную с другими, не способствует созданию интегрированных систем нового поколения на базе профессиональных СУБД. По-видимому, эти факторы и являются причиной того, что в небольшом, но растущем секторе рынка банковских систем, построенных на профессиональных платформах, лидируют те фирмы, которые, миновав увлечение персональными СУБД, начали осваивать корпоративные информационные технологии еще в начале девяностых годов. Не потому ли фирмы - лидеры рынка btrieve-систем, пока не занявшие сколь-нибудь заметного места на секторе рынка банковских систем на профессиональных платформах, предпочитают демонстративно отрицать сам факт существования этого сектора [1]? Автор предпочитает "не видеть", что именно реально объединяет фирмы, которые он упрекает за "уход от общих правил соревнования", и что их отличает от остальных фирм, участвовавших в опросе.

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

OLAP и OLTP в одном флаконе

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

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

Чаще всего оправдывают разделение OLAP и OLTP техническими проблемами - неизбежной перегрузкой сервера, падением производительности, невозможностью оптимальной настройки OLTP и OLAP на одной платформе и т.п. Что ж, если в качестве платформы для обработки транзакций выбран Btrieve, то с этим, пожалуй, можно и согласиться, но не все же транзакционные системы сделаны на Btrieve! Использование профессиональных СУБД, многопроцессорных серверов и, прежде всего, продуманных и оптимизированных моделей данных и алгоритмов позволяет достичь вполне достаточного запаса производительности и при использовании единой базы данных, причем четкое разграничение транзакционных и аналитических структур и механизмов на логическом уровне позволит легко разделить базы данных по желанию конкретного банка, если у него возникнет такое желание.

К тому же, выбор профессиональной СУБД для построения отдельной аналитической базы данных как-то не вяжется с утверждениями, что Oracle, Progress, Sybase и даже MS SQL слишком дороги и сложны для транзакционной системы и для нее как нельзя лучше подходит Btrieve. Но если для анализа и отчетности все равно предлагается купить систему на Oracle (Sybase, MS SQL - ненужное зачеркнуть), которую все равно придется администрировать, то почему бы не использовать эту платформу и для обработки транзакций - неужели транзакционная система на Oracle или Progress будет хуже, чем на Btrieve?

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

Факт, план, прогноз

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

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

Непонимание этого (как правило, проистекающее из отсутствия реального опыта работы с интегрированными системами), иногда приводит к забавным недоразумениям. Так, например, Александр Прусаков [2], неверно истолковав положение статьи [3], что "в прогнозе … должна учитываться информация не только об уже выполненных операциях, но и о тех, что запланированы на период прогноза ", утверждает, что "сотрудники аналитических подразделений ни в коем случае не должны заниматься учетом плановых платежей...“.

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

Интегрированность или модульность?

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

На мой взгляд, именно наличие общего ядра и единой модели данных, а вовсе не отсутствие модулей является отличием интегрированной системы от неинтегрированной, представляющей собой набор автономных, слабо связанных друг с другом модулей (АРМов), каждый из которых работает со своей собственной базой данных (иногда со своим набором таблиц в общей базе данных, создавая ложное впечатление интегрированности).

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

Литература:

1. Александр Смирнов. Взаимная оценка разработчиков АБС. Банки и технологии, N1, 1998.
2. Александр Прусаков. Организация информационного обеспечения аналитического подразделения. Diasoft-Info, декабрь 1997 г.
3. Анатолий Грушко, Георгий Котелевец, Андрей Орехов. Анализ и прогноз финансовых процессов (информационно-технологическое обеспечение). Банки и технологии, N3, 1997.