Day 03 確認了 JSON 有沒有被改壞。
但 JSON 寄出去後，申請人還得跨系統開單、送審、分派與追蹤。
這是展開第三代改版的重點項目。

第二代的 DAP 已經能讓使用者選擇申請項目、整理資料，最後產出 JSON，並寄到申請人的信箱。

這一代其實只完成單據申請流程的一半而已。原本要人工申請，因為有了 web 畫面，更方便勾選申請項目。然而，申請完寄出 JSON 後，申請人還有另一段工作要執行。

JSON 是申請資料的交付物，但不是申請人的完成點。

JSON 寄出去後，後面其實還有很長一段

申請人收到包含 JSON 的信件後，還要到既有單據系統開單，把 JSON 作為附件帶進去、填入識別資料、選擇主管並送審。

接著，管理員得讀取單據內容，判斷要交給哪些組別處理。有些申請只需要一組，有些可能涉及多組。各組開始作業後，還要追蹤進度、結案、通知申請人，最後再由申請人確認。

這些步驟不能全部視為多餘。主管覆核、責任分派與結案，本來就有治理和稽核意義。

真正讓我想改的，是同一份 JSON 還要由人帶到另一個系統重新開單；管理員也得一次次讀內容，判斷應交給誰。當時最花時間的地方，正是分派與跨組追蹤。

Google SRE 把手動、重複、可自動化的工作稱為 toil；但它也提醒，真正需要人類判斷與責任承擔的工作，不該只是為了自動化而被消除。(Google SRE Book)

我想減少的是跨系統搬資料和重複開單，不是把應該保留的審核責任一起拿掉。

第三代限時四個月：倒數計時開始

第二代花了九個月，把 Notebook 的操作搬到 Web，也累積了可沿用的前後端架構、API 和 12 項功能。第三代不是從零開始，但也不是換個顏色就結束。

我得在四個月內完成兩件大事：一邊調整既有頁面與入口，讓系統從產品分類轉向使用者任務；另一邊開發一套完整的編審放流程，處理送單、審核、分派、執行、通知與結案。這段時間不到第二代的一半，但兩個階段的範圍並不相同，不能直接拿來宣稱開發速度變成兩倍。

我當時把這四個月拆成幾個階段：

這是我第一次很明確感覺到：第三代的挑戰不是把功能做出來，而是要在有限時間裡，把既有系統的經驗、使用者流程和新的編審需求一起接起來。

所以第三代不只拉皮：我把單據生命週期帶回 DAP

第三代的第一個改變，是使用者在 DAP 選完項目、送出後，由系統直接建立申請單。使用者不必再從信件裡拿 JSON，到另一個平台做一次開單作業。

第二個改變是分派。申請人送出時，會選擇要交給哪一位主管覆核。案件仍會經過申請人主管、預算審查、執行者主管分派、執行同仁處理、執行主管覆核，最後回到申請人結案。每通過一個關卡，申請人都會收到通知信。

系統處理的是依申請內容，將案件路由給涉及組別的負責人。目前沒有提供管理員人工改派；原本需要管理員先讀單據、判斷該送到哪些組別的部分，改成由規則處理。

我想減少的是帶著資料跨系統轉手，不是移除該被保留的審核責任。

上線後我才發現：自動送單，也可能送得太多

自動分派上線後，單據流動變快，各組負責人收到案件的頻率也提高。這時候才出現一個流程盤點時沒有看清楚的問題：有些人收到單據後，發現自己其實沒有需要做的事。

我印象最深的是一類「資源調整」需求。原本它是一個大類，裡面包含成員調整、新增環境與預算調整三個子功能。流程盤點時，某個組別認為這一類單據都應該經過他們；但系統上線後，他們回饋真正需要處理的只有成員調整。新增環境與預算調整送到他們，只會多一道等待。

我們沒有補一個讓管理員手動改派的按鈕，而是把這個大類拆開。成員調整、新增環境與預算調整各自有自己的路由規則，單據才能更精準地送到真正需要處理的人。

這也讓我重新理解自動化。問題有時不是規則寫錯，而是需求一開始分得太粗。

例如，新增資料庫權限的申請通常只需要資料庫相關組別處理；雲端新專案則可能同時涉及預算、環境建立與不同權限，因此需要多個組別。單組或多組都不是問題，重點是路由依據要和實際工作相符。

自動化的完成不是「單據有送出」，而是「單據有送到真正需要處理的人」。

單據送對人後，還要讓每個人找得到自己的工作

把案件送出去還不夠。如果所有角色都只能在一大堆單據裡找自己的工作，使用者的困擾只是從外部單據平台搬回 DAP。

因此第三代規劃了「我的單據中心」：

工作單完成後，申請單會自動回到申請人手上，讓申請人確認並結案。信件通知讓申請人知道關卡正在推進；單據中心則讓每個角色看見現在輪到自己做什麼。

上線後一個月，這套流程的單據處理量約為既有流程月平均的兩倍。我不會把這個數字直接當成「效率提升兩倍」：不同月份的案件難度、人力與工作量都可能不同。不過，它至少讓我知道，這次改造值得持續觀察，而不是只在發布當天確認畫面能不能跑。

流程不只要跑得動，也要讓每一個人知道下一步輪到誰。

今天可以做的：畫出你系統裡還沒被接住的 handoff

今天不需要打造一套單據中心。請從自己的專案選一個流程，從「使用者按下送出」開始，畫到他真正拿到結果或案件結案。

# Handoff Map｜功能名稱

- 使用者完成的最後一個操作：
- 系統目前產出的結果：
- 接下來要交給誰：
- 對方在哪個系統處理：
- 需要帶什麼資料／附件：
- 哪個步驟只是重複轉手：
- 哪個步驟需要人類判斷或稽核：
- 最容易卡住或最難追蹤的是：
- 若改成自動路由，哪些人其實不該收到案件：
- 是否有一個大類混了路由規則不同的子功能：
- 使用者如何只看到與自己相關的案件：

現在的 Claude Code 可以協助盤點一個功能：使用者送出後，程式已經處理到哪裡？通知、人工交接、外部系統與文件裡還藏著哪些步驟？但哪些審核該保留、哪些路由可以規則化，仍要由真正理解流程責任的人決定。

小結：自動化上線後，流程才開始接受檢驗

第二代把 Notebook 的操作搬上 Web，也讓 JSON 成為可驗證的輸出；但使用者只要還得帶著 JSON 去另一個系統開單，流程就還沒有真的接起來。

第三代把申請單、工作單、路由、通知與結案放回 DAP，減少了跨系統的重複轉手。資源調整的回饋也提醒我：自動化規則不是寫完就永遠正確，分類方式本身要能接受實際使用者與處理人的回饋。

下一篇要談的是，當流程真的進到畫面裡，按鈕的位置、角色看見的內容、狀態如何呈現，不能再只靠一句 Prompt 猜出來。我後來開始用 Pencil 與 MCP，先把畫面變成可以討論的設計輸入。

參考資料

• Google SRE Book. Eliminating Toil.