2.2.5Особенности управления качеством проектов корпоративных информационных систем

Крупный проект по созданию информационной системы (ИС) предприятия всегда включает множество задач, связанных с общим управлением проектом, разработкой ПО, проектированием ИС, внедрением ERP-системы, каждая из которых сама по себе является проектом с присущими ему особенностями. Под крупным понимается проект, в котором:

• сметная стоимость - от 800 тыс. долл. и выше;

• срок реализации - от года и больше;

• число вовлеченных участников - от нескольких десятков до сотен человек, которые работают в трех и более организациях, часто территориально удаленных друг от друга;

• развиты цепочки субподрядных работ.

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

Общие методические указания по управлению качеством проектов даны в ИСО 10006:1996 "Административное управление качеством. Руководящие указания по обеспечению качества при управлении проектом", ИСО 10007:1995 "Административное управление качеством. Руководящие указания по управлению конфигурацией". По управлению качеством проектов в области информационных технологий (ИТ-проекты) существуют специализированные стандарты, например, стандарты COBIT или корпоративный стандарт Microsoft MSF. Но крупные проекты имеют три основные особенности.

Первая - смена задач в ходе проекта. Этим могут "страдать" и мелкие ИТ-проекты, но именно в крупных последствия бывают особенно тяжелыми. Часто первоначальная постановка задачи существенно меняется в ходе проекта. Кроме того, при внедрении проектных решений необходима реорганизация деятельности заказчика, при этом постоянно должны уточняться и корректироваться функциональность разрабатываемой системы и отслеживаться потребности заказчика при изменении его бизнес-процессов. Как правило, любое неуправляемое изменение в функциональности создаваемой ИС или работах, осуществляемых в рамках проекта, существенно сказывается на качестве проектных решений и может вообще привести к краху проекта. И это необходимо учитывать при управлении проектом.

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

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

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

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

Методы управления проектами и проектными рисками для малых и средних проектов достаточно проработаны и позволяют эффективно снижать уровень рисков и трудозатраты по проекту. Для ведения крупных проектов "стандартного" набора методов оказывается недостаточно (табл. 3).

Таблица 3

Масштаб проекта	Число работ	Число подпроектов	Связность работ	Методы управления
Малый	10-50	Нет	Низкая	PMI3, FMEA, MSF, личный опыт руководителя
Средний	50-100	Единицы	Низкая, средняя	Стандартные методики (ASAP4, PJM5, PMI), SPICE6, COBIT
Kрупный	100-1000	От нескольких десятков до нескольких сотен	Высокая	Проработаны слабо

3. PMI (Project Management Institute) - Методология управления проектами института управления проектами, Pennsylvania USA.

4. ASAP (Acceler-ated SAP) - методология внедрения ERP-системы SAP R/3 компании SAP.

5. PJM (Project Management) - Методология внедрения ERP-системы Oracle Appications корпорации Oracle.

6. SPICE (Software Process Improvement Capabilities and dEtermination) - Оценка и улучшение процессов разработки ПО.

В связи с этим возникает необходимость в разработке специфичной модели управления качеством проекта именно для крупных проектов ИС.