前几天业务召集多部门会议讨论关于一款智能产品的出货问题。
该智能产品的生产最早是由A子公司生产，现在B子公司也要开始生产了。因为集团公司间交易模式是子公司出货均由股份/集团统一出（实物不一定），而A子公司的送货形式都是日备货的形式（生产需求预下达，提前一天做出货需求再备货），而B子公司完全相反，一直都是按订单按交期送货。
这个差异落到SAP系统中就变成了同一个物料同一个渠道里面排单做和不做可用性检查的逻辑了，这个实际上是跟SAP标准逻辑相违背的。
会上讨论了半天也没有结果，后来业务部门发邮件出来希望IT这边先想办法从系统层面上解决这个问题。
一位SAP同事自告奋勇，很快就回复了邮件并给出了相关的解决方案：取消物料的可用性检查设置，根据不同的订单来源，SAP系统通过增强开发的方式计算出物料库存占用情况，再根据订单数量来做卡控是否有足够的可用性库存。
通过系统开发的方式看起来逻辑有一定的可行性，但我立马把这个方案给否决了，原因很简单：要尽可能遵循SAP系统标准的逻辑，先以业务规范和调整为主，IT解决方案为辅。
且不说通过增强实现风险不小，如果不先从业务层面约束规范和改变业务逻辑，第一时间想到的是IT改变系统逻辑解决，表面上看起来是帮了用户的忙，但实际上无形中给自己挖了坑，给运维增加负担。
任何的业务调整和增加，往往意味着相关的业务规则逻辑需要做一定的变更，不能把这个变更都强加给IT去通过改造系统来解决。当然，在业务变更和规范的同时，IT通过一点点系统开发手段让业务变更更加可控是很有必要的。此时的IT方案就不再是做主导的方案了，而是以辅助为主。
后续：业务部门经过重新讨论，决定改变子公司交货方式，SAP系统增加一个库位，事情得到解决。
END
本文作者 | SAP梦心