日薪預支先導計劃範本及擴展決策標準

一份日薪預支(EWA)先導計劃須預先訂明目標、參與員工群組、時間表、額度政策、整合數據、責任分工、預算、KPI及停止條件。參考流程共分六個階段:準備、設計、系統整合、用戶驗收測試(UAT)、受控運作及評估。先導計劃結束時,企業不只是二選一「擴展」或「不擴展」,而是可以作出四種決定:Go(推行)、Adjust(調整)、Extend(延長)或Stop(停止)。決定須以員工價值、人力資源影響、營運質素、成本及風險為依據。

> 注意: 本文為推行框架範本,並非日薪預支在時間表或功能上的承諾。時間表、規模、KPI門檻、法律角色、收費政策、資金來源及結算流程,均須由Nhan Kiet Manpower Supply Co., Ltd.與企業在正式先導計劃文件中確認。

> 詞彙解釋: EWA(按已完成工作日數預支工資)· 先導計劃/pilot(有限度的試驗推行)· UAT(用戶驗收測試)· RACI(角色分工矩陣:執行 – 最終負責 – 諮詢 – 知會)· KPI(關鍵績效指標)· cutoff(截數時點)· go-live(正式投入運作)· project charter(項目章程)· baseline(基準)· wave(擴展批次)· Go–Adjust–Extend–Stop(推行 – 調整 – 延長 – 停止)。

日薪預支先導計劃是甚麼?

日薪預支先導計劃是一個有限度的推行階段,目的是在正式擴展之前驗證一組假設。範圍可按法人實體、廠房、員工群組、考勤系統、薪資週期、人數或時間長短來限定。

先導計劃不應是「毋須管控的試跑」。員工進行的仍是真實交易,薪資及帳戶資料依然敏感,資金流及薪資仍須對數。因此,先導計劃必須具備如正式運作環境般完整的必要管控,但範圍有限,以便快速學習並在出現問題時減低影響。

一個好的先導計劃必須回答五個問題

1. 員工是否理解並能使用日薪預支?

2. 考勤、薪資及員工狀態數據是否足夠可靠?

3. 交易是否得到正確處理及對數?

4. 計劃是否帶來人力資源或員工福利方面的價值訊號?

5. 成本、風險及營運量是否適合擴展?

1. 企業何時已準備好推行先導計劃?

不應只因合約已簽署或應用程式已備妥就展開先導計劃。最低前提條件包括:

關於目標

• 有具體的業務或員工問題需要解決;

• 有可量度的假設;

• 有具足夠權限級別的項目發起人(sponsor);

• 各部門已就何謂先導計劃成功與失敗達成共識。

關於數據

• 有統一的員工編號;

• 員工在職狀態能準時更新;

• 考勤或工時有明確的審批狀態;

• 薪資週期、截數時點及薪資規則已界定清楚;

• 日薪預支交易能與薪資及付款系統相連結;

• 數據質量已在實際樣本上測試過。

關於營運

• 有流程負責人及支援聯絡窗口;

• 有處理未審批考勤、錯誤帳戶、卡住交易及投訴的流程;

• 有每日及週期結束時的對數機制;

• 有按權限鎖定/解鎖帳戶的機制;

• 有系統或付款中斷時的應變方案。

關於法規與保安

• 合約模式及各方責任已審核;

• 向員工提供的資訊清晰明確;

• 數據範圍、處理目的、儲存及分享方式已獲批准;

• 權限分配、身份驗證、加密、日誌記錄及事故應變均已就緒;

• 各方清楚事故發生時的協調聯絡窗口。

若未能滿足上述條件,企業應將此視為準備階段來處理,不應為了「追趕進度」而強行引入真實交易。

2. 在選定KPI之前先寫下先導計劃假設

一個好的假設應包含四個部分:對象、變化、預期結果及量度條件。

範例結構

> 針對[單位]內合資格的員工群組,按[政策]在[時間]內提供日薪預支,預期能帶來[結果],同時維持在[營運及風險門檻]之內。

範例說明

> 針對A廠已完成試用期的生產員工,日薪預支預期可提升員工應對短期開支的主動性,並減少人手預支申請;同時交易須在已核准的內部目標範圍內完成處理、對數及支援。

此範例並未假設任何改善百分比。數字目標須以企業本身的基準數據為依據制定,而非照搬市場推廣資料或其他客戶的數字。

3. 選擇範圍要小到可控、大到可學習

選擇單位的準則

• 單位主管願意配合;

• 考勤流程相對穩定;

• 員工群組的需求與目標相符;

• 薪資及人力資源部門能準時提供數據;

• 有現場或遙距支援團隊;

• 沒有同時進行太多系統/政策變動;

• 如需評估影響,可建立合適的對照組。

不應只因「最容易的單位」而選擇

過於理想的單位或能令先導計劃「成功」,卻未必能代表日後擴展的其他單位。相反,一開始就選最棘手的據點,可能令項目團隊無法分辨究竟是產品本身的問題,還是數據基礎的問題。

較平衡的做法,是選擇複雜度適中的範圍,並清楚記錄與全公司的差異之處:班次類型、發薪方式、收款銀行、地區、年資、合約類型及考勤系統。

範圍描述表

4. 六個階段的先導計劃路線圖

(逐日詳細計劃,參閱企業日薪預支90日先導計劃。)

```mermaid
flowchart TD
A["1. 準備"] --> B["2. 設計"]
B --> C["3. 系統整合"]
C --> D["4. UAT及演練"]
D --> E["5. 先導運作"]
E --> F["6. 評估及決策"]
```

每個階段所需時間視乎準備程度而定。在完成數據及系統調查之前,不應貿然承諾統一的時間表。

5. 第一階段 – 準備及審批項目建議

主要工作

1. 確定目標及假設;

2. 選定範圍及對照組;

3. 成立指導委員會及項目團隊;

4. 確定預算及資源;

5. 建立初步風險登記冊;

6. 收集基準數據;

7. 審核法規、數據及合約;

8. 就先導計劃結束時的決策標準達成共識。

交付成果

• 項目章程(Project Charter);

• 範圍說明書;

• 持份者名單;

• RACI矩陣;

• KPI組合及基準數據;

• 風險登記冊;

• 溝通計劃;

• 每個階段的進入/退出條件。

過關條件

若尚未確定政策審批人、數據負責人及薪資/對數方面的最終負責人,不應進入詳細設計階段。

6. 第二階段 – 政策及旅程設計

需要敲定的政策

• 合資格對象;

• 可參與的在職狀態;

• 合資格的考勤或收入類型;

• 額度計算方式及上限;

• 交易次數限制;

• 收費政策及費用承擔方;

• 適用週期/截數時點;

• 離職、暫停在職及考勤更正的處理方式;

• 失敗、狀態未明及退款交易的處理方式;

• 交易計入薪資及會計的方式。

員工使用旅程

1. 獲取資訊;

2. 登記/啟用;

3. 身份驗證;

4. 查看可用額度;

5. 選擇提取金額;

6. 確認前查看完整資訊;

7. 交易驗證;

8. 獲取交易狀態;

9. 收款或在出錯時獲得指引;

10. 查看歷史記錄及相關結算。

營運旅程

須為人力資源部、負責審批考勤的主管、薪資部、財務部、IT部、支援團隊、風險管理部及付款合作夥伴分別設計流程。即使員工端介面設計得再好,也彌補不了內部流程缺乏負責人的問題。

7. 第三階段 – 數據及系統整合

(數據需求及架構詳情,參閱日薪預支與考勤、薪資及ERP的整合及日薪預支交易與薪資、會計的對數。)

最低數據集

• 員工資料及在職狀態;

• 法人實體、單位、薪資群組;

• 考勤/工時及審批狀態;

• 薪資週期、截數時點及所需規則;

• 在安全處理範圍內的收款帳戶;

• 日薪預支交易;

• 付款狀態;

• 用於對數的薪資/ERP數據。

技術決策

• 近乎即時的API、批量檔案/SFTP或其他可控方式;

• 識別鍵及對應表;

• 數據版本及遲到數據的處理;

• 冪等性(idempotency)及防止檔案重複;

• 交易狀態;

• 重試、逾時及警示;

• 對數及差異報告;

• 權限分配、日誌及數據儲存。

UAT前的數據質量檢查

不應在測試環境中使用未受保護的真實數據。測試數據須經過適當模擬或遮蔽處理。

8. 第四階段 – UAT及演練

UAT須同時測試成功流程及各種異常情況。

員工情境組

• 成功啟用;

• 身份資料錯誤或缺失;

• 更換裝置、電話號碼或收款帳戶;

• 因考勤未經審批而無可用額度;

• 申請超出額度;

• 交易成功、失敗及處理中;

• 就非本人發起的交易提出投訴;

• 員工離職或調職。

數據情境組

• 審批後更正的考勤;

• 舊版本數據延遲到達;

• 檔案重複或次序錯誤;

• 部分記錄出錯;

• 員工編號對應錯誤;

• 薪資週期或截數時點錯誤;

• 源頭數據暫停供應。

支付情境組

• 重新發送相同的idempotency_key;

• 發送指令前或後逾時;

• 回調(callback)延遲、重複或簽名錯誤;

• 收款帳戶無效;

• 合作夥伴回報結果未明;

• 交易成功後被退款。

薪資及會計情境組

• 交易計入正確週期;

• 攔截已輸入的交易;

• 總額與逐筆交易相符;

• 處理截數後的調整;

• 差異建立個案並指定負責人;

• ERP/憑證可追溯至相關交易。

事故演練

至少應演練以下情境:

• 員工帳戶被盜用;

• 匯款錯誤或懷疑重複扣款;

• 大規模考勤同步錯誤;

• 數據檔案外洩;

• 臨近出糧日服務中斷;

• 付款服務供應商無回應。

每次演練都須記錄由誰決定封鎖流程、由誰負責通知、哪些數據須保留,以及重新開放的條件。

9. 先導計劃正式上線條件

必要條件

• [ ] 範圍及合資格名單已獲批准。

• [ ] 額度、收費、截數時點及例外處理政策已敲定。

• [ ] 業務、系統整合、保安及對數方面的UAT已達標。

• [ ] 嚴重缺陷已修復並重新測試。

• [ ] 初始數據已完成對數。

• [ ] 支援及升級聯絡窗口已就緒。

• [ ] 每日報告及警示機制已運作。

• [ ] 回退或暫停方案已完成演練。

• [ ] 向員工發放的資訊已獲審批。

• [ ] 有權限人士已簽署正式上線決定。

不應因先導計劃參與人數少而放行嚴重缺陷。規模小只是縮小影響範圍,並不會減輕保護員工及資金安全的責任。

10. 第五階段 – 受控先導運作

初期「加強關注」(hypercare)機制

在初期階段,各方宜以較密的頻率進行監察:

• 檢查考勤數據及額度;

• 追蹤出錯/狀態未明的交易;

• 即日對數;

• 召開簡短會議處理阻礙事項;

• 統一維護單一問題清單;

• 向受影響用戶作透明通報;

• 記錄臨時應對措施及根本解決方案。

毋須訂立固定的hypercare時長。當數據、交易及支援已按核准標準趨於穩定,即可調降監察頻率。

決策日誌

先導計劃期間任何政策變動均須記錄:

• 問題;

• 佐證數據;

• 採納的方案;

• 審批人;

• 生效日期;

• 受影響群組;

• 變動後的量度方式;

• 回退方案。

若同時改動太多變數,企業將無法判斷究竟是哪項改動帶來了結果。

11. 先導計劃RACI範本

符號說明:R – 執行;A – 最終負責;C – 諮詢;I – 知會。

此為範本。企業須按實際組織架構調整,並確保每項工作只有一個角色明確承擔最終責任。

12. 均衡先導計劃KPI組合

(完整指標組合,參閱應以哪些KPI量度日薪預支成效?及推行日薪預支的ROI計算方法。)

觸達及使用KPI

• 合資格人員比率;

• 資訊接收率;

• 啟用開始及完成比率;

• 顯示可用額度的比率;

• 活躍用戶比率;

• 按群組(cohort)劃分的交易頻率及金額。

體驗KPI

• 交易成功率;

• 收款時間的中位數及百分位數;

• 各步驟的放棄率;

• 每千宗交易的工單數目;

• 回應及解決時間;

• 滿意度及對收費/條款的理解程度。

人力資源KPI

• 人手預支申請數目;

• 缺勤及無故缺席;

• 按群組劃分的離職率;

• 新入職員工的出勤率;

• 對此項福利的認知度及感知價值。

營運KPI

• 考勤按時獲審批;

• 數據新鮮度;

• 自動處理比率;

• 自動對數比率;

• 按來源劃分的數據錯誤;

• 截數後的調整;

• 差異結案時間。

財務及風險KPI

• 總擁有成本;

• 每名合資格人員/活躍用戶/每宗交易的成本;

• 結果未明的交易;

• 差異的比率及金額;

• 已確認的欺詐個案;

• 誤攔截比率;

• 保安或數據事故;

• 逾期未處理的存取權限及例外情況。

13. 成果KPI與保護KPI

成果KPI反映計劃創造了甚麼價值;保護KPI則防止項目團隊為達標而製造其他風險。

若業務KPI達標,但保護KPI已超出可接受水平,則不應進行擴展。

14. 如何設定KPI目標?

步驟一:取得基準

以相同的定義量度先導計劃開始前的數據:離職率、缺勤、預支申請、薪資工單、處理時間及成本。

步驟二:界定必要最低要求

例如:不得有重複扣款、不得有未處理的嚴重保安漏洞、狀態未明的交易須有專人跟進、薪資須能對數。這些是管控條件,而非增長目標。

步驟三:設定改善目標

須根據基準數據、系統能力及範圍而定。每個目標均須列明數據來源、計算方式、負責人及量度時間點。

步驟四:設定預警閾值及停止閾值

預警閾值觸發調查;停止閾值則按授權觸發暫停個別流程或整個先導計劃。

步驟五:上線前審批

不應為了遷就既定結果而更改先導計劃結束時的標準。若有正當理由需要更改,必須記錄於決策日誌內。

15. 停止或暫停先導計劃的標準

計劃須事先訂明何時應停止接受新交易、暫停某個群組,或終止整個計劃。

以下事件可能觸發緊急檢視:

• 懷疑大範圍出現重複扣款或匯錯對象;

• 考勤/薪資數據錯誤導致額度不可靠;

• UNKNOWN(狀態未明)交易累積至超出可控範圍;

• 嚴重保安漏洞尚未被隔離;

• 數據外洩或被超出範圍使用;

• 薪資在結算前無法完成對數;

• 資金來源或付款合作夥伴中斷;

• 投訴異常增加;

• 防欺詐管控誤攔截大量合法用戶;

• 項目團隊已無法提供安全的支援。

具體的數字門檻應載於內部計劃文件,如公開可能削弱管控成效則不應對外發布。

暫停不同於終止

暫停是在保留數據、交易及證據的同時,保護用戶並展開調查。終止先導計劃則是經評估後的管治決定。流程須清楚訂明誰有權暫停、誰負責審批重新開放,以及如何通知員工。

16. 第六階段 – 先導計劃結束評估

評估應同時運用數據及定性證據。

定量數據

• 先導計劃前、中、後的KPI;

• 與基準數據比較;

• 如有對照組,與之比較;

• 按群組、單位及旅程劃分的結果;

• 總成本及效益假設;

• 事故、差異及剩餘風險。

定性數據

• 訪談有使用及沒有使用的員工;

• 主管、人力資源、薪資、財務及支援部門的反饋;

• 用戶流失(漏斗跌出)的原因;

• 難以擴展的人手步驟;

• 未能在儀表板上反映的問題;

• 從事故及例外情況中汲取的經驗。

不要急於下因果結論

若離職率下降,須一併考慮季節性因素、訂單量、薪酬、獎金、管理及其他政策的影響。若使用日薪預支的員工離職率反而較高,亦有可能是該群組原本已承受較高的財務壓力。當研究設計尚不足以斷定因果關係時,報告應採用「觀察到差異/訊號」等較審慎的表述方式。

17. Go – Adjust – Extend – Stop 決策矩陣

建議的Go條件

• 主要價值目標已達成或有足夠有力的證據;

• 沒有尚未修復的嚴重缺陷;

• 交易、薪資及會計均能完成對數;

• 每人/每宗交易的支援工作量呈可控趨勢;

• 擴展成本已被完整計算;

• 員工理解政策並有支援渠道;

• 剩餘風險有負責人並獲有權限人士接受;

• 系統架構能應付更大規模;

• 下一批單位與先導計劃單位的差異已被評估。

即使使用率KPI達標,但保安、對數或對員工的透明度未達標,仍不足以構成Go的條件。

18. 分批擴展計劃

若各單位、系統或政策存在顯著差異,不應由小規模先導計劃一步跳到全公司推行。

批次(wave)設計

每個批次應將特徵相近的單位歸為一組:

• 同一考勤/薪資系統;

• 同一法人實體或政策;

• 同一班次組別及計薪方式;

• 人力資源/主管的準備程度相若;

• 同一支援渠道;

• 付款複雜程度相近。

每個批次前的關卡

• 數據及對應表已檢查;

• 支援團隊具備足夠能力;

• 上一批次的問題已處理;

• 對數及儀表板已擴展至新範圍;

• 按新範圍的存取權限已審核;

• 溝通內容已按員工群組調整;

• 回退方案已就緒;

• 已獲有權限人士批准。

每批次後的追蹤

不應只與首個先導計劃比較。每個單位的啟用率、數據錯誤、收款銀行及使用行為都可能有所不同。須按批次逐一比較,並留意成效是否隨規模擴大而下降。

19. 簡化版項目章程範本

1. 項目名稱

在[單位]推行的日薪預支先導計劃。

2. 待解決的問題

說明現況數據、受影響群組及目前的影響。

3. 目標及假設

列明期望結果及保護KPI。

4. 範圍

法人實體、單位、員工、系統、薪資週期、時間及交易類型。

5. 不涵蓋範圍

尚未推行的員工群組、系統或功能。

6. 交付成果

系統整合、文件、培訓、UAT、儀表板、對數及先導計劃結束報告。

7. RACI

誰是最終負責人、誰負責執行、誰需諮詢及誰需知會。

8. 風險及相依因素

數據、薪資、付款、保安、法規、資源及薪資週期時間表。

9. 預算

供應商費用、系統整合、人力、支援、保安、溝通及應急預備金。

10. 決策標準

Go、Adjust、Extend、Stop,以及負責審批的有權限人士。

20. 先導計劃結束評估報告範本

A. 管理層結論

• 哪些目標達成/未達成;

• 建議的決定;

• 重大風險;

• 下一步所需資源及條件。

B. KPI結果

C. 財務

總成本、有根據的效益、假設條件、擴展時的成本及敏感度情境分析。

D. 風險

事故、欺詐、誤攔截、差異、個人資料、剩餘風險及接受風險的負責人。

E. 經驗總結

哪些做法應保留、修正或捨棄;推廣至其他單位所需的條件。

F. 決定

Go/Adjust/Extend/Stop;範圍;預算;負責人;檢視時間點。

21. 推行日薪預支先導計劃常見錯誤

開始前未定義何謂成功

到先導計劃結束時,各部門各自選取對本身立場有利的指標。

只顧規模而忽略代表性

人數雖然足夠,但全部只來自同一班次、同一主管或同一系統,無法反映全公司的實際情況。

未跑完一個完整薪資週期

只評估到應用程式層面,卻未驗證對數、結算及週期末調整。

只測試成功流程

不清楚如何處理逾時、考勤遲修改、帳戶錯誤、退款及薪資輸入錯誤等情況。

量度很多卻沒有基準數據

推行後有儀表板可看,卻不知道計劃究竟改善了甚麼。

在營運團隊仍靠人手處理時就擴展

先導計劃看似穩定,是因為項目團隊「逐筆盯緊每宗交易」,但這種模式根本無法擴大規模。

政策不斷更改

無法分辨究竟是政策、溝通、數據還是產品本身帶來的影響。

沒有結束計劃

終止時,交易尚未對數、數據尚未刪除、員工未獲通知,而且責任誰屬亦不清楚。

22. 先導計劃中的數據及員工保護

(完整保安框架,參閱推行日薪預支時的數據保安及私隱保護及日薪預支的風險管理及防欺詐機制。)

先導計劃仍須遵守數據保護及資訊保安的原則。企業須按用途限制數據範圍、按職能分配權限、使用安全的測試數據、保存日誌記錄、管理供應商,並備有事故應變計劃。

在越南,《個人資料保護法》第91/2025/QH15號將於2026年1月1日起生效。先導計劃的設計須按各方角色、數據類型、分享範圍及員工權利加以審核。

在人力資源量度方面,ISO 30414:2025就人力資本報告提供了相關要求及建議。在資訊保安風險管治方面,NIST Cybersecurity Framework 2.0是一個參考框架,可用以組織管治、識別、保護、偵測、應變及復原等活動。以上僅為參考來源;先導計劃的標準仍須按企業本身及實際的日薪預支模式來設計。

結論

日薪預支先導計劃是一項受控的管治決定,而不僅僅是一次技術試用。一個可信的先導計劃,必須具備假設、基準數據、具代表性的範圍、清晰的政策、質量足夠的數據、涵蓋異常情況的UAT、保護KPI,以及事先獲批准的停止標準。

先導計劃結束時,企業須以實證為依據,在Go、Adjust、Extend或Stop之間作出選擇。如企業有意制訂一套配合現有考勤系統、薪資系統及員工結構的日薪預支先導計劃,歡迎瀏覽企業日薪預支方案,進一步商討調查範圍及推行所需的文件套件。

參考資料

• ISO 30414:2025 – Human capital reporting and disclosure

• NIST Cybersecurity Framework 2.0

• 《個人資料保護法》第91/2025/QH15號

• 第356/2025/NĐ-CP號議定 —《個人資料保護法》實施指引

---

作者: Tran Van Tai — 總經理特別助理,負責發展策略,Nhan Kiet Manpower Supply Co., Ltd.

企業日薪預支方案諮詢: 熱線 0937.022.655 · 電郵 info@nhankiet.vn · 企業日薪預支方案