MAN.5 Risk Management 風險管理
ASPICE 標準解讀: 管理流程
目錄: Automotive SPICE(ASPICE)標準解讀 / 管理流程MAN: 管理流程概述
MAN.3 專案管理
MAN.5 風險管理
流程目的(Process Purpose)
The purpose of the Risk Management Process is to identify, analyze, treat and monitor the risks continuously.
風險管理流程的目的是持續地識別、分析、處理和監測(專案中的)風險。
流程結果(Process Outcome)
成功實作風險管理流程，其相應的結果如下：[Outcome 1]確認要執行風險管理的範圍；[Outcome 2]定義且執行適當的風險管理策略；[Outcome 3]識別在專案執行過程中的風險；[Outcome 4]分析風險並確認用於處理這些風險資源的優先順序；[Outcome 5]定義、應用和評估風險措施，以確定風險狀態的改變及處理(風險)活動的進展；[Outcome 6]根據風險的優先順序、發生概率、影響後果或已定義的風險接受水平，採取適當的措施來修正或避免風險的影響；
基礎實踐(Base Practices)
MAN.5.BP1: Establish risk management scope.
MAN.5.BP1: 建立風險管理範圍[Outcome 1]
Determine the scope of risk management to be performed for the project, in accordance with organizational risk management policies.
根據組織(公司)的風險管理政策，確定要對該專案執行的風險管理範圍
NOTE 1: Risks may include technical, economic and timing risks.
備註1: 風險可包含技術、經濟和時間風險
額外說明 -- 風險的管理範圍 - 專案前期ASPICE的專案風險可以額外考量ISO 26262及ISO/SAE 21434所識別的風險。由於風險管理的範圍涉及多份標準，及在整個專案生命週期中，因此在進行實際的風險管理之前，必須要訂定風險的範圍。如下圖所示，為整合功能安全與網通安全的專案前期的風險管理範圍。圖中紅色打星處為風險評鑑的起始點，亦為整個專案風險的管理範圍起始點。
- 網通安全的風險: 以威脅(Threat)為主要觀點出發，從TARA(Threat Analysis and Risk Assessment)開始進行可能的外部威脅分析。
- 專案的風險: 以技術、經濟、時間等觀點出發，從可行性分析(Feasibility Study)開始進行可能的專案風險分析。
- 功能安全的風險: 以危害(Hazard)為主要觀點出發，從HARA(Hazard Analysis and Risk Assessment)針對情境、環境、傷害、可控性等面向進行危害分析。
額外說明 -- 風險的管理範圍 - 專案生命週期(過程中)專案執行中，亦可能有許多可能的風險，風險管理策略需要在專案開始時，定義所有可能的範圍，以免無止盡的發散；如下圖所示為，專案過程中，不同流程可能會有的風險，這些風險亦考量到功能安全與網通安全。
—
MAN.5.BP2: Define risk management strategies.
MAN.5.BP2: 定義風險管理策略[Outcome 2]
Define appropriate strategies to identify risks, mitigate risks and set acceptability levels for each risk or set of risks, both at the project and organizational level.
定義適當的策略，並在專案和組織(公司)層級進行以下：
- 針對各別風險(或一組風險)制定風險接受水平
- 識別風險
- 減輕風險
額外說明 -- 風險分析法語風險接受水平最常見的風險分析法，將分析風險的可能概率(Occurence)及影響(Impact)。如下圖所示為，為專案管理流程的時程風險領域的可能概率(左)與影響(上)的參考定義。將這兩者合併所產生的風險矩陣(Risk Matrix)定義如右下角。假設，風險接受水平定義為「小於等於5是可接受的風險」，那麼在此風險矩陣中，橘色與紅色兩種顏色就為不可接受的風險，必須進一步制定減輕風險的措施。上所述為一般的風險分析法，讀者若有興趣，請參考備註5所提到的其他分析法。值得一提的是不同的風險領域，都可以有自己的定義，因此根據所採用的方法、所評鑑的流程和風險領域，都有很多不同的定義。例如：在網通安全(Cybersecurity)中，就必須會針對威脅攻擊經過的時間(Elasped Time)、攻擊者的經驗(Expertise)、攻擊者的對於所攻擊系統的知識(Knowledge of the system)、時機(Window of opportunity)、設備(Equipment)等綜合評鑑出攻擊的潛在可能。
額外說明 -- 風險管理策略常見的風險管理策略，必須是根據組織(公司)層級的政策，訂定專案的風險接受水平，並在風險管理範圍(專案前、中、後)，進行風險的識別，而後根據風險的狀態決定風險處置方法；常見的風險處置方法如下：1. 避免風險(Avoid): 避免永遠是第一步，任何降低風險的手段都不及避免風險，因此，如果風險可以被避免，當採用風險避免的策略。例如：現有的設計存在功能失效的風險，實務風險處置策略是透過採用其他的方法來實現原有的需求功能。2. 風險轉移(Transfer): 如果風險無法被避免，則採用轉移的方式來進行，常見的轉移方法有兩個，其一是「流程轉移」，例如:外包、採購；其二是「結果轉移」，例如:保險。例如: 當被要求要採用AUTOSAR架構時，為了降低專案實作的風險，透過AUTOSAR基礎軟體架構的採購，來轉移這個部分的風險。3. 風險減輕(Mitigation): 如果上述兩個方法都無法採用，那麼就需要進一步降低風險，常見減輕風險的方法，可以針對降低可能性來或減輕後果的影響。例如: 現有的電路設計存在隨機失效的可能，當失效發生可能導致功能失效，那麼針對降低可能性的作法是增添一組相同功能的電路配置，當第一組電路發生失效，仍然有第二組的電路可以持續實現功能；針對後果影響的減輕可以是實作當功能失效時的額外防護功能。4. 風險接受(Acceptance): 當風險低於可接受水平，那麼便可以採用接受風險。
—
MAN.5.BP3: Identify risks.
MAN.5.BP3: 識別風險[Outcome 2,3]
Identify risks to the project both initially within the project strategy and as they develop during the conduct of the project, continuously looking for risk factors at any occurrence of technical or managerial decisions.
識別在專案策略初期及專案執行期間的專案風險，並持續在技術或管理決策等任何過程中尋找風險因素。
額外說明 -- 何時該識別風險？基本上這個問題，可以先來討論風險分析的本質；風險本身可以區分成高階風險分析，及細部分險分析。高階風險分析，如BP1的「專案前期的風險」圖示，最好的啟動時機是在開案前，針對專案的可行性進行風險的分析，如果該案牽涉功能安全或網通安全，則亦可進行以危害(Hazard)為出發點的危害風險分析，及以威脅(Threat)為出發點的威脅風險分析。上述三種分析，都是屬於高階風險分析，其分析的結果將有助於決定案子的啟動與否，並在專案前期，根據風險分析結果，定義相關的目標或需求。至於細部的風險分析，則要用到備註2及備註3所提到的風險領域及風險因素，讀者也可以參照BP1所提到的「專案過程中的可能風險分布」圖示，其中風險領域又可再以流程底下的主題來進行細分，每一個子題都可能存在潛在的風險。細部風險分析是隨著專案推移而改變的，因此也需要定期的重新識別。一般會以專案的里程碑做為一個重新識別的起始點，在里程碑當下重新的檢視現有的風險，將已經結束(不會再發生)的風險剔除，並識別接下來會出現的風險。--
額外說明 -- 怎麼做風險識別？一般來說，在開案前會先整理出一份組織(公司)針對專案統計的風險清單，該清單條列各種風險領域的可能風險因素，專案團隊可以使用這份清單進行風險識別。當專案出現識別出新的風險，亦可以將之納入此清單，做為後續專案執行時的參照。
NOTE 2: Examples of risk areas that are typically analyzed for potential risk reasons or risks factors include: cost, schedule, effort, resource, and technical.
NOTE 3: Examples of risk factors may include: unsolved and solved trade-offs, decisions of not implementing a project feature, design changes, lack of expected resources.備註2: 風險領域是被用來分析潛在風險原因或風險因素，其範例包含：成本、時程、工作量、資源和技術
備註3: 風險因素的範例可包含: 未解決和解決的代價、不實作專案功能的決策、設計變更、缺乏預期資源。
額外說明 -- 風險領域與風險因素風險領域指的是可能會出現風險的主題，這個主題可能是各種流程，或是流程中的細節，例如：專案管理流程中的成本、時程、工作量；或系統工程流程中的技術等領域。風險因素指的是風險事件本身。專案中可能會存在多種的風險領域，從不同的風險領域中都可以分析出潛在的風險原因或風險因素，例如：在專案管理流程中的成本領域，其潛在的風險可能是經費不足、或專案花費超支、等；在系統工程流程的技術領域，其風險因素則可能是技術不熟悉、技術複雜度過高。
—
MAN.5.BP4: Analyze risks.
MAN.5.BP4: 分析風險[Outcome 4]
Analyze risks to determine the priority in which to apply resources to mitigate these risks.
分析風險，以確定導入資源來減輕這些風險的優先順序。
NOTE 4: Risks are normally analyzed to determine their probability, consequence and severity.
NOTE 5: Different techniques may be used to analyze a system in order to understand if risks exist, for example, functional analysis, simulation, FMEA, FTA etc.備註4: 通常對風險進行分析以確定其可能性、後果和嚴重性。
備註5: 可以應用不同的技術來執行系統分析，以確認風險是否存在。例如：功能分析、模擬、失效模式與影響分析(Failure Mode and Effects Analysis，簡稱FMEA)、FMEA、故障樹分析(Fault Tree Analysis, 簡稱FTA)、等。
額外說明 -- 其他確認風險的技術除了上述提到的幾種技術方法外，失效模式影響和診斷分析(Failure Modes Effects and Diagnostic Analysis，簡稱FMEDA)，威脅模型(Threat Modeling)，攻擊路徑分析(Attack path analysis)等。
—
MAN.5.BP5: Define risk treatment actions.
MAN.5.BP5: 定義風險處置行動[Outcome 5,6]
For each risk (or set of risks) define, perform and track the selected actions to keep/reduce the risks to acceptable level.
針對各別風險(或一組風險)定義、執行和追蹤所選擇的行動，以保持/降低風險至可接受的水平。
額外說明 -- 針對每個風險都要定義處置行動嗎？這個問題需要回到BP2的定義，必須要確認各別風險是否超過可接受的風險水平，如果超過才需要進一步的規劃處置行動。--
額外說明 -- 降低風險至可接受風險接受水平風險是尚未發生的問題，因此面對風險，並非將其完全消除，而是要將低到可接受的範圍內。為何不能完全消除？因為，如果要將其完全消除，那麼付出的代價將會非常的大。例子：為了預防電路的隨機失效，增加了另外一組的電路配置。但儘管如此，多配置的一組店路亦有可能發生隨機失效，為此，如果還要再增添第三組的電路配置，又會有延伸的兩個問題，其一，多增加的成本是否符合效益？其二，如果第三組電路又有失效的可能，那麼是不是又要無限上綱的增加電路配置。風險不可能完全消除，只能將其降低到可接受的範圍。同上範例，儘管一組電路可能會有隨機失效的風險，但是基於成本考量，這個風險如果在風險接受水平內，一般公司也不會再多做其他的調整改善。
—
MAN5.BP6: Monitor risks.
MAN5.BP6: 監控風險[Outcome 5,6]
For each risk (or set of risks) define measures (e.g. metrics) to determine changes in the status of a risk and to evaluate the progress of the mitigation activities. Apply and assess these risk measures.
針對各別風險(或一組風險)定義量測措施(例如:指標)，以確定風險的狀態變化並評估減輕活動的進度。應用和評估這些風險量測措施。
NOTE 6: Major risks may need to be communicated to and monitored by higher levels of management.
備註6: 主要風險可能需要傳達給高階管理階層，並由其進行監控。
額外說明 -- 監控風險的頻率基本上，風險管理是伴隨著專案管理的監控頻率，因此通常會在每週、每月、每里程碑進行風險監控；如果是主要的風險，那麼也必須跟高階管理階層商定溝通頻率，並邀請高階管理階層成員加入一同監控。
—
MAN.5.BP7: Take corrective action.
MAN.5.BP7: 採取矯正行動[Outcome 6]
When expected progress in risk mitigation is not achieved, take appropriate corrective action to reduce or avoid the impact of risk.
當風險減輕未取得預期進展時，採取適當的修正措施以減少或避免風險造成的影響。
NOTE 7: Corrective actions may involve developing and implementing new mitigation strategies or adjusting the existing strategies.
備註7: 修正措施可包含制定和實行新的減輕策略或調整現有的策略。
工作產出(Output Work product)
07-07 風險措施 [Outcome 5]08-14 復原計畫 [Outcome 4,6] 08-19 風險管理計畫 [Outcome 1,2,3,4,5,6] 08–20 風險減輕計畫 [Outcome 3,4,5,6] 13–20 風險行動請求 [Outcome 1,2,6] 14-02 矯正措施登錄 [Outcome 6] 14-08 追蹤系統 [Outcome 6] 15-08 風險分析報告[Outcome 4] 15-09 風險狀態報告 [Outcome 4,5]
感謝閱讀本文章！
如果你對文章內容有任何問題，請隨時與我聯絡。
if you found any question in the article, please feel free to contact me.
email: linchewing@gmail.com
