Учебная работа. Реферат: Банковские информационные системы

Кафедра информационных систем и технологий в экономике и управлени

Самостоятельное задание

по дисциплине

«Информационные системы»

на тему:

«
Банковские информационные системы
».

Выполнил:

Студент 3-го курса

Группы №6293

Валин Ф. Н.

Проверил:

проф. Широков Л. А.

— Москва 2003 г. —

ОГЛАВЛЕНИЕ.

Введение…………………………………………………………………………………………………………….
3

1.
Архитектура системы и реализация главных функций
…………….
5

1. 1. Глобальный уровень
……………………………………………………………………………….
6

1. 2. Уровень менеджера. Функции управления банком.
………………..
7

1. 3. Уровень агентов
………………………………………………………………………………………
11

2.
Решения, применяемые при разработке банковской системы автоматизации
………………………………………………………………………………………………….

12

3.
Требования к банковской информационной системе и принципы разработки программных средств
………………………………………………………….

13

4.
структура условной встроенной информационной системы


17

5.
Межбанковские взаимодействия и коммуникации
……………………..

25

Заключение
……………………………………………………………………………………………………..

31

Перечень применяемой Литературы.

1. Банковские технологии. № 7-8 , 1997.

2. Информационные технологии. № 2 , 1997.

3. Международные банковские эталоны. Под. ред. С. И. Кумок. -М.: Столичное финансовое объединение , 1995.

4. InterNet

Введение.

Исходя из убеждений банковских экспертов и их клиентов банк является денежным учреждением. Но исходя из убеждений телекоммуникационных профессионалов инфы. Денежные и валютные процессы, протекающие в банке, могут и должны быть интерпретированы как процессы обработки, хранения и переноса инфы. Это относится в равной мере как к расчётным действиям, манипулирующими информацией о состоянии счетов клиентов, так и к действиям управления банком и принятия решений в сфере, к примеру, кредитной либо дилинговой деятель. В особенности ярко таковая интерпретация проявляет себя при переходе банков, делового мира и всего общества на новейшие способы валютного воззвания, когда кредитные и дебетовые карты, банкоматы, электрическое сервис клиентов и остальные подобные процессы ведет к тому, что все платёжные, расчётные и остальные денежные процедуры не будут нуждаться в картонных деньгах и документах, а будут заключаться в компьютерной обработке и передаче инфы . Имея в виду такую перспективу, недозволено переоценивать роль компьютерных информационных систем и компьютерных телекоммуникаций в банковском деле. С данной точки зрения обширно понимаемая неувязка управления становится главный в обеспечении эффективности и надёжности работы банка, конкретно её высококачественное решение обусловит в итоге его жизне- и конкурентоспособность.

При формировании концепции управления и выборе базисных средств желательно применять и учесть имеющиеся международные эталоны и советы в данной области. Эти советы суммируют скопленный опыт управления локальными, глобальными сетями и интерсетями на их базе, выделяют главные многофункциональные области сетевого управления, определяют архитектуру, информационную базу и протоколы сетевого управления. Внедрение обычных способов и средств управления дозволяет обеспечивать сопоставимость аппаратно-программных средств, разработанных разными изготовителями.

Международные советы определяют последующие главные области сетевого управления:

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

* управление учётом — учёт и контроль использования системных ресурсов и определение их цены, оповещение юзеров о потребляемых ими ресурсах, тарификация, ведение счетов и установление лимитов на внедрение тех либо других ресурсов;

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

* управление эффективностью — оценка эффективности функционирования системных ресурсов, сбор статистической инфы о работе сетевых объектов, её анализ и обработка, прогнозирование эффективности работы системы и планирование её развития. Эффективность работы системы тесновато связана с управлением дефектами, потому что для действенной работы требуется если не вполне убрать отказы, то, во всяком случае, уметь предсказывать и сводить к минимуму их последствия;

* управление сохранностью — управление аутентификацией, полномочиям, доступом, засекречиванием и обеспечением целостности передаваемой, обрабатываемой и хранимой инфы;

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

— сетевое управление — мониторинг сетевых устройств и управление ими;

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

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

К более развитым базисным средствам построения систем управления следует отнести:

* OpenView+IT operation/administration компании Hewlett-Packard ;

* Sun Connect SunNet Manager компании Sun Solution ;

* Tivoli компании IBM ;

* SMS компании Microsoft ;

Любой из этих товаров является красивым средством построения системы управления, имеющим широкий диапазон внедрения и развития приложения. Но, на мой взор, 1-ые два продукта нацелены в главном на решение задачки сетевого управления и в наименьшей степени затрагивают вопросцы системного управления, а 2-ые два, созданные для решения как задач сетевого, так и системного управления, ограничены довольно твердыми рамками или определенной области внедрения, или применяемых платформ (операционные системы, СУБД, технические средства) .

Сейчас требуется система управления компанией, которая создавала бы полный эффект присутствия админа на любом рабочем месте и позволяла централизованно решать текущие задачки по управлению конфигурацией и оперативному устранению возникающих заморочек. Попробуем перечислить перечень требований к системе подобного типа и способы их реализации .

1.




Архитектура системы и реализация главных функций.

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

— уровень глобального отображения — поддержка интегрированного пользовательского интерфейса и ведение репозитария общих объектов;

— уровень управления банком, либо уровень менеджеров — управление информационными действиями, происходящими во всех субъектах информационно-телекоммуникационной инфраструктуры компании;

— уровень агентов — наблюдение и контроль за всеми элементами информационно-телекоммуникационной инфраструктуры банка.

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

Особо необходимо подчеркнуть, что система обязана владеть довольно широким набором функций управления, которые за счёт интеграции с инфраструктурой системы и вместе обеспечивают высочайший уровень управления банком. Система обязана допускать предстоящее развитие и улучшение этих функций. Расширяемость — прямое следствие объективно-ориентированной природы системы, так как все управляемые объекты определены в репозитарии общих объектов, а методы управления им вполне документированы .

Высочайшая степень масштабируемости обязана позволять настраивать систему на задачки определенного бизнеса, используя сети TCP/IP, SNA, DECnet и IPX, мейнфреймы IBM операционные системы VMS , OS/400 , NonStop Kernel , Unix , Windows NT и Windows 95 .

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

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

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

— маневренность хоть каким ресурсом системы независимо от его месторасположения;

— «дружеский» трёхмерный графических интерфейс юзера.

В итоге юзер получает в руки инструмент, позволяющий визуализировать объект управления и управлять им на трёх уровнях: глобальном (система в целом), банка либо менеджера (управление бизнес действиями), агентском (управление программными и техническими средствами).

1. 1.




Глобальный уровень.

На верхнем уровне объектно-ориентированной архитектуры системы реализуется графический интерфейс настоящего мира, при помощи которого управляющие приложения распознают подчинённые им ресурсы и устанавливают связи. Для отображения всей вычислительной среды употребляется трёхмерная анимация и элементы виртуальной действительности, дозволяющие админу «передвигаться» по вычислительным ресурсам и сетевым соединениям. Таковым образом, со собственного «пульта управления» админ может следить за функционированием информационно-телекоммуникационной инфраструктуры компании и решать возникающие трудности.

Обязана представляться возможность логически кооперировать структуру компании с картой местности либо планом строения, что содействует наиболее эргономичной работе админа и дозволяет ему резвее ориентироваться. Если админ имеет дело с очень распределённой в пространстве компанией, то полезной может оказаться возможность работы с интегрированной географической картой, позволяющей представлять ресурсы в согласовании с их физическим расположением. На карте можно располагать разные условные знаки и изображения, к примеру планы помещений, что нередко оказывается очень принципиальным для управления современными информационными системами.

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

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

1. 2




Уровень менеджера (функции управления банком).

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

Обозначенные функции соединяются воединыжды в последующие главные группы:

* управление событиями;

* управление рабочей перегрузкой;

* управление носителями данных;

* хранением и восстановлением инфы;

* управление защитой;

* управление неуввязками.

Функция управления событиями
дозволяет создавать методы определения принципиальных событий, реагировать на их и по мере необходимости принимать неотложные меры. При обработке событий больше всего времени обычно тратиться на управление исключительным ситуациями. Нередко один-единственный сбой приводит к лавинообразному скоплению остальных, так что становится весьма тяжело найти источник проблем.

Для определения обстоятельств сбоев реализуются функции фильтрации и взаимоувязки событий, возникающих в разных информационных ресурсах. При управлении событиями выделяются сообщения, имеющие для системы наибольшее значение, и определяются деяния, выполняемые при их возникновении. Функция управления событиями может играться роль как менеджера, так и агента — не только лишь распознавать действия, да и обрабатывать их. В качестве интерфейса к функции управления событиями употребляется консоль управления событиями, представляющая собой отдельное окно в графическом интерфейсе управляющих функций, которое дозволяет смотреть за всем происходящим в системе. Отсюда же админ может следить за потоком сообщений, связанных с управлением событиями. Неповторимость данной функции состоит в способности созидать график сообщений в целом и сходу же реагировать на их .

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

Функция управления рабочей перегрузкой
решает задачку автоматизации ведения графика работ. Она управляет таковыми важными действиями, как планирование заданий, контроль за порядком их выполнения и вариантами отказа, учёт временных требований, выбор компов для выполнения тех либо других заданий Для действенного управления рабочей перегрузкой нужно иметь информацию о том, какая работа обязана быть выполнена, где когда и как. программка управления рабочей перегрузкой получает эти сведения в виде четырёх главных частей:

¨ станции — идентификация и описание рабочего места, где будет производиться задание. Это быть может , рабочая станция либо некое пространство, где производятся ручные операции;

¨ календари, указывающие, в какие сроки может производиться задание либо их набор. Для всякого задания также указывается четкое время начала его выполнения;

¨ задания, определяющие, какую конкретно работу нужно выполнить, и содержащие информацию о времени начала выполнения, предыдущих заданиях, нужных ресурсах и признаках окончания задания;

¨ набор заданий — логическая совокупа либо набор заданий.

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

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

Функция автоматического управления хранением данных
обеспечивает всё нужное для выполнения запасного копирования и архивирования инфы с отслеживанием перемещения данных с активных носителей на запасные. Менеджеры хранения данных поддерживают также такие функции, как шифрование, сжатие, корректировка избыточности и ошибок. Подчинённые им агенты поддерживают широкий спектр устройств, в том числе RAID, оптические диски и боты.

Система обеспечивает также иерархическое управление запоминающими устройствами, позволяющее убирать старенькые данные с активных носителей. При первой же попытке воззвания к таковым данным они автоматом переносятся из архива назад на активный носитель. Не считая того, имеется средство предотвращения случайного либо намеренного стирания либо перезаписи данных на запасных носителях. Интеграция функции управления хранения с управлением рабочей перегрузкой дозволяет планировать централизованные операции архивирования и запасного копирования данных по всему банку, что делает выполнение этих операций наиболее действенным.

В современном банке информация является одним из более принципиальным объектов, нуждающихся в защите. При всем этом управление защитой в распределённой среде — далековато не обычная задачка. Для ей решения нужно согласование огромного количества причин, таковых, а именно, как аутентификация, авторизация, администрирование и аудит, в рамках единой, просто управляемой системы .

Функция защиты
реализует решение трудности аутентификации для гетерогенной среды. Такое решение обеспечивает единый вход в систему для доступа ко всем ресурса, будь то мейнфреймы, локальные сети, unix-системы, компы среднего класса либо ПК . Юзеру довольно зарегистрироваться один раз, чтоб работать со всеми доступными системами, не запоминая огромное количество имён и паролей для входа в каждую. средства системы должны позволять админу создавать метод использования паролей, который соответствовал бы уже сложившимся в банке требованиям.

В системе реализованы средства группирования юзеров и ресурсов, также расширенные средства авторизации (кроме обычных прав чтения и записи). В отличие от обычных систем файлы защищаются не их физическими атрибутами, к примеру перечнем прав доступа, а правилами которые инсталлируются в специальной реляционной базе данных управления защитой. В данной базе хранится вся информация, сплетенная с защитой, и админы постоянно могут получить оттуда нужные сведения. Система предоставляет средства определения ресурсов, нуждающихся в защите: файлы, терминалы, принтеры, настольные ПК , порты TCP/IP, Web-страницы и соединяет воединыжды их в группу по отображению определенного бизнес процесса. Потом админ может назначать возможности для юзеров, задействованных в этом процессе. Не считая того, развитые аудиторские функции дают возможность надзирать внедрение алгоритмов защиты в системе — ведется журнальчик неавторизованного доступа и попыток взлома защиты, также данных о внесении конфигураций в методы защиты .

Функция управления неуввязками
— это набор инструментов оперативного разрешения проблемных ситуаций, которые появляются в ежедневной деятель системных админов. Управление неуввязками включат в себя три главных многофункциональных элемента:

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

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

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

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

одной из главных функций на данном уровне является функция отображения бизнес действий
. Бизнес процессы, такие, к примеру, как обработка заказа, электрический платёж, сервис клиента, осуществляемые в рамках автоматических денежных и промышленных систем типа MANMAN/X, Baan, SAP/R3, могут врубаться в так называемое отображение бизнес-процессов. Хоть какое из их можно «открыть», создав для него папку, и «положив» туда все атрибуты, отвечающие за его функционирование: идентификаторы компа и диска, описания требований к ресурсам и т. п. В итоге можно сформировать динамическую картину животрепещущего состояния автоматической системы, про которой админ способен проследить появление возможных коллизий и вовремя, к примеру, перераспределить либо добавить ресурсы.

1.3



Уровень агентов.

Как уже отмечалось, модель управления распределёнными системами реализуется в виде гибкой структуры, в базе которой лежит разработка «менеджер — агент», реализованная на 2-ух нижних уровнях архитектуры системы. Агент — это программка на языке программирования Си, использующая библиотеку функций связи с ядром системы и генерирующая информацию для верхних уровней управления. Данная программка запускается централизованно и управляется брокером объектов. Всякий раз, когда в корпоративную систему врубается новейший компонент, происходит опрос с целью обнаружения уже узнаваемых агентов и установления с ними связи. Агенты по аналогии с датчиками и детекторами смотрят за работой фактически всех ресурсов информационной системы и дозволяет следить за 7 элементами сетевой инфраструктуры, базами данных и приложениями. Перечень готовых агентов в системе должен включать поддержку таковых более всераспространенных ОС и баз данных, как Windows NT, unix, Oracle, Sybase, SQL Server , CA-OpenIngres. Доп агенты могут создаваться при помощи системных инструментальных средств.

Для действенного использования агентов все ресурсы сгруппированы в домены, которые могут быть организованы по топологическому (сетевому), географическому, организационному (в согласовании со структурой банка) либо многофункциональному (с группировкой по типам ресурсов) принципу. Домены разрешают достигнуть наиболее четкого и целенаправленного внедрения алгоритмов управления. Любой домен может применять свои методы для управления своими ресурсами.

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

2.



Решения, применяемые при разработке банковской системы автоматизации.

В большинстве БИС банковская разработка оказывается агрессивно встро­енной в программный продукт. Потому юзер не имеет возмож­ности отклоняться от нее, пользуясь меню, и постоянно следует по пути за­программированного диалога, правильность которого зависит практи­чески вполне от разраба. При всем этом разные продукты име­ют разную степень их технологической адаптации и почти всегда таковая настройка делается спецом в процессе инстал­ляции. Обычно таковым спецом является представитель разработ­чика, пореже — банковский технолог (админ) автоматизируемого учреждения.

Мера многофункциональной избыточности определяется чертами управленческой структуры, принятой в банке. При всем этом ряд управленче­ских задач часто не выделяется в самостоятельные, как, к примеру, вся группа задач маркетинга. Это можно разъяснить неразвитостью бан­ковских систем управления и нежеланием маленьких, бедных банков растрачивать средства на дорогостоящие рекламные исследования.

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

Внедрение компа дозволяет расширить применение эконо­мико-математических способов в управлении, т.е. не попросту убыстрить о­работку инфы способом прямого счета, а улучшить некото­рые процессы (к примеру, распределение и размещение мобилизованных средств). При всем этом время на обработку понижается так, что это ска­зывается на повышении оперативности проведения расчетов и, следова­тельно, на повышении оперативности принимаемых решений. Появляет­ся возможность расширения диапазона оказываемых услуг, увеличения их свойства и расширения географии за счет наиболее полного использования средств телекоммуникаций.

Но при всех преимуществах автоматизации перед банком по­мимо необходимости огромных издержек на закупку платформы (техниче­ские средства и базисное программное обеспечение) и обучение собственных профессионалов возникает неизменная неувязка. Она состоит в том, что желание банка обеспечить наивысшую продолжительность эксплуата­ции полученной платформы сталкивается с тем, что неважно какая плат­форма обречена на резвое моральное старение, обусловленное уста­реванием оборудования, базисного программного обеспечения (опера­ционная система, СУБД, языки программирования) и заложенной в продукт банковской технологии.

При разработке системы автоматиза­ции могут быть реализованы два других решения.

1-ое решение состоит в том, что проектировщики разработчика­тывают систему исходя из сложившейся структуры управления и, таковым образом, «увековечивают» ее достоинства и недочеты.

2-ое решение подразумевает подготовительную реорганизацию системы управления и усовершенствование ее в согласовании с современ­ной концепцией организации управления и требованиями управления уч­реждения.

3.



Требования к банковской Информационной системе и принципы разработки программных средств.

Неизменные конфигурации, происходящие в сфере деятель банков и затрагивающие юридическую сферу, экономическую среду и банковские технологии, требуют от системы управления банком высочайшей степени адап­тивности. БИС обязаны иметь гибкую структуру и быть открытыми систе­мами, т.е. допускающими внесение нужных конфигураций в модель в случае каких-то перестроек в банковской сфере. Потому система обязана быть нацелена на автоматизацию управления банковской деятель­ностью, а не на определенную задачку незапятанной автоматизации обработки бан­ковской инфы. Иными словами, система обязана соблюдать прин­цип мотивированного нрава управления и удовлетворять требованию откры­тости для легкого внесения конфигураций и наращивания многофункциональных ее способностей при необходимости. Это требование реализуется на принципах серьезной параметризованности автоматизируемых объектов и модульности. Основным лозунгом тут обязана служить ориентация систе­мы на автоматизацию управления банковской деятельностью, а не на решение локальных многофункциональных задач.

Процедуры расширения и опции системы должны основываться на так именуемом «связывании» модулей, которое обеспечивает комплексность системы за счет их интеграции. К примеру, оплата уведомлений по пога­шению коммунальных платежей клиента сразу обновляет пози­ции в текущих счетах, также остальные позиции, затронутые операцией.

К особым требованиям, соответствующим для банковской сферы, от­носится до этого всего возможность отката на дату (контрольную точ­ку) или технологического отката через систему оборотных проводок «красноватое сторно». При достижении начальной ситуации и ее фиксации сотрудники банка обязаны иметь возможность внесения конфигураций и воз­врата с автоматическим расчетом, закрытием и архивацией всех опосля­дующих дней.

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

Иным требованием, которое сейчас предъявляют банки к систе­мам автоматизации собственной деятель, является блокирование вво­да платежных документов, приводящих к дебетовому сальдо, чтоб ис­ключить таковым методом пополнение картотеки № 2. Если же таковая ситуация не возникает и платежный документ не владеет некоррект­ными реквизитами, банковская разработка подразумевает однократный ввод инфы в систему и автоматическое формирование прово­док по всем операциям. Это требование совпадает и с требованием разрабов.

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

Лицевые счета должны проходить анализ на ситуацию неоткрытый счет. Вновь открываемые счета получают автоматом присваиваемые номера. По мере необходимости клиент (при наличии системы клиент-банк) либо сотрудник банка должен иметь возможность просмотра лицевого сче­та и оценки его динамики за данный период. По способности очень освобождать служащих от выполнения рутинных задач вручную. При всем этом документооборот в банке лучше уменьшить.

Требования разраба в главном соединены со сложившимся под­ходом к проектированию автоматических систем, также с собст­венными его интересами, которые носят денежный нрав. Это пре­жде всего соотношение: стоимость — себестоимость — размер работ.

К встроенным системам при разработке предъявляются наиболее ужесточенные требования, чем к локальным разработкам. Это обусловле­но расширенными многофункциональными запросами комплексности решений и неотклонимыми системными соглашениями.

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

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

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

Внедрение в качестве опорной концепции разработки системы автоматизации банковской деятельности концепции АРМ как недозволено бо­лее соответствует применению мотивированного подхода в управлении. Опреде­лив главные цели сотрудника, можно сконструировать главные сис­черные соглашения по использованию дискетной либо сетевой техноло­гии, избрать нужный инструментарий. наличие в почти всех АРМ одноименных участков дозволяет обширно применять перемещаемые блоки типа: расчет нормативных коэффициентов, оценка своей ликвидности, заключение и ведение договоров и др. и применять при всем этом объектно-ориентированный подход.

Любому объекту (лицевой счет, проводка, клиент) соответствует стан­дартный инструментарий (создание, контроль, корректировка, удаление, сортировка, поиск и др.), также специфичный инструментарий («крас­ное сторно» для проводок, заключение оборотов либо закрытие — для сче­тов и др.).

Очень животрепещущей неувязкой сейчас остается обеспечение банков­ской сохранности. Ее решение быть может удачным лишь при ком­плексном подходе, который предполагает разделение доступа к инфор­мации, к разным АРМ и к режимам в их. Так, для доступа к системе есть уровни: пересылка файлов в определенную директорию, дос­тупы в определенную директорию, доступ к диску, реализация всех функ­ций на удаленной ЭВМ . Для этого обычно употребляется система паро­лей, шифрования передаваемой инфы, электрической подписи. Так­же принципиальное системы.

Таковым образом, принципы разработки систем автоматизации банков­ской деятельности вытекают из подходов и требований, предъявляемых к программному продукту заказчиком (банком). Эти требования содержат внутри себя требование банка к системе в целом как к продукту, который будет обслуживать специфическую сферу (банковское дело), также специ­альные требования, отражающие специфику применяемых в банке опера­ций и технологий их выполнения.

С иной стороны, существует ряд требований, которые предъявля­ются к разработке исполнителем (разрабом). Эти требования могут совпадать с требованиями банка, но могут и конфликтовать. Хотя боль ­шинство из перечисленных требований, предъявляемых проектировщиком, не являются конфликтными по отношению к требованиям банков.

Следует уяснить, что при проектировании встроенных БИС нужно учесть требования банковской среды. Это возможность отката на определенную дату и технологического отката; однократный ввод инфы; блокирование ввода платеж­ных документов при дебетовых сальдо; выполнение прово­док в настоящем масштабе времени; анализ ситуации — от­крытый (закрытый) счет; информационная сохранность.

Общие требования разработки информационных систем: сокращение документооборота; автоматизация рутинных задач: адаптивность денежных информационных систем (ФИС) (параметризованность); возможность расширения систем; единая информа­ционная база; мобильность; ведение архива системы; вос­становление архивной копии базы данных системы.

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

4.




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

Вероятной структурой построения встроенной БИС может слу­жить структура, включающая в себя более всераспространен­ные в наших программных продуктах АРМ и блоки.

На базе проведенного аналитического обзора рынка Русских БИС был выделен и скомпонован состав АРМ и определены их функции для условной встроенной БИС. В настоящей встроенной БИС такое выделение зависит от структуры управления, разде­ления управленческих функций и целей, также от избранного подхода к проектированию сис­темы и почти всех остальных причин. В структуре БИС в процессе ее разработ­ки выделяют перемещаемые блоки, которые обеспечивают выполнение неких обычных банков­ских техноло­гий: обслужи­вание договоров (кредитного, депозитного, трастового, до­говора на рас­четно-кассовое о­служивание и др.), обслужи­вание процен­-

Набросок 1. структура встроенной БИС

тов по разным договорам, о­служивание штрафных процентов и др.

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

тут (см. рис. 1) имеется ряд АРМ, которые нужны относи­тельно полноценности управления, но отсутствуют как самостоятельные в большинстве БИС: АРМ спеца по маркетингу, АРМ сотрудника по управлению активами и пассивами, АРМ аналитика, АРМ планиров­щика, АРМ сотрудника по управлению ликвидностью и др.

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

Если электрической почты, дискетой либо бумаж­ной технологии. АРМ по работе с филиалами дает сотруднику возможность ввода инфы о денежных операциях филиалов, учета их деятель­ности при формировании консолидированного баланса, анализа инициативно­сти филиалов и расчета для их нормативных коэффициентов.

Работа с наружной средой осуществляется по каналам телекоммуникаций через АРМ коммуникаций. АРМ обеспечивает экспорт-импорт инфор­мации, т.е. двухсторонний обмен данными с наружными абонентами: ЦБ РФ

Для обеспечения взаимодействия по схеме клиент-банк у клиента ус­танавливается программный комплекс АРМ клиента, который дозволяет вводить, редактировать платежные документы с внедрением типово­го набора бланков, печатать приготовленные документы, шифровать и де­шифровать информацию и обеспечивать авторизацию через механизм элек­тронной подписи, отправлять и принимать документы, файлы и сообще­ния. В банке снутри базисного блока устанавливается для взаимодействия с клиентом АРМ банка. Этот комплекс обеспечивает через АРМ комму­никаций подобные функции по взаимодействию с клиентом, поддер­живает архивы взаимодействия с клиентом и посылает поступившие платежные документы по ЛВС на обработку в подходящий АРМ.

Набросок 2 Схема работы АРМ коммуникаций по экспорту данных

АРМ сотрудника межбанковских расчетов (МБР) обеспечивает веде­ние расчетов с иными коммерческими банками через сеть клиринговых центров и через обоюдное открытие кор­респондентских счетов. При работе на базе прямых межбанковских расчетов АРМ дозволяет производить контроль, корректировку и отме­ну текущих операций МБР и формирование исходных авизо, реестров и соответственных платежных документов. При работе с ответными авизо АРМ проводит весь комплекс работ с входным документом: ввод, коррек­тировку, отмену текущих документов (с одновременным контролем сумм авизо и платежных документов); выполнение квитовки ответных авизо, ведение соответственного журнальчика и документов по квитовке; откры­тие, ведение и закрытие заключительных оборотов.

Для проведения электрических взаимодействий с иными банками, клиентами, процессинговым центром либо биржами информация пересы­лается по ЛВС на АРМ коммуникаций, через которое реализуются теле­коммуникационные взаимодействия.

АРМ сотрудника кредитного отдела (АРМ СКО) обеспечивает заклю­чение и ведение контракта, его пролонгацию и закрытие (поступление в архив), формирование графиков погашения основного долга и выплаты процентов по разным схемам, также контроль выполнения этих гра­фиков и начисление пеней по главный части долга и по процентам. При всем этом формируется ряд ведомостей. АРМ поддерживает обычные и ин­дивидуальные процентные ставки: по главный части долга, за неисполь­зованный кредит (если это не обозначено в договоре), за просроченный воз­ворот ссуды либо за несвоевременную выплату процентов за .

АРМ сотрудника по работе с физическими лицами все почаще включает­ся в состав БИС, что обосновано необходимостью вербования средств от физических лиц, хотя эти операции соединены с большенный трудозатратностью из-за массовости. В главном они носят нрав депозитных операций, и потому данный АРМ принципно различается от АРМ сотрудника де­позитного отдела только специфичным набором оказываемых услуг.

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

АРМ сотрудника депозитного отдела обеспечивает вербование времен­но вольных средств. Относительно предметной технологии в этот АРМ врубаются такие же режимы, как и в АРМ СКО: заключение контракта, расчет процентов по разным схемам, причисление их к остатку и др.

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

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

Работа АРМ конструктивно строится на базе ряда всепригодных перемещаемых блоков: Контракт, График выплат. Расчет нормативов бан­ка, также ряда особых с методической и технологической точек зрения блоков: Оценка кредитоспособности клиента и Прогноз вольных средств банка (на базе сроков окончания договоров). Блок Контракт обес­печивает подготовку, ведение, учет и контроль выполнения договоров банка и его обязанностей; учет сумм кредитов и депозитов при расчете коэффи­циентов ликвидности банка; прогноз состояния кредитных ресурсов бан­ка к данному моменту времени; прогноз воздействия предполагаемого дого­вора на финансовое состояние банка. Он дозволяет получить выписку о состоянии отдельного контракта и сводную отчетную документацию.

Блок График выплат дозволяет провести подготовительную прикид­ку вариантов погашения кредитов и выплат по депозитам и кредитам. Воз­можны графики равномерного погашения базы кредита, равномерного погашения базы кредита и процентов; аннуитет (ссудозаемщик часто выплачивает равные суммы — аннуитеты, состоящие из суммы процентов и суммы погашения основного долга, так как проценты начисляются на остаток долга, они понижаются по мере погашения с одновременным повышением толики погашения); график выплаты процентов при получе­нии ссуды (дисконтированная ссуда); график единовременного погаше­ния кредита в конце срока контракта с текущим погашением процентов; график случайного погашения базы кредита и др.

АРМ оператора (может и не быть) обеспечивает ввод документов, собранных в пачки, с просчитанной контрольной суммой. Обычно документов рейсы и передачу их на ВЦ для проведения одногородных рас­четов.

АРМ сортировщика (может и не быть) создается для проверки пачек документов, введенных операционистами, и отправки их на проводку, также для формирования и печати авизо и реестров для РКЦ.

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

АРМ кассира-контролера обеспечивает: ввод кассовых платежных до­кументов; прием и обработку валютных чеков, объявлений на взнос на­личными, приходных и расходных кассовых ордеров и документов по инкассации; формирование сводных ведомостей по приходу и расходу; ве­дение кассовых журналов; подготовку проводок по кассе; получение свод­ной справки по кассовым оборотам, формирование мемориальных орде­ров; расчет платы всякого клиента за кассовое сервис; получение отчета по кассовым символам оборотов за период; работу со справочни­ком знаков; формирование справки по кассе.

При помощи АРМ старшего операциониста (может и не быть) оцени­вается загрузка операционистов и назначаются операционисты для новейших клиентов банка; просматривается и контролируется перечень открытых за денек лицевых счетов.

Одно из принципиальных мест во всех банковских программных продуктах за­нимают АРМ операционистов. В неких разработках предвидено их разделение на АРМ операциониста по платежным документам и АРМ операциониста по подготовке отчетов или на АРМ операциониста по ра­боте с физическими лицами и АРМ операциониста по работе с юридиче­скими лицами. В больших банках время от времени выделяют операционистов для проведения работ по открытию и закрытию счетов.

Обычно же АРМ операционистов могут реализовывать открытие и за­крытие счетов; начисление, причисление к остатку вкладов и выдачу про­центов по всем видам вкладов; перевод вкладов; поиск клиента по номеру его лицевого счета и напротив; установление договорной процентной став­ки и платы за совершение операций и расчет дохода от проведения опера­ций; оплату переводов; ведение операционного дневника; аналитический и операционный контроль за выполнением операций; ввод платежных до­кументов; работу с картотеками:

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

АРМ экономиста (может и не быть) производит: формирование вы­писок из лицевых счетов, контроль начисления процентов по лицевым счетам, контроль остатков и проводок по лицевым счетам, расчет норма­тивов и характеристик работы банка, контроль за работой филиалов, форми­рование сведений для налоговой инспекции.

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

АРМ головного бухгалтера производит: получение инфы о ра­боте банка, его клиентах; открытие и закрытие лицевых счетов; просмотр и печать оборотно-сальдовых ведомостей по балансовым и внебалансовым счетам, также ведомостей открытия, закрытия и конфигурации лице­вых счетов; обновление файла подписей клиентов (в неких БИС).

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

текущую работу по документам:

— отражение оперативных проводок;

— составление текущей описи документов;

— выполнение текущей сверки;

— составление документального баланса;

— печать отчетов;

— межфилиальный обмен по дискетной технологии;

— планирование и окончание операционного денька банка;

— планирование работ и наделение возможностями служащих отдела;

операционно-учетных работ:

— планирование работ на требуемый денек;

— регистрация, удаление, изменение статуса юзера;

— контроль протокола работы юзера;

— функциональное конфигурирование рабочих мест юзеров;

— поддержание санкционированного доступа к информационным ре­сурсам БИС;

— выполнение отката комплекса;

ведение фонда НСИ:

— администрирование файлов базы данных;

— организация и ведение фонда НСИ (изменение процентных ставок, справочники МФО, таблицы балансовых и внебалансовых счетов, типов платежных документов, кассовых знаков, атрибутов банка, прейскуранта услуг, видов операций и др.);

— установление и конфигурирование рабочих мест остальных пользовате­лей БИС;

— включение и выключение задач в комплексе;

— настройка комплекса;

— выполнение пусковых работ при внедрении БИС. Если в каких-то БИС состав АРМ иной, то функции служащих ОУР просто разбиты меж АРМ по-другому, так как БИС только обес­печивает реализацию банковских учетных технологий средствами инфор­мационных технологий, являясь некой моделью системы у правления.

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

Таковым образом, АРМ сотрудника кредитного от­дела (СКО) должен под­держивать реа­лизацию целей, которые вы­ставляются со­труднику бан­ка, и обеспечивать его информа­цией для приня­тия решения по кредитова­нию и предстоящему обслуживанию кредита.

Ри­сунок 3. Схема данных решения задач АРМ СКО

Для этого нужно иметь сведения о кредитном потенциале банка, о кредитоспособности ссудоза­емщика и рабочую информацию по обслуживанию кредита.

Обычно в российских БИС АРМ СКО обеспечивает ввод и обра­ботку инфы о кредитных дого­ворах и отражает технологические этапы кредитова­ния: заключение контракта и его ведение (выдачу кре­дита, начис­ление процентов по кредиту, расчет неустоек и выставле­ние их на инкассо или полу­чение этих сумм в порядке неоспоримого платежа, контроль фактических выплат клиентом по договору, пролон­гацию контракта и его закрытие, перевод договоров в состояние про­срочки). Расширение способностей АРМ СКО может происходить через до­бавление средств обра­ботки инфы договоров на гаран­тии погашения кредитов и на их страхование; средств оценки креди­тоспособности заемщика; расчет платы за для но­вых схем кре­дитования и др.

На рис.3 представлена схема данных решения задач АРМ СКО. Сотрудник кредит­ного отдела, используя огромное количество текстовых прототи­пов (шаблоны договоров), составляет контракт о выдаче кредита также в текстовой форме, имеющий статус черновика. Кредитный контракт как тек­стовый документ содержит: наименование сторон; вид кредита; сумму; срок контракта; процентную ставку; порядок выплаты процентов; вид обес­печения; список необ­ходимых документов (по просьбе банка); но­мер расчетного счета и остальные реквизиты банка, обслуживающего пред­приятие; юридические адреса сторон.

Технологически контракт может иметь разный статус: черновик, условно работающий, реально работающий и завершенный. Первона­чально составленный черновик перебегает в статус условно действую­щего при его подписании. Контракт приобретает статус реально дейст­вующего опосля перемещения на его основании денежных средств. Опосля окончания расчетов меж ссудозаемщиком и банком контракт приобретает статус завершенного. Реально работающий контракт мо­жет иметь уточненный статус: нормально работающий, просроченный и пролонгированный.

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

При перечислении средств на ссудный счет, на расчетный счет, про­лонгации контракта либо переводе его на счет просроченных ссуд форми­руются проводки, которые передаются в отдел операционно-учетных ра­бот. На базе файлов проводок и начисленных процентов формируется файл плановых платежей по договору. Он обрабатывается вместе с файлом проводок, поступившим из операционного денька, в итоге что появляется файл платежей по договору. На базе крайнего формиру­ются ведомости состояния контракта, кредитный журнальчик и др.

При пролонгации этот цикл повторяется, но статус контракта меняет­ся. Если же контракт переводится в просрочку, изменяется не только лишь статус контракта, да и начинается начисление пенсий. И в том, и в другом случае формируются надлежащие проводки.

При закрытии контракта изменяется только его статус.

Для расчетов по предоставленным кредитам обычно применяется файл процентов (начисленные проценты).

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

5.


Межбанковские взаимодействия и коммуникации.

Компьютерные сети обеспечивают выполнение коммуникационной функции и доступ к разделяемым ресурсам, т.е. передачу файлов, доступ к удаленным базам данных и удаленный пуск задач. Компьютеризован­ные межперсональные коммуникации могут быть 3-х видов: обыкновенные пересылки сообщений по определенному адресу; рассылка сообщений по почтовым перечням и проведение телеконференций.

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

В качестве наружной среды, с которой ведет взаимодействие коммерческий электрического валютного воззвания (ЭДО) с использова­нием пластмассовых карточек (ПК );

Набросок 5 Схема взаимодействия коммерческого банка с наружной средой

· банки на местности Рф;