Министерство общего и профессионального образования РФ

Московский Государственный Индустриальный Университет

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

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

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

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

на тему:

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

Выполнил:

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

Группы №6293

Валин Ф. Н.

Проверил:

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

- Москва 2003 г. -

ОГЛАВЛЕНИЕ.

Список используемой Литературы.

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. Архитектура системы и реализация основных функций.

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

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

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

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

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

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

Высокая степень масштабируемости должна позволять настраивать систему на задачи конкретного бизнеса, используя сети 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 Уровень агентов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• банки на территории России;

• банки на территории СНГ;

• зарубежные банки;

• другое.