Современные банковские автоматизированные системы

заслуженные разработчики, как «Инверсия», «ПрограмБанк», «ЛИМ», чьи DOS-

комплексы в некоторых банках будут заменены на системы третьего поколения —

и вовсе не обязательно тех же самых фирм. Ожидается, что самые большие

«убытки» понесут собственные программные разработки банков.

Целый ряд опросов, проведенных журналом «Банковские технологии»,

показал парадоксальную картину: среди банков-респондентов, имеющих АБС

собственной разработки, довольных этой АБС оказалось значительно меньше,

чем среди тех, кто работает на «фирменной» АБС. Объясняется это просто: во-

первых, собственные системы в большинстве случаев выполнялись на тех же

FoxPro или Clipper; во-вторых, коллективы разработчиков, которых могут

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

разработка ведется по принципу «латания дыр», что исключает системный

подход и нормальное взаимодействие отдельных модулей. «Доморощенные» АБС

очень трудно, да и практически невозможно, подвергнуть серьезной

модернизации, так как нормальная документация проекта обычно не ведется.

Именно такие АБС скорее всего потребуют замены. Если какие-то банки еще

питают иллюзии, что им удастся «довести до ума» подобную разработку

собственными силами и в срок, и поэтому тянут с решением о переходе на АБС,

созданную внешними фирмами, то их ожидают большие разочарования.

Совершенно очевидно, что многие банки будут вынуждены «менять коней

на переправе», так как имеющиеся у них АБС неадекватны, и любые попытки как-

то удержаться на старой платформе приведут к большим потерям. В этом случае

следует помнить одно: переход на новый План счетов будет успешным только

там, где вовремя проведена тщательная его организационная подготовка (жаль

только, что методичность и скрупулезность не свойственны нашему

национальному характеру). Руководство банка должно было уже в октябре

составить и утвердить детальный план перехода, в котором следует четко

распределить обязанности и ответственность подразделений и должностных лиц.

Этот план должен быть расписан по неделям, а с декабря — по дням, с

соответствующей оперативной отчетностью.

Чтобы более нагляднее представить, что такое современная АБС,

постараемся более подробно разобрать ее строение.

Технологическое построение АБС описывает группировку программных

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

части этих процессов определяют абстрактные механизмы, лежащие в основе

реализации конкретных прикладных компонент системы. Такие механизмы

составляют технологическое ядро системы.

Архитектурное построение

Вся система состоит из трех компонентов:

1) клиентской части системы;

2) объектов сервера данных;

3) процедур сервера приложений.

Клиентская часть системы обеспечивает взаимодействие пользователя с

системой. Никакой обработки данных в клиентской части не происходит. Ее

назначение сводится к тому, чтобы принять от пользователя запрос на

выполнение операции системы и необходимые для выполнения этого запроса

данные. После того, как запрос реализован, клиентская часть дает

пользователю возможность ознакомиться с результатами выполнения операции.

Объекты сервера данных являются центральной частью системы. Здесь

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

операций. Хранимые процедуры получают запрос от клиентской части на

выполнение операций и подготавливают для нее результаты своей работы. Для

выполнения некоторых специфических операций хранимые процедуры могут

вызывать процедуры сервера приложений.

На сервере приложенией выполняются специализированные AS-процедуры,

которые вызываются по запросам от процедур сервера данных.

Процедуры сервера приложений обеспечивают функционирование системы

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

операций, для которой реализация средствами сервера данных неэффективна. AS-

процедуры могут обращаться и к объектам сервера данных, если это необходимо

для их работы.

Клиентская часть системы. Основное назначение клиентской части

системы — обеспечить взаимодействие пользователя с системой, предполагающее

организацию интерфейса пользователя (отображение и обработка событий) и

связь с сервером данных (Manager SQL).

Интерфейс пользователя состоит из процедур отображения результатов

работы системы, представленных в виде экранных форм или отчетов, а также из

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

или по сообщениям сервера данных.

Объекты сервера данных. Объекты сервера данных — это таблицы и

процедуры. По своему назначению они разделяются на системные (в контексте

банковской системы, а не базы данных) и прикладные.

Системные объекты реализуют задачи “секретности” и управления

доступом (этим правом обладает только уполномоченный оператор — так

называемый “офицер безопасности”).

Доступ к прикладным объектам клиентов возможен только через узкую

“щель”, определенную системой безопасности. Система построена так, что все

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

Последние надежно защищены системой управления доступом, и поэтому давать

разрешение пользователю на использование таблиц нет необходимости. Иначе

пришлось бы заботиться о том, кому из персонала банка следует передать

таблицу для выполнения определенных действий — при этом о доступе к

конкретным записям (“сайтам”) речь не могла бы идти вообще.

При вызове клиентом пользовательских процедур (объектов,

представляющих для системы безопасности основной интерес) сразу же

происходит обращение к серверу защиты (он реализуется как сервер

приложений). При получении соответствующего разрешения выполнение процедур

продолжается. В этом и заключается сущность взаимодействия клиента с

сервером данных под надзором системы безопасности. Остальные процедуры

(т.е. те, которые не вызываются клиентом) не связаны с системой

безопасности, поскольку они защищаются средствами сервера данных (Рис. 1).

Рис. 1. Архитектура построения системы.

Все объекты на сервере данных создаются при инсталляции системы системным

администратором. Этот процесс проходит в пакетном режиме, когда с клиента

на сервер посылаются запросы на создание процедур и таблиц, а также на их

заполнение.

Процедуры сервера приложений. Сервер приложений организуется

средствами Open-Server Sybase. Он может функционировать на том же

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

компьютере. Различают два вида процедур сервера приложений: первые из них

отвечают за функционирование системы безопасности и управления доступом,

вторые выполняют ту часть прикладных операций, которая неэффективно

реализуется средствами сервера данных.

Независимо от назначения, все AS-процедуры вызываются только по

запросам от хранимых процедур. Последние могут обращаться на сервер данных

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

на AS-сервере, либо к внутренним хранимым процедурам, применяя средства

Open-Client Sybase.

Технологическое построение

Проектирование и реализация системы позиционного и фактического учета

банковских операций, детальное рассмотрение вопросов ее взаимодействия с

обработкой банковских документов позволило представить технологическое

построение системы в следующем виде (Рис. 2):

Рис.2. Технологическое построение системы.

Можно определить три составляющие системы:

- Система безопасности и управления доступом.

- Ядро системы.

- Прикладная система.

Как уже отмечалось, система безопасности и управления доступом

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

обособленной системой (ей все равно, какую прикладную систему защищать).

Все остальные системы при разработке регистрируют в системе безопасности

свои объекты, а потом процедуры прикладных систем разрабатываются с учетом

требований безопасности (в основном эти процедуры представляют собой вызов

в определенных местах прикладных процедур соответствующих им процедур

системы безопасности).

Ядро системы — достаточно абстрагированный от предметной области

проблемно-ориентированный инструмент. Работа механизмов ядра не зависит от

функциональности системы. Ядро включает в себя:

- систему учета банковских операций;

- систему хранения документов;

- транзитную систему.

Система учета выполняет фактический и позиционный учет операций, а

также формирует “ограничения” на лицевые счета на базе единой абстрактной

модели.

Система хранения документов обеспечивает формализацию и хранение

документов предметной области.

Транзитная система осуществляет взаимодействие системы учета с

прикладной системой.

Реализацию функциональности, адаптацию к изменениям предметной

области обеспечивают механизмы прикладной системы, состоящей из трех

компонент:

- компоненты поддержки документооборота и выполнения операций;

- компоненты справочников и классификаторов;

- компоненты представления системы учета в аспекте предметной области.

Прикладная система обеспечивает реализацию объектов и операций

предметной области.

Система безопасности и управления доступом

Система безопасности и управлением доступом призвана обеспечить

разграничение прав пользователей системы к ее объектам (операциям и

данным). Она базируется на сервере данных и использует для управления

доступом к объектам БД — таблицам и процедурам — возможности сервера

данных. Для проверки возможности выполнения пользовательских процедур,

которые защищает система, применяется специализированный сервер защиты. Он

реализован в виде сервера приложений.

Основными требованиями, предъявляемыми к системе безопасности и

управления доступом, являются гибкость при определении объектов доступа и

удобство администрирования при управлении доступом. Поэтому была выбрана

матричная система защиты, предусматривающая, что управление доступом

рассматривается как с точки зрения доступа к прикладным объектам системы,

так и относительно доступа к прикладным операциям системы.

Для определения прав пользователя на возможность осуществлять

операции и на доступ к объектам надо построить некую матрицу, узлами

которой являются пересечения требований на доступ к объектам и операциям.

Функциональность системы основана на базовых операциях. Предоставляя

пользователю набор базовых операций, администратор системы определяет тем

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

взгляд на систему. Появляется возможность управлять доступом к объектам,

определяя права на их методы, которыми являются элементарные операции.

Каждая базовая операция использует какой-либо из методов базового объекта

(т.е. какие-либо элементарные операции). Таким образом, доступ пользователя

в системе складывается из его прав на базовые операции и объекты.

Рис.3. Объекты управления доступом.

Для обеспечения эффективной работы администратора системы по

управлению доступом вводится понятие оргштатного элемента, модуля и

способов группировок базовых объектов, базовых операций и самих оргштатных

элементов. Дефиниции всех этих понятий представлены в Таблице 1, а схема

управления — на Рис.3.

Работу системы по организации обобщенных объектов и операций,

построению оргштатной схемы и определению прав оргштатных элементов на

объекты и операции выполняет технолог системы на основе анализа бизнес-

процессов, происходящих в банке. Администратор системы назначает

исполнителей оргштатных элементов из числа штатных сотрудников банка.

Таблица 1

ТЕРМИНЫ И ПОНЯТИЯ, КОТОРЫЕ ИСПОЛЬЗУЮТСЯ

ПРИ РАБОТЕ АДМИНИСТРАТОРА ПО УПРАВЛЕНИЮ ДОСТУПОМ.

|Оргштатный элемент |Это “обезличенный” пользователь системы, для |

| |которого проводится работа по управлению |

| |доступом к операциям и объектам системы. Затем |

| |реальному пользователю выдается право быть |

| |представленным в системе в виде оргштатного |

| |элемента. |

|Модуль |Это характеристика клиентской части системы, |

| |физически объединяющая вызовы базовых операций. |

| |Одна базовая операция может входить в несколько |

| |модулей. |

|Обобщенный объект |Логическое объединение группы базовых объектов. |

| |Это иерархическая структура, “листьями” которой |

| |являются базовые объекты, а “ветвями” — |

| |обобщенные объекты различного уровня |

| |“вложенности”. При управлении доступом |

| |администратор системы манипулирует обобщенными |

| |объектами наравне с базовыми объектами. |

|Обобщенная операция |Логическое объединение группы базовых операций. |

| |Это иерархическая структура, “листьями” которой |

| |являются базовые операции, а “ветвями” — |

| |обобщенные операции различного уровня |

| |“вложенности”. При управлении доступом |

| |администратор системы манипулирует обобщенными |

| |операциями наравне с базовыми операциями. |

|Оргштатная структура |Логическое объединение группы оргштатных |

| |элементов. Это иерархическая структура, |

| |“листьями” которой являются оргштатные элементы,|

| |а “ветвями” — оргштатные подразделения |

| |различного уровня “вложенности”. При управлении |

| |доступом администратор системы манипулирует |

| |оргштатными структурами наравне с самими |

| |оргштатными элементами. |

Ядро системы

Центральное место в ядре системы занимает учетная система. В ее

основе — абстрактная модель бухгалтерского учета с основополагающим

принципом двойной записи. Основными объектами системы учета являются:

- конто;

- показатель;

- журнал;

- проводка.

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

абстрактными счетами учетной системы.

Конто предназначен для аналитического учета однородных банковских

операций с использованием механизма проводок. На внешнем (прикладном)

уровне конто соответствуют лицевые счета (балансовые, внебалансовые, депо),

кассовые символы, бюджетные символы и другие регистры аналитического учета.

Показатель предназначен для синтетического учета, для группировки

аналитики при формировании отчетности и анализа. На внешнем уровне

показателям соответствуют счета I—II порядков, разделы Плана счетов ЦБ,

символы отчетности различных форм.

Структура показателей и конто строится на основе иерархии

неограниченного уровня вложенности.

Журнал — это объединение показателей, имеющих один экономический

смысл.

Примерами журналов могут быть главы Плана счетов ЦБ (“Балансовые

счета”, “Внебалансовые счета”, “Счета депо”), список символов кассовой

отчетности, формы отчетности по Инструкции № 17 и т.д.

Проводки формируют состояния конто — хранящиеся в системе обороты по

дебету и кредиту, остаток. Состояния показателей рассчитываются на основе

их отношения к конто.

При выполнении операций над проводками фиксируются время ввода,

планирования, подтверждения планирования и фактического учета. При помощи

этого механизма ведется фактический и позиционный учет операций. Для

реализации алгоритмов учетной системы используются процедуры и таблицы

сервера данных. В состав модулей системы учета входят модули клиентской

части, которые обеспечивают диалоговый режим создания и применения счетов.

В основном это модули технолога системы, которые позволяют:

- осуществлять ведение структуры объектов учетной системы;

- организовывать доступ для проведения аудита ко всем счетам и проводкам

системы учета независимо от их прикладного применения.

Интерфейс модулей технолога представляет журналы, показатели, конто и

проводки в терминах прикладной области.

Форма хранения документов и форматированный документ позволяют

автоматизировать обработку посредством выборки данных, которые передаются в

учетную систему и в прикладную систему (для компоненты поддержки

документооборота).

При обработке документа транзитная система формирует обращения к

учетной системе — как при выполнении операции, так и при ее откате. В этой

системе присутствуют правила учета, которые определяют состав проводок и их

атрибуты, а также фонд счетов, переводящий внешнее представление счетов в

идентификаторы конто учетной системы. Кроме того, в транзитной системе

хранится история движения документа, фиксирующая переходы документа из

одной стадии обработки в другую. Транзитная система получает результаты

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

Прикладная система

Компонента поддержки документооборота — самая важная в прикладной

системе. В ее состав входят: документ, картотека и портфель.

Взгляд на систему обеспечения документооборота достаточно подробно

освещен в одноименном разделе статьи В.Чаусова “Концептуальное построение

банковской системы” [5].

В нашей статье понятие “папка” заменено на понятие “картотека”.

Картотеки (в отличие от папок) имеют некоторые ограничения, в частности:

- их количество в системе конечно;

- пользователи системы не могут создавать и уничтожать их;

- разрешенные перемещения документа из одной картотеки в другую заранее

прописываются технологом системы;

- обращение к транзитной системе для инициирования проводок в системе

учета происходит при перемещении документа из картотеки в картотеку.

Картотека объединяет документы, находящиеся на одной стадии обработки

(скажем, лицевые счета картотеки № 2).

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

документы связаны между собой (подчеркнем, однако, что на взаимодействие

прикладной системы с транзитной и учетной он не влияет). Примером портфеля

может служить совокупность документов, относящихся к кредитному договору:

собственно договор, соглашение о пролонгации, графики погашения платежей,

платежные документы, сопровождающие его выполнение и др.

Взаимодействие прикладной системы с учетной в процессе движения и

обработки документа представлено на Рис. 4.

Любая операция по обработке документов начинается с ввода документа в

систему. Затем компонента обеспечения документооборота прикладной системы

выполняет перемещение документа из одной картотеки в другую, одновременно с

этим документом совершаются определенные операции. Когда в составе этих

операций есть учетные, система обращается к транзитной системе, которая, в

свою очередь, формирует запрос к учетной системе для формирования проводок

и изменения состояния конто.

Рис. 4. Процесс обработки документа.

У прикладной системы довольно сложная клиентская интерфейсная часть,

отображающая движение документов по картотекам с учетом специфики

реализуемой функциональности.

Модули клиентской части и процедуры сервера данных обеспечивают как

выполнение операций над документом, так и информационный сервис по

документообороту.

Компонента представления учетной системы дает (независимо от

документооборота) возможность доступа к системе учета в пределах,

необходимых конкретной прикладной подсистеме.

Компонента справочников и классификаторов — вспомогательная. Основное

ее назначение — осуществлять учет всех остальных объектов банковской

системы, т.е. тех, которые не являются ни документом, ни счетом. К этим

объектам относятся анкетные данные о клиентах, классификаторы банков-

корреспондентов, информация о валютах (в том числе об их курсах), сведения

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

Для каждого из этих объектов предусмотрены по две группы программных

модулей: одна отвечает за создание и поддержку объектов, другая является

модулями использования объектов.

Первая группа модулей обеспечивает ввод данных об объектах в систему,

их сохранение, модификацию и удаление. Для некоторых объектов (среди них

анкетные данные, курсы валют и т.д.) ведется история изменения их

состояний, что требуется для правильного выполнения алгоритмов, связанных с

обработкой счетов (заметим, что состояние счета или его позиция — это тоже

история изменения состояний). К истории состояний объектов обращаются и в

том случае, если необходимо подготовить отчетность за какой-либо период.

Вторая группа модулей предназначена для использования данных об

объектах программами организации интерфейса пользователя, процедурами

подготовки отчетов, а также операциями обработки документов в системах

обеспечения документооборота и учетных системах. Многие объекты из

классификаторов и справочников являются объектами аналитического учета.

Поэтому документы и счета в своих структурах хранят ссылки на эти объекты и

Страницы: 1, 2, 3