跳到主要內容

AD 101 · 模組 1

發現問題

從個人工作案例出發,學會分辨問題與解法、辨識工作摩擦,並釐清 user、owner 與可衡量的結果。

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

資訊

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

學習目標

  • 辨識 solution bias,選出不含預設工具且可觀察的 problem statement。
  • 以頻率、等待、重工、錯誤、搜尋、重複輸入、判斷負荷辨識機會,但明確說明高 friction 不代表一定需要 AI。
  • 分清 user、process owner、decision owner 與 measurable outcome。

問題與解法

25 分鐘

問題與解法(Problem vs Solution)

學習目標:辨識 solution bias,選出不含預設工具且可觀察的 problem statement。

很多 AI 導入的討論一開始就說「我們應該用 AI 做 XX」,這其實已經是一個解法,不是問題。solution bias 指的是還沒確認問題之前,就先假設了工具或做法。好的 problem statement 只描述「現在什麼工作結果不好」,不預設要用什麼工具解決,而且要可觀察、可被第三人檢查。

Solution-bias 檢查清單
欄位說明
有沒有提到工具或技術名稱?有 → 先移除,只留下工作結果
能不能被第三人觀察或查證?不能 → 補上可觀察的證據
是不是只是「應該要有」的期望?是 → 改寫成目前實際發生的落差
工作情境

某分校行政室提出:「我們應該用 AI 幫忙寫會議紀錄。」這句話已經預設了工具(AI)與做法(寫會議紀錄)。改寫成問題陳述:「每次跨部門會議後,待辦事項平均要三天才會整理成書面紀錄並分派給負責人,導致部分事項被遺漏。」後者不提工具,只描述可觀察的落差。

  1. 找出工具字眼
    圈出句子裡任何工具、技術或產品名稱(AI、聊天機器人、系統、App),先把它們整段拿掉。
  2. 寫下可觀察的落差
    用數字或可查證的事實描述「現在」與「期望」之間的落差,例如處理天數、件數、錯誤率、等待時間。
  3. 找第三人檢查
    請沒有參與討論的同事讀一次,確認句子完全沒有預設解法,也能看出具體、可查證的落差。
工作情境(對照案例)

圖書館櫃台提出:「我們應該導入 AI 問答機器人回覆讀者問題。」這同樣是 solution bias,一開口就先決定了工具。改寫成問題陳述:「開館時間內,櫃台人員平均每天被問到 40 次相同的借閱規則問題,尖峰時段讀者常等待超過 10 分鐘才獲得回應。」這句話同樣不提工具,只描述可被排班紀錄查證的落差。

  • 句子裡出現「導入」「使用」「上線」等動詞,後面接工具或系統名稱時,多半是 solution bias 的訊號。
  • 「應該要更有效率」「應該更智慧」這類形容詞堆疊,無法被第三人觀察或查證,必須追問具體數字。
  • 可觀察的落差通常能回答「現在是多少、理想是多少、差距多大」三個問題。
  • 同一個問題陳述可以同時被不只一種做法解決(流程調整、人力調配、工具協助),這正是好問題陳述的特徵。

資訊

Human、AI、Human:人先確認問題與判斷,AI 在確認之後才協助執行,最終結果仍由人驗證與負責。

注意

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

下列哪一句最符合「不含預設工具且可觀察」的 problem statement?

下列哪一句最符合「不含預設工具且可觀察」的 problem statement?

重點: 好的問題陳述描述「現在什麼結果不好」,不預設要用什麼工具解決。

工作摩擦與機會

30 分鐘

工作摩擦與機會(Work Friction & Opportunity)

學習目標:以頻率、等待、重工、錯誤、搜尋、重複輸入、判斷負荷辨識機會,但明確說明高 friction 不代表一定需要 AI。

Work friction 是工作中消耗時間與精力、卻不是工作本身目的的部分:等待審核、重複輸入同樣的資料、為了找一份文件花十分鐘、同一件事因為出錯要重做。辨識 friction 的七個訊號是:頻率高、等待時間長、常重工、容易出錯、需要搜尋、需要重複輸入、需要高負荷的判斷。但要小心:friction 高不代表答案就是 AI,也可能是流程設計問題,需要先改流程而不是加工具。

七個摩擦訊號
欄位說明
頻率這件事多常發生?
等待有沒有人在等結果?等多久?
重工同一件事要做第二次嗎?
錯誤多常出錯?後果是什麼?
搜尋要花多少時間找資料或文件?
重複輸入同樣的資料要打第二次嗎?
判斷負荷需要多少專業判斷才能完成?
工作情境

教務處每學期要把三個系統的選課資料手動比對一次,耗時約 16 小時,且常因人工輸入產生誤差。摩擦訊號:高頻率(每學期)、重複輸入、容易出錯。但進一步了解後發現,三個系統本可直接串接,先解決資料源頭的重複,才是比先導入 AI 比對更根本的做法。

  • 頻率:圖書館每天要手動統計到期提醒名單,一年超過 300 次,屬於高頻率訊號。
  • 等待:採購申請送出後,平均要等 4 天才輪到承辦人審核,中間沒有人知道案子進度。
  • 重工:報帳單據被退回修改的比例若超過兩成,代表重工訊號明顯。
  • 錯誤:手動輸入成績到兩個系統時,每學期平均發現 3-5 筆不一致,屬於錯誤訊號。
  • 搜尋:承辦人每次處理陳情案前要花 20 分鐘翻找過去類似案例,屬於搜尋訊號。
  • 重複輸入:同一位學生的基本資料在報名表、繳費單、名冊上各打一次,屬於重複輸入訊號。
  • 判斷負荷:每件獎助學金申請都需要承辦人逐案判斷資格邊界,屬於判斷負荷訊號。
工作情境(對照案例:流程問題而非 AI 問題)

圖書館跨館借閱申請摩擦很高:平均要等 5 天才能收到書。訊號看起來像是「判斷負荷」,但追問後發現真正原因是調書人員只在每週二、四兩天出車,與借閱需求無關。這種情況下,調整出車頻率比導入任何 AI 工具更直接有效。

資訊

Human、AI、Human:人先確認問題與判斷,AI 在確認之後才協助執行,最終結果仍由人驗證與負責。
自我檢測

某單位發現「經費核銷」流程摩擦很高(等待審核 5 天、常被退件重填)。下列哪一個判斷最正確?

某單位發現「經費核銷」流程摩擦很高(等待審核 5 天、常被退件重填)。下列哪一個判斷最正確?

重點: 摩擦訊號幫你找到值得探索的地方,但下一步永遠是先問「為什麼」,不是急著加工具。

使用者、擁有者與結果

35 分鐘

使用者、擁有者與結果(User, Owner, Outcome)

學習目標:分清 user、process owner、decision owner 與 measurable outcome。

一個工作問題常常牽涉不只一個人:user 是實際執行這項工作或直接受影響的人;process owner 是負責這個流程整體運作的人;decision owner 是有權核准改變或承擔結果責任的人。三者可能是同一人,也可能不是。沒有先分清楚,Use Case 討論很容易找錯人、或漏掉真正該負責審查的人。desired outcome 則必須是可衡量的結果,而不是活動本身(例如「回覆更快」而不是「用 AI 回信」)。

四個欄位一次分清楚
欄位說明
User誰實際做這件事、誰受影響?
Process owner誰負責這個流程本身?
Decision owner誰有權核准改變、承擔結果?
Desired outcome可衡量的結果是什麼(不是活動)?
工作情境

某系辦公室的成績複查申請流程:user 是提出複查的學生與承辦助理;process owner 是系主任辦公室;decision owner 是教務長(涉及成績變更的最終核准)。desired outcome 寫成「複查申請從收件到回覆平均縮短到 5 個工作天內」,而不是「用 AI 自動回覆學生」。

  1. 列出所有相關角色
    先寫下這項工作牽涉到的每一個人或單位,不急著分類。
  2. 標出 user
    誰實際執行這項工作,或直接承受結果(例如等待回覆的學生)?
  3. 標出 process owner 與 decision owner
    誰負責流程日常運作?誰有權核准改變、承擔最終結果責任?兩者常常不是同一人。
  4. 把 outcome 寫成可衡量的句子
    確認句子描述的是結果(時間、件數、比例),而不是「使用了什麼工具」。

活動式寫法(偏離 outcome)

  • 「導入 AI 系統協助複查。」
  • 「開始使用新的審核流程。」
  • 「讓大家都學會用新工具。」

結果式寫法(符合 desired outcome)

  • 「複查申請平均處理天數從 9 天降到 5 天以內。」
  • 「審核退件率從 30% 降到 10% 以下。」
  • 「學生申請後 24 小時內收到進度通知的比例達到 95%。」

資訊

Human、AI、Human:人先確認問題與判斷,AI 在確認之後才協助執行,最終結果仍由人驗證與負責。
自我檢測

下列哪一個最符合「desired outcome」的寫法?

下列哪一個最符合「desired outcome」的寫法?

重點: 先分清楚 user、process owner、decision owner 是誰,再把 outcome 寫成可衡量的結果,Use Case 才站得住腳。

接下來做什麼?