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

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

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

再往前问一步:两批产品名称相同,图纸版本不同,还能不能合?

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

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

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

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

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

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

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

接着,再看拆单、合单。

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

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

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

举一个假设例子:甲客户要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可用于辅助建模、脚本开发,也能在已配置的权限与工具范围内查询数据、参与业务操作。不过,复杂排程算法、现场接口和具体控制规则,仍要逐项验证实现方案;不能把平台可开发,理解成所有行业规则已经预置。

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

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

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

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

相关推荐
什么嘻嘻果冻6 小时前
无代码开发平台中的自然语言生成:恐象AI实现路径
大数据·人工智能·低代码
李福春7 小时前
技术思考问题19:低代码省代码,能省架构吗?
低代码·架构·rxjava·深圳同盟·腾讯云架构师技术同盟·能力圈·机会成本
用包装物1 天前
表单草稿自动保存:断网不丢数据
低代码
RestCloud1 天前
iPaaS集成平台如何打通ERP、CRM、OA等异构系统
数据治理·crm·erp·ipaas·oa·集成平台
SL_staff1 天前
低代码选型避坑指南:为什么‘能拖拽’不等于‘能交付’?——基于JVS八大引擎的四维交付能力评估框架
java·低代码·spring cloud
逻辑孤独2 天前
小店进销存实操:扫码收货、卖货、盘货三个环节
低代码
三号路口2 天前
消息推送去重:同一事件只提醒一次的实现
低代码
内存过载2 天前
用表格模拟甘特图:项目排期的土办法
前端·低代码
百数平台2 天前
六大 AI 智能体业务场景:表单、巡检、合同审查落地实践
低代码·ai