記錄、角色、規則與上線
如何設計資源管理系統
首先定義需求、人員、可用性、申請和資源分配記錄；軟體無法修復定義不清的容量基數，也無法替無人負責的審核作出決定。
登入後檢視範例應用，再安裝包含範例資料的版本，測試記錄和審核路徑。
設計原則
資源管理系統由記錄、角色、規則、檢討頻率、指標和軟體共同組成，用於將需求與可用容量配對。先從一個規劃期間和少量決策開始，待人員信任輸入資料後再逐步擴充。
- 先定義，再設定
- 每項規劃資訊都由一位負責人維護
- 首次上線驗證決策，而不是介面數量
系統設計
讓每項持續變化的資訊都有清晰負責人
分開記錄可以減少歧義，也便於系統整合。
| 記錄 | 最少欄位 | 業務負責人 |
|---|---|---|
| 人員與技能檔案 | 穩定識別碼、團隊、職級、技能、工作容量、下次可用時間 | 容量或人力營運團隊 |
| 可用性變化 | 人員、類型、開始時間、結束時間、受影響工時、核准狀態 | 本人及審核經理 |
| 工作需求 | 成果、負責人、技能、職級、工時、日期、確定性、優先順序 | 專案、服務或專案組合負責人 |
| 人員申請 | 需求、候選人員、工時、日期、適配程度、衝突、決定 | 資源或容量負責人 |
| 資源分配 | 已確認工作、人員、工時、日期、狀態、保護狀態、健康狀態 | 交付與容量負責人 |
| 異常 | 訊號、受影響記錄、嚴重程度、決策、負責人、截止日期 | 指定決策負責人 |
決策權限
設定工作流程前先寫清營運約定
系統應讓責任更加清晰，而不是把每項變更都變成集體討論。
需求負責人
定義工作、成果、日期、所需能力和優先順序。
容量負責人
維護規劃假設，並審核不同工作之間的衝突。
人員經理
確認可用性和能力限制，同時避免暴露不必要的 HR 詳情。
交付負責人
工作開始後回報健康狀態及計畫與實際變化。
實施順序
選擇一項重複發生的決策，開展端到端試點
一套範圍較小但流程完整的做法，比涵蓋廣泛卻只是靜態呈現的記錄庫更有學習價值。
統一定義與邊界
確定規劃期間、容量基準、需求狀態、審核節點和權威資料系統。
匯入一組乾淨的工作資料
匯入在崗人員、目前可用性、已承諾工作和有限範圍的預測。
執行真實的人力配置決策
提交、退回、核准、分配並修正具有代表性的申請。
檢討指標與流程阻力
擴充前，檢查過時輸入、未解決缺口、決策耗時、排程變更和使用者修正情況。
指標
衡量系統是否改善了決策
不要把高利用率百分比當作唯一成果。
人力配置決策用時
從申請資訊完整到核准、退回或拒絕所需的時間。
未滿足需求的等待時間
已準備好的工作在沒有可靠人員安排的情況下等待了多久。
開始前解決的過載
在計畫工作開始前已糾正的衝突比例。
計畫準確度
依工作類型和分析期間比較計畫與實際工時差異。
修正率
使用者修正過時可用性、技能或需求假設的頻率。
實用問題
設定前需要明確的系統設計問題
選擇權威記錄、決策負責人、檢討節奏，以及能夠檢驗真實人員選擇的首次上線範圍。
資源管理系統應使用什麼規劃單位？
工時是實用的統一尺度，但僅憑工時還不夠。範例會把技能、職級、時區、可用性、日期、優先順序和交付狀態與工時放在一起，避免把「數學上有空」的人誤認為真正合適的人選。 選擇團隊有能力持續維護的統一尺度，並將技能、日期、可用性和優先順序與其一起儲存，確保數字可解釋。
資源管理系統從第一天起就需要自動最佳化嗎？
不會。它會呈現容量、技能、日期、工作負荷和衝突等依據，供人員作出決策。規模較大時，自動最佳化可能很有價值，但前提是先明確約束條件、優先順序並具備專業能力。當營運規則和審核路徑需要由業務團隊自行設計時，Jodoo 更具優勢。 先建立可信輸入和責任明確的審核；再複雜的最佳化也無法彌補定義不清或決策權缺失。
誰可以更改資源管理系統？
受過訓練的 Jodoo 管理員無需重建傳統應用，就能新增欄位、選項、檢視、流程規則和儀表板。變更仍需明確負責人、完成測試並做好溝通，尤其是涉及審核、存取權限或報表指標時。 指定受過訓練的業務管理員，同時確保審核、存取權限和指標變更受到控管且可以測試。
哪個系統應負責維護員工可用性？
如果已有權威 HR、休假或勞動力系統，應以其為準，只將資源決策所需的已核准規劃資訊帶入流程。對於較小的流程，Jodoo 範例也可以維護可用性變化，或透過整合進行協調。
首次上線應包含什麼？
選擇一個有重複工作需求且需要真實人員決策的團隊。涵蓋正常、過載、不可用、已退回、已核准和已變更等情況。只展示匯入記錄的上線無法驗證流程是否真正幫助人員作出更好的選擇。
從設計到實際執行的系統
設定自己的系統前，先檢視完整的規劃流程
沿著資料檢視人員與需求如何經過審核、資源分配、異常處理，以及計畫與實際檢討。