|
这个问题要分两个方面来讨论,一是有库存的情况下变更BOM,一是有需求的情况下变更BOM,我们先讨论在有库存的前提下变更BOM,应该如何控制?
在有库存前提下变更BOM,可能是因为两种原因导致的:
第一,原本的BOM表没有错误,后来因为工程设计上的优化或者其他原因而变更BOM,导致以前订购回来的物料不再使用。解决这个问题要从两个方面来控制:①对于那些容易发生变更的物料而且又非通用件,尽量少使用,或者不使用订货点法,而要使用MRP法,同时也不要设安全库存。批量订货数量和倍数,系统跑出来多少我们就相应采购、生产多少。这样就算BOM变更,库存里相对为"零",新旧物料替换也不存在问题。②在提出ECR变更请求的时候,要充分考虑到库存量、在订量以及待检量,如果在有库存的情况下一定要变更BOM,那么可以用设定虚项--用完替换的方法来控制。
第二,原本的BOM表本身就有错误,而且这个错误直到采购或者生产入库以后才发现,结果导致了库存积压、物料呆滞。解决这个问题也要从两个方面入手:①上ERP以后的BOM表一定要求准确,而且需要有人来检查,特别是下单的时候,审单小组需要召集相关人员做最后的BOM审核,要把因BOM表错误而导致的物料积压消灭在下单之前。②事先审核都没检查出来,后来物料已经入库,或者已经开始总装时发现BOM错误,这个时候除了需要紧急插单,补上相应的采购或者生产单外,同时也要处理这些多出来的物料。如何处理呢?此时就只能碰机会了,比如积压物料在同类型产品中是否能用到,或是等到下次有订单的时候把它用掉,或者联系供应商是否同意退货,这样也可以挽回一些损失。
此时的系统操作是:如果在下了生产单之后变更BOM,工程应及时发放ECN工程变更通知单到PMC,则PMC计划员手工修改系统提料单,相对应的采购或生产需要另外下单来完成BOM的变更物料需求。
在有需求的情况下变更BOM,我们又该如何控制呢?
这个问题应该分阶段来讨论:
第一,在业务下单之前变更BOM,这个时候一点问题都没有,所有的需求都是按新BOM表结构来产生的。
第二,在业务下单之后,但在相应子项的采购或者生产单下达之前变更BOM,这个时候需要跑一个MRP批处理,然后系统相关的行为建议都会按新的BOM表结构来产生,而旧的结构全部消失。此时也没有问题。
第三,在下了相应的采购或者生产订单,但并未入库的时候变更BOM,此时首先需要人为通知停止相应的采购或者生产动作,在第一时间里下发ECN工程变更通知到PMC、物料、品质、生产部门,PMC直接手工修改相应的系统提料单,采购、生产手工下达相应的物料需求单来满足因BOM变更而导致的需求。
第四,相应的采购或生产都已经入库,或者到总装时才发现BOM错误,这个时候的情况和在有库存时变更BOM情况一致,请参考上面的内容予以处理。 |
|