需求人数和休假申请难以兼顾。
休假申请、时段需求、最低人数常常需要同时人工检查。
SHIFT & WORKFORCE OPTIMIZATION
休假申请、资格、需求人数。 按贵公司的规则 自动生成排班候选。
我们把现成排班工具难以吸收的条件整理成数理模型。系统生成可复核的候选方案，让人员能一边看理由和例外，一边确认结果。
- 起点
- Excel 排班表和规则备忘即可做初步确认
- 结果方式
- 候选方案由人员复核后再确认
- 边界
- 未满足条件和理由会显示出来
第24周 / 方案A
门店A每周排班
已检查全部硬性规则
需求满足100%
偏好匹配91%
排班差1次
可说明结果王伟被安排周一早班的理由值班负责人 / 偏好早班 / 本周负荷较低
问题
比填表更重的是平衡各种条件的判断。
排班难点不是把名字填进表格，而是同时保持许多规则、偏好和例外一致。
必须安排合格人员。
负责人、持证人员、设备操作人员等，必须出现在指定时段。
公平性难以靠目视确认。
夜班、周末、总班次数和高负荷工作不能集中在少数人身上。
小变化会导致整体重排。
一次缺勤或需求变化，就可能让整张表需要重排。
自动化目标不是排班表本身，而是排班负责人在制作表格时反复进行的判断。
建模
把现场规则转成可计算条件。
把“尽量公平”“不要连续工作”“这两人分开”“尊重休假申请”等现场语言，转换成数据、硬性规则、偏好和评分。
目标函数示例
人数不足 x 1000 + 资格缺口 x 1000 + 偏好违背 x 20 + 工作量不均 x 5
权重仅用于说明。实际项目会通过访谈确定绝对条件和优先级，并与真实排班比较后调整。
输入数据
员工、可出勤时间、休假申请、资格、需求人数和现行排班。
硬性条件
需求人数、资格安排、休息限制等不能违反的条件。
偏好条件
休假申请、偏好班次、公平性等尽量满足的条件。
复核输出
排班候选、未满足条件、理由、指标和变更影响。
可操作演示
调整条件，重新计算排班候选。
可以切换业务场景，并调整需求人数、资格安排、偏好、公平性和连续工作上限。排班候选、指标和检查日志会同步更新。
这是用于说明的简易启发式演示，不是生产用优化引擎。
人数满足率
资格安排率
偏好匹配率
排班次数差
| 员工 | 周一 | 周二 | 周三 | 周四 | 周五 | 周六 | 周日 |
|---|
规则库
把“贵公司默认如此”的条件逐一模型化。
以下代表规则会逐步建模。不是一开始就加入全部条件，而是根据运营重要度和数据是否存在来决定第一阶段范围。
COV-01
硬性
各时段需求人数
按星期、时段、地点、部门和角色设置最低人数和建议人数。
COV-02
偏好
按繁忙程度增员
根据销售预测、预约数、入住人数、产量等调整建议人数。
LAB-01
硬性
连续工作与间隔
处理连续工作上限、夜班后休息、班次间隔等已确认的内部规则。
LAB-02
硬性
合同工时与上限
纳入周或月工时、雇佣类型上限、可加班时间等条件。
SKL-01
硬性
资格人员与负责人安排
保证各时段所需的资格、负责人或设备操作技能组合。
SKL-02
偏好
新人和熟练人员组合
避免新人单独值班，尽量与培训负责人或熟练人员组合。
PRF-01
偏好
休假申请与可出勤时间
区分不可出勤与休假申请，并按重要度设置优先级。
PRF-02
偏好
工作负荷公平性
减少夜班、周末、晚班、总班次数和高负荷工作的偏差。
PRF-03
偏好
固定负责人和匹配度
将客户连续性、团队匹配度和擅长领域纳入安排评分。
定制规则
贵公司理所当然的条件，正是建模对象。
通用示例中不会出现的条件，往往正是专用建模的价值所在。
闭店后不要立即安排开店避免全是新人值班特定两人不要同时安排支援其他地点每月最多两次夜班后第二天休息保持同一客户负责人
输出
返回判断材料，而不仅是排班表。
实用的排班系统不能只输出一张表，还应说明发生了什么变化、哪些条件未满足，以及人员需要检查什么。
多个候选方案
不是给出一个不透明答案，而是返回多个取舍不同的候选方案。
未满足条件
显示人数缺口、未满足的休假申请，以及无法满足的条件。
安排理由
说明为什么安排某个人，例如资格、偏好、当前负荷较低或覆盖优先。
变更影响
发生缺勤时，固定需要保留的班次，只重新计算受影响范围。
行业示例
为每个现场定义“好排班”。
什么是好排班，在不同现场并不相同。模型应使用业务现场本来使用的语言和优先级。
零售与餐饮
开店和闭店、繁忙日、卖场技能、周末公平性。
护理与医疗
日班和夜班、持证人员、照护连续性、休息间隔。
制造与物流
设备资格、产量、产线安排、轮班轮换。
现场与支持团队
现场可用人员、支持覆盖、紧急响应、移动约束。
自建或选型
标准排班适合现成服务。现场规则会左右结果时，专用模型更合适。
定制开发并不总是正确答案。应根据规则复杂度、数据准备度，以及可说明候选方案的业务价值来判断。
不会把定制开发当作默认答案。
如果现成服务能够很好解决问题，我们会直接说明。只有当定制条件的业务价值可能高于成本时，才建议开发专用系统。
现成服务足够时
如果班次模式标准、规则较少、团队规模不大，现成排班服务通常能更快开始。
适合定制系统时
资格、现场规则、临时变更和结果说明较多时，建立专用模型更有价值。
数据
从现有文件和规则备忘开始。
第一天不需要完整数据库。现有 Excel、纸质休假申请和员工台账，都可以整理成第一版数据契约。
员工与可出勤时间
员工姓名或 ID、技能、合同工时、可出勤时间、休假申请，足以开始第一版模型。
需求人数
按日期、时段、地点、部门、角色拆分的需求人数，定义了覆盖目标。
硬性规则与偏好
把绝对不能违反的规则，与尽量满足的偏好分开处理。
现行排班样例
当前排班和人工调整记录，可用于比较自动候选方案是否符合实际。
流程
正式开发前，先小范围确认是否能解。
第一目标不是替换整个业务，而是验证计划规则能否表达、生成候选是否有用。
01
确认当前做法
确认当前 Excel、休假申请收集和人工修正流程。
02
分类条件
分离硬性规则、偏好、评价指标和只能由人判断的部分。
03
试作计算部分
用代表数据建立小型计算组件。
04
比较候选方案
将生成候选与现行排班和负责人意见比较。
05
系统化业务
确认适合后，再连接编辑、权限和业务流程。
下一步验证
选择下一项要确认的内容。
从排班问题继续选择有助于团队判断的材料。
FAQ
排班自动化前的常见问题。
说明页面演示能展示什么、原型验证什么，以及哪些部分仍应由人判断。
本页演示就是生产用优化器吗？
不是。本页演示只是说明思路的简易启发式。实际项目会在确认规则、规模和响应时间后选择求解器或搜索方法。
可以从 Excel 开始吗？
可以。通常只要有当前排班、员工表、休假申请和简短规则备忘，就能开始第一轮确认。
系统会自动决定最终排班吗？
不会。系统应展示排班候选、未满足条件和安排理由，由人员确认最终排班。
休假申请如何处理？
除非组织明确把它作为硬性规则，否则会作为偏好处理。输出会显示哪些申请未满足，以及原因。
两周原型包含什么？
先限定在一个组织、一类排班和主要规则内，确认是否可计算、与现行方案相比是否有用。编辑、权限和业务集成在后续判断。