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

Прежде чем выявлять риски, нужно договориться о правилах игры. Планирование определяет стратегию управления рисками проекта и фиксируется в плане управления рисками. В нём определяются:

• цели, границы и контекст: какие объекты, стадии жизненного цикла и категории рисков рассматриваются;
• шкалы оценки вероятности и последствий, матрица рисков;
• критерии риска — какой уровень допустим, а какой требует обязательной обработки («аппетит к риску»);
• роли и ответственность: кто владелец риска, кто принимает решения об обработке;
• периодичность пересмотра рисков и контрольные точки (ворота качества), на которых оценивается профиль рисков проекта;
• инструменты и форма ведения реестра рисков.

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

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

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

• анализ требований: нечёткие, противоречивые, нестабильные или трудно проверяемые требования — прямой источник технических рисков;
• анализ архитектуры: новые, не апробированные технологии, сложные интерфейсы, единичные точки отказа;
• анализ видов и последствий отказов (FMEA) и анализ дерева неисправностей (FTA);
• анализ опасностей (FHA, HAZOP, предварительный анализ опасностей);
• анализ цепочки поставок и производственных возможностей;
• база знаний «извлечённых уроков» (lessons learned) по предыдущим проектам.

Хорошая практика — единый формат описания риска, который отделяет причину от события и последствий:

«Если <причина / условие>, то <нежелательное событие>, что приведёт к <последствиям для целей проекта>».

Например: «Если тепловыделение драйвера окажется выше расчётного, то температура платы превысит допустимую, что приведёт к снижению ресурса изделия и невыполнению требования по сроку службы».

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

Цель анализа — понять природу риска и определить его уровень. Цель оценки — сравнить уровень риска с установленными критериями и определить приоритет обработки.

Для каждого риска оценивается вероятность события и тяжесть последствий. Самый распространённый инструмент — матрица рисков («вероятность — последствия»), которая наглядно показывает, какие риски требуют первоочередного внимания.

Пример матрицы рисков 5×5 с исходным и остаточным уровнем рисков (риски R1 и R2 описаны в примере ниже)

В зависимости от доступных данных используются разные методы анализа:

• качественные — экспертная оценка по шкалам, матрица рисков;
• полуколичественные — FMEA с расчётом приоритетного числа риска (ПЧР / RPN);
• количественные — анализ дерева неисправностей с расчётом вероятности, моделирование методом Монте-Карло для рисков по срокам и стоимости, анализ чувствительности.

Методы оценки систематизированы в ГОСТ Р 58771 (IEC 31010) «Менеджмент риска. Технологии оценки риска».

Для технических рисков оценка вероятности может и должна опираться не только на мнение экспертов, но и на результаты моделирования. Инженерный анализ и имитационное моделирование заменяют вопрос «насколько вероятно, что температура превысит допустимую?» расчётным значением с известным запасом.

Обработка — выбор и реализация мер, изменяющих риск. Основные стратегии:

• Уклонение — отказ от решения, порождающего риск (например, апробированная технология вместо новой).
• Снижение — уменьшение вероятности и/или последствий: дополнительные расчёты, макетирование, резервирование, раннее тестирование.
• Передача — передача риска другой стороне: страхование, контракт с поставщиком, гарантийные обязательства.
• Принятие — осознанное решение не предпринимать действий, с резервами времени и бюджета и наблюдением за риском.

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

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

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

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

• регулярные совещания по рискам и пересмотр реестра;
• профиль рисков проекта — распределение рисков по уровням и его динамика во времени;
• отчёты о статусе выполнения мер обработки;
• анализ рисков на воротах качества: переход на следующую стадию жизненного цикла допускается только при приемлемом профиле рисков.

Хороший индикатор эффективности — снижение суммарного уровня рисков по мере продвижения проекта: чем ближе к серийному производству, тем меньше неопределённости должно оставаться.

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

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

Риск связывается с требованием, невыполнение которого он описывает, а мера обработки — с новыми требованиями, которые она порождает. Это позволяет:

• видеть, какие требования находятся «под риском»;
• обосновывать проектные требования (например, требования безопасности) рисками, для снижения которых они введены;
• при изменении требования сразу получать перечень рисков, требующих пересмотра.

Подробнее — в практике «Инженерия требований».

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

С помощью MBSE-систем, например ЛОЦМАН:PLM Архитектурное проектирование, и инструментов оценки функциональной безопасности на ранних стадиях можно:

• выявлять риски, связанные с функциями и интерфейсами системы, до выбора конструктивных решений;
• выполнять FMEA и FTA на основе функциональной и физической архитектуры (модельно-ориентированный анализ безопасности, MBSA);
• сравнивать варианты архитектуры не только по характеристикам, но и по уровню риска (анализ компромиссов);
• выявлять единичные точки отказа и обосновывать решения по резервированию.

Поэтому определение архитектуры — важная часть ранней идентификации и анализа рисков. Подробнее — в практике «Архитектурное проектирование».

Управление рисками и верификация и валидация (ВВ) дополняют друг друга:

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

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

Подробнее — в практике «Верификация и валидация».

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

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

Подробнее — в практике «Управление конфигурацией».

1. Планирование. Утверждена матрица рисков 5×5. Риски с уровнем 15 и выше недопустимы, с уровнем от 10 до 14 требуют обязательной обработки. Реестр пересматривается раз в две недели и на каждых воротах качества.

2. Идентификация. По результатам анализа требований и архитектуры в реестр внесены риски:

• R1: «Если тепловыделение платы драйвера окажется выше расчётного, то температура в корпусе превысит допустимую, что приведёт к невыполнению требования по сроку службы 25 000 часов». Связан с требованием к сроку службы и компонентом HW-DRIVER-001.
• R2: «Если поставщик прекратит выпуск выбранного микроконтроллера, то производство будет остановлено, что приведёт к срыву сроков вывода изделия на рынок». Связан с компонентом HW-DRIVER-001 и прошивкой SW-FW-001.

3. Анализ и оценка. R1: вероятность 4, последствия 4, уровень 16 (критический). R2: вероятность 3, последствия 4, уровень 12 (высокий).

4. Обработка.

• R1 (снижение): выполнен тепловой расчёт в CAE-системе, по его результатам изменена топология платы и добавлен теплоотвод. В спецификацию добавлено проектное требование к максимальной температуре платы и запланирована процедура его верификации.
• R2 (снижение): заранее подобран и испытан аналог микроконтроллера от второго поставщика, подготовлен запрос на изменение. Когда микроконтроллер действительно сняли с производства, замену выполнили через процедуру управления изменениями без остановки производства (новая версия HW-DRIVER-002). В примере из практики управления конфигурацией это же событие стало неожиданностью — в этом и разница между реакцией на проблему и управлением риском.

5. Мониторинг. После расчётов и испытаний остаточный риск R1 оценён в 8 (средний), R2 — в 4 (низкий). Риски переведены в статус «на мониторинге». В PDM-системе видна связь каждого риска с требованиями, компонентами, расчётными моделями, протоколами испытаний и изменениями, которые обеспечили его снижение.