昨天车间老张又一次在电话里吼我，说三号产线又停工待料了。这已经不是第一回。
说实话，我盯着屏幕上的排程表，长长叹了口气。做生产计划排程联动调度管理平台这个项目三年多，深知一个道理：计划这东西，写出来容易，排出来要命。
平台名气很响，什么APS、MES、ERP联动，听着是个智能系统。但真正落地时，你要面对的是Excel表、老师傅拍脑袋定的优先级、还有设备时不时闹个脾气。所以很多人问我这平台到底有没有用。我的回答是，有用，但前提是你先把那些窟窿都堵上。
排程逻辑的底层矛盾：产能还是交期？
我们都巴不得交付准时又产能拉满，可现实总是打脸。一个插单进来，要么牺牲一部分设备利用率，要么推迟别的订单。排程引擎的活，就是在这些约束里找一条说得过去的路径。经典的Job Shop模型，本质是NP-hard问题。真要大范围求解，直接算到地老天荒。工程上，我们用启发式算法，遗传、模拟退火、粒子群，甚至简单的优先规则，再根据现场情况调参。
联动调度嘛，要管的不只是设备。物料齐套、工装夹具、质检资源，甚至行车运行，都得塞进约束模型。平台把这些抽象成资源对象，但你定义粒度时，坑就来了。比如我们车间，有些设备看着一样，实际能力差很多。你用名义工时做产能系数，排出来的计划基本没法看。后来我们按近三个月的OEE均值去校准，才稍微靠谱。设备OEE计算按ISO 22400标准来，数据一定要取准。
还有，排程的粒度到底是分钟还是小时？太细了，计算量爆炸；太粗了，现场没法执行。我一般建议，批量生产的用小时，单件小批的用分钟。这个得跟车间班长反复确认，不能拍脑袋。
业务规则如果不灵活，平台就是个玩具
每个车间的潜规则，比明面上的工艺卡片多得多。有的客户优先，有的紧急插单有特权，有的模具寿命有限得省着用，有的是换型时间太长必须凑单。这些规则，如果写死在代码里，那干脆别上平台了。我们做需求调研时，光优先规则就收集了三十多条，还有互相冲突的。这就要靠配置化的规则引擎来洗。
我们后来引入了Groovy脚本，让计划员自己写判断逻辑。比如“当库存低于安全库存且交期小于三天时，把优先级提到最高”，这种用脚本几行搞定。但脚本多了也乱，得有人管理，版本控制得做起来。灵活和可控，永远是一对矛盾。平台设计时，最好提供“规则冲突检测”功能，能让管理员看到当前生效的规则优先级。
这里务必参考ISA-95的模型，把计划层和执行层边界划清楚。平台不宜越俎代庖，指挥Device级动作，那是PLC的活。
我还见过一个案例，某厂把排程结果直接下发到每个机床的控制面板，结果刀补参数被计划员误改，整批工件报废。所以，联动调度要有个“安全管理带”，定义哪些数据可以自动下发，哪些只能人工确认。
联动，难在系统间的主数据同步
排程平台不是孤岛。它要从ERP拿订单和BOM，从MES拿实时工单状态，从WMS拿库存。最乱的就是主数据不一致。BOM版本不同，计量单位不对，工艺路线缺工序，都是家常便饭。我们踩过一个大坑：某料号在ERP里单位是个，MES里是套，需求数量直接放大十倍，采购差点买疯掉。
所以，我们后来在接口层做了个数据映射和校验机制。比如计量单位转换、日期格式统一、关键字段非空检查。另外，接口调用的频率也别拍脑袋。MES的设备状态十分钟拉一次，等于瞎扯，设备都停半天了你还在排。我们建议用消息队列，订阅MES的事件，实时推送设备启停、完工报工、异常报警。这样排程引擎才能拿到“活着”的数据。
关于接口性能和稳定性，我们设过阈值：API响应超过200毫秒就熔断，不再调用。数据同步延迟超过5秒就告警。这里可以参考OPC UA的数据模型规范。不要贪多求全，先把关键的几十个接口做好。
一个真实案例：机加工车间的排程改造
去年，我们帮一个机加车间上了这套平台。车间里32台数控车床、8台加工中心，还有三坐标检测，一共约50个资源。原来每天计划员手动排，要算上一个通宵。我们用基于优先规则加模拟退火的两阶段算法，目标是最小化总拖期和总换型时间。
先花了一个月做数据治理。把每台设备的额定工时、可用时间、小修大修日历全捋清楚。再设定了换型时间矩阵，比如从加工哪种材料切到哪种材料，需要多久，这些数据来自车间老技师的估算。
上线后，计划编制时间从一天压到二十分钟。设备利用率从61%升到73%，平均提前期从14天降到9天。但是，头一个月老师傅们根本不看系统，还是按自己的经验干。我们加了个人工微调功能，计划员可以手动拖拽任务，但每次调整都会记录，每周开一次复盘会，看看调整原因是什么，把不合理的规则改掉。慢慢地，系统才被信任。
所以，生产计划排程联动调度管理平台，说到底不是个算法题，是个管理题。数据不清，规则不明，再牛的引擎也白搭。系统倒是像个放大器，你输入好的治理基础，它放大效益；你输入乱麻，它放大混乱。踩过这么多坑，最大的心得就一句话：先理顺流程，再谈自动化。
