# 找出缺失的根本原因"rca"，矯正、預防再發生

根本原因分析是用在回溯已經發生的問題，以提出未來的防範或解決方案的常用的工具。可以從最簡單的五個WHY、Pareto Chart柏拉圖、到複雜的事件分解方法或8D (Eight Disciplines Problem Solving)、等品質管理手段。

從專案經驗知道，RCA在顧問甚至一般專案導入的過程中也相當重要而有效。首先我們要強調，檢視問題的根本原因是為了找到治本的解決方案，不是為了將問題發生的責任討論歸咎到某個人身上。所有工作都是人為，就算天災也可能是因為人員防範不足、AI犯錯也是因為訓練或算法有誤。但是把事件發生的責任歸咎到某個人身上，應該不是避免再次發生的最終答案。

在專案中應用RCA是其中一種比較好溝通方式，讓成員或User聚焦在專案本來的目標上，降低因為固有的成見，或工作的慣性造成的目標偏移。

例如我們作健檢的各項指標，目標是為了健康，而不是為了好看的數據。但如果我們發現，維持該指標的行為並不能讓我們保持健康，那麼這個指標以及維持該指標的行為就應該被檢討。企業常會犯的問題就是守住了一些KPI，但卻忘了為什麼要守著這些KPI。或許過去有它的原因，更可能是從頭到尾都是個誤會，很多時候KPI的制定是因為上層要看到數據化的結果，所以部屬就製造了數據化。

專案會延時或超出預算有很多原因，其中很大一塊是需求的變動或不必要的需求，也就是浪費。這時候訓練每個人問RCA的五個Why就可以是很好的找問題，或確定需求必要性的方法。最近有一個資產維護系統的案例，我們為一個客戶進行大型維護管理的督導系統開發，在專案上線前，客戶忽然提出需要增加另外一套評分的表單。這個客戶也很講理的知道這是需求變動要額外費用（當你在軟體業遇到過很多把程式開發當作跟畫PPT一樣，會隨便要求開發人員改來看看，把需求變動不當成本的無良客戶時，你就知道我說的講理有多難能可貴）。但基於顧問的職責，我們還是追根究底的了解為什麼要這個功能，以下是簡化後的過程。

> *客戶：沒有這個評分表我們無法完成督導*
> 
> *顧問：督導系統可以自由設計彈性的督導事項，紀錄每個事件，也有了針對事件的嚴重性／急迫性評等，額外進行評分的作用是？*
> 
> *客戶：因為督導完都要計算這個評量，現在系統沒有納入的話，我們就要回紙本再填*
> 
> *顧問：這個評分要給被督導單位看嗎？*
> 
> *客戶：沒有*
> 
> *顧問：這個評分表看不出評量的標準，評分的結果也不知道如何作為改善的依據，主管看到這個評量表的決策目的是？*
> 
> *客戶：呃……以前都有這個評分表給主管看，我們不知道主管會作什麼。*

最後問了一圈發現這就是一張下面的人會呈上去，上面的人也習慣看到的報表，但沒人能解釋這一個指標如何作為決策或改善的依據。不少企業內都有這種目的不可考的作業流程或表單，除去增加工作負擔，較負面的潛在影響反而是，這些指標的問題相當的主觀，評分的方式會夾雜了很重的個人見解，對管理層分析跟改善設備維運沒有幫助，但卻會對被評分人留下不正確的印象。

其實仔細想想，系統開發中很多冗餘的功能，後來可能作廢不用甚至還要花代價去拔掉，浪費了開發的人力成本，常常都是因為這麼來的。不是說因為不確定結果就不能嘗試，在敏捷開發中之所以要切Sprint衝刺，有MVP（最小可行版本）的觀念，就是為了要用來驗證觀念的可行性，避免一廂情緣的設計開發一堆最終不符合管理功能或市場需求的功能。但需求的根本原因還是要能禁的起深究，若連假設都不過關，那麼也不該被包裝以「嘗試」「驗證」的外衣來進行。

[  
](https://medium.com/tag/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90?source=post_page-----661774212aaf---------------%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90-----------------)