多品种、小批量生产，系统选型前要梳理哪些业务规则？

把“支持合单生产”写进选型需求，乍看已经很具体了。

可合的是哪一种单？两张客户订单合成一个生产任务，还是只把其中相同的加工工序排在一起？合起来以后，一部分产品返工，先扣哪张订单的可交数量？

再往前问一步：两批产品名称相同，图纸版本不同，还能不能合？

这几种情况，都可能被概括成合单。供应商回答支持，企业也点头，双方却未必说的是同一件事。等系统上线，计划员要拆回去，仓库要分开领，质量员还得重新确认追溯关系。

多品种、小批量生产的选型，恰恰容易在这里产生误会。订单少量、多变，同一类产品也可能有不同配置、工艺和客户要求。功能名称能对上，具体做法却未必对得上。

所以，选型前值得做的准备，是把日常工作中那些“可以一起做”“这次可以改”“这批不能动”，逐项说清楚。

一、先分清，哪些可以合，哪些必须分开

小批量不意味着所有环节都要一单一做。

通用零件可以先备货，接单后再完成差异化加工；同类零件可能集中下料，后续分成不同工单；也有产品需要从采购开始，就与特定客户订单对应。企业内部完全可能同时存在这些做法。

梳理时，先按产品类别确认：什么情况下开始采购和生产，依据是正式订单、已批准的备货计划，还是设计确认后的任务？哪些资料没确认时只能做准备，不能直接投产？否则，需求预测和正式订单都进入计算，还有可能重复安排采购。

接着，再看拆单、合单。

订单批量、生产批量和转序批量，可以不同。客户订了一批货，工厂可能分几次生产；前道完成一部分，经允许后就转给后道，不必总等整单完成。但某些热处理、配料或检验过程有整批要求，也不能为了赶交期随意拆开。

需要确认的是拆并条件，而不只是增加两个按钮。

哪些规格、版本、材料、工艺和客户要求必须一致，才能拼批加工？允许合并的是整段路线，还是某一道工序？谁批准，怎样标识，完工后如何分回原订单？

举一个假设例子：甲客户要30件，乙客户要20件。技术与质量人员确认，两批在某道工序满足共同加工条件，可以安排一个50件的加工任务，但客户订单、数量分配和必要批次标识仍须保留。若只有其中一批允许分批交货，发货时就不能把50件当成同一项承诺。

共同加工产生的准备费用、外协费用如何分配，也要与财务确认。不能仅因为数量合在一起，就默认成本和责任都平均分。

生产上允许合并，管理上仍可能需要分别核算、分别交付、分别追溯。系统的数据关系要能表达这种区别。

图1：30件和20件为正文假设。满足共同加工条件后，订单来源、数量分配及交付要求仍分别保留。

二、版本和用料规则，要说到具体订单上

多品种生产中，难处理的不只是产品数量，还有相近产品之间的细小差异。

一个孔位改了、一种材料换了、表面处理要求不同，都可能影响采购、加工和检验。产品名称没有变化，不代表原来的生产依据还能继续用。

因此，物料编码、技术图号、产品配置和版本分别表示什么，需要先约定。不是每次文件修订都要新建物料编码，也不能仅凭名称相同，就认定两个版本的实物可以互换。是否需要分开库存、是否允许互换，应由企业按技术和交付要求判断。

选型前尤其要回答：新版本批准后，哪些订单开始使用，哪些在制品仍按原要求处理？

尚未下达的任务、已经领料的任务、加工一半的产品，不能只靠更新一份公共附件就全部切换。变更应明确适用范围、批准人，以及旧料、在制品的处理办法。涉及客户要求时，还要确认是否需要客户认可。

历史工单也要能查到当时实际采用的依据。文件库里保存着旧图，不等于能够证明某批货当时用的就是那张图。

替代料同样如此。

缺料时能否换料，要明确可替代的物料、适用产品、用量换算、限制条件和审批权限。一次订单上的临时批准，不应不加区分地变成以后所有订单的默认选项。仓库实际发出了哪种料、哪个批次，也应与批准结果对应。

这里还牵涉一个容易被忽略的约定：通用库存先分给谁？按交期、客户承诺，还是已批准的生产顺序？已经分配的物料允许谁调整，挪给急单以后，原工单怎样重新计算缺料？

如果这些问题尚无一致意见，系统自动分料，只会把某一种未经确认的做法执行得更快。

图2：版本变更须按任务状态评估；临时替代批准只适用于明确的范围，不自动推广至全部订单。

三、排产之前，先确定什么不能被排程改动

小批量订单多，减少换型通常有价值。但把同类产品排在一起，也可能推迟另一张急单。

这就需要明确排序目标：先满足已承诺交期，还是优先减少换型？遇到冲突时由谁取舍？质量和工艺禁止的安排，不能因为设备利用率更高就被采用。

基础时间也要分开。

准备夹具、换刀、调程序所花的时间，与连续加工每件产品所花的时间，并不一定按同样方式变化。假设一次换型需要40分钟，每件加工5分钟，做10件就需要90分钟的相关设备时间。这里只为说明计算方式，不能把它当成行业工时，更不能只拿50分钟加工时间去排设备。

还要区分哪些准备能在机外提前完成，哪些必须占用设备。两台机器都能做某道工序，也要核实夹具、人员资格、加工能力及批准条件是否相同，不能只按设备名称判断可以替换。

对开工条件，则要避免两个极端。

要求整单所有物料齐套，可能让本来能先做的工序一起等；什么都没确认就先下工单，又可能增加半成品积压。企业可以按工序明确开工条件：这一道需要的物料、有效文件、工装和检验条件是否具备，后续关键资源是否已有安排。

插单规则必须接着讨论。

谁能提出急单，谁能批准调整？已经上机的任务能否中断，今天已下达的任务是否允许重排？若设定一段计划不随意调整的时间，应明确起止范围和例外权限，不必照搬统一的天数。

批准插单前，还应看到被挤占任务的影响。急单提前了，原订单晚了，却没有人重新确认交期，协调工作就没有做完。

因此，比较排程能力时，既要看系统会不会计算，也要看它能否遵守企业确认的资源约束、调整权限和交货优先级。

图3：工时为教学假设，按换型全程占用同一设备、顺序加工计算。实际还须核对其他时间和资源条件。

四、外协、返工和余料，最能检验规则有没有说透

正常路线容易画，例外发生后，原先的数量关系是否还能解释清楚，才更考验系统。

先看外协。企业要区分整件委外与某道工序外协，确定交出的是原料还是半成品、由谁供料、按什么数量或工作量结算。计划里还要纳入发运、供应商加工和回厂接收安排，不能只为外协工序填一个加工时长。

供应商分批交回时，应分别记录已交出、已交回、待检、合格、返工及未回数量。回来了多少，与下道工序可以用多少，是两件事。

质量异常又会产生新的分支。

某个流转批次中部分产品不合格，需要明确隔离对象、处理权限、返工路线和复检要求。若异常原因可能影响整批，先按质量要求控制疑似范围，不能为了凑交货数量，只冻结已经发现的不良件。

例如，在一个不涉及合批的20件流转批次中，18件已确认合格，2件进入返工。返工完成后，这2件仍是原来的产品，需要复检，不能再报一次产量，就把订单完成数累计成22件。若最终报废并补做，报废和补做则应分别留下记录。

图4：仅说明正文独立20件批次的数量口径，不与甲乙客户共同加工例子混用。18件是否可先流转，仍依质量和工艺要求判断。

余料也是小批量管理里值得提前讨论的细节。

整根、整张材料开料后剩下的部分，满足什么尺寸、材质、批次和状态才能再用？由谁判断，放在哪里，下一次怎样找到并计入可用量？确有复用价值的余料，如果系统里只剩一个重量数字，计划员未必能判断它是否适合下一张订单。

这些规则最终会影响成本。换型、返工、补料和外协加急费用，要记录到什么程度、归到哪张任务上，取决于企业准备回答什么问题。想比较同类小单是否赚钱，就不能只保存整月的费用总额；也不必为用不上的分析，让操作员重复填十几项数据。

五、规则梳理到什么程度，才可以开始选型

不必等所有历史数据都整理完，也不必要求每个例外都提前有答案。

但那些决定订单能否合并、任务能否开工、物料能否替换、产品能否放行的规则，至少应有明确的当前做法和确认负责人。不能把企业内部尚未决定的事，全部写成“系统灵活支持”。

可以拿近期有代表性的订单、变更单和异常记录，组织销售、计划、技术、采购、仓库、质量及财务共同核对。IT负责把要求变成可实现的系统逻辑，业务部门负责确认这是不是企业认可的做法。

一条可以用于选型的规则，至少要说明：什么条件下，谁可以做什么，做完影响哪些记录，例外由谁决定。

下面以临时替代料为例，展示写法，并非建议所有企业采用同一审批制度。

适用范围：指定产品、指定订单及用料工序，不自动扩展至其他订单。

前置条件：技术人员确认适用性和换算关系，质量岗位确认检验要求；需要客户认可的，取得相应认可后再执行。

执行与记录：授权岗位批准后，仓库按批准数量发料，记录实际物料与批次；原需求和替代关系可以查询。

变化处理：取消替代、超量使用或更换另一种材料，重新按授权规则确认，不能靠修改备注放行。

同样一句支持替代料，写到这里，才知道系统究竟要校验什么。

尚未讨论清楚的规则，应单列待决事项，写明负责人和确认时间。每次都在变化的参数，例如交期优先级、允许使用的替代设备，也要区分出来，询问以后由谁维护、调整是否需要开发和测试。

选型需要一套能执行的当前规则，也需要为合理变化留下维护办法。

六、带着规则试系统，才能比较实施范围和代价

到这一步，再安排演示，就不必只跟着供应商的菜单看。

可以用脱敏资料准备一组连续测试：两张订单满足条件时安排共同加工，保留来源与数量分配；把其中一张改为不兼容版本，检查是否阻止或转交授权确认；再加入一次已批准的临时换料、一次插单和一次部分返工。

不需要所有情况都一次做成。每做一个动作，核对订单、工单、库存、质量和预计交期发生了什么变化。还要用无权限账号试一遍，看看限制是否真正生效。

图5：验证结果须区分标准支持、配置、开发和暂不支持，并确认相应交付及维护工作。

标准ERP或MES已经能覆盖的规则，可以优先通过配置验证。需要开发时，要把具体差异、交付结果、测试责任和维护费用列入范围，避免签约时都叫支持，实施时每条都变成新增需求。

针对需要较多定制的企业，织信这类企业级AI开发平台也是一种建设选择。它以数据模型为基础，提供关联数据、工作流、权限、脚本及接口能力，可以用于开发ERP、MES等复杂系统，而不只是在现有软件外增加几张表。

例如，上面的临时替代料规则，就可以作为一个小范围验证题：关联订单、用料和批准记录，限定适用范围，让发料与审批结果对应。企业借此比较实现方式和后续维护工作，比只看能否快速生成一个表单更有意义。

织信的AI能力可辅助建模、脚本开发，也能在配置的权限与工具范围内查询数据、参与业务操作。不过，复杂排程算法、现场接口和具体控制规则，仍要逐项验证实现方案；不能把平台可开发，理解成所有行业规则已经预置。

最后，别漏掉已有系统的数据分工。产品版本、库存、工单和质量结论分别以哪里为准？谁维护，如何传递，接口失败或重复提交后怎样核对？规则跨了两个系统，就要把两边一起测，而不只验收一个页面。

选型前把这些事谈清楚，企业才能判断自己需要的是现有模块配置、行业软件，还是一套能够持续定制的系统。

多品种、小批量生产，变化无法全部消除。但哪些可以合、哪些必须分，哪些允许改、谁有权改，可以先有共同的约定。

让供应商按这些约定做一遍，再谈系统是否适合。否则，买到的可能只是同一组功能名称，外加另一套工作习惯。