Шпаргалка по "Информационным системам в банковском деле"

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

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

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

Каковы временные  рамки для процесса выбора, внедрения  и возможной эксплуатации решения?

Действительно ли новое решение продиктовано требованиями бизнеса и какие альтернативные варианты существуют?

Возможно ли и что необходимо предпринять, чтобы уже имеющаяся система (Legacy System) удовлетворила новым задачам и реалиям?

Существуют ли на рынке решения, способные удовлетворить  требованиям банка?

Какова примерная  стоимость собственной и сторонней  разработок?

Соответствует ли замена информационной системы общей стратегии банка?

Каковы основные риски, с которыми столкнется банк при  том или ином сценарии?

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

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

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

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

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

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

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

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

Этап включает следующие шаги:

проведение интервью с руководством и представителями  бизнес-подразделений банка;

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

оценка организационной  структуры, стратегии и направлений  развития банка и их влияние на выбор АБС;

осуществление детального анализа используемых систем;

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

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

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

определение и  утверждение требований к системе.

Результатом этой работы должен стать документ «Требования к системе», который является частью тендерной документации. Такой документ может иметь в зависимости от размера и сложности банка от 50 до 1500 страниц. Впрочем, если документ построен правильно и в нем не излагаются общепринятые требования, то для среднего банка вполне достаточно 70—100 страниц. Некоторые банки в подобных документах пытаются описать всю технологию работы банка со всеми деталями, используя специальные средства и стандарты моделирования (IDEF0, DFD, UML). Но, по нашему мнению, излишняя детализация может обойтись достаточно дорого как с точки зрения финансовой, так и с точки зрения потерянного времени.

Рассмотрим некоторые  обычно выдвигаемые требования к  банковским информационным системам. К общим требованиям к АБС обычно относят следующее:

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

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

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

Иметь возможность  увеличения количества обрабатываемых транзакций и/или клиентов.

АБС должна предусматривать  ввод и обработку операций посредством  электронного документооборота (workflow). Для документов должен быть предусмотрен набор состояний и стадий обработки, определенных банком.

Система должна формировать аналитические отчеты по критериям (как минимум): по клиентам и по продуктам.

Система должна обеспечивать конфиденциальность, целостность и доступность деловой информации.

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

Система должна иметь возможность импортирования данных из внешних приложений.

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

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

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

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

Система должна быть понятной, удобной в использовании и применять современные технологии построения интерфейса.

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

Система должна иметь возможность классифицировать пользователей и предоставлять  различным категориям пользователей  различные уровни доступа к системе  и данным: по объему операторских функций (доступ к определенным экранам и функциям); по степени доступа (просмотр/ввод/авторизация); Системный администратор должен иметь возможность создавать индивидуальные меню для конкретных пользователей.

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

Система должна осуществлять автоматическую проверку остатка денежных средств на счете  клиента перед списанием средств  со счета.

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

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

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

Система должна предусматривать возможность формирования автоматических операций. Такие операции должны настраиваться по произвольным шаблонам и иметь возможность формироваться по заранее определенному графику (stand-by orders). Примером таких операций может быть ежемесячное списание сумм коммунальных платежей сотрудников организации с ее расчетного счета.

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

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

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