Определение масштаба и содержания проекта со стороны заказчика

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

• список объектов, подлежащих внедрению в FlexCube
• список бизнес-продуктов, подлежащих миграции в FlexCube
• перечень основных систем, с которыми Flexcube должен быть интегрирован
• принципы реализации бизнес-функциональности в Flexcube. Более подробно описывается функциональность, которая будет перенесена на FlexCube не полностью
• принципы взаимодействия FlexCube с Midas.

Система FlexCube внедряется в два шага. Данный подход был утвержден в ходе проекта по выбору Core Banking Package. На первом шаге будет осуществлено внедрение системы для работы с физическими лицами, включая сотрудников банка. В ходе первого шага должна быть осуществлена миграция соответствующих данных из текущей системы в FlexCube. Основным критерием успешного внедрения FlexCube, его содержания является перенос работы с физ. лицами в новую систему. Это означает, что после завершения первого шага внедрения подразделения банка при работе с физ. лицами, их счетами, сделками будут использовать FlexCube вместо системы Midas и интегрированных с ним приложений. На втором шаге внедрения системы FlexCube должен быть осуществлен перенос оставшейся части клиентов и их продуктов из Midas в FlexCube. До завершения второго шага внедрения Midas и FlexCube будут функционировать параллельно. Основным критерием успешного завершения второго шага внедрения FlexCube является перенос всего бизнеса банка из системы Midas в FlexCube.

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

В FlexCube реализуются два стандарта бухгалтерского учета: IAS и RAS.

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

Все продуктовые модули FlexCube должны быть локализованы в части бухгалтерского учета, в части ведения и поддержания, необходимых для России параметров объектов FlexCube (счета, клиенты, сделки, словари и т.д.)

На рисунке3 приведена схема, на которой помечены модули, которые полностью или частично покрываются функциональностью системы FlexCube. Из этой схемы следует выделить следующие модули:

·        FX&MM. Предполагается, что банк будет использовать FlexCube, как Backoffice систему для FXMM операций, а в качестве Front Office системы будет использоваться in-house приложение FXMM

·        Representative office. В состав системы FlexCube входит модуль FlexCube Branch, который может быть использован в качестве решения для отделений банка

·         ATM и POS. При реализации задачи по созданию On-line интерфейса с карточной системой банка поддержка ATM и POS будет осуществляться непосредственно в FlexCube. В составе FlexCube присутствует специальное приложение для поддержки данных каналов доставки ATM Server. Вопрос об использовании данной функциональности FlexCube или альтернативного решения будет решен на этапе тренинга и определения детальной архитектуры Core Banking Package уже после начала проекта

·        Internal reporting, Controlling, Regulatory reporting. Предполагается, что данная функциональность будет реализована в FlexCube только частично. В основном в FlexCube будет осуществляться подготовка данных для создания отчетов. Сами же отчеты должны будут создаваться во внешних системах или посредством Business Objects.

Рис. 3 Покрытие модулями FlexCube функциональности банка

Отчетность

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

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

В части обязательной отчетности Банка России i-Flex реализует подготовку данных в необходимом для внешних систем формате. В качестве основной системы, реализующей обязательную отчетность для Банка России, будет использоваться решение компании GCP.

Archive system

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

Среди вопросов, требующих обязательного решения на этапе внедрения FlexCube, можно выделить следующие:

• изменение системы нумерации клиентов, счетов, сделок. Это потребует переработки большого количества приложений от самых маленьких (Excel, Word) до достаточно крупных (RSS)
•  Корреспонденция планов счетов в двух системах
• Миграция данных в FlexCube. Необходимо не только собрать непротиворечивую информацию о клиентах, их счетах, сделках из различных источников данных и загрузить ее в новую систему, но и исключить эти данные из дальнейшего использования в текущей системе
•  реализация транзакционного интерфейса между двумя системами и выверка межсистемных операций
•  выстраивание новых бизнес-процессов банка, минимизирующих операционные риски при работе с двумя системами
• поддержка режима 24x7. Поддержка данного режима может быть критичным моментом при планировании on-line интерфейса между карточным центром и FlexCube

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

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

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

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