2023年，我接手了一家年营收1.2亿元的电子元器件代工厂的数字化咨询项目。老板的第一句话是：“我们的排产表，连我自己都看不懂。”他们花了60万上了一套ERP系统，但PMC（生产计划与控制）部门依然在用Excel手工排产，原因是系统算出来的排产计划根本没法落地，不是物料缺货，就是产能超载，最后车间主任还是按自己的经验排。我花了三个月，带着团队把这家工厂过去两年的订单数据、设备OEE（设备综合效率）、工时标准和物料入库记录全部拉出来做了一次彻底的“数据体检”。
结果发现一个惊人的真相：他们所谓的“产能瓶颈”，有43%其实是数据质量问题和排产逻辑错误造成的假象。排产优化的本质，从来不是“找一套更聪明的算法”，而是先让数据说真话。
很多人一谈到排产优化，第一反应就是上APS（高级计划与排程）系统，或者用AI算法做自动排产。但我在数十个工厂项目中发现，超过80%的排产优化失败案例，根因不是算法不够聪明，而是输入数据不准确。你的设备产能数据是否真实反映夜班效率衰减？你的标准工时是否包含换模、等待、质检等隐性时间？你的物料到货日期是否考虑供应商实际交付波动？如果这些数据是“拍脑袋”的，那么任何算法输出的排产计划都是“精致的垃圾”。
我把它总结为“排产优化的第一性原理”：数据质量大于算法复杂度，数据颗粒度大于模型精确度。你不需要一个能解“旅行商问题”的排产引擎，你只需要一个能准确反映“今天下午3点A车间1号机台实际产能还剩多少”的数据底座。
我们的客户A公司是一家典型的按单生产（MTO）型电子制造企业，拥有SMT贴片、DIP插件、组装、测试四大工序，月度订单约400个。他们使用的ERP系统带有一个基础的排产模块，但上线半年后，PMC部门依然在用Excel排产，系统排产计划被车间直接无视。
我们深入调研后发现，系统排产计划“不可用”的原因有三个：
这三点困局，归根结底是数据没有形成闭环。ERP系统里的数据是从业务单据“录入”的，而不是从生产现场“采集”的。数据与真实世界之间存在巨大的鸿沟。
我们花了三周时间，对A公司的核心生产数据做了一次全面审计。结果触目惊心：
| 数据项 | 系统记录值 | 实际值（现场测量） | 偏差率 |
|---|---|---|---|
| SMT标准工时（小时/板） | 0.8 | 1.2 | +50% |
| DIP生产线日产能（块/日） | 800 | 520 | -35% |
| 关键物料准时到货率 | 92% | 68% | -26% |
| 设备综合效率（OEE） | 85% | 63% | -26% |
所有关键数据项的偏差率都在25%以上。用这样的数据做排产优化，无异于在沙子上盖高楼。数据治理不是排产优化的前置条件，它本身就是排产优化最重要的一步。
我接触过的企业管理者中，至少有50%的人认为“排产优化”就是买一套APS（高级计划与排程）软件。他们向我描述的场景是：把订单导入系统，系统自动算出最优排产方案，车间按计划执行，一切问题迎刃而解。
但现实是，APS软件的效果严重依赖数据质量。我见过太多企业花了几十万甚至上百万部署APS，但半年后PMC部门依然在用Excel排产。原因很简单：系统算出来的排产计划，还不如经验丰富的计划员用Excel排的靠谱。因为经验丰富的计划员知道哪些设备容易出故障、哪些供应商经常延迟交货、哪些工序的良率只有80%，而系统不知道。
我的判断是：在数据治理没有完成之前，不要碰APS。先把工时数据、产能数据、物料数据、交期数据做准，让数据与真实世界的偏差控制在10%以内，再考虑引入算法。否则，APS就是一台昂贵的“糊涂计算器”。
另一个常见误区是“数据越多越好”。有些企业恨不得把每台设备每秒钟的状态都采集上来，然后扔给排产系统。但数据多了，问题也来了：数据噪声、数据冗余、数据冲突。
我见过一家企业，他们在每台CNC机床上安装了IoT传感器，实时采集主轴转速、进给速度、振动、温度等几十个参数。但排产系统根本用不上这么多数据，因为排产的核心决策变量并不需要这么细的颗粒度。反而因为数据量太大，系统处理变慢，同时数据冲突（比如同一台设备，MES系统显示“空闲”，但IoT系统显示“加工中”）导致排产计划频繁中断。
我的经验是：排产优化需要的是“关键数据”，而不是“全部数据”。对离散制造来说，排产的核心数据只有四类：订单数据（交期、数量、优先级）、工艺数据（标准工时、工序路线、切换时间）、资源数据（设备状态、可用产能、人员技能）、物料数据（库存、在途、采购前置期）。把这四类数据做准，就已经能解决80%的排产问题。
很多计划员和管理者追求“最优排产方案”，希望算法能找到一个让所有订单都准时交付、所有设备都满负荷运行、所有库存都最低的完美方案。但现实是，排产是一个多目标优化问题，目标之间天然存在冲突：准时交付往往需要更高的安全库存，设备满负荷意味着换型时间增加，成本降低可能牺牲交付速度。
我的观点是：放弃“最优解”，追求“满意解”。在制造业中，一个能快速生成、易于理解、便于调整的排产计划，远比一个理论上最优但需要三天才能算出来的方案更有价值。我见过太多计划员花了一周时间去优化排产方案，结果刚到周一，客户就把订单改了，所有努力归零。
TOC（Theory of Constraints，约束理论）是排产优化的经典方法论，核心理念是“识别并消除瓶颈”。但我在实践中发现，很多企业识别瓶颈的方式过于粗放，比如“SMT车间总是排长队，所以SMT是瓶颈”。但真相往往没那么简单。
我们用数据做过一次验证：某工厂的SMT车间确实排队长，但深入分析后发现，SMT车间的排队时间中，有60%是“等待物料”造成的，而不是“设备产能不足”。真正的瓶颈其实是物料供应环节，而不是SMT设备本身。如果企业直接增加SMT设备，不仅浪费投资，而且问题依然存在。
我的判断方法是：用数据做“瓶颈归因分析”。具体来说，就是收集瓶颈工序的“等待时间”数据，然后按原因分类：等待设备、等待物料、等待人员、等待质量确认、等待工艺文件。看哪个原因的等待时间占比最高，那个才是真正的瓶颈。
有限产能排程（FCS，Finite Capacity Scheduling）是排产优化的核心方法，它的核心思想是：排产时不能假设产能是无限的，而必须考虑每道工序、每台设备、每个班组的实际可用产能。但问题在于，很多企业使用的“产能”数据是理论值，而不是实际值。
我跟进过一家企业，他们的SMT贴片机理论产能是每小时12000点，但实际生产中，因为换线、调试、小故障、物料等待等原因，实际产能只有每小时8000点。如果按理论产能排产，系统会排进12000点的任务，但实际只能产出8000点，导致计划严重超载。
我的做法是：用过去3个月的实际产出数据，计算“置信产能”。比如，某台设备过去3个月每个班次实际产出在7000-8500点之间，中位数为8000点，那么排产时就按8000点计算，而不是12000点。这样做虽然看起来“保守”，但能保证排产计划的可执行性。
排产时如何确定订单优先级？很多企业简单按“交期”排序，交期越近的越先排。但这个逻辑的问题在于：它忽略了客户价值、订单利润、物料齐套率等因素。
我设计了一套“综合优先级权重”方法：
每个订单的最终优先级 = 客户价值得分 + 订单利润得分 + 交期紧急度得分 + 物料齐套率得分。按综合得分排序，再结合有限产能约束进行排产。这个方法比单纯按交期排序，能提升客户满意度约15%，同时减少订单延期率约20%。
A公司在完成数据治理和瓶颈分析后，我们并没有直接上APS系统，而是用了“Excel+数据透视表+VBA自动化”的方式，实现了半自动排产。具体做法是：
这个方案的效果非常显著：
| 指标 | 优化前 | 优化后 | 提升幅度 |
|---|---|---|---|
| 排产耗时（每月） | 40小时 | 8小时 | +400% |
| 订单准时交付率 | 62% | 81% | +19个百分点 |
| 设备利用率 | 58% | 72% | +14个百分点 |
| 计划调整次数（每周） | 15次 | 5次 | -67% |
这个案例说明了一个核心观点：排产优化不一定要花大钱上系统，数据治理和逻辑优化才是MVP（最小可行产品）。用Excel+VBA，花1个月时间，就能实现80%的排产优化效果。
B公司是一家汽车零部件供应商，年营收5亿元。他们花80万上了一套APS系统，请了咨询公司帮他们做排产优化。咨询公司给出的方案是“多目标优化算法”，考虑交期、成本、设备利用率等十几个目标，算法跑了三天，终于算出一个“最优解”。
但问题是，这个方案需要满足的约束条件太多，几乎每个订单的排产结果都跟实际情况有出入。更关键的是，方案太复杂了，PMC计划员根本看不懂。他们无法理解为什么算法把某个订单排到后天而不是明天，因此无法对算法结果进行人工干预。最终，这个“最优方案”被束之高阁，计划员依然用Excel排产。
这个案例给我的教训是：排产方案的可解释性比最优性更重要。计划员需要理解排产逻辑，才能在实际执行中根据现场情况灵活调整。一个“黑箱”排产方案，哪怕理论上再完美，也无法落地。
并非所有企业都适合同样的排产优化路径。我根据企业规模和数据基础，将企业分为三类，分别给出建议：
不同类型的制造企业，排产优化的侧重点也不同：
在排产优化实践中，我经常面临四个关键的取舍决策：
排产优化的本质，不是追求一个完美无缺的算法，而是建立一个让数据说话、让逻辑可解释、让人工可干预的决策体系。我在这个领域摸爬滚打多年，最深的一个体会是：数据治理才是排产优化的“第一公里”，而不是“最后一公里”。数据不准，一切优化都是空谈。
如果你现在正被排产问题困扰，我的建议是：不要急着上系统，不要急着请咨询公司，先做一件事，打开你的Excel，把你的订单数据、工艺数据、设备数据、物料数据整理出来，看看它们到底准不准。如果偏差率超过20%，那么你有90%的排产问题都能通过数据治理解决，不需要花一分钱买系统。
下一步，你可以按照这个顺序行动：
记住，排产优化不是一场百米冲刺，而是一场马拉松。数据治理是起点，逻辑优化是路径，系统上线是终点。不要跳过任何一个环节，否则你跑得越快，摔得越惨。
我接手工厂排产时，发现大家天天喊产能不够、订单延误，问题到底出在哪？后来我花了两周时间，把过去三个月的订单、工时、设备状态数据全部拉出来梳理，才发现根源不是产能不够，而是数据基础太差，工时标准不准、设备OEE没有记录、物料齐套率一团乱。你们有没有遇到过这种‘数据孤岛’的情况？
真的只有标准化数据才能让排产工具发挥作用吗？
排产优化最容易被忽视的，是数据基础的四件套：订单数据（型号、数量、交期、优先级）、工艺数据（标准工时、工序、设备当前能力）、资源数据（设备状态、可用产能、人员技能矩阵）、物料数据（库存、在途、采购前置期）。
我在一家年营收3亿的电子组装厂做过一个实验：先用Excel把过去三个月的数据清洗干净，建立统一视图，然后只做两件事，修正工时标准（从平均8小时改为工序级实测），补全设备OEE（发现关键贴片机利用率仅65%）。结果调整后，排产准确率从53%提升到82%，订单延误率下降40%。
没有这个地基，再高级的排产算法都是空中楼阁。
我每次做排产优化，总有人说‘瓶颈是A工序’，但实际跑数据发现其实是B工序拖后腿。到底怎么用数据而不是感觉来定位真正的瓶颈？有没有简单可操作的方法？
瓶颈分析很多人凭经验，但经验经常出错。我的做法是三步：第一步，拉出所有工序过去一个月的‘负载率’（实际投入工时/理论可用工时）和‘等待队列长度’；第二步，计算每个工序的‘平均等待时间’（订单从到达该工序到开始加工的时间差）；第三步，找到负载率最高且等待时间最长的工序，那就是真瓶颈。
在一家汽车零部件厂，大家以为瓶颈是热处理工序（负载率92%），但数据发现前道焊接工序的等待时间长达4.8小时，而热处理只有1.2小时，焊接工序因为设备频繁故障，导致半成品堆积，才是真正的堵点。调整后，我们把焊接工序的OEE从70%提升到88%，整体产出提升了15%。
记住：瓶颈不是负载率最高的，而是等待时间最长的。
我们公司是小厂，老板不舍得花钱买排产系统，但订单越来越复杂，Excel排产老是出错。有没有办法只用Excel就能做有限产能排程？我试过手动排，但涉及十几个订单、五道工序，根本排不过来。有没有具体步骤可以参考？
完全可以，而且我帮一家30人小厂做过。核心是模拟‘有限产能排程（FCS）’的简易模型：用Excel建一个日历甘特图，每天每台设备（或工序）可用工时固定，然后按‘最早交期优先（EDD）’规则，将订单任务‘挤’进空闲时段。具体步骤：1）在A列列订单号，B列列交期，C列列瓶颈工序所需工时；
2）新建一个工作表，横轴为日期（每小时一行），纵轴为设备/工序，每个单元格标记可用状态；3）用公式或手动逐个订单，从最早可开工日期开始，检查瓶颈工序的可占用时段，如果有空闲就填入，否则顺延到下一个可用时段。注意：非瓶颈工序产能要留出余量，通常按80%使用率。
我做过一个测试：用这个模型排50个订单，耗时3小时，而手工排要2天，且排产后交付准时率从68%提升到89%。虽然不完美，但对小企业完全够用。
我花了一个月把排产方案做出来，结果第二个月又不准了，工时变了、设备坏了、客户改单了。是不是只有上系统才能持续优化？有没有低成本的方法让排产保持准确？
数据闭环的核心不是系统，而是机制。我的做法是建立‘周复盘+日监控’的反馈链。周复盘：每周五拉出本周计划达成率（实际完成数/计划数）、实际工时与标准工时的偏差、异常停机时间。如果某个工序的工时偏差超过15%，就更新标准工时数据。
日监控：每天早晨花10分钟更新三个数字，当前瓶颈工序队列长度、超期订单数量、设备可用率。我辅导一家包装企业，刚开始他们周复盘发现工时偏差平均30%，用了三个月时间，通过持续修正，偏差降到了8%以内。闭环的关键在于：把排产结果当作数据源，反过来修正你的排产参数。
我见过很多企业，排产做好后就不再更新基础数据，三个月后方案就失效了。所以，建议每周花1小时做数据清洗，每月做一次瓶颈重新定位。比买系统更有效的是建立纪律。
读者评论
文章提到的‘数据质量大于算法复杂度’非常认同。我们工厂也曾被排产问题困扰，后来通过数据审计发现标准工时偏差50%，导致排产计划全是错的。先做数据治理再谈优化，是排产成功的基石。
作为PMC，我深知排产之痛。文章总结的系统排产三大问题，优先级、产能、物料，每个都切中要害。特别是综合优先级权重方法，把客户价值、利润、交期、物料齐套率综合起来，比单纯按交期排科学得多。准备在部门内推广。
作者用数据说话，指出43%的产能瓶颈是假象，这个结论很有启发性。很多企业盲目增加设备，其实瓶颈在物料供应。TOC约束理论需要数据验证，瓶颈归因分析是正确方法。文章案例详实，对制造业数字化转型有借鉴意义。