Перечень задач, которые будут выполнены в проекте
«Внедрение бизнес процессов»
«Business Implementation»
Следующие задачи решаются в ходе проекта:
· Подготовка функциональных требований по поставке кастомизированных (измененных под требования Банка) модулей FlexCube.
· Параметризация системы
· Описание бизнес-процессов TO-BE
· Параметризация системы FlexCube
· Изучение функциональной спецификации
· Разработка стратегии миграции
· Business Process Re-engineering, общее представление о том, как будут выглядеть бизнес-процессы Банка после завершения проекта внедрения.
Задачи, которые решались в ходе этого подпроекта являются основополагающими для удачного выполнения проекта. На этапе кастомизации происходило изменение модулей новой банковской системы под требования банка. На этапе описания бизнес процессов определялись, какие процессы используются в текущей банковской системе, и как будут выглядеть бизнес процессы в новой системе. В задачи параметризации входит определение всех настроек и параметров системы, а так же бухгалтерские настройки General Ledger, отчетности и банковских продуктов. Поскольку предполагается поставка трех лотов, процедура параметризации и тестирования должна быть произведена так же трижды. Так же составлялась концепция миграции данных, определялось, как данные будут переноситься из системы Midas в FlexCube.
«Кассовые операции и платежи в национальной валюте»
«Teller and Local payments»
Следующие задачи решаются в ходе проекта:
- Подготовка бизнес-требований и функциональных спецификаций модули Рублевых платежей и Кассы. Эти модули в рамках системы FlexCube будут сделаны с нуля специально по заказу Банка
- Получение от поставщика документа, описывающего, как именно компания I-Flex будет изменять систему, чтобы удовлетворить требования Банка, а так же получение детальных технических спецификации, которые Банк должен согласовать.
- Подготовка детальных процедур «TO BE» по кассовым и платежным продуктам с учетом новой системы и рекомендаций специалистов Business Process Re-engineering.
Основной задачей данного подпроекта является составление функциональной спецификации для кассового модуля и модуля платежей в национальной валюте. Так же важной задачей является проведение параметризации и тестирования модуля Кассовых операций и модуля Локальных платежей.
«Архитектура приложений, интеграция, миграция, отчетность»
«Application Architecture/Integration/Conversion/Reporting»
Следующие задачи решаются в ходе проекта:
- Описания текущей архитектуры приложений
- Разработка новой архитектуры приложений
- Описание интерфейсов с новой системой
- Детализация каталога отчетов
- Разработка концепции формирования отчетности банка
- Разработка концепции реализации миграции данных
- Разработка плана миграции данных
- Разработка плана очистки данных
Основной задачей этого подпроекта является описание текущей и бедующей архитектуры системы, а так же разработка и управление процессом интеграции приложений Банка и новой АБС.
«Инфраструктура/ Тестирование/ Внедрение»
«Infrastructure/Test/Cut-over»
Следующие задачи решаются в ходе проекта:
- Разработка Стратегии тестирования, плана тестирования и шаблонов документов по тестированию в проекте «Замена АБС».
- Сопровождение процесса параметризации.
- Развертывание нового тестового сервера и комплексной тестовой среды, включающей FlexCube, MIDAS, RSS, GCP и др. системы и модули
- Разработка стратегии внедрения АБС
- Проработка процесса передачи на сопровождение и эксплуатацию в УИТ новой АБС – FlexCube
Члены подпроекта осуществляют установку всего программного обеспечения, поставляемого в Банк, а также курируют процесс отслеживания статуса ошибок, начиная от их обнаружения вплоть до момента полного исправления в установленной системе и процесс управлением конфигурациями.
«Обучение конечных пользователей/Коммуникация»
«Training and communication»
Следующие задачи решаются в ходе проекта:
- Разработать нормативные документы по внутренним коммуникациям
- Составление структуры тренинга для конечных пользователей
- Выделение и обучение со-тренеров из подразделений.
Основными задачами членов подпроекта являются привлечение сотрудников банка для тестирования функциональности системы, чтобы убедиться, что в АБС реализовано ровно то, что было заказано, а так же управлением процессом обучения конечных пользователей.
5.3. Концепция миграции данных
«Концепция миграции данных» определяет:
- цели миграции;
- принципы отбора данных подлежащих переносу;
- участников процесса миграции и зону их ответственности;
- основные принципы выверки данных;
- основные этапы миграции;
Целью процесса миграции, является:
- перенос объектов данных, необходимых для работы, из системы Midas во FlexCube
- изменение статуса перенесенных объектов в информационные системы Банка
Критерием достижения цели, является положительный результат окончательной выверки данных между ИС Банка и FlexCube.
Этап очистки данных предваряет этап миграции. Очистка данных ведется в исходных системах банка. Очистка данных не всегда возможна в виду особенностей реализации функциональности систем.
Загрузка данных во FlexCube возможна только по завершению параметризации системы.
После успешного завершения процесса миграции, необходимо инициализировать данные во внешних системах, использующих данные из FlexCube.
Для построения списка переносимых данных используется продуктовый подход. То есть, рассматриваются все объекты данных для переносимых во FlexCube продуктов. Список продуктов предоставляется и утверждается подпроектом Business Implementation. Осуществляется перенос только актуальной информации. Исторические данные не подлежат переносу во FlexCube.
Миграция данных - итеративный процесс, и не может быть проведен в один шаг. При обнаружении ошибок, допущенных при: анализе данных, их интеграции, маппировании, разработке процедур конверсий, тестировании, выверки отчетов и т.д. - предусмотрен возврат на предыдущий уровень. План миграции может считаться окончательно утвержденным только после завершения параметризации системы, тестирования скриптов загрузки данных и выверки отчетов между системами.
Выверка данных производится бизнес подразделениями, либо автоматически на основании критериев сформулированных бизнес подразделениями.
Миграция считается успешной:
- при отсутствии расхождений в отчетах двух систем;
- при наличии объяснимых расхождений, причиной которых являются различные способы обработки данных, или заранее описанные исключения.
Недавно был пересмотрен подход к методу внедрения. Если первоначально планировалось внедрять систему для всех клиентов-физ. лиц во всех отделениях и филиалах одновременно, то новым решением является внедрение "By Branch". При таком методе первое внедрение производится в одном филиале, желательно новом с небольшой клиентской базой. Вся техническая поддержка будет сконцентрирована на одном филиале. После успешного внедрения и небольшого периода работы на новой системе банк внедрит сразу все остальные филиалы и отделения.
Плюсами такого метода является снижение риска внедрения проекта за счет получения опыта полного внедрения на ограниченной функциональности и упрощение сложной процедуры миграции.
Из недостатков я бы отметил следующее: потребуются значительные усилия по работе с компанией I-Flex – согласование изменения подхода внедрения, изменение проектного плана, требования по аллокации дополнительных ресурсов I-Flex на новые интерфейсы и ChRq, организация подготовки функциональной спецификации и разработки. Как следствие это приведет к увеличению общего срока проекта. К сожалению, поставщик новой банковской системы зарекомендовал себя с не лучшей стороны, поставляя некачественные модули, которые требовали доработки, поэтому такой подход внедрения "By Branch" скорее всего, оправдан. Так же мне кажется, что после внедрения в первом филиале банка системы FlexCube , внедрение сразу во все остальные филиалы и отделения не удастся и нам придется продолжать внедрение по бранчам. Это связано с очень неустойчивой работы системы при увеличении нагрузок на неё, поэтому придется постепенно увеличить нагрузки, переводя новые филиалы на систему FlexCube.
| 
