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

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

Разработка функциональных требований включает в себя следующие шаги:

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

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

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

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

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

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

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

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

Результатом этой работы должен стать документ «Требования к системе», являющийся частью тендерной документации. Его объем в зависимости от размера и сложности банка может составлять от 50 до 1500 страниц. Если документ построен правильно и в нем не излагается общепринятых требований, то для среднего банка вполне достаточно 100-200 страниц. Не следует пытаться описать всю технологию работы банка со всеми дета­лями, используя специальные средства и стандарты моделирования (IDEF, ARIS, ABC, UML, BPEL, BPMN и др.), так как излишняя детализация может обойтись достаточно дорого как с точки зрения денег, так и с точки зрения временных затрат.

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

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

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

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

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

• предусматривать ввод и обработку операций посредством электронного документооборота (work flow). Для документов должен быть предусмо­трен набор состояний и стадий обработки, определенных банком;

• предусматривать возможность получения отчетов о стадии обработки документов;

• формировать аналитические отчеты как минимум по двум критериям: по клиентам и по продуктам;

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

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

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

• содержать гибкие возможности настройки отчетов, доступные для применения обычными пользователями. Система должна автоматизи­ровать (где это возможно) подготовку отчетности для ЦБ РФ, а также налоговой отчетности;

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

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

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

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

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

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

• обеспечивать следующие требования парольной политики:

— все пользователи вводят уникальный идентификатор и пароль для получения доступа в систему;

— после определенного количества неудачных попыток (3 раза) от­дельного пользователя получить доступ система должна закрыть его для такого пользователя до снятия этого статуса администра­тором. Система ведет учет неудачных попыток и протоколирует их; хранимые в ней пароли должны быть зашифрованы и должны составлять как минимум 8 символов. При этом предусматривается возможность устанавливать различную длину пароля для различных групп пользователей;

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

— система периодически запрашивает изменение паролей пользова­телями;

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

— пользователям сообщается о предыдущих удачных/неудачных по­пытках доступа в систему в момент входа, включая время заверше­ния предыдущего сеанса;

— предусматривается возможность ограничивать время и рабочее место (IP-адрес, МАС-адрес или имя компьютера) пользователей в системе;

— соединение с системой должно автоматически прерываться, если пользователь не работает в системе определенное количество вре­мени.

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

• позволять осуществление автоматизированной подготовки писем для рассылки заинтересованным сторонам (клиентам, налоговым органам и т. п.) по группам счетов или клиентов. Формирование выписок по счетам клиентов, писем клиентам производится в формате, необходи­мом для их автоматической упаковки в конверты;

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

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

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

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

• предусматривать возможность как полностью блокировать операции по счету клиента, так и разрешать только дебетовые или кредитовые операции. Изменение статуса счета производится уполномоченным сотрудником;

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

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

• иметь возможность копирования создаваемых отчетов в файлы, до­ступные для других офисных приложений, с целью их дальнейшей обработки (например, Excel, Access);

• отслеживать все стадии жизненного цикла кредита, начиная от предо­ставления заявки до закрытия договора;

• автоматически рассчитывать сумму резерва и подготавливать для по­следующего подтверждения и авторизации соответствующие проводки на сумму создаваемого резерва на потери по ссудам;

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

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

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

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

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

Рассмотрим недостатки тех и других. В зарубежных это:

• относительно высокая стоимость решения и его сопровождения;

• сложности с поддержкой российский специфики, и прежде всего бухгал­терского учета и отчетности в соответствии с требованиями ЦБ РФ;

• более долгое внедрение (обычно исчисляемое годами).

В чем же основные недостатки российских систем? Ниже приведены основные отличия.

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

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

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

• Недостаток механизмов автоматизации управления банком: управлен­ческая отчетность, on-line-анализ рентабельности продуктов и услуг, прибыльности клиентов, средств моделирования, механизмов авто­матизации управления активами и пассивами, слабая визуализация управленческой информации.

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

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