Принцип однократного ввода и учета информации

– обеспечение непротиворечивости и устранения дублирования данных. В АБС должен быть предусмотрен однократный ввод информации и ее многократное использование (ввод и обработка операций с помощью электронного документооборота – технология Workflow).

 

3. Жизненный цикл АБС

 

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

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

Жизненный цикл автоматизированной системы представлен в таблице

 

№ п/п	Название этапа	Содержание	Особенности реализации	Минимальный перечень сопутствующих документов
1.	ФТ – формирование требований к АБС	1.1. Обследование объекта и обоснование необходимости создания АБС. 1.2. Формирование требований пользователя к АС. 1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)	На данном этапе необходимо как можно полнее описать и разбить на категории те требования, которые предъявляются к автоматизированной банковской системе (АБС), так как на их основании будут формироваться концепция и проект АБС. Целесообразно также определить приоритеты в реализации требований, что позволит более гибко формировать проект	1. Документ, отражающий итоги проведенного обследования. 2. Общий перечень требований к АБС. 3. Список требований к АБС со стороны пользователей.
2.	РК – разработка концепции АБС	2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющей требованиям пользователя. 2.4. Оформление отчета о выполненной работе.	В концепции АБС следует отразить вышеупомянутые требования и заложить возможность быстрой и гибкой модификации под изменяющееся законодательство, кроме того, наметить направление будущего развития системы с учетом расширения услуг, предоставляемых банком	Концепция АБС
3.	ТЗ – техническое задание	Разработка и утверждение технического задания на производство АС	В техническом задании должны быть отражены все необходимые детали и нюансы (и, естественно, их решения), которые могут потребоваться при эксплуатации АБС	Техническое задание на разработку АБС, включающее перечень функциональности и перечень автоматизированных отчетных форм
4.	ЭП – эскизный проект	4.1. Разработка предварительных проектных решений по системе и ее составляющим. 4.2. Разработка документации на АС и ее составляющие.	На данном этапе происходит практическое воплощение АБС на основании ранее сформированных документов. Необходимо обратить пристальное внимание на особенности реализации.	Эскизный проект, в составе которого документация к АБС и предварительный проект
5.	ТП – технический проект	5.1. Разработка проектных решений по системе и ее составляющим. 5.2. Разработка документации на АС и ее составляющие. 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку. 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.	Собственно создание законченного продукта, который будет в дальнейшем эксплуатироваться, и разработка соответствующей технической документации. На данном этапе, видимо, стоит уделить больше внимания обратной связи между заказчиком и разработчиком для наиболее полной и приемлемой реализации всех требований.	Технический проект, в составе которого техническая документация и проект разработки АБС
6.	РД – рабочая документация	6.1. Разработка рабочей документации на систему и ее составляющие. 6.2. Разработка и адаптация программ.	Необходимо очень серьезно подойти к данному этапу, так как от полноты и правильности разработки документации к АБС зависит и качество обучения персонала, и дальнейшая преемственность АБС.	Документация к АБС
7.	ВД – вод в действие	7.1. Подготовка объекта автоматизации к вводу АС в действие. 7.2. Подготовка персонала. 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями). 7.4. Строительно-монтажные работы. 7.5.Пусконаладочные работы. 7.6. Проведение предварительных испытаний. 7.7. Опытная эксплуатация. 7.8. Проведение приемочных испытаний.	Если АБС разрабатывалась не под конкретного клиента, то с особой тщательностью следует отнестись к: составлению документа, в котором подробно описываются результаты обследования; разработке плана внедрения; подготовке технических заданий на конвертор и доработки системы; проведению опытной эксплуатации.	1. План внедрения. 2. Документ, описывающий результаты проведенного обследования. 3. Техническое задание на разработку конверторов. 4. Технические задания на доработку АБС (при необходимости). 5. План обучения сотрудников
8.	Сп – сопровождение АС	8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание.	От этого этапа собственно зависит успешность эксплуатации системы. Над тем, как будет осуществляться сопровождение, необходимо задуматься еще на этапе выбора АБС и ее внедрения. В регламенте сопровождения желательно предусмотреть все работы, которые предвидятся при эксплуатации системы, включая: модификацию под требования заказчика; гарантийное обслуживание (исправление ошибок, внесение коррективов в связи с изменениями законодательства); проведение профилаткических работ и т.д.	Если речь идет о закупленной АБС, работы, как правило, выполняются на основании Договора сопровождения, в котором выделяют наиболее затратные по ресурсам статьи из регламента сопровождения АБС

 

4. Инфраструктура АБС.Подсистемы АБС

 

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

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

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

 

Концептуальная модель банка - система понятий и отношений банковской предметной области. Описывает классы объектов, а не отдельные экземпляры.

Концептуальная модель банка используется в целях:.

? дать общую основу для понимания поведения АБС группе разработчиков и специалистов банка, организовать совместную работу;

? определить логическую структуру информации и допустимые операции над ней в АБС;

? дать основу для интерпретации данных, обрабатываемых АБС;

Концептуальная модель банка удовлетворяет следующим требованиям:

? описывает классы объектов предметной области, а не отдельные экземпляры;

? описывает концепты, правила, ограничения, имеющие постоянный, малоизменчивый характер;

? содержит правила и ограничения, действующие в предметной области.

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

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

Организационная модель – описание взаимодействия между организационными единицами, посредством обмена информацией. Кроме целей проектирования концептуальная модель может использоваться в перспективном планировании, создания имитационной модели АБС, тестирования, диагностики.

Принципы построения АБС:

Гл принцип – модульное построение;

принцип динамичности рабочих мест;

Базирование на системе ЭДО;

Совместное использование он и оф лайн технологий в обработки документов;

Использование уникальной идентификации документов;

Интеграции компьютерных систем.

Ориентация банков на клиентов требует перехода к организации их работы согласно четким бизнес-процессам. Эти бизнес-процессы могут быть контролируемы АИС и ведут к улучшению деятельности

банка. Однако увеличение количества договоров ставят перед банками новые задачи:

Минимизировать риски;

Контролировать целесообразность заключение договоров;

Создавать процедуры, обеспечивающие максимально быстрое согласование при заключении договоров;

Организовывать для заинтересованных лиц доступ к досье клиентов;

Контролировать использование каждого договора клиента с т.з. финансовых обязательств.

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

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

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

- выделен;

- структурирован;

- выполняется по правилам, которые можно сформулировать;

- периодически повторяется.

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

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

Технология Workflow не накладывает каких-либо специальных ограничений на уровень детализации бизнес-процесса и/или степень автоматизации выполняемых операции.

 

5. Концептуальная модель банка

 

6. Автоматизация банковской деятельно­сти на основе технологии WorkFlow.

 

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

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

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

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

В основе технологии Workflow лежат следующие понятия:

объект - информационный, материальный или финансовый объект, используемый в бизнес-процессе (например письмо, оборудование, счет);

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

операция - элементарное действие, выполняемое в рамках рассматриваемого бизнес-процесса (допустим подготовка письма, замена оборудования, оплата счета);

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

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

Основное количество внедрений систем класса Workflow в России сосредоточено сегодня вокруг задачи управления документооборотом.

 

 

7. Банковская информационная технология. Понятие, виды

 

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

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

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

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

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

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

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

 

8. Трехуровневая архи­тектура банковских приложений

 

Автоматизированные банковские системы (АБС) создаются в соответствии с современными представлениями об архитекту­ре банковских приложений, которая предусматривает разде­ление функциональных возможностей на три уровня (рис. 7.1).

Верхний уровень (front-office) образуют модули, обеспечивающие быстрый и удобный ввод информации, ее первичную обработку и любое внешнее взаимодействие банка с клиентами, другими бан­ками, ЦБ, информационными и торговыми агентствами и тд.

Средний уровень (back-office) представляет собой приложения по разным направлениям внутрибанковской деятельности и внутренним расчетам (работу с кредитами, депозитами, ценны­ми бумагами, пластиковыми карточками и т.д.).

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

Разделение банка на front-office и back-office основывается не столько на функциональной специфике обработки банковских операций (сделок) и принятия решений (обобщения и анализа), сколько на самой природе банка как системы, с одной стороны, фиксирующей, а с другой — активно влияющей на экономическое взаимодействие в финансово-кредитной сфере.

 

9. Сис­темы удаленного обслуживания клиентов.

см. слайд

 

10. Обеспечение безопасности электронных платежей.

 

Меры защиты электронных платежей:

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

- подготовка, ввод и обработка электронных платежных документов должны проводиться типовыми автоматизированными вычислительными системами или на специализированных типовых автоматизированных рабочих местах (АРМ);

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

- централизованно распространяемое в системе Банка России программное и информационное обеспечение систем электронных платежей должно передаваться по каналам связи (записываться на магнитные носители для рассылки) с использованием механизмов контроля целостности и достоверности, согласованных с Главным управлением безопасности и защиты информации Банка России;

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

- должен быть разработан комплекс мер, обеспечивающих управление парольной защитой автоматизированных рабочих мест ввода и обработки электронных платежных документов;

- длина пароля должна быть не менее 8 символов;

- в числе символов пароля обязательно должны присутствовать буквы в верхнем и нижнем регистрах, цифры и специальные символы (@, #, $, &, *, % и т.п.);

- пароль не должен включать в себя легко вычисляемые сочетания символов (имена, фамилии, наименования АРМ и т.д.), а также общепринятые сокращения (ЭВМ, ЛВС, USER, SYSOP и т.д.);

- при смене пароля новое значение должно отличаться от предыдущего не менее чем в 6 позициях;

- личный пароль пользователь не имеет права сообщать никому.

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

- контур защиты (комплекс мер и средств) передачи и контур защиты внутрибанковской обработки электронных платежных документов должны быть независимы друг от друга.

 

11. Виды информационных банковских технологий.