跳到主要內容

AD 103 · 模組 1

評估

建立 portfolio 思維,分開評估 Value 與 Outcome、Feasibility 與 Readiness、Risk 與 Governance。

開始第一節
已完成 0 / 4
同步我的進度加入梯次後,進度可跨裝置保存,講師也能看到

資訊

加入後,你已完成的模組編號會連同「學員代碼」傳送給講師,講師可以看到你的進度。請使用講師提供的代碼,不要輸入姓名、公司機密或其他個資。進度資料與該梯次的其他資料一起保存。

學習目標

  • 在有限資源下以 portfolio 而非單一案例思考 dependency、capacity 與 learning value。
  • 把 activity 與 outcome 分開,價值可包含時間、品質、容量、成本、服務與策略。
  • 技術可行性與組織準備度分開記錄。
  • 風險保持可見,不用負分藏入總分;需要時轉 governance review。

組合思維

25 分鐘

組合思維(Portfolio Thinking)

學習目標:在有限資源下以 portfolio 而非單一案例思考 dependency、capacity 與 learning value。

當手上有多個 Use Case 候選時,不能逐一單獨評估、看哪個「分數最高」就做哪個。Portfolio thinking 是同時考慮:案子之間有沒有相依性(dependency,例如一個案子做完才能做下一個)、團隊目前的執行容量(capacity)、以及先做小案子帶來的學習價值(learning value,例如先驗證一個假設,降低後面案子的風險)。

Portfolio 思維三面向
欄位說明
Dependency案子之間有沒有先後相依關係?
Capacity團隊目前能同時執行幾個案子?
Learning value先做哪個案子能降低後面案子的風險?
工作情境

三個候選 Use Case:A(請假流程自動化)、B(財務報表摘要)、C(採購比價協助)。B 需要先確認財務資料授權(dependency),團隊這季只有一組人力(capacity),C 規模小、能快速驗證「AI 協助比價是否可信」的假設(learning value)。因此可能先做 C,再視結果決定 A 或 B。

  • Dependency 延伸案例:Use Case D(跨系統報表整合)要等 Use Case E(資料倉儲上線)完成後才能開始,兩者有明確先後關係。
  • Capacity 延伸案例:團隊同時只能深度支援一個 pilot,若硬塞三個案子同時上線,每個都會因人力分散而延遲。
  • Learning value 延伸案例:先做一個小規模的分類案子,驗證「AI 分類結果人工修正率能不能控制在 10% 以內」,這個學習結果能套用到後面更大的案子。
  • 當三個面向互相衝突時(例如 learning value 最高的案子恰好 capacity 不足),應該誠實記錄取捨,而不是強行排出單一名次。

逐案打分、各自決定

  • 每個案子單獨評分,分數高的先做。
  • 沒有考慮案子之間的先後關係。
  • 容易同時啟動太多案子,導致每個都做不好。

Portfolio 思維

  • 同時檢視所有候選案子之間的關係。
  • 先確認哪些案子彼此相依,排出合理順序。
  • 依團隊容量決定同時執行的數量,並優先選學習價值高的案子驗證假設。

資訊

Human、AI、Human:人做最終的優先順序判斷與治理決定,AI 可協助整理比較資料,但不能替組織做最終決定。

注意

資料安全提醒:本課程所有練習一律使用課程提供的模擬情境檔案,不含任何真實機構或個人資料。
自我檢測

手上有五個 Use Case 候選,下列哪一種做法最符合 portfolio thinking?

手上有五個 Use Case 候選,下列哪一種做法最符合 portfolio thinking?

重點: 面對多個候選 Use Case,要用組合思維一起看,而不是逐一單獨打分數。

價值與結果

25 分鐘

價值與結果(Value & Outcome)

學習目標:把 activity 與 outcome 分開,價值可包含時間、品質、容量、成本、服務與策略。

評估 Value 時,先確認寫的是 outcome(結果)還是 activity(活動)。Value 不是單一維度,可能包含:時間(縮短處理時間)、品質(減少錯誤)、容量(同樣人力能處理更多案件)、成本(降低支出)、服務(提升滿意度)、策略(支持組織長期目標)。同一個 Use Case 可能同時帶來好幾種價值,應該分別寫清楚,而不是含糊地說「有價值」。

價值的六個面向
欄位說明
時間處理時間縮短多少?
品質錯誤或重工減少多少?
容量同樣人力能多處理多少?
成本支出降低多少?
服務滿意度或體驗提升多少?
策略支持哪個組織長期目標?
工作情境

請假流程自動化的 Value:時間(核准時間從 3 天縮短到 1 天)、容量(人事同樣人力可多處理 30% 案件)、品質(減少因手動登錄產生的錯誤)。三者分開寫,而不是只說「效率提升」。

工作情境(對照案例:採購比價協助)

採購比價協助的 Value 拆解:時間(比價作業從平均 2 小時縮短到 30 分鐘)、品質(減少因人工抄錄報價單產生的金額錯誤)、服務(廠商詢價回覆速度提升,抱怨件數下降)、策略(支持組織「數位化行政流程」的年度目標)。四個面向分開寫,審查者才能分別判斷哪個面向最值得投入資源。

  • 時間:處理一件案子從多久縮短到多久?用具體數字,不要只說「比較快」。
  • 品質:錯誤率、重工率、申訴件數等指標是否下降?
  • 容量:同樣人力能多處理多少件?或原本需要加班的狀況是否改善?
  • 成本:是否降低了外包費用、材料耗損或其他直接支出?
  • 服務:使用者或申請人的滿意度、等待體感是否改善?
  • 策略:是否支持組織公告過的長期目標(例如數位轉型、永續、服務品質提升)?

資訊

Human、AI、Human:人做最終的優先順序判斷與治理決定,AI 可協助整理比較資料,但不能替組織做最終決定。
自我檢測

某 Use Case 的 Value 寫成:「大家會覺得工作更輕鬆。」下列哪一個改寫最符合本課要求?

某 Use Case 的 Value 寫成:「大家會覺得工作更輕鬆。」下列哪一個改寫最符合本課要求?

重點: Value 要拆成具體面向分別描述,不能只用一句模糊的感受帶過。

可行性與準備度

20 分鐘

可行性與準備度(Feasibility & Readiness)

學習目標:技術可行性與組織準備度分開記錄。

Feasibility(可行性)問的是技術與整合複雜度:資料能不能取得、系統能不能串接、AI 能力是否足夠。Readiness(準備度)問的是組織面:owner 是否明確、workflow 是否能配合改變、團隊是否有能力執行、是否符合現有政策。兩者容易被混在一起,但技術上可行不代表組織準備好了,反之亦然,必須分開記錄。

兩個獨立問題
欄位說明
Feasibility資料、系統、AI 能力是否足夠?
ReadinessOwner、workflow、team capacity、政策是否準備好?
工作情境

請假流程自動化:Feasibility 高(資料在現有系統中,串接不複雜);Readiness 中等(人事單位 owner 明確,但主管習慣紙本簽核,需要變革管理)。分開記錄才能看出真正該投入資源的是「準備度」而非「技術」。

  1. 先問 Feasibility
    需要的資料在哪裡?格式是否乾淨?要串接的系統是否有開放介面?
  2. 再問 Readiness
    Owner 是誰?這個單位的工作方式能不能配合改變?團隊有沒有時間與能力執行?
  3. 分別標記高中低
    兩個維度各自標記,不要互相影響彼此的判斷。
  4. 找出真正該投入的資源
    哪一個維度低,就代表那裡才是接下來該投入時間溝通或準備的地方。

Feasibility 高、Readiness 低

  • 資料齊全、系統容易串接,技術上隨時能做。
  • 但沒有單位願意當 owner,或主管習慣舊流程、抗拒改變。
  • 該投入的是變革管理與溝通,不是技術資源。

Feasibility 低、Readiness 高

  • 單位非常有意願改變、owner 明確、團隊準備充分。
  • 但資料分散在多個系統、格式不一致,整合成本高。
  • 該投入的是資料整理與技術評估,而不是說服組織。

資訊

Human、AI、Human:人做最終的優先順序判斷與治理決定,AI 可協助整理比較資料,但不能替組織做最終決定。
自我檢測

某 Use Case 技術上很容易實作(資料齊全、API 現成),但沒有人願意負責上線後的維運。這反映了什麼?

某 Use Case 技術上很容易實作(資料齊全、API 現成),但沒有人願意負責上線後的維運。這反映了什麼?

重點: 技術可行不代表組織準備好了,Feasibility 與 Readiness 永遠分開記錄。

風險與治理

20 分鐘

風險與治理(Risk & Governance)

學習目標:風險保持可見,不用負分藏入總分;需要時轉 governance review。

風險評估的目的不是扣分,而是讓決策者清楚看見「這裡有什麼風險、後果是什麼」。如果把風險折算成負分藏進一個總分裡,反而會讓真正需要人工審查的高風險案子被平均掉、不容易被看見。遇到明顯的高風險(例如涉及個資、財務決策、法規遵循),應該直接轉交 governance review,而不是讓 Use Case 自己通過。

風險處理原則
欄位說明
風險描述後果是什麼、機率如何?
可見性風險是否清楚呈現,而不是藏進總分?
升級是否需要轉交 governance review?
工作情境

某 Use Case 涉及自動核准超過一定金額的採購申請。風險:若誤判,可能造成財務損失與稽核問題。做法:不是給這個案子扣分後仍計入總分通過,而是明確標示「高風險,需 governance review」,轉交財務與法遵單位審查。

工作情境(對照案例:學生成績資料)

另一個 Use Case 想用 AI 協助分析學生成績趨勢,提供導師輔導建議。這涉及學生個資與學業表現,風險:若分析錯誤或外洩,可能影響學生權益與機構信任。做法:不是用「輔導效果看起來不錯」的總分掩蓋風險,而是明確標示「涉及學生個資,需先經個資保護與教務單位共同審查」,在審查通過前不進入試行階段。

  • 個人資料風險:是否涉及學生、員工或其他個人的敏感資訊?
  • 財務風險:是否涉及金額核准、預算分配或可能造成財務損失?
  • 法規遵循風險:是否涉及必須符合特定法規或政策的決定?
  • 安全風險:若輸出錯誤,是否可能影響人身安全或重大權益?
  • 以上任一項明顯成立,就應該優先轉交 governance review,而不是等所有維度算完總分再決定。

資訊

Human、AI、Human:人做最終的優先順序判斷與治理決定,AI 可協助整理比較資料,但不能替組織做最終決定。
自我檢測

下列哪一個做法最符合本課「風險不藏入總分」的原則?

下列哪一個做法最符合本課「風險不藏入總分」的原則?

重點: 風險要清楚可見、獨立記錄,高風險案子該直接升級到治理審查,而不是被總分平均掉。

接下來做什麼?