案例｜Staff Inflexibility：Call Centre 如何用七步診斷找到真正問題

核心主題 主要觀點／概念 實務或理論意義 重要條件／限制／延伸
Diagnosis Before Solution 作者認為 management 常直接跳到 solution，卻沒有先確認真正 problem／cause。 錯誤 diagnosis 會浪費資源、保留 root cause，甚至製造新問題。 「快」不等於有效；尤其 execution barriers 彼此高度關聯。
Symptoms vs Causes 表面症狀如「staff inflexibility」「communication problem」「lack of resources」可能只是 downstream effect。 診斷要重新定義 fundamental question，而不是接受既有標籤。 Call-centre 案展示從症狀轉向 managerial choice 的過程。
Framework Selection 適當 framework 用來簡化複雜性、聚焦 hotspot，再產生／測試 explanations。 Framework 是 hypothesis-generating tool，而不是直接答案。 Management fashion／popular models 也必須檢查 validity 與 context fit。
Seven-Step Diagnosis 擱置未經診斷的 solutions；不猜原因；為 stakeholder 定義問題；找 fundamental question；選 framework；聚焦 hotspot；生成並測試 explanations。 把模糊 execution problem 轉成可調查、可證偽的問題。 步驟可迭代，不應機械化使用。

Strategy Execution 的第一個錯誤通常不是「做太少」，而是「解錯問題」

第 4 章把 diagnosis 放在 action 之前。作者批評典型 solution-oriented management：一看到 performance gap，就立即買 system、改 structure、辦 training、加 KPI 或進行 culture programme。這些 intervention 可能有效，但前提是它們處理的是真正 cause。

不要接受問題的第一個名字

「員工不彈性」「跨部門溝通差」「缺乏 accountability」都是很像原因的描述，但它們也可能只是 symptom。Call-centre 案中，morning capacity 不足最初被解釋成員工不願早班；重新檢查 comparative staffing、abandon rates 與 manager choices 後，問題才被改寫成：「為什麼 manager 選擇不在早晨配置足夠 capacity？」

這個 reframing 會直接改變需要收集的 data 與可能 solution。

七步 Diagnosis Logic

原書建議：

  1. 暫時擱置沒有建立在良好 diagnosis 上的 proposed solutions；
  2. 不要先猜 underlying causes；
  3. 從 stakeholder／objective 重新定義 problem；
  4. 找到最 fundamental question；
  5. 選擇合適 framework 幫助簡化；
  6. 聚焦最可能的 hotspot；
  7. 產生多個 explanations，再用 evidence 測試。

Framework 不是管理時尚

作者特別警告，consultants、books、conferences 與 management fashions 很容易讓組織把流行 solution 套到任何問題上。Framework 的角色應是幫助思考與測試，而不是讓 manager 跳過 diagnosis。

本章判斷重點