Управление качеством проектов корпоративных информационных систем

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

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

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

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

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

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

На схеме 1 показаны основные элементы крупномасштабных проектов.

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

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

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

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

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

Таблица 1

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) - Оценка и улучшение процессов разработки ПО.

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

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

• с управлением проектом;
• с продуктом проекта.

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

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

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

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

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

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

Таблица 2

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

В основе модели управления качеством крупного проекта должна находиться система управления рисками проекта.

Практически любой процесс проекта имеет свой собственный (специфичный) набор рисков и некоторый общий набор рисков для всех процессов проекта. В соответствии со стандартом ИСО 10006:1996 управление рисками включает следующие виды деятельности:

• выявление - определение рисков в проекте;
• оценка - оценивание вероятности появления рисковых событий и их воздействия на проект;
• развитие реакции - разработка планов реагирования на риски;
• контроль за рисками - реализация и обновление рисковых планов.

Для выявления рисков первоначально необходимо выбрать объекты, которые будут анализироваться. К ним относятся процессы и продукты проекта. Как правило, в сферу анализа рисков невозможно включить все процессы и продукты проекта, так как это может потребовать неприемлемых затрат времени и сил, поэтому приходится останавливаться на некоторых наиболее важных и критичных процессах и продуктах. Поможет в выборе таких процессов анализ конфигурации. В стандартах ИСО/МЭК 12207:1995 "Информационные технологии. Процессы жизненного цикла программного обеспечения" и ИСО 10007:1995 представлены процедуры и задачи, которые должны выполняться при управлении конфигурацией. Конфигурация проекта обычно основывается на спецификациях ИС на определенном этапе работ и процессах, выполнение которых приведет к созданию этой системы. Так же можно определить взаимосвязи процессов и соответственно наметить возможные "переходные" риски.

При выявлении и анализе рисков существенную помощь могут оказать формализованные методы. Например, в стандарте SPICE описаны 35 основных процессов, используемых при создании ИС и методы их оценки. Здесь же приводятся пять категорий процессов (взаимодействия поставщика и потребителя, проектирования, обеспечения, управления и организационные процессы) и набор соответствующих базовых методов. При сравнении действующих процессов проекта с приведенными референтными моделями можно выявить вероятные риски каждого из процессов [4]. Процессы, уровень адекватности которых оказался неудовлетворительным, имеют высокую вероятность возникновения риска (схема 2). Наличие в стандарте также перечня входных и выходных данных, необходимых для исследования того или иного метода, позволяет при оценке процесса определить вид риска. Конечно, ни один стандарт не в состоянии описать полный набор возможных методов и данных, которые могут применяться в том или ином проекте, но отсутствие базовых методов в управлении проектом почти наверняка приведет к возникновению риска.

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

Важным этапом работ по управлению риском проекта является разработка планов реагирования на риск. Как правило, для разработки таких планов недостаточно идентифицировать и оценить риски, необходимо еще и провести анализ причин их возникновения. Одним из простых и достаточно эффективных методов такого анализа может служить метод FME(С)A (Failure Mode, Effects and (Criticality) Analysis) - метод анализа видов, последствий и (критичности) отказов (дефектов). На этом этапе работ определяется стратегия внесения изменений в проект, так как конфигурация проекта находится в прямой зависимости от вероятных рисков процессов. При необходимости планы реагирования на риск должны строиться на основе данных предыдущих аналогичных проектов, так как это уменьшит вероятность внесения новых рисков. Составляя планы реагирования на риск, целесообразно учитывать возможность с помощью одного мероприятия предотвратить несколько рисков. Такая возможность появляется, например, при наличии "переходных" рисков.

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

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

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

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

На все группы внутренних рисков проекта существенно влияют:

• организация проекта;
• конфигурация проектируемой системы;
• ресурсы проекта;
• структура процессов проекта.

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

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

Конфигурация проектируемой системы существенно влияет на состав работ и участников проекта, структуру рисков и практически всегда подвергается изменениям. Это обусловлено уникальностью проекта и создаваемой ИС.

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

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

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

• риски "наследуются", т. е. риск на определенной стадии проекта может зависеть от факторов, не только действующих на этой стадии, но и от действовавших на предыдущих;
• риски изменяются в зависимости от того, произошло или не произошло рисковое событие на предыдущей стадии проекта.

Эти особенности обычно не учитывают при анализе рисков "некрупных" проектов, риски считают независимыми и неизменными [4], при этом ошибка лежит в допустимых пределах. А вот в случае крупных проектов пренебрежение приведенными особенностями может привести к существенным ошибкам.

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

Верхний уровень рисков связан со стратегическими целями проекта, такими как:

• организация и ведение процессов проекта;
• изменения затрат и сроков проекта;
• изменение требований к продукту проекта.

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

 Так как все процессы проекта взаимосвязаны, и выполнение их обычно идет параллельно, то возникает ситуация "переходных" рисков двух направлений. Горизонтальные - риски одного процесса переходят в риски другого процесса, и вертикальные - риски совокупности процессов переходят в риски верхнего уровня (например, из-за ошибок при выявлении требований к системе необходимо изменять функционал системы, а это ведет к риску увеличения затрат и сроков работ и может привести к изменениям целей проекта). Используя сетевые графики и диаграммы Ганта, традиционно применяемые для администрирования и управления проектом, выявить наследование и передачу рисков оказывается затруднительно (схема 3).

При передаче риска из процесса в процесс или с одного этапа работ на следующий действует правило 10-кратного увеличения последствий возникновения рискового события. Например, если риск одного процесса не был выявлен и повлиял на выполнение другого, связанного с первым процессом, то усилия на устранение последствий возникшего рискового события потребуют в 10 раз больше затрат (временных, материальных, людских), чем если бы этот риск был устранен в первом процессе [5]. Таким образом, важно выбрать такую методику оценки риска, которая бы позволяла учитывать возможность передачи риска из процесса в процесс. На схеме 4 представлен фрагмент структуры процессов проекта (в соответствии с графиком схемы 3) и указан момент возникновения рисковых событий P1 и P2, которые передаются в последующие процессы. Числа в узлах графа обозначают номер работы по списку, а числа в скобках - число вероятных рисков, присущих каждой работе.

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

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

1. COBIT - Released by the COBIT Steering Committee and the Information Systems Audit and Control Foundation. 2nd edition, 1998.
2. Microsoft MSF - Microsoft Solutions Framework, 1999.
3. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. - М.: Синтег, 2000.
4. ISO/IEC 15504-8:1998. Information technology. Software process assessment.
5. Круглов М.Г., Сергеев С.К., Такташов В.А. Менеджмент систем качества. - М.: ИПК Издательство стандартов, 1997.

1. COBIT (Control Objectives for Information and Related Technology) - Контроль целей для информационных и связанными с ними технологиями.
2. MSF (Microsoft Solutions Framework) - Методика управления проектами разработки информационных систем Microsoft.