5.1 Детализация проекта, используя технологию декомпозиции
«Внедрение бизнес процессов»
«Business Implementation»
В рамках этого подпроекта осуществляется “Business Process Re-design”. Цели и задачи подпроекта «Business Implementation» сводятся к тому, что все бизнес процессы банка должны быть проанализированы и скоординированы с новой системой FlexCube.
Основные проблемы, с которыми столкнулись в этом проекте связаны с кастомизацией и параметризацией системы, подготовки функциональных спецификаций, а так же составлением GAP анализа. Так же в виду ограничения проекта по срокам и необходимостью работы в жестких временных условиях испытывался острый дефицит в ресурсах, на подпроект было выделено меньше людей, чем требуется для покрытия столь большого количества вопросов.
На этапе кастомизации проекта мы столкнулись с проблемой непонимания поставщиком российской специфики бизнеса и того, как мы хотим изменить поставляемые модули под требования банка. Как результат поставляемые модули не соответствовали предъявленным к ним требованиям и функциональной спецификации, которая была разработана, приходилось повторно объяснять поставщику, что мы от них хотим получить. Доходило, до того, что члены проектной команды сами объясняли поставщику системы, где у них ошибки и как их нужно исправить. Вследствие большого количества доработок по поставляемым модулям системы приходилось несколько раз пересматривать параметризацию системы.
В ходе заключения договора с компанией I-Flex было определено и описано отдельным пунктом договора, что все решения по GAP они предоставляют нам бесплатно, но в самом проекте, когда находились “дыры” в функционале их системы поставщик хотел деньги за их исправление. Приходилось выходить на уровень менеджеров проекта, для того что бы урегулировать эти вопросы. Все это затягивало выполнения проекта и не позволяло выполнять намеченные работы в заданные сроки. Применение штрафных санкций к поставщику системы, так же не принесло успеха. В этом случае они замыкались, уходили в себя и практически прекращали работы по проекту. Наши западные акционеры, имеющие опыт работы с этой компанией не рекомендовали использовать против них “пенальти”, а пытаться договариваться путем переговоров. В итоге после переговоров на уровне председателя правления банка и членов правления с высшими руководителями компании I-Flex удалось наладить процесс работы и понимания с поставщиком системы. Поэтому пока удалось организовать нормальный рабочий процесс было потерянно достаточно много времени – около 8 месяцев.
Мне кажется, что наш банк, выступая в роли заказчика, не имел опыта работы с поставщиками такого размера и не предполагал, как можно наладить рабочий процесс в случае не исполнения договора с их стороны. Это явилось следствием не учтенных рисков, что поставщик не будет исполнять заключенный договор в полном объеме и в заданный срок. Если бы мы учли такой риск в самом начале, то я думаю смогли бы предотвратить или минимизировать возникшие проблемы.
«Кассовые операции и платежи в национальной валюте»
«Teller and Local payments»
Основная цель под-проекта - внедрение полнофункциональных модулей для кассовых операций и платежей в рублях. Эти модули в рамках системы FlexCube будут сделаны с нуля специально по заказу Банка. В ходе внедрения этих модулей сократиться бумажный документооборот и как следствие - ускориться обработка операций. Одновременно с этим, в отделениях будут работать две отдельные кассы – для физических и юридических лиц.
Основной проблемой, с которой пришлось столкнуться подпроектной команде это долго и детально описывать специалистам I-Flex особенности проведения кассовых и платежных операций в России с учетом запутанного законодательства. Так же помимо этого компания I-Flex обязалась в рамках проекта по внедрению системы FlexCube бесплатно локализовать кассовый модуль и реализовать отчетность по кассовым операциям в системе.
Мне кажется, поставщик не представлял, объемы работ, которые ему предстоит сделать или если представлял, то обманул нас, сказав, что сможет исполнить заявленные работы точно в срок. Я склоняюсь, все же, что они не понимали, во, что ввязались. В ходе описания процессов поставщик признавался, что он не понимает схемы, что российская банковская система намного отличается от западных. Как следствие не исполнение поставщиком заданного объема работ в намеченные сроки, поставка продуктов с неполной функциональностью и ошибками, требующих дополнительных доработок.
Мне кажется, что вопрос с локализацией кассового модуля надо было рассмотреть более подробно. Надо было дать понять поставщику, какой объем работ его ожидает в рамках этого проекта, что бы он смог реально оценить свои возможности о выполнении всего объема работ в заданные сроки.
«Архитектура приложений, интеграция, миграция, отчетность»
«Application Architecture/Integration/Conversion/Reporting»
«Инфраструктура/Тестирование/Внедрение»
«Infrastructure/Test/Cut-over»
Основная цель подпроекта - техническое обеспечение подпроектных команд на весь период работы, развертывание и управление техническими средами, включая сервера, системное ПО, прикладное ПО, интерфейсы и т.д. Разработка стратегии тестирования, организация и координация процессов тестирования систем перед передачей в промышленную эксплуатацию, а так же последующий переход на новую банковскую систему. Бизнес подразделения совместно с сотрудниками проекта подготавливали test case, на основании которых проводилось тестирование.
В тестировании заняты как представители проектной команды, так и представители бизнеса. Сначала тестирование проводят представители проектной команды, если в ходе их тестирования не выявлено явных ошибок, то в тестировании принимают участие представители бизнес подразделений, которым выдается инструкция, где описано, что надо сделать. После ввода тестовых данных бизнес подразделения проверяют полученный результат, если он соответствует тому, что должно было получиться, то считается, что тест успешно завершен, если выявлены ошибки, то указываются какие.
Ошибки регистрируются в Request Tracker. Используется следующая классификация ошибок по приоритетам:
- Priority 1 (high) - грубые ошибки c серьезными последствиями для промышленной системы. Должны быть исправлены к внедрению.
- Priority 2 (medium)- ошибки, влияющие на систему в незначительной степени. Не обязательно должны быть исправлены к моменту внедрения системы в промышленную эксплуатацию, но для них должны быть workaround
- Priority 3 (low) - незначительные расхождения
- СR – Change Request, ошибка вызвана отсутствием спецификации или ошибкой в спецификации.
Основные проблемы, с которыми столкнулись участники подпроекта это: i-flex имеет тенденцию занижать приоритеты ошибок или не признавать их, ссылаясь, например, на неправильную параметризацию. Низкое качество предоставляемого софта, долго не получалось развернуть систему из-за возникающих ошибок, когда же её развернули наблюдалось неустойчивая работа системы, при увеличении нагрузке на неё происходил сбой и она падала. Задержки поставляемых модулей для установки на тестовую систему для организации последующего тестирования.
Как мне кажется являясь заказчиком системы мы должны были предвидеть эти риски и для их минимизации нам было просто необходимо в ходе заключения договора с компанией I-Flex на поставку банковской системы дополнительно заключить соглашение Service Level Agreement (SLA) для эффективного устранения ошибок, где должны учитываться не только количественные показатели, но и качественные. Так же стоило изначально заложить 30% времени на задержки со стороны I-flex, что бы иметь резерв времени. Возможно, эти меры позволили бы нам избежать многих проблем возникающих в ходе реализации проекта.
«Обучение конечных пользователей/Коммуникация»
«Training and communication»
Основная цель подпроекта – организовать обучение для сотрудников банка, являющихся пользователями банковской системы для операций клиентов банка - физических лиц. Информировать сотрудников, не вовлеченных в работу по замене АБС непосредственно, о ходе проекта. Осуществление коммуникаций между участниками проекта, а также между участниками проекта и сотрудниками банка не вовлеченными в проект. Так же сотрудники подпроекта отвечают за документирование информации о проекте и доступности к этой информации всех участников проекта. База данных о ходе проекта и всех документах, которые были сделаны в ходе проекта, ведется в почтовой системе Lotus Notes. Доступ к этой базе имеют все члены проектной команды, а так же некоторые пользователи линейных подразделений, которые частично привлечены для работе в проекте. Основные проблемы, с которыми столкнулись сотрудники этого подпроекта это: сложность получения информации, которую необходимо получить в рамках проекта от линейных подразделений. Так же не все подразделения выдерживают поставленные сроки для предоставления информации или относятся к запросу от проекта слишком формально.
Еще один сложный момент – согласования решений по вопросам, которые лежат на границе ответственности различных линейных подразделений. Бывает сложно свести воедино мнение разных групп заказчиков.
Я считаю, что для предотвращения возникших проблем членам подпроектной команды отвечающим за коммуникации необходимо было донести до сотрудников линейных подразделений всю важность совместной работы над внедрением проекта. Потому что после его окончания именно им, сотрудникам банка придется работать на этой системе. И насколько гладко пройдет процесс перехода с одной системы на другую, и насколько эта система будет работоспособна, немаловажную роль играют линейные бизнес подразделения, которые привлекаются для составления функциональных спецификаций и тестирования готовых продуктов.
| 
