數字化專案的「做完了」:一份可執行的驗收清單
「這不都做了嗎」和「這也能叫做完」——雙方都沒說謊,只是「做完」從未被定義。驗收清單的價值不在嚴密,而在開工那天就存在。
讀這一篇能得到什麼
- 驗收爭議源於完成定義缺失,不是單純執行不力
- 四層標準——功能可用、資料正確、使用者會用、指標改善——每層舉證方式不同
- 只驗功能不驗資料,是最大漏洞,也是最難返工的一層
- 演示環境透過不等於上線可用;場景須含真實資料與真實使用者
- 上線後 30/60/90 觀察指標要提前約定,否則「上線即結項」會留下無人使用的系統
「這不都做了嗎」——收尾季最常見的一句
專案例會上,實施方開啟功能清單,逐項打勾:「流程通了、報表出了、培訓也簽到了。」業務方翻出真實單據:「這筆退回走不通;這個數跟老臺賬對不上;車間還在用 Excel。」兩邊都沒有說謊。他們只是在用不同的「做完」——而這個詞,在立項會上從來沒有被寫成可舉證的句子。
驗收清單的價值不在條款有多長,而在開工那天就已經存在。沒有它,收尾剩下的只有立場:一方談交付範圍,一方談業務可用性,談判地位在上線之後會急劇傾斜。
四層標準:從「能點」到「值得留」
很多人以為驗收就是「功能清單打勾」。更穩妥的理解是:從「能點開」走到「值得繼續留下來用」。四層標準對應的舉證完全不同,混在一張簽字頁裡,最後一定扯皮。
| 層級 | 驗什麼 | 怎麼舉證 | 不過會怎樣 |
|---|---|---|---|
| 一、功能可用 | 需求內流程可走通 | 場景清單逐項走查,含異常分支 | 上線後卡在半截 |
| 二、資料正確 | 計算、流轉、報表結果可信 | 真實資料對照舊方式 | 使用者迴流 Excel |
| 三、使用者會用 | 關鍵崗位能獨立完成日常作業 | 使用率、單據系統化比例、實操考核 | 系統在,人手不動 |
| 四、指標改善 | 約定業務指標有改善 | 改造前基線 vs 上線後 | 有成本無收益 |
第二層是最大漏洞。 功能驗收容易——點一遍看能不能用。資料正確需要對照,工作量大,常被跳過;卻偏偏最難返工:上線半年後發現口徑錯了,歷史資料要重算。
第三層最容易被忽略。 技術上線了、業務沒人用,等於沒上線。培訓簽到不等於會用——關鍵崗位當著你的面獨立做完一筆日常單據,比一百份簽到表更有說服力。
第四層依賴前三層,且必須有改造前基線。沒有基線,這一層無法驗收——所以基線採集要在專案啟動時安排,而不是上線後再找。基線口徑也要凍結:同一指標,改造前用什麼取數方式,上線後必須可比,否則「改善」會變成各說各話。
驗收場景怎麼設計才夠狠
不要只驗正常路徑。建議三類:
- 正常流程:標準業務從頭走到尾
- 異常分支:退回、部分完成、撤銷、超期、併發
- 邊界情況:數量為零或極大、跨月跨年、批次、權限邊界
抽樣要選真實單據,並至少包含一筆曾經出過問題的歷史案例——這類單子往往暴露最多漏洞。
| 驗收動作 | 透過標準 | 誰簽字 |
|---|---|---|
| 場景走查 | 清單含異常分支均可走通 | 業務負責人 |
| 資料對照 | 抽樣與舊方式一致或差異可解釋 | 業務 + 財務 / 計劃 |
| 崗位實操 | 關鍵崗位無協助完成日常單據 | 崗位代表 |
| 指標觀察 | 30/60/90 達約定閾值 | 專案指導組 |
自測一句:場景清單裡有沒有一筆「你們自己都知道以前做錯過」的業務?沒有的話,清單不夠狠。
資料對照不要平均抽樣,按風險加權更有效:正常閉環約四成,曾經出錯 / 扯皮過的歷史單約三成,跨月 / 部分完成 / 退回重走約兩成,權限邊界約一成。每一筆記錄舊結果、新結果、差異原因、是否可接受、修復責任方——沒有這張對照表,第二層等於沒做。
製造業還要特別盯三類數字:數量與單位換算、金額與稅率、狀態遷移後的庫存 / 在制餘額。這三類錯了,業務會立刻迴流 Excel。
六種把驗收掏空的做法
| 做法 | 表現 | 後果 |
|---|---|---|
| 演示場景驗收 | 在準備好的資料上走一遍 | 真實資料一上就炸 |
| 只驗功能不驗資料 | 功能點打勾,不看數字 | 口徑錯誤帶入生產 |
| 上線即結項 | 上線當天籤驗收,無觀察期 | 無人使用,問題堆積 |
| 需求邊界模糊 | 缺陷與新增需求混談 | 尾款無休止扯皮 |
| 培訓簽到當會用 | 只看出席,不看實操 | 第三層形同虛設 |
| 基線後補 | 上線後再找改造前資料 | 第四層永遠驗不成 |
其中代價最大的是「上線即結項」:跳過第三、四層,把風險全部留到上線之後,而那時雙方談判地位已完全不同。
分期驗收,比堆到末期一次簽字更安全
| 階段 | 驗收重點 | 付款掛鉤 |
|---|---|---|
| 核心場景上線 | 第一層 + 第二層 | 首期結清 |
| 關鍵崗位穩定使用 | 第三層 | 中期款 |
| 指標觀察期結束 | 第四層 | 尾款 |
爭議分散在過程中,而不是堆在末期;每一批也為下一批提供經驗。
上線後建議約定觀察視窗:
| 時點 | 看什麼 | 想確認什麼 |
|---|---|---|
| 約 30 天 | 關鍵崗位使用率、單據系統化比例 | 是不是真用起來了 |
| 約 60 天 | 資料抽檢透過率、異常處理時效 | 資料是否可信 |
| 約 90 天 | 約定業務指標、手工檯賬殘留 | 是否產生實際價值 |
手工檯賬殘留很實用:上線數月後仍有人私下維護同一批資料的 Excel,說明系統沒解決真實問題,要回去找原因。
可寫入合同附件的節奏:開工前凍結四層標準、場景清單與基線採集計劃;上線當週完成第一、二層並登記未關閉缺陷;之後按表跟蹤第三、四層,缺陷與變更分軌。
合同裡先寫清三件事
- 質保範圍與響應標準:什麼算缺陷、響應與修復時限
- 缺陷與變更的界線:什麼免費修,什麼走變更
- 驗收標準與付款節點:四層如何對應付款,觀察期多長
寫得越具體,後期越省事。驗收標準越模糊,最後越依賴人情談判——而談判結果通常對甲方不利。
可執行分界示例:
| 情形 | 傾向 | 處理 |
|---|---|---|
| 需求已寫明,未實現或實現錯誤 | 缺陷 | 質保期內免費修復 |
| 文件未寫,但行業預設必須且影響上線 | 協商缺陷 / 小變更 | 事先約定「上線阻斷項」清單 |
| 上線後新想法、新欄位、新報表 | 變更 | 評估與報價 |
| 遷移後歷史口徑與新口徑不一致 | 視合同 | 遷移範圍與清洗責任須開工前寫清 |
把這張表當附件,比事後爭論「算不算做完」有效得多。
什麼時候可以簡化——以及什麼絕不能省
範圍極小、內部自建、合規強制上線、明確試點允許失敗——形式可以簡化。資料對照抽樣不建議省略,無論哪種情況。試點若允許失敗,也要把「失敗後是否推廣、失敗成本由誰承擔」寫進附件,避免試點變成無結論的長期並行。
上線放行的最小門檻建議寫進放行紀要:核心場景異常分支走通、阻斷級缺陷清零;資料對照抽樣達約定閾值,未透過項有責任人與修復日期;關鍵崗位完成實操考核(不是培訓簽到);回滾 / 應急方案明確——誰決策停用、雙軌期間資料以哪邊為準;觀察指標與取數負責人已指定。缺資料對照與實操就放行,通常會在第一個月末以「系統不準 / 沒人用」反噬。
驗收不是儀式,是把「做完」從口頭詞變成可舉證狀態——舉證材料比簽字頁更重要。簽字可以一天完成,對照表、實操記錄與觀察期報告才是日後發生爭議時真正能拿出來的東西。
「做完」寫在開工日,收尾才不用靠嗓門
對照現有清單兩件事就夠:有沒有資料對照測試,有沒有上線後觀察期。仍在立項階段,就把四層標準寫進合同附件——比專案末期補清單便宜一個數量級。平臺與產品落地路徑不同,但驗收邏輯相通:JEDP 專案同樣建議把場景走查、資料對照與觀察期寫進附件,而不是上線當天一次性簽字了事。
- JEDP 平臺能力總覽
- 資訊化選型打分表(免留資自測)
- 6 周 vs 6 個月:落地路徑對照長圖
- 數字化投入 ROI 怎麼測算
想把這篇裡的做法落到自己的廠裡?資源中心有對應場景的線上自測與資料模板,也可以直接約一次真實環境演示。
常見問題
圍繞本篇主題的追問,先看這裡;仍有疑問可聯絡我們
驗收一定要一次性完成嗎?
建議分期。按模組或場景分批確認,付款節點與之掛鉤。一次性驗收會把爭議堆到末期,雙方都沒有迴旋空間。
資料正確性怎麼驗?
用真實資料對照:同一筆業務分別走舊方式與新系統,比對結果。抽樣要覆蓋正常與異常,尤其是退回、部分完成、跨期。
使用者會用算不算驗收項?
應量化。看關鍵崗位使用率、單據系統化比例、手工檯賬殘留。上線數月後仍有人用 Excel 記同一批資料,這一層就沒過。
上線後發現問題算誰的?
合同階段約定質保範圍與響應標準,並分清缺陷修復與新增需求。界線不清,後期最容易扯皮。
第四層指標改善達不到怎麼辦?
先區分系統問題、流程問題還是基線不合理。建議把第四層設為觀察期目標、與部分尾款掛鉤,而不是與「能否上線」完全繫結。