結構化思考：顧問真正的優勢

結構化思考，是顧問從一個模糊、雜亂的客戶問題，走到一份會議室裡的人可以理解、也可以質疑的建議的方法。您先界定決策，把問題拆成互不重疊的部分，先檢驗最可能的答案，再把發現彙整成一個清楚的建議。

這篇文章寫給想要一套在壓力下可重複運用的方法的顧問與分析師。內容涵蓋我倚重的四種工具、一份您在下一個顧問專案就能使用的一頁式工作表，以及 AI 對這項技能帶來的改變。

我見過有人在客戶會議上僵住。不是因為他們沒有想法，而是因為不知道從哪裡開始。

場景很熟悉。一個複雜的問題、一屋子資深人士、模糊的範疇，以及對清晰答案的期待。沒有結構的反應，是開始講話，然後希望答案自己浮現。有時候真的會。但更常見的是，您繞了二十分鐘，沒有人滿意地離開。

它是把一個模糊的問題拆成各個部分、依序處理每個部分，再把發現彙整回一個建議的做法。

它不是填一張範本，然後稱之為分析。它也不是把一個框架硬套在不適合的問題上。對每種情況都套用 2x2 矩陣的顧問，是在比對模式，而不是在思考。

您正在培養的是幾項能力：

1. 看出真正的問題，它往往與被提出來的問題不同
2. 把它拆成可以分別分析的部分
3. 知道哪些資訊重要，哪些不重要
4. 依據您的發現，建立前後一致的論述
5. 在會議室氣氛緊繃時，把它清楚地說出來

在這些能力養成的過程中，框架就是鷹架。如果您想要更廣的工具箱，我在 SAP 與 AI 交付的七個顧問框架中談到了常用的幾個。

界定問題的提問

在任何框架之前，先問一個問題。需要做出什麼決策，以及什麼資訊會改變這項決策？

對分析品質而言，它的作用比任何結構性工具都大。它迫使您釐清產出是什麼，並阻止您為一個沒有人需要答案的問題，做徹底的工作。《哈佛商業評論》（HBR）多年前就提出過同樣的主張，見 《Are You Solving the Right Problem?》：大多數白費的力氣，都始於一個定義不清的問題。

在 SAP 的情境中，「哪種部署模式適合這個組織」是一項決策。「S/4HANA 是什麼」是一段描述。前者需要分析，後者需要文件。知道自己在做哪一種，決定了您這一週怎麼花。

MECE

MECE 代表 Mutually Exclusive, Collectively Exhaustive，也就是彼此獨立、完全窮盡。當您把問題拆成幾個部分時，每個部分都應該各自獨立（沒有重疊），合起來則應該涵蓋整個問題（沒有缺口）。

重疊的類別會重複計算。缺口則會遺漏東西。多數顧問都知道這個縮寫，但很少人嚴格運用它。

有兩個檢驗能讓它不流於形式。第一，某個項目能不能同時放在兩個分支裡？如果可以，這些分支就重疊了。第二，如果每個分支都得到了答案，核心問題是否也就得到了答案？如果沒有，就有缺口。完美的 MECE 很罕見。重要的是每一次都問這兩個問題。

議題樹

議題樹把核心問題放在樹根，子問題放在分支上。每個分支都可以單獨分析。

以「為什麼這次 SAP 上線超出計畫預算 40%？」為例。第一層的拆分可能是範疇變更、人力成本、時程延長與計畫外的補救。範疇變更接著再拆成正式的變更請求、非正式的追加項目，以及很晚才發現的落差。每一個末端節點都可以衡量。

議題樹的價值，體現在顧問專案一開始、您還沒做任何分析之前。它們能防止您在某一個分支上花了三週，而另一個分支卻完全沒碰。

假設驅動分析

不是先蒐集所有資料再下結論，而是從最可能的答案開始，然後檢驗它。策略顧問公司就是靠這個方法建立起聲譽。

在時間有限、問題複雜的情況下，窮盡式分析是不可能的。一個好的假設，會告訴您該先看什麼。如果它成立，您就有了答案。如果它不成立，推翻它的證據，通常會指向某個有用的方向。

它也是最常被誤用的方法。顧問提出了假設，卻只去找能證實它的證據。請問問自己，什麼證據能證明您是錯的，然後先去找那個證據。

這是我會在新顧問做第一次診斷之前交給他的順序。在打開任何一份試算表之前，先把它填好。

1. 01界定問題用一句話說出要做的決策
2. 02拆解三到五個符合 MECE 的問題
3. 03提出假設每個分支一行
4. 04找反證能證明您是錯的證據
5. 05檢驗每個分支的發現，附上來源
6. 06綜整先講建議，再講佐證
7. 07壓力測試在會議室提出之前，先回答反對意見

一個撐得過指導委員會檢驗的建議

步驟	要回答的問題	產出	由誰簽核
1. 界定問題	客戶需要做出什麼決策，期限是什麼時候？	一句話	客戶端發起人
2. 拆解	哪三到五個問題，合在一起回答，就能定下這項決策？	第一層議題樹，已通過 MECE 檢驗	顧問專案主持人
3. 提出假設	我目前相信答案是什麼，為什麼？	每個分支一行假設	顧問專案主持人
4. 找反證	什麼證據會顯示每個假設是錯的？	排序後的資料需求清單	客戶端資料負責人同意提供
5. 檢驗	證據說了什麼？	每個分支的發現，附上來源	團隊中各分支的負責人
6. 綜整	所以客戶應該怎麼做？	先講建議，再講佐證要點	顧問專案主持人
7. 壓力測試	會議室裡誰會不同意，不同意什麼？	已準備好的反對意見與回應	一位沒有參與這項工作的同事

第 7 步是大家最常跳過的。它也是決定這份建議能不能撐過指導委員會的那一步。

有一位 SAP 客戶，是一家大型製造集團，營運著高度客製化的 ECC 系統環境。IT 主管說得很直白：「我們需要降低營運成本，但我們承擔不起弄壞任何東西。」

直覺是開始列出節省成本的點子。這會給您一張很長的清單、一堆緊張的人，以及沒有優先順序。

我們把成本分析整理成三個分支：應用系統維護、基礎架構與授權。接著再疊加客製程式碼的分析。實際在使用的修改有多少？超過一半都沒有在用。多餘的介面、沒人用的自訂報表、重疊的工作流程。

這樣組織之後，我們得以指出感覺安全的節省項目，例如封存沒在用的客製物件、整併開發環境。這份清晰降低了政治上的摩擦，也建立了信任。沒有這棵樹，它就只會是一張沒有人願意簽名的刪減清單。

同樣的方法，也適用於更模糊的委託。有一家企業軟體廠商曾要求我們為沙烏地阿拉伯的中型市場，提供「區域上市策略」。我們把工作拆成市場需求、競爭定位與夥伴準備度。在夥伴準備度底下，我們發現他們的經銷商網路幾乎沒有 SAP S/4HANA Cloud 的經驗。不論市場看起來多有吸引力，這個阻礙都會讓執行停擺，而這個結構在他們花掉行銷預算之前，就把它揭露了出來。

框架沒有改變。改變的是另外兩件事。

草稿現在變得很便宜。Joule、ChatGPT 與 Claude 幾秒鐘內就能產出一棵議題樹或假設樹。過去要花一整晚做初稿的資淺顧問，現在半分鐘就能產生，然後把那一晚花在模型做不到的事情上：檢驗這個結構是否適合這個問題、找出它遺漏的東西，以及質疑提示詞裡的假設。

判斷力的溢價變大了。當每個人都能產生 MECE 的拆解，問題就不再是「您有沒有拆解問題」。而是「您有沒有注意到，客戶所說的問題其實是另一個問題，以及您有沒有抓到模型預設接受的那項假設」。在真實的顧問專案中培養出判斷力的顧問，如今的領先幅度，比 2024 年時更大。

所以這項技能已經轉移了。不再是「您能不能建出一棵議題樹」，而是「您能不能看出 AI 草擬的樹哪裡錯了，並且在客戶的會議室裡把它修正」。

如果您正在思考這讓您自己的職涯處於什麼位置，SAPopedia 的職涯路徑描繪了顧問的各條發展路線，而 ERPCV 職涯資料包則協助您在履歷上展現這類判斷力，而不只是列出一堆框架名稱。

從解決方案開始。 客戶或顧問在問題被界定之前，心裡就已經有了答案。分析於是變成了驗證。

結構太多。 有些簡單的問題，值得得到直接的答案，而不是一次 MECE 的拆解。知道什麼時候不該用結構，與知道怎麼用同樣重要。

拆解的深度不對。 太早拆得太深的樹，會造成癱瘓。停留在淺層的樹，產生的建議沒有人能據以行動。要讓深度配合決策與可用的時間。

只有分析，沒有綜整。 一棵嚴謹的樹，最後卻只是一堆資料傾倒。結構幫助您思考。判斷力才產出建議。

把溝通的結構與思考的結構混為一談。 結論先行的呈現方式，如 Barbara Minto 的金字塔原理，是一種溝通技巧。它並沒有說明底下的思考是否站得住腳。把糟糕的分析溝通得很好，仍然是糟糕的分析。

這是一項技能，不是天賦。它來自練習。

每一次重要的客戶對談之後，把您理解的問題、您的拆解、您的假設，以及能檢驗它的證據寫下來。在看任何資料之前就做。寫作所逼出的清晰度，是在腦中思考所無法達到的。

要練習綜整，而不只是分析。拿一堆證據，產出一個站得住腳的建議，是比較難的那一半。多數資淺顧問在分析上還算稱職，在綜整上則發展不足。這個落差，就是下一次升遷所在的位置，也是把流行語都剝掉之後，顧問實際在做的事中很大的一部分。

顧問工作中的結構化思考是什麼？

它是把一個複雜、模糊的問題拆成幾個部分，依序處理每個部分，再把發現組合成一個清楚的建議。它讓困難的問題變得可以處理，也讓推理看得見，讓客戶可以跟上並加以質疑，而不是憑信任接受一個結論。

主要的工具有界定問題的提問、議題樹、MECE 與假設驅動分析。沒有任何一個能取代判斷力。

MECE 是什麼意思，如何使用？

Mutually Exclusive, Collectively Exhaustive，即彼此獨立、完全窮盡。拆解出來的各個部分不應重疊，合起來則應涵蓋整個問題。

檢驗重疊：某個項目能不能放在兩個分支裡？檢驗缺口：如果每個分支都得到了答案，核心問題是否也就得到了答案？要在建立議題樹時就運用它。等到分析完成之後才運用，通常已經太晚。

假設驅動分析是如何運作的？

您在早期就說出最可能的答案，列出能證實或推翻它的證據，然後去檢驗它。它比先蒐集所有資料更快，因為它告訴您該看哪裡。

風險是確認偏誤。要先去找能證明您是錯的證據。

如何正確界定顧問問題？

問問需要做出什麼決策，以及什麼資訊會改變它。然後在接受客戶的問題陳述之前，先檢驗它。

一位客戶問「我們應該先導入哪個 SAP 模組？」，他真正要決定的，可能是「現在到底是不是啟動 SAP 專案的正確時機？」。如果不檢驗問題的界定，就直接回答所陳述的問題，您得到的分析，在技術上是正確的，在商業上卻是錯的。

顧問工作中的分析與綜整有什麼差別？

分析把問題或資料集拆成幾個部分，以便理解它們。綜整則把發現組合成一個建議。

交付成果最常見的失敗，是有大量分析，卻沒有綜整：客戶拿到一疊發現，卻沒有得到他們聘請您所要回答的那個問題的答案。先寫結論，會迫使綜整發生。

結構化思考如何應用在 ERP 導入上？

在專案開始時，它能阻止團隊在理解真正的問題之前就去組態設定。一個說「我們需要 SAP」的組織，可能首先需要修正的是某個流程或資料問題，而 SAP 只會讓這個問題更明顯。

在 Fit-Gap 工作中，對業務流程做 MECE 的拆解，能確保每個流程都被考慮到，而不只是工作坊中被提出來的那些。在一次問題叢生的上線之後，界定決策（穩定、救援或汰換），並針對主要原因檢驗一個假設，比起列出各種症狀，能更快帶您得到一個站得住腳的建議。