рефераты бесплатно

МЕНЮ


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ядро системы

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

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

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

- конто;

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

- журнал;

- проводка.

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

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

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

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

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

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

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

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

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

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

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

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

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

смысл.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

обращаются к системе справочников и классификаторов за сервисом — и,

получив значения объектов, указывают их в этих ссылках.

3. ОСНОВЫ АВТОМАТИЗАЦИИ БАНКОВСКОЙ

ДЕЯТЕЛЬНОСТИ

3.1. СИТУАЦИЯ НА РЫНКЕ БАНКОВСКИХ ТЕХНОЛОГИЙ

Сегодняшняя банковская система России характеризуется:

- усилием конкурентной борьбы между банковскими консорциумами на всех

текущих рынках и борьбы за новые рынки;

- слиянием банков, поглощением крупными банками мелких;

- прекращением деятельности ряда мелких банков.

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

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

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

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

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

ступеньку выше, а со временем – на следующий уровень банковской иерархии

России, выйти на мировой рынок услуг.

На Российском рынке АБС помимо широко известных фирм производителей

DIASOFT и RS-BANK можно встретить и менее известных таких как БИСквит,

МИМ-Технология, ГАМБИТ, SC-Банк, IB-System. Практически все они АБС III

поколения (использование менеджера записей BTRIVE, сетевая технология).

Для роста нужна высококачественная база. Ее составляют, наряду с

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

технологиями, еще и инструменты, с помощью которых эти инструменты

реализуются. Одним из инструментов является современная информационная

система.

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

использует. Случаям, когда ожидавшийся сразу вслед за приобретением новой,

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

числа. Да и в редкость ли случаи, когда такое дорогостоящее и долгожданное

приобретение, столь, успешно, вроде бы, работающее у соседа, не оправдывает

ожидание?

Российский банковский рынок сегодня, прежде всего активно меняющейся

рынок. Количество его участников стремительно сокращается. Банковская

система России планомерно движется к структуре, которая во многих странах

сложилась уже давно. Постоянные изменения в банковском законодательстве

свидетельствуют о стремлении Центрального Банка усилить контроль над

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

качественный уровень.

Все эти процессы являются причинами усложнения управленческих и

учетных функций внутри коммерческих банков. Отсюда повышение требований к

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

банки. Разработчики этого программного обеспечения вынуждены постоянно

осуществлять изменение своих продуктов, едва успевая за последними

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

Фактор «несовременности» является наиболее очевидной проблемой и чаще

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

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

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

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

легко диагностируются. Например, если в качестве принципиально новых

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

«мультивалютный операционный день», «реальный масштаб времени» или что-то в

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

как минимум, устарела уже к моменту ее выхода на рынок.

Итак, требования к финансовым системам за последние год-два

существенно возросли. Теперь все хотят иметь масштабируемые и переносимые

системы, которые могли бы функционировать не на какой-то одной, а целом

ряде популярных СУБД и на целом ряде сетевых операционных систем. Все

интересует возможность доступа через глобальную сеть Интернет. Многим очень

интересна возможность создание графической отчетности, наличие элементов

бизнес графики, а также возможность работы с графической информацией,

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

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

стояла остро, и до сих пор она окончательно не решена. Основными методами

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

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

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

достаточного уровня надежности, а самое главное – безопасности.

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

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

большинство фирм – разработчиков. Эти инструментальные средства реализованы

для платформы MS-DOS и уже значительно устарели. Поэтому современные

программные средства должны соответствовать вышеперечисленным требованиям.

3.2 КЛАССИФИКАЦИЯ СОВРЕМЕННЫХ

АВТОМАТИЗИРОВАННЫХ БАНКОВСКИХ СИСТЕМ

Как построить эту классификацию? Кто в ней заинтересован? Для кого она

предназначена?

Наверное, для тех, кто работал, и будет работать с банковскими

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

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

Присматриваясь к своей будущей АБС, банку, наряду с предоставляемым при

поставке программного продукта сервисом на единицу денежных затрат, а также

финансовым положением и репутацией компании-поставщика и разработчика,

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

программного комплекса и перспективы его дальнейшего развития.

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

(«векторный») подход к классификации не совсем оправдан, так как помимо

используемых СУБД и технологических решений есть и много других параметров,

не менее важных при классификации АБС.

Такими параметрами могут быть, например:

1. «Базовый объект» при построении технологий обработки бизнес процессов:

- проводка;

- документ;

- банковский продукт.

2. Уровень реализации банковских технологий:

- с жестко заданным набором определенных технологий;

- с возможностью работать с разными банковскими технологиями

(универсальная АБС).

3. Уровень защиты информации:

- криптозащита;

- криптозащита и трехуровневая модель обработки данных;

- криптозащита, трехуровневая модель;

- другие средства защиты.

4. Функциональная полнота:

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

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

- поддержка широкого спектра банковских продуктов;

- включение новейших банковских технологий («Home Banking», «Internet»,

«телефонного банка», видеоконференций и т.д.).

5. Работа с филиалами и удаленными площадками:

- на основе распределенной базы данных с off-line-репликацией;

- на основе единой базы данных.

6. Использование встроенных средств разработки:

- генератора отчетности;

- макроязыка;

- генератора объектов;

- других CASE-средств.

Возможны и другие критерии оценки.

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

банковских систем будет использован комплексный («матричный») метод,

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

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

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

показатель — так называемый Классификатор «поколение АБС». Таким образом,

полагаю, можно достичь наиболее полной «достоверности» классификации. При

использовании «матричного» подхода разработчик-аналитик должен определить

следующие параметры модели:

- наиболее адекватные критерии оценки;

- формальные взаимосвязи между этим критериями;

- значения выбранных критериев оценки;

- значения Классификатора «поколение АБС»;

- функции (математические или продукционные), определяющие получение

интегрального показателя (в нашем случае - это показатель «поколение

АБС»). В таблице 8 представлены основные классифицирующие признаки

технологических поколений АБС.

Таблица 2

Основные классифицирующие признаки

технологических поколений АБС

|Технологическое поколение|Основной классифицирующий признак |

|АБС | |

|I |Персональная СУБД в автономном режиме |

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


Copyright © 2012 г.
При использовании материалов - ссылка на сайт обязательна.