Риски — это неизбежная реальность любого бизнеса. Избежать их полностью практически никогда невозможно. Управление рисками строится на том, чтобы минимизировать вероятный ущерб и повысить эффективность деятельности компании. Алексей Александров, генеральный директор компании SEBEKON, рассказал «Бизнесологу», как управлять рисками в IT-проектах.
Новости бизнеса и подборка кейсов — в вашей почте:
var PS_ErrPref = ‘Поля не заполнены или заполнены неверно: n’;
Алексей Александров, генеральный директор компании SEBEKON, эксперт в области разработки сложных web-проектов.
— Шеф, я заболел. Работать в ближайшую неделю не смогу.
— Нет, договор на подключение эквайринга мы не заключили еще.
— А давайте сделаем так. Я точно не знаю как, но хочется попробовать.
— Ой, а начальник еще не согласовал дизайн. И вообще он сейчас в отпуске, вернется через две недели.
Онлайн-семинар «Управление рисками бизнес-процессов»
Знакомо? Все эти фразы — это иллюстрации рисков, которые возникают в любом it-проекте.
За всеми it-рисками, на наш взгляд, почти всегда стоят люди:
- кто-то переоценил себя и своих коллег и замахнулся на амбициозный проект, на которых не хватило сил и ресурсов;
- кто-то, наоборот, грамотно посчитал все ресурсы и замахнулся на масштабный проект, который по факту не нужен его компании на данном этапе развития;
- кто-то решил, что нашел грамотного исполнителя, который сделает все правильно без дополнительного участия заказчиков в проекте.
Если не классифицировать и не оценить риски на подготовительном этапе, то у заказчиков есть большая вероятность либо сильно затянуть сроки внедрения, либо вовсе не получить проект, а у подрядчиков — нарушить сроки или вовсе провалить проект и чувствительно ударить по репутации.
У опытных web-разработчиков есть уже перечень рисков, которые можно предотвратить на старте проекта. Причем для каждого нового проекта этот реестр будет индивидуален.
- Как мы управляем ИТ-рисками
- ИТ-риски и их классификация
- Недостаточная поддержка проекта со стороны заказчика
- Недостаточная поддержка со стороны пользователей ИТ-системы
- Несоответствие реализации бизнес-процессов в системе ожиданиям заказчика
- Расширение функциональных требований в процессе реализации проекта
- Недоступность членов рабочей группы
- Изменение состава рабочей группы
- Изменение бюджета и сроков проекта
- Несвоевременное предоставление необходимых документов со стороны заказчика
- Несвоевременное заключение договоров заказчиком со сторонними сервисами, получение тестовых и боевых доступов для интеграции
- Неполнота отражения ожидаемых результатов проекта
Как мы управляем ИТ-рисками
В нашей компании есть документ: таблица с описанием рисков, с которыми мы когда-либо сталкивались в своей практике. Она постоянно дополняется и расширяется. На ее основе для каждого нового проекта мы готовим отдельный документ по возможным рискам. Он содержит не только перечень рисков, но и их описание, способы его предотвращения и устранения последствий.
Управление Рисками в бизнес-анализе
Для некоторых заказчиков мы даже делали отдельные презентации по возможным рискам, но впоследствии отказались от этого. Некоторым такие меры могут показаться лишними: достаточно проговорить возможные риски в рамках очередной встречи заказчиков и подрядчиков. Однако в том, что касается рисков, лучше сделать как минимум отдельный документ, в котором зафиксировать все риски проекта и способы их минимизации.
ИТ-риски и их классификация
- По источнику риски бывают внутренние, т.е. происходящие внутри команды разработчиков, и внешние, зависящие от компании-заказчика.
- По степени влияния риски делятся на высокие, средние и низкие.
Рамки статьи не позволяют детально рассмотреть все существующие риски, поэтому мы выбрали из своей практики пример проекта по разработке CRM-системы.
На начальном этапе мы сформировали список возможных рисков, оценили их по степени влияния, описали и составили рекомендации по уменьшению и/или преодолению риска.
1. Недостаточная поддержка проекта со стороны заказчика
Степень риска: низкая.
Недостаточный опыт управления и низкий уровень знаний специфики бизнеса могут привести к задержке решения ключевых вопросов о планировании работ, выделении ресурсов, приемки конечных результатов проекта.
Чтобы уменьшить риск, необходимо:
- предоставить руководителю проекта необходимые полномочия;
- привлечь в рабочую группу (далее: РГ) экспертов с необходимыми для проекта компетенциями.
Качества хорошего руководителя: деловые, личностные, профессиональные
Многие заказчики полагают, что их финансового участия в проекте достаточно. Часто на роль руководителя проекта по созданию сайта со стороны клиента, например, в среднем сегменте, назначают менеджера по продажам. Логика простая: он умеет продавать, значит разберется и в разработке интернет-магазина. Между тем, этот менеджер не обязан знать отличия офлайн- и онлайн-поведения покупателя. Безусловно, у него есть свои представления о хорошем интернет-магазине, но они могут расходиться с бизнес-задачами компании в целом.
И вот под его руководством сделали дизайн, сверстали, напрограммировали. Он посмотрел, не вник, но работу принял. А потом оказывается, что все работает не так, как задумывалось: первый же заказ не попал туда, куда нужно, или попал, но по другому сценарию и т.д.
Чаще всего такого рода риски возникают в небольших компаниях либо в огромных госпредприятиях (например, в вузе в рабочую группу по разработке сайта могут включить преподавателей, которые в принципе плохо понимают, зачем нужен сайт). Чем крупнее компания, тем больше шансов, что у нее есть IT-отдел, который будет заниматься проектом.
2. Недостаточная поддержка со стороны пользователей ИТ-системы
Степень риска: средняя.
Поддержка со стороны пользователей системы крайне важна для успеха проекта. В противном случае возможно увеличение стоимости / продолжительности проекта, неполное / неправильное понимание требований заказчика.
Завтра ваш интернет-магазин может закрыться!
Чтобы уменьшить риск, необходимо:
- дать четкие указания, касающиеся поддержки проекта, подготовить и провести собрание, подготовить приказ или иной документ, в котором будут зафиксированы эти указания;
- контролировать участие сотрудников компании-заказчика в проекте;
- провести обучение сотрудников компании-заказчика;
- передать промежуточную версию системы сотрудникам для тестирования.
В среднем в проекте бывает 5-6 итераций. Если пренебречь последним пунктом, то подрядчик может допустить ошибки, которые фатальным образом скажутся на функционировании всей системы.
3. Несоответствие реализации бизнес-процессов в системе ожиданиям заказчика
Степень риска: низкая.
Недопонимание бизнес-процессов заказчика подрядчиком может привести к несоответствию реализованной системы ожиданиям заказчика.
Для преодоления данного риска необходимо:
- согласовать протоколы встреч с участниками со стороны заказчика.
- настроить и провести показ прототипов системы для детализации требований.
4. Расширение функциональных требований в процессе реализации проекта
Степень риска: средняя.
Расширение функциональных требований к системе после завершения первого этапа приведет к увеличению сроков и бюджета ИТ-проекта. Риск в том, что часть уже сделанных работ может оказаться лишней из-за изменения архитектуры решения.
Чтобы уменьшить риск, необходимо:
- ответственно относиться к выработке требований к системе на подготовительных этапах и согласованию итоговых документов;
Под ответственностью понимается взвешенное отношение к формированию технического задания. Так, лучше сделать минимальный функционал и потом его дорабатывать, чем сразу нагородить множество функций и на этапе тестирования понять, что половина из них лишние.
- привлечь ключевых пользователей будущего решения к обсуждению и согласованию формулировок на начальных этапах.
Для преодоления риска следует обсудить расширения и после этого принять одно из решений:
- пересмотреть согласованные рамки текущего этапа проекта — добавить недостающие этапы работ, если их действительно необходимо провести;
- включить эти этапы в дополнительное соглашение по следующему этапу проекта либо в договор сопровождения;
- отказаться от расширительных требований и продолжить работу в рамках ранее утвержденного перечня работ.
5. Недоступность членов рабочей группы
Степень риска: низкая.
Физическое отсутствие одного или нескольких членов РГ может привести к задержке решения вопросов по проекту и к увеличению сроков проекта.
Геймификация в управлении персоналом: обучение, адаптация, мотивация
Чтобы уменьшить риск или полностью его преодолеть, необходимо заранее планировать встречи с учётом отпусков и командировок, а также назначить заместителей.
6. Изменение состава рабочей группы
Степень риска: средняя.
Смена участников РГ в ходе проекта может привести к нарушению сроков и низкому качеству работ.
Чтобы уменьшить риск, необходимо:
- заранее планировать встречи с учетом отпусков и командировок;
- мотивировать участников проекта сохранять состав РГ в неизменном виде.
Для преодоления риска необходимо:
- привлечь дополнительных сотрудников из компании при изменении состава РГ для помощи в работе новому участнику;
- скорректировать состав работ, выходных результатов или рамок текущего этапа, если невозможно быстро решить вопросы замены участника РГ;
- скорректировать сроки выполнения работ, если невозможно изменить рамки проекта.
Этот риск может возникнуть как на стороне заказчика, так и на стороне исполнителя. Новым участникам рабочей группы необходимо время для того, чтобы вникнуть в ход проекта. Как правило, в таких случаях времени обычно не бывает. Новому разработчику нужно пересмотреть все, что было сделано до него. Новому руководителю проекта нужно прочитать множество документов, протоколов встреч, наладить контакт со всеми участниками и т.д.
Для подрядчика этот риск связан с рисками 8 и 9. Например, заказчик не предоставил нужные документы иили доступы к сторонним сервисам. Руководитель проекта перебрасывает разработчиков на другой проект, чтобы у них не было простоя в работе. В итоге, когда доступы получены, разработчики могут быть еще заняты на другом проекте. И тут заказчику либо приходится ждать, когда они освободятся, либо опять ждать, когда другие разработчики вникнут в проект.
7. Изменение бюджета и сроков проекта
Степень риска: низкая.
Неопределенность объемов и сроков финансирования проекта может привести к затруднениям при планировании и использовании необходимых ресурсов. в итоге проект может быть затянут. Несоблюдение графика платежей может стать причиной задержки проекта, вплоть до прекращения работ.
Как составить финансовый план для бизнес-плана — подробная инструкция
Чтобы уменьшить риск, необходимо:
- согласовать и утвердить бюджет всего проекта, график платежей;
- соблюдать график платежей;
- своевременно проинформировать стороны, вовлеченные в проект, в случае нарушения графика платежей и выработать общее решение вопроса задержки платежа;
- соблюдать график сдачи работ по проекту;
- определить порядок действий при нарушении сроков платежей или сдачи работ
Для преодоления риска необходимо своевременно провести встречи со всеми сторонами и выработать согласованный план действий:
- сдвиг плана проекта;
- уменьшение объема работ;
- перенос работ на другой этап и т.д.
8. Несвоевременное предоставление необходимых документов со стороны заказчика
Степень риска: низкая.
В случае несвоевременного предоставления заказчиком документов, необходимых для реализации проекта, возможен сдвиг сроков реализации этапа ТЗ и проекта в целом.
Чтобы уменьшить риск, необходимо:
- заранее сформировать запрос на предоставление документов в начале разработки ТЗ;
- составить график предоставления документов;
- включить данные по статусу получения документов в отчет по проекту.
Для преодоления риска следует скорректировать план проекта, перенести работы по на более позднее время.
9. Несвоевременное заключение договоров заказчиком со сторонними сервисами, получение тестовых и боевых доступов для интеграции
Степень риска: средняя.
В случае несвоевременного предоставления заказчиком тестовых / боевых доступов к сторонним сервисам, необходимым для реализации проекта, возможен сдвиг сроков запуска.
Чтобы уменьшить риск, необходимо:
- сформировать запрос на предоставление доступов в процессе разработки ТЗ;
- составить график предоставления доступов;
- включить данные по статусу предоставления доступов в отчет по проекту.
Для преодоления риска необходимо скорректировать план проекта, перенести работы на более позднее время.
Несмотря на то, что на каждом проекте мы фиксируем возможные риски и просим заранее организовать все регистрации, доступы и договоры со сторонними сервисами, все равно часто случаются простои из-за несвоевременного заключения договоров. При этом мы со своей стороны для избежания простоев разработчиков можем перекинуть их на других проекты, с которых потом не всегда оперативно можем вернуть их обратно.
10. Неполнота отражения ожидаемых результатов проекта
Степень риска: средняя.
Решения, проговоренные устно на рабочих встречах, могут быть не зафиксированы документально.
Чтобы уменьшить риск необходимо:
- документировать все существенные результаты встреч и совещаний в протоколах или иных документах;
- согласовывать в письменной форме протоколы встреч со всеми участниками.
Для преодоления риска необходимо оперативно добавить новую утвержденную и согласованную информацию во все исходные документы и устранить все разногласия.
Однажды менеджер одного из наших проектов передал его на тестирование заказчику. Во время тестирования вылезли ошибки. Менеджер со стороны заказчика позвонил нашему менеджеру и перечислил, что нужно поправить. Наш менеджер передал все разработчикам для исправления. Ошибки были устранены, сайт заработал как надо.
Наш менеджер выставил счет на оплату проведенных работ. В компании-заказчике эта сумма не была согласована внутри и стала неприятным сюрпризом. Дальше была череда изматывающих встреч, в ходе которых мы со своей стороны доказывали свою правоту и отстаивали стоимость работ, заказчики пытались уйти от оплаты без договора. В итоге для нас все закончилось благополучно, но нервов было потрачено много. Зато теперь мы на каждую работу, не прописанную в основном договоре делаем дополнительное соглашение и не приступаем к реализации работ до подтверждения со стороны заказчиков.
Как правильно составить договор — рекомендации юриста
Список рисков можно продолжать бесконечно. И все они, как правило, взаимосвязаны друг с другом. Для наглядности мы собрали в схему описанные выше риски и стрелками показали их зависимости друг от друга. Помните, что даже риск, оставленный без внимания, тянет за собой как минимум еще один.
Источник: businessolog.ru
Управление рисками проекта
Проект внедрения программного продукта 1С представляет собой сложный процесс, в котором присутствуют и технологические, и интеллектуальные ресурсы как заказчика и исполнителя, так и внешних консультантов, партнеров, соисполнителей. Процесс внедрения системы автоматизации чаще всего связан с высоким уровнем рисков, носящих организационный и технологический характер.
В настоящей статье мы рассмотрим основные практические моменты по управлению рисками проекта внедрения программного обеспечения, которые могут возникнуть.
РИСКИ ПРОЕКТА НА ЭТАПАХ ЖИЗНЕННОГО ЦИКЛА
Жизненный цикл проекта по внедрению программ 1С состоит из нескольких этапов, на каждом из которых присутствуют свои риски. Также существуют общие риски всего проекта.
К общим проектным рискам обычно относятся:
- риски в виде отсутствия поддержки со стороны руководства заказчика;
- отсутствие четкого разделения ответственности между проектными командами заказчика и исполнителя, а также внутри самой проектной команды;
- недостаток времени у проектной команды заказчика в связи с выполнением текущих функциональных обязанностей;
- отсутствие соответствующей компетенции у персонала;
- предоставление неполноценной или несогласованной информации;
- недоступность технической информации для исполнителя и прочее.
На этапе продажи проекта внедрения системы 1С существенным риском является ошибка в оценке затрат на реализацию проекта. Это связано с ценообразованием, которое в первую очередь строится исходя из высокой конкуренции между исполнителями.
И некорректная оценка затрат на проект напрямую связана с тем, что на этом этапе заказчик ещё не может полноценно определить или сформулировать требования к внедряемому программному продукту. Как следствие, технические специалисты исполнителя не могут детализировано провести оценку проектных работ. А менеджер по продажам, преследуя цель получения проекта может занизить экспертную оценку в угоду оптимистичной оценке предстоящего проекта. Как следствие неверная оценка затрат проекта приводит к негативным последствиям для всего проекта, включая его срыв.
На предпроектном обследовании системы и формализации требований выполняется интервьюирование специалистов заказчика с целью сбора и категоризации основных требований ключевых пользователей системы 1С. Обычно в этом процессе участвуют специалисты заказчика нескольких организационных подразделений, что являет собой различные взгляды, как на цели и задачи проекта, так и на некоторые нюансы автоматизации бизнес-процессов. Результатом разобщенности во взглядах на данном этапе может стать общая неудовлетворенность во внедренной информационной системе, затягивание периода опытной эксплуатации и существенный поток замечаний и претензий в адрес исполнителя.
На этапе проектирования и разработки осуществляется проработка архитектуры системы в целом, а также некоторых её модулей. На этом этапе велики технологические риски, связанные с ошибкой решения в части архитектуры информационной системы или неполной проработкой отдельных модулей и/или взаимосвязей между ними, неучтенными нефункциональными требованиями, такими как отклик системы на действия пользователя, надежность данных, их масштаб и технические возможности оборудования заказчика и т.п. Критичным является то, что выявление этих рисков происходит в достаточно поздние сроки, например на стадии опытной эксплуатации или эксплуатации на реальных данных реальными пользователями 1С. Это приводит к необходимости экстренного выполнения доработок или даже возможного срыва проекта в целом в силу непригодности системы к реальной и полноценной эксплуатации.
Как правило, этот этап является самым длительным, и основная причина появления рисков в процессе разработки – это недостаточный анализ требований или неоднозначная их трактовка, что приводит к тому, что результат не соответствует ожиданиям представителей заказчика.
При внедрении информационной базы довольно часто исполнителю приходится сталкиваться с непринятием сотрудниками заказчика обновленного функционала системы, её пользовательского интерфейса и т.п. Если не контролировать этот риск, то он может перерасти в открытый саботаж пользователями новой системы. Также ситуация может усугубляться неподготовленностью информационной инфраструктуры заказчика к внедрению программного обеспечения, что является причиной срывов сроков проекта и необходимостью доработки или адаптации программного обеспечения за счет увеличения бюджета проекта.
На стадии завершения проекта и поддержки пользователей в период опытно-промышленной эксплуатации системы очень часто встречается риск, обусловленный отсутствием службы поддержки со стороны заказчика или её некомпетентности из-за отсутствия навыков по работе с новой конфигурацией системы. Это приводит к тому, что ликвидация сбоев системы становится неоперативной или поддержка конечных пользователей не является комплексной и полноценной.
РИСК-МЕНЕДЖМЕНТ ПРОЕКТА
Если проектный менеджер (как со стороны исполнителя, так и со стороны заказчика) не видит преград в реализации проекта, то в большинстве случаев это говорит о том, что он скорее всего не потрудился на старте их поискать и придумать как с ними лучше всего разобраться.
А риски в итоге возникают (это неизбежно) и приходится их в суете решать. Но ведь можно это сделать заранее и спокойно, до старта проекта.
В проектном управлении существует такое понятие, как «риск-менеджмент». Но нужно понимать, что риск-менеджмент – это не только составление и просчет рисков проекта на определенных его этапы. Риск-менеджмент – это спокойная, без истерик и суеты, сенсорика и разрешение проектному менеджеру думать о том, что что-то пойдет не так.
Управление рисками проекта можно разделить на 3 части:
- Идентификация, анализ и оценка рисков проекта
- Определение мероприятий по управлению рисками
- Контроль и мониторинг рисков проекта
Но простого разделения на части процесса управления рисками недостаточно, ведь управление рисками имеет под собой некую цикличность, когда в зависимости от возникающих изменений требуется выполнять одни и те же процессы управления:
При определении рисков необходимо исходить не только из методологии определения и расчета рисков, но и из опыта реальных проектов внедрения программ 1С, имеющейся базы знаний, областей деятельности компании, в которой реализуется проект. Требуется участие не только исполнителя, который определит основные существующие риски проекта внедрения, но и заказчика, который заложит риски в виду нюансов и особенностей ведения деятельности компании.
Перед стартом проекта проводится работа по идентификации возможных и существующих рисков. Процесс идентификации представляет собой поиск всех возможных рисков, по итогам которого мы должны найти ответы на вопрос: «Что может пойти не так?» (для негативных рисков). Но при поиске ответов на вопрос: «Что может пойти не по плану?» можно найти и позитивные риски.
При планировании рисков следует учитывать, что большим количеством рисков одновременно и качественно управлять невозможно, поэтому цель качественного анализа рисков проектов состоит в группировке и расстановке приоритетов.
Оценка рисков проекта и идентификация проводится для составления плана реагирования на риски. Оптимально управлять одновременно не более 10 рисками.
Этот этап является одним из сложных, так как принятые решения по ликвидации или снижению рисков затрагивают основные составляющие управления проектом: объем, бюджет и сроки проекта. То есть необходимо учитывать тройное ограничение проекта:
Такое ограничение говорит о том, что, как и у треугольника, нельзя изменить одну сторону, не задев как минимум ещё одну. Изменение одного параметра управления проектом влияет и на другие параметры.
Поэтому процесс контроля и мониторинга рисков ориентирован на оценку текущей ситуации по проекту: управление рисками, анализ возникших отклонений, контроль изменений и их влияния на все параметры проекта.
При выборе стратегии управления рисками проекта необходимо учитывать понятие о риске проекта. Риск проекта – это неопределенное событие, которое в случае его возникновения имеет негативное или позитивное воздействие как минимум на один из параметров проекта (например, срок или бюджет проекта).
Исходя из логики определения риска проектов можно выделить следующее:
- Риск имеет как негативную, так и позитивную сторону. Дело в том, что при переводе с английского слово «риск» имеет значение «шанс».
- Риск – это неопределенное событие, то есть событие, которое может произойти или нет с некоторой вероятностью. Таким образом мы должны понимать, что событие не считается риском, если мы точно знаем, произойдет оно или нет.
- Риск влияет на проект. То есть если какое-то событие (например, засуха на другом материке) не влияет на цели и параметры проекта, то это не является риском.
- Любой риск имеет два обязательных параметра: влияние и вероятность возникновения.
При расчетах величины риска значения влияния и вероятности возникновения определяются по шкале от 0 до 1:
0 – известно, что событие определенно не произойдет
1 – известно, что событие определенно произойдет.
0 и 1 – это крайние значения, которые не должны учитываться в оценке, так как риск имеет под собой вероятностную природу. Например, если что-то точно произойдет, то это уже не риск, а состоявшееся событие, то есть свершившийся факт. Следовательно, в таком случае необходимо управлять не риском, а изменениями, которые на это событие повлияли.
В процессе расчета величин риска определяются стратегии ликвидации рисков. При этом можно использовать следующие мероприятия по реагированию на риски:
- Уклонение от риска предполагает корректировку плана управления проектом так, чтобы максимально исключить угрозу негативного риска, а также снизить последствия риска для целей проекта (например, пересмотреть график проекта или изменить объемы путем исключения некритичных модификаций). Важно заметить, что некоторых рисков можно избежать, если на ранних стадиях проекта детализировано собирать требования заказчика, налаживать более приятные коммуникации.
- Передача риска осуществляется путем переложения негативных последствий риска под ответственность третьей стороны. При этом необходимо понимать, что при передаче управления риском третьей стороне сам риск не снимается. Такая стратегия управления риском эффективна в части финансовых рисков. Например, страхование, гарантии выполнения контракта, выдача гарантийных обязательств и т.п. Естественно, что условия передачи рисков третьей стороне несут в себе обязательства по выплате премии за риск третьей стороне. Если проект подразумевает оплату фактических издержек заказчиком, то бремя выплаты премии может быть переложено на заказчика, а вот с фиксированной ценой контракта это бремя обычно ложится уже на исполнителя.
- Снижение риска предполагает уменьшение вероятности и/или последствий рискованного события до необходимых пределов. То есть стратегия состоит в формировании предупредительных мер по снижению вероятности негативного события или последствий его наступления, т.к. предупреждение всегда эффективнее, чем разрешение последствий свершившегося факта. Как пример снижения риска можно привести работу по планированию человеческих ресурсов как на стороне заказчика (бизнес-эксперты, ключевые пользователи), так и на стороне исполнителя (консультанты, разработчики) в случаях их болезни, отпуска или увольнения. Как предупредительная мера может использоваться оптимизация сложных процессов за счет их упрощения (исключить неактуальные действия или пересмотреть схему движения бизнес-процесса), увеличение количества тестовых испытаний на реальных данных с активным участием пользователей, выполняющих соответствующие функциональные обязанности и прочее.
- Использование риска выбирается в качестве стратегии реагирования на благоприятные последствия случившегося события. Примером использования может служить возникновение возможности по привлечению специалиста более высокого уровня с целью сокращения времени на реализацию определенных задач проекта. Также примером является отказ от модификации в пользу использования стандартного функционала системы в виду изменения методологии бизнес-процесса.
- Усиление через позитивное воздействие на складывающуюся ситуацию позволит повлиять на условия формирования события в положительном ключе. Один из примеров реагирования на такой положительный риск – это привлечение специалиста со стороны заказчика, находящегося на более высоком уровне принятия решений по проекту, в случае каких-то согласований задач по модификациям.
Результатом работ по определению стратегий нивелирования рисков должен явиться план по управлению рисками (он же реестр рисков). Данный реестр относится к проектной документации, и его актуализация производится на протяжении всего жизненного цикла проекта за счет мониторинга и контроля рисков.
В данном реестре рисков кроме перечня возможных рисков определяется, как данный риск влияет на проект, учитывается величина риска по вероятности наступления и степени его влияния и определяются мероприятия (стратегия) по управлению этим риском.
Пример реестра рисков:
Потенц. воздействие на проект
Источник: habr.com
20 бизнес-рисков, о которых всегда нужно помнить руководству компании
В период пандемии или различных форс-мажоров бизнесу нужно помнить и просчитывать всевозможные риски. Риск — это потенциальная проблема. Риск может реализоваться или нет, но вести бизнес и не думать о рисках — это как лезть по скалам без страховки.
Бизнес-риски угрожают компании провалом в достижении бизнес-целей. Менеджмент разрабатывает планы, работает с продуктом, пытается удержать показатель рентабельности, а если вдруг все усилия идут насмарку — реализовался риск. Но если знать, откуда и какой опасности ожидать, можно удержать показатели в желаемых пределах. В SWOT-анализе бизнеса риски закладываются в блок угрозы.
И если жизнь на планете Земля протекает благоприятно этих рисков будет мало, а при текущей ситуации рисков для бизнеса предостаточно. Предлагаю Вам ознакомиться с 20 бизнес-рисками, на которые сегодня стоит обратить внимание в первую очередь.
Если вы знаете другие риски, то напишите их, пожалуйста, в комментариях.
1. Риск потерять конкурентные преимущества
В отраслях, где существует серьезная конкуренция, может случиться ситуация, когда компания теряет конкурентные преимущества. Например, на рынок выходит новый продукт, имеющий гораздо лучше потребительские свойства, чем тот, что предлагаете вы. Или другая фирма получила возможность значительно сократить расходы на производство. Для того, чтобы уменьшить эту угрозу, всегда наблюдайте за рынком, крупнейшими конкурентами, технологическим развитием в отрасли. Прорыв, произошедший в конкурентном окружении, не должно неожиданностью.
2. Экономический риск
Это изменения в экономике, которые могут привести к падению продаж или увеличению расходов компании. Есть большое количество инструментов, которые уменьшают последствия наступления следующих рисков: от диверсификации бизнеса с выходом за пределы одного государства и монопродукта к фиксации контрактных цен на долгосрочной основе. Некоторым экономическим рискам невозможно противостоять, но это не значит, что их можно игнорировать.
3. Операционный риск
Предположим, экскаваторщик на соседнем участке во время работы разорвал линию связи. Компания мгновенно лишилась потока входящих звонков и интернета. Даже один день без клиентов — это существенная потеря дохода, поэтому необходимо задуматься о налаживании резервных или альтернативных рабочих процессов.
4. Правовой риск
То, что сегодня находится в рамках закона, назавтра может стать преступлением — и наоборот. Изменения в правовом поле несут большие угрозы, но часто бывают прогнозируемыми: законодательный процесс в большинстве государств — медленное дело. Поэтому юридический отдел должен отслеживать изменения в государственных актах, которые могут влиять на деятельность компании. А в странах, где правовая ситуация плохо прогнозируема, необходима дополнительная бдительность, максимальное упрощение операций или даже сокращение присутствия на рынке.
5. Риск несоответствия требованиям законодательства