Microsoft Solutions Framework Официальное издание Белая книга

Вид материала

Содержание

Управление рисками на предприятии
Создание культуры управления рисками
Управление портфелем проектов

Подобный материал:

Microsoft Solutions Framework Белая книга, 344.57kb.
Microsoft Solutions Framework Белая книга, 618.02kb.
Microsoft Solutions Framework Белая книга, 596.75kb.
Н. И. Лобачевского Факультет Вычислительной математики и кибернетики Кафедра Математического, 169.45kb.
Н. И. Лобачевского Факультет Вычислительной математики и кибернетики Кафедра Математического, 172.6kb.
Сравнительная характеристика систем управления предприятием Microsoft® Business Solutions-Navision®, 332.01kb.
Microsoft Business Solutions ApS являются частью корпорации Microsoft. Названия действующих, 309.28kb.
Учебная программа курса Введение в обязанности и условия работы специалиста по технической, 16.36kb.
Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический, 177.56kb.
Белая книга жизни книга 3 о здоровье и об устранении, 14327.18kb.

1 ... 11 12 13 14 15 16 17 18 19

Управление рисками на предприятии

Для получения максимальной отдачи от затрат на управление рисками важно иметь единое видение процесса управления рисками в масштабе всего предприятия.

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

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

Двумя основными причинами этого являются:

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

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

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

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

Управление портфелем проектов

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

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

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

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

Вот те методики, применение которых возможноНиже приводятся рекомендации впо управленииуправлению рисками портфеля проектов:

ОбеспечьтеЗаручитесь поддержкуподдержкой исполнительного руководства компании. процесса анализа портфеля исполнительными действиями. Поддерживайте их рРегулярной отчетностьюпредоставляйте “наверх” отчеты о новых данных и извлеченных уроках, полученных в процессе анализа рисков портфеля проектовданных и извлеченных уроках.
Планируйте собрания заблаговременно. В идеале, планируйте их регулярно в такие дни, когда смогут присутствовать многиебольшинство руководителируководителей проектов смогут присутствовать. Заблаговременно приглашайте аналитическую группу – хорошие аналитики имеют много других обязанностей.
Тщательно выбирайте проекты, представляемые на анализ. Вы можете исходить из ежемесячного графика анализа больших проектов, но нужно также обеспечьтеобеспечить регулярный анализ широкого спектра проектов средней величины.
Устанавливайте фиксированный круг вопросов, рассматриваемый по каждому из проектов., Ттаким образом чтобы руководители проектов будут знализнать, чегочто ожидать от проводимых собраний. Например, 20 минут выделяется на доклад о текущих оценках рисков, затем 20 минут идет обсуждение стратегий по предотвращению и смягчению последствий, а затем делается 5-ти минутный обзор извлеченных уроков для обмена опытом с другими проектными группами.
Используйте стандартизированную документацию для отчетности об оценке рисков и их состоянии.
Убедитесь, что все документы розданы всем участникам собрания заблаговременно. Это позволит сократить трату времени.
ПригласитеСтимулируйте напосещение аналитических собраниесовещаний руководителейями проектныхвнутрипроектных групп – либо в личной беседе, либо по телефону (т.н. “селекторное” совещание).
Убедитесь, что проводимые встречи приносят проектным группам пользу. Часто это может быть достигнуто анализом прогресса в тех вопросах, которые, в узком понимании, не являются рисками, но где опыт аналитической группы способен помочь проектной группе.
Избегайте персональных порицаний за сложившуюся в проектуе ситуацию.
Позволяйте всякомукаждому члену проектной команды сделать прошениезаявку о рассмотрении их проекта.

Заключение

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

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

Данный обзор носит чисто информативный характер. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, НИ ЯВНО ВЫРАЖЕННЫХ, НИ ПОДРАЗУМЕВАЕМЫХ В СВЯЗИ С ДАННЫМ ДОКУМЕНТОМ.

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

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

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

It is important to capture as much information as is possible about problems when they incur or about a contingency plan when it is invoked to determine the efficacy of such a plan or strategy on risk control.

Microsoft является охраняемым товарным знаком корпорации Майкрософт в США и других странах.

Названия компаний или продуктов, указанные здесь, могут быть товарными знаками соответствующих владельцев.Часть номер: 602-i401a

Перевод данного документа на русский язык был осуществлен в 2003 г. корпорацией eLine Software (ссылка скрыта). Другие документы по MSF на русском языке доступны в Internet по адресу: ссылка скрыта .

1 MSF Process Model v. 3.0, 2002 (доступно наavailable at soft.com/msf/)

2 Audrey J. Dorofee, Julie A. Walker, Christopher J Alberts et al, Continuous Risk Management Guidebook (Carnegie-Mellon University, 1996).

3 Ronald P. Higuera, “Team Risk Management: A New Model for Customer-Supplier Relationships”, SEI Technical Report CMU/ SEI-94-SR-5, (Pittsburgh, PA: Software Engineering Institute—Carnegie Mellon University), 1994.

4 Encarta 2002, Статья “Insurance. II. Reasons for Insurance”.

5 Jim McCarthy, Dynamics of Software Development (Redmond, Washington: Microsoft Press, 1995), page 99.

6 Восемь принципов – это:

1. ожидайте изменений – проявляйте гибкость (expect things to change – stay agile);.
2. вырабатывайте общее видение (work toward a shared vision).;
3. концентрируйтесь на бизнес-ценностях (focus on delivering business value throughout the life cycle).;
4. инвестируйте в качество (invest in quality).;
5. извлекайте уроки из любого опыта – и положительного, и отрицательного (learn from all experiences – good and bad).;
6. поощряйте открытое общение (foster open communication).;
7. распределенная ответственность, фиксированная отчетность (clear accountability, shared responsibility).;
8. компетентная команда, наделенная полномочиями (empowered team).

7 MSF Team Model 3.0 Whitepaper (soft.com/msf/).

8 См. более детальное рассмотрение в MSF 3.0 Process Model Whitepaper, доступно наavailable at soft.com/msf/

9 Ronald P. Higuera and Yacov Y. Haimes, “Software Risk Management”, SEI Technical Report CMU/SEI-96-TR-012 ESC-96-012 (Pittsburgh, PA: Software Engineering Institute—Carnegie Mellon University, 1996).

10 К примеру, Steve McConnell, Software Project Survival Guide, (Redmond, WA: Microsoft Press), 1998.

11 Barry W. Boehm, Software Risk Management, (New York, NY: IEEE Press), 1989.

12 Capers Jones, Assessment and Control of Software Risks. (Englewood, NJ: Prentice-Hall, 1994). ISBN 0-13-741406-4

13 Ronald P. Higuera and Yacov Y. Haimes, “Software Risk Management”, SEI Technical Report, 1996.

14 Steve McConnell, Rapid Development, (Redmond, Microsoft Press), 1996, pp 87-91.

15 Thomas R. Peltier, Information Security Risk Analysis, (Boca Raton: Auerbach Publications, 2001).

16 Donald L Pipkin, Information Security: Protecting the Global Enterprise, (Newark, NJ: Prentice Hall, 2000).

17 cmu.edu/

18 Одна из эффективных методик мозгового штурма для обнаружения первопричины называется “Пять почему”. Согласно этому подходу, команда должна поставить вопрос “Почему это так?” по отношению к условию риска, дать ответ и циклически повторить “Почему это так? - Потому что ...” до пяти раз.

19 Это может быть достигнуто вариацией методики “5 почему”, при которой команда циклически повторяет вопрос-ответ “Что тогда?..Тогда будет...” до пяти раз.

20 Audrey J Dorofee, Julie A Walker, Christopher J Alberts, et al., Continuous Risk Management Guidebook. (Pittsburgh, PA: Carnegie Mellon University, 1996).

21 Linda H Rosenberg , Theodore Hammer , Albert Gallo, Continuous Risk Management at NASA, 1999 (.nasa.gov/support/ASM_FEB99/crm_at_nasa.phpl)

22 MSF Risk Management Process Whitepaper, 2001.

23 Principles of Application Development- Course 593 and Course 1517.

24 Rosenberg LH, et al., 1999.

25 Elaine Hall, Managing Risk. Methods for Software Systems Development, SEI Series in Software Engineering, (Reading, MA: Addison-Wesley, 1998), Ch. 4, “Identify Risk”.

26 Dorfee AJ, et al, 1996.

27 Elaine Hall, Managing Risk, p. 101.

28 Project Management Institute, A Guide to the Project Management Body of Knowledge 2000 Edition, (Newtown Square, PA: Project Management Institute, Inc. 2000), Chapter 11.

29 Elaine Hall, Managing Risk.