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

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

Неизбежен передел рынка АБС: с него уже ушли некоторые фирмы, например «АСОФТ» (не путать с «АСофт», которая благополучно продолжает существовать) или «VIMCOM». По-видимому, понесут некоторые потери такие заслуженные разработчики, как «Инверсия», «ПрограмБанк», «ЛИМ», чьи 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