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

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

1 января 1998 г. на какой-то неопределенный срок. Ассоциация российских

банков даже обратилась в Банк России с просьбой перенести переход на начало

второго квартала(!). Не дай Бог, если эта просьба будет удовлетворена. Тогда

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

— и это дос­таточно очевидно — всякие изменения в бухгалтерском учете гораздо

легче ввести с начала года, чем с начала квартала.

Новый план счетов и АБС

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

потребует обязательной замены или модернизации АБС практически во всех

отечественных банках. Дело в том, что изменяется не только План счетов, но и

сама методология бухгалтерского учета, причем в нормативных документах ЦБ РФ

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

систе­мах автоматизации, которые сегодня работают в наших банках, этих

функций про­сто-напросто нет. Поэтому современная ситуация на рынке

напоминает ту, которая сложилась в 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 и т.д.

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

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

к конто.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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