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