BGWN 项目Global Template 狗血设计之一 ： One SA One Material

早在去年9月份BGWN 宁波项目开工第一周，BGWN集团美国总部的 core team来宁波工厂来给我们顾问团队以及业务团队展示其SAP 全球模板的时候，负责SAP后勤模块的老美Sundar就反复强调，对于直接物料，一个采购的SA (Scheduling Agreement，计划协议)里一个物料号。说是core team强烈推荐和要求按照这个规则来下达采购SA凭证，在其全球40多家已经上了SAP的海外工厂中，都是遵循这个规则云云。

宁波业务团队立马反弹：我们向一个供应商采购几十个直接物料，之前我们只用创建一个采购订单，把几十个物料都维护在同一个采购订单里就行了。以后上了SAP，需要向这个供应商下达几十个采购SA。工作量太大，跟供应商交互也不方便，需要把这几十个采购SA，都打印出来，签字然后给到供应商，岂不让人抓狂？

老美辩称，采用一个SA一个物料的规则，理由有2：
? 第一个理由，一个物料一个SA， 这个SA只用创建一次，永久使用，不会带来工作量的问题；
? 第二理由是性能问题，说是一个SA里如果物料号太多，容易在后续的收货或者发票校验等操作时候，会容易导致数据锁定等问题。

这2个理由，貌似有些道理，工作量的问题，确实也不是个大问题，因为上线之前我们会帮忙导入open SA数据，对于直接物料我们顾问会帮忙一次性在系统里批量导入，业务以后原则上不用创建新的SA单据，除非有新的直接物料或者新的供应商。而Performance的问题，core team的说法有些牵强，个人不太认同，SAP系统里采购凭证都是采取Header-Item结构，一个单据里维护很多个item，在项目实践中，很常见，很合理。从业务的角度来讲，也是很切实际的。现在core team却一反常理，提出这么个规则，让人觉得，core team这帮家伙真是只懂IT，而不懂业务！

所以无论是宁波工厂的业务团团队，还是现在武汉工厂的业务团队，刚开始都对这个规则表示不能接受，抱怨core team的设计没站在业务的角度来思考。

在宁波项目开始2个多月的时候，我终于深刻理解了为什么core team要求一个SA一个物料了。原来在其全球模板中，采购SA的收货是通过一个RF 枪程序来做的，由于启用了DB（Documentary Batch）并且需要关联DB和供应商批次号，所以不能使用MIGO事务代码进行直接物料的采购SA的收货了。在这个RF枪程序里，不能支持一个SA里有多个物料号的场景的收货！这是个大坑，收货程序本身的局限或者说短板，才是core team要求业务人员一个采购SA一个物料的深层次的原因。只是这个大坑，core team老美不好跟我们本地顾问团队以及业务团队讲。尼玛，这个收货程序真TM狗血！你RF程序难道不能支持对含有多个ITEM的采购SA收货？有过SAP项目经验的顾问都知道，这个功能其实不难做到的！但是客户总部的core team就是这么任性，不打算加强这个RF收货程序，只支持含有一个物料号ITEM的采购SA的收货！

看来业务团队的抱怨 --- 没有站在业务的角度去设计 --- 一语中的。Core team的顾问，明显只站在技术的角度来设计！为了技术实现上的便利和简洁，或者说掩盖技术上的短板，却逆反业务常规做法，不能不说，这个设计太狗血了！

悲剧的是，虽然我们顾问不认同不屑于core team设计这个规则的理由，但是在Global 推广项目中，顾问是需要和客户总部站在同一个角度，去帮忙推广其全球模板的。所以项目里后续在和业务团队一起做GAP分析的时候，就这个问题，我们顾问团队要和业务团队开会，要帮忙想各种理由，说服业务团队接受这个规则。无论是宁波工厂还是武汉工厂，经过几轮讨论下来，业务团队终于受不了，缴械投降，接受了这个规则，‘服从总部要求’，他们说。

2016-06-02 写于武汉