
目錄
真正重要的 ERP 導入 KPI,是一小組在交付期間每週檢視、在 Hypercare 期間每日檢視的指標,每一項都有指名的負責人:時程遵循度、成本差異、範疇變更、測試通過率、資料移轉準確度,以及最重要的使用者採用率。以下是我使用的 30 項,分成交付階段與上線後兩部分,附上公式,以及應該觸發行動的門檻值。
這份內容寫給專案總監、PMO 負責人與專案發起人,他們需要一份能在第 8 週、而不是第 18 個月就抓到問題的指導委員會資料包。
有一位客戶曾在一個 SAP 專案中追加 73 項「小」變更。單獨看,沒有一項顯得重要。加在一起,卻造成了五個月的延誤。沒有人在追蹤範疇變更的數量。(如果這聽起來很耳熟,我那篇談如何避免 SAP 專案範疇蔓延的指南說明了各項管控做法。)
另一位客戶忽視了早期的時程警訊,一個一年期的專案拖成了十八個月。一家零售客戶無視早期的預算警訊,最後為了完工,只好砍掉關鍵功能。
這些並不是罕見的失敗。這就是團隊追蹤錯誤的東西,或是什麼都不追蹤時會發生的事。
| # | KPI | 衡量什麼 | 為什麼重要 |
|---|---|---|---|
| 1 | 時程遵循度 | 任務實際完成與計畫完成的對照 | 連鎖延誤的第一個訊號 |
| 2 | 成本差異 | 各階段實際支出與預算的對照 | 在超支滾雪球之前抓到它 |
| 3 | 範疇變更量 | 已核准變更的數量與影響 | 失控的變更是超支最常見的原因 |
| 4 | 資源使用率 | 實際工時與計畫工時的對照;工作負荷是否平衡 | 負荷過重的人會在專案中途倦怠或離職 |
| 5 | 使用者採用率 | 實際在使用系統的目標使用者占比 | 唯一能告訴您系統是否真正為業務所用的指標 |
| 6 | 訓練成效 | 評量分數;已受訓使用者占比 | 在上線前預測採用失敗 |
| 7 | 資料移轉準確度 | 乾淨移轉的記錄占比;錯誤率 | 新系統裡的錯誤資料要花好幾個月才清得完 |
| 8 | 測試環境停機時間 | 測試系統非計畫性停機的小時數 | 測試時的不穩定,預示上線時的不穩定 |
| 9 | 參與度分數 | 問卷結果;重要會議的出席情形 | 在抗拒情緒公開浮現之前提早示警 |
| 10 | 風險解決率 | 按時結案的未結風險占比 | 衡量結案,而不只是識別 |
| 11 | 夥伴績效 | 交付物品質;里程碑達成率 | 早期交付物就失手的夥伴,後面幾乎一定也會失手 |
| 12 | 測試通過率 | 首次就通過的測試案例占比 | SIT 中低於 85%,通常代表系統性問題,而不是零星的錯誤 |
| 13 | 變更需求處理時間 | 從提出需求到做出決定的天數 | 排隊過長代表治理失靈 |
| 14 | 預算消耗率 | 支出占總預算的比例,對照已完成的工作 | 顯示金錢與進度是否同步前進 |
| 15 | 組態設定進度 | 已完成的計畫組態項目占比 | 這裡落後,測試與訓練就會跟著往後推 |
| # | KPI | 衡量什麼 | 門檻值或備註 |
|---|---|---|---|
| 16 | 系統可用性 | 上線後的運作時間 | 高於 99.9% 算良好;低於 99% 就會變成使用者信心問題 |
| 17 | 報表與儀表板速度 | 載入時間;更新頻率 | 如果主管都把資料匯出到 Excel,就代表系統沒有達標 |
| 18 | 員工生產力 | 任務耗時與上線前基準的對照 | 一家把核准流程自動化的經銷客戶,上線後每天多處理了 25% 的交易 |
| 19 | 首次聯繫解決率 | 首次聯繫就解決的工單 | 衡量 Hypercare 的成效 |
| 20 | 支援工單數量 | 未結工單;平均解決時間 | 第 30 天前後暴增,通常代表訓練有缺口,而不是系統有錯誤 |
| 21 | 流程週期時間 | 訂單處理、發票核准、結帳週期 | 高階主管真正在意的成果 |
| 22 | 庫存準確度 | 實體盤點與系統數量的對照 | 上線後最明顯的資料品質指標 |
| 23 | 訂單履行率 | 在新系統中準時履行的訂單 | 對營運的直接影響 |
| 24 | 營收歸因 | 與新功能相關聯的營收變化 | 為商業案例提供長期佐證 |
| 25 | 法遵達成度 | 稽核發現;法規問題 | 在金融、製藥與受管制產業最為重要 |
| 26 | 預測準確度 | 預測與實際需求的對照 | 顯示規劃功能是否被使用、被信任 |
| 27 | 使用者滿意度 | 易用性問卷;關鍵使用者 NPS | 討厭系統的使用者會自己做出各種變通做法 |
| 28 | 流程效率 | 每個流程的時間與成本,對照基準 | 向董事會證明這筆投資值得 |
| 29 | 已實現的節省 | 實際節省金額與商業案例的對照 | 財務長會在第 6 與第 12 個月來問 |
| 30 | 投資報酬率 | 淨效益除以總成本 | 通常在第 12 與第 24 個月衡量 |
這幾項是大家問得最多的。
- 時程績效指數 (SPI) = 實獲值 ÷ 計畫值。高於 1.0 表示超前,等於 1.0 表示準時,低於 1.0 表示落後。
- 成本績效指數 (CPI) = 實獲值 ÷ 實際成本。高於 1.0 表示有效率,低於 1.0 表示超支。
- 範疇變更比例 = (已核准變更數 ÷ 初始範疇項目數) × 100。低於 10% 影響輕微;高於 20% 影響重大。
- 使用者採用率 = (活躍使用者 ÷ 目標使用者) × 100。前 90 天內高於 80% 表現強勁;低於 60% 就需要介入。
- 資料移轉準確度 = (乾淨移轉的記錄數 ÷ 嘗試移轉的記錄數) × 100。上線前要高於 98%;低於 95% 就應該延後切換。
SPI 與 CPI 來自實獲值管理 (earned value management)。只有在誠實衡量「實獲值」時,它們才有用:一項連續三週都「完成 90%」的任務,並不是真的有 90% 的價值。
沒有檢視節奏的 KPI 只是擺設。以下是該建立的節奏。
- 交付期間每週專案委員會時程、成本、風險、測試通過率、範疇變更。關卡 KPI 送交指導委員會
- 第 1 至 30 天每日 Hypercare 檢視可用性、工單數量、各部門的採用度
- 至第 90 天每週採用度檢視採用度、流程週期時間、工單類別
- 第 6 與第 12 個月專案發起人與財務長檢視生產力、已實現的節省、ROI
| 時機 | KPI | 檢視者 | 對應的決策 |
|---|---|---|---|
| 交付期間每週 | 時程遵循度、成本差異、風險解決、測試通過率、範疇變更量 | 專案委員會 | 重新規劃、升級處理或守住範疇 |
| 每個階段關卡 | 組態設定進度、訓練成效、資料移轉準確度、夥伴績效 | 指導委員會 | 通過、有條件通過或停止 |
| 上線後前 30 天每日 | 可用性、工單數量與趨勢、各部門採用度 | Hypercare 負責人 | 現場支援與修正該往哪裡派 |
| 每週,至第 90 天 | 採用度、流程週期時間、工單類別 | 專案委員會 | 複訓、組態修正 |
| 第 6 與第 12 個月 | 生產力、已實現的節省、ROI、滿意度 | 專案發起人與財務長 | 商業案例簽核、第二階段範疇 |
我的一位製藥客戶為每個里程碑都指派了一位負責人,外加一位備援。相較於先前那次 SAP 嘗試,它的時程遵循度大幅改善。等到每月檢視才揭露落後時,問題早已結構化。
關卡決策應該以證據為依據,而不是以日曆為依據。而且到了上線後第三個月,變通做法已經變成習慣,所以採用度的窗口關閉得比大多數團隊預期的更快。如果您的指導委員會需要重新來過,我在建立有效的 SAP 專案指導委員會裡說明了該怎麼運作。
一位客戶追加了 73 項「小」變更。隨之而來的五個月延誤,一點也不小。範疇變更 KPI 的存在,正是為了在這種模式變得看不見之前就阻止它。
RISE with SAP 與 SAP GROW 專案帶來了傳統清單沒有涵蓋的治理問題。三項額外的衡量有幫助。
Clean Core 等級組合
SAP 現在把擴充分成四個 Clean Core 等級,從 A 到 D。A 級只使用已釋出的 API;D 級則不算 Clean。請追蹤各等級的擴充占比,並使用 SAP 建議的 ABAP Test Cockpit 檢查。
在 Public Edition 上,依設計一切都是 A 級。在 Private Edition 與地端環境,任何 C 級或 D 級的擴充,都是一筆會在下次升級時浮現的債。在 Realize 階段,每週依此檢視新的擴充請求,並讓每一項 C 級或 D 級的核准都有人負責。
已決定擴充的放置位置
公式:(已議定等級與位置的擴充數 ÷ 待辦清單中的擴充總數) × 100。目標是在 Explore 階段結束時達到 100%。沒有人決定要放在哪裡的擴充,最後就會在期限壓力下變成傳統的修改。
與 SAP 關係的健康度
在 RISE 專案上做每季一次的質性檢視,因為 SAP 負責基礎架構與營運,也是交付的一部分。平台問題的升級處理,是否在議定的服務水準內解決?SAP 的成功檢視是實質的,還是走過場?分數偏低,通常預示著專案中途會出現一次團隊還沒準備好的升級事件。
AI 對指標周邊的報告工作很有用,但它取代不了檢視本身。
- Joule 搭配 SAP Cloud ALM。 SAP 已把 Joule 加入 Cloud ALM,團隊因此可以用一般語言查詢專案與營運資料,而不必手工做出每一份狀態報表。
- Power BI 中的 Copilot。 根據底下的儀表板,為指導委員會資料包草擬文字摘要。資料模型乾淨時效果最好。
- 異常偵測。 Power BI、Tableau 與 SAP Analytics Cloud 可以標出偏離常態的 KPI。對資源使用率、工單數量與範疇變更率值得做;對自然變異很大的指標,例如每日訂單數,則不值得。
AI 解決不了的,是政治上的工作。儀表板可以連續六週用紅色顯示時程落後。如果指導委員會不採取行動,落後就會繼續。
影響最大的 KPI 是使用者採用率,也是大多數團隊最晚才去衡量的一項。
我有一位製造業客戶,他們的高階主管把所有東西都匯出到 Excel。這是個超大的警訊。資料都在,他們需要的儀表板卻不在。我們把儀表板修好,決策時間就縮短了一半。
一個技術上能運作、實務上卻被繞過去的系統,什麼都沒交付。變革管理的研究也支持這個論點:Prosci 長期的研究發現,變革管理出色的專案,達成目標的可能性約是變革管理差的專案的七倍。
最好的 KPI 儀表板不是最完整的那一個,而是指導委員會真的會看的最小集合:每一行都有負責人,而且當紅燈連續兩個週期不退時,就有後果。大多數 KPI 計畫失敗,是因為追蹤的東西對了,卻被置之不理。如果數字已經亮紅燈,該怎麼做,請見讓 SAP 專案回到正軌。
最重要的 ERP 導入 KPI 是什麼?
使用者採用率。技術上成功、卻沒人使用的導入,不會帶來任何業務價值。其他 KPI(時程、預算、測試)是在保護採用的條件。採用率則告訴您,採用有沒有真的發生。
從上線後第一週起,依部門追蹤。某個團隊採用率偏低,通常指向訓練缺口或流程設計問題,而這些問題在 Hypercare 期間還來得及修正。
ERP 導入 KPI 應該多久檢視一次?
交付期間,時程、成本與風險每週檢視,而不是等到指導委員會每月才看。階段關卡的 KPI 在每個關卡檢視。營運類 KPI 在上線後的前 30 天每日檢視,之後每週檢視到第 90 天。
SAP UAT 的健康測試通過率是多少?
系統整合測試的首次通過率高於 85% 算健康。低於這個數字,通常代表流程設計有缺口或組態有錯誤,而不是零星的錯誤。
如果進入 UAT 時低於 85%,請停下來修正根本原因。UAT 幾乎從來補救不了 SIT 漏掉的問題。
範疇變更比例超過 20%,對 ERP 專案意味著什麼?
專案正在進行途中被重新設計。超支與延誤變得很可能發生。
趨勢比數字更重要。如果隨著專案成熟,變更反而加速,而不是趨於平穩,就代表治理正在失靈。每一項核准的變更,都需要附上成本與時程影響說明。沒有的話,範疇就已經失控了。
RISE with SAP 專案有哪些專屬的 KPI?
在標準的 30 項之外再加三項:擴充的 Clean Core 等級組合(A 到 D)、已議定等級與位置的擴充占比,以及每季一次的 SAP 關係健康度檢視(升級處理、服務水準、SAP 成功檢視的品質)。
如何計算 ERP 導入的 ROI?
ROI = (淨效益 ÷ 總投資) × 100。淨效益是可歸因於系統、可衡量的節省與營收增加,減去新環境的營運成本。總投資涵蓋軟體、導入、內部人員時間、訓練、資料移轉與持續支援。
要保守一點。完整的效益很少在第一年就到位。建立一個逐步提升的模型:第一年達到穩態效益的 50%,第二年 80%,第三年起 100%。
ERP 導入預算超支的主要原因是什麼?
沒有追蹤的範疇變更、因為品質問題浮現得晚而遠遠超出計畫的資料移轉、測試中才發現的整合失敗,以及啟動得太晚、進而推高上線後支援量的變革管理。
每週追蹤成本差異並落實正式的範疇管控,可以處理第一項。及早評估資料品質,可以處理第二項。及早以實際資料量做整合測試,可以處理第三項。從一開始就做變革管理,可以處理第四項。
下一步
您目前正在進行 ERP 專案嗎?
如果這篇文章談到的正是您目前進行中的專案,30 分鐘的對談通常比再花一週做內部分析更有進展。




