跳轉到內容

商業分析指南/根本原因分析

來自華夏公益教科書,開放的書籍,為開放的世界

什麼是根本原因分析/為什麼重要

[編輯 | 編輯原始碼]

簡而言之,根本原因分析是對特定情況的仔細檢查,以確定特定問題或偏差的根本原因。商業分析知識體系 (BABOK) 將其定義為“對情況各個方面的結構化檢查,以確定問題的根本原因和由此產生的影響”。根據進行的檢查的嚴格程度,有可能識別出幾層症狀,然後才能找到特定情況的根本原因或原因。

何時使用

[編輯 | 編輯原始碼]

根本原因分析最常與問題解決相關聯,儘管它也可以應用於組織分析、差異分析、流程改進和軟體錯誤修復。本質上,每當結果不如預期時,通常可以找到一個或多個因果關係。鑑於識別根本原因分析的一些工具可能是主觀的,因此確定導致偏差的根本原因通常是一個判斷問題,尤其是在所評估的系統很複雜時。

需要考慮的問題

[編輯 | 編輯原始碼]

透過仔細尋找特定問題的根本原因,然後對根本原因採取一些緩解措施,問題通常就會消失。僅僅處理問題的症狀,潛在的問題很可能以新的方式出現,但不會消失。例如(想出一個好的例子)。問題通常可能沒有嚴重到需要進行嚴格的評估。在決定對根本原因進行多深入或多快的挖掘時,這裡有一些問題需要考慮

  • 這個問題/問題的後果是什麼?是頭條新聞嗎?危及生命還是僅僅令人討厭?
  • 這是單獨發生還是以前發生過?
  • 這種情況再次發生的可能性有多大?
  • 在問題/出現之前是否有可能作為早期預警訊號的事件?
  • 在事件發生之前是否有最近的變化可能直接或間接地促成了它的發生?
  • 這是系統範圍內的型別問題,還是僅限於一個辦公室或部門?
  • 是否有控制措施來檢測此類問題/問題?

問題來源

[編輯 | 編輯原始碼]

根本原因可能相當廣泛。通常是一系列的小問題,而不僅僅是一個單一的問題。以下列表改編自保羅·威爾遜等人 1993 年出版的《根本原因分析》一書。擁有一個貢獻因素列表通常有助於識別實際的根本原因。

  • 培訓(正式和非正式)
  • 管理方法(資源和時間表計劃)
  • 變更管理(對現有流程的修改)
  • 溝通(有效或無效)
  • 外部(機構控制範圍之外的因素)
  • 設計(支援工作的裝置和系統)
  • 工作實踐(用於完成任務的方法)
  • 工作組織(組織績效和任務順序)
  • 物理條件(影響績效的因素)
  • 採購(獲取必要的資源)
  • 文件(說明和程式)
  • 維護/測試(包括預防性維護)
  • 人機關係(到位警報和控制)

需要注意的是,這些潛在的根本原因可能是症狀,在某些情況下,可能存在多個根本原因。

有許多工具可用於確定根本原因。每種方法將簡要解釋,提供一個示例圖表來說明該概念,並將提供構建和解釋的工具。所介紹的工具包括

  • 魚骨圖
  • 問為什麼5次
  • 檢查表/帕累託圖
  • 相互關係圖
  • RPR(快速問題解決)

魚骨圖

[編輯 | 編輯原始碼]

此工具也稱為石川圖或因果圖。它以卡魯·石川的名字命名,卡魯·石川在 20 世紀 60 年代在川崎造船廠開創了 TQM 流程。它從圖的形狀中得到它的通用名稱,如圖所示

要構建魚骨圖,從您要解決的問題開始,該問題位於魚的眼睛附近。從那裡,確定問題的根本原因。通常,這些是 4P 或 4M,但可以是針對特定問題有意義的東西。4P 是人員、程式、政策和工廠。4M 是人、機器、方法和材料。一個示例圖表顯示了“可能”導致一杯咖啡變壞的原因如下

這些圖表可以用筆和紙輕鬆構建,還可以使用各種圖表工具,例如 Visio(參見業務流程/因果圖)。要分析結果,請查詢常見示例。是否多次列出某些內容?在這種情況下,沒有培訓和劣質輸入(例如,壞糖、髒杯子等)似乎是需要進一步探索的非常常見的主題。這是一個非常適合在小組環境中使用的工具。

問為什麼5次

[編輯 | 編輯原始碼]

雖然很容易跳到解決方案,但確定某事發生的原因通常更難。最常用的根本原因分析工具之一被稱為“5個為什麼”。這是基於不斷問為什麼的前提。使用前面圖示中的髒咖啡,您可以從咖啡不好這個明顯的問題開始。透過問“為什麼咖啡不好”,第一個回覆可能是它很淡。下一個為什麼是,“為什麼咖啡很淡”,回覆可能是咖啡不夠。在問“為什麼咖啡用量不夠”時,回覆可能是我們用完了。不斷地問“為什麼”,直到你找到可能的根本原因。為了說明這個概念,請參見下圖

在華盛頓特區的傑斐遜紀念堂可以找到使用此工具的真實示例。美國國家公園管理局注意到,這座紀念碑的腐蝕速度比其他華盛頓特區紀念碑更快。透過問為什麼5次,他們能夠找到問題的根源,如下所示

  • 為什麼紀念碑腐蝕得更快?因為它被清洗得更頻繁。
  • 為什麼紀念碑被清洗得更頻繁?因為有很多鳥糞。
  • 為什麼紀念碑上有更多的鳥糞?因為鳥兒非常喜歡這座紀念碑。
  • 為什麼鳥兒更喜歡傑斐遜紀念碑?因為紀念碑內外有許多肥蜘蛛。
  • 為什麼有很多蜘蛛?因為紀念碑周圍有許多在晚上飛來飛去的昆蟲。
  • 為什麼有更多的昆蟲?因為紀念碑的照明吸引了更多的昆蟲。

在評估解決這個問題的各種方案(例如殺蟲劑、特殊塗層、不同的燈光等)時,小組會確定不同的重點領域。在本案例研究中,公園管理局選擇將每晚的燈光開啟時間延遲一個小時。這一改變使鳥糞問題減少了 90%。

使用這種技術時,可以遵循不同的路徑並得出不同的解決方案。如果發生這種情況,在確定適當的解決方案時,可以考慮幾個因素,例如小組能夠控制的內容。在傑斐遜紀念堂的案例中,他們有能力控制照明,並選擇了一個無需成本的方案來解決問題。

此技術也用於需求收集,特別是在採訪主題專家時。請參見“記錄和管理需求”部分。

檢查表/帕累託圖

[編輯 | 編輯原始碼]

有一句老話:“凡是能被測量的,就能被做到。”在根本原因分析中,結合建立簡單的檢查表來收集來自觀察或事件的資料,並將資料繪製到帕累託圖上,可以幫助確定問題區域。在沒有資料的情況下,經常被認為或顯而易見的問題會讓你走上錯誤的道路。透過觀察和記錄特定時間段內事件發生的頻率,可以確定相對嚴重程度。請參見下面的示例檢查表。

收銀員 卡紙 輸入的資訊錯誤 交易取消 資金不足 總數
A 4 2 2 9
B 10 5 3 2 20
C 3 2 5
D 3 1 1 1 6
總數 21 10 6 3 40

在構建檢查表時,只需簡單地確定要計數的內容,然後在它們發生時計數即可。在合理的時間段後,只需將發生的次數加起來。在本例中,識別的錯誤表明卡紙(紙張和裝置問題)和操作員輸入的資訊錯誤。對於卡紙,可能是印表機有問題,也可能是要列印的材料有問題(重量、材料、塗層等)。為了解決這個問題,需要進行多次試驗測試,以幫助識別真正的根本原因。對於“輸入的資訊錯誤”,可能只需對收銀員 B 進行重新培訓,或在後臺新增一些編輯檢查,以查詢常見的錯誤。在所有情況下,最好先關注你直接控制範圍內和環境中的專案,然後再嘗試用技術解決問題。收集完資料後,可以使用稱為帕累託圖的強大工具來記錄結果。帕累託圖顯示了問題或事件的相對重要性,其基礎是 80% 的問題源於 20% 的原因。80-20 規則的基礎是義大利經濟學家維爾弗雷多·帕累託,他注意到 80% 的土地為 20% 的人所有。透過應用上述檢查表的結果,下面是一個示例圖表

請注意,該圖有兩個縱軸。左邊的縱軸提供發生次數的相對計數,而右邊的縱軸則關注總髮生次數的累積%。透過將問題解決工作集中在最大數量上,總錯誤將顯著減少。

相互關係圖

[編輯 | 編輯原始碼]

互相關係圖是另一個有價值的工具,它有助於比較相關問題,以確定哪些是驅動因素(根本原因)以及哪些受到其他因素的影響(症狀)。這項練習最好在有各種視角的小組環境中進行。矩陣可能需要一些時間才能完成,但通常會在完成後提供有價值的見解。使用症狀/根本原因列表,建立一個矩陣(我們這裡使用一個 5x5 的示例),然後在右側新增 3 個額外的摘要列。

在本例中,我們將關注非有效會議的原因,5 個潛在的症狀或根本原因是:沒有議程、缺乏引導、會議上的人不對、少數人主導發言時間和重複討論相同內容。在本例中,症狀因小組和組織而異,毫無疑問,透過小組的意見,有可能提出更多專案。數量較少是為了演示如何構建、引導和評估結果。下面是一個已完成的矩陣

編輯說明:插入表示不良會議互相關係圖的表格

對於每個已識別的問題,詢問小組每個專案對另一個專案的影響。從 A. 缺乏議程到 B. 缺乏引導開始,詢問小組,A 驅動或影響 B,還是 B 影響 A?通常,如果你有引導者,你通常也會有議程,因此在這種情況下,在 A 行/B 列上放置一個“向上箭頭”表示 A 對 B 的影響,在 B 行 A 列上放置一個“向上箭頭”表示 A 對 B 的影響。你會放置一個“向內箭頭”表示 A 對 B 的影響。接下來,你將檢視缺乏議程和會議上的人不對。雖然你可以“提出”一個弱論點,即如果你有一個議程,那麼很明顯你召集了錯誤的人參加會議,但這還有其他驅動因素——因此在這種情況下,我們將放置一個“-”連字元,表示沒有關係。對於每對專案,矩陣將收到一個關係標記。完成後,就該加起來。將所有指向內部的箭頭(被影響的專案)為每行相加,並將總和報告到“向內”列中。將所有指向向上的箭頭(影響專案的專案)為每行相加,並將總和報告到“向外”列中,然後將向內和向外都相加。在評估結果時,尋找“向外”數量最多的專案作為你的根本原因。在本例中,缺乏引導者會導致重複討論相同內容(一次又一次地開會)。此工具也非常適合確定關鍵流程以及根本原因。而不是列出問題或問題,而是記錄所有流程並用字母表示,並評估哪些流程影響或直接影響其他流程。

快速問題解決 (RPR)

[編輯 | 編輯原始碼]

此技術專門設計用於識別 IT 問題的根本原因。雖然它與 ITIL 問題管理流程一致,但它要求問題能夠被複制,並且該方法旨在一次專注於一個症狀,直到確定根本原因。該方法包括三個步驟:1) 發現 2) 調查和 3) 修復。在發現階段,重要的是獲取儘可能多的有關問題的資訊(問題是什麼,何時發生,在什麼環境中,頻率等),並確定我們要解決的問題是什麼。調查階段側重於能夠複製問題,以便可以識別導致問題的原因。在這種情況下,有必要開發和執行診斷資料捕獲工具,以便可以獲得結果來識別導致問題的原因。一旦確定了根本原因,就可以透過檢視診斷資料來跟蹤其發生的位置。找到問題後,需要開發和實施修復方案,並驗證解決方案。

根本原因分析是解決問題的關鍵組成部分。如果你沒有處理問題的根本原因,那麼這個問題很可能不會消失。透過治療症狀,問題通常以不同的方式表現出來,提供了一組新的症狀。由於解決問題的時間和資源有限,最好擁有幾種工具來尋找根本原因。

參考文獻

[編輯 | 編輯原始碼]

編輯說明:按照格式規則編譯並新增列表

華夏公益教科書