前年冬天我站在机加工车间里看调度员老周对着他那张花花绿绿的Excel排产表发呆。表格里每一个色块代表一道工序红的代表急单黄的代表等待物料灰色的是已经拖期的任务。他每天要花两三个小时在这张表上挪来挪去刚排好新的计划夜班班长又跑过来说三号机床主轴异响不能上工。那一刻我意识到这个“用Excel排产”的时代必须结束了。后来我们自研了一套生产调度系统内部代号就叫AX团队里喊它“Axe”意思是像斧头一样把每天两三个小时的排产时间砍到十几分钟把靠老师傅拍脑袋的决策逻辑变成可解释、可回放、可调整的规则引擎。这篇文章就是AX调度系统从立项到上线两年来的完整复盘。1. 为什么放着现成APS不用外购排产软件遇见的边界难题1.1 排产在工厂里到底难在哪排产这件事本质上就是给一大桌客人排座位有的客人非要靠窗有的客人赶时间还有几个拖家带口的必须坐一起而饭店就这么几十张桌子后厨的出菜速度还时不时掉链子。放在离散制造场景里我们面对的是每个月两三百个订单、五六百道工序、七八十台设备以及模具、刀具、物料、人员班次这些交织在一起的约束条件。人工用Excel排产最大的问题是“决策不可回溯”。老周今天这样排明天那样排问他为什么他只能说是凭经验。经验当然有价值但经验没法复制更没法在老师傅休假的时候被另一个人接管。而且Excel排产本质上是一次性快照上午排好的计划下午来了一个插单或者一台设备故障整个表格就要推倒重来。车间里真正的时间损耗往往不是因为某道工序干得慢而是因为上一道工序干完了、下一道工序还在等排产。1.2 调研外购APS时的三个死结我们也正经做过外购选型前后看了三四家APS高级计划排程供应商把他们的演示案例翻了个遍。实话实说软件本身质量不差但我们工厂用不起来卡在三个死结上。第一个死结是算法黑盒。供应商的排程引擎确实能算但你不知道它的优先级排序逻辑到底是怎么定义的。现场想调整一个规则比如“老客户A的订单优先于交期更近的订单B”销售部门内部都吵不清楚更别提让供应商按我们的逻辑改一版算法——那不是一个配置项能解决的事那是要动内核的。第二个死结是机台模型太僵化。我们车间里有几台老设备稳定性一般有些活就只能在那两三台设备上干其他新设备虽然快但加工工艺不支持。外购APS的设备组模型往往按“同类设备互为替代”来建模落到我们现场就失真了。模型一旦失真排出来的计划就是纸上谈兵。第三个死结是实施周期和数据接口。我们产线已经自建了MES系统有完整的报工数据。外购APS要跟MES做双向对接对方报价的实施周期是六个月起步项目组里还得专门养两个顾问。我们团队当时算了笔账与其被外部系统绑住手脚不如自己写一个调度引擎反正生产数据、工艺路线、设备台账都在我们自己手里。现在回头看自研AX这个决定是对的。关键在于我们的目标从来不是“做一个APS替代品”而是“做一个跟我们的MES和现场管理方式完全咬合的排产中枢”。2. AX的数据骨架订单、工序与设备约束的建模方式2.1 一个工单拆成可排程的任务四级数据模型排产系统最底层的功夫不是算法而是数据建模。数据模型如果跟现场不一致算法再漂亮也白搭。AX采用了四级模型销售订单拆成生产工单生产工单拆成工艺路线上的多道工序每道工序最终落到具体设备的加工任务上。销售订单是源头它决定了交期和客户优先级。生产工单是我们跟现场沟通的基本单元车间里每个人都认工单号。工艺路线由工艺部门维护每一道工序都挂接了标准工时、设备组要求、工装模具要求。最后一级是任务也就是“在某台具体设备上执行某道工序”的最小可调度单元。这里有一个关键的建模取舍我们不在排产阶段直接锁死“工单—设备”的绑定关系而是先生成“工单—工序—设备组”的候选集合由排产引擎在候选设备里做选择。设备组不是简单的“同类型机床划一组”而是要结合工艺能力、精度等级、加工范围来定义。比如五号车床和七号车床确实是同型号但七号车床的精度保持性更好精车工序只允许在这两台车上做粗车则可以放宽到另外四台设备。AX里每个设备组都有“允许工序集合”和“优先设备列表”两个属性为后面的排程算法留出决策空间。2.2 把现场约束翻译成数据字段建模过程中最难的不是订单和工序而是那些老师傅脑子里“默认知道”的隐性约束。我们把它们逐个摊开翻译成了AX里的数据字段。切换时间是第一个被低估的约束。很多排产教程里都假设“设备只要有空就能干下一道活”现实里设备从加工A产品切换到加工B产品可能要换夹具、换刀具、调参数这段切换时间短则半小时长则两三个小时。如果排产时不考虑切换计划就会比实际乐观很多。我们给每台设备建了一张“切换时间矩阵”记录不同工件族之间的切换耗时。工件族这个概念也是从老师傅那里挖出来的他们嘴里说的“这一批都是同类活”其实就是在说同一工件族内的切换成本很低。模具和工装占用是第二个约束。冲压工序和注塑工序尤其明显一套模具只能装在一台设备上模具在A设备上生产的时候B设备即使空闲也没法干这道工序。所以AX里把模具模型做成了“单资源”跟设备资源一样参与排产占用。物料齐套状态是第三个约束——不是所有物料都能准时到位外购件延误是常事。我们在工单上增加了一个“齐套时间”字段排产时工单的最早开始时间不得早于齐套时间。再加上班次日历白班夜班、周末加班、节假日停机每台设备一个日历。这些约束全部建模完成后AX才真正有了“排出来就能落地”的基础。3. 排产引擎的核心逻辑优先级算分、瓶颈拉式排程与滚动重排3.1 先定优先级一张可调整的算分表算法引擎里最先处理的是“先排谁”的问题。我们没有用一个单一指标比如“交期最早优先”而是做了一张可配置的算分表每个参与排产的工单任务都会被计算一个综合优先级分数。分数越高越早被排入设备时间轴。算分表的设计思路是把业务关注维度拆开交期紧迫度、客户等级、工单余量、设备稀缺度、是否是插单。这五个维度各有权重权重可以在系统配置页面里调整不需要改代码。举个例子交期紧迫度打分按“剩余天数/剩余工序数”计算剩余天数越少分数越高客户等级分A/B/C三档A类客户基础分50工单余量指已产出数量占订单数量的百分比余量越小越要优先设备稀缺度取决于该工序候选设备组的设备数量候选设备越少分数越高插单标记是个布尔值销售特批的急单直接加30分。这样算下来一个A类客户、交期紧、差最后一道工序、只在一台设备上能干的活优先级分数必然很高。值得强调的是算分表本身就是管理意图的数字化表达。销售想提高某个客户的权重生产副总想强调瓶颈设备的利用率都可以通过调权重来实现。这个过程我们每个月沟通一次调完直接生效比外购系统动不动发版本迭代要快太多。3.2 瓶颈设备上做拉式排程其余工序按时间窗推演优先级分算完接下来是排程主体。AX采用的策略是“瓶颈设备拉式排程 非瓶颈设备前推排程”混合路径。先说为什么不在所有设备上统一用前推排程前推就是从工单第一道工序开始按设备空闲时间一个个往后排逻辑简单但结果往往是瓶颈设备前面堆了一堆半成品瓶颈设备本身却吃不饱。排产的本质是让瓶颈环节的利用率最大化因为瓶颈环节损失一个小时整条产线就损失一个小时。具体做法是分三步。第一步识别瓶颈设备统计过去三十天内每台设备的实际利用率利用率最高的三到五台设备标记为瓶颈设备。第二步对瓶颈设备上的工序按优先级倒排从工单交期往前推推算出每道瓶颈工序的最晚开始时间和最晚结束时间形成各工单在瓶颈设备上的时间窗。第三步瓶颈设备的时间窗排定之后再把瓶颈之前和之后的工序分别向前向后推演填充到各自的候选设备上。这个过程我打一个比方瓶颈设备是高速公路的收费站所有车都要经过它那么你先把每辆车过收费站的先后顺序定下来再倒推每辆车什么时候应该从家出发、什么时候应该到达目的地整条路的通行效率才能最高。AX在第三步填充非瓶颈工序时默认留出一段缓冲时间一般是标准工时的百分之十五用来吸收上游工序的波动。这个缓冲比例不是拍脑袋定的我们跑了三组模拟实验分别用百分之五、百分之十五和百分之三十结果显示百分之十五在计划达成率和产能利用率之间最平衡。3.3 资源冲突消解与人工干预入口再完善的算法也会遇到冲突。比如两个急单都想独占唯一一台精密磨床时间窗头尾相接。AX的冲突消解采用逐级让步策略第一级让步是检查该工序能否移动到同设备组的其他替代设备如果精度允许就自动转移第二级让步是压缩缓冲时间从百分之十五压到百分之八尽量挤出空间第三级让步是触发“跳工序”检查——有些工单的后续工序可以调整顺序前提是工艺部门在系统里提前维护了“可调整工序集合”。如果三级都无法消解系统不会硬排而是把这些工单挂上“待人工决策”标记推送到调度看板。这个设计为我们争取了很大的现场信任。老周后来跟我说他最反感的就是系统“自作主张”把明明不能干的设备分配给他或者把工艺上不允许的工序顺序悄悄改掉。AX在无法消解冲突时选择“交还给人”反而让调度员觉得系统是在帮自己干活而不是跟自己抢控制权。人工干预也很简单调度员在甘特图上直接拖拽任务到其他设备系统会自动重新校验设备组、模具占用和班次日历校验通过就锁定校验不通过会给出具体原因。4. 计划-执行-反馈闭环AX与MES的数据交互和插单处理4.1 从计划到派工一键下发与报工回写排程算法跑出来的只是一张计划真正的考验在计划下发到车间之后。AX与MES的对接是核心环节。每天早晨AX把当天各设备的生产任务列表推送给MESMES回传到车间电子看板操作工人在工位终端上就能看到自己今天的任务顺序。任务完成时工人点报工按钮MES记录实际完工时间、实际加工数量、设备停机时长这些数据实时回写到AX。这个闭环里有一个很容易被忽略的细节报工数据的时间精度。我们最初设定的是“任务完成才算报工”后来发现根本不够用。一道工序加工时间可能长达四五个小时如果中途设备故障停机一小时调度员完全不知道直到报工时间延后了才察觉。后来我们改了规则增加了“工序开工报工”和“暂停报工”两个节点工人点击开工后任务在AX里自动标记为“执行中”设备如果发生异常停机MES自动上报暂停事件AX立刻在甘特图上把该任务标红并计算对后续任务的影响。这个改动让调度响应故障的速度从“发现时已经晚了两小时”缩短到“故障发生十几分钟内就启动调整”。4.2 插单、延期与设备故障三大异常的处理策略没有异常的计划不是计划只是幻想。AX上线半年后我们统计了一下触发重排的原因排前三的分别是插单、物料延期、设备故障。针对这三类异常AX设计了不同的应对策略。插单的处理策略是“局部重排优先”。销售特批的急单进来先把它放到优先级算分表里加上插单标记分然后触发一次“影响范围评估”系统只对冲撞时间窗的任务进行重排没有被影响到的任务原计划不动。这个“只动局部”的设计非常重要如果每次插单都全局重排整个车间计划就会变成一盘流沙工人今天看到的任务明天又变了信任感会迅速崩塌。物料延期处理则相对简单。工单齐套时间字段一旦更新AX标记相关任务为“待料阻塞”并把预估影响时间推到调度看板上。调度员可以根据阻塞影响范围手动决定是保持原计划等料还是把设备切换给其他任务。设备故障处理会复杂些AX收到MES的故障停机事件后先把故障设备上的任务自动标记为“中断”然后查这些任务的替代设备组是否有空闲窗口。如果有生成“转产建议”如果没有则将任务移到故障设备恢复后的时间窗末尾并通知计划员评估交期风险。这三种策略共同依赖一个机制——滚动重排。AX不是每天只排一次而是每半小时扫描一次现场数据发现偏差超过阈值就自动触发重排。阈值设定是某设备实际进度与计划偏差超过三十分钟或者某个工单齐套时间发生变更或者有新的插单进入。半小时的粒度是综合考虑计算耗时和现场反应速度的结果实测下来一版全车间重排大约需要二十秒钟完全来得及。5. 上线两年数据说话排产效率与按期交付的变化5.1 上线前后的核心指标对比做了这么一大套系统最终要看的是业务指标有没有变好。我们按上线前六个月和上线后最近六个月的数据做了对比取的是月度均值结果如下指标上线前上线后变化幅度每日排产耗时2.5小时/天15分钟/天下降90%月度计划达成率68%89%提升21个百分点订单准时交付率61%82%提升21个百分点瓶颈设备利用率74%91%提升17个百分点车间平均在制时间8.3天5.6天缩短32%月中临时加班时长约36小时约12小时下降67%最直观的变化是排产耗时。以前老周每天下午两点开始排第二天的计划下班前勉强排完碰到插单还得加班。现在系统十五分钟出全车间计划老周需要做的主要是审核和微调他的角色从“天天赶作业”变成了“关键决策的把关人”。月度计划达成率从68%提升到89%这个数据有一个微妙的解释之前手工排产不敢把计划排得太满因为一旦排满一旦现场有个风吹草动达成的数字会很难看。所以手工计划的“达成率”其实是建立在“计划故意留有余地”的前提下的。AX排产对设备利用率的预估更接近理论产能计划本身就排得比以前更满在这个基础上还能把达成率拉到89%说明现场执行效率的提升是真实的。5.2 这些数字背后的业务逻辑指标变好当然让人高兴但更有价值的是搞清楚“为什么变好了”这样才能持续改进。排产耗时下降直接原因是Excel被AX取代间接原因是数据采集从人工汇总变成了MES自动推送。以前光是把各班组的产品日报汇总到一张表上就要半小时而且数据还经常对不上。现在这一步被系统替代了省下的不只是时间还有统计口径不一致造成的扯皮。瓶颈设备利用率从74%提升到91%这十七个百分点的提升一半功劳归排产算法另一半归数据透明。以前瓶颈设备上的任务经常被非瓶颈工序拖累上游半成品不能及时供应瓶颈设备只能停机等待。AX的拉式排程确保瓶颈设备前始终有缓冲库存这个改进立竿见影。设备利用率上去之后我们本来打算新购一台设备的预算也被管理层暂时冻结了——现有产能还有潜力可挖。计划达成率提升的另一个关键因素是“计划不再频繁变动”。以前为什么达不到成因为计划本身就是乱的上午排的计划下午就改了工人都不知道自己按哪个版本来。我们做过统计AX上线之前一个月内同一个工单的任务时间被调整超过五次的占比接近四成。上线后局部重排策略把这个比例压到了百分之十以下。计划稳定了工人对系统的信任度自然上来了。6. 踩过的坑与给后来者的建议6.1 数据质量是排产系统的生命线如果让我只给一条建议那就是排产引擎的输入数据质量决定了系统的天花板。算法再聪明喂进去的是错误工时排出来的计划就是精确的胡说八道。我们第一个月上线时排出来的计划几乎被车间吐槽了一个遍。原因很朴素工艺路线里的标准工时很多是工艺员凭经验填的跟实际加工时间偏差经常在百分之二十以上。系统基于错误的工时排产时间窗自然对不上。这件事没有捷径最好的办法是拉长试运行期用三个月的时间让标准工时被MES的实际报工数据持续修正。我们还做了一个“工时偏差率”的监控报表偏差超过百分之十五的工序会被标红工艺部门每两周过一遍。另一个数据质量的坑是编码不统一。同一个物料编码在ERP里是一套在MES里是另一套同一个客户销售系统里叫“华东重工”车间报工系统里叫“华重”两套数据在系统对接时全靠人工映射。AX上线前我们花了两周时间做代码清洗建立了一张对照表过程非常痛苦但这一步的回报率极高。如果你打算做类似的系统先把基础数据治理做完再谈算法否则后面每一步都在还债。6.2 不要一上来就想做全自动刚开始做AX时我犯过一个战略上的错误想做一个“全自动排产系统”计划全部由算法生成调度员只要审核就可以。结果第一次试运行算法排出的计划被现场否掉了三分之一。原因五花八门有的工序之间需要特殊转运时间有的设备操作工请假了人没法开机有的工艺要求同一个操作者连续完成前后两道工序以保证质量一致性。这些约束不是不能建模而是团队一开始根本没有意识到它们存在。后来我们转变了策略把AX定位成“辅助调度系统”系统自动生成建议计划调度员在甘特图上做调整确认。经过三个月的人机协同配合随着越来越多的隐性约束被补充进系统调度员需要手动调整的任务比例才逐步降下来。这个“先人后人、逐步自动化”的路径比一步到位的全自动要务实得多。还有一个容易被忽视的点规则变更要有回放机制。AX每当权重调整或约束新增时会自动保留上一版排产结果。出现争议时可以把新旧两版计划放到一起对比看看到底是谁影响谁、为什么某个工单被推后了两小时。有了这个“排产快照”功能生产例会上的讨论从“谁乱改了计划”变成了“我们一起看看规则要不要调整”沟通成本下降了不止一个量级。6.3 现场共识比算法更值钱最后说一点可能听起来不太像工程师会说的话排产系统的成败算法只占了三分之一另外三分之二是让现场人员认可系统。我们的经验是调度员、车间主任、生产计划员这三类人必须在项目启动第一天就深度参与。不要等系统做完了再让看让他们从规则定义阶段就坐进来。AX在需求分析阶段我们找了经验最丰富的老师傅做了四轮访谈把他们嘴里的“感觉”“大概”“差不多”翻译成可量化的规则。老师傅提到“瓶颈设备前的缓冲不能少于两小时”这句话后来变成了系统的硬约束。他提到“某些客户欠了我们人情这次交期松一点也没关系”这句话没法直接建模但最终演变成了优先级算分表里的“客户等级权重”——把模糊的人情变成了透明的规则。上线两年AX系统最大的变化不是算法越来越好而是老师和车间之间的信任关系变了。以前排产是调度员的个人手艺关在脑子里带回家。现在排产规则写在系统里透明可见谁都可以看谁都可以提建议。老周对我说过一句话我一直记着“这系统排的活我大部分时候是认的。它做的第一件事就是把我脑子里那些说不清的东西一个一个摆到了桌面上。”如果让我给准备做同类系统的团队一句忠告那就是别把精力全放在算力上。调度最贵的资源从来不是服务器的CPU而是现场那些经验没有流失之前你能把它们接住多少。