Автоматизированная информационная система управления в ОАО «Сбербанк России»

Схема логического ядра ИБС RS-Bank V.6 приведена на рисунке 2.

Рисунок 2-Построение ИБС RS-Bank V.6

 
Реализованный в ИБС RS-Bank V.6 механизм документооборота позволяет:

• наращивать сложность процесса обработки документов (практически неограниченно и без потери управляемости системы);
• использовать ИБС RS-Bank V.6 как централизованную автоматизированную банковскую систему (ЦАБС), *обеспечивающую деятельность банка со сложной организационно-территориальной структурой и единым центром администрирования;
• многократно использовать один и тот же автоматизированный процесс на разных участках документооборота банка, которые относятся к разным частям структуры (филиалам и подразделениям).

В основе архитектурного решения, реализованного в ИБС RS-Bank V.6, лежат:

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

2.3 Обоснование эффективности  использования в ОАО «Сбербанк России» автоматизированных банковских систем

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

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

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

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

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

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

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

Лицевые счета должны проходить  анализ на ситуацию неоткрытый счет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 Обоснование проектных решений по автоматизации управленческого процесса в ОАО «Сбербанк России»

3.1 Обоснование требований  к автоматизированной информационной системе управления

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

• функциональные (Functional);
• нефунцианальные (Non-functional Requirements).

Функциональные требования задают «что» система должна делать; нефункциональные – с соблюдением «каких условий» (например, скорость отклика при выполнении данной операции). Часто функциональные требования представляют в виде сценариев (вариантов использования) Use Case.

Рассмотрим функциональные требования к автоматизации процесса управления и проранжируем их по степени важности для Сбербанка России:

1. разграничение доступа к информации на уровне ролей, индивидуальных прав пользователей и грифов доступа к документам;
2. поддержка электронно-цифровой подписи для заверения содержания кредитных заявок и связанных с ними документов, результатов обработки кредитных заявок;
3. хранение сертификатов электронно-цифровой подписи на различных внешних носителях информации (смарт-карты, таблетки Touch-Memory и др.);
4. идентификация/аутентификация пользователей с помощью паролей, сертификатов и Active Directory;
5. планирование и контроль сроков выполнения работ по кредитным заявкам;
6. on-line мониторинг процесса обработки кредитных заявок;
7. рассылка оповещений о выданных поручениях и сроках их исполнения;
8. анализ плановых/фактических сроков и длительности обработки кредитных заявок, а также выявление "узких мест", возникающих во время кредитного процесса;
9. анализ информации о причинах отклонения кредитных заявок, изменения плановых сроков поручений и пр.;
10. анализ загрузки исполнителей поручений по кредитным заявкам;
11. использование аналитических OLAP отчетов;
12. формирование специализированная статистическая/аналитическая отчетность по кредитной деятельности;
13. поддержка наиболее распространенных форматов (*.doc, *.rtf, *.pdf, *.xls, *.html и пр.);
14. формирование отчетов по настроенному расписанию, рассылка по электронной почте, публикация на файловых или web-ресурсах.