Файл: Управление проектом внедрения специализированного программного обеспечения в Банк.docx

Глава III. Управление проектом внедрения специализированного программного обеспечения в Банк

3.1. Характеристика внедряемого программного обеспечения в Банк

Банком «XXX» внедрялось специализированное программное обеспечение для автоматизированной оценки кредитоспособности клиента и для принятия решения о выдаче кредита. В качестве заказчика разработки и внедрения ПО выступал непосредственно Банк, в качестве исполнителя – поставщик программного обеспечения для финансового рынка.

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

• 
  Автоматизировать бизнес-процесс кредитования в Банке;
  
• 
  Автоматизировать современные методы оценки риска клиента и заявки в соответствии с кредитной политикой Банка;
  
• 
  Минимизировать время рассмотрения заявки на выдачу кредита;
  
• 
  Уменьшить операционные риски Банка;
  
• 
  Сформировать новое продуктовое предложение клиенту, соответствующее его риск-сегменту.
  

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

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



Рис. 15 Схема XML-обмена

После одного из последних обращений к системе XML-сообщение содержит в себе риск-сегмент заявки, после чего, согласно кредитной политике банка принимается решение о выдаче кредита.

---

3.2. Управление проектом внедрения ПО на основе водопадной модели

План проекта по внедрению автоматизированной системы по принятию решения о выдаче кредита составлялся на базе традиционной модели жизненного цикла проекта, то есть, в виде «водопада» - последовательных фаз, где каждая фаза не может быть начата до завершения предыдущей. Официальная дата начала проекта – 23 мая 2012 года.

Базовый план проекта и распределение ресурсов были построены в программе управления проектами Microsoft Office Project (рисунок 16):



Рис. 16 Базовый план проекта по внедрению ПО в банк

Соответствующая базовому плану диаграмма Ганта (визуализированная цепочка задач) представлена на рисунке 17:



Рис. 17 Диаграмма Ганта проекта

Как видно из рисунка 16, проект был спланирован менеджером как классический «водопад», причем этапы сформулированы довольно широко. В представленном выше плане проекта отсутствуют операции слияния и практически отсутствуют дробящиеся операции.

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

Сравнение запланированных и фактических сроков выполнения проекта в процессе выполнения работ продемонстрировано на рисунке 18. Среди 14 задач 9 из них имели существенные отклонения по длительности: задача № 3, задача № 4, задача № 5, задача № 6, задача № 7, задача № 8, задача № 10, задача № 11, задача № 12. На рисунке они выделены цветом:



Рис. 18 Отклонения фактического плана от базового

Для наглядности отклонений была построена диаграмма Ганта с отслеживанием, где серым выделены задачи базового плана, а синим – задачи реального плана (рисунок 19). Даже по этому рисунку видно, что фактическая длительность проекта намного превышает запланированную. Этот же факт дает основания предполагать, что и стоимость проекта значительно увеличилась.

---

Рис. 19 Диаграмма Ганта с отслеживанием

С помощью наблюдения за ходом выполнения проекта были выявлены и систематизированы следующие причины задержек задач проекта:

Задача № 3 «Сбор бизнес требований и документирование стратегии принятия решений».

Базовая длительность предполагалась равной 35 дням, фактическая составила 46 дней.

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

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

Задача №4 «Проектирование модели данных на базе кредитной политики»:

Базовая длительность предполагалась равной 3 дням, фактическая составила 14 дней.

• 
  Во время предыдущего этапа отдел маркетинга не участвовал в формировании требований к программному обеспечению, но на текущем этапе его представители решили внести собственные пожелания по работе внедряемой программы с клиентом. Эти изменения в требованиях, по словам исполнителя, в некоторых местах противоречили ТЗ, поэтому за доработку этих требований Банк заплатил 79 200 рублей.
  

Задача №6 «Проектирование общей логики архитектуры решения»:

Базовая длительность предполагалась равной 6 дням, фактическая составила 12 дней.

---

• 
  Задержки на этом этапе связаны с коммуникацией между исполнителем и компаниями, которые предоставляли дополнительные сервисы (CreditRegistry, ЦФТ).
  

Задача №8 «Разработка схемы XSD модели данных»:

Базовая длительность предполагалась равной 2 дням, фактическая составила 8 дней.

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

Задача №9 «Разработка тест-стенда для проверки корректности реализованной стратегии»:

Базовая длительность предполагалась равной 37 дням, фактическая составила 41 дней.

• 
  Тест-стенд получает на вход XML-сообщение, затем обращается к серверу, где находится программное обеспечение по принятию решения о выдаче кредита, обрабатывающее запрос, и после этого на экран возвращается новое, дополненное XML-сообщение с результатами проверки. Тест-стенд в своем первом релизе не имел функционала сохранения XML-ответов, что показалось крайне неудобным Банку. Проблема задержки на данном этапе вызвана разным толкованием ТЗ разработчиками и работниками банка. Исполнитель считал, что задача выполнена корректно, по крайней мере предмет спора не был описан в ТЗ, в то время как Банк посчитал что такой очевидный пункт не стоило даже подробно описывать. Дополнительные работы исполнитель оценил в 32 000 рублей.
  

Задача № 10 «Программирование стратегий во внедренной ИС»:

Базовая длительность предполагалась равной 33 дням, фактическая составила 54 дней.

• 
  Задержки на данном этапе связаны с явными изменениями бизнес требований программного обеспечения, вызванными корректировками отдела маркетинга, операционного отдела и отдела рисков. Многие из нововведений повлекли за собой изменения в модели данных (андеррайтеры из операционного отдела захотели видеть на интерфейсе распределение дохода по месяцам, произошло уточнение функционала некоторых кнопок на экранных формах, например, появилась возможность осуществления визуальной оценки клиента). Запросы на изменения на текущем этапе обошлись Банку в 84 000 рублей.
  

---

Задача № 11 «Модульное тестирование разработанной стратегии»:

Базовая длительность предполагалась равной 6 дням, фактическая вышла 19 дней.

• 
  С результатами тестирования были ознакомлены сотрудники отдела рисков Банка. Задержки во время выполнения данной задачи вызваны расхождением между разработчиками программы и сотрудниками отдела рисков по поводу корректности настроенной стратегии. Заказчиком были установлены новые требования, учитывающие динамику заявки клиента во времени (в ТЗ данный функционал описан не был). Трудозатраты на добавление такого функционала были оценены менеджером проекта в 32 часа, что в денежном выражении равно 16 000 рублям согласно ставке разработчика.
  

Задача №12: «Интеграционное тестирование внедренной ИС с фронт-офисным решением»:

Базовая длительность предполагалась равной 10 дням, фактическая составила 20 дней.

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

• 
  Внедряемое программное обеспечение рассчитывает рисковые показатели, риск-сегмент клиента, а также проверяет соответствие правилам кредитной политики банка. Вышеописанные действия предполагают формирование некоторых комментариев, которые в бизнес требованиях и ТЗ записаны на русском языке (пример «Клиент имеет негативную кредитную историю»). Их реализация была осуществлена на этапе программирования стратегии, однако на этапе интеграции с фронт-офисным решением выяснилось, что передача данных возможна только с помощью латинского алфавита; таким образом, разработчикам пришлось вводить понятие «транслитерации» для решения данной проблемы. Существенное время было потрачено на обсуждение проблемы между заказчиком проекта (Банком) и менеджером проекта.
  
• 
  Издержки, понесенные Банком на данном этапе, составили 72 000 рублей.
  

---