跳到主要內容
NTPU AI Learn

IL 302 · 模組 2

營運與組織

設計系統與資料的所有權、使用者支援模式、能力培養計畫，並釐清決策責任（RACI）。

開始第一節
  • 時長240 分鐘
  • 難度架構
  • 先備知識已完成 Module 1 的投資組合與價值帳本
已完成 0 / 4

學習目標

  • 為系統與資料指定明確的所有權與更新決策權。
  • 設計涵蓋一線支援、升級與教育訓練的使用者支援模式。
  • 用 RACI 把能力培養與日常決策責任分配給具體角色，而不是部門名稱。

系統與資料的所有權

60 分鐘

一個成功的專案背後，誰真的擁有這個系統？

IL 301 Pilot 期間，系統與資料的所有權通常暫時掛在專案團隊底下：出問題找專案負責人就好。進入常態營運後，這個暫時安排必須變成明確的組織責任，否則專案結束、成員異動時，系統會變成沒人真正負責的孤兒系統。

系統與資料所有權必須回答的問題
項目要問的問題
系統所有權這套 AI 工具／整合，正式移交後由哪個角色負責維運與版本升級？
資料所有權這套系統使用與產出的資料，由誰負責分類、保存期限與存取權限的持續管理？
內容／知識更新知識庫或參考文件過期或需要修訂時，誰有權核准更新，誰負責實際執行？
預算所有權持續的授權費、維運與覆核人力成本，編列在哪個部門的預算裡？

注意

常見錯誤：所有權寫成「IT 部門」或「客服部門」這種部門名稱，而不是具體角色。部門名稱在人員異動或組織改組時會失去意義；正式的營運模式需要寫清楚「哪個職位」，並在職位異動時有交接機制。
  1. 第一步
    列出這套系統會用到的每一份資料與每一個元件（沿用 IL 202 的資料盤點）。
  2. 第二步
    為系統、資料、內容更新與預算四項，分別指定具體角色，而不是部門。
  3. 第三步
    寫下如果目前的角色離職或調動，交接程序是什麼；沒有交接程序視為缺口。

重點: Pilot 結束後，「專案負責人」這個臨時角色必須被拆解成具體、可交接的正式所有權，否則系統會變成沒人管的孤兒。

使用者支援模式

60 分鐘

使用者支援模式：AI 給錯答案時，使用者該找誰？

常態營運跟 Pilot 期間最大的差別，是使用者不再有專案團隊隨時待命。使用者支援模式要清楚回答：AI 工具出現錯誤輸出、系統中斷或使用者不確定該不該相信結果時，第一時間該怎麼處理、找誰處理。

使用者支援模式的三個層級
層級負責處理典型情境
第一線（使用者自己）依教育訓練學到的判斷準則，先自行判斷是否可信、是否需要人工覆核AI 輸出看起來合理但使用者不完全確定
第二線（內部支援窗口）處理明確的錯誤輸出、操作問題與升級請求，記錄問題類型AI 給出明顯錯誤的答案，或系統操作異常
第三線（技術／治理負責人）處理系統性問題、資料或權限缺口，決定是否需要暫停功能同一類錯誤重複發生，顯示系統性問題而非單一案例

資訊

使用者支援模式必須包含教育訓練：使用者要知道「什麼時候該轉人工處理」，而不是遇到任何不確定都繼續往下做，也不是遇到任何小問題都升級到第三線。這個判斷準則本身就是 IL 202 異常演練（Module 3）產出的 runbook 內容，這裡要把它變成正式支援流程的一部分。
  1. 第一步
    為每個層級指定具體角色與聯繫方式（不是部門信箱，而是實際會被監看的管道）。
  2. 第二步
    訂出使用者判斷「該不該轉人工」的具體準則，並排入教育訓練內容。
  3. 第三步
    設計問題記錄機制，讓重複出現的錯誤類型能被第三線發現並升級為系統性問題處理。

重點: 沒有明確支援層級的系統，會讓使用者要嘛盲目相信 AI 輸出，要嘛完全不敢用；兩者都不是常態營運該有的狀態。

能力培養與決策責任（RACI）

60 分鐘

用 RACI 分配能力培養與日常決策責任

RACI 把每一項工作或決策，標記出 Responsible（實際執行）、Accountable（最終負責、只能有一人）、Consulted（事前徵詢意見）、Informed（事後被告知）四種角色關係。企業轉型的常態營運，需要用 RACI 把「能力培養」與「日常決策」兩類工作講清楚，避免每次出狀況才臨時決定誰該負責。

RACI 範例欄位（以「知識庫內容更新」這項決策為例）
活動ResponsibleAccountableConsultedInformed
知識庫內容更新內容維運人員（具體角色）客服部門流程負責人法務／合規（涉及政策變更時）客服團隊全體
使用者教育訓練排程教育訓練負責人客服部門流程負責人技術管理員（提供系統操作內容）參與訓練的使用者

注意

常見錯誤：同一項活動的 Accountable 欄位填了兩個以上角色，或乾脆留白。Accountable 只能有一個人；如果覺得需要兩個人共同負責，代表這項活動應該拆成兩個更小的決策分開處理，而不是讓責任變得模糊。
  1. 第一步
    列出常態營運需要的能力培養活動（教育訓練、新人上手、進階使用者培養）與日常決策（內容更新、例外處理、功能調整）。
  2. 第二步
    為每一項活動填上 RACI 四個欄位，Accountable 只能填一個具體角色。
  3. 第三步
    把這份 RACI 表與 Module 2 第一張投影片的所有權表對照，確認沒有互相矛盾的責任歸屬。

重點: RACI 的價值不在於填滿表格，而在於逼問「這件事出狀況時，到底該找誰」，並確保答案只有一個。

範例：營運模式與 RACI

60 分鐘

範例（SYN-CS-001）：客服知識助理的營運模式與 RACI

延續 Module 1 的合成案例，示範服務公司 A 的客服知識助理已從客服部門的 Pilot 進入小範圍常態採用。以下示範一份簡化的營運模式與 RACI 摘要，供你對照自己專案的版本。

客服知識助理系統與資料所有權（合成範例）
項目所有權角色
系統維運技術管理員（合成角色，非部門名稱）
資料所有權客服部門流程負責人，會同隱私負責人管理保存與存取
內容更新核准客服部門流程負責人核准，內容維運人員實際執行
預算客服部門年度營運預算，含 AI 工具授權與覆核人力時數
客服知識助理使用者支援層級（合成範例）
層級角色與管道
第一線客服人員依教育訓練準則自行判斷是否轉人工
第二線內部支援窗口（合成角色），處理明確錯誤輸出與操作問題，記錄問題類型
第三線技術管理員與隱私負責人，處理重複出現的系統性問題與權限缺口
自我檢測

一份 RACI 表中，「知識庫內容更新」這項活動的 Accountable 欄位同時填了「客服部門流程負責人」與「技術管理員」兩個角色。這樣寫最主要的問題是什麼？

一份 RACI 表中，「知識庫內容更新」這項活動的 Accountable 欄位同時填了「客服部門流程負責人」與「技術管理員」兩個角色。這樣寫最主要的問題是什麼？

重點: 把所有權、支援層級與 RACI 放在同一份文件裡對照，才能發現「這件事到底誰負責」中間有沒有缺口或重複。

另存 PDF

接下來做什麼？