Системы управления ресурсами предприятия

−выявление – определение рисков в проекте;

−оценка – оценивание вероятности появления рисковых событий и их воздействия на проект;

−развитие реакции – разработка планов реагирования на риски;

−контроль за рисками – реализация и обновление рисковых планов. Для выявления рисков сначала необходимо выбрать объекты, кото-

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

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

40

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

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

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

41

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

1.4.2.Основные факторы, влияющие на риски крупного проекта

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

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

42

важно знать степень влияния таких субъективных факторов на достижение целей проекта.

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

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

−организация проекта;

−конфигурация проектируемой системы;

−ресурсы проекта;

−структура процессов проекта.

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

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

Конфигурация проектируемой системы существенно влияет на состав работ и участников проекта, структуру рисков и практически всегда под-

43

вергается изменениям. Это обусловлено уникальностью проекта и создаваемой ИС.

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

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

1.4.3.Особенности анализа проектных рисков

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

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

•риски изменяются в зависимости от того, произошло или не произошло рисковое событие на предыдущей стадии проекта.

44

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

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

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

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

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

45

том, выявить наследование и передачу рисков оказывается затруднительно.

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

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

46

Контрольные вопросы.

1 Перечислите ключевые риски при планировании проекта 2 Опишите модель управления изменениями, а также укажите воз-

можные риски для крупного проекта 3 Основные факторы, влияющие на риски крупного проекта

4 Особенности анализа проектных рисков

1.5. Организация управления по критериям качества

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

стандарты документации:

какие документы;

формат и содержание; стандарты программного кода:

классы (методы) соглашения об обозначении переменных;

стандарты комментариев (например, javadoc);

соглашения о тестировании

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

Процессы обеспечения качества проектов В наиболее общем случае организация управления проектами по

критериям качества связана со следующими процессами:

•процессы построения иерархии целей как самого проекта, так и проектируемой системы;

47

•процессы взаимосвязи и координации работ; процессы разработки проекта;

•процессы управления финансовыми, материальными и временными ресурсами;

•процессы управления информационным и коммуникационным обменом между участниками проекта; процессы управления кадрами;

•процессы управления рисками.

Пример процессов проекта приведен в табл. 2.

Таблица 2

Менеджмент взаимодей-Управление взаимодействием в течение проекта. ствия

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

онных систем

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

48

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

1.5.2.Процессная модель управления качеством

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

Таким образом управление качеством проектных работ достигается через управление процессами проекта по двум направлениям:

а) через структуру и работу самого процесса, внутри которого имеются потоки продукции или информации;

б) через структуру продукции или информации, протекающих внутри процесса.

49