Автор: Пользователь скрыл имя, 14 Декабря 2011 в 15:26, реферат
Современное денежно-кредитное и финансовое хозяйство страны пе¬ре¬жи¬вает серьезные изменения в структурном отношении. Пере¬страи¬вается кре¬дитная система, возникают новые виды кредитно-фи¬нансовых институтов и операций, модифицируется система отношений центральных Банков и фи¬нан¬сово-кредитных институтов, складываются иные пропор¬ции в динамике госу¬дарственного и част-ного сектора.
Несмотря на существующие недостатки российского законодательства, ре-гулирующего деятельность банков, ситуация неуклонно меняется к лучшему.
Существенные изменения происходят и в функционировании бан¬ков: по-вышается их самостоятельность, роль в сельском хозяйстве, рас¬ши¬ряются функции действующих и создаются новые финансово-кредит¬ные институты; идет поиск пу-тей повышения эффективности банков¬ского об¬служивания, оп¬ти¬мального разгра-ничение сфер деятельности и функций специализированных банковских учрежде-ний.
Все эти процессы являются причинами усложнения управленческих и учетных функций внутри коммерческих банков. Отсюда повышение требований к финансовому программному обеспечению, которое используют коммерческие банки. Разработчики этого программного обеспечения вынуждены постоянно осуществлять изменение своих продуктов, едва успевая за последними изменениями законодательства.
Фактор
«несовременности» является наиболее
очевидной проблемой и чаще других
сегодня характеризует
Итак, требования к финансовым системам за последние год-два существенно возросли. Теперь все хотят иметь масштабируемые и переносимые системы, которые могли бы функционировать не на какой-то одной, а целом ряде популярных СУБД и на целом ряде сетевых операционных систем. Все интересует возможность доступа через глобальную сеть Интернет. Многим очень интересна возможность создание графической отчетности, наличие элементов бизнес графики, а также возможность работы с графической информацией, например, хранение фотографий физических лиц, образцов их подписей и т.д.
Проблема интеграции программных продуктов одного разработчика всегда стояла остро, и до сих пор она окончательно не решена. Основными методами решения этой проблемы были взаимодействие систем на уровне экспорта и импорта данных, через какой либо текстовый файл, либо непосредственный доступ одной системы к базе данных другой. Все эти методы не обеспечивают достаточного уровня надежности, а самое главное – безопасности.
Все перечисленные задачи очень трудно, а зачастую и невозможно решать на том поколении инструментальных средств, которыми пользуются сегодня большинство фирм – разработчиков. Эти инструментальные средства реализованы для платформы MS-DOS и уже значительно устарели. Поэтому современные программные средства должны соответствовать вышеперечисленным требованиям.
2.2 Классификация современных автоматизированный банковских систем
Как построить эту классификацию? Кто в ней заинтересован? Для кого она предназначена?
Наверное, для тех, кто работал, и будет работать с банковскими технологиями. Конечно же, в первую очередь, это — сотрудники кредитных учреждений, выбирающие себе стратегического партнера по автоматизации. Присматриваясь к своей будущей АБС, банку, наряду с предоставляемым при поставке программного продукта сервисом на единицу денежных затрат, а также финансовым положением и репутацией компании-поставщика и разработчика, необходимо оценить технический и технологический уровень приобретаемого программного комплекса и перспективы его дальнейшего развития.
В условиях стремительного развития банковских систем, односторонний («векторный») подход к классификации не совсем оправдан, так как помимо используемых СУБД и технологических решений есть и много других параметров, не менее важных при классификации АБС.
Такими параметрами могут быть, например:
1.
«Базовый объект» при
2. Уровень реализации банковских технологий:
3. Уровень защиты информации:
4. Функциональная полнота:
5.
Работа с филиалами и
6.
Использование встроенных
Возможны и другие критерии оценки.
Вероятно, что в дальнейшем при классификации автоматизированных банковских систем будет использован комплексный («матричный») метод, основанный на выборе группы критериев, определяющих множество возможных значений классификации. Совокупность значений критериев для оцениваемой АБС с помощью определенной функции преобразуются в сводный интегральный показатель — так называемый Классификатор «поколение АБС». Таким образом, полагаю, можно достичь наиболее полной «достоверности» классификации. При использовании «матричного» подхода разработчик-аналитик должен определить следующие параметры модели:
Основные классифицирующие признаки
технологических
поколений АБС
Технологическое поколение АБС | Основной классифицирующий признак |
I | Персональная СУБД в автономном режиме |
II | Персональная СУБД в сетевом режиме |
III | Менеджер записей Btrieve |
IV | Профессиональная СУБД |
V | Менеджер транзакций |
VI | Компонентная технология |
Возможно,
что такой подход внесет новый импульс
в систематизацию современных АБС — классификация
программных продуктов, станет более сложной
и разветвленной, а также будет учитывать
различные характеристики и параметры.
2.3
Сравнительная оценка
АБС
Сравнительная оценка банковских систем из-за их разнородности является сложным процессом. Она включает оценку архитектуры систем, базовых программных средств (от MS DOS до Unix), функциональных возможностей.
Недолгая история развития отечественных банковских систем показывает, что в функциональном плане в целом, они соответствуют развитию банковского дела в стране. Большинство эксплуатируемых в настоящее время систем являются DOS-комплексами. Несмотря на недостатки такого рода систем они функционируют в большинстве банков.
Раскроем существо этих недостатков.
Прежде
всего недостаточная
Другим существенным недостатком является невозможность обеспечения безопасности данных на должном уровне. Эта проблема в ряде случаев может быть устранена организационно-техническими методами: установкой источников бесперебойного питания, тщательным соблюдением регламента системных работ, персональным контролем использования вычислительных средств.
Отрицательным фактором может быть признана также ограниченность архитектуры средств. Эта проблема возникает, когда для реализации тех или иных банковских операций необходимо обеспечить взаимодействие нескольких протяженных во времени процессов. В рамках DOS эта проблема обычно решается выделением под каждый процесс станции локальной сети. Такое решение может иметь ограничения.
Как правило, недостатки DOS-комплексов проявляются на этапе перехода банка в класс выше среднего. DOS-системы покрывают сегодняшние потребности многих малых и средних банков, являясь приемлемым компромиссом малой стоимости и ограниченных возможностей. Эти системы отражают средний уровень развития банковской практики в стране.
В качестве ступени, следующей за DOS – комплексами, можно рассматривать системы, работающие под ОС Windows. Наибольшую эффективность имеют системы построенные в архитектуре ’клиент- сервер’, в рамках ’Novell Net Ware’.
Под сервером при этом понимается логическая процедура, которое обеспечивает обслуживание поступающих к нему запросов. Клиентами сервера являются процессоры ПЭВМ, посылающие серверу запросы на тот или иной вид обслуживания. Задачей клиента является установление связи с сервером, формирование запроса конкретного вида на обслуживание, получение результатов и подтверждения процесса обслуживания.
Связь между клиентом и сервером в конкретной банковской системе может быть реализована различными способами: с помощью локальной или глобальной или вычислительной сети, путем применения поименованных каналов, совместно используемой ’памяти’ системы, установлением связи между задачами, посредством стандартных протоколов обмена и т.д. Примером технологии с архитектурой ’клиент – сервер’ являются сетевые базы данных с реализацией стандартного языка запросов SQL.
’Клиент – сервер’ включает в себя два типа процессоров: клиентские, исполняемые под управлением DOS (или другой ОС), на рабочей станции, и серверный, в качестве которого может выступать ’Btrieve’ Record Manager на сетевом сервере. Клиент, процессоры на рабочих станциях, вырабатывают запросы к базе данных, которые поступают в сервер ’Net Ware’ и обрабатываются в программе ’Btrieve’. При этом рабочие станции только формируют запрос и получают ответ, а все процессы обработки информации в базе данных осуществляются на сервере в программе ’Btrieve’.
Заключение
Автоматизированные банковские системы часто разрабатываются под потребности потребителей, по индивидуальному заказу с полным сопровождением в ходе формирование “гибкой” банковской технологии.
В реальной практике трудно сделать типовой программный продукт, поскольку спектр потребностей и услуг у разных банков не совпадает. Однако в любом случае автоматизированная система должна поставить преграду против “виртуозного мастерства” некоторых бухгалтеров, позволяющего представить финансовое положение банка не так, как оно есть в действительности.
Совершенствование банковской бухгалтерской информации и создание универсальной банковской системы автоматизации окажут влияние на дальнейшее укрепление надежности банковской системы в целом. Направление работ в этой области становятся особенно актуальными в связи с существующей тенденцией по созданию системы раннего выявления банков, находящихся в предкризисном состоянии, которая позволит выявить такие банки на более ранней стадии, вести мониторинг, учитывая достаточность капитала, уровень управляемости текущей ликвидностью и результаты финансовой деятельности.