Today's share
01
背景介绍
工程变更业务一直是SAP实施的过程中比较常见的业务。不止是汽配行业，其他行业只要对研发要求较高、较规范的企业都会涉及到工程变更的业务及应用。
常见的工程变更主要包含两种：立即切换（强制切换）和自然切换（消耗库存类切换）。
立即切换（强制切换），顾名思义就是研发对某些零件需要升版，对旧件要进行淘汰，并且旧件即使有再多的库存也不能再进行使用，一旦切换后旧件将形成呆滞库存。这类的业务对应的系统实现，相对而言也是比较简单的，研发在BOM释放的时候基本上不需要与采购、物控等部门多轮沟通设定零件的切换日期，主要是在研发和质量部门的考虑下，应该在哪个日期切换，现场根据切换日期进行执行。
自然切换（消耗库存），该类就是一般业务部门比较头疼的业务了。一般研发会与采购、物控、生产计划开多轮切换会议，评估初始切换日期和最终切换日期。比如某零件要升版，研发会提前如3到6个月召集各相关部门查询旧件目前的库存情况、在途情况以及未来的生产计划需求数量，进行评估出初版计划切换日期，然后进行发布工程变更切换日期，并作用至BOM中进行有效日期切换。当临近切换时间，两周到一个月内会再次查询旧件目前的库存情况、在途情况以及详细的生产计划需求数量，得出更精准的切换日期。由于是自然切换，之前定义好的初始切换日期不一定精准且已经生效在BOM中，并形成了计划订单或者甚至有的企业转单的提前期非常长已经转为了生产订单，那么企业应该如何比较平滑的作消耗库存类切换？项目组应当如何设计较优的可应用的、能辅助业务部门调整的解决方案？
02
解决方案设计
（1）工程变更隐藏的“强大”实用功能：
大家都知道工程变更设定的零件切换的日期在工程变更维护该日期生效过后，会作用于BOM中，BOM修改时根据工程变更号的切换日期将新件、旧件通过不同的生效日期进行拆分出两行或多行。工程变更若应用于BOM中后，那个日期在CC02修改界面显示的就变成是灰色的。若顾问或用户不知道这个隐藏的功能，就会认为工程变更和其生效日期一旦应用，就无法修改，那么针对自然切换这种是否就需要研发部门不停的生成新的工程变更号或取消工程变更激活去修改日期。
其实当工程变更应用至BOM后，若对于自然切换类变更确定新的日期后，可以直接点击切换，系统会自动应用至BOM中，再次运行MRP已经作用于计划订单也可以系统自动进行更新（生产订单属于执行层单据是不允许的）。
示例：
如研发部门提前3个月召集零件工程变更会，根据旧件的需求供给情况得出了一个初始的、不太精准的切换日期。然后创建一个工程变更号，并维护初始的切换日期：2023.06.01（笔者截图的是工程变更修改的截图）
可以看到该工程变更在应用于BOM后，日期变成了灰色无法修改。
应用于BOM中：2023.06.01计划旧件切换新件
旧件EWMS4-10的计划结余110， 临近切换前各部门通过分析查询其需求供给情况，应该旧件根据消耗库存应该继续使用至2023.06.06（06.01至06.06对新件EWMS4-11是109个）
此时去修改工程变更的有效日期，从2023.06.01修改为2023.06.06
这里隐藏的“强大的”功能就是下图的②处，SAP的常规逻辑就是工程变更作用于BOM了，日期字段是灰色，是不支持修改的。但是在②处，SAP因为对自然切换开放了，可修改日期的功能：
修改后，查询BOM的情况，自动更新切换至2023.06.06
运行MRP之前，查看计划订单组件，旧件EWMS4-10切换新件EWMS4-11日期是6月1日
通过修改工程变更后的6.06后，再运行mrp看计划订单组件。运行父项MRP
此处发现有个小注意点：6月6日还是用的新件EWMS4-11，对于未来这类数据如果通过计算可用，算到旧件EWMS4-10是110的计划结存，可以在用到6月6日当天的43使用完，剩余1个，切换日期不能给6.06需要给6.07。
修改工程变更生效日期至06.07
修改后
再次运行MRP，A料剩余结存只剩1了
对于该情况，笔者建议剩余的结存不足以找到下一个日期或者下一个订单，需与业务沟通，是否需要保留至库存中，因为有的项目和客户会考虑避免同一个生产订单中混料使用、也减少增强的干预，调函数修改订单组件的不稳定性。如业务用户就反馈项目实际情况，只要剩一个也必须用完，不用考虑混料等问题，简单的方式就是让业务手工的去在6月7日订单中去人为修改，将55个新件数量改为54、新增一行旧件数量为1。
注意：如果有自然切换消耗库存的工程变更（初始的切换日期是6月7日），PLM不能将一个6月7日的工程变更号应用到多个父项BOM修改中，否则比如a和b对应的父项A1计算时应该6月2日自然切换，结果c和d对应的父项是A2也是用的6月7日这个工程变更号改的bom，那么c和d因为物料的需求供给不一样可能是6月20日才自然切换，这种时候修改6月1号只想改a和b的到6月7日，也会影响到c和d（可能有这块的风险，故工程变更号不同的消耗库存变更不要共用到多个BOM中，SAP标准是允许的，避免该情况则需要源头PLM进行拆分或者SAP处理形成工程变更号的时候进行拆分再作用到BOM中去）
场景二：工程变更日期调整+BOM展开号
旧件EWMS4-10在5月31日还剩110个，6月1日有多笔订单：
比如订单是1001订单需求50,1002订单需求50,1003订单需求是20.
笔者建议处理的方式是：
逻辑判断，5月31日最后旧件EWMS4-10计划结余110个，6月1日对旧件EWMS4-10需求总量是120 超过了5月31日计划结余总量，
即切换日期会在工程变更设为6月2日。此时3个订单的数量都是使用的旧件EWMS4-10，但又不够1003订单的20.
父项MD04
旧件和新件MD04
可以看到由于切换日期是6月2日，故6月1日全使用的旧件，但旧料不够，如果修改后会跑出来一个采购申请数量为10，但实际业务对于这类即将被替换的物料是不能让它跑出采购申请的
故，使用SAP的另外一个功能 “BOM展开号”（BOM展开号如果要展开来讲的话，涉及的内容和配置就比较多了，笔者此处进作为自然切换某种业务场景下需要使用展开号进行讲解）
对1003计划订单需求20数量的计划订单使用BOM展开号
达到的效果就是：如果同日期下，多个父项订单对新件有需求，而旧件的计划可用供给只能部分满足当天的订单，在工程变更日期由6月1日更新调整为6月2日过后，当天的所有计划订单都会变为旧件，那么对于不够的那一个1003计划订单使用BOM展开号，展开日期设为2023.06.02给它还原回新件。
目前是使用的旧件EWMS4-10
使用BOM展开号
使用后该计划订单是使用的新件EWMS4-11
MD04中也会记录该计划订单使用了BOM展开号
1003订单数量为20的转生产订单带BOM展开号
若存在重新读bom的情况，由于使用了展开号的原因，他会让读6月2日的新件作为组件，不会还原成旧件
BOM展开号也存在，这样避免人工、增强修改的订单组件重读BOM时读成旧件件。
但是大家细心会发现，此时旧件还是剩余了10个呆滞库存。对于有的项目客户有严格的要求，必须把这10个的给使用掉，也就是在1003的计划订单中改为10个使用旧件、10个使用新件
场景三：工程变更日期调整+BOM展开号+自开发程序
旧件EWMS4-10还剩110个，6月1日有多笔订单，
比如订单是1001订单需求50,
1002订单需求50,
1003订单需求是20.
需要改为1003订单需求是10个EWMS4-10，10个EWMS4-11.
下图中的方案二就是笔者说述的场景三的情况，只不过当时是以别的数据进行举例：
可以看到针对后面旧件部分满足的，如果客户又有强烈要求系统有自动计算的功能，就只有自开发去进行处理了。
通过自开发“呆滞库存处理平台”，根据新件的需求情况、旧件的需求供给情况，计算哪些数据需要计算工程变更切换的日期、哪些数据需要使用BOM展开号、哪些数据是需要修改计划订单、生产订单组件。该方案对于大多数切换的数据是使用的标准功能。优点为：
1.SAP设计工程变更日期可通过“单独功能”进行切换日期调整，就是专门为“消耗库存类工程变更”设计的，是全球制造型企业的最佳业务实践；
2.MRP也会根据标准功能进行考虑逻辑，不会存在BUG导致订单组件读取错误的情况；
3.自开发调整订单，仅为计算完后某单的余量数据，可以理解为每个物料涉及到的修改订单组件的情况只会有一单，此时修改订单组件功能的风险小；
4.任何项目的需求，一定是能用标准功能则用标准功能，避免程序和业务数据的复杂性带来的自开发程序BUG问题，无限次数修复；
5.手工创建和重读订单时，仅需考虑某单库存部分满足的情况。
自然切换平台功能（呆滞库存处理平台）：
另一个就是方案一，笔者之前的优化项目确实是使用的方案一。
因为当时优化项目的特点，客户一期和业务现状是只要有计划订单就转成了生产订单，故方案二本来的考虑点和优点就是系统能通过调整切换日期、使用BOM展开号去使得MRP运行的时候自动更新，那么在该客户下无法得到收益的。
方案一注意的细节非常多，笔者下一期抽空总结再进行分享。
以上为笔者实施各行各业项目自然切换工程变更业务后，与业务深入探讨的过程和理解他们的关注点，得到一些浅显的理解，欢迎更多的同行进行沟通、探讨、交流。笔者不推荐自开发，能尽量发挥标准功能到极致是原则，但是对于自然切换工程变更要减少业务的操作工作量，目前来看， SAP的标准功能不太能完全满足业务的需求，需要开发相关的功能进行辅助。以上不代表权威，仅供大家作为思路参考，感谢大家支持。
感谢支持
03
文档下载链接
666
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
