Анализ целесообразности, осуществимости, известный в западной практике как процесс Feasibility Study, является обязательной составляющей начальной стадии всех проектов по покупке или разработке системы автоматизации: на основе оценки имеющейся информации принимается решение о покупке новой сторонней системы автоматизации или ее разработке собственными силами. Результатом анализа может быть и вывод об отсутствии адекватных решений, их недостижимости или необходимости отложить процесс замены системы. Также производится анализ экономической, технической, технологической и социальной целесообразности нового решения.
К сожалению, в российской практике этот процесс редко бывает формализован, и решение о покупке или разработке принимается без анализа соответствующих критических факторов и всех аспектов, что существенно повышает риски проектов автоматизации.
До начала проекта банку необходимо найти четкие ответы на следующие вопросы:
* Каковы временные рамки для процесса выбора, внедрения и возможной эксплуатации решения?
* Насколько новое решение действительно продиктовано требованиями бизнеса и существуют ли альтернативные варианты?
* Что необходимо (и возможно) предпринять, чтобы существующая система (Legacy System) удовлетворила новым задачам и реалиям?
* Есть ли на рынке решения, способные удовлетворить требованиям банка?
* Какова примерная стоимость собственной и сторонней разработки?
* Соответствует ли замена информационной системы общей стратегии банка?
* Каковы основные риски, с которыми столкнется банк при том или ином сценарии?
Далее должна быть обоснована целесообразность и осуществимость с экономической, технической, технологической (операционной) и социальной точек зрения.
Расчет экономической целесообразности включает сопоставление возможных затрат и потенциальной экономической выгоды от использования нового решения. Для этого могут анализироваться такие параметры, как:
- период окупаемости системы;
- чистая приведенная стоимость;
- норма рентабельности;
- общая стоимость владения и др.
Цель всего этого процесса - хотя бы примерно оценить экономическую эффективность решения.
Техническая осуществимость состоит в оценке адекватности существующей технической и телекоммуникационной базы для нового решения. При ее недостаточности требуется дополнительная оценка возможных сценариев развития технической инфраструктуры, стоимости и времени таких изменений.
Технологическая (или операционная) целесообразность включает оценку возможных плюсов от использования новой системы - повышения качества услуг, расширения спектра продуктов и достижения других требований банковского бизнеса.
Важным этапом является и анализ социальных составляющих этого процесса, который включает оценку следующих аспектов: насколько пользователи будут поддерживать новое решение и готовы ли они к повышенным нагрузкам и обучению работе на новом продукте, насколько их квалификация соответствует современным требованиям и технологиям, реалистичны ли их требования и ожидания. Как показывает практика, неудачи многих проектов в этой области носят именно социальный характер.
На основании всей собранной информации высшим руководством принимается окончательное решение о покупке или разработке новой системы. Не существует типового решения этой задачи. Для банка оно всегда индивидуально и каждый раз должно базироваться на результатах анализа, хотя на практике большинство банков, как российских, так и зарубежных, принимают решения в пользу сторонних разработок.
Следующим шагом является разработка функциональных требований. Детальные требования к системе автоматизации банковской деятельности должны быть определены также на предварительных стадиях проекта, до начала непосредственного выбора системы.
Для организации процесса определения требований к системе может быть рекомендован следующий подход. Данный этап осуществляется специальной командой сотрудников банка или консультантов во взаимодействии со специалистами функциональных подразделений под руководством выделенного руководителя, обычно высшего звена (члена правления). Иногда в крупных организациях такие команды создаются еще на предыдущей стадии (анализа целесообразности). Разработка функциональных требований включает:
* проведение интервью с руководством и представителями бизнес-подразделений банка;
* ознакомление с существующей и планируемой технологией, бизнес-процессами, особенностями работы и информационных потоков;
* оценку организационной структуры, стратегии и направлений развития банка и их влияния на выбор АБС;
* осуществление детального анализа используемых систем;
* анализ существующих требований к системе по функциональным возможностям и отчетным средствам, их доработку и установление приоритетов;
* определение, согласование и утверждение требований к техническим характеристикам системы - объемам операций, оперативности, защищенности данных и т.д.;
* определение/уточнение/утверждение основных бизнес-процессов банка, подлежащих и не подлежащих автоматизации, а также их взаимодействия;
* определение и утверждение требований к системе.
Результатом этой работы должен стать документ "Требования к системе", который является частью тендерной документации. Его объем в зависимости от размера и сложности банка может составлять от 50 до 1500 страниц. Если документ построен правильно и в нем не излагаются общепринятые требования, то для среднего банка объем обычно не превышает 70-100 страниц. Не следует пытаться описать технологию работы банка со всеми деталями, используя специальные средства и стандарты моделирования (IDEFO, DFD, UML), так как излишняя детализация может обойтись достаточно дорого - как с точки зрения денег, так и с точки зрения временных затрат.
Рассмотрим общие требования к банковским информационным системам. Система должна:
- базироваться на современных технологиях. Так, современные платформы (ОС и СУБД) позволяют реализовать гибкость, открытость и масштабируемость системы;
- представлять собой оптимальное, интегрированное решение и иметь единую базу статистических данных; иметь возможность интеграции с существующими системами или модулями;
- иметь достаточное функциональное покрытие и возможность расширения (наращивания) функциональных возможностей в соответствии с потребностями банка, изменениями законодательства и т.д.;
- иметь возможность увеличения количества обрабатываемых транзакций и/или клиентов;
- предусматривать ввод и обработку операций посредством электронного документооборота (work flow). Для документов должен быть предусмотрен набор состояний и стадий обработки, определенных банком;
- предусматривать возможность получения отчетов о стадии обработки документов;
- формировать аналитические отчеты как минимум по двум критериям: по клиентам и по продуктам;
- обеспечивать конфиденциальность, целостность и доступность деловой информации;
- обеспечивать контроль за действиями пользователей на системном и прикладном уровне и их последующий анализ;
- иметь возможность импортирования данных из внешних приложений;
- содержать гибкие возможности настройки отчетов, доступные для использования обычными пользователями. Отчеты можно формировать для любой информации, содержащейся в АБС. Информацию, обрабатываемую в разных модулях АБС, можно группировать в один отчет. Система должна автоматизировать (где это возможно) подготовку отчетности для ЦБ РФ, а также налоговой отчетности;
- иметь инструментарий (генератор отчетов), позволяющий: определять внешний вид отчетов; данные, на основе которых будет формироваться отчет; порядок сортировки и критерии отбора как для отчетов, получаемых на регулярной основе, так и для разовых отчетов по специальному запросу. Также в системе должна существовать возможность модификации существующих отчетов;
- проверять данные, вводимые пользователем или поступающие через интерфейс обмена данными, и осуществлять лексический, синтаксический и семантический контроль. Примерами контроля могут быть: проверка формата (например, цифровой); существование кода клиента в справочнике; отклонение от обычных значений; задвоение операции; диапазон дат; проверка соответствия остатка типу счета (активный, пассивный); достаточность средств на счете; превышение лимитов; проверка критерия (сумма и счет);
- предусматривать возможность верификации и авторизации действий и документов персоналом, не связанным со вводом операции. Должна существовать возможность настройки данной опции для определенных видов операций или операций, превышающих установленный лимит;
- быть понятной, легкой в эксплуатации и использовать современные технологии построения интерфейса;
- вести протокол всех операций, который должен быть доступен для просмотра по запросу администратора безопасности и иметь разграниченный доступ. Как минимум следующие данные должны содержаться в протоколе операций: время, идентификатор пользователя, рабочее место, приложение и тип операции. Ручной ввод, пакетная обработка данных и обработка данных через внешние интерфейсы также должны фиксироваться в протоколе. Протокол операций пользователей в системе должен быть защищен от изменений;
- иметь возможность классифицировать пользователей и предоставлять различным категориям пользователей различные уровни доступа к системе и данным: по объему операторских функций (доступ к определенным экранам и функциям); по степени доступа (просмотр/ввод/авторизация); системный администратор должен иметь возможность создавать индивидуальные меню для конкретных пользователей;