Файл: Автоматизированные системы в банковской деятельности.pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 29.03.2023

Просмотров: 556

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

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

Таким образом, в АБС должна входить аналитическая подсистема, которая обеспечивает сбор, обработку и агрегирование информации, ее анализ в соответствии с требования Центробанка.

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

Развитие и внедрение АБС в России началось с 1990 г., т. к. до этого банковской системы как таковой не существовало. В Советском Союзе был только один банк и весьма ограниченный набор стандартных банковских операций. В центральном отделении банка широко использовалась вычислительная техника, была развита система безналичных расчетов между предприятиями. [14, с. 32]

Начиная с 1990-х гг. в связи с реформой банковской деятельности и созданием коммерческих банков появляются и первые автоматизированные банковские системы.

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

Развитие автоматизации банковских технологий в нашей стране имело несколько этапов. [19]

Быстрый рост числа акционерных и частных предприятий и банков позволил некоторым компаниям увидеть здесь будущий рынок и инвестировать средства в создание программного аппарата для этого растущего рынка. Из всего спектра проблем разработчики выделили наиболее значимые: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов. Для банков это в основном расчетно-кассовое обслуживание, для промышленных предприятий — автоматизация процессов проектирования и производства (имеется в виду не конкретных станков и т. п., а информационных потоков). Учитывая тот факт, что ядром АИС, безусловно, является аппарат, обеспечивающий автоматизированное ведение аналитического учета, большинство фирм начали с детальной проработки данной проблемы. Системы были спроектированы «сверху», т. е. в предположении, что одна программа должна удовлетворять потребности всех пользователей. [10 с. 78]


Сама идея использования «одной программы для всех» резко ограничила возможности разработчиков в структуре информационных множеств базы данных, использовании вариантов экранных форм, алгоритмов расчета и, следовательно, лишила возможности принципиально расширить круг решаемых задач — автоматизировать повседневную деятельность каждого работника. Заложенные «сверху» жесткие рамки («общие для всех») ограничивали возможности таких систем по ведению глубокого, часто специфического аналитического и производственно-технологического учета. Работники проводили эту работу вручную, а результаты вводили в компьютер. При этом интерфейс каждого рабочего места не мог быть определен функциями, возложенными на пользователя, и принятой технологией работы. Стало очевидно, что для успешной реализации задачи полной автоматизации банка следует изменить идеологию построения АИС.

Развитие банковских структур и промышленных предприятий, увеличение числа филиалов, рост количества клиентов, необходимость повышения качества обслуживания предъявляли к автоматизированным системам новые требования. Новый подход к проектированию АИС заключается в сбалансированном сочетании двух предыдущих. В первую очередь это относилось к идеологии построения ядра системы: «Автоматизированная бухгалтерия — аналитический учет».

Для банковских структур это дало: с одной стороны, в ядре системы сохранялась возможность работы «от лицевого счета», с автоматическим формированием соответствующих бухгалтерских проводок, с другой — отменялись жесткие требования работы только с лицевыми счетами. Появилась возможность ведения бухгалтерского учета по балансовым счетам любого порядка без углубления до уровня лицевых счетов клиентов. При этом ведение аналитического учета по лицевым счетам клиентов опускалось на уровень специализированного программного обеспечения (СПО), установленного на рабочих местах банковских работников (контролеров, кредитных бухгалтеров, инспекторов и т. д.). Таким образом, принципиальное отличие нового подхода к созданию АБС заключается в идее распределения плана счетов по уровням экспертизы. При этом и сам справочник плана счетов с соответствующими описаниями, и информационное множество клиентов проектировались по принципу распределенной базы данных. Результатом этого явилось: [17]

  • формирование всех необходимых бухгалтерских проводок, уже агрегированных по балансовым счетам, и автоматическая передача их в базу данных «автоматизированной бухгалтерии»;
  • реализация специфических требований каждого банковского работника, в том числе по формированию произвольных отчетов и справок, мемориальных ордеров, операционных дневников; выполнение любых вспомогательных и технологических расчетов и пр. 

С использованием гибкой системы настроек СПО (компонентов АБС) появилась реальная возможность адаптации программного аппарата к практически любым условиям и различным требованиям инструктивных материалов и правилам работы, принятым либо в вышестоящей организации, либо в данном банковском учреждении. Кроме того, при многокомпонентной схеме организации АБС при проведении модернизации одного из компонентов центральная часть (ядро) АБС и другие ее компоненты не затрагивались, что значительно повышало надежность, продолжительность жизни автоматизированной системы и обеспечивало наиболее полное выполнение требуемых функций. [7]

Двойственный подход к формированию ежедневного баланса лег в основу так называемого «принципа дуализма» — одного из важных принципов построения современных банковских систем. Реализация принципа дуализма неизбежно требовала построения АБС нового поколения в виде программных модулей, органически связанных между собой, но в то же время способных работать и автономно.

Такая многокомпонентная система обеспечивала соблюдение основополагающего принципа построения автоматизированных информационных систем — отсутствия дублирования ввода исходных данных. Информация по операциям, проведенным с применением одного из компонентов системы, могла быть использована любым другим ее компонентом. Модульность построения АИС нового поколения и принцип одноразового ввода дают возможность гибко варьировать конфигурацией этих систем. Так, в банках, имеющих разветвленную филиальную сеть и не передающих данные в режиме реального времени, установка всего СПО во всех филиалах не всегда экономически оправданна. В этих случаях возможна эксплуатация в филиалах ПО общего назначения, предназначенного для первичного ввода информации и последующей автоматизированной обработки данных в СПО, установленном в головном офисе банка. Такая структура дает возможность органически включить в АБС нового поколения компонент для создания хранилища данных, разделяя системы оперативного действия и системы поддержки принятия решения. [6, с. 90]

Кроме того, одно из достоинств принципа многокомпонентности, являющегося базовым при создании АИС нового поколения, состоит в возможности их поэтапного внедрения. На первом этапе внедрения устанавливаются (или заменяются уже устаревшие) компоненты системы на те рабочие места, которые нуждаются в обновлении ПО. На втором этапе происходит развитие системы с подсоединением новых компонентов и отработкой межкомпонентных связей. Возможность применения такой методики внедрения обеспечивает ее достаточно простое тиражирование и адаптацию к местным условиям. Таким образом, автоматизированная информационная система нового поколения — это многокомпонентная система с распределенной базой данных по уровням экспертизы. [16, с. 93]


Первоначально это были достаточно простые программные продукты, которые автоматизировали отдельные аспекты банковской деятельности на базе традиционных СУБД. Процесс автоматизации банковских технологий перешел на новый этап в конце 1980-х начале 1990-х гг. Это напрямую связано с банковской реформой 1989 г., когда на рынке банковских услуг появились коммерческие банки (КБ). [17, с. 89]

На первых этапах многие банки разрабатывали системы автоматизации своими силами. Каковы преимущества собственной разработки:

  • Во-первых, это, конечно, относительно низкая стоимость таких разработок (по сравнению с покупными). Как правило, к существующим подразделениям департамента информатизации, таким как управление эксплуатации, управление эксплуатации вычислительной сети и средств связи, экспертно-аналитическое управление (постановка задач), добавляется лишь новая структура — управление развития и разработки АИС, что, как правило, не влечет за собой больших финансовых затрат;
  • Во-вторых, собственная разработка — это максимальная ориентация на реализацию бизнес-процессов предприятия или банка, его уникальных финансовых и управленческих технологий, складывающихся годами;
  • В-третьих, это позволяет обеспечивать значительно более высокий уровень безопасности и независимости от внешних факторов;
  • В-четвертых, оперативная реакция на изменения правил игры на рынке.

Однако для использования собственной разработки необходимо решить ряд проблем, которые определяют ее надежность и перспективность:

  • Во-первых, правильный выбор архитектуры построения вычислительно-коммуникационной сети и ориентация на профессиональные СУБД. По экспертным оценкам, собственные разработки АИС в 53 % случаев базируются на СУБД Oracle, приблизиельно в 15 % — на Informix, в 22 % — другие СУБД. [9]
  • Во-вторых, использование при разработке современного инструментария (CASE средства, эффективные средства разработки: Delphi, Designer2000, Developer2000, SQL-Stations и т. п.).
  • В-третьих, мультизадачная инфраструктура разработки проекта, когда конкретный модуль АИС ведет группа разработчиков с взаимосвязанным перечнем задач, построенная на принципах полной взаимозаменяемости, т. е. функционирование данного модуля АИС и его развитие не связаны с одним конкретным разработчиком. [9]
  • В-четвертых, применение эффективных организационно-технических средств по управлению проектом и контролю версий АИС.

Только при соблюдении этих основных положений можно рассчитывать, что собственная разработка окажется конкурентной и эффективной. В противном же случае можно столкнуться с эффектом «неоправданных ожиданий» — это в лучшем случае, а в крайнем случае — вообще задуматься о смене АИС. При этом смена АИС может как вызвать непосредственно смену клиентских модулей и табличной структуры БД, так и потребовать замену серверного и клиентского аппаратного и общесистемного программного обеспечения, включая СУБД, а это дело не дешевое. Поэтому очень важно при выборе варианта реализации АИС сразу решить вопрос о возможностях экспорта/импорта данных в создаваемой системе. При правильном решении данного вопроса смена АИС, если в ней все-таки возникнет необходимость, произойдет практически безболезненно для функциональных подразделений.


С развитием финансового и фондового рынков сфера деятельности КБ расширялась, возрос и объем перерабатываемой информации. [9]

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

В силу различия банков по размерам, структуре, используемой методологии, т. е. по всем тем параметрам, которые в первую очередь характеризуют банк как объект приложения информационных технологий, расширился круг используемых ими АБС.

Поэтому в настоящее время в России выделяют пять поколений банковских систем. [6, с. 91]

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

Таблица 1 - Поколения АБС

Поколение

Аппаратная платформа

СУБД

Базовый элемент технологии

Структура АБС

ПК MS DOS

Clipper, foxpro, Clarion

Бухгалтерская проводка

Автономные АРМ, не связанные обмен файлами через перенос на носителе

ПК MS DOS + локальная сеть под Novell Net Ware

Clipper, foxpro, Clarion

Бухгалтерская проводка

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

3

ПК MS DOS Widows + локальная сеть под Novell Net Ware (Windows NT)

Btrive

Бухгалтерская проводка + документ

Автономные АРМ, связанные данными через файлы на сервере, слабо связанные по функциям. Переходная технология «файл-сервер» «клиент-сервер»

ПК MS DOS Widows + локальная сеть Windows NT

Профессиональная реляционная СУБД (MS SQL Server, Oracle, System, DB2, informix)

Бухгалтерская проводка + документ + сделка

Автономные АРМ, сильно связанные данными через общую БД, связанные по функциям через общее ядро. Архитектура «клиент-сервер» или «хост-терминал»

5

ПК ms windows + распределенные сети с несколькими выделенными физическими серверами приложений, работающими под многозадачными многопользовательскими ОС

Профессиональные реляционные или постреляционные СУБД (MS SQL Server, Oracle, System11, DB2, informix) + менеджеры транзакций

Документ или сделка

Логические АРМЫ, сильно связанные по данным и функкциям. Архитектура трехуровневая «Application Server», сервер приложений

Таблица составлена на основании источников: 6,7, 8.