一、排产真正的痛点：不是算不出来，是没人知道
很多制造企业的周计划其实有人做——生产内勤用 Excel 排，周一早上打印出来贴到车间白板上。真正的问题从第二天开始：
- 计划变了，白板没变。 设备故障、来料延迟、客户插单，改完 Excel 忘了重新打印，车间照着旧单子干了一整天。
- 进度靠腿问。 老板想知道"这批货做到哪了"，得去车间数工位；班组长一天要回答十几遍同样的问题。
- 完工数量滞后。 报工写在纸质流转卡上，晚上甚至第二天才录进电脑，当天的实际进度是笔糊涂账。
- 改期没有约束。 插一张单，谁也不知道会把后面哪几张挤掉，全靠老师傅的记忆判断冲突。
- 数据留不下来。 为什么延期、哪个工序最常卡住，事后想复盘只能凭印象说。
这些都不是 APS（高级排程算法）要解决的问题。绝大多数中小批量、多品种的企业，缺的首先是一套让计划、执行、反馈三方看同一份数据的底座。本文讲的就是这个底座怎么用 AI 构建器搭出来——不写优化算法，只讲数据结构怎么建、页面怎么用、移动端怎么配合、上线前查什么。
二、数据怎么建：四张表撑起一套排程
排程系统的数据模型不需要复杂，核心是四层引用关系：产品 → 工艺路线 → 生产工单 → 工序任务。前面两层是相对稳定的基础档案，后面两层是每天在变的执行数据。
1. 产品与工艺路线（基础档案）
产品档案记录品名、编码、规格、单位。工艺路线是关键的一张表：一个产品对应一条路线，一条路线下面挂着若干道工序，每道工序有顺序号、工时定额、默认工作中心（班组或机台）。
这一步的价值在于：排程的对象从"订单"变成了"工序任务"。有了工艺路线，一张生产工单落进来就能自动展开成"下料—焊接—机加工—装配—包装"五条待排任务，不用人工一条条敲。
平台的数据字典能力在这里用来固化口径：工序类型、任务状态、班次、优先级都做成字典项，全公司统一叫法。避免"A3 线""三号产线""3号线"三种写法把统计打散。
2. 生产工单（计划的载体）
工单字段建议保持精简：工单号、产品（引用产品档案）、计划数量、已完成数量、计划开始日、计划完成日、客户/订单备注、状态（草稿 / 已下达 / 生产中 / 已完工 / 已暂停）、优先级。
两条数据约束值得在一开始就定下来：
- 状态决定可编辑范围。 草稿态随便改；一旦"已下达"，计划数量与日期字段的修改就要走审批流并留下变更记录；"已完工"后所有字段锁定。
- 已完成数量不由人填。 它是下面工序任务报工汇总上来的结果，不是工单页面上的输入框。手工填的完工数一定会和现场对不上。
3. 工序任务（排程的最小单元）
这是整套系统的重心。每条任务挂在工作单下，字段包括：所属工单、工序序号、工序名称、计划开始/结束时间、指派到的工作中心（机台或班组）、负责人、状态（待排 / 已排 / 进行中 / 完工 / 暂停 / 取消）、实际开始/实际完成时间、报工数量、异常标记。
任务的状态机要简单清晰，每个状态转换都要有时间戳。"实际开始时间"由班组长在手机上点一下"开工"写入，"实际完成时间"由报工写入——这两个字段一旦有了值，看板上的颜色就是真的，不是猜的。
三、页面怎么用：车间要的是日视图，不是甘特图
排程模块的页面设计有个常见误区：一上来就想做甘特图。实际上车间班组长每天看的是"今天这个机台该干什么"，管理者每周看的是"这周有哪些单会延期"。两类需求对应两类页面，都不需要拖拽排程。
1. 待排任务池（生产内勤的工作台）
一个列表页，筛选条件默认是"状态 = 待排"，按工单交期升序排列。每行显示：产品、数量、交期、剩余天数、工序名称、标准工时。
内勤的操作只有两个动作：指定工作中心 和 指定计划日期。指定完成后状态自动从"待排"变"已排"，任务就从池子里消失，进入下面的日视图。
这里可以配一条数据流规则（平台的数据流引擎支持条件触发的数据变换）：当任务的计划结束日期早于所属工单的交期时，自动给工单打上"有风险"标记。不用人算，也不用等周报。
2. 车间日视图（班组长的主页面）
按"工作中心 × 日期"组织的表格：一行一个机台或班组，列是当天的任务序列。单元格显示产品名、数量、状态色。这就是把白板搬到系统里，但它是活的——计划一改，所有终端同时刷新。
颜色规则要少而明确，四种足够：
- 灰色：待排 / 未开始
- 蓝色：进行中（已过计划开始时间且有实际开工）
- 绿色：完工
- 红色：逾期（当前时间 > 计划结束时间且状态未完工）
颜色由状态与时间字段推导，不让人手工选色。人一旦能手动改颜色，看板第二天就变成装饰品。
3. 周计划总览（厂长和计划员看的）
按天汇总的负荷视图：每个工作中心在未来七天里每天排了多少工时、对比它的标准产能，超载的行高亮。这张表回答的不是"最优排法是什么"，而是"我这样排会不会明显干不完"——对多数企业来说，后者才是每天真正要做的判断。
同一页面上方放几个关键指标：本周下达工单数、在制工单数、逾期任务数、今日完工数。指标全部来自实时查询，不做人工填报。
4. 工单详情页（追溯用）
一张工单打开后能看到它的全部工序任务、每条任务的实际起止时间、报工记录、异常说明、以及历次改期记录。客户问"我的货为什么晚了三天"，答案在这页上能找到具体是哪道工序卡了多久。
四、移动端在车间怎么配合
排程数据的源头在车间现场，所以移动端不是"PC 的缩小版"，而是三个高频动作的入口。PC 端构建好的模块会自动同步到移动端，班组长用手机就能操作，不需要单独开发一套 App。
开工打卡。 班组长在手机上找到今天的任务，点"开工"，写入实际开始时间。这一步让看板上的蓝色是真的。
报工。 完工时填数量、选合格/返工/报废，提交。报工数据向上汇总，驱动工单的已完成数量和状态流转。建议放在移动端而不是 PC，因为工位上没有电脑。
异常上报。 设备故障、缺料、质量问题，一键选择类型并拍照上传（平台的文件能力支持图片附件）。异常触发后任务自动置为"暂停"，看板立刻变红，同时通过站内信通知到设备或采购相关的人。
这三步做完，车间的数据就不再依赖晚上回办公室补录了。当天进度当天可见，这是轻量排程能落地的前提。
五、插单与改期：把冲突变成可见的数据约束
车间最抗拒数字化的一句话是"计划赶不上变化"。轻量排程不去消灭变化，而是让变化的后果立刻可见。
1. 改期走审批，不走直接编辑
工单已下达之后修改计划日期，触发平台的审批流：申请人填写原因，计划员或厂长审批。审批通过后系统才写入新日期，同时保留旧值形成改期记录。这样做的收益不是管控本身，而是留下"为什么改"的原始数据——三个月后复盘延期原因，有账可查。
2. 冲突检测用规则，不用算法
在任务保存时做两条朴素校验：
- 同一工作中心、同一天的累计计划工时超过标准产能 → 提示超载，允许继续保存但标记风险。
- 工序序号小的任务计划结束时间晚于下一道工序的开始时间 → 提示工艺顺序冲突。
这两条不需要求解器，就是查询加比较。它们的作用是让内勤在排的时候就知道"这么排有问题"，而不是等到车间停工才发现。
3. 插单的实际操作
插单 = 新建一张高优先级工单 + 展开工序任务 + 指定到目标工作中心和日期。系统按上面的规则提示该时段是否已被占满，内勤据此决定顺延哪些现有任务。被顺延的任务批量改期，同样留下改期记录。
整个过程在页面上是几次点击，而不是一场会议。这才是"轻量"的含义：不追求数学最优，追求改一次计划只要几分钟、所有人都能立刻看到新版本。
六、上线前查什么
排程模块涉及现场执行，数据一旦不准，车间很快就不信了。上线前建议逐项核对：
- 基础档案完整性。 每个要排产的产品都有工艺路线吗？每条路线的工序顺序号连续无重复吗？工时定额有没有填 0 的？漏一个产品，车间当天就会退回纸质流程。
- 工作中心与人员绑定。 每台机台/每个班组是否有明确负责人？移动端报工权限是否只开放给对应班组？
- 状态字典口径。 待排/已排/进行中/完工/暂停/取消，每个状态的进入条件和退出条件是否和班组长讲清楚过？颜色规则是否由字段推导而非手工选择？
- 历史数据起点。 建议选一个自然节点（周一开工）冷启动，不把在制的老工单硬塞进新系统。带着干净的数据起步，第一周的看板才可信。
- 权限分层。 车间只能看本班组任务与报工；计划员可改排程；工单的锁定字段需要审批；管理层可看全量总览。平台按角色配置权限点，上线前用真实账号逐角色登录验证一遍。
- 通知链路。 异常上报、超载提示、审批待办这三类消息，接收人是否正确？站内信通道是否已开通？
- 移动端实测。 拿真机到车间走一遍开工—报工—异常上报，确认网络、字号、拍照上传都可用。这一步别在办公室做。
七、之后怎么延伸
这套数据结构搭好后，往几个方向延伸都不用推倒重来：
- 接质量检验。 报工时增加合格/返工数量，就能长出检验记录和工序合格率统计。
- 接设备点检与维保。 工作中心关联设备档案，超载或异常记录自然成为保养排期的输入。
- 接物料与备料。 工单展开出工序任务的同时展开用料需求，形成缺料预警清单。
- 积累实际工时。 跑上几个月，每道工序的真实耗时就有了样本，这时再谈排程精度或引入优化算法，才有数据可依。
轻量排程的价值不在于替代 APS，而在于把计划、执行、反馈三方的数据先打通。有了这份底座，企业后续无论做什么升级，都是在真实数据上做，而不是在 Excel 上做。