Комплексные решения в проекте Центра Финансовых Технологий "Банковский Информационный Комплекс"

А. Погудин, Центр Финансовых Технологий, (3832) 39-9233, E-mail

Информационная система банка, как основа управления

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

Унификация банковского продукта - основа для создания аналитических приложений

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

Объектно-ориентированный подход к проектированию - способ создания гибкой системы управления технологией

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

Подход ЦФТ к разработке банковского ПО в новом проекте

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

взаимоотношения Банк-клиент;
технологические цепочки и документооборот;
учет информации;
организация системы доступа.

Рис. 1

Взаимоотношения Банк-клиент

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

Расчетно-кассовое обслуживание юридических лиц
Обслуживание счетов банков-корреспондентов
Срочные депозиты юридических лиц
Банковские депозиты
Счета до востребования частных лиц
Срочные вклады частных лиц
Коммерческие кредиты юридическим лицам
Банковские кредиты
Кредиты частным лицам
Неторговые операции
Ведение счетов Ностро
Ведение хозяйственных договоров банка
Обслуживание счетов-депо
Первичное размещение собственных акций банка
Обслуживание вторичного обращения собственных акций банка
Выплата дивидендов

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

Организация документооборота

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

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

Учет информации

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

Клиент

Основные требования к организации данных по клиенту можно сформулировать следующим образом:

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

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

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

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

Резюме

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

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

Архитектура банковской системы

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

описание модели ;
работа с конкретными данными (экземплярами).

Администрирование системы

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

Организация рабочего места пользователя

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

Выводы и перспективы развития

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