资源与容量规划
什么是资源？
在流程仿真中，资源指的是具有有限容量、各活动需争抢的对象。资源带来真实瓶颈、排队和等待时间。
常见资源类型
| 类别 | 示例 |
|---|---|
| 人力 | 客服、信贷专员、管理人员、专员 |
| 设备 | 机器、工作站、测试设备 |
| 系统 | 软件license、服务器容量、API限流 |
| 场地 | 会议室、产线、检验工位 |
为什么要建模资源？
若无限制资源，模拟会假设容量无限，所有 case 无需等待直接处理，这不符合实际。
资源建模可：
- 发现真实瓶颈
- 精确预测等待时间
- 进行容量规划及假设分析
- 了解资源利用模式
资源池
ProcessMind 将资源按可互换单元组织成资源池。
资源池属性
| 属性 | 说明 |
|---|---|
| Name | 资源标识（如“审批人”、“贷款专员”） |
| Capacity | 资源池可用数量 |
容量说明
Capacity（容量） 指可同时有多少活动使用该资源：
- Capacity = 1：同一时刻仅 1 个 case 可用
- Capacity = 5：可同时支持 5 个 case 并行使用
示例： 若审批部门有 3 人，每人一次处理 1 个审批，容量设为 3。
分配资源到活动
在你的流程中，每个活动都可以声明所需资源：
分配属性
| 配置项 | 说明 |
|---|---|
| Resource Pool | 使用的资源池 |
| Quantity | 需要的资源数量 |
简单分配
大部分活动只需一个资源单位：
- 活动: “审核申请”
- 资源: “信贷员”（数量: 1）
多单元分配
有些活动需要多个单位：
- 活动: “重大决策委员会”
- 资源: “高级经理”（数量: 3）
资源分配：案例如何获取资源
当案例进入需要资源的活动时，仿真会按如下流程分配资源：
分配流程说明
- 检查可用性：所需资源是否可用？
- 排队等待：如不可用，该 case 加入等待队列
- 等待：case 等待直至资源可用
- 资源分配：资源可用时分配给此 case
- 执行：活动按采样时长运行
- 释放资源：结束后资源回到池中
队列行为和策略
ProcessMind 支持多种队列策略来确定待案在资源可用时的优先级：
| 策略 | 说明 |
|---|---|
| FIFO | 先进先出——按到达顺序处理（默认） |
| LIFO | 后进先出——新到优先 |
| Random | 随机从队列中抽取 |
你可在每个活动元素设置中定制队列策略。
如何选择队列策略
FIFO最常见也最公平。LIFO适于新案优先（如紧急升单）。Random适合模拟不确定服务。
资源不可用时怎么办？
如所需资源被占用：
- case 进入该资源的等待队列
- case 等待（模拟时间流逝）
- 资源释放后，根据队列策略选出等待 case
- 活动开始执行
这种排队机制让模拟产生真实等待时间。
通过时段建模资源可用性
资源的可用容量经常变化。用 periodicity 来建模资源时段可用性。
示例：营业时间
| 时段 | 容量 |
|---|---|
| 每周一至周五 09:00-17:00 | 5位坐席 |
| 每周一至周五 17:00-21:00 | 2位坐席 |
| 周末 10:00-16:00 | 1位坐席 |
| 其他 | 0位坐席 |
示例：轮班表
| 时段 | 容量 |
|---|---|
| 每天06:00-14:00（早班） | 5名操作员 |
| 每天14:00-22:00（中班） | 3名操作员 |
| 每天22:00-06:00（夜班） | 1名操作员 |
示例：季节性变动
| 时段 | 容量 |
|---|---|
| 每年11月15日-12月31日（高峰） | 20人 |
| 其他 | 12人 |
理解资源利用率
利用率衡量资源的繁忙程度：
利用率 = (忙碌时间 ÷ 可用总时间) × 100%
利用率解读
| 利用率水平 | 意义 |
|---|---|
| 低于50% | 利用不足——资源过剩 |
| 50-70% | 平衡——有充足弹性 |
| 70-85% | 忙碌——高峰弹性有限 |
| 85-95% | 很高——易产生等待 |
| 超过95% | 瓶颈——队列积压 |
利用率陷阱
不要追求 100% 利用率
高利用率看似高效，但容易出问题。即使需求稍有波动，接近 100% 利用率时队列也会激增。建议目标为 70-80%，保障流程稳定和响应速度。
高利用率为何导致队列拥堵
以简单例子说明：
- 资源容量：1
- 平均处理时间：10分钟
- 到达率 5.5/小时（55% 利用率）：队列可控
- 到达率 5.9/小时（98% 利用率）：队列暴增
利用率接近 100% 时，哪怕有微小波动（如多几个 case 或任务稍长）队列都会堆积。
共享资源
一个资源池可以支持多个活动。这在实际业务中很常见：
设置共享资源
- 创建资源池（如“客户服务团队”）
- 将该池分配给多个活动
- 各活动竞争共享容量
示例：共享团队
“客户服务团队”（容量：5人）负责：
- “接听电话咨询”
- “处理邮件请求”
- “在线聊天支持”
这三个活动共用一资源池。如4通电话处理中，仅剩1人可做邮件或聊天。
共享资源的优势
- 模拟多技能灵活团队
- 展示不同业务类型间的资源竞争
- 识别最消耗资源的活动类型
多资源活动
有些活动需要同时用到多种不同类型的资源：
示例：设计评审会
| 资源池 | 需求数量 |
|---|---|
| 高级设计师 | 2 |
| 会议室 | 1 |
| 设计主管 | 1 |
注意： 只有当所有所需资源同时可用时，活动才可开始。如设计师有空但会议室没空，流程需等待。
多资源场景注意事项
- 可能产生复杂的排队模式
- 警惕多类型资源被阻塞
- 判断是否所有资源都需同时到位
利用仿真进行产能规划
资源仿真的最大价值之一就是产能规划。
仿真可解答的关键问题
我需要多少资源？
用不同容量进行仿真：
| 容量 | 平均等候时间 | 利用率 | 吞吐量 |
|---|---|---|---|
| 2人 | 45分钟 | 95% | 150/周 |
| 3人 | 12分钟 | 78% | 150/周 |
| 4人 | 3分钟 | 58% | 150/周 |
洞见： 增加第3人后等待大幅降，第4人改善不明显。
瓶颈在哪里？
对比全部资源利用率：
| 资源 | 利用率 |
|---|---|
| 前台 | 65% |
| 审核员 | 92% |
| 法律复核 | 48% |
| 结算团队 | 71% |
洞见： 审核员为瓶颈。加前台无效，积压只会更快拦在审核。
需求增大怎么办？
调高到达率试算：
| 需求 | 当前人手 | 队列变化 |
|---|---|---|
| 当前 | 5 | 稳定 |
| +20% | 5 | 缓慢增加 |
| +50% | 5 | 不可持续 |
洞见： 当前产能可应对约20%增长，再多需扩资源。
资源建模最佳实践
从简入手
先选最具实际约束的核心资源：
- 无需为每个人单独建模
- 可互换员工归入同池
- 仅在有意义处加细节
基于真实数据设定
请根据实际人员情况设定容量：
- 当前人数
- 工作时间与排班
- 历史可用性（包括请假、病假）
预留弹性（Slack）
现实中资源不可能100%可用：
- 人员需休息
- 设备需维护
- 有突发缺勤
建模时请用实际可用时间，而非理想值。
与实际情况验证
对比模拟与现实数据：
- 模拟队列长度与实际等待时间是否一致？
- 模拟吞吐量是否接近实际？
- 资源利用率是否合理？
如有差异，请调整资源模型。
考虑人力因素
注意人不是机器：
- 效率随时间波动
- 持续高利用率容易疲劳与出错
- 多技能培训有上限