← M08 大數據分析 M08 大數據分析

M08.10｜資料分析專案管理

從問題到洞見的完整旅程 — CRISP-DM 讓每個分析都有始有終

L1-AI應用規劃-專案管理 L2-AI技術應用-資料分析

🇺🇸 DOL AI Literacy 🎯 有效指揮 AI 🔎 評估 AI 產出 💡 培養互補的人類技能 👥 培育賦能角色

📋

本講學習重點

CRISP-DM 的六個階段是什麼，各自最重要的產出是什麼？

業務問題如何轉換為資料分析問題？

為什麼分析師花最多時間在資料準備上？

如何向非技術背景的主管有效溝通分析結果？

分析專案最常在哪個階段失敗？

CRISP-DM 六階段：業務理解 → 資料理解 → 資料準備 → 模型建構 → 評估 → 部署，是循環而非線性

業務問題轉分析問題：把模糊的『業績為何下滑』轉為可量化的假設，定義成功指標（KPI）、時間範圍、資料來源

資料準備佔 60-80% 的時間：清洗、整合、轉換、抽樣，這是被低估但最影響結果品質的環節

模型評估要問：業務指標是否有改善？技術指標是否符合業務要求？是否有意料外的後果？

洞見溝通：用故事結構（問題-發現-建議-影響），視覺化要服務結論而非展示技術，一頁報告原則

專案失敗的主因：問題定義不清（分析對象和業務問題脫節）、資料品質問題、缺乏利害關係人的支持、結果無法被採納行動

敏捷資料分析：兩週一個 Sprint，快速原型驗證假設，避免「三個月後才發現方向錯了」

📌 CRISP-DM（跨產業資料挖掘標準流程）提供了從「業務問題」到「可採取行動的洞見」的結構化框架，其六個階段不是線性的而是循環迭代的——在任何階段發現問題都可以回到之前的步驟。分析專案最常失敗的原因不是技術，而是「回答了一個沒有人真正關心的問題」或「產出了利害關係人看不懂的結果」。成功的資料分析需要同等重視：清晰的問題定義、高品質的資料準備、和有效的洞見溝通。

🎙️ Podcast（中文）

0:00 / 0:00

一句話搞懂

資料分析專案管理是把「業務問題」轉化為「可行動的洞見」的全流程管理方法——從釐清「到底要回答什麼問題」開始，經過探索資料、清洗資料、建立模型、評估結果，到最後把分析結果有效地傳達給決策者並落實到業務行動；CRISP-DM（跨產業資料挖掘標準流程）是業界最廣泛使用的框架，它最重要的洞見是：80% 以上的失敗分析專案敗在「技術之外」——問題定義不清或溝通無效，而非算法本身。

白話解說

CRISP-DM：給資料分析一個可重複的流程

在資料分析被系統化之前，許多分析專案的進行方式是：拿到資料就開始分析，跑了很多模型，最後做一個精美的報告，交給主管後沒有下文。幾個月的工作換來一句「好，我知道了」，什麼改變都沒有發生。

CRISP-DM（Cross Industry Standard Process for Data Mining，跨產業資料挖掘標準流程）是 1996 年由 IBM、DaimlerChrysler、NCR 等公司聯合提出的分析流程框架，提供了一個從業務問題到落地行動的結構化路徑，至今仍是業界最廣泛採用的資料分析方法論。

CRISP-DM 的六個階段：

第一階段：業務理解（Business Understanding） 這是整個專案中最重要、也最常被跳過的步驟。核心問題是：「我們真正想回答的業務問題是什麼？」一個常見的陷阱是分析師直接跳入資料，幾周後才發現分析方向和業務需求完全錯位。

業務理解階段需要產出：

清晰的業務目標（如「提升次月留存率 5%」）
轉換為資料分析的分析目標（如「建立預測用戶 30 天內流失的分類模型，精確率不低於 75%」）
成功標準（判斷這個專案算完成的具體指標）
限制條件（時間、預算、資料可得性、技術限制）

第二階段：資料理解（Data Understanding） 探索性資料分析（Exploratory Data Analysis, EDA）：了解有哪些資料可用、資料的品質如何、各個欄位的分佈和相互關係，找出潛在的資料問題（缺失值、異常值、重複記錄）。

核心產出：資料品質報告、關鍵變數的統計摘要和視覺化分析、初步的資料相關性觀察。

第三階段：資料準備（Data Preparation） 把「業務資料」轉換為「可供模型使用的乾淨特徵」。這個階段通常佔整個 CRISP-DM 週期 60-80% 的時間，包括：資料清洗（處理缺失值、異常值、格式錯誤）、特徵整合（把來自多個資料源的資料合併）、特徵工程（計算衍生特徵）、資料轉換（標準化、編碼）。

第四階段：模型建構（Modeling） 選擇合適的算法、訓練模型、調整超參數。這個階段在整個週期中佔的時間反而相對最少（如果資料準備充分的話），但往往是最被外界高估重要性的一個階段。

第五階段：評估（Evaluation） 不只是評估技術指標（如 AUC、RMSE），更重要的是回到業務視角：這個模型真的能回答最初的業務問題嗎？模型的預測結果是否符合業務邏輯（可解釋性）？是否存在不期望的副作用（如對特定用戶群的歧視）？

如果評估結果不符合預期，這個階段可能觸發回到之前任何一個階段重新迭代。

第六階段：部署（Deployment） 把模型或分析洞見從「研究環境」帶入「業務環境」。可能是把模型整合進 IT 系統做自動化預測，或者把分析結論轉換為業務行動建議，或者建立例行化的報表和監控看板。

CRISP-DM 最重要的設計原則是：六個階段是循環的，而不是線性的。資料準備時發現資料根本不足，可能需要回到業務理解階段重新定義更可行的問題；模型評估發現效果達不到業務要求，可能需要回到資料準備做更多的特徵工程。

問題定義：分析專案成敗的第一關

研究顯示，大多數失敗的資料分析專案，問題不出在技術，而出在「一開始就回答了錯誤的問題」。以下是一個典型的問題演化過程：

原始業務問題（模糊版）：「我們的用戶流失越來越嚴重，幫我分析一下。」

這個問題太寬泛，無法直接分析。一個有經驗的分析師會和業務主管進行深入訪談，把問題逐步具體化：

深化後的問題（具體版）：

「流失」的定義是什麼？（30 天沒有登入？取消訂閱？）
流失問題發生在哪個用戶族群？（新用戶？老用戶？特定方案的用戶？）
流失主要發生在哪個時間點？（注冊後的第幾天？首次付費後？）
已知業務上發生了什麼變化？（最近的定價調整？新競爭對手上市？產品功能更新？）
分析結果要用來做什麼決策？（決定是否推出挽留優惠？優化 Onboarding 流程？）
分析結果需要在什麼時間內完成？（下周董事會要用？三個月後的產品規劃？）

轉換為可分析的問題：「定義：連續 30 天未登入的用戶為流失。目標：識別注冊後第 7-14 天的用戶中哪些人有高流失風險（預測召回率 ≥ 80%），以便在用戶流失前 7 天觸發個人化的挽留通知（A/B 測試後評估效果）。數據範圍：最近 12 個月，排除企業帳戶。」

這個具體問題定義才能直接驅動後續的資料準備、模型設計和評估標準。

資料準備的現實：為什麼要花這麼多時間

業界的普遍共識是：資料分析師 60-80% 的時間花在資料準備上，而非建模。很多剛入行的分析師對此感到挫折（「我是來建模型的，不是來清資料的」），但理解其中的原因後，會發現這個比例是合理甚至必要的。

現實問題一：資料從來都不是「分析就緒」的。企業的資料通常分散在多個系統（CRM、ERP、行銷工具、日誌系統），格式不統一（日期格式：「2024/01/15」「Jan 15, 2024」「20240115」可能同時存在），口徑不一致（行銷部門的「訂單量」和財務部門的「訂單量」可能因為退貨處理方式不同而數字不同）。把這些資料整合成一個可分析的資料集本身就是巨大的工程。

現實問題二：資料品質問題往往隱藏得很深。表面上「完整」的資料中，可能存在邏輯矛盾（「出生日期」是 1900 年的記錄、「退貨日期」早於「購買日期」），或者記錄的是系統行為而非業務行為（如測試帳號的交易記錄、員工的自購記錄），這些問題如果不仔細清洗，會讓模型學到錯誤的規律。

現實問題三：特徵工程需要深度的業務理解。把「交易紀錄」轉換為「對信用風險有預測力的特徵」，需要對金融業務有深入的理解（哪些消費行為和違約風險相關？），這種業務知識的注入發生在資料準備階段，不是在跑模型時。

洞見溝通：分析結果如何影響決策

一個在技術上完美的分析，如果無法讓決策者理解並採取行動，就是失敗的。洞見溝通（Insight Communication）是資料分析師經常被忽視但極為重要的能力。

故事結構：問題 → 發現 → 建議 → 影響

好的分析報告不是按「資料說明 → 方法論 → 結果 → 結論」的學術論文結構組織，而是用能讓業務主管快速抓住重點的故事結構：

問題：「我們的次月留存率在過去 3 個月下降了 8 個百分點，每月額外損失約 200 萬的訂閱收入。」（先說業務影響，讓讀者理解為什麼重要）
發現：「分析顯示，流失主要集中在注冊後第 7-14 天的用戶，且這些用戶 92% 在第 3 天之後就沒有完成第一個核心功能的設置。」（直接說最重要的發現，不要把技術細節放前面）
建議：「建議在用戶注冊後第 3 天，針對尚未完成核心功能設置的用戶，發送一封個人化的引導郵件 + App 推播。」（可行的、具體的行動建議）
影響：「根據歷史類似介入的效果，預估可以挽回 15-20% 的潛在流失用戶，每月增加約 30-40 萬的收入。」（量化建議的預期效果，幫助決策者評估是否值得投入）

視覺化原則：每張圖只說一個結論

分析師常犯的錯誤是把複雜的圖表直接放進報告，讓讀者自己解讀。有效的視覺化應該：圖表標題直接是結論（如「第 7-14 天流失用戶中 92% 未完成核心設置」而非「流失用戶的功能設置完成率」）；用顏色和標注引導眼睛去看最重要的資料點；去除所有不服務結論的裝飾元素（3D 圓餅圖、漸層背景）。

一頁報告原則：核心的業務洞見應該能被壓縮在一頁內傳達（問題、關鍵發現、建議、預期效果）。詳細的技術方法論和輔助分析放在附錄，供需要的人深入查看。

敏捷資料分析：避免三個月後才發現方向錯了

傳統的瀑布式分析方法（收集需求 → 三個月後交付完整報告）有一個致命缺陷：如果在最後才發現分析方向和業務需求不符，所有工作都付之東流。

借鑒軟體開發的敏捷方法論（Agile），資料分析也可以以兩週為一個 Sprint（衝刺期），在每個 Sprint 結束時交付一個小但可驗證的分析成果：

Sprint 1（第 1-2 週）：完成 EDA，輸出「資料品質報告 + 5 個關鍵假設的初步驗證」
Sprint 2（第 3-4 週）：第一個可用的基準模型（baseline model），可能準確率不高但可以評估方向
Sprint 3（第 5-6 週）：特徵工程改進後的模型，加上第一輪業務利害關係人的評審回饋
Sprint 4（第 7-8 週）：最終版本的模型 + 部署評估 + 行動建議

每個 Sprint 後的評審會議讓業務主管能及早介入（「你分析的這個定義不對，我們的流失是指 60 天而不是 30 天」），避免方向性的錯誤被帶到最終交付。

應用場景

場景	CRISP-DM 階段特點	常見挑戰	成功關鍵
電商用戶流失分析	業務理解：流失定義爭議大；資料準備：多渠道行為日誌整合	行銷、產品、技術各部門對「流失」定義不一致	在業務理解階段獲得跨部門的定義共識
金融詐欺偵測系統	模型建構：嚴重類別不平衡；部署：需要即時推論低延遲	詐欺標注資料獲取困難、模型上線後的維護	建立標注反饋迴路（人工審查結果回饋進訓練資料）
供應鏈需求預測	業務理解：預測的粒度（SKU 級？類別級？）影響資料需求	外部因素（原料短缺、匯率）難以量化進模型	把模型預測和業務判斷的混合決策流程設計好
客戶終身價值模型	評估：LTV 要幾年後才能驗證真實性	長時間跨度讓評估回饋週期很長	用中間代理指標（3 個月消費金額）作為早期評估
工廠品質改善分析	資料理解：感測器資料量龐大，信噪比低	製程工程師和資料科學家的跨專業溝通	讓製程工程師深度參與特徵工程（領域知識）
媒體內容推薦	部署：推薦結果的 A/B 測試設計複雜	用戶對推薦多樣性的期待難以量化	定義多維度評估指標（相關性、多樣性、新鮮度）

常見誤區

誤區 1：「業務問題已經很清楚了，可以直接跳到資料分析」

這是分析專案失敗的第一大原因。問題的清晰往往是表面上的，業務主管說的「很清楚的問題」，往往包含了大量的隱含假設和待確認的細節，如果不在開始前探明這些，等到分析做完之後才發現偏差，損失是巨大的。

舉一個常見的例子：行銷總監說「幫我分析一下廣告效果」，這個問題聽起來很清楚，但實際上包含了至少以下幾個需要確認的維度：

「廣告效果」是指哪個指標？點擊率（CTR）、轉換率、每獲取客戶成本（CPA）、廣告支出回報率（ROAS），還是更長期的客戶終身價值（LTV）？這些指標的優化方向有時是相互矛盾的——一個把 CPA 降到最低的廣告策略，可能帶來大量低質量的客戶，長期 LTV 反而更低。

分析的時間範圍是什麼？最近一個月的廣告效果，還是要和去年同期比較，還是評估某個特定的廣告活動？不同的時間範圍可能給出完全相反的結論（一個季末的廣告活動在短期看效果差，但拉長到半年看可能效果很好）。

分析結果用來做什麼決策？預算分配（哪個渠道多投？）、廣告創意優化（哪個文案更好？）、還是評估代理商績效？不同的決策目的需要不同粒度的分析。

業務理解階段的核心輸出應該是一份和業務主管達成共識的問題定義文件，明確記錄：問題的業務背景、分析目標（業務目標 + 技術目標）、成功標準、資料範圍、時間限制。這份文件在專案過程中既是方向指南，也是在最終交付時評估「分析有沒有解決業務問題」的依據。

誤區 2：「模型精準度高了，分析專案就成功了」

高精準度的模型部署後沒有產生業務價值，在業界是非常常見的現象。有一個著名的說法：「資料科學家關心 AUC，業務主管關心 KPI，這兩件事有時完全不相關。」

技術指標（AUC、RMSE、Precision）衡量的是模型在測試集上的預測能力，但業務價值取決於：模型預測結果是否被正確整合進決策流程、業務執行團隊是否理解和信任模型的輸出、基於模型的行動是否能實際改善業務指標。

一個信用評分模型的 AUC 從 0.78 提升到 0.82，在統計上是顯著的進步，但如果：信貸審查員不信任模型（覺得「模型不了解行業特殊情況」），繼續主要依靠人工判斷；或者模型的輸出方式讓業務人員難以使用（輸出是一個分數，但業務人員不知道這個分數應該在什麼情況下接受、在什麼情況下人工複核）——那麼這 4% 的 AUC 提升對業務幾乎沒有影響。

真正的分析專案成功是：模型被實際用於業務決策，並且有可量化的業務效果（如違約率降低 X%、貸款審核效率提升 Y%）。這要求分析師從一開始就和業務執行團隊緊密合作，確保模型的輸出方式、閾值設定、例外處理流程都是為業務場景量身設計的。

誤區 3：「做完一個完整的分析就算完成，不需要後續維護」

這種心態把資料分析視為一次性的「建造工程」，而忽略了它本質上是一個需要持續維運的「服務」。特別是對於部署在生產環境中的機器學習模型，「完成部署」只是另一個維護週期的開始。

資料漂移的問題在大數據分析模組前幾節已經詳細討論過：用戶行為改變、業務環境變化、新競爭對手進入市場，都會讓曾經表現良好的模型逐漸退化。一個電商推薦模型在 2019 年訓練時效果很好，在 2020 年疫情改變消費行為後，如果不更新模型，效果可能急劇下降。

除了模型退化，還有資料管道的脆弱性：上游資料格式改變、資料量突然增大或減少、新的資料品質問題出現，都可能在不知不覺中讓分析結果失真。沒有監控的分析系統，可能在很長一段時間內都在靜默地輸出錯誤的結論，直到有人注意到業務決策的異常為止。

正確的做法是在分析專案的設計階段，就把「維護需求」一併規劃進去：多久重新訓練一次模型？監控哪些指標（輸入資料的統計分佈、模型的預測分佈、最終的業務指標）？異常告警觸發後的處理流程是什麼？誰負責定期審查模型的業務效果？只有把這些問題回答清楚，分析專案才算真正有一個可持續的閉環。

小練習

練習 1：把模糊的業務問題轉換為分析問題

一家台灣的連鎖便利商店集團，高層主管在月會上提出：「我們的鮮食商品（便當、御飯糰、三明治）最近浪費太嚴重了，請資料團隊分析一下，能不能減少報廢。」

請完成以下業務理解任務：

列出你需要向主管釐清的 5 個問題。
假設主管給了你合理的答案，把這個模糊問題轉換為一個清晰的分析問題定義（包含：業務目標、分析目標、成功標準、資料需求）。

練習 2：設計分析專案的 CRISP-DM 計劃

繼續上題的鮮食報廢分析專案。假設資料團隊有兩個分析師，時間限制是 8 週。請設計一個 CRISP-DM 為基礎的分析計劃：

把 8 週工作分配到 CRISP-DM 的各個階段，說明每個階段的主要工作內容和預期產出。
識別這個專案最可能遇到的 2-3 個風險，並提出對應的緩解策略。
最終交付物應如何呈現，才能讓門市管理者（非技術背景）能夠理解並採取行動？

查看答案

**練習 1：業務問題轉換** **（1）需要向主管釐清的 5 個問題** **問題 1：目前的報廢率是多少，業務上的容忍範圍是什麼？** 需要了解「嚴重」的基準。是行業平均的兩倍？是某個門市突然惡化？業務方有一個可接受的目標報廢率嗎（如從現在的 8% 降到 5%）？沒有明確的目標，無法定義成功。 **問題 2：報廢問題在全台灣所有門市都存在，還是集中在某些類型的門市或某些商品？** 這決定了分析的範圍和粒度。如果問題主要集中在高鐵站附近的門市（流量波動大）或特定的季節性商品，先針對高影響的子集分析，效果更大。 **問題 3：目前的訂貨決策是誰做的？用什麼方式？** 了解現有的決策流程，才能設計出「分析結果如何嵌入現有流程」。如果現在是門市店長人工訂貨，分析結果要輸出成「給店長的每日訂貨建議」；如果是總公司統一排定，輸出要對接後台系統。 **問題 4：有哪些資料是可以使用的？資料品質和完整性如何？** 最少需要：每個門市每個品項的每日銷售量 + 訂貨量 + 報廢量。此外，天氣資料、周邊門市的位置特徵（車站附近？辦公區？住宅區？）、節假日資訊都可能有用。了解資料的可得性才能評估技術可行性。 **問題 5：這個分析要支持什麼具體的業務決策，時效性要求是什麼？** 「幫我分析報廢」可以是一個事後的深度分析（找出系統性問題，改善訂貨政策），也可以是一個日常工具（每天為每個門市每個商品產生明日訂貨量的預測和建議）。前者適合深度研究，後者需要部署一個即時預測系統。時效性要求（月度報告？每日建議？）完全影響技術架構選擇。 **（2）轉換為清晰的分析問題** 假設主管的回答是：全台 1,000 家門市，目前平均鮮食報廢率約 7%，公司希望降至 5% 以下（減少報廢量 30%）；問題在全台都存在但高鐵站、大學附近門市特別嚴重；訂貨由門市店長每天人工決定；有 2 年的每日品項銷售和訂貨資料；希望做成每日訂貨輔助工具。 **業務目標**：透過資料驅動的鮮食訂貨決策，把全台平均鮮食報廢率從 7% 降至 5% 以下，預計年節省報廢成本約 X 萬元。 **分析目標**：建立一個每日為每家門市、每個鮮食品項預測「明日最佳訂貨量」的預測模型，在保持缺貨率不超過 1%（缺貨也是損失）的前提下，最小化報廢量。評估指標：預測訂貨量的 MAE（平均絕對誤差）低於歷史訂貨量的 ± 5%。 **成功標準**：在 A/B 測試中（隨機選 50 家門市使用新系統，50 家繼續人工訂貨），新系統門市的平均報廢率比對照組降低至少 1.5 個百分點，且缺貨率不上升超過 0.5 個百分點。 **資料需求**：過去 2 年的每日品項銷售量（實際售出量）、每日訂貨量、報廢量（按時段更佳）；門市屬性（地點類型、面積、附近競業數）；天氣資料（氣溫、降雨）；節假日和學校行事曆；行銷促銷活動紀錄。 --- **練習 2：8 週 CRISP-DM 分析計劃** **（1）時間分配和工作計劃** **第 1-2 週：業務理解 + 資料理解** 主要工作：完成與門市營運、商品管理部門的訪談（釐清業務流程和數據口徑）；存取並初步探索歷史 2 年的銷售和報廢資料；產出 EDA 報告（各門市、各品項類別的報廢率分佈、銷售量的時間模式）；識別資料品質問題。預期產出：資料品質報告 + 5 個初步業務假設（如「周五鮮食銷售量是周一的 2.5 倍，但訂貨量差距只有 1.8 倍，過量訂貨導致周五報廢率最高」）。 **第 3-4 週：資料準備（第一輪）** 主要工作：清洗資料（處理缺失的報廢記錄、品項名稱的不一致等）；整合外部資料（天氣、節假日）；計算基礎特徵（過去 7 天/30 天的銷售移動平均、季節性指數）；準備訓練集和測試集（按時間分割）。預期產出：可供第一輪建模使用的特徵資料集。 **第 5-6 週：模型建構 + 評估（第一輪）** 主要工作：訓練第一個基準模型（如 Prophet 或 LightGBM）；計算各門市的預測誤差；與門市管理者進行中期評審（展示初步結果，收集對「訂貨建議」呈現方式的反饋）；根據反饋優化特徵工程和模型參數。預期產出：基準模型 + 中期評審報告 + 下一步改進計劃。 **第 7 週：模型優化 + 業務評估** 主要工作：按第一輪反饋改進特徵（如加入「門市鄰近辦公區的上班族數量估計」）；完成模型優化；計算預計的業務影響（如果採用模型建議，歷史資料模擬顯示報廢量可降低 X%）；完成倫理和偏見審查（是否對某類門市有系統性的預測偏差）。預期產出：最終模型 + 業務影響模擬報告。 **第 8 週：部署評估 + 交付** 主要工作：設計 A/B 測試方案（哪 50 家門市先試點，如何分組確保可比性）；設計訂貨建議的輸出界面（店長能看懂的報表格式）；完成技術交接文件；進行最終發表。預期產出：最終分析報告 + A/B 測試方案 + 系統交接文件。 **（2）主要風險和緩解策略** **風險 1：歷史報廢量資料記錄不完整或不準確** 大多數便利商店系統記錄「訂貨量」和「銷售量」，但「報廢量」往往是用「訂貨量 - 銷售量」推算，可能不反映實際的報廢行為（如提前下架但未正式記錄的情況）。緩解策略：在資料理解階段就進行資料品質審計，如果報廢量資料嚴重不可靠，改用「最佳訂貨量 ≈ 實際銷售量 × （1 + 可接受缺貨率）」作為訓練目標，繞過不可靠的報廢記錄直接優化訂貨量。 **風險 2：門市店長不信任或不採用系統建議** 資料驅動的訂貨建議和店長的「業務直覺」可能衝突，特別是在特殊事件（附近有大型活動）時，系統可能給出保守建議而店長知道要多訂。如果店長不用，所有分析都白費。緩解策略：在產品設計上，訂貨建議要提供「建議量 + 置信區間」，並允許店長手動覆蓋（同時記錄覆蓋原因）；在試點期間密切跟蹤採用率，對採用率低的門市進行訪談，了解阻力所在，快速迭代改進。 **風險 3：8 週內無法獲得模型上線的 IT 資源** 把模型真正整合進現有的訂貨系統可能需要 IT 部門的配合，而 IT 資源往往有排程，可能 8 週內無法完成系統整合。緩解策略：把「完整系統整合」和「分析結果交付」分開來。8 週的工作聚焦在：完整的分析報告 + 預測模型原型 + A/B 測試設計。系統整合作為下一個工作階段，由 IT 部門另行排程。A/B 測試的最初幾週可以用「半手動」的方式（分析師每天產出建議 Excel 表格，由試點門市手動參考），在等待 IT 整合的同時先收集業務效果資料。 **（3）最終交付物的呈現方式** 針對非技術背景的門市管理者，交付物應分層設計： **執行摘要（1 頁）**：給高層主管看的。用圖表直觀展示「現況報廢率 vs 目標報廢率」、「採用系統建議後預估的節省金額」、「推薦的試點門市選取方式」。不出現任何技術術語。 **操作手冊（3-5 頁）**：給門市店長看的。用截圖和圖示說明「如何使用每日訂貨建議表格」、「建議的數字是怎麼來的（用一句話解釋：根據過去 30 天的銷售趨勢、明天的天氣預測和是否為假日計算）」、「什麼時候可以考慮手動調整建議量（如附近有大型活動）」。 **技術報告（完整版，20-30 頁）**：給資料團隊和 IT 部門看的。詳細說明資料處理方式、模型架構、評估指標、部署要求、維護計劃。 **互動式看板（選配）**：用 Tableau 或 Power BI 建立一個讓門市區域主管可以按地區、門市類型篩選的「報廢率監控看板」，讓後續的效果追蹤可視化、可即時更新。

關鍵字自我檢核

✅ CRISP-DM ✅ Cross Industry Standard Process for Data Mining ✅ 業務理解 ✅ Business Understanding ✅ 資料理解 ✅ Data Understanding ✅ 資料準備 ✅ Data Preparation ✅ 模型建構 ✅ Modeling ✅ 評估 ✅ Evaluation ✅ 部署 ✅ Deployment ✅ 問題定義 ✅ Problem Definition ✅ 利害關係人 ✅ Stakeholder ✅ 資料分析師 ✅ Data Analyst ✅ 分析專案 ✅ Analytics Project ✅ KPI ✅ 洞見溝通 ✅ Insight Communication ✅ 資料驅動決策 ✅ Data-Driven Decision