Завершение проектов

Переход на рабочую эксплуатацию системы обычно заканчивается
подписанием акта о проделанной работе. Однако большое количество
недоработок и недовольство пользователей нельзя назвать успешным
завершением. Таким образом, взаимодействие с разработчиками не
заканчивается рабочей эксплуатацией, а переходит в новую стадию—
сопровождение. Не стоит требовать от разработчиков немедленного
устранения всех недочетов. Лучше в течение некоторого времени дать
пользователям поработать с новой системой, почувствовать ее возмож-
ности и преимущества перед старой. И только после того, как отрица-
тельные эмоции улягутся и пользователи смогут более квалифициро-
ванно говорить о достоинствах и недостатках нового решения, необхо-
димо провести их опрос и составить план устранения действительно
важных недоработок. При этом часть проблем к этому времени смогут
снять сотрудники автоматизации банка. А остальные решит компания
разработчика, которая, получив аргументированные и понятные претен-
зии, не сможет отказать своему клиенту.

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

Глава 9. Анализ рисков при реализации проектов

Развитие информационных систем в современном мире требует все
больших и больших инвестиций. Затраты современного коммерческого
банка на решение информационных задач соизмеримы, а нередко и
превосходят все остальные затраты на содержание организации. По-
этому неудачи информационных проектов очень болезненны. Но еще
больший ущерб приносят упущенная прибыль, нереализованные услу-
ги, аналитические ошибки.

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

Мы уже упоминали, что доля неудачных проектов крайне высока.
Почему это происходит и кто виноват в подобных ошибках? Наказать и
уволить разработчиков и отдельных исполнителей — самое простое
решение, однако это не выход, так как потом выясняется, что ошибки
продолжают появляться и проект заходит в тупик.

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

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

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