---
title: "從增員遭拒開始的非開發人員工作自動化案例"
locale: zh-hant
category: case_study
category_name: "案例研究"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/project-manager-workflow-automation-case-study
published_at: 2026-08-29T05:28:31+09:00
---

# 從增員遭拒開始的非開發人員工作自動化案例

> 這是一位在缺乏人力與標準的情況下還需負責維護工作的專案管理人員，消除瓶頸並使用 Claude Code 開始小型自動化的案例。重點不在於更快完成工作的技術，而在於先改變會產生不必要轉手與重複作業的工作結構。

## Key Points

- 比工作量增加更嚴重的問題，是現有人員必須同時建立新的流程與交付成果標準。
- 即使是簡短的檔案匯出入請求，若反覆打斷專注，也會造成超出實際處理時間的工作負擔。
- 最先產生效果的改善並非自動化程式，而是改變請求路徑，使其不必經過負責人。
- 非開發人員也能利用生成式 AI 與程式設計工具，透過說明問題、執行、確認錯誤及修正的循環，建立小型自動化。
- 評估自動化對象時，除了重複次數，也應一併考量錯誤風險、中斷頻率、標準化可能性及安全管控。

被重複性工作壓得喘不過氣的人，往往會先尋找更快處理的方法。然而，這個案例所呈現的起點並不相同。在難以增補人力的情況下，一名事業管理負責人沒有直接加速處理集中到自己身上的工作，而是先重新檢視，為什麼所有請求與審查都必須經過自己。

本文並非介紹自動化技術的功能，而是分析不得不開始自動化的工作環境、第一次流程改善、非開發人員的學習過程，以及能從該經驗中歸納出的原則。

## 案例的起點：增加的不只是工作量，還有複雜度

該團隊原本負責基礎設施營運業務。對於穩定營運系統、處理故障，以及彙整每月績效等工作，已經有一套熟悉的流程。問題始於在維持原有人力的情況下，又增加了新的維護管理業務。

這與把相同工作做兩遍的情況不同。負責人除了要處理從未接觸過的工作，也必須重新設計下列要素。

- 要接收哪些交付成果
- 文件中要放入哪些項目
- 如何決定廠商與客戶的審查順序
- 如何管理各項作業的編號與時程
- 以何種方式收回並報告已簽署的成果文件

| 分類 | 既有基礎設施營運 | 新增的維護管理工作 |
|---|---|---|
| 工作體系 | 已有熟悉的營運程序 | 必須重新設計程序與標準 |
| 主要交付成果 | 營運績效與故障處理紀錄 | 計畫表、工作日誌、簽署本、驗收資料等 |
| 管理對象 | 以內部營運為主 | 廠商、作業人員、負責單位與客戶共同參與 |
| 核心負擔 | 穩定營運 | 包括建立標準、調整時程、審查、退回與回收 |

不只工作增加，連處理工作的體系也必須建立，這一點正是造成超載的核心。

## 沒有標準，審查與退回就會反覆發生

由於維護管理交付成果的既有標準不夠完整，負責人必須親自製作表單並發給廠商。然而，現場不斷發生使用前一年度格式、漏掉作業人員簽名，或含糊填寫特殊事項等問題。

例如，若在結果欄只寫「預計日後處理」，管理人員就無法追蹤完成時間。因此必須退回，要求填寫具體預定日期，之後再重新確認修正版。這種結構會使確認並要求修正交付成果的管理工作，比檢查本身更加繁重。

這個案例顯示，標準化應先於文件自動化。在輸入格式與必填項目尚未確定的狀態下，自動化工具也只會快速搬運模糊且不完整的資料。若要評估自動化，應先確定以下事項。

1. 必須輸入的項目
2. 可接受的日期與姓名標示方式
3. 需要簽名或附件的條件
4. 退回原因與修改負責人
5. 可判定為完成的標準

## 幾分鐘的請求為何會打亂一整天的工作節奏

基於資安考量，外部檔案的匯入與匯出採單一窗口方式運作，所有流程都要經過一名負責人。處理單一請求所需的時間並不長，但問題在於請求出現的時間毫無預警。

在專注於原有工作時收到請求，就必須停下手邊工作處理檔案。之後還得重新回想中斷工作的脈絡。在這個案例中，增加主觀負擔的並非個別請求所需的時間，而是反覆切換工作。

尋找自動化對象時，只計算處理單一案件的時間並不夠。還必須一併檢視下列成本。

- 確認請求並判斷優先順序的時間
- 停下手邊工作再重新開始的切換成本
- 向請求者重新詢問遺漏資訊的時間
- 另行記錄並報告處理狀態的時間
- 特定負責人不在時產生的等待時間

雖然短暫，卻無法預測且反覆出現的請求，可能成為大幅擾亂整體時程與專注力的瓶頸。

## 第一個解決方案不是自動化，而是移除路徑

針對檔案匯入與匯出問題，第一次改善並不是開發程式，而是利用內部專案管理系統的討論區，改變流程，讓請求者與客戶直接收發請求。

| 變更前 | 變更後 |
|---|---|
| 所有請求都經過事業管理負責人 | 請求者與客戶直接在系統中處理 |
| 負責人同時執行轉交與記錄 | 系統會留下處理紀錄 |
| 每次收到請求都會中斷原有工作 | 負責人可在需要時查看紀錄 |
| 負責人不在時，請求可能延誤 | 指定參與者可在同一流程中確認 |

由此可得的原則很明確。與其更快地完成自己負責的工作，讓該工作不必經過自己，可能是更好的解決方案。

設計自動化之前，依照下列順序進行檢視會很有幫助。

1. 這是可以刪除的步驟嗎？
2. 請求者能否自行輸入或確認？
3. 能否利用既有系統的功能簡化路徑？
4. 能否標準化輸入與判斷標準？
5. 能否將其後仍然存在的重複性工作自動化？

## 多項簡單工作同時湧入，使超載狀態固定下來

維護管理的整體流程包括制訂時程、整理廠商與作業人員資訊、編號、收回工作日誌、客戶審查與簽署、掃描、驗收報告，以及向各廠商交付成果。每個步驟單獨來看都不困難，但一旦同時重疊，就很難只靠人的記憶與手工作業加以控制。

這種狀態持續了約三個月。白天要回應匯入與匯出請求、廠商詢問、團隊成員確認與客戶要求，直到下班時間過後聯絡減少，才能處理積壓的核心工作，這種模式不斷重複。與其說是在解決問題，不如說是在事後追趕當天發生的事情。

負責人曾要求增補工作輔助人力，但未獲接受。人力無法增加後，改變既有方式的選項變得重要。自動化不是從興趣開始的嗜好，而是基於「若維持目前的工作結構，下個月仍會重複相同問題」的判斷所採取的應對方式。

## Claude Code 示範成為小型實驗的契機

轉捩點是在總公司活動中看到的 Claude 自動化應用示範。比起複雜的開發技術，更重要的是確認了「這項工具也能應用於我們的工作」的可能性。與一同出席的同事談到不妨進行小規模嘗試，成為後續自動化工作的起點。

原本不是開發人員的負責人，從 Claude Code 的安裝方法開始向其他生成式 AI 提問。確認並執行符合作業系統的說明與指令，再一邊觀看影片資料等，一邊模仿其他使用者的初始設定過程。並不是先完全學會程式設計理論後才開始。

不過，這種方式並不表示可以直接執行來源不明的指令。在工作用裝置上，應確認組織的資安政策與軟體安裝權限，並盡可能採用官方文件中的安裝程序。執行前也必須確認指令是否會刪除檔案、變更權限或向外部傳輸資料。

## 比成果更重要的互動式問題解決過程

第一個成果讓負責人建立了「非開發人員也能製作自動化工具」的信心。然而，在這個案例中，比完成的程式更重要的學習發生在製作過程中。

互動式開發大致依照下列循環進行。

- 說明要解決的問題與目前程序。
- 提供輸入檔案、輸出格式、資安限制等約束條件。
- 檢視 AI 提議的方法與程式碼。
- 使用副本或測試資料執行。
- 再次說明錯誤訊息與不符預期的結果。
- 套用修改方案並重新驗證。

生成式 AI 可以提出使用者原本不了解的技術或方法，也可以要求它重新解釋陌生術語。另一方面，其建議不一定總是正確，也不一定適合組織的環境。因此，不應把 AI 視為代替人進行判斷的核准者，而應將其視為擴大選項並減少反覆試錯的輔助工具。

## 從案例中歸納出的自動化對象判斷標準

並非所有重複發生的工作都有必要自動化。綜合評估下列標準，有助於排定優先順序。

| 判斷標準 | 要確認的問題 | 意義 |
|---|---|---|
| 重複頻率 | 相同工作多久發生一次？ | 重複越頻繁，可累積節省的幅度越大 |
| 處理規則 | 能否以明確規則說明輸入與結果？ | 規則越清楚，實作與驗證越容易 |
| 中斷頻率 | 是否會毫無預警地出現並打斷核心工作？ | 即使是短暫工作，也可能具有高優先順序 |
| 錯誤影響 | 遺漏或誤判是否會影響合約、資安或成本？ | 可能需要人工核准，而非完全自動化 |
| 輸入品質 | 表單與必填項目是否已標準化？ | 不規則的輸入會增加例外處理 |
| 可追蹤性 | 能否留下何人在何時處理何事的紀錄？ | 稽核與確認責任時需要 |
| 變動可能性 | 程序與表單是否經常變更？ | 必須一併考量維護成本 |

應優先自動化的工作，通常是規則明確、重複頻率高，且人員能輕易比對結果的小型作業。相反地，涉及法律判斷、資安核准、合約責任或重要金額決策的工作，保留人工審查步驟會更安全。

## 自動化中容易遺漏的控制與維護管理

若因工作緊急而倉促推動自動化，既有的手工作業風險可能只是被轉移到程式碼中。尤其在像這個案例一樣處理外部檔案、簽署本與客戶資料的環境中，必須在追求處理速度的同時設計控制機制。

### 至少應確認的控制項目

- **權限：** 將自動化工具可存取的資料夾與帳號限制在必要範圍內。
- **資料保護：** 不得將個人資料、合約資料與驗證資訊輸入未經核准的外部 AI 服務。
- **測試環境：** 先使用副本與去識別化測試資料執行，而不是使用原始檔案。
- **人工核准：** 在檔案傳輸、刪除與最終報告等難以復原的步驟中設置確認程序。
- **記錄：** 留下輸入、執行時間、處理結果、錯誤與修改紀錄。
- **復原：** 保存原始檔案與備份，以便失敗時恢復至先前狀態。
- **負責人依賴性：** 將流程文件化，確保製作者以外的團隊成員也了解執行與停止方法。

自動化的成功標準也不應只是「曾經成功執行一次」。還必須一併評估表單變更或負責人更換後能否修改、能否發現錯誤，以及能否恢復使用手動程序。這是區分短期個人生產力工具與永續工作系統的標準。

## 經驗中確認的事實與推廣時的限制

這個案例以一名負責人的實際經驗為基礎，因此無法保證所有組織都會得到相同結果。有必要區分案例中直接確認的內容，以及套用至其他環境時必須驗證的內容。

| 案例中觀察到的內容 | 套用前需另行確認的內容 |
|---|---|
| 在人力未變動的情況下增加了新的維護管理工作 | 各組織的人力配置與工作調整可能性 |
| 單一窗口導致負責人的工作反覆中斷 | 資安規定是否允許請求者之間直接處理 |
| 利用既有管理系統的討論區減少中間轉交步驟 | 使用中系統的權限、紀錄保存與核准功能 |
| 非開發人員利用生成式 AI 的說明安裝工具並進行學習 | 公司裝置的安裝權限與外部 AI 使用政策 |
| 小型成果帶來嘗試更多自動化的信心 | 自動化的準確度、節省時間與維護成本 |

因此，這個案例的核心價值並不在於主張某項特定工具能讓所有人獲得相同成果，而在於沒有把重複性工作解讀成個人不夠努力，而是重新將其定義為流程、標準、權限與瓶頸的問題。

## 結論：沒有時間這件事本身也能成為起點

自動化不必只被視為有餘裕後才學習的獨立專案。若工作持續累積，而且下個月仍會重複相同問題，這可能就是必須改變目前結構的訊號。

起點不必是龐大的開發計畫。可以先挑出最常打斷專注力的一項請求，確認該步驟是否真的必須經過自己。若無法刪除或交由既有系統處理，則應先將輸入格式標準化，並從容易驗證結果的小部分開始自動化，這樣會更安全。

這個案例留下的最重要問題，不是「如何更快完成這項工作」，而是「為什麼這項工作會反覆出現、為什麼一定要經過我，以及可以交由系統處理到哪個階段」。

## FAQ

### 即使不是開發人員，也能開始進行業務自動化嗎？
可以，但從小範圍開始較為安全。應清楚說明目前的流程及輸入、輸出條件，先使用副本或測試資料執行生成式 AI 建議的方法，再親自驗證結果。

### 所有重複性業務都應該自動化嗎？
不是。首先應確認是否可以取消該步驟，或讓提出請求的人自行處理。如果難以取消或簡化流程，且是規則明確的重複性工作，則可以考慮自動化。

### 處理時間短的業務也值得自動化嗎？
如果經常在沒有預告的情況下發生，導致核心業務中斷，就可能值得自動化。不僅要評估單筆業務的處理時間，也應一併評估確認請求、切換工作、補齊缺漏資訊、記錄及重新專注所需的成本。

### 為什麼在業務自動化之前需要先進行標準化？
因為如果必填欄位和輸入格式不一致，自動化就難以穩定處理例外情況。先確定完成標準、日期格式、簽署條件和退回原因，會讓實作與驗證更容易。

### 可以直接執行生成式 AI 撰寫的程式碼嗎？
不應直接執行。必須檢查是否涉及刪除檔案、變更權限或對外傳輸，並確認組織的資安政策與安裝權限。先使用副本而非原始檔案，以及去識別化的測試資料進行驗證，會比較安全。

### 自動化後可以完全取消人工審查嗎？
視業務的風險程度而定。對於檔案傳輸與刪除、資安核准、合約上的判斷、重要金額決策等錯誤影響較大的步驟，必須保留人工確認與核准流程。

### 第一次進行自動化時，選擇哪種業務比較好？
適合選擇重複頻率高、規則明確，而且人員能輕易核對結果的小型工作。也應確認即使發生錯誤，是否能從原始資料復原，以及敏感資訊外洩的風險是否較低。

### 如何判斷自動化是否成功？
不要只看是否成功執行，也應一併比較中斷次數、退回與遺漏情況、處理等待時間及錯誤修正時間。還應評估在表單變更和負責人更換時是否仍能維護，以及失敗時是否能恢復為人工流程。

## Sources

- [增員遭拒後，從「來試試這個吧」開始的自動化 | 요즘IT](https://yozm.wishket.com/magazine/detail/3912/)

## Images

![員工在工作桌使用筆電，後方同事查看觸控螢幕](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI4NzUsInB1ciI6ImJsb2JfaWQifX0=--6ea22c48d8437db264e2c179ded939ce099f2a0b/ai-fcef29be.webp)
![雜亂的文件與通知轉化為自動化儀表板和工作流程](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI4ODMsInB1ciI6ImJsb2JfaWQifX0=--8996698429ec4d415b74063aa44ca9f301aa486e/ai-cd6d8a57.webp)