Эту статью мы написали вместе с Анастасией Борисюк, руководителем проектной группы в Актион Технологии. Вот ее телеграм-канал.
Мэри работает проджект-менеджером. Она управляет разработкой мобильного приложения с элементом блокчейна. Все шло хорошо, но за месяц до релиза главный разработчик заболел, а кроме него в технологии блокчейна никто не разбирается.
Мэри не знает, что делать. Нужно искать другого разработчика, сдвигать дедлайны, увеличивать бюджет. Заказчики недовольны, конкуренты вот-вот выпустят похожий продукт.
На месте Мэри может оказаться любой проджект. Чтобы этого не произошло, нужно не забывать работать с рисками проекта.
Сложность: средняя
Время на чтение: 9 минут
Что будет в статье:
-
Какие бывают источники рисков
-
Шаблон реестра рисков
-
Как выбрать стратегию управления рисками
Изучите профессию проджект-менеджера
За 3 месяца интенсивного обучения в симуляторе skillsetter вы получите ключевые навыки для карьерного роста
Начать учиться бесплатно
Что такое риски
Прежде чем понять, как работать с рисками, давайте проговорим, что это такое и какие они бывают.
Риски — это негативные события, которые могут произойти и повлиять на проект. Например, государство выпустит новый закон или разработчик временно не сможет работать над проектом.
Если негативное событие произойдет в любом случае — это не риск, а задача. Например, проджект знает, что новому QA-инженеру нужно в два раза больше времени на тестирование продукта. Его задача — учесть факт и заложить достаточно времени на этот этап.
Риски можно делить на внешние и внутренние.

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

Например, типовой риск на стадии дизайна — заказчики не утвердили макет. После разработки может оказаться, что они по-другому их представляли. Тогда придется потратить время на внесение изменений, а для этого нужны дополнительные ресурсы.
Чем раньше проджект выявит и проработает риск, тем дешевле и проще будет его компенсация или предотвращение. Если детально изучить требования и обсудить непонятные моменты, то на этапе тестирования будет меньше проблем.
В статье вы встретитесь с терминами, которые могут быть вам незнакомы. Их использует в своей работе Анастасия Борисюк в Актион Технологии. Давайте введем определения, чтобы говорить на одном языке.
ДОДинг, от Defenition of Done — это встреча между заказчиком, проджектом и тимлидом. Цель встречи — договориться, что будет сделано в фиче, для кого она, какую проблему решает. Это нужно, чтобы можно было грубо оценить, приоритизировать и запланировать работу.
Предоценка — это грубая оценка работы тимлидом. Она проводится после ДОДинга и используется для планирования и выставления сроков работы проектной команды. Для этого тимлид берет время на то, чтобы еще раз все прочитать и продумать технические аспекты реализации.
В следующем блоке вы погрузитесь в будни джуниор проджект-менеджера. Представьте, что вы работаете в компании по разработке мобильных приложений.
Как работать с рисками
Рабочая неделя начинается с проверки Google-календаря. На сегодня у вас стоит созвон с Оливией — опытным проджектом, которая давно работает в компании и будет вашим ментором.
Вы заходите в Google Meet
Привет! Как настрой на неделю?
Да, понимаю. Мне тоже было страшно выполнять новые задачи. Но я уверена, что ты быстро освоишься.
Здорово, спасибо за поддержку. Как будем работать?
Первое время я буду отдавать тебе часть своих задач — объяснять, как это делается, и проверять, все ли правильно. Так ты поймешь, как все устроено, и сможешь брать на себя больше ответственности за проект.
Я сейчас работаю над приложением SportLife — это сервис для внедрения привычки заниматься спортом каждый день. Нужно проработать все возможные риски, поможешь мне в этом?
Ты уже знаешь, что такое риски и какие они бывают?
Да, знаю. Но мне еще не приходилось с ними работать. Это делается на протяжении всего проекта?
Конечно. Риски нельзя описать и забыть, ведь проект живет. С течением времени могут появиться новые риски, а старые — измениться.
Обычно проджект начинает работу с рисками на этапе планирования и продолжает вплоть до релиза.
В начале работы он выявляет риски на ДОДинге, когда обсуждается фича, объем работ и сроки, а также на предоценке и встрече с заказчиком. Периодически он возвращается к рискам, чтобы проверить, ничего ли не изменилось.
А команда участвует в обсуждении рисков?
Да. На планировании можно рассказать команде о выявленных рисках и провести брейншторм. Он поможет найти новые риски или придумать способы минимизировать старые.
На дейли стендапах нужно спрашивать разработчиков, что может помешать достичь целей спринта, а на ретро — анализировать причины неудач, потому что они могут возникнуть снова.
Ну как, пока все понятно?
Отлично, тогда перейдем к делу. Я отправлю тебе на почту документ, в котором описан весь процесс работы с рисками проекта.
Разберись подробнее в теме и распиши риски для одного этапа. Я проверю, все ли ок, и ты пойдешь работать дальше.
Какой именно этап разобрать?
Давай возьмем этап оценки.
Хорошо, вернусь к тебе, как доделаю задачу.
Удачи! Если будут вопросы, спрашивай 😎
Вы открываете почту, переходите по ссылке и погружаетесь в чтение.
Как анализировать риски
Работа с рисками начинается с их анализа. Он включает три этапа: выявление проблем, определение причин возникновения этих проблем и систематизация причин.

Рассмотрим подробнее каждый этап.
Гайд по лучшим статьям skillsetter
В нашем блоге уже больше 150 статей про рост продуктов и карьеру в IT. Для удобной навигации мы объединили их в тематические подборки.
Выбрать подборку
Как выявлять проблемы
Анализ рисков начинается с выявления проблем. Для этого можно использовать три способа: вспомнить старые проблемы, обсудить проект с командой, опросить экспертов, продактов и представителей бизнеса.
Вспомнить старые проблемы. Выпишите все проблемы, с которыми вы уже встречались в предыдущих проектах. Например, команда регулярно не вписывается в сроки или сдает не то, что нужно заказчику.
Обсудить проект с командой. Опытные разработчики подскажут, что может произойти в зависимости от целей проекта, используемых технологий, объема ресурсов. Например, если проект подразумевает внедрение незнакомой технологии, нужно учесть время на изучение и заложить риски в оценку на внедрение.
Опросить экспертов, продактов и представителей бизнеса. Они могут обнаружить проблемы, связанные с рынком, конкурентами, целевой аудиторией, законодательством. Например, при разработке банковского сервиса будет полезно проконсультироваться с юристом в сфере финансовых вопросов, чтобы не нарушить действующие или будущие законы.
Вы решаете начать работу над заданием от Оливии в процессе изучения документа. Так как проект на начальной стадии и команда еще с ним не знакома, вы отталкиваетесь от старых проблем.
Вы вспоминаете, с чем уже сталкивались: иногда тимлид дает предоценку без декомпозиции или с высокоуровневой декомпозицией. Это приводит к тому, что команда не укладывается в сроки.
Как определять причины проблем
Чтобы предотвратить проблемы, нужно определить их триггеры — причины возникновения. Для этого можно воспользоваться методом “5 почему”.
Метод “5 почему” заключается в том, чтобы постепенно отвечать на вопрос “Почему это произошло?” Вопросов не обязательно должно быть пять — их может быть как больше, так и меньше. Главная задача — добраться до корневой причины.
Например, проблема в том, что команда не попала в оценку:

Так за три вопроса мы добрались до истинной причины. Если лучше изучать технологии, которые используются в проекте, оценка сроков может стать более реалистичной и команда будет чаще укладываться в дедлайны.
Этот пример натолкнул вас на еще один возможный триггер неправильной оценки в SportLife — команда плохо разбирается в технологии и может неправильно оценить, сколько ресурсов потребуется. Вы обратились к продакту и узнали, что приложение должно синхронизироваться с фитнес-браслетами и пульсометрами. Команда никогда не разрабатывала аналогичный проект, и этот риск может стать проблемой.
В статье об ошибках в управлении разработкой вы найдете десять примеров, как стоит управлять разработкой, а как — нет. Также мы даем шаблон для распределения времени команды в спринте.
Как систематизировать причины
Причины, полученные с помощью метода “5 почему”, следует включить в реестр рисков — документ, в котором собраны все риски. Чем масштабнее, длительнее и сложнее становятся проекты, тем труднее контролировать ситуацию. Без централизованного мониторинга рисков вы можете что-то забыть или упустить.
Для удобства можно группировать риски по этапам работы над проектом — например, дизайн, снятие требований, оценка, планирование, разработка, тестирование и приемка. На каждом этапе могут возникать разные риски. Находясь на этапе дизайна и зная типовые риски этого этапа, проджекту легче их обнаружить и начать работать с ними.

Задание
Как вы думаете, какие риски относятся к этапу “Разработка”?
Реестр рисков можно вести в Google-таблицах. Нужно зафиксировать риск, его триггер и оценку. Затем прописать действия, которые можно предпринять, чтобы снизить вероятность появления риска. Также нужно продумать план на случай, если риск станет проблемой.

Вы вносите в реестр риски и их триггеры.

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

Риски принято делить на три группы: высокий, средний и низкий:
- К низкой группе относятся риски с низкой вероятностью и степенью влияния.
- К высокой — с высокой вероятностью и степенью влияния.
- Если у риска высокая вероятность, но низкое влияние, или наоборот, то он относится к средней группе.
Высокие риски нужно прорабатывать в первую очередь, так как они представляют наибольшую опасность для проекта.
С рисками из средней группы можно работать двумя способами:
1. Снизить их влияние и переместить в низкие
2. Переместить в высокие и составить план их отработки
Рисками из низкой группы можно пренебречь и мониторить их состояние. Их вероятность и влияние на проект не такие существенные.
Оценка рисков обычно субъективна, на нее влияет контекст проекта. Одни и те же риски в двух проектах с разной вероятностью становятся реальной проблемой и по-разному влияют на результат.
Например, для одной команды увеличение бюджета на $10 000 повлечет полную перестройку плана, а для другой эта сумма — стоимость всего одного дня работы команды.
У вас пока нет опыта в оценке рисков, но вы понимаете, что неизвестная технология с большей вероятностью может стать проблемой и сильно повлияет на результаты работы. Предоценка без декомпозиции или с высокоуровневой декомпозицией скорее всего не так критичны. Вы расставляете в реестре рисков вероятности и степень влияния.

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

Далее рассмотрим каждую стратегию подробнее — что она значит, как ее применять и в каких случаях рекомендуется использовать.
Стратегия «Принять риск»
Суть стратегии. При использовании данной стратегии проджект-менеджер принимает то, что риск станет проблемой, и сразу планирует ее решение.
Когда используется. Эта стратегия подходит для рисков, когда вероятность негативного события низкая или последствия на проект незначительные. Например, переход на удаленную работу, небольшие доработки в проект, новые баги.
Пример. Когда в команде разработчиков появляется джун, скорость работы над проектом уменьшается. То, что обычно команда делала за один спринт, может растянуться на полтора. В таком случае проджект закладывает дополнительный запас времени в проект.
Задание
Как вы думаете, какой риск можно принять?
Стратегия «Уклониться от риска»
Суть стратегии. При использовании стратегии уклонения проджект предпринимает действия, чтобы событие не произошло. Для этого он старается ограничить влияние внешних факторов и взять под контроль внутренние.
Когда используется. Эта стратегия подходит для рисков, причина которых предсказуема и ее можно устранить. Например, болезни сотрудников, долгие согласования с другими отделами, изменение требований к продукту.
Пример. Есть риск, что приемка фичи у заказчика затянется. Значит, следует поставить четкий срок по приемке. В этом случае цель фича будет выполнена вовремя, так как проджект ограничил влияние внешних факторов.
Стратегия «Снизить влияние»
Суть стратегии. При использовании данной стратегии проджект-менеджер планирует такие мероприятия, чтобы степень влияния и вероятность снизились.
Когда используется. Эта стратегия подходит для рисков, у которых высокая вероятность того, что события произойдут, и высокое влияние на проект. Например, недостаток экспертизы или изменения в рабочих процессах.
Пример. Нужно перенести систему для бухгалтерского учета на другую платформу. При этом есть риск, что у команды недостаточно экспертизы в технологии, по которой работает эта система — только один разработчик имеет релевантный опыт. С высокой вероятностью этот риск станет проблемой и повлияет на сроки проекта.
Проджект не может полностью избавиться от этого риска, но может снизить его влияние. Для этого можно привлечь команду к разработке плана реализации. Так разработчики заочно погрузятся в проект. Также можно заложить время на погружение в технологию и мониторить риск еженедельно. С увеличением знаний у команды можно корректировать оценки.
О том, как ставить цели, чтобы их достигать, вы узнаете в нашем гайде по OKR. В нем мы разобрали каждый этап планирования.
Стратегия «Передать другому»
Суть стратегии. Эта стратегия подразумевает передачу задачи и связанные с ней риски заказчику или другим исполнителям.
Когда используется. Стратегия используется в тех случаях, когда нет ресурсов и знаний для решения проблемы, которая может возникнуть. Например, команда может не разбираться в искусственном интеллекте или технологии распределенных вычислений.
Пример. Команде нужно подключить к продукту электронную цифровую подпись. У компании нет экспертизы и возможности заниматься этой задачей и бюрократическими вопросами. Проджект исключает этот пункт из контракта и договаривается, что заказчик отдает эту фичу другим подрядчикам и сам несет за нее ответственность.
Вы дочитали документ Оливии, теперь нужно определить стратегию действий для каждого риска. Но сначала вы делаете небольшой перерыв, чтобы переварить информацию.
Проработка рисков для SportLife
После чашки кофе вы приступаете к выбору стратегии управления выявленными рисками.
❌ Стратегия «Принять риск». Все ваши риски на этапе оценки достаточно значимы. Вы не можете просто принять их.
❌ Стратегия «Передать другому». Передать задачу другому тоже не получится — по договору все задачи по проекту лежат на вашей проектной команде.
✅ Стратегия «Уклониться от риска». От рисков, связанных с декомпозицией задач, можно уклониться. Они предсказуемые, и вы можете сделать так, чтобы риск не стал проблемой.
Риск предоценки без декомпозиции можно предотвратить, заранее попросив тимлида декомпозировать задачу на более мелкие шаги и проверив, как у него это получилось. Если же риск все-таки станет проблемой, нужно посмотреть, можно ли убрать что-то из скоупа и вынести в следующий спринт.
Чтобы предотвратить риск слишком крупной декомпозиции, нужно прописать, из каких этапов будут состоять решение и работы. На груминге фичи нужно сравнить предоценку и оценку. Если же риск станет проблемой, нужно занести в реестр рисков, какие работы не были учтены. Это поможет не допустить такого с другой фичей.
✅ Стратегия «Снизить влияние». Для управления риском неправильной оценки из-за неизвестной технологии можно использовать стратегию снижения влияния. Для этого нужно заранее провести рисерч, чтобы лучше разобраться, какие работы потребуется провести в проекте. На ретро нужно обсудить, вписывается ли команда в оценку. Если окажется, что команда выбивается из сроков, нужно заложить дополнительное время на разработку и правки.
Вы вносите план действий в реестр рисков и спешите показать Оливии результат.
Вот реестр рисков. В нем три риска на этапе оценки, их триггеры, вероятность и степень влияния. На основе этой информации прописаны действия, даты отслеживания и план на случай, если риски все же станут проблемой.
Хорошо, ты молодец. Вообще рисков может быть намного больше, но для первого раза неплохо.
Отлично. Слушай, я сегодня столкнулась с проблемой. Интересно послушать твое мнение. Нам попался странный заказчик. Он не хочет выходить за рамки бюджета, но при этом уже сейчас говорит, что возможно пересмотрит набор фичей для запуска MVP. Как ты думаешь, какую стратегию лучше использовать?
Задание
Как вы думаете, какая стратегия управления рисками лучше подойдет в этом случае?
Единственно правильного варианта никогда не бывает, но это звучит логично. Давай еще раз закрепим порядок действий:
Ну что, я могу прорабатывать риски для SportLife дальше?
Да, заноси их в этот же реестр. Это поможет тебе держать все риски в одном месте и регулярно к ним возвращаться. Как заполнишь — скидывай мне.
Резюмируем
Предусмотреть все на свете не получится. Но чем основательнее проджект подходит к анализу рисков, тем меньше вероятность, что проект сорвется по срокам и принесет компании финансовые и репутационные потери.
Если вы столкнулись с проблемой, не волнуйтесь. В следующий раз вы учтете этот риск, чтобы не пришлось задействовать дополнительные ресурсы и переносить релизы.
Рекомендуем почитать
Чтобы грамотно управлять угрозами для бизнеса, мы решили использовать метод фреймворка PMBoK от PMI. Разработчики предлагают поделить процесс управления на 6 этапов:
- Планирование управления
- Идентификация факторов
- Качественная оценка
- Количественная оценка
- Планирование реакции
- Мониторинг и контроль
Такая методология предполагает активный подход в работе с источниками проектных угроз. Пассивное реагирование на последствия допустимо при появлении непредвиденных факторов. Но пассивная реакция на угрозы, которые можно предугадать недопустима — можем сильно увеличить смету, сорвать сроки или потрелять заказчика. В современных бизнес-реалиях пассивная реакция равноценна осознанному убийству проекта.
Такую схему из 6 этапов предлагает PMBoK.
Планирование управления
На этапе планирования выбираем стратегии организации процесса управления и правила взаимодействия участников и заинтересованных сторон. Мы сможем уточнить выбранные методы, инструменты и уровень организации управления.
Вот такую проектную схему предлагают разработчики PMBoK.
Диаграмма потоков данных планирования управления рисками в PMBoK.
3 главных аспекта правильного планирования:
- формирование благоприятной среды управления — гармонизация отношений внутри команды
- использование заранее заготовленных схем и шаблонов процессов управления
- создание описательной части и плана управления угрозами
Основной процессный инструмент — совещание. В нем принимают участники все члены команды, а иногда и инвесторы, когда речь идет про угрозы для инвестиционного проекта. Результат их работы — создание плана управления. Это полноценный регламент, которым команда руководствуется при противодействии угрозам.
Обычно в плане управления указывают:
- методы и инструменты управления
- роли участников при возникновении рисковых ситуация
- допустимые значения и диапазоны угроз
- принципы и правила внесения изменений в работу
- форматы отчетности и документации по проектным угрозам
- способы мониторинга и ответственные
Идентификация
На этом этапе выявляют и документируют проектные угрозы. Результат — перечень возможных проблем с ранжированием по степени опасности. Сначала команда выявляет рисковые факторы, затем проводит исследования и идентифицирует угрозы. Нужно понимать, что не все угрозы можно идентифицировать на старте. Обычно по мере развития проекта количество возможных рисковых событий увеличивается.
Чтобы увеличить вероятность идентификации, есть смысл использовать грамотную классификацию рисковых событий. Например, мы в Oko используем классификацию по степени по степени контролируемости.
Классификация рисковых событий по степени их контролируемости.
Использование этой классификации помогает определить, под какие неконтролируемые угрозы стоит планировать резервы. Нужно учитывать и то, что контролируемость рисковых событий еще не гарантирует успеха в их управлении. Также отмечу, что не всегда удается четко классифицировать угрозы, поэтому есть смысл использовать и другие способы классификации. Например, по источникам.
Пример классификации рисковых событий в зависимости от их источника.
При формулировании угрозы важно использовать двух составные понятия: с указанием на источник события и саму угрозу. Например, «угроза срыва сроков реализации из-за отсутствия определенности с функционалом» или «риск отсутствия финансирования из-за нестабильной ситуации с бюджетом у компании-заказчика». Результат — создание реестра возможных рисковых ситуаций.
Фрагмент реестра рисковых ситуаций.
Анализ и оценка рисков проекта
Здесь мы совмещаем качественную и количественную оценку.
Качественный анализ — оценка экспертных мнений и взглядов на возможные неблагоприятные последствия, обусловленные выявленными факторами. Качественный анализ более поверхностный, но часто его достаточно. Он позволяет получит на выходе:
- перечень рисковых событий, сгруппированный по приоритету
- перечень событий, которые нужно дополнительно проанализировать
- комплексную оценку угрозы для команды в целом
При анализе экспертные оценки делят на две категории: оценки вероятности н
аступления рисковых событий и оценки их влияния. Для их корректного анализа создают специальную матрицу с оценками. Например, вот такую матрицу предлагают разработчики PMBoK.
Матрица вероятности/воздействия угроз и благоприятных возможностей из PMBoK.
На основе этой матрицы можем получить три пороговых уровня: незначительные, средние и недопустимые угрозы. Оценка — это приоритет риска. В зависимости от того, в какую из категорий попадает рисковое событие, а также в зависимости от оценки, которую получает угроза, разрабатываются конкретные мероприятия по купированию и предотвращению последствий.
Чтобы оценить степень угрозы у себя в компании, мы придумали такую матрицу, в которой эта степень зависит от вероятности реализации риска и его влияния на показатели работы. Чем выше вероятность реализации и существенней влияние на проектов, тем выше степень угрозы — бороться с ней нужно активнее.
Чем выше вероятность реализации и существенней влияние на проектов, тем выше степень рисковой угрозы.
Количественный анализ рисков проекта направлен на получение конкретных оценок вероятности наступления рискового события. Количественный анализ значительно более трудоемкий, но и более точный. Он требует качества входных данных, использования развитых математических моделей и более высокой компетентности от персонала. Поэтому его используют только для сложных проектов.
Количественная оценка помогает проанализировать:
- вероятность достижения конечной цели
- степень воздействия угроз на проект и объемы непредвиденных затрат и материалов, которые могут понадобиться
- события, требующие скорейшего реагирования и большего внимания, а также влияние их последствий на результат
- фактические расходы, предполагаемые сроки окончания
Обычно для количественного анализа используют такие методологии:
Вероятностный анализ — оценка на основе статистики по прошлым проекта с учетом вероятностной погрешности.
Анализ чувствительности — оценка влияния основных параметров финансовой модели на результирующий показатель в целях выявления наиболее существенных переменных для проекта.
Имитационное моделирование — оценка, сделанная на основе многократных опытов с моделью.
Чтобы не усложнять себе жизнь, для количественного анализа лучше использовать специальный софт. Иначе от огромного массива данных и случайных чисел будет боль голова.
Планирование реакции
Когда вы определили угрозы, выяснили, на что они влияют и дали им оценку, нужно продумать реакцию, которая поможет минимизировать последствия от угрозы. Обычно на этом этапе придумывают меры, которые с высокой вероятностью помогут добиться успеха по проекту, несмотря даже на неопределенные рисковые события.
В своей практике мы выработали 4 варианта реакций, которые помогают нам ликвидировать или хотя бы минимизировать последствия от возможных проблем. Вот какие стратегии можно использовать.
1. Уклонение. Корректируем план управления таким образом, чтобы исключить возможность наступления негативных событий или снизить последствия от их наступления. Например, пересмотреть график или изменить объем работы путем удаления некритичных модификаций.
2. Передача. Перекладываем ответственность за негатив на третью сторону. Например, заключаем договор страхования, берем предоплату, предусматриваем в договоре с заказчиком неустойку. Иногда на это потребуются дополнительные деньги.
3. Снижение. Формируем предупредительные меры по снижению вероятности наступления негативных событий или последствий их наступления. Например, при формировании команды включаем в нее возможных дублеров — на случай, если разработчик заболеет, а дизайнер-фрилансер решит пропасть на неделю без предупреждения.
4. Использование. Превращаем негатив в позитив. Пример риска проекта: квалификация тестировщика вызывает у руководителя группы вопросы, есть вероятность срыва сроков и снижения качества продукта. Думаем, что делать — в качестве дублера привлекаем более опытного тестировщика. Мы увеличим бюджет, но сократим сроки на выполнение важных для нас процессов с гарантией их качества.
На основании выбранного варианта реагирования предпринимаются дальнейшие действия. Например, в PMBoK рекомендуют вносить изменения в документацию или план проекта.
Диаграмма потоков данных планирования реакции на угрозы из PMBoK.
Мониторинг и управление
Последний этап — системная работа над выявлением новых угроз, их контроль и реакция в соответствии с планом управления. Обычно эту работу ведут на всех этапах реализации продукта, вплоть до подписания акта приема-передачи. Чем ближе конец работы, тем сильнее последствия может вызвать угроза.
Важно отслеживать состояние как выявленных, так и потенциально новых рисковых событий. Дополнительно отслеживают динамику изменений, отклонений, трендов и состояние резервов, которые используют для нивелирования угроз.
Важный момент: проектный менеджер не может быть владельцем всех угроз и отвечать за всех одновременно. Поэтому есть смысл назначить ответственного по каждому риску отдельно.
В процессе мониторинга и контроля обычно выбирают и тестируют альтернативные стратегии, корректируют план для внедрения новых тактик. Все изменения и дополнения вносятся в новый план, ответственные регулярно готовят отчет, проводят совещания и обсуждают угрозы с коллегами.
Причиной возникновения рисков являются неопределенности, существующие в каждом проекте. Риски могут быть “известные” — те, которые определены, оценены, для которых возможно планирование. Риски “неизвестные” — те, которые не идентифицированы и не могут быть спрогнозированы. Хотя специфические риски и условия их возникновения не определены, менеджеры проекта знают, исходя из прошлого опыта, что большую часть рисков можно предвидеть.
Реализуя проекты, имеющие высокую степень неопределенности в таких элементах, как цели и технологии их достижения многие компании уделяют внимание разработке и применению корпоративных методов управления рисками. Данные методы учитывают как специфику проектов, так и корпоративных методов управления.
Американский Институт управления проектами (PMI), разрабатывающий и публикующий стандарты в области управления проектами, значительно переработал разделы, регламентирующие процедуры управления рисками. В новой версии PMBOK (принятие которого ожидается в 2000 году) описаны шесть процедур управления рисками. В данной статье мы предлагаем краткий обзор процедур управления рисками (без комментариев).
Управление рисками — это процессы, связанные с идентификацией, анализом рисков и принятием решений, которые включают максимизацию положительных и минимизацию отрицательных последствий наступления рисковых событий.
Процесс управления рисками проекта обычно включает выполнение следующих процедур:
- Планирование управления рисками — выбор подходов и планирование деятельности по управлению рисками проекта.
- Идентификация рисков — определение рисков, способных повлиять на проект, и документирование их характеристик.
- Качественная оценка рисков — качественный анализ рисков и условий их возникновения с целью определения их влияния на успех проекта.
- Количественная оценка — количественный анализ вероятности возникновения и влияния последствий рисков на проект.
- Планирование реагирования на риски — определение процедур и методов по ослаблению отрицательных последствий рисковых событий и использованию возможных преимуществ.
- Мониторинг и контроль рисков — мониторинг рисков, определение остающихся рисков, выполнение плана управления рисками проекта и оценка эффективности действий по минимизации рисков.
Все эти процедуры взаимодействуют друг с другом, а также с другими процедурами. Каждая процедура выполняется, по крайней мере, один раз в каждом проекте. Несмотря на то, что процедуры, представленные здесь, рассматриваются как дискретные элементы с четко определенными характеристиками, на практике они могут частично совпадать и взаимодействовать.
Планирование управления рисками
Планирование управления рисками — процесс принятия решений по применению и планированию управления рисками для конкретного проекта. Этот процесс может включать в себя решения по организации, кадровому обеспечению процедур управления рисками проекта, выбор предпочтительной методологии, источников данных для идентификации риска, временной интервал для анализа ситуации. Важно спланировать управление рисками, адекватное как уровню и типу риска, так и важности проекта для организации.
Идентификация рисков
Идентификация рисков определяет, какие риски способны повлиять на проект, и документирует характеристики этих рисков. Идентификация рисков не будет эффективной, если она не будет проводиться регулярно на протяжении реализации проекта.
Идентификация рисков должна привлекать как можно больше участников: менеджеров проекта, заказчиков, пользователей, независимых специалистов.
Идентификация рисков — итерационный процесс. Вначале идентификация рисков может быть выполнена частью менеджеров проекта или группой аналитиков рисков. Далее идентификацией может заниматься основная группа менеджеров проекта. Для формирования объективной оценки в завершающей стадии процесса могут участвовать независимые специалисты. Возможное реагирование может быть определено в течение процесса идентификации рисков.
Качественная оценка рисков

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

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

Мониторинг и контроль следят за идентификацией рисков, определяют остаточные риски, обеспечивают выполнение плана рисков и оценивают его эффективность с учетом понижения риска. Показатели рисков, связанные с осуществлением условий выполнения плана фиксируются. Мониторинг и контроль сопровождает процесс внедрения проекта в жизнь.
Качественный контроль выполнения проекта предоставляет информацию, помогающую принимать эффективные решения для предотвращения возникновения рисков. Для предоставления полной информации о выполнении проекта необходимо взаимодействие между всеми менеджерами проекта.
Целью мониторинга и контроля является выяснить, было ли:
- Система реагирования на риски внедрена в соответствии с планом.
- Реагирование достаточно эффективно или необходимы изменения.
- Риски изменились по сравнению с предыдущим значением.
- Наступление влияния рисков.
- Необходимые меры приняты.
- Воздействие рисков оказалось запланированным или явилось случайным результатом.
Контроль может повлечь за собой выбор альтернативных стратегий, принятие корректив, перепланировку проекта для достижения базового плана. Между менеджерами проекта и группой риска должно быть постоянное взаимодействие, должны фиксироваться все изменения и явления. Отчеты по выполнению проекта должны формироваться регулярно.
Вряд ли вам встречался проект, который волшебным образом шел в точности, как его запланировали в самом начале. Любой проект подвержен рискам — всевозможным событиям, которые на него влияют и обычно создают проектному менеджеру головную боль. Вообще, если не считать планирования, главная головная боль проектного менеджера как раз и заключается в разрешении рисков. Чтобы уменьшить ее, можно подумать об угрозах заранее. Оно того стоит — управлять рисками куда дешевле и проще, чем управлять реальными проблемами. Об этом и расскажем в статье: как правильно работать с рисками при управлении проектами и почему это важно.
Что такое риск
Если вам предстоит запустить проект, рано или поздно вы задумаетесь, что в нем может пойти не так. Вы начнете предугадывать слабые места проекта. Это и есть риски. Риск проекта — это неопределенное событие или условие, которое положительно или отрицательно влияет на цели проекта. Например, цель — закрыть проект, не превышая бюджет. Тогда любые события с непредвиденными расходами будут считаться риском. Или цель — создать качественный продукт раньше конкурента. Тогда есть риск опоздать с запуском или потерять проверенного поставщика и проиграть в качестве. Как только у проекта появляется цель, пора подумать о факторах, которые могут ей помешать.
Обычно риски возникают не просто так — к ним приводят действия участников проекта или они появляются из-за внутренних и внешних условий. Скажем, из-за плотной занятости руководителей проекта или плохой организации внештатных сотрудников.
Но иногда риски проекта бывают позитивными. Часто это удачные случайности или неожиданные результаты работы с негативными рисками. Представьте, что вы перестраховались и заложили в бюджет трудозатраты сотрудника-заместителя. Теперь если ваш ключевой сотрудник вдруг заболеет, а заместитель окажется эффективнее его, показатели улучшатся. Такие риски головной боли не приносят, но и встречаются очень редко. Поэтому управление рисками нужно в первую очередь для негативных событий.
Зачем управлять рисками
Управление рисками проекта — это страховка, с помощью которой можно вовремя спасти важную составляющую проекта, будь то деньги, время или даже уровень качества продукта. К тому же, профилактические меры часто выходят дешевле и быстрее решения возникших проблем. Пример рисков проекта: вы боитесь, что в середине проекта заказчик изменит требования — вам придется все переделывать и расширять бюджет. Подумайте об этом заранее. Уже на первом этапе вы можете согласовать подробное ТЗ и обговорить условия для пересмотра требований. Потратив пару дней на такую страховку, вы защитите проект от крупных задержек и сэкономите ресурсы.
По большому счету для любого риска есть два решения: игнорировать его и надеяться на лучшее или сразу попытаться устранить. Если надежда оправдается, первый вариант принесет выигрыш. Но для этого нужна скорее удача, чем расчет и планирование. В противном случае это просто принятие риска со всеми его последствиями — потерями в деньгах, времени или качестве.
Второй вариант — разрешение риска, ряд действий, чтобы снизить или устранить вероятность опасного события. Разрешение риска обычно требует дополнительных ресурсов и тщательного анализа. Но с ним проектному менеджеру немного спокойнее — проходит головная боль, появляется уверенность и защищенность. Этот вариант подходит для угроз, которые значительно выгоднее предотвратить, чем разбираться с негативными последствиями.
Получается, главная проблема и вместе с тем задача в управлении рисками — найти баланс между затратами на страховку и потенциальным ущербом от принятия риска.
Какие риски проекта самые опасные
Управление рисками проекта начинается с анализа. Предполагается, что к этому моменту вы уже знаете, какие риски проекта могут возникнуть на проекте, а лучше — имеете готовый реестр рисков. О том, как составить реестр, мы уже рассказывали в нашем журнале. Для начала можете просто сделать таблицу с рисками, их причинами и последствиями.
Задача анализа — сравнить сэкономленные ресурсы, если риск был принят, но не реализовался, с затратами на его разрешение. Оценка должна быть всесторонней, поэтому проводится в два этапа: сначала качественный, а потом количественный анализ.
Качественный анализ рисков проекта
Во время качественного анализа выбираются самые опасные и приоритетные угрозы. То есть все риски проекта делятся на важные и второстепенные. Критерии оценки руководитель выбирает самостоятельно, в зависимости от целей. Обычно решающие факторы — вероятность и возможные последствия.
Например, всегда есть опасность природных катаклизмов, скажем, наводнения. Но реальный риск существует только для производства в определенных географических районах — близко к воде. Для полноценного анализа этой угрозы нужно как минимум изучить статистику таких ЧП и посчитать потенциальный ущерб. Так, для производства в сухих районах риск маловероятен. Поэтому даже несмотря на большой потенциальный ущерб, нет смысла тратить на этот риск ресурсы.
Для определения вероятности рисков распределите их по шкале вероятности. Она может быть относительной или с цифровыми значениями.
Оценка последствий — подсчет потенциального ущерба проекту, например, расходы на зарплату сотруднику-заместителю или процент качества продукта. На универсальной шкале воздействие риска расположить сложно: ущерб зависит от целей проекта. Попробуйте записать последствия в виде таблицы, соотнося угрозы с целями.
Результаты качественного анализа ложатся в основу количественного.
Риски проекта — количественный анализ
На этот этап попадают наиболее вероятные и опасные риски. При плохом сценарии они напрямую угрожают целям проекта. Задача количественного анализа — выявить негативное влияние главных рисков и распределить их по степени этого влияния.
При количественном анализе, в отличие от качественного, значения определяются точно. Выделить высокие и низкие риски проекта недостаточно. Для оценки используются разные способы от анализа ожидаемой денежной стоимости (ОДС) до создания дерева решений.
Здесь вам может понадобиться помощь экспертов. Используйте опыт и знания сотрудников или внешних специалистов. Постоянно пересматривайте оценку, так как условия реализации проекта и его специфика могут меняться.
Управление рисками проекта — сложная область знаний со своими методиками и инструментами. Для углубления в нее можно почитать Руководство к своду знаний по управлению проектами — PMBOK. Там подробно описаны все необходимые методы управления рисками проекта, в том числе инструменты для качественного и количественного анализа.
Как найти выход
Главная цель работы с рисками — выбрать и применить верную стратегию управления. Какие риски проекта как лучше решать, подскажет тщательный анализ. Для каждого риска можно подобрать одну стратегию или скомбинировать несколько. В результате должна быть готова основная стратегия и на случай неэффективности основной — резервная.
Для работы с рисками есть несколько стратегий:

-
Уклонение — исключение опасности. Включает все меры, чтобы защитить цели проекта от угрозы. Возможно, придется изменить сами цели — смягчить требования, узнать дополнительную информацию. Например, если появляется риск сорвать сроки проекта, можно попробовать упростить продукт и сократить количество задач.
-
Передача — передача ответственности за последствия риска третьей стороне. Угроза все еще реальна, но устранить ее предстоит другим людям. Стратегия эффективная, но за принятый риск придется выделить вознаграждение. Главные примеры ведения этой стратегии — страховка, гарантии выплат и гарантийное обслуживание.
-
Снижение — снижение вероятности риска или его негативных последствий с помощью профилактических мер. Чтобы перестраховаться, можно, например, покрыть все основные кейсы программного продукта автотестами. Пусть они в обязательном порядке запускаются перед попаданием кода в продакшн. Более простой пример снижения — заранее выбирать только опытных и проверенных участников проекта и партнеров.
-
Принятие — реагирование на последствия рисков без вмешательства в сам проект. Когда исключить или снизить риски проекта невозможно, их приходится принимать — работать с негативными событиями уже после того, как они произошли. Принятие может быть пассивным и активным. Пассивное представляет собой игнорирование событий риска и экстренные меры по устранению последствий. Активное принятие — создание резерва ресурсов на случай опасности. К резервным ресурсам относятся, например, деньги, время, загруженность сотрудников.
Как управлять рисками с помощью BPM-системы
Разобраться с рисками раз и навсегда невозможно — нужно постоянно следить за результатами решенных рисков и появлением новых. Управление рисками — долгосрочный процесс, поэтому на всех его этапах должна быть возможность:
-
собирать и документировать риски проекта;
-
хранить и передавать информацию о выполненных задачах;
-
обеспечивать мониторинг статусов рисков;
-
обеспечивать контроль со стороны проектного менеджера над всеми работами.
Учесть все эти требования помогает процессный подход. Он позволяет построить последовательную цепочку задач и обеспечивает контроль их исполнения.
Процессный подход реализуется с помощью BPM-системы, в которой работа организована в виде бизнес-процессов. Бизнес-процесс — это совокупность взаимосвязанных операций, направленных на достижение цели.
Одним из примеров BPM-систем является система ELMA. С помощью дополнительного модуля Проекты+ она позволяет запустить бизнес-процесс прямо из карточки проекта. А используя мониторинг процессов, проектный менеджер сможет контролировать все этапы работы и получать подробную аналитику после завершения процесса.
Процессы управления рисками проекта могут запускаться несколько раз за проект. Например, в начале проекта для планирования и после прохождения контрольных точек — для актуализации реестра рисков. В зависимости от структуры компании и самого проекта, задачи бизнес-процесса могут отличаться, но этапы работы общие:
-
После запуска бизнес-процесса проектный менеджер самостоятельно или вместе с командой выявляет все опасности. Лучше сразу разделить риски по целям, которым они угрожают, источнику и силе последствий. Можно собрать общий реестр для всех проектов компании и выбирать из него угрозы для определенного проекта.
-
Для оценки всех рисков или отдельной группы выбираются эксперты. Им приходит задача в виде сформированного реестра с комментариями менеджера. Эксперты проводят качественный анализ и для каждой угрозы определяют статус. Во время оценки также должна быть возможность вносить в реестр новые незафиксированные риски проекта.
-
Реестр возвращается к проектному менеджеру с проставленными статусами и замечаниями экспертов. Дальше нужно провести количественный анализ. Для этого можно снова привлечь экспертов или оценить риски силами команды проекта. Важно зафиксировать все результаты количественного анализа в реестре и передать в следующую задачу. Еще один вариант: отказаться от детальной оценки и сразу перейти к выбору стратегии.
-
Менеджер проекта подводит итоги анализа, пересматривает реестр рисков и приступает к выбору стратегии. Любое изменение статуса риска, например, если он состоялся или решился, менеджер сможет зафиксировать в реестре.
-
Когда для всех рисков появится план решения, остается продумать необходимые мероприятия и поставить по ним задачи.
-
После выполнения работ проектный менеджер оценивает эффективность всего процесса.
Бизнес-процессы по управлению рисками выполняются многократно, так что менеджер получает достаточно данных для глобальной оценки всей работы: сколько времени требует оценка, риски какого типа наиболее опасны, какая стратегия выигрышная. При этом у него есть возможность непрерывно следить за статусом угроз.
Если кратко
Гарантировать успех проекта невозможно — всегда будет оставаться элемент неопределенности и риски проекта, угрожающие целям. Чтобы уменьшить неприятности, можно подстраховаться и устранить угрозы заранее. По большому счету работа с рисками заключается в поиске баланса между затратами на решение рисков и потенциальным ущербом в случае их принятия. Достичь этот баланс получится, опираясь на результаты анализа. Только после аргументированной оценки угроз можно приступать к выбору стратегии управления: уклонение, передача, снижение или принятие. Работать с рисками удобнее с помощью бизнес-процесса, а в качестве инструмента для управления рисками использовать BPM-систему.
Вот небольшой чек-лист, как начать работу с рисками проекта:
-
Найдите слабые места проекта и запишите все возможные риски.
-
Проведите качественный анализ: разделите все риски проекта на важные и второстепенные.
-
Проведите количественный анализ: определите влияние рисков на проект в точных значениях.
-
Подберите и примените к каждому риску одну или несколько стратегий управления.
-
Следите за поведением решенных рисков и регулярно начинайте сначала: риск может возникнуть на любом этапе проекта.
Риски проекта – это события, которые могут негативно повлиять на продукт или услугу: снизить эффективность, качество, способствовать расходам и т. д.
Рассмотрим, как выполнять управление рисками и какие моменты нужно учитывать, чтобы сделать работу компании более продуктивной.

Виды рисков
Различают известные и неизвестные риски:
- Для известных рисков возможно прогнозирование, их можно контролировать. Допустим, если планируется предлагать продукт в конкурентной нише, есть риск недостаточного спроса на товар или услугу.
- Для неизвестных рисков невозможно прогнозирование и контроль. Например, компания решает поставить новое оборудование не сегодня, а через неделю. Но за это время оно изменилось в цене из-за изменения экономической ситуации. Это неизвестный риск, который нельзя предугадать.
Зачем управлять рисками?
Управление рисками проекта необходимо для определения проблемных точек, их анализа и снижения эффекта от их воздействия. При грамотном подходе обеспечивается сохранение качества продукта независимо от внешних факторов.
Управление позволяет выполнять профилактику возможных проблем, прогнозировать риски и принимать решения для успешного развития.
Этапы управления рисками
Процесс управления рисками состоит из 6 стадий:
- Планирование
- Идентификация факторов риска
- Качественная оценка
- Количественная оценка
- Подготовка плана реакции
- Мониторинг и контроль
Рассмотрим эти стадии подробнее.
Планирование
Здесь осуществляется выбор стратегии управления.
Грамотное планирование подразумевает:
- Создание комфортной среды управления – налаживание отношений в команде
- Применение подготовленных шаблонов процессов управления
- Подготовка описательной части и плана управления рисками
Главное средство планирования – совещание. На нем команда, а иногда и инвесторы, обсуждают возможные риски для проекта. Затем формируется план управления, который является руководством по противодействию рискам для определенного проекта.
Идентификация
Для определения рисков проводятся исследования, которые выполняются на основе факторов риска. Возможные риски указываются по очереди от самого большого к самому несущественному. Однако не все риски можно выявить в начале проекта. Поэтому обычно число возможных рисков становится больше во время работы.
Важно: контроль рисков еще не гарантирует успешность проекта. Это нужно учитывать.
Но управление рисками необходимо, так как делает работу над проектом более эффективной.
Качественная и количественная оценка
Качественная оценка – это анализ точек зрения специалистов на возможные риски с учетом факторов риска, свойственных для определенного проекта. Такая оценка обычно более глубокая, и нередко ее достаточно. Результаты качественного анализа:
- определение рисков и их сортировка;
- определение событий для дополнительного анализа;
- комплексная оценка рисков для проекта.
Оценки экспертов бывают двух видов: которые оценивают вероятность возникновения рисков, и которые оценивают их влияние. Для работы обычно используется матрица вероятности/воздействия рисков, которая делает анализ более эффективным.
При анализе матрицы угрозы делятся на три вида: несущественные, средние и недопустимые. С учетом этого подготавливаются мероприятия для исключения рисков или снижения эффекта от их воздействия.
Количественный анализ сложнее, и применяется не всегда. Для него важно качество применяемых данных. Такой анализ подразумевает внедрение сложных математических моделей, а специалист должен иметь необходимую квалификацию для проведения такого исследования. Количественный анализ более точный, но применяется в основном для сложных проектов. Он позволяет определить:
- вероятность, с которой может быть достигнута определенная цель;
- силу действия рисков на проект;
- события, на которых нужно сконцентрироваться, чтобы исключить угрозы;
- расходы, которые могут быть.
Для исследования обычно применяются такие методы:
- Вероятностный анализ. Изучается история других проектов, вероятность, с которой возникали в них определенные риски.
- Анализ чувствительности. Изучение действия основных характеристик экономической модели на результат для определения самых важных точек проекта, в которых могут быть риски.
- Имитационное прогнозирование – определенная модель, которая имитирует реальный проект, тестируется несколько раз.
Для количественного анализа обычно используются специальный софт, который делает работу более комфортной.
Подготовка плана реакции
После определения рисков, нужно понять, как защитить о них проект или минимизировать их воздействие. Предусматриваются действия, которые в теории будут более эффективными для борьбы с определенными рисками. Главная их задача – сохранить работоспособность проекта.
Можно выделить четыре вида реакций:
- Уклонение. План корректируется, что позволяет защитить проект от рисков или снизить эффект от их действия. Допустим, можно изменить график или объемы работы, удалив несущественные модификации.
- Передача. Этот метод позволяет снизить расходы на работу с рисками. Например, подписывается соглашение в страховой или берется предоплата у заказчика.
- Снижение. Подготавливаются действия, которые снижают вероятность появления угроз. Допустим, при создании команды предусматриваются дублеры, которые могут заменить любого специалиста.
- Использование. Минусы можно превратить в плюсы. Например, для проекта берется тестировщик без опыта. Это риск, который может снизить качество продукта. Поэтому берем дублера – более опытного специалиста. Его услуги будут не нужны, если основной тестировщик выполнит работу.
Реакции применяются в зависимости от проекта, его особенностей и рисков.
Мониторинг и контроль
Эта стадия важна не меньше, чем другие. Постоянный мониторинг позволяет определять новые риски и контролировать угрозы, которые известны. Данная работа выполняется в течение всей подготовки продукта. Важно также понимать, что чем более подготовленным продукт является, тем сильнее на него могут воздействовать угрозы. Устранить или минимизировать их эффект в начале проекта легче.
Рисками занимается проектный менеджер, но он не может контролировать все угрозы. Поэтому желательно назначить для каждого риска своего специалиста. Затем проект-менеджеру нужно будет только контролировать их работу, а не заниматься самими рисками.
FAQ
Сложно ли выполнять работу по управлению рисками?
Задача непростая и для нее важна определенная квалификация. Проектный менеджер, или директор по рискам – это специалист, который использует в работе специальные инструменты. Они упрощают анализ и определение рисков, улучшают качество оценки. При определенном опыте и применении подходящих средств анализа управле6ние рисками становится обычной задачей, которая выполняется при работе над проектом. Плюс, управление рисками может осуществлять не только проектный менеджер, но и специалисты в его команде. Иногда создаются рисковые команды, которые занимаются только этим.
Требуется ли управление рисками всем компаниям?
Если предприятие достаточно крупное и производит серьезный продукт, или просто компании важна стабильность, управление рисками необходимо. Обычно оно требуется для принятия управленческих решений. Без оценки угроз решения по развитию компании может быть неправильным. Поэтому оценивать угрозы необходимо всем компаниям. Другой вопрос – насколько качественно они выполняют эту работу. Здесь все зависит от размеров предприятия и его возможностей.
Подведем итоги
- Риски – это события, которые могут повлиять на качество продукта, команду и весь проект. Они не формируются сами по себе, а образуются от внешних или внутренних факторов (например, из-за малого опыта сотрудников).
- Риски бывают известными и неизвестными. Работать проще с первыми, но предусматривать нужно и вторые.
- Для исключения угроз или снижения эффекта от их действия необходимо управлять рисками. Этим занимаются проектные менеджеры и специалисты в их команде.
- Выделяют несколько этапов управления рисками: планирование, выявление, анализ, подготовка плана реакции, мониторинг и контроль.
- Грамотное управление рисками позволяет сделать работу над продуктом более эффективной. Однако успех проекта не только в этом. Просто это работа, которая должна проводиться, как и другие проектные мероприятия.
Любой технологический проект сопряжен с рисками. Чем сложнее реализуемый продукт, чем больше процессов запущено — тем выше вероятность возникновения непредвиденных рисковых ситуаций.
В этой статье рассматриваем, что такое риск в контексте проектной деятельности, как его выявить на старте проекта и какие механики управления рисками проекта использовать.
Что такое риски проекта
Риском называют неблагоприятные события, которые вероятно могут случиться в процессе работы над проектом и повлечь за собой нежелательные последствия, помешав достижению конкретной цели. Риск может быть известным, который можно заранее спрогнозировать и придумать к нему стратегию реагирования, и неизвестным. Реагировать на неизвестные рисковые обстоятельства проблематично — их тяжело предугадать на раннем этапе и проявляются они только в процессе работы. Часто риск проекта связан с отсутствием конкретики и четкости в постановке задач, в понимании результата, на которые рассчитывает клиент. Также нередко проблемы возникают из-за некорректного планирования бюджета или расплывчатых формулировок при составлении плана. Ответственность за каждый риск проекта и несет руководитель.
Благодаря управлению риском можно предотвратить или, по крайней мере, минимизировать последствия , к которым приводят рисковые ситуации. Как это выглядит на практике — рассмотрим дальше.
Зачем управлять рисками
Практически любой риск проекта, если им не управлять, может растянуть запланированные сроки, «убить» рентабельность продукта и привести к другим нежелательным последствиям. Прогнозируя возможный риск и проблемы, которые за ним последуют, можно заранее принять меря для их исключения.
Грамотные управленцы, используя современные инструменты и методологию, на ранних этапах идентифицируют проблемные факторы, анализируют их и принимают решение, как минимизировать возможные отрицательные последствия при наступлении рисковой ситуации.
Рисковые ситуации возинкают постоянно и управление ими — это непрерывный процесс. Использование набора стандартных превентивных мер на самом старте проекта — правильно, но для хорошего результата мало. Важно регулярно оценивать и предотвращать потенциальные проблемы и рисковые случаи— это поможет повысить рентабельность проекта, высвободить материальные и трудовые ресурсы.
Оценка рисков и работы по управлению проектом нужны как своего рода страховка, которая в случае чего позволит спасти основной костяк или главную составляющую проекта. Многие управленцы согласятся, что с помощью внедрения профилактических мер и использования эффективных методов управления рисками обходится выгоднее, чем решение возникших проблем в срочном порядке.
В любом проекте есть два пути — игнорировать любой риск и надеяться на удачу, или поступить более продуманно — использовать инструменты для оценки и эффективного анализа для выявления возможных проблем и рисковых обстоятельств в будущем. Оценка рисков помогает держать, если не все, то большинство работ в рамках проекта под контролем.
Принимая риск как данность, и не предпринимая никаких мер по управлению рисками, компания может понести большие убытки.
Оценка рисков и последующие работы по их предотвращению требуют больше ресурсов и тщательного анализа, но в конечном результате это принесет свои плоды, если речь идет не о мелких, а серьезных угрозах.
Оценка рисков преследует одну цель — определить, какой риск наиболее опасен, а также разработать уникальный механизм по управлению рисками в конкретной ситуации.
Под каждый риск можно подобрать свою стратегию или сочетать несколько методов, которые будут наиболее эффективны. В результате развернутой оценки должна быть подготовлена главная стратегия и на случай непредвиденных рисковых ситуаций — резервная.
Как провести анализ рисков проекта
Проводить оценку рисковых обстоятельств важно всей командой. Необходим всесторонний подход — качественный и количественный анализ. Такая оценка помогает разобраться в рисках, распределяя их по мере их приоритетности и разработать готовые схемы реагирования. Подробнее количественный и качественный анализ мы рассмотрим далее, обсуждая шаги в управлении рисками.
Анализируя, управленцу необходимо собрать всю команду — каждый из специалистов, задействованный в работе над проектом, сможет предложить идеи и указать на «слабые места», руководствуясь практическим опытом и наработанными навыками.
Анализируя каждый риск, важно понять, что делать и как разбираться с последствиями, когда он превратится в проблему. Чтобы структурировать информацию, можно создать список рисковых ситуаций и классифицировать их по силе последствий. Если вероятность возникновения низкая, а последствия будут некритичными, то достаточно учитывать, что такой риск есть в числе возможных, и наработать схему реагирования. Если вероятность, что риск возникнет, высокая, а последствия, скорее всего, будут серьезными, важно поэтапно продумать, какими действиями можно предупредить возникновение рисковых обстоятельств.
Виды рисков
Есть несколько классификаций рисковых ситуаций. Мы предлагаем рассмотреть виды, с которыми чаще всего сталкиваются при управлении:
- Временной риск (связан с затратой времени). Суть в том, что все действия по реализации проекта могут занять больше времени, чем запланировали на старте. Время — ценнейший ресурс, поэтому о временных рисках важно всегда помнить. Временной риск опасен еще тем, что ведет к повышению расходов.
- Риск, связанный с изменением объемов работ. Такие рисковые ситуации могут появиться, если при согласовании проекта исполнители не до конца поняли требования клиента или же клиент сам внес дополнения в проект. Результат — потребуется увеличить бюджет, скорректировать сроки выполнения проектов и задач.
- Внешний риск. Речь идет о потенциально возможных рисковых событиях, которые никак не связаны с внутренними процессами компании, а значит, не могут контролироваться. Простой пример — в процессе работы над сложным проектом государство ввело новый законопроект, в результате чего потребуются дополнительные корректировки, расходы финансов и временные затраты.
- Бюджетный риск. Чаще всего такой риск возникает из-за недостатка планирования конечной стоимости проекта. Получается, что расходы больше, чем заложено в бюджет. Далее варианта два — либо проект останавливается, либо придется вкладывать дополнительные средства, чтобы устранить последствия, вызванные возникшим риском.
- Риск возникновения единой точки отказа. Это событие, которое кардинально влияет на работу всей команды над проектом. То есть, пока проблема не будет решена, никто из специалистов, задействованных в проекте, не сможет приступить к своим обязанностям. Из примеров можно рассмотреть такую ситуацию: для компании, работа которой связана с подключением к сети, единой точкой отказа может быть отключение интернета и/или электричества.
- Риск зависимости. При работе над сложными проектами одна задача тесно связана с другой. И пока один специалист не закончит свою часть работы, другой — не сможет приступить к выполнению своей.
Зная, что может возникнуть риск определенного вида, и, понимая, какие этапы включает в себя управление рисками проекта вкомпании, следует заранее проанализировать вероятность возникновения рисковых ситуаций в рамках проекта. Как это делать, мы рассмотрели, когда обсуждали качественный и количественный анализ.
Этапы управления рисками
Условно весь процесс управления можно разделить на 5 отдельных этапов:
- Планирование.
На этом этапе выбираем стратегию, то есть, решаем, как будет организован процесс по управлению рисками проекта — как между собой будут взаимодействовать участники процесса, какие инструменты будут использоваться.
Для эффективного планирования важны: благоприятная среда для коммуникации внутри команды, заранее подготовленные схемы и шаблоны, которые будут задействоваться в управлении рисками. На этапе планирования важно провести совещание, в котором примут участие все члены команды. По результату в плане должны быть прописаны рисковые ситуации, подборка методов для реагирования, правила формирования отчетности и документации по проектным угрозам, а также ответственные по рискам лица. - Идентификация факторов.
Следующий шаг — выявить и зафиксировать угрозы и определить вероятность возникновения конкретного риска на проект. В результате должен быть сформирован перечень возможных проблем и рисковых обстоятельств с ранжированием по уровню опасности для проекта. Не все угрозы можно идентифицировать на старте, а по мере работы над проектом значимость некоторых рисковых ситуаций может возрасти.
В идентификации факторов, которые могут привести к риску, можно использовать два важных фактора: источник рискового события, а также саму угрозу. В результате команда должна сформировать реестр возможных рисковых ситуаций для конкретного проекта. - Качественный и количественный анализ.
Чтобы идентифицировать риск, важно дать ему соответствующую оценку. Для этой цели применяют два метода — качественный и количественный анализ.
Качественный заключается в получении экспертных мнений относительно возможности развития неблагоприятных последствий, связанных с обнаруженными факторами риска. Качественный анализ носит поверхностный характер, но для многих проектов этого вполне достаточно. Плюс в том, что уже на старте можно получить перечень рисковых событий, распределить их по приоритетности (уровню опасности) и предпринять необходимые меры.
Количественный анализ занимает больше времени, но он намного точнее — помогает получить конкретные оценки вероятности наступления определенного рискового события. К проведению количественного анализа необходимо привлекать компетентных специалистов, так как приходится использовать сложные математические модели и методики. Благодаря проектному количественному анализу можно спрогнозировать степень воздействия на проект, а также объемы возможных материальных потерь при риске. - Планирование реакции.
Далее следует важный этап — планирование реакции для предупреждения или минимизации последствий угрозы, вызванной возникшим риском. Проще говоря, на этом этапе нужно продумать меры, которые позволят достичь целей проекта, даже при появлении непредвиденных рисковых обстоятельств.
При планировании реакции можно использовать одну из следующих стратегий:- Уклонение. План возможных действий корректируется таким образом, чтобы снизить или исключить вероятность появления негативных последствий, которые может спровоцировать тот или иной риск. Например, скорректировать утвержденный ранее график.
- Передача. Суть методики в том, чтобы переложить ответственность и возможные последствия на другую команду (третью сторону). Например, заключить договор страхования, предусмотреть в договоре неустойку.
- Снижение. Стратегия формирования предупредительных мер. Например, собирая команду экспертов, для ведущих специалистов подбирают «дублера» с соответствующей квалификацией, который в случае непредвиденной ситуации сможет взять выполнение обязанностей на себя.
- Мониторинг.
Финальный этап — проведение системной работы, направленной на выявление новых возможных угроз и рисков на проект, их контроль и реагирование в согласии с ранее составленным планом. Проводить мониторинг и контроль важно на каждом этапе старта продукта, отслеживая как уже выявленные, так и потенциальные рисковые ситуации. При поэтапном управлении рисками предполагается активный подход в работе источниками проектных угроз. Если придерживаться только пассивного реагирования уже по факту обнаружения угроз, можно сорвать сроки выполнения проекта, не уложиться в бюджет и потерять клиента. Если проект крупный, разумно по каждому риску назначить ответственного, так как менеджер по управлению не сможет контролировать все угрозы одновременно.
Управление рисками с помощью BPM-системы от «КСК ТЕХНОЛОГИИ»
Использовать механизмы по управлению рисками проекта и давать оценку вероятности возникновения проблем необходимо постоянно, так как разобраться со всеми проблемами раз и навсегда невозможно. Поскольку задача долгосрочная, на каждом этапе важно организовать:
- сбор информации о рисках и возможность для документирования;
- хранение и передачу информации о реализованных задачах;
- мониторинг статусов рисковых ситуаций;
- контроль процессов проектным менеджером.
Учесть все вышеперечисленные требования поможет процессный подход, благодаря которому выстраивается последовательность задач и контролируется их выполнение в автоматическом режиме.
Компания «КСК ТЕХНОЛОГИИ» предлагает готовое решение для реализации процессного подхода в компании — low-code платформу «КСК.ИК» класса ВРМ для цифровой трансформации организации. Платформа построена на базе ВРМ-движка, который помогает автоматизировать все процессы организации, мониторинг и аналитику исполнения приоритетных задач.
Основный функционал:
- автоматическая постановка задач;
- контроль просрочки задач и процессов;
- доступна история процесса;
- удобный функционал для коммуникации сотрудников;
- возможность группировать процессы и кейсы в списки по предметной области;
- интеграция с почтовыми сервисами;
- автоматическая рассылка системных уведомлений;
- версионность процессов (возможность исполнения бизнес-процессов по разным версиям);
- актуализация процессов без остановки уже запущенных;
- сбор информации для подготовки отчетности и анализа бизнес-процессов.
С помощью ВРМ-системы от «КСК ТЕХНОЛОГИИ», вы сможете эффективно моделировать и исполнять бизнес-процессы, принимать наилучшие решения для вашего бизнеса, грамотно управляя каждым вероятным риском.
Управление рисками – необходимый элемент ведения бизнеса и принятия управленческих решений. Экономика не имеет четкого прогноза развития событий на рынке, а как выбрать из нескольких вариантов при отсутствии определенности? Для этого компании управляют рисками проекта. О том, как их выявлять, анализировать и предотвращать, читайте в статье.
Риски проекта: понятие, значение
Риски проекта – это события, которые со некоторой долей вероятности могут произойти и повлиять на результат или исполнение проекта. В понимании риска важны два фактора:
- Вероятность – означает как возможность наступления события, так и его отсутствие. Если риск наступления события очень высок, его просто необходимо учитывать при планировании, в этом случае такое событие принимается, как реальный факт.
- Влияние – не всегда риски могут негативно влиять на проект. Если влияния на цели проекта нет, такое событие нельзя расценивать как риск.
Анализ рисков проекта проводят по этим двум факторам.
Важно! Любой проект имеет четкие ограничения: жесткие сроки, стоимость проекта и содержание, которые также можно назвать «жесткий треугольник». Риски влияют на эти ограничения, при этом невозможно изменить один параметр, не затронув остальные. Так, если сокращаются сроки проекта, возникает риск потери в качестве конечного продукта или увеличение стоимости проекта.
Управление рисками проекта представляет собой совокупность приемов и механизмов выявления событий, влияющих на проект, а также разработку мер управления и минимизации негативных рисков, которые несут угрозу бизнесу.
Управление рисками заключается в их планировании с целью предугадать появление отрицательных событий и понизить их негативный эффект, а также повысить вероятность позитивных событий, которые предоставляют возможности для развития проекта.
Рисками управляют и руководителем проекта и рядовые сотрудники, ответственные за его реализацию. При этом на начальном этапе проекта возможности управления рисками выше.
Виды рисков: основные классификации
Существуют несколько классификаций рисков проекта.
Источник угрозы
Риски подразделяются на внешние и внутренние. Внешние – непосредственное окружение проекта – поставщики, подрядчики, кредитные и иные финансовые учреждения (в случае финансирования проекта за счет кредитных и заемных средств), государственные органы (вмешательство органов государственного регулирования), окружающая среда (стихийные и чрезвычайные события), изменение валютного курса, инфляция, изменения налоговой системы.
Внутренние риски включают возможные проблемы и трудности, с которыми может столкнуться команда в процессе реализации проекта. Например, увольнение ключевого сотрудника, введение новых технологий и приемов, превышение затрат по вине внешних партнеров, срывы графика, вынужденные простои, различные технологические риски. Вероятность болезни в связи с нынешней непростой эпидемиологической ситуацией и необходимость длительного лечения и восстановления ключевых работников также должны учитываться при планировании рисков проекта.
В отдельную категорию можно вынести юридические и правовые факторы – например, необходимость получения лицензии, патента, внешние судебные иски, разрешения на ввоз/вывод при экспорте и таможенное оформление.
Этапы проекта
Как известно, любой проект, независимо от целей, включает следующие этапы осуществления:
- разработка и дизайн,
- разработка требований и методов,
- оценка и планирование,
- реализация,
- тестирование и анализ результатов.
Риски подразделяются на три категории:
- Риски неправильной оценки.
- Планирования.
- Контроля.
Выявление рисков на более ранних этапах несет меньше затрат на внесение изменений в проект и минимизирует дополнительные вовлекаемые ресурсы.
Коммуникации между командой проекта вносят свои коррективы. Их можно выделить в четвертую категорию рисков, как связующее звено между этапами реализации проекта. Процесс коммуникации важен для снижения возможных проблем в понимании и решении сложных ситуаций. Если процесс передачи информации налажен, опасность непонимания или неверного предоставления информации снижается.
Организация проекта
Сложности, связанные с ресурсами, необходимыми для реализации проекта, достаточность финансирования за счет собственных и заемных средств, зависимость от других организаций. Эти риски, как правило, неизбежны при планировании и реализации любого проекта.
Достаточность ресурсов, мотивация и заинтересованность проект-команды и руководителя в достижении целей проекта, правильная расстановка приоритетов и делегирование задач между подчиненными – факторы, влияющие на успешное и эффективное принятие управленческих решений.
Иные классификации
По сфере возникновения выделяют финансовые и страховые, коммерческие и производственные риски.
Последствия у рисков проекта также могут быть как допустимыми, так и критическими, существенно влияющими на параметры «сроки-стоимость-содержание». Наиболее негативные последствия вызывают катастрофические риски – их действие необратимо.
Время возникновения – еще один фактор классификации рисков проекта – перспективные, текущие и ретроспективные. Первые можно предугадать, последние известны на начальном этапе планирования проекта.
Как выявлять?
Анализ рисков проекта начинается с выявления проблем, которые имеют большую вероятность возникновения. Используйте один из трех способов ниже либо их комбинацию.
Прежний опыт
Анализируйте проблемы, с которыми компания сталкивалась при реализации прошлых проектов. Если фирма постоянно срывает сроки из-за проблем с поставками по вине поставщика или с несвоевременной оплатой покупателей, есть значительная вероятность подобных рисков. Использовать данный способ можно, если существует большой накопленный опыт, база, от которой можно отталкиваться при анализе рисков проекта.
Обсуждение в команде
Команда – это люди, которые непосредственно связаны с реализацией проекта, его исполнители. Именно они знают и могут вынести на обсуждение основные проблемы, с которыми компания может столкнуться. Так, инженер-технолог сможет подсказать, какого качества сырье необходимо закупить для изготовления продукта с заданными параметрами и поможет выбрать нужного поставщика, исключив соответствующие категории риска. Данный способ применим, если команда проекта – сильный и сплоченный коллектив, обладающий необходимыми навыками и соответствующей квалификацией для оценки рисков.
Пригласить внешних экспертов
Эксперты – знатоки в определенных областях – помогут разработать и реализовать проект, если в команде проекта нет соответствующих специалистов. Например, иногда необходима консультация юриста или аудитора, оценщика или финансового консультанта. Данный способ считается универсальным, он срабатывает даже тогда, когда у компании нет опыта в планировании и реализации проектов или же он негативный, а также если в команде проекта отсутствуют сотрудники нужной квалификации.
Другие способы
При выявлении рисков можно (и нужно) использовать и иные методы – например оценку специфики поставщика/потребительского рынка, учитывать случайный человеческий фактор, возникновение форс-мажорных ситуаций и особенности географического сегмента.
Анализ рисков проекта
Анализ рисков заключается в определении причин их возникновения. Главное, выявить первостепенную, главную проблему, понять, почему она появилась. Пример: компания закупила новое оборудование из Германии, возникли простои поскольку потребовалось значительное время для отладки оборудования и запуска в работу. Причины – никто не понял, как оно работает, потому что никто не прочитал инструкцию из-за незнания немецкого языка. А изначальная проблема – не было перевода инструкции по наладке оборудования, поскольку главный технолог не запросил ее при заключении договора на поставку, понадеявшись на схожие технологии и собственные силы.
Все риски подлежат документированию. Так, необходимо создать реестр для их сбора – со временем проект усложняется, увеличивается их длительность. Без постоянного и оперативного мониторинга есть опасность что-то упустить или забыть. Риски возможно группировать по этапам реализации проекта. Так в значительной мере будет легче использовать в дальнейшем накопленный опыт управления рисками проекта и систематизировать их.
Как работать с рисками?
Любой проект подразумевает наличие значительного количества пробоем, связанного с разными сферами деятельности. Все их отработать невозможно, однако следует сосредоточиться на наиболее важных из них. Для оценки рисков проекта необходимо:
- оценить вероятность их возникновения;
- определить степень влияния на проект.
Риски делятся на три группы:
- Низкая вероятность возникновения и некритичное влияние на результат проекта.
- Высокая вероятность возникновения и значительное влияние на проект и его результат определят группу рисков, которая будет привлекать внимание команды проекта и являться объектом управления.
- Комбинации высокой вероятности и низкой степени влияния или же низкой вероятности возникновения в совокупности со существенным влияние на проект определяют среднюю группу.
Исходя из построенной таблицы, легко понять, каким рискам необходимо уделять особое внимание. С ними необходимо работать в первую очередь, именно эта группа представляет особую опасность для реализации проекта. Даже если все они имеют незначительный характер, необходимо выявить приоритетные. Важно мониторить их состояние.
Таблицу рисков необходимо пересматривать. Как часто? Необходимо смотреть по значимости. Со временем, какие-то могут исчезнуть, на их место встать те, которые ранее были признаны незначительными.
Важно! Оценка рисков – субъективна и зависит от целей и специфики проекта. Одни и те же опасности в разных проектах могут иметь разную вероятность возникновения и степень влияния на результат.
Методы управления
После анализа и оценки рисков необходимо разработать план по управлению ими. Для этого
- разработайте план с мерами, которые позволят избежать проблемы;
- приготовьте план действий, на случай, если избежать сложностей не удалось.
Стратегии управления рисками
Выделяют четыре стратегии (метода) управления.
Принятие
Риск-менеджер заведомо определяет вероятность возникновения риска, как 100-процентную, и планирует меры по его устранению. Эта стратегия актуальна, когда вероятность негативных последствий минимальна или последствия незначительны.
Уклонение
Менеджер проекта старается избежать рисков и предпринимает действия, направленные на ограничение влияния внешних и внутренних факторов на результат проекта. Стратегию можно использовать, когда есть возможность с достаточной точностью предсказать возникновение риска и ее можно ликвидировать. Например, ставить четкие сроки поставок, жесткие договорные условия с поставщиками, четкие перечень работ и требования к качеству продукта.
Снижение негативного влияния
Менеджер проекта старается минимизировать негативное влияние рисков, которых не представляется возможным избежать. Эта стратегия применяется в значительной мере для рисков с высокой вероятностью возникновения и значительной степенью влияния на результат проекта.
Передача рисков
Суть стратегии заключается в передачи рисков другим исполнителям (заказчику, покупателю). Эта стратегия необходима, если компания не обладает необходимыми ресурсами для решения проблемы. Например, в команде нет экспертов по IT-технологиям или специалиста по юридическим вопросам.
Алгоритм управления рисками
Процесс управления рисками состоит из нескольких последовательных этапов:
- Выявляем риски.
- Проводим оценку (вероятность возникновения и степень влияния на результат проекта).
- Разрабатываем мероприятия (плана) по управлению.
- Мониторинг.
- Анализ результатов управления (контроль).
Предотвратить риски проще, чем исправлять ошибки
Меры предотвращения рисков являются своего рода профилактикой риск-менеджмента. Для этого требуется скорректировать обычную работу команды проекта, добавив несколько особых действий:
- Понимание целей проекта, постановка четких задач заказчиком. В начале проекта необходимо спрогнозировать с максимальной точностью конечный его результат. Это позволит определить с наибольшей достоверностью все риски, которым будет подвержен проект.
- Составление плана и документирование рейтинга рисков, соблюдение договорных обязательств и их фиксирование.
- Правильная оценка задач, необходимость предусмотреть возникновение случайных, форс-мажорных обстоятельств, которые также имею степень влияния на конечный результат проекта.
- Распределение ответственности и делегирование полномочий в команде проекта.
- Работа с частью рисков, которые признаны наиболее опасными для проекта. Не забывайте мониторить изменение остальных групп рисков.
- Максимальная проработка плана мероприятий по минимизации негативных последствий или повышения позитивного влияния.
Сочнева Анастасия Сергеевна1, Торопова Анастасия Игоревна1, Ротанова Валерия Александровна1, Власова Анастасия Андреевна1, Кокарева Марина Евгеньевна1
1ФГБОУ ВО Нижегородский государственный педагогический университет имени Козьмы Минина (Мининский университет), студент
Аннотация
В данной статье авторы анализируют основные способы минимизации рисков на предприятии, описывают их, а также рассматривают существующие механизмы.
Библиографическая ссылка на статью:
Сочнева А.С., Торопова А.И., Ротанова В.А., Власова А.А., Кокарева М.Е. Механизмы минимизации рисков // Современные научные исследования и инновации. 2020. № 1 [Электронный ресурс]. URL: https://web.snauka.ru/issues/2020/01/91075 (дата обращения: 23.01.2023).
Управление рисками — это процесс принятия и выполнения управленческих решений, которые направлены на снижение вероятности возникновения неблагоприятного результата и минимизацию возможных потерь проекта, вызванных его реализацией. Для того чтобы правильно управлять рисками, необходимо знать основные механизмы.
1. Уклонение от риска. Организация в процессе производственно-хозяйственной деятельности способна отказаться от совершения отдельных операций или видов деятельности, связанных с высоким уровнем риска. К числу основных из таких мер относятся:
— отказ от осуществления финансовых операций, уровень риска по которым чрезвычайно высок;
— отказ от использования в высоких объемах заемного капитала;
— отказ от чрезмерного использования оборотных активов в низколиквидных формах;
— отказ от использования временно свободных денежных активов в краткосрочных финансовых вложениях.
Данный путь наиболее прост и радикален. Он позволяет полностью избежать вероятных потерь, связанных с предпринимательскими рисками, но, с другой стороны, не позволяет получить прибыли, связанные с рискованной деятельностью. Поэтому в системе внутренних механизмов нейтрализации рисков их избежание должно осуществляться очень взвешенно при следующих основных условиях [1]:
— если отказ от одного финансового риска не влечет возникновения другого риска более высокого или однозначного уровня;
— если уровень риска несопоставим с уровнем доходности финансовой операции по шкале “доходность-риск”;
— если финансовые потери по данному виду риска превышают возможности их возмещения за счет собственных финансовых средств предприятия и др.
Данный метод применяется только в отношении очень серьезных и крупных рисков.
2. Принятие риска на себя. Главная цель – изыскание источников ресурсов, нужных для покрытия вероятных потерь. В данном случае потери покрываются из любых ресурсов, оставшихся после наступления предпринимательского риска. Если у предприятия недостает оставшихся ресурсов, то это, возможно, приведет к сокращению объемов бизнеса.
3. Передача (или трансферт) риска партнерам по отдельным сделкам или хозяйственным операциям путем заключения контрактов. При этом хозяйственным партнерам будет передана та часть предпринимательских рисков, по которой предприятие имеет больше возможностей нейтрализации их негативных последствий.
4. Объединение риска. Риск делится между несколькими субъектами экономики. Объединяя усилия в решении проблемы, несколько предпринимательских организаций могут разделить как возможную прибыль между собой, так и убытки от ее реализации [2].
Поиски партнеров проводятся среди тех предприятий, которые располагают дополнительными финансовыми ресурсами, а также сведениями о состоянии и особенностях рынка.
5. Диверсификация – представляет собой процесс распределения капитала между различными объектами вложения, которые непосредственно не связаны между собой. Диверсификация является наиболее обоснованным и относительно менее ёмким способом снижения степени финансового риска.
Диверсификация бывает следующих видов:
- предпринимательской деятельности предприятия;
- портфеля ценных бумаг;
- программы реального инвестирования;
- кредитного портфеля;
- поставщиков сырья, материалов и комплектующих;
- покупателей продукции;
- валютной корзины предприятия.
Характеризуя механизм диверсификации в целом, следует отметить, что он избирательно воздействует на снижение негативных последствий отдельных финансовых рисков. Обеспечивая несомненный эффект в нейтрализации комплексных, портфельных финансовых рисков несистематической (специфической) группы, он не дает эффекта в нейтрализации подавляющей части систематических рисков – инфляционного, налогового и др. Поэтому использование этого механизма носит на предприятии ограниченный характер.
6. Хеджирование. Хеджирование используется в банковской, биржевой и коммерческой практике для обозначения различных методов страхования валютных рисков. В отечественной литературе термин “хеджирование” стал применяться в более широком смысле как страхование рисков от неблагоприятных изменений цен на любые товарно-материальные ценности по контрактам и коммерческим операциям, предусматривающим поставки (продажи) товаров в будущем. Контракт, который служит для страховки от рисков изменения курсов (цен), носит название “хедж”, а хозяйствующий субъект, осуществляющий хеджирование – “хеджер”.
Существуют две операции хеджирования: хеджирование на повышение и хеджирование на понижение:
— Хеджирование на повышение, или хеджирование покупкой, представляет собой биржевую операцию по покупке срочных контрактов или опционов. Хедж на повышение применяется в тех случаях, когда необходимо застраховаться от возможного повышения цен (курсов) в будущем.
— Хеджирование на понижение, или хеджирование продажей – это биржевая операция с продажей срочного контракта. Хеджер, осуществляющий хеджирование на понижение, предполагает совершить в будущем продажу товара, и поэтому, продавая на бирже срочный контракт или опцион, он страхует себя от возможного снижения цен в будущем.
7. Страхование риска – это отношения по защите имущественных интересов физических и юридических лиц при наступлении страховых случаев, которые производятся за счет денежных средств, формируемых из уплачиваемых ими страховых взносов (страховых премий). Страхование риска является наиболее важным методом снижения степени риска.
Сущность страхования выражается в том, что инвестор готов отказаться от части своих доходов, чтобы избежать риска, т.е. он готов заплатить за снижение степени риска до нуля [3].
8. Самострахование (внутреннее страхование). Механизм этого направления минимизации финансовых рисков основан на резервировании предприятием части финансовых ресурсов, позволяющем преодолеть негативные финансовые последствия по тем финансовым операциям, по которым эти риски не связаны с действиями контрагентов. Основными формами этого направления нейтрализации финансовых рисков являются:
— формирование резервного (страхового) фонда предприятия (не менее 5% суммы прибыли, полученной предприятием в отчетном периоде);
— формирование целевых резервных фондов;
— формирование системы страховых запасов материальных и финансовых ресурсов по отдельным элементам оборотных активов предприятия.
Наиболее распространённые инструменты и методики (техники) оценки риска приводятся в международном стандарте ISO/IEC 31010:2009. В стандарте кратко описывается 31 метод оценки риска: мозговой штурм, анализ «Что если…», FMEA, HAZOP, HACCP, диаграмма «галстук-бабочка», анализ дерева отказов, Байесовы сети, FN-кривые и др.
Библиографический список
- Буньковский Д.В. Методы минимизации рисков предприятия // Вопросы управления. 2018. №5 (35). URL: https://cyberleninka.ru/article/n/metody-minimizatsii.. (дата обращения: 21.12.2019)..2019).
- Мамаева Л.Н., Артемьев Р.Д., Бекетова А.П. Минимизация коммерческих рисков // ИБР. 2018. №4 (33). URL: https://cyberleninka.ru/article/n/minimizatsiya-komme.. (дата обращения: 21.12.2019).
- Дмитрий В.Б. Инструменты управления предпринимательскими рисками // Вопросы управления. 2019. №1 (37). URL: https://cyberleninka.ru/article/n/instrumenty-upravle.. (дата обращения: 21.12.2019).
Количество просмотров публикации: Please wait
Все статьи автора «Сочнева Анастасия Сергеевна»
Проект внедрения программного продукта 1С представляет собой сложный процесс, в котором присутствуют и технологические, и интеллектуальные ресурсы как заказчика и исполнителя, так и внешних консультантов, партнеров, соисполнителей. Процесс внедрения системы автоматизации чаще всего связан с высоким уровнем рисков, носящих организационный и технологический характер.
В настоящей статье мы рассмотрим основные практические моменты по управлению рисками проекта внедрения программного обеспечения, которые могут возникнуть.
Жизненный цикл проекта по внедрению программ 1С состоит из нескольких этапов, на каждом из которых присутствуют свои риски. Также существуют общие риски всего проекта.
На этапе продажи проекта внедрения системы 1С существенным риском является ошибка в оценке затрат на реализацию проекта. Это связано с ценообразованием, которое в первую очередь строится исходя из высокой конкуренции между исполнителями. И некорректная оценка затрат на проект напрямую связана с тем, что на этом этапе заказчик ещё не может полноценно определить или сформулировать требования к внедряемому программному продукту. Как следствие, технические специалисты исполнителя не могут детализировано провести оценку проектных работ. А менеджер по продажам, преследуя цель получения проекта может занизить экспертную оценку в угоду оптимистичной оценке предстоящего проекта. Как следствие неверная оценка затрат проекта приводит к негативным последствиям для всего проекта, включая его срыв.
На предпроектном обследовании системы и формализации требований выполняется интервьюирование специалистов заказчика с целью сбора и категоризации основных требований ключевых пользователей системы 1С. Обычно в этом процессе участвуют специалисты заказчика нескольких организационных подразделений, что являет собой различные взгляды, как на цели и задачи проекта, так и на некоторые нюансы автоматизации бизнес-процессов. Результатом разобщенности во взглядах на данном этапе может стать общая неудовлетворенность во внедренной информационной системе, затягивание периода опытной эксплуатации и существенный поток замечаний и претензий в адрес исполнителя.
На этапе проектирования и разработки осуществляется проработка архитектуры системы в целом, а также некоторых её модулей. На этом этапе велики технологические риски, связанные с ошибкой решения в части архитектуры информационной системы или неполной проработкой отдельных модулей и/или взаимосвязей между ними, неучтенными нефункциональными требованиями, такими как отклик системы на действия пользователя, надежность данных, их масштаб и технические возможности оборудования заказчика и т.п. Критичным является то, что выявление этих рисков происходит в достаточно поздние сроки, например на стадии опытной эксплуатации или эксплуатации на реальных данных реальными пользователями 1С. Это приводит к необходимости экстренного выполнения доработок или даже возможного срыва проекта в целом в силу непригодности системы к реальной и полноценной эксплуатации.
Как правило, этот этап является самым длительным, и основная причина появления рисков в процессе разработки – это недостаточный анализ требований или неоднозначная их трактовка, что приводит к тому, что результат не соответствует ожиданиям представителей заказчика.
При внедрении информационной базы довольно часто исполнителю приходится сталкиваться с непринятием сотрудниками заказчика обновленного функционала системы, её пользовательского интерфейса и т.п. Если не контролировать этот риск, то он может перерасти в открытый саботаж пользователями новой системы. Также ситуация может усугубляться неподготовленностью информационной инфраструктуры заказчика к внедрению программного обеспечения, что является причиной срывов сроков проекта и необходимостью доработки или адаптации программного обеспечения за счет увеличения бюджета проекта.
На стадии завершения проекта и поддержки пользователей в период опытно-промышленной эксплуатации системы очень часто встречается риск, обусловленный отсутствием службы поддержки со стороны заказчика или её некомпетентности из-за отсутствия навыков по работе с новой конфигурацией системы. Это приводит к тому, что ликвидация сбоев системы становится неоперативной или поддержка конечных пользователей не является комплексной и полноценной.
Если проектный менеджер (как со стороны исполнителя, так и со стороны заказчика) не видит преград в реализации проекта, то в большинстве случаев это говорит о том, что он скорее всего не потрудился на старте их поискать и придумать как с ними лучше всего разобраться.
А риски в итоге возникают (это неизбежно) и приходится их в суете решать. Но ведь можно это сделать заранее и спокойно, до старта проекта.
В проектном управлении существует такое понятие, как «риск-менеджмент». Но нужно понимать, что риск-менеджмент – это не только составление и просчет рисков проекта на определенных его этапы. Риск-менеджмент – это спокойная, без истерик и суеты, сенсорика и разрешение проектному менеджеру думать о том, что что-то пойдет не так.
Но простого разделения на части процесса управления рисками недостаточно, ведь управление рисками имеет под собой некую цикличность, когда в зависимости от возникающих изменений требуется выполнять одни и те же процессы управления:
При определении рисков необходимо исходить не только из методологии определения и расчета рисков, но и из опыта реальных проектов внедрения программ 1С, имеющейся базы знаний, областей деятельности компании, в которой реализуется проект. Требуется участие не только исполнителя, который определит основные существующие риски проекта внедрения, но и заказчика, который заложит риски в виду нюансов и особенностей ведения деятельности компании.
Перед стартом проекта проводится работа по идентификации возможных и существующих рисков. Процесс идентификации представляет собой поиск всех возможных рисков, по итогам которого мы должны найти ответы на вопрос: «Что может пойти не так?» (для негативных рисков). Но при поиске ответов на вопрос: «Что может пойти не по плану?» можно найти и позитивные риски.
При планировании рисков следует учитывать, что большим количеством рисков одновременно и качественно управлять невозможно, поэтому цель качественного анализа рисков проектов состоит в группировке и расстановке приоритетов.
Оценка рисков проекта и идентификация проводится для составления плана реагирования на риски. Оптимально управлять одновременно не более 10 рисками.
Этот этап является одним из сложных, так как принятые решения по ликвидации или снижению рисков затрагивают основные составляющие управления проектом: объем, бюджет и сроки проекта. То есть необходимо учитывать тройное ограничение проекта:
Такое ограничение говорит о том, что, как и у треугольника, нельзя изменить одну сторону, не задев как минимум ещё одну. Изменение одного параметра управления проектом влияет и на другие параметры.
Поэтому процесс контроля и мониторинга рисков ориентирован на оценку текущей ситуации по проекту: управление рисками, анализ возникших отклонений, контроль изменений и их влияния на все параметры проекта.
При выборе стратегии управления рисками проекта необходимо учитывать понятие о риске проекта. Риск проекта – это неопределенное событие, которое в случае его возникновения имеет негативное или позитивное воздействие как минимум на один из параметров проекта (например, срок или бюджет проекта).
При расчетах величины риска значения влияния и вероятности возникновения определяются по шкале от 0 до 1:
1 – известно, что событие определенно произойдет.
0 и 1 – это крайние значения, которые не должны учитываться в оценке, так как риск имеет под собой вероятностную природу. Например, если что-то точно произойдет, то это уже не риск, а состоявшееся событие, то есть свершившийся факт. Следовательно, в таком случае необходимо управлять не риском, а изменениями, которые на это событие повлияли.
В процессе расчета величин риска определяются стратегии ликвидации рисков. При этом можно использовать следующие мероприятия по реагированию на риски:
Уклонение от риска предполагает корректировку плана управления проектом так, чтобы максимально исключить угрозу негативного риска, а также снизить последствия риска для целей проекта (например, пересмотреть график проекта или изменить объемы путем исключения некритичных модификаций). Важно заметить, что некоторых рисков можно избежать, если на ранних стадиях проекта детализировано собирать требования заказчика, налаживать более приятные коммуникации.
Передача риска осуществляется путем переложения негативных последствий риска под ответственность третьей стороны. При этом необходимо понимать, что при передаче управления риском третьей стороне сам риск не снимается. Такая стратегия управления риском эффективна в части финансовых рисков. Например, страхование, гарантии выполнения контракта, выдача гарантийных обязательств и т.п. Естественно, что условия передачи рисков третьей стороне несут в себе обязательства по выплате премии за риск третьей стороне. Если проект подразумевает оплату фактических издержек заказчиком, то бремя выплаты премии может быть переложено на заказчика, а вот с фиксированной ценой контракта это бремя обычно ложится уже на исполнителя.
Снижение риска предполагает уменьшение вероятности и/или последствий рискованного события до необходимых пределов. То есть стратегия состоит в формировании предупредительных мер по снижению вероятности негативного события или последствий его наступления, т.к. предупреждение всегда эффективнее, чем разрешение последствий свершившегося факта. Как пример снижения риска можно привести работу по планированию человеческих ресурсов как на стороне заказчика (бизнес-эксперты, ключевые пользователи), так и на стороне исполнителя (консультанты, разработчики) в случаях их болезни, отпуска или увольнения. Как предупредительная мера может использоваться оптимизация сложных процессов за счет их упрощения (исключить неактуальные действия или пересмотреть схему движения бизнес-процесса), увеличение количества тестовых испытаний на реальных данных с активным участием пользователей, выполняющих соответствующие функциональные обязанности и прочее.
Использование риска выбирается в качестве стратегии реагирования на благоприятные последствия случившегося события. Примером использования может служить возникновение возможности по привлечению специалиста более высокого уровня с целью сокращения времени на реализацию определенных задач проекта. Также примером является отказ от модификации в пользу использования стандартного функционала системы в виду изменения методологии бизнес-процесса.
Усиление через позитивное воздействие на складывающуюся ситуацию позволит повлиять на условия формирования события в положительном ключе. Один из примеров реагирования на такой положительный риск – это привлечение специалиста со стороны заказчика, находящегося на более высоком уровне принятия решений по проекту, в случае каких-то согласований задач по модификациям.
Результатом работ по определению стратегий нивелирования рисков должен явиться план по управлению рисками (он же реестр рисков). Данный реестр относится к проектной документации, и его актуализация производится на протяжении всего жизненного цикла проекта за счет мониторинга и контроля рисков.
В данном реестре рисков кроме перечня возможных рисков определяется, как данный риск влияет на проект, учитывается величина риска по вероятности наступления и степени его влияния и определяются мероприятия (стратегия) по управлению этим риском.
|
№ |
Описание риска |
Потенц. воздействие на проект |
Вероятн. возн-ия |
Влияние на проект |
Уровень риска |
Вариант решения |
|
1 |
Недостаточное внимание к проекту со стороны бизнес-экспертов (например вследствии их занятости текущей работой или участия в других проектах). Возможно, риск проявится на интеграционном тесте |
— Эксперты не выдают ответную реакции и тормозят проект или ведет к сдвигу сроков старта— Недостаток ресурсов от Заказчика |
0,4 |
0,9 |
0,36 |
1) Заранее оговорить возможность подключения доп. экспертов в случае занятости основных участников2) заложить в бюджет проекта (заказчику) доп. мотивацию экспертов на резульатты проекта (премирование по завершению проекта)3) Привлечение спонсора проекта к решению конфликта ресурсов4) Замена бизнес-эксперта на менее занятого специалиста |
|
2 |
Отставание в разработке скриптов или модификаций |
0,3 |
0,5 |
0,15 |
1) Позиционирование задач по проекту как задач 1 приоритета2) Заложить резервы в плане работ между модификациями и началом интеграционного теста3) Для модификаций: приостановка всех остальных модификаций4) Для скриптов: определение приоритетных и необходимых к старту |
|
|
3 |
Смена заказчика |
0,2 |
0,6 |
0,12 |
вести документацию, встретится с новым заказчиком сразу после смены |
|
|
4 |
Смена требований |
0,8 |
0,9 |
0,72 |
дизайн решения, хорошая документация, записи, протоколы |
|
|
5 |
Производительность системы, блокировки |
Низкая производительность системы может привести к простоям при работе ключевых процессов (приемка/отгрузка) |
0,5 |
0,5 |
0,25 |
замеры при большом объеме, можно риски оптимизации взять на себя,увеличение мощности серверов, добавление памяти и т.д.1) Разводим сервер приложений и SQL сервер на разное «железо» — Трилайн2) Планирование железа с резервом относительно рекомендаций вендора |
|
6 |
Фин. Стабильность заказчика или изменчивость заказчика |
часто меняющиеся приоритеты и взгляды заказчика |
0,4 |
0,9 |
0,36 |
дробить акты на более мелкие этапы и чаще актироватьсяне начинать следующий этап пока не подписан акт за предыдущий |
|
7 |
Смена проектной команды – мониторить состояние людей и искать замену если кто-то уходит |
0,7 |
0,7 |
0,49 |
мониторить состояние людей и искать замену если кто-то уходит |
|
|
8 |
Предварительная оценка трудоемкости по задачам проекта не соответствует оценке, уточняемой сейчас по факту написания ФД, т.к.ФД отсутстовали момент подготовки первоначальной оценки |
Неверная (оптимистичная) оценка сроков разработки может повлечь срыв сроков по подготовке к старту |
0,8 |
0,9 |
0,72 |
1. Упрощение функционала, отказ от неприоритетных требований2. сдвиг сроков проекта, расширение бюджета проекта1) Закладывание в план резервов по времени относительно оценки трудоемкости — ФТО2) Разделение модификаций на критичные для старта и некритичные — и выполнение в соответствии с приоритетами (некритичные модификации, не готовые на момент начала интеграционного теста не участвуют в нем) — ФТО |
|
9 |
Работа во время нового года — 1) недоступность компетентных людей на филиалах. Если потребуется оперативно поменять БП, то это не с кем будет обсудить. Например, решение по включению в работу доп. операторов никто не сможет исполнить2) недоступность экспертов. Пример — до старта принято решение о сохранении кредитного лимита, после старта выявляется, что необходимо отключить кр. лимит. Этот вопрос будет не с кем согласовать |
срыв сроков запуска, старта системы |
0,5 |
0,8 |
0,4 |
Письмо от РП на директора:1) на каждом филиале должно быть выделено ответственное лицо (нач. ООЗ или операторов выписки), который будет доступен 01.01.хх гг. С ними предварительно обсудить возможные сложности при старте2) Получить контакты всех экспертов проекта3) Получить полномочия на принятие решений своими силами (В случае если связаться с экспертами не удается — принятие решений производить самостоятельно) |
|
10 |
Возникновение проблем с каналом в Омске/Москве в новый год. Работы выполнены не будут, так как провайдер оперативно проблему не решит |
срыв сроков запуска, старта системы |
0,4 |
0,8 |
0,32 |
В Омске: Есть два магистральных канала в офисе. Если даже закрыть риск сбоя в обоих, то необходимо протестировать работу каналов на дому у одного из специалистов, осуществляющих перенос остатковВ ЦО: риска нет |
|
11 |
Есть изменения в алгоритмах работы пользователей. Это может повлечь человеческие ошибки |
0,8 |
0,8 |
0,64 |
Информирование специалистов на филиалах по двум каналам — через лидеров на филиале и через функциональных руководителей (Координация действий осуществляется через службу поддержки, с использованием ленты сообщений в аксапте, телефона, e-mail) |
|
|
12 |
Риск падения производительности в первые 5 дней после старта новой базы (из-за быстрого роста базы) |
падение производительности и блокировки из-за одновременной работы многих пользователей и нагрузка по загрузке остатков |
0,8 |
0,9 |
0,72 |
1) Периодический пересчет статистики2) Продумать вариант подключения доп. оборудования для нужд статистики и периндексации — например, узел от архивной и офлайна.3) Анализ и выявление таблиц, по которым может потребоваться переиндексация (а также выяснение времени, необходимого на переиндексацию).В случае возникновения проблемы проводить переиндексацию по необходимым индексам (возможно, потребуется останов), временное увеличение мощности серверов |
|
13 |
Для запуска новой базы будет необходим длительный останов (более суток) |
0,9 |
0,9 |
0,81 |
1) Тест производительности2) В случае, если тест производительности покажет, что времени впритык — подготовка алгоритма действий для возврата к работе в старой базе (например, перенос заказов на 2007 год из новой базы в старую, ярлыки)Возврат на старую базу до 12:00ч 01 января. Проведение повторно работ с 31 января на 01 февраля |
|
|
14 |
Невозможность выхода на работу кого-либо из членов команды проекта в критический момент. Например, в новый год по причине болезни |
0,5 |
0,5 |
0,25 |
Необходимо заранее договориться какие члены в команде должны быть взаимозаменяемыми, как со стороны ФТО, так и со стороны Заказчика. Перед новым годом провести «передачу знаний» |
|
|
15 |
Служба поддержки (при текущем графике работы) не будет справляться с поступающими вопросами от пользователей. |
0,8 |
0,9 |
0,72 |
Заранее утвердить график работы службы поддержки (с учетом повышенной нагрузки) на первые 5 рабочих дней января.В случае, если служба поддержки не будет справляться, временно перебросить им в помощь одного разработчика. |
|
|
16 |
Закрытие декабря и текущего года, а также января следующего года не будет выполнено во время |
в момент старта новой системы еще не буде закрыт период в старой системе и не будет реалных данных по остаткам |
0,5 |
0,9 |
0,45 |
1) Требуется заранее согласовать с руководством ЮМ возможное отставание2) На помощь в закрытии выделить двух квалифицированных специалистов службы поддержки3) перенос временных остатков по тем данным что есть в старой базе. После закрытия периода доперенос остатков |
|
17 |
С 27.12 будет действовать две базы — старая и новая для ввода заказов на следующий год. При этом в старой базе могут изменить настройки и справочники, которые не попадут в новую (случайно, т.к. права должны быть закрыты по плану)Либо пользователи будут выполнять операции не в той базе |
0,7 |
0,9 |
0,63 |
1. Выслать на всех пользователей аксапты, и ежедневно дублировать, требование не изменять справочники и настройки в старой базе с 27.12 по 31.122. Программные запреты на выполнение операций в неправильной базе3. Вручную откорректировать справочники в старой базе в случае расхождения. Операции сторнировать и вводить в правильную базу |
|
|
18 |
Объем ручной работы бухгалтеров по переносу остатков может сдвинуть срок закрытия |
0,5 |
0,7 |
0,35 |
1. По результатам сформированного дизайн-решения удалось добиться минимальной ручной работы. Есть подтверждение, что доп.ресурс не нужен2. В случае тотального кризиса подключение поддержки к выполнению сверок |
|
|
19 |
Сжатые сроки выполнения работ |
0,5 |
0,9 |
0,45 |
Подневное планирование работ руководителями проектных группПодготовка и тщательное соблюдение процедуры для согласования документов, как наиболее рисковой в части подготовки Концептуального проекта.Сформировать временной резерв в части даты запуска проекта в продуктивную эксплуатацию. |
|
|
20 |
Расширение объема проекта в ходе выполнения |
0,6 |
0,9 |
0,54 |
Необоснованное расширение объема проекта в ходе выполнения ведет к затягиванию сроков и удорожанию пилотного проекта, а так же усложняет дальнейшееДля минимизации данного риска руководители проектных групп должны понимать границы проекта (см. раздел 3) и обеспечивать их соблюдение. При возникновении отклонений они должны фиксироваться и рассматриваться согласно процедуре одобрения запросов на изменения. |
|
|
21 |
Большое количество модификаций |
0,8 |
0,9 |
0,72 |
Минимизация данного риска должна быть достигнута с помощью определения в качестве одной из задач проекта использования стандартной функциональности и лучших практик 1С.Любая модификация стандартной функциональности 1С должна быть оформлена запросом на изменение и пройти процедуру одобрения для включения в проект. Каждая модификация будет оцениваться с точки зрения возможных затрат, выгод, обходных путей. |
|
|
22 |
Один руководитель возглавляет несколько проектных групп |
0,5 |
0,8 |
0,4 |
Основные негативные влияния риска: перегруз руководителей оперативными задачами, срыв сроков подготовки проектных решений, недостаточный уровень качества проектных решений для передачи в реализацию, замедление формирования 1С-экспертизы у проектной группы.Для устранения влияния данного для каждой проектной группы нужно назначить отдельного руководителя.Для снижения влияния данного риска для руководителей, возглавляющих сразу несколько проектных групп следует предусмотреть заместителей, которым будет делегированы необходимые полномочия. |
|
|
23 |
Один сотрудник выступает в качестве эксперта в нескольких проектных группах |
0,5 |
0,8 |
0,4 |
Основные негативные влияние риска: невозможность независимой работы групп, необходимость согласования загрузки бизнес-экспертами между различными проектными группами. Бизнес-эксперты перегружены информацией по различным функциональным модулям 1С, что затрудняет ее усвоение.Риск может быть минимизирован распределением бизнес-экспертов по отдельным группам (определение будущей специализации бизнес-эксперта), с возможностью привлечения другими проектными группами по договоренности между руководителями групп. |
|
|
24 |
Перераспределение нагрузки в разнородных проектных группах |
0,5 |
0,6 |
0,3 |
Большинство проектных групп являются разнородными состоят из представителей клиента и ФТО. Некорректное перераспределение работы внутри группы может привести к удорожанию проекта, затягиванию сроков, замедлению формирования 1С-экспертизы у сотрудников клиента и ФТО.Для минимизации данного риска руководители рабочих групп должны понимать корректное распределение работ между участниками, соответствующим образом составлять рабочие планы, вести их оперативный контроль, своевременно направлять вопросы руководству проектом. |
|
|
25 |
Отсутствие у клиента на дату начала проекта подготовленной проектной команды и специалистов по 1С. |
Основным негативным влиянием риска является затягивание сроков проекта в связи с необходимостью обучения новому решению, вероятность принятия некорректных решений в связи с недостатком знаний о 1С, сложности с поддержкой и тиражированием решения силами клиента и ФТО |
0,5 |
0,8 |
0,4 |
Для минимизации данного риска следует организовать обучение проектной команды согласно рекомендациям фирмы 1С. Руководители проектных групп отвечают за формирование 1С-экспертизы в своих группах и имеют право запросить проведение дополнительного обученияУчастники проектной команды клиента и ФТО приобретают практический опыт использования 1С при выполнении задач проекта. |
|
26 |
Не полное понимание и принятие, бизнес-экспертами и сотрудниками проектных групп клиента стандартных бизнес-процессов и лучших практик 1С. |
срыв сроков запуска проекта, сложности в реализации модификаций |
0,7 |
0,7 |
0,49 |
Проведение обучения стандартным функциональным возможностям 1С и тест-скриптов системы по наложению бизнес-процесса на стандартный функционал системы.Руководители проектных групп продвигают одно из основных допущений проекта: использование стандартной функциональности и лучших практик 1С. |
|
27 |
Бизнес-процессы, разработанные в по головному предприятию, не будут приняты на пилотной площадке |
0,3 |
0,8 |
0,24 |
Мастер-эксперты и руководители проектных групп отслеживают отклонения существующей организации бизнес-процессов и модели бизнес-процессов, спроектированной в Концептуальном проекте. В случае возникновения существенных отклонений должна быть обеспечена тесная коммуникация с пилотной площадкой для обеспечения реализуемости изменений. |
|
|
28 |
Неработоспособность более 10% функционала после переноса модификаций |
0 |
Добавление ресурса разработки ФТО |
|||
|
29 |
Невозможность полноценного переноса функционала на внедряемую редакцию |
0,5 |
0,6 |
0,3 |
Изменение функционала ПО |
|
|
30 |
В период между полной готовностью ПО и стартом появятся изменения в законодательстве, требующие модификаций, и ПО на момент старта не будет соответствовать ему в полном объеме |
0,6 |
0,7 |
0,42 |
Добавление ресурса разработкиСо стороны бизнес-эксперта заказчика — постоянный мониторинг изменения законодательства в части планируемой автоматизации бизнес-процессов |
|
|
31 |
Не будет выделено достаточное время пользователей на обучение — пересечение с рабочим графиком |
— Плохое качество обучения— Плохое понимание нового функционала, непривычность к интерфейсу -> ошибки в работе с новой системой -> возможные проблемы с отгрузкой |
0,6 |
0,9 |
0,54 |
1) Минимум за неделю до старта обучения согласовать комфортный график обучения2) по результатам обучения провести аттестацию, тестирвоание3) Резервы времени по обучению людей, выполняющих бизнес-критичные операции — ФТООбучение будет проводиться по группам пользователей (склад — отдельно, заявки — отдельно и т.п.), вместе с группами обучаются непосредственные руководители4) со стороны заказчика — контроль и планирование текущей работы и графика работы сотрудников |
|
32 |
Большой объем разработки -> ошибки в новом функционале -> возможны проблемы на старте (оперативного плана) |
0,5 |
0,8 |
0,4 |
Выделение достаточного объема времени на интеграционный тест |
|
|
33 |
Срыв сроков закрытия периода в старой системе, может привести к задержке закрытия месяца старта в новой |
0,5 |
0,8 |
0,4 |
мер нет на заказчик должен быть к этому готов. |
|
|
34 |
Большая загрузка бизнес-экспертов, может пострадать качество приемки разработанной системы (интеграционного теста) |
0,7 |
0,9 |
0,63 |
Планирование интеграционного теста в период с наименьшей загрузкой экспертовПланирование замены бизнес-экспертов для приема функционала системы |
|
|
35 |
Изменяются настройки кредитного лимита — могут быть проблемы с недоотгрузкой в первые дни работы |
0,8 |
0,4 |
0,32 |
Проверка кредитных лимитов перед запуском системы (руководитель отдела) |
|
|
36 |
Новый документооборот склада -> путаница в рядах операторов, бухгалтерия может потом «не собрать» нужные документы |
0,8 |
0,6 |
0,48 |
Предварительное обучение людей (операторы) именно документооборотуОформление подробных инструкций пользователя со схемами документооборота |
|
|
37 |
Коммуникационный риск («правая рука не знает что делает левая») между ФТО и субподрядчиком — системным администратором по тех. поддержке ТСД |
0,4 |
0,7 |
0,28 |
с даты старта — еженедельные совещания (Бухгалтерия + Склад + Продажи + Закупки + ИТ + ФТО) по ходу работ, в течение первой недели после старта — ежедневные — с субподрядчиком |
|
|
38 |
Риск наложения ввода 2-х проектов одновременно работа с ТСД и ФТО. Риск некорректной работы ПО для ТСД, используется не тиражное решение |
0,5 |
0,7 |
0,35 |
Предусмотреть в плане интеграционного теста этап проверки сопряжения с ТСД по всем функциям — ФТОПрогон по работе с ТСД всех кладовщиков на складе (еще до сопряжения с аксаптой) — субподрядчик |
|
|
39 |
Интеграционный риск (интеграция с кассами не будет работать корректно, в результате нарушается ключевой бизнес процесс розничных продаж) |
0,5 |
0,9 |
0,45 |
Предусмотреть в плане интеграционного теста этап проверки сопряжения кассами по всем функциям — ФТО |
|
|
40 |
Расширение рамок проекта в плане функционального объема (на интеграционном тесте) |
0,5 |
0,8 |
0,4 |
Анализ и распределение по степени критичности и необходимости внедрения к дате старта |
|
|
41 |
Риск проявления ошибок в ходе согласования процессов (недостаточная полнота или точность информации), которые приведут к неработоспособности процессов по факту |
0,5 |
0,8 |
0,4 |
Проведение интегротеста принимаемого функционала системы должно выполняться не только по выполненым модификациям, но и по стандартному функционалу ПО |
|
|
42 |
Функциональный риск — новый функционал резервирования продукции под существующие заказы. Может привести к путанице и снижению контроля за товарным объемом |
0,5 |
0,8 |
0,4 |
Предусмотреть в плане интеграционного теста детальную проверку функционала резервирования — ФТОПредоставить кейсы примеров по всем вариантам резервирования товаров — Заказчик |
|
|
43 |
Отсутствие утвержденной учетной политики и плана счетов может привести к изменениям относительно согласованного дизайна |
0,3 |
0,7 |
0,21 |
Детальное интервью со службой бухгалтерии |
|
|
44 |
Нарушение товародвижения (расхождения фактических остатков и движений по складу с операциями в системе) |
0,5 |
0,8 |
0,4 |
Только интеграционный тест, других вариантов нет. ФТО (качественный план) + Субподрядчик (выделение времени) |
|
|
45 |
Не укомплектован штат пользователей. Предварительно определено, что должно быть 2 человека в ночь, днём 1 + 1 по возвратам, + хотя бы один маршрутизаторщик |
0,4 |
0,7 |
0,28 |
Планирование человеческих ресурсов со стороны заказчика с учетом предварительных оценок по численности необходимого штата |
|
|
46 |
Некорректно будут сделаны настройки системы. В результате не будут проводиться документы или будут проводиться ошибочно |
0,5 |
0,5 |
0,25 |
Проверить корректность вводом документа каждого вида перед стартом |
|
|
47 |
Низкая производительность общей базы может повлечь проблемы с приемом заказов или на ночной отгрузке |
0,5 |
0,8 |
0,4 |
1) Делаем сравнительный анализ серверов (например, с наиболее загруженным филиалом) — ФТО2) Разводим сервер приложений и SQL сервер на разное «железо» — ИТ-служба заказчика3) В течение 2 месяцев после запуска запланирована покупка нового сервера — ИТ-служба заказчика |
Кроме определения перечня рисков с их оценкой и стратегией правильным будет также назначить ответственных за разрешение соответствующего риска, так как проектный менеджер не может быть владельцем всех рисков и отвечать за всех одновременно. Иначе у него не останется времени на то, чтобы в целом управлять проектом. Например, управление риском неохвата всего персонала заказчика для обучения в виду их отсутствия по различным причинам должно происходить на стороне заказчика путем назначения ответственных. Как вариант, руководителей подразделений в части организации своих сотрудников для прохождения обучения.
В процессе управления имеющимся списком рисков необходимо просчитывать возможность возникновения следующих или даже новых рисков и пополнять реестр рисков с расчетом стратегии по реагированию на них. То есть вести работу на опережение через просмотр на срабатывание риск-триггеров. Например, вероятность наступления риска ещё далека, но по некоторым сигналам можно определить, что ситуация нагнетается и риск может произойти раньше запланированного.
Ещё одной предупредительной мерой может быть наличие плана «С». Так или иначе при стратегии реагирования на риск всегда имеется как минимум план «А», а если что-то пошло не так, то выполняется план «В». Но в некоторых случаях можно предусмотреть также план «С», когда количество векторов развития событий высоко, и когда и план «А», и план «В» могут не так пойти или реакция на эти риски окажется не той, которую ожидали.
Правильное управление рисками – процесс достаточно интересный, но сложный. Он требует постоянного внимания проектного менеджера, регулярного развития у него соответствующих компетенций. Поэтому стоит отметить, что если не заниматься управлением рисками, то это приведет к срыву проекта и весьма отрицательно скажется на репутации компании.
В заключение хотелось бы сказать, что бороться с рисками бессмысленно, ими надо управлять.