记录、角色、规则与上线
如何设计资源管理系统
首先定义需求、人员、可用性、申请和资源分配记录；软件无法修复定义不清的容量基数，也无法替无人负责的审批作出决定。
登录后查看示例应用，再安装包含示例数据的版本，测试记录和审核路径。
设计原则
资源管理系统由记录、角色、规则、复盘节奏、指标和软件共同组成，用于将需求与可用容量匹配。先从一个规划周期和少量决策开始，待人员信任输入数据后再逐步扩展。
- 先定义，再设置
- 每项规划信息都由一位负责人维护
- 首次上线验证决策，而不是界面数量
系统设计
让每项持续变化的信息都有清晰负责人
分开记录可以减少歧义，也便于系统集成。
| 记录 | 最少字段 | 业务负责人 |
|---|---|---|
| 人员与技能档案 | 稳定标识、团队、职级、技能、工作容量、下次可用时间 | 容量或人力运营团队 |
| 可用性变化 | 人员、类型、开始时间、结束时间、受影响工时、批准状态 | 本人及审批经理 |
| 工作需求 | 成果、负责人、技能、职级、工时、日期、确定性、优先级 | 项目、服务或项目组合负责人 |
| 人员申请 | 需求、候选人员、工时、日期、匹配度、冲突、决定 | 资源或容量负责人 |
| 资源分配 | 已确认工作、人员、工时、日期、状态、保护状态、健康度 | 交付与容量负责人 |
| 异常 | 信号、受影响记录、严重程度、决策、负责人、截止日期 | 指定决策负责人 |
决策权限
配置工作流前先写清运营约定
系统应让责任更加清晰，而不是把每项变更都变成集体讨论。
需求负责人
定义工作、成果、日期、所需能力和优先级。
容量负责人
维护规划假设，并审核不同工作之间的冲突。
人员经理
确认可用性和能力限制，同时避免暴露不必要的 HR 详情。
交付负责人
工作开始后汇报健康度及计划与实际变化。
实施顺序
选择一项重复发生的决策，开展端到端试点
一套范围较小但闭环完整的流程，比宽泛却静态的记录库更有学习价值。
统一定义与边界
确定规划周期、容量基数、需求状态、审批节点和权威数据系统。
导入一组干净的工作数据
导入在岗人员、当前可用性、已承诺工作和有限范围的预测。
执行真实的人员配置决策
提交、退回、批准、分配并修正具有代表性的申请。
复盘指标与流程阻力
扩展前，检查过时输入、未解决缺口、决策耗时、排程变更和用户修正情况。
指标
衡量系统是否改善了决策
不要把高利用率百分比当作唯一成果。
人员配置决策用时
从申请信息完整到批准、退回或拒绝所需的时间。
未满足需求的等待时间
已准备好的工作在没有可靠人员安排的情况下等待了多久。
开始前解决的过载
在计划工作开始前已纠正的冲突比例。
计划准确度
按工作类型和规划周期比较计划与实际工时差异。
修正率
用户修正过时可用性、技能或需求假设的频率。
实用问题
配置前需要明确的系统设计问题
选择权威记录、决策负责人、复盘节奏，以及能够检验真实人员选择的首次上线范围。
资源管理系统应使用什么规划单位？
工时是实用的统一尺度，但仅凭工时还不够。示例会把技能、职级、时区、可用性、日期、优先级和交付状态与工时放在一起，避免把“数学上有空”的人误认为真正合适的人选。 选择团队有能力持续维护的统一尺度，并将技能、日期、可用性和优先级与其一起保存，确保数字可解释。
资源管理系统从第一天起就需要自动优化吗？
不会。它会呈现容量、技能、日期、工作负荷和冲突等依据，供人员作出决策。规模较大时，自动优化可能很有价值，但前提是先明确约束条件、优先级并具备专业能力。当运营规则和审批路径需要由业务团队自行设计时，Jodoo 更具优势。 先建立可信输入和责任明确的审核；再复杂的优化也无法弥补定义不清或决策权缺失。
谁可以更改资源管理系统？
经过培训的 Jodoo 管理员无需重建传统应用，就能添加字段、选项、视图、流转规则和仪表板。变更仍需明确负责人、完成测试并做好沟通，尤其是涉及审批、访问权限或报表指标时。 指定经过培训的业务管理员，同时确保审批、访问权限和指标变更受到管控且可以测试。
哪个系统应负责维护员工可用性？
如果已有权威 HR、休假或劳动力系统，应以其为准，只将资源决策所需的已批准规划信息带入流程。对于较小的流程，Jodoo 示例也可以维护可用性变化，或通过集成进行协调。
首次上线应包含什么？
选择一个有重复工作需求且需要真实人员决策的团队。涵盖正常、过载、不可用、已退回、已批准和已变更等情况。只展示导入记录的上线无法验证流程是否真正帮助人员作出更好的选择。
从设计到实际运行的系统
配置自己的系统前，先查看完整规划闭环
沿着数据查看人员与需求如何经过审核、资源分配、异常处理，以及计划与实际复盘。