Рискованный проект – Риски проекта — примеры и анализ возможных событий

Содержание

Риски в управлении проектами — e-xecutive.ru

Определение понятия

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

Негативные риски

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

Позитивные риски

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

Непредвиденные обстоятельства

Непредвиденные обстоятельства – это события, которые невозможно было или не смогли предусмотреть на стадии идентификации рисков.

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

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

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

Планирование реагирования на риски

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

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

Ссылки

  1. Юрий Ким. «Современные методы и стратегии реагирования на риски проекта»
  2. Виктор Степанов. «Практические инструменты управления рисками проекта»


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

www.e-xecutive.ru

пример, оценка рисков, анализ возможных событий

В данной статье будет рассказано о рисках проекта, примеры будут приведены, что называется — «из жизни». Для управления процессом выполнения работы всегда ставятся одни и те же цели: экономить время и вложенные деньги. Чтобы минимизировать риски проекта, примеры которых весьма многочисленны, создается управление рисками, вооруженное особой методологией. И это помимо того что спонсор проекта будет видеть эффективность такой работы. Любое опасное событие имеет вероятность состояться, однако не факт, что его влияние на ведение работы будет обязательно отрицательным. Время от времени отмечают и положительные риски проекта. Пример: внезапно у проекта появляется настоящий эксперт, который в пух и прах разнесет всю проделанную работу, но в итоге значительно ускорит появление результатов и прибавит им качества.

Как предусмотреть вероятность?

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

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

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

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

Оценка рисков проекта

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

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

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

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

Конкретика и неопределенность

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

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

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

Влияние риска на проект

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

Риск, согласно данной трактовке, — это возможность опасности, событие, которое либо произойдет, либо нет. Если произойдет, то будут и варианты последствий: результат положительный (например, прибыль или любая другая выгода), результат отрицательный (потери, ущерб, убытки и тому подобное), результат нулевой (когда проект оказался без убытка или без прибыли).

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

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

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

Структура разбиения рисков

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

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

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

Элементы плана управления проектом

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

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

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

Матрица рисков

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

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

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

Первый способ классификации рисков

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

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

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

Второй способ классификации рисков

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

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

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

Всегда есть технические и технологические риски на производстве — отказ оборудования, аварии, брак и тому подобное. Если команда проекта действует так, как это делали Щука, Рак и Лебедь в басне Крылова, то есть если изначально подбор участников был сделан неправильно; если в команде не определены цели, не сосредоточены на главном интересы и поведение участников проекта вредит общему делу — есть риск, что поставленных целей добиться не удастся.

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

Третий способ классификации

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

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

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

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

Выводы

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

Предполагать пожар в офисе компании или планировать внезапный отказ от субсидирования спонсора было бы странным, хотя по влиянию на бизнес последствия такого риска выглядят страшно. Вероятность низка, риск на «желтом» уровне. А вот если программное оборудование не поступит вовремя, проект пострадает очень сильно. Случается это гораздо чаще. Уровень риска явно «красный». Но главное то, что этого риска при нормальной работе участников проекта вполне можно избежать. Вероятность риска — просчитывание возможности его реализации от 0 до 100%.

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

fb.ru

Добавление риска в проект — Project Online

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

Добавление рисков в проект

Если риск не относится к чьей-либо конкретной задаче, просто добавьте его на сайт проекта.

  1. На панели быстрого запуска выберите пункт Проекты.

  2. Выберите имя проекта в списке.

  3. На панели быстрого запуска выберите пункт Сайт проекта.

  4. На панели быстрого запуска выберите пункт Риски.

  5. Выберите команду Создать элемент.

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

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

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

    План снижения риска нужен, чтобы избежать возникновения риска.

    План на непредвиденный случай — это действия, запланированные на случай возникновения риска.

    Описание фактора и Фактор — это пункты, указывающие на факторы, которые свидетельствуют о возникновении риска. При их появлении следует воплощать план на непредвиденные случаи.

  7. Закончив, в группе Правка нажмите кнопку Сохранить.

Назначение рисков конкретным задачам

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

  1. Щелкните имя риска в списке, чтобы просмотреть его.

  2. В правой нижней части страницы щелкните Добавить связанный элемент.

  3. В левой части диалогового окна под именем проекта щелкните Задачи.

  4. В правой части диалогового окна щелкните строку для конкретной задачи, которой нужно назначить риск.

  5. Щелкните Вставить, чтобы назначить риск этой задаче.

Дополнительные сведения

Если вы не получили ответ на свой вопрос, попробуйте поискать его на сайте support.office.com или просмотрите список разделов в Центре справки Project.

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

support.office.com

что поменялось за последние годы / Техносерв corporate blog / Habr

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

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

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

Что поменялось за последние 10 лет в ИТ-проектах?


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

Раньше CIO занимались автоматизацией бизнес-процессов компании и обеспечением стабильной работы своего зоопарка систем. Сейчас этап автоматизации классических бизнес-функций подходит к концу: ERP, CRM, BI и прочие инструменты управления бизнесом уже оцифрованы. Просто наличие автоматизации — это уже не конкурентное преимущество. Важнее Time-to-value, Time-to-market, ROE, непрерывность и кибербезопасность. Скорость вывода продукта на рынок, обеспечение бесперебойного доступа к сервисам и их защищённость — основной фокус сейчас там.

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

Теперь невозможно успешно реализовать проект, не понимая отраслевой специфики и нюансов в бизнес-процессах заказчика, то есть усложнилась и работа интеграторов. На передний план выходит сервисная модель работы. Крупная продажа всё больше оформляется почти как контракт о сотрудничестве, но ещё без revenue sharing, хотя и такие примеры есть в моей практике. Проекты всё чаще начинают перерастать модель «начало и конец» и превращаются в непрерывный процесс развития ранее реализованных проектов. Интегратор начинает восприниматься как партнёр, готовый разделить ответственность не только за успешную реализацию проекта, но и за тот бизнес-результат, ради которого он стартовал.

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

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

Это связано в основном с отсутствием накопленного опыта и разработанных стандартов, гарантированных механизмов защиты процессов и данных в киберпространстве.
С точки зрения CIO, продолжается интеграция ИТ и основного бизнеса компании, соответственно, и рост влияния ИТ-службы на систему управления рисками компании.
Что это значит с точки зрения изменения работы CIO и его подчинённых? С точки зрения руководителей команд?

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

…Сроки реализации проектов уменьшаются, а темп растёт


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

Настоящим вызовом для проектной команды становится управление требованиями и ожиданиями заказчика. В чём здесь основная сложность? Проекты всё чаще стартуют с минимальным набором требований, которые непрерывно уточняются и дополняются в процессе всей реализации проекта. Зачастую бывает так, что к концу проекта набор требований абсолютно «перпендикулярен» тому, что было на старте. Я не раз наблюдал, как заказчик только к середине проекта, а иногда и к его концу, наконец (!) осознавал, а что он хочет на самом деле.

Здесь обычно помогает итерационный подход — деление на мелкие спринты и глубокая вовлечённость заказчика в процесс реализации. И чем больше такая неопределённость, тем более тесным должно быть взаимодействие. Чтобы создать необходимые условия для эффективной совместной работы, мы часто высаживаем ключевых людей из Техносерва на площадку заказчика. Это в разы улучшает коммуникации, сокращает время реакции, создаёт необходимые условия для интеграции проектных команд, а соответственно, снижает количество работы «в корзину».

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

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

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

Кадры как базовый риск


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

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

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

В такие моменты обычно спасают две важные вещи:

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

Консерватизм заказчика


Современные проекты ИТ-трансформации подразумевают не только оцифровку существующих бизнес-процессов компании, но и глобальный пересмотр функционирования всей организации – выход на принципиально новый уровень работы. Все меняется, как только рынок от массовых увлечений новыми технологиями переходит к попыткам реальных внедрений. Многие заказчики оказываются просто не готовы проводить глобальные изменения своей бизнес-модели. Как итог – все ограничивается поверхностной оптимизацией громоздких и неэффективных бизнес-процессов, сформировавшихся за долгие годы. Перевели процессы as-is в цифру и продолжаем работать также, как и работали раньше, не замечая очевидных возможностей повысить эффективность. Основные причины – инерция мышления и страх к переменам. И чем старше компания, тем ярче они проявляются. Реализация таких проектов превращается для команды в затяжную позиционную борьбу со стереотипами заказчика – «мы всегда так работали, и все было хорошо…», «мы сами знаем как лучше», «нет, что вы, это не забюрократизованность, это регулирование принципиальных аспектов работы, поэтому столько уровней согласования» и т. д.

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

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

Продуктовая самоидентификация рынка


Если вы посмотрите отчёты ведущих аналитических агентств, то увидите, что только 15% современных инновационных ИТ-проектов признаны успешными! Почему так происходит?
Всё чаще проекты на стороне заказчиков инициируются под действием маркетингового прессинга со стороны вендоров, а также в погоне за пресловутыми конкурентами, которые уже внедрили себе что-то такое новенькое и поспешили известить об этом рынок в бесчисленных пресс-релизах. На всех конференциях и форумах мы слышим: «BigData — must have», «blockchain — наше всё», «IOT — в каждый дом» и много чего ещё…

Не имея должной ИТ-зрелости и опыта внедрения подобных решений, заказчики часто стартуют проект либо с завышенными ожиданиями, либо без должного целеполагания. В итоге мы наблюдаем такую картину: внедрил заказчик BigData и использует её для получения простой аналитики, которую можно получить и более дешёвыми способами. Либо получает качественную многогранную аналитику, но совершенно не понимает, как её использовать в своей работе. Либо понимает, как использовать, но внутренние процессы и ИТ не позволяют этого сделать. Как результат — разочарование заказчика и в самом решении, и в исполнителе. Ну а кого у нас ещё винить?

Осознание приходит на рынок методом проб и ошибок, продукты проходят так называемую самоидентификацию: термины приобретают своё истинное значение, появляется больше пользовательского опыта и успешных внедрений. Чтобы понять, как это работает, достаточно взглянуть на хайп-циклы Гартнера и посмотреть, что сейчас находится на пике «рекламной шумихи». Вот один из них за 2017 год.

Возьмём, к примеру, BigData и посмотрим на график (отмечено красной точкой). Только сейчас, спустя почти десяток лет с момента появления первых продуктов и решений, относящихся исключительно и непосредственно к проблеме обработки больших данных, данная технология прошла своё «дно разочарований» и начинает выходить «на плато продуктивности». С другими технологиями примерно всё то же самое.

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

Регуляторика


Обычно под этим термином понимают правовые аспекты взаимодействия с регуляторными органами. Нормативно-правовая база — это отдельная головная боль на пути современных «цифровых» проектов, особенно для госсектора. Дело в том, что многие СНИПы, ГОСТы, регламенты и постановления, по которым сейчас работают контролирующие органы, писались ещё «при царе горохе», когда и технологий-то таких не было. Большое количество из них на текущий момент просто неприменимы. Это действительно серьёзная проблема, которую осознаёт и само государство. И это учтено в программе «Цифровая экономика», которая утверждена правительством РФ в прошлом году. Был в моей практике случай, когда виртуализация не ложилась в требования по безопасности для крупного госбанка: стандарты, по которым велось проектирование, много лет назад были написаны «под железо». Тогда заказчику пришлось обращаться к регуляторам, одним из которых был ФСТЭК, для доработки нормативной базы и требований по защите виртуальных сред. Как вы понимаете, было это совсем не быстро! Сейчас аналогичные проблемы испытывают и другие технологии.

Какими бы эти стандарты ни были — инженерными, платёжными и прочими, — вам придётся разобраться в этом самому, привлекая нужных специалистов вроде юриста. Почему самому, потому что самый главный навык ПМа — это понять, как можно реализовать проект. Чаще всего ваши консультанты найдут миллион причин «почему так нельзя», а не одну возможность «как можно».

Яркий пример — прохождение сертификации PCI DSS.
Или ещё пример — определение, что же такое персональные данные для вас.

Классическое проектное бюджетирование


Давайте вспомним, как происходит бюджетирование у большинства заказчиков (госов вспоминаем отдельно и в ярких красках). Бюджет формируется в начале года, защищается на УК (или в других инстанциях) и часто даже не пересматривается. Когда мы перейдём к реализации, возникнет основная дилемма — какую схему оплаты выбрать. Схема работы «fix scope — fix price», её ещё называют «Fixed Fee», не очень устраивает исполнителя, т. к. требования нечёткие, вариативность большая, а бюджет фиксирован. Возникают огромные риски промахнуться с бюджетом.

Схема «Time & Material» часто даже неприемлема для заказчика. С одной стороны, невозможно говорить о финансовом планировании, если ты не знаешь стоимость реализации (процедурные ограничения внутри), а с другой — у заказчика часто не хватает опыта для «отруливания» такой схемы. А если нет опыта, да ещё и доверия к исполнителю, убедить заказчика в её применении практически невозможно. Для госсектора эта схема вообще беда: перерасход — плохо, недоосвоение — плохо вдвойне. Помню забавный проект для одной из гос.служб по развитию и модернизации их основной информационной системы. Решил заказчик законтрактоваться по схеме «Т&М». Это был его первый опыт. Заложил деньги в бюджет на целый год, сформировал основные направления развития. Дальше контрактом предполагалось, что отдельные заказы будут поступать исполнителю в виде частных ТЗ, предварительно оцениваться и оплачиваться по модели «Т&М». Первым делом заказчик пофиксил накопившиеся баги — на это ушло не особо много времени и, соответственно, бюджета. А дальше… идеи закончились! Сотрудники на местах просто не знали, куда им дальше развивать свою же систему. Команда проекта смогла помочь только частично, т. к. задача была относительно новой, а команда недостаточно укомплектована отраслевыми экспертами и аналитиками. Понимая, что время идёт, а деньги «сгорают», заказчик начал генерить задачи из разряда «не особо нужно, но вдруг пригодится». Динамика резко возросла, освоение тоже. А вот когда у заказчика к концу проекта появились действительно светлые идеи, бюджет проекта уже закончился! Больше заказчик такую схему не применял!

Будущее уже не то, что прежде


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

Есть и множество других рисков, которые могут неожиданно поставить крест на вашем проекте. Раньше они были для нас не так актуальны. В последнее время эти риски часто генерит геополитическая обстановка в мире. Это и валютные риски (когда курс доллара резко вырос и железо стало «золотым»), и введение санкций, когда вдруг в середине проекта вендор вам сообщил, что не может привезти нужное оборудование, и теперь ты вынужден покупать то, что есть в наличии у поставщика, по цене в 2 раза дороже…

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

habr.com

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

Библиографическое описание:

Кошелевский И. С. Обзор методов управления проектными рисками [Текст] // Проблемы современной экономики: материалы II Междунар. науч. конф. (г. Челябинск, октябрь 2012 г.). — Челябинск: Два комсомольца, 2012. — С. 164-166. — URL https://moluch.ru/conf/econ/archive/56/2746/ (дата обращения: 19.11.2019).

На протяжении последних нескольких лет в России взят курс на преобразование экономики. По мнению премьер-министра Д.А. Медведева: «Россия должна стать страной, благополучие которой обеспечивается не столько сырьевыми, сколько интеллектуальными ресурсами: «умной» экономикой, создающей уникальные знания, экспортом новейших технологий и продуктов инновационной деятельности» [1]. Хозяйственная деятельность прошедших десятилетий показала, что проектно- ориентированные организации становятся более конкурентоспособными по отношению к вертикально интегрированным, с их функциональной организацией деятельности [2]. Поэтому текущий период развития реального сектора российской экономики характеризуется ростом инвестиционной активности проектно-ориентированных промышленных предприятий. В связи с этим возрастает актуальность исследований по разработке методик управления проектами в условиях действующего промышленного предприятия.

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

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

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

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

В мировой практике оценку рисков рекомендуется проводить поэтапно.

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

На данном этапе полезно применять следующие методы:

  • метод мозгового штурма;

  • метод Дельфи;

  • метод аналогий;

  • метод «Синектика».

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

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

  • метод статистической идентификации;

  • методы аналитической идентификации;

  • экспертные методы идентификации риска;

  • метод анализа чувствительности.

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

  • анализ уместности затрат;

  • метод аналогий;

  • метод экспертных оценок.

Данные результаты используются впоследствии в ходе количественного анализа рисков. Основная задача количественного подхода заключается в численном измерении влияния факторов риска на поведение критериев эффективности инвестиционного проекта.

Основой анализа уместности затрат выступает предположение о том, что перерасход средств может быть вызван одним или несколькими из следующих факторов:

  • изначальная недооценка стоимости проекта в целом или его отдельных фаз и составляющих;

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

  • отличие производительности машин и механизмов от предусмотренной проектом;

  • оценка увеличения стоимости проекта, в сравнении с первоначальной, вследствие инфляции или изменения цен на выполняемые работы по проекту[4].

Среди количественных методов оценки можно выделить следующие:
  • статистический метод;

  • анализ целесообразности затрат;

  • метод экспертных оценок;

  • аналитические методы;

  • метод аналогий;

  • анализ финансовой устойчивости предприятия и оценка его платежеспособности.

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

  • уклонение от риска;

  • передача риска;

  • принятие риска;

  • снижение риска;

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

  • пересмотр рисков;

  • аудит рисков;

  • анализ отклонений и трендов.

  • анализ резервов.

  • совещания по текущему состоянию.

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

Литература:
  1. Медведев Д.А. «Россия, вперед» от 10 сентября 2009 года. http://www.kremlin.ru/news/5413

  2. Мазурина Е.В. Оценка стоимости ресурсов углеводородов в условиях высокой степени неопределенности, филиал ООО «Газпром ВНИИГАЗ», Ухта, Россия.

  3. Архипенков С. Лекции по управлению программными проектами.

Москва 2009 г.

  1. Краснов Александр Михайлович. Управление рисками инвестиционных проектов промышленных предприятий: дис. … канд. экон. наук : 08.00.05 Москва, 2006 178 с. РГБ ОД, 61:07-8/147

  2. «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е изд., PMI, 2004.

moluch.ru

Отправить ответ

avatar
  Подписаться  
Уведомление о